Executable UML for Real-Time Systems

Mats Tigerström Department of Computer Science

Lund University, Sweden

2008

A master thesis conducted at a large telecom company.

Supervisors: Andreas Henriksson

Carl Christian Rolf

Opponent: Johan Baltsén

Examiner: Lennart Andersson

Department of Computer Science

Lund University

Ole Römers väg 3

SE-223 63

SWEDEN

© Mats Tigerström

Department of Computer Science

Lund University

ISSN: 1650-2884

LU-CS-EX: 2008-06

Printed in Sweden by the Department of Computer Science, Lund University

Abstract

New, more advanced software is released continuously. The key to this ever ongoing

progress is abstraction and reuse of code. Instead of starting from scratch with each

new program, the industry tries to adapt old solutions to new problems. The potential

to reuse old solutions has proven to be good if their behavior and structure are

described in models.

In this area, the Unified Modeling Language (UML) has made an enormous impact

and has become a tool to design and communicate program solutions on paper.

Graphical tools, where code-generation straight from models is possible, have become

available and have managed to drive the software industry forward. Today, there are

several tools, such as, Eclipse and IBM Rational Rose. These tools provide great

advantages for modeling, model testing, and code generation.

Several tools have made it possible to generate code for certain machines in one target

language. To increase efficiency even more, it is now possible to generate code for

any target machine straight from the models. The new concept is called Executable

UML (xtUML) and works with Platform Independent Models to generate code. These

models strongly increase the potential of reusing old solutions.

This master thesis was performed at a large telecom company that was currently using

IBM Rational Rose. The report will focus on xtUML and especially on the xtUML

tool PathMATE. This project has customized and shown a possible solution to

introduce PathMATE at the large telecom company. The report also highlights

benefits and disadvantages of introducing PathMATE compared to keeping IBM

Rational Rose as the main development tool at the company.

PathMATE is not a complete xtUML development tool in itself, but built as an

extension to Eclipse-based programs. By following the latest UML standard, and

introducing an Action Language, it takes a front position in leading the way to an

xtUML standard.

Acknowledgements

This master thesis has taken me on a journey filled with hard work and success.

I would especially like to thank my supervisor at the large telecom company, Andreas

Henriksson, for general guidance throughout the project, as well as great times when

discussing new ideas.

Even if I have worked alone on this project, I was warmly included in the

organization through a group lead by Roger Holmberg. I would like to thank him and

everyone in the team for a great time.

I would also like to thank the staff at the Department of Computer Science at Lund

University; Carl Christian Rolf for supervising the work progress and for giving

feedback on the report; and Lennart Andersson for all the administrative help in

addition to the regular work as an examiner.

Finally, my deepest appreciation goes to everyone close to me who has given me their

support and patience.

Thank you!

Mats Tigerström

Contents

1 INTRODUCTION.........................................................................................................................1

1.1 BACKGROUND ........................................................................................................................1 1.2 PRESENTATION OF THE PROBLEM............................................................................................2 1.3 GOALS ....................................................................................................................................3 1.4 DELIVERABLES .......................................................................................................................3 1.5 SYSTEMS AND PROGRAMS USED THROUGHOUT THIS PROJECT.................................................3

2 THEORY........................................................................................................................................4

2.1 THE BASIC IDEA BEHIND PATHMATE ....................................................................................4 2.2 DOCUMENT HANDLING IN PATHMATE ..................................................................................5 2.3 PATHMATE’S RUNTIME LIBRARY AND OTHER PARTS ............................................................5 2.4 TASK IN PATHMATE (VER. 7.0.0) ..........................................................................................7 2.5 TEMPLATES IN PATHMATE ...................................................................................................8 2.6 OSE SIGNALS .........................................................................................................................9

2.6.1 Signal files in OSE ..........................................................................................................10

3 METHODS ..................................................................................................................................11

3.1 TIMER THREAD FOR TASK.....................................................................................................11 3.2 OS SIGNALING TO IMPLEMENT TIMER FUNCTION IN TIMERTHREAD......................................13 3.3 COMMUNICATION BETWEEN PROCESSES...............................................................................13 3.4 FOUR CASES OF ROUTING IN THE OSE DISPATCHER ..............................................................15 3.5 TEST APPLICATION – GPEH AND CLIENT-SERVER APPLICATION..........................................16 3.6 TEST SPECIFICATION FOR CLIENT-SERVER TESTS .................................................................17 3.7 A SUMMARY OF WHAT NEEDS TO BE IMPLEMENTED AND SOLVED.........................................19

4 DESIGN SOLUTIONS ...............................................................................................................20

4.1 THE TIMERTHREAD SOLUTION .............................................................................................20 4.2 THE OSE SIGNALING SOLUTION............................................................................................21

5 RESULTS.....................................................................................................................................22

5.1 ERROR DISCOVERED IN PATHMATE ....................................................................................22 5.2 DEPENDENCY ON C++ STANDARD LIBRARY .........................................................................23 5.3 NAME CONFLICTS .................................................................................................................24

5.3.1 Name conflicts with signal numbers................................................................................24 5.3.2 Other name conflicts .......................................................................................................25

5.4 PATHMATE’S TEMPLATE LANGUAGE ..................................................................................25 5.4.1 Impact of weaknesses in template support ......................................................................26 5.4.2 Weakness of new marking for OSE signaling .................................................................27

5.5 PATHMATE ACTION LANGUAGE (PAL) ..............................................................................27 5.6 KNOWN LIMITATIONS IN THE OSEDISPATCHER....................................................................28 5.7 PATHMATE MODEL OF THE GPEH APPLICATION.................................................................29 5.8 DIFFERENCES BETWEEN THE MODEL AND THE GENERATED CODE.........................................30 5.9 RESULT OF THE CLIENT-SERVER TEST ..................................................................................30 5.10 A SUMMARY OF PROBLEMS ENCOUNTERED IN THE PROJECT .................................................32 5.11 A SUMMARY OF THE RESULTS ...............................................................................................33 5.12 NEW MARKINGS INTRODUCED IN THIS THESIS.......................................................................34

6 DISCUSSION ..............................................................................................................................36

6.1 TEMPLATES ..........................................................................................................................36 6.2 RECOMMENDED CHANGES IN PATHMATE ...........................................................................36

6.2.1 Inheritance of the template type UserDefinedType .........................................................37 6.3 COMPILING PATHMATE’S RUNTIME LIBRARY .....................................................................37 6.4 COMMENTS ON THE CLIENT-SERVER TEST ...........................................................................38 6.5 RISK OF BECOMING DEPENDENT ON PATHMATE .................................................................40

7 CONCLUSIONS..........................................................................................................................41

7.1 LEGACY PROBLEMS AND OSE SIGNALING SOLUTIONS ..........................................................41 7.2 BENEFITS AND DISADVANTAGES OF PATHMATE.................................................................41

8 FUTURE WORK ........................................................................................................................43

8.1 PROBLEMS IN YEAR 2038......................................................................................................43 8.2 NEW TOOLS FOR DEVELOPING TEMPLATES ...........................................................................43 8.3 XTUML FOR CRITICAL SYSTEMS...........................................................................................43 8.4 XMI BRIDGE ........................................................................................................................43 8.5 HYBRID PATHMATE – ROSE RT TOOL ................................................................................44 8.6 IMPROVEMENTS TO PATHMATE ..........................................................................................44

8.6.1 Validate correctness between model and generated code...............................................44 8.6.2 New way of handling deferred events .............................................................................45

9 REFERENCES ............................................................................................................................46

APPENDIX A: WAY OF WORKING WITH PATHMATE............................................................47

APPENDIX B: TEST APPLICATIONS AND GUI IN PATHMATE .............................................50

B1 THE GPEH APPLICATION...........................................................................................................50 B2 THE CLIENT-SERVER APPLICATION ...........................................................................................54

Reading guidelines

The thesis was performed at a large telecom company that will be referred to as “large

telecom company”.

This report assumes that the reader has some experience from programming and a

basic understanding of UML. The report contains quite a lot of modifications of

PathMATE in order to prove its potential with the large telecom company’s systems.

The reader who only wants an overview of xtUML and the tool PathMATE, focus on

sections 2.1 through 2.3 and Appendix A. Figure 1 is essential and worth studying in

order to understand what PathMATE is and how it works.

All PathMATE applications shown in this thesis are developed with PathMATE

version 7.0.0 and installed as a plug in to IBM Rational System Developer

version 7.0. Modifications of PathMATE are made for the operative system OSE

(developed by ENEA) and run on a platform that will be referred to as “generic

platform” throughout this report.

Code specific elements will be marked with the font Courier.

Abbreviations

AL – Action Language

ASCII – American Standard Code for Information Interchange

GPEH – General Performance Event Handler (application at the large telecom

company)

GUI – Graphical User Interface

IDE – Integrated Development Environment

MBT – Model Based Testing

MDA – Model Driven Architecture

OMG – Object Management Group

OS – Operative System

OSE – Operative system developed by ENEA

PAL – PathMATE Action Language

PIM – Platform Independent Model

PSM – Platform Specific Model

Rose RT – IBM Rational Rose Real-Time

UML – Unified Model Language

xtUML – Executable Unified Model Language

Definitions

Action Language – A language to describe behavior in a model. Action language is

today tool specific since no standard exists. The action language in PathMATE is

abbreviated PAL. Work is in progress by OMG to make an AL standard for xtUML.

Analyzed <code/domain> – Analyzed code or domain has been used in this report to

express parts of the system that is fully modeled and created with PathMATE.

Antonym to realized.

Markings – Platform specific data used by the model compiler to choose a wanted

path during the generation of code from the PIM. Some markings do not affect the

generated code but appear as compile flags.

Platform Independent Model – A UML model, often complemented with action

language, to describe the structure and behavior of the system without any platform

details.

Platform Specific Model – A PIM with markings that describes constrains in the

target system.

Realized <code/domain> – Realized code or domain has been used in this report to

express external code that is not developed in PathMATE but included in the

executable system and for reference purpose in the PIM. This is represented by the

box “Non modeled elements” in Figure 1. Antonym to analyzed.

Target Language – The language that is generated from the PIM, for example Java,

C++ etc.

Templates – Files that are used by the transformation engine. These files contain

what will be written to the source code files. The structure and choices made when

running templates could be seen as the grammar for the target language. Templates

are written in a PathMATE specific language that are similar to the Action Language

but should not be confused with each other.

Transformation engine – A PathMATE functionality to read in information from

both PIMs, markings and templates in order to generate code.

1

1 Introduction This thesis is divided into four parts:

Phase 1. Make PathMATE generated applications run in a simulated environment

where OSE and a generic platform is used.

Phase 2. Implement a new way of handling time dependent events in PathMATE.

Phase 3. Add functionality through templates that will make it possible for

PathMATE generated applications to send and receive OSE signals.

Phase 4. Test the above by producing test applications and compare the result to

equivalent applications developed in Rose RT.

Through completing the above, a general knowledge about xtUML will be achieved

and PathMATE’s strengths and weaknesses will be shown. The outcome of this

project will show the large telecom company how PathMATE can be used together

with the large telecom company’s existing applications. It will also prove a technical

solution that can be used in future software development at the large telecom

company.

1.1 Background

Model-based tools have been highly important for software companies in order to

keep up with fast developing markets. These tools have been a foundation for

effective communication and production within companies. A great example of this is

a success story told by Graham Bath at a congress held by the large telecom company.

Graham works at T-systems and had recently been part of introducing Model Based

Testing (MBT) into the organization. By doing this they overcame the language

barrier with their off shore unit in India that they had been struggling with for a while.

The result was monetary savings in the production by 30 %.

The figures were later questioned during the session whether these great savings were

due to the effectiveness of MBT or lower salary cost in India. Graham had to admit

that the salary had probably made a big impact on the result. Still this story proves

that savings and efficiency are achievable through model based techniques whether it

is due to effective work methods or better communication.

Stories like these plus companies’ own experiences of working with models have

made the industry come up with new, more effective techniques for MDA. A lot of

effort is put into research and evaluation of different MDA products. Which ones have

something new to contribute with? How big will the impact be on a company’s

current way of working? This report could be seen as part of the process to find

answers to these questions at a large telecom company.

This report will focus on one product in the xtUML category developed by Pathfinder

and called PathMATE. The first release of PathMATE was in 1996 but was certainly

2

not an xtUML tool at that time. It had a transformation engine that could generate

C++ code, Microsoft Word documents and debug models. PathMATE started to take

the shape of an xtUML tool in 2000 when templates for generation of Java code were

added and one year later also templates for C. The base for the current version was

released in 2005 with integration to popular modeling tools and support for UML 2.0.

A previous report by Henriksson and Sabir (2007) has shown that PathMATE is a

candidate for being part of future software development at the large telecom company.

This report is focused on a direct interaction between Rose RT and PathMATE where

a hybrid model of the two was created and compiled together. The result proved a

possible technique for coexistence between Rose RT and PathMATE applications on

Win32 platforms.

This report will focus on PathMATE in OSE, first in a stand alone environment and

then evaluate possible interaction with other OS processes though the OSE kernel

using signaling.

For the large telecom company it is essential to achieve a mixed environment between

PathMATE and other applications if PathMATE should be part of future software

development. In Henriksson and Sabir (2007) there is an estimate that it will take

about one hundred work years to re-design the large telecom company’s old

applications in PathMATE. This is an unreasonable effort and an introduction of

PathMATE must be established in another way.

1.2 Presentation of the problem

Earlier work at the large telecom company has indicated errors in PathMATE’s timer

function when running applications on a generic platform used by the large telecom

company. It is essential that these errors are discovered and corrected if PathMATE

should be used at the large telecom company. Any corrections in the timer function

needs to result in efficient code since it will be used in the large telecom company’s

real-time products.

In Henriksson and Sabir (2007), full integration with older applications developed in

Rose RT could not be achieved on all platforms within the project’s time scope. The

strategy in this project was built on a hybrid build concept where code was generated

from both Rose RT and PathMATE and compiled together. A new strategy that hasn’t

been tested exists. This strategy considers PathMATE in a green field area and with

possible interacting with the existing system through an OSE signaling concept at

model and code level.

Rose RT is currently in use at the large telecom company. PathMATE will therefore

have to compete with Rose RT to be part of the large telecom company’s future. It is

for that reason important to investigate how much work needs to be done to introduce

PathMATE and if it is favorable to introduce PathMATE compared to keeping the

existing version of Rose RT.

3

1.3 Goals

The goal of this thesis is to:

• Demonstrate a possible mixed design environment where different stand alone

applications in the system can coexist and interact, whether they are developed

in PathMATE or Rose RT.

• Analyze and compare generated applications from PathMATE versus

applications generated from Rose RT.

1.4 Deliverables

1. A working PathMATE port for real time applications on a generic platform

used by the large telecom company. This port will have a modified runtime

library and transformation templates.

2. A functional OSE load module, achieved through new templates that can be

used for code generation. The code will also be able to interact with other OS

processes through OSE signaling.

3. Deliver a technical report that will support business decisions regarding

PathMATE’s role at the large telecom company.

4. Design and create solutions to prove or disprove PathMATE’s ability to

generate code for the large telecom company’s generic platform.

1.5 Systems and programs used throughout this project

Desktop computer (HP workstation xw6200)

- Intel(R) Xeon 3.20GHz

- 2 GB RAM

- Microsoft Windows 2000 sp4

- PathMATE version 7.0.0

- IBM Rational System Developer version 7.0

- Citrix (meta frame to UNIX)

- SoftOSE version 2.2.2 (simulated OSE environment)

- Microsoft Visual C version 6.0

- Existing applications and source code on the large telecom company

4

2 Theory This chapter will highlight important techniques and existing behavior in PathMATE

that are essential to understand in the methods in chapter 3.

2.1 The basic idea behind PathMATE

Here follows an overview of how to work with PathMATE in order to achieve the

advantages mentioned in chapter 1. Please refer to Figure 1 for a clear view of the

workflow in PathMATE. For details in the different steps, please refer to Appenix A.

The first step is to build an UML model of your solution with the requirements as

base. This step will likely require most work and includes designing domains, classes,

state machines and any AL that is needed. In order to make this model into a PIM it is

important to focus on “what” needs to be done by the system not “how” it is done on a

code level. To make your model more reusable for the future it is recommended that

larger systems are divided up into domains.

The second step is to mark your PIM with platform specific requirements such as

which operative system the application will run on and what language your PIM

should be translated into.

After these steps, code can be generated with the Transformation Engine. Existing

translation maps can be used most of the time but it is also possible to create your own

templates or modify the existing ones. By transforming your model, it will also be

tested for any inconsistency or structural errors.

The outcome from the Transformation Engine is a PSM containing code and

compiling instructions that are ready to be complied with PathMATE’s run-time

mechanisms. If the model contains realized domains, the code for these can be added

just before compiling to an executable system.

Finally, Spotlight is a debugging tool that can be used to step though the execution or

to simulate input to the system. Once debugging is completed, the marking for

Spotlight can be removed and an executable system without Spotlight can be

generated.

5

Figure 1 Description of the workflow when using PathMATE. The figure is inspired of Figure 1 in

Doby (2005).

2.2 Document handling in PathMATE

PathMATE contains support for document generation. This means that it is very easy

to keep documentation up to date throughout the lifecycle of the software. Whenever

a new version is generated, a new documentation can be generated. The

documentation contains, for example, class diagrams on the domain and system level,

all operations and attributes for a class and dependency between classes and domains.

2.3 PathMATE’s runtime library and other parts

To understand the underlying structure and mechanisms of PathMATE there are some

important folders to be aware of. There are two folders with constant code and one

folder with system code generated from the PIM plus one folder for each domain in

the system.

Application

specific

requirements

Platform

specific

requirements

Platform

Independent

Model (PIM)

Marked

PIM

PathMATE Transformation maps

Code

templates

Run time

mechanisms

PathMATE

Transformatin

engine Non

modeled

elements

Build Platform

Specific Model

(PSM)

UML editor

customized for

MDA modeling

PathMATE

Spotlight

EXECUTABLE SYSTEM

6

Figure 2 General appearance of folder structure from PathMATE generated project.

If the user hasn’t specified anything else, PathMATE will create subfolders named

after each domain under the project folder. These folders contain the code for each

domain’s properties and any classes in that domain. Note that these files contain the

source code in a specified target language but are not yet compiled.

PathMATE has a static folder called mechanisms. This folder contains the same

source code all the time and sets the framework for how to handle messages and

interaction within the system. This code is never generated from the PIM but included

at compilation.

System is the other folder with constant source code and contains basic set up

information of the system. For example, the PathMATE types are defined here and the

folder also contains the main file that is responsible for starting up the system by

calling functions in system.hpp which is generated from the PIM and can be found

in the sys folder.

The sys folder contains source code generated from the information obtained from the

PIM and the markings the user has made. This code sets up processes and has a close

interaction with both the constant source code and the source code generated from the

PIM.

In addition to these folders, PathMATE will also generate compiling instructions for

the system. These instructions will have different appearance depending on what

target system has been selected and which compile flags the user wish to apply.

This thesis has made changes in the constant code in the folder mechanisms in order

to improve PathMATE. During normal use of PathMATE the constant code should

not be modified and only controlled with compile flags. The compile flags can be

expressed in markings for automatic generation to build files. For example defining

the constant PATH_NO_WIN32 with markings will include this compile flag and

specific blocks for Win32 systems will be avoided in the constant code. Compile flags

mechanisms: Constant code

for PathMATE’s runtime

library.

system: Constant code to

define system types and

variables.

sys: Generated code that will

set up the system in a proper

way for the specific application

that has been generated.

“Various names”: Generated

folders with code for each

domain and other user

specified properties.

7

do not only control which platform the program is run on but could also be used for

different optimizations such as memory handling.

2.4 Task in PathMATE (ver. 7.0.0)

For this thesis has the class Task been essential. This class can be seen as a separate

thread of execution that is mapped to an OS thread. During runtime it handles events

that are used for signaling between different tasks and instances. These events can be

of different subclasses depending on whether the event is to be handled straight away

or if it is supposed to go dormant for a specified time.

To handle these events there are 3 different queues; “incidentQueue”,

“delayedEvents” and “periodicServices”. There are also 2 queues for incoming

events, called “intertaskQueue” and “intertaskDelayedQueue”, where other classes

can post events. From a simplified point of view, the purpose of these two inter task

queues is to function as mailboxes for the task and then sort incoming events to the

appropriate queue. The incoming events are double check if they have a time

dependency regardless of what queue they are posted on. A delayedEvent posted on

the intertaskQueue can therefore be placed in the delayedEvents’ queue even if it

should have been received on the intertaskDelayedQueue. If the events have a delay,

they will become PfdDelayedEvents and sorted by execution time. An event

without a delay on the “intertaskQueue” is simply posted on the “incidentQueue”.

There is another queue called deferredEvents in Task. Deferred events are used if an

event is received in a state that doesn’t receive that type of event. If the user has

specified that the event can be deferred, it will be put on the deferred queue and

released in the appropriate state. Otherwise the system will stop with a “CANT

HAPPEN ERROR” message and will most likely not recover unless the user has

specified that the event can be ignored for the current state. The queue has been used

through a test application in this project but is otherwise not important in this project.

For further explanation of why deferred events are used and the event handling in

state machines, please refer to Table 1 in this section.

This thesis will not involve periodic services and will therefore not be dealt with in

depth. The general characteristics of a periodic service are similar to a

PfdDelayedEvent that will put itself on the queue right after it is handled but with

a new execution time one period later.

8

State Transition Table for Class Session state MaxCapacity ResetTimer StartSession

CheckIfClientOverload TooManyClients waiting IGNORED

Created CANT_HAPPEN CANT_HAPPEN CheckIfClientOverload TimeOut CANT_HAPPEN CANT_HAPPEN CANT_HAPPEN

TooManyClients CANT_HAPPEN CANT_HAPPEN CheckIfClientOverload

handleRequest CANT_HAPPEN waiting CANT_HAPPEN

waiting CANT_HAPPEN CANT_HAPPEN IGNORED

state TimeOut closeSession handleCall CheckIfClientOverload CANT_HAPPEN CANT_HAPPEN DEFERRED

Created CANT_HAPPEN CANT_HAPPEN DEFERRED

TimeOut CANT_HAPPEN CANT_HAPPEN CANT_HAPPEN

TooManyClients CANT_HAPPEN CANT_HAPPEN DEFERRED

handleRequest CANT_HAPPEN CANT_HAPPEN CANT_HAPPEN

waiting TimeOut TimeOut handleRequest

Table 1. The table is generated from the Client-Server application that is used as a test application later

in this thesis. It describes the state machine in the Session class and the names in bold represents the

states while the italic names are the signals that are used in the state machine. One can in the table see

the importance of deferring or ignoring events that otherwise would cause a “CANT HAPPEN

ERROR”.

2.5 Templates in PathMATE

Templates are the underlying code that is used in the Transformation Engine. The

template files in PathMATE have the extension “.arc” and their own template

language. This code is built up of commands that are guarded within []-brackets. All

code outside []-brackets will be printed either to a file or the GUI console during

transformation.

In PathMATE ver. 7.0.0 there are about 460 template files that are used for generation

of C++ code plus about 180 common template files not specific to C++. All these files

may or may not be called depending on which path the transformation engine chooses

and the path chosen depends on the PIM and the markings put on the same. The only

thing that can be guaranteed is that the transformation engine starts by calling the

template file that has been specified in the transformation map. In most transformation

maps this is sys_top.arc for generation of source code and build_top.arc

for generation of build support. These two files will therefore be the entrance for new

customized templates to be called.

The template language in PathMATE is quite simple with syntax such as

[ASSIGN variable name = value]

[IF (condition)] [ENDIF]

[FOREACH variable name IN list] [ENDFOREACH].

9

2.6 OSE signals

The following knowledge is obtained through the manual Enea OSE Systems AB, OSE

ver. 4.3 Documentation Volume 1 – Kernel.

The target system will run an OSE Kernel and signaling between processes will play a

major roll in this project.

OSE keeps track of processes by assigning each process a unique process number.

This number is assigned at creation of a new process and is the key to call the process

later on in the program.

Calls between processes are made with a mailbox like system where processes can go

dormant for a specified or unspecified duration while waiting for incoming signals.

The signals can be sent from any process in the system as long as it is active and has

access to the process number assigned to the receiving process.

New signals can be created as long as they follow a specified pattern with a signal

number and a struct. It is possible to include references or pointers in the struct and

these will be carried inside the signal to the receiver. This has however not been used

in this project since one can not guarantee that an object and all of its references are

allocated in a memory that the receiving process has access to. Instead only primitive

data types will be sent within signals. Hence, will possible system crashes due to

unreachable memory be avoided.

To create a new process, the programmer will first have to create an OS macro. This

macro can simply be seen as a global function that is given as an input when creating

a new process. The system will then run whatever code is specified in the macro once

the new process is created and started.

10

2.6.1 Signal files in OSE

Each signal has its own signal number define in an int or SIGSELECT which is the

type defined name in OSE. This number is used by the receiver to comprehend which

action to take and what structs are available. For example:

#define MY_SIGNAL_WITH_STRUCT 1234 #define MY_EMPTY_SIGNAL 5678

struct SigWithStruct{ SIGSELECT sigNo; int someNumber; struct PreviousDefinedStruct prevDefStruct; };

struct EmptyStruct{ SIGSELECT sigNo; };

union SIGNAL{ SIGSELECT sigNo; SigWithStruct sigWithStruct; };

This is the general appearance in the signal files that are used in this project. These

signals will then typically be used in the following way:

SIGNAL* toSend; toSend = alloc(sizeof(EmptyStruct), MY_EMPTY_SIGNAL); toSend->sigNo = MY_EMPTY_SIGNAL; send(&toSend,process ID of receiving process); rec_signal = receive(&anySig); // blocking until received switch (rec_signal->sigNo){ case MY_EMPTY_SIGNAL : ...

11

3 Methods The following chapter describes a number of software implementations. All of these

are made in C++ and with PathMATE’s runtime library as reference. The purpose is

to make PathMATE compatible with OSE and to make PathMATE applications

communicate through signaling in OSE.

3.1 Timer thread for Task.

The standard PathMATE version 7.0.0 doesn’t work with OSE. The system compiles

but crashes at execution and a real time problem is suspected in the class Task in

PathMATE’s runtime library. This project’s first assignment will therefore be to

modify Task to make it run with OSE. Earlier work by Henriksson and Sabir (2007)

mostly took place in a Windows environment and problems with OSE could therefore

be avoided. But in order for the large telecom company to undertake PathMATE as a

developing tool, it is necessary that generated projects will work with OSE.

To solve this issue and identify the problem a more of a “single responsibility

concept”, as discussed in Martin (2003), will be applied for Task. This will make it

less complex and hopefully reveal the timer issue. The class Task is described in

chapter 2 and the chapter defines that Task contains 6 different queues to keep track

of 3 different classes of events.

To reduce the complexity in the class, Task’s responsibility will be divided and a

support class TimerThread will be introduced. The goal with TimerThread is to

ease Task’s responsibility by sending all incoming events that have a time

dependency for its execution to TimerThread. With this approach 2 out of 6

queues are now outside Task. PeriodicServices will still remain inside Task.

12

Figure 3 Visualization of event queues in the PathMATE class Task, standard version to the left and a

modified version to the right.

PathMATE applications keep on crashing when using time dependent events in OSE.

Because of this, the project will not implement TimerThread by using

PathMATE’s own semaphores and time functions. Instead, signals in OSE will be

used to hopefully avoid a possible error source.

The method to be implemented is simply that the TimerThread will have its own

process that can be blocked until a signal arrives and register a PfdDelayedEvent.

If a PfdDelayedEvent is registered, the TimerThread will be blocked until the

delayed event either expires or a new signal is received and another delayed event is

registered.

This solution is to be implemented as regular, non generated, code and work together

with the code in the mechanisms folder, described in section 2.3. The implemented

code then has to be guarded by compile flags so it won’t be included unless OSE is

the target OS.

Task C

Task B

Task A

B C D

F

E

TimerThread

G

Regular event handling in

PathMATE

Task C

Task B

Task A

B C D

F

E

New implementation where the TimerThread will handle all

delayed events

A A

A – Deferred Events, B – Incident Events, C – Intertask Events, D – Periodic Events, E – Delayed

Events, F – Intertask Delayed Events, G – New queue for all delayed events

13

To summarize the benefits of this design:

1. The application will be more optimized since only TimerThread will ask

for the system time and use it for handling of all delayed events. This means

that if a delayed event is removed it will not affect the dormant timer function

unless it was the next to execute in the whole application.

2. The timer functionality is concentrated to one class with the following

benefits:

a. It will be easier to discover any error with fewer queues and hopefully

can the error that causes the system to fail in an OSE environment be

discovered.

b. Possible optimization of the way delayedEvents are queued will

be easier. In PathMATE, the events are queued in a sorted list. This is

not optimal for quick insertion of new delayedEvents and the new

design allows an easy exchange to another sorted structure.

3.2 OS signaling to implement timer function in TimerThread

Some code has been made into comments and left in PathMATE’s source code during

the development by Pathfinder. Comments in the file pfd_os.cpp in PathMATE’s

runtime library show an aborted attempt to make a functional timer function in OSE.

The commented code could also be results of further development of PathMATE

where OSE is no longer supported. This attempt or previous functionality is built up

on signaling between processes in OSE.

In order to make TimerThread time aware, it will have its own semaphore

functions that use OSE signaling. With the fact that one of PathMATE’s strength is

platform independency, these semaphore functions have to be valid only when ran

with the OSE kernel. If the system is run with other operative systems

TimerThread will use the standard PathMATE semaphore.

A blocking semaphore call, with an explicitly specified delay, can be made with the

signals created for TimerThread. OSE doesn’t have an explicit function for this

purpose but due to the possibility to wait for a signal during a specified time can this

semaphore function be implemented.

3.3 Communication between processes

In order to make applications generated from PathMATE compatible with

applications generated from other tools this thesis will combine the flexibility of

templates and the strength of OS signaling in OSE.

This thesis will send OS signals in an OSE environment between applications. In

order to enable this functionality for PathMATE applications, code needs to be added

into every single PathMATE application that will support the functionality. By

14

writing this code in templates, the functionality will be automatically included when

the code is generated from the PIM.

The code that needs to be added will in it most basic form look like the code shown in

section 2.6.1.

Figure 4 Schematic draft of the basic functionality to be implemented in order to make PathMATE

processes communicate with other processes.

There is a major drawback to this method. It is quite possible that objects defined in

one process needs to be sent to another process where the object is not defined. The

receiving process will have no idea how to handle this foreign object, or on the other

side the sender might not know how to create an object that the receiver needs as

input.

To overcome this obstacle, this thesis will assume that all signals that will be sent or

received have a corresponding modeled class representation in the sending or

receiving domain. It will not be considered how these representations are created.

During the developing phase in this project all signals have to be modeled by hand in

PathMATE.

The effect of, in some sense, making these signal definitions public to other processes

is that the signal has to be represented or redefined multiple times.

1. A modeled class definition is needed in all PathMATE applications that use

the signal (as stated above).

2. Each signal needs to be connected to a domain service, class service or

instance. This is necessary if the OSE dispatcher should have a fair chance of

routing the signal to the right receiver.

3. Finally an OSE definition is needed where the struct and signal number are

stated (a signal file with code like the definition in section 2.6.1).

PROCESS B

PROCESS A

PathMATE generated application

OSE

dispatcher

(template generated)

Existing application

with functions for OSE

signals.

(For example Rose RT)

15

Point two will be connected through markings that will cause the new templates to

include signal representation where it is needed. The markings will also allow the

dispatcher to know which signal object needs to be created from the incoming signal.

In order to make objects visible from one application to another, it is necessary for a

model of each signal used in the system. This allows object representations from other

applications to be compiled with the new application and communication will be

possible through signaling in OSE.

Point 3 regarding the struct definition will most likely already be in the system or at

least parts of the definition that easily can be expanded with new signals. This project

will also add templates for generation of new signal files or extension of existing

signal files. If the existing signal files contains a definition of union SIGNAL, this

definition has to be removed in order to avoid multiple definitions of SIGNAL.

3.4 Four cases of routing in the OSE dispatcher

Incoming signals are most likely to be handled somehow. There are a few different

cases to consider.

1. Signals calling domain interfaces

2. Signals calling static class operations

3. Signals calling instance based class operations

4. Signals effecting state machines

The first two cases are both static calls and can be handled through markings. In this

case will the user map the operation to a signal number with the new marking

“OSESignalName”. In this way, code can be generated through templates to call the

right function.

The other two cases are a bit more difficult since there will be no information about

instances when the code is generated. This will be solved through a subscribe function

in the OSE dispatcher. If an instance wants to receive a certain signal, it will first have

to subscribe itself to that signal through the OSE dispatcher. In this way will an

instance be able to listen to as many signals as it has registered itself to. If multiple

instances try to subscribe on the same signal will only the newest registered instance

receive the signal. If an instance wants to stop receiving certain signals it has to

unregister itself.

Support for multiple subscribing instances to the same signal could be achieved by

slightly changing the way subscriptions are handled and stored. This have however

not been implemented in this project. One could question the importance and use of

having an instance based support for receiving signals in the first place.

After all, this project will with the OSE dispatcher allow a new feature (instances

receiving signals) that is not currently possible at the large telecom company that uses

Rose RT. Multiple instances subscribing to the same signal are therefore not

important today. However if the need should appear in the future, it is possible to use

the same method to implement this support.

16

Figure 5 The receiving part of the OSE dispatcher.

3.5 Test application – GPEH and Client-Server application

A test application needs to be developed with PathMATE and run with the large

telecom company’s software to prove that PathMATE could be used at the company.

An ideal candidate for a test application could for example be an existing application

that interacts with several different parts of the large telecom company’s system. The

test would be even more interesting if the existing application would have been

developed in Rose RT. In this case an interesting evaluation could be made between

Rose RT and PathMATE generated code.

A suitable application that had the character of a router was found but during the

primary study of this application it turned out that it would probably not be possible to

re-model this application within the time frame of this project. This, and most other

existing applications, were simply to large and complex to quickly be re-modeled in

PathMATE.

Instead the General Performance Event Handler (GPEH) application was chosen. This

application supervises a part of the system’s performance and makes periodical logs

that are saved to the hard drive. The GPEH could, according to system expertise on

the large telecom company, be the only application that interacts with the system and

at the same time fits within this project’s time frame. Unfortunately this application is

hand coded in C and an evaluation with Rose RT is not possible. Note that this thesis

has no ambition of improving the GPEH application. Modeling the GPEH application

in PathMATE will most likely result in more and less effective code but show that the

communication problem connected to introducing PathMATE can be overcome.

Since the GPEH application is not developed in Rose RT, an application needs to be

developed in both PathMATE and Rose RT to study differences between the two.

OSE signal

PathMATE Application

Markings

(properties.txt)

Creating class

representation

of the signal

Where to

send the

created class?

Table or

similar with

subscribing

instances

Domain service

Static object

service

Instance based

service

(subscribing)

State machine

(subscribing)

OSE dispatcher

OSE Kernel

17

This application will be separated from the large telecom company’s system. A

suitable task for this purpose is a simple Client-Server process where many clients can

connect to one server. This application will allow a study on how the different code

from the two tools will perform under various conditions.

This thesis’ solution to make PathMATE compatible with the large telecom company

will be tested in aspects of interaction with the surrounding system through the GPEH

application and in aspects of performance difference between Rose RT and

PathMATE through the Client-Server application.

3.6 Test specification for Client-Server tests

This section describes the tests that are performed on the Client-Server application.

The tests evaluate execution time for different cases.

Since disturbing processes might be present while testing will each test be conducted

5 times and the lowest time will be taken as the result. The result might not be

completely accurate but will provide an approximate value of the execution time in

different situations. The lowest time will be equivalent with the time when the test

process got most access to the system’s resources.

For easy reference to the results, the tests will also be given a test name that follows

the pattern T<test number> <number of clients>x<requests per client><how requests

have been made, blank = uninterrupted, i = session interruption between requests, q

= sessions can be queued due to limited server capacity>

General behavior in the test of Client-Server application:

1. The server and all the clients are created

2. The system time is registered

3. All clients start requesting

4. All clients have got response from all requests

5. The system time is registered

6. Time difference in milliseconds between 2 and 5 is printed to screen

Test 1 (T1 1000x1q):

• 1 server, 1000 clients, server capacity 50 simultaneous client sessions

• Each Client will do 1 request and close connection

Test 2 (T2 1000x5q):

• 1 server, 1000 clients, server capacity 50 simultaneous client sessions

• Each Client will do 5 continuous requests and close connection

Test 3: (T3 1000x5iq)

• 1 server, 1000 clients, server capacity 50 simultaneous client sessions

• Each client will do 5 requests by closing the connection after each request

18

Test 4-6 (T4 3000x1q) (T5 3000x5q) (T6 3000x5iq):

Same as 1-3 but with 3000 clients

Test 7 (T7 10x1000)

• 1 server, 10 clients, server capacity 10 simultaneous client sessions

• Each client will do 1000 request and close connection

Test 8 (T8 10x3000)

• 1 server, 10 clients, server capacity 10 simultaneous client sessions

• Each client will do 3000 request and close connection

Test 9 (T9 10x5000)

• 1 server, 10 clients, server capacity 10 simultaneous client sessions

• Each client will do 5000 request and close connection

Test 10 (T10 100x1000)

• 1 server, 100 clients, server capacity 100 simultaneous client sessions

• Each client will do 1000 request and close connection

Test 11 (T11 100x3000)

• 1 server, 100 clients, server capacity 100 simultaneous client sessions

• Each client will do 3000 request and close connection

Test 12 (T12 100x5000)

• 1 server, 100 clients, server capacity 100 simultaneous client sessions

• Each client will do 5000 request and close connection

Test 13 – Test 18 (T13 10x1000i) – (T18 100x5000i)

• Same as Test 7 – 12 but with session closing in between each request

Test 19 – Test 24 (T19 10x1000iq) – (T24 100x5000iq)

• Same as Test 13 – 18 but the server will only be able to handle half the amount

of created clients a time.

19

3.7 A summary of what needs to be implemented and solved

• Implement the class TimerThread which will use OSE signals to

implement timer functionality.

• Re-design the class Task to extract delayedEvents to TimerThread.

• Introduce markings and compile flags for TimerThread so that platform

independency can be preserved.

• Implement an OSE dispatcher for sending and receiving OSE signals in

PathMATE applications.

• Express the implementation of the OSE dispatcher in templates for automatic

generation of the code.

• Introduce new markings to trigger and control the new templates.

• Test the new OSE solution by modeling the existing GPEH application in

PathMATE.

• Compare Rose RT and PathMATE application performance through the

Client-Server application.

20

4 Design solutions This chapter will reveal the design of important solutions that this project has treated.

The chapter will therefore focus on the new TimerThread class and the OSE

dispatcher. For an overview of the design for the GPEH application, see Appendix B.

4.1 The TimerThread solution

The purpose of TimerThread is to create one class that can handle all time trigged

events. By doing this each Task instance doesn’t have to ask for the system time.

Instead of having an unknown number of Tasks asking for the system time, only the

TimerThread will ask for the time. DelayedEvents are sorted with pointers

according to their execution time in TimerThread. This new solution will only ask

for the system time if an incoming DelayedEvent has shorter delay than any

queued DelayedEvents. Depending on the application, this can make a difference

in performance if many DelayedEvents with shorter delay than the previous

queued will be added after one and other. Note that the system time is still called for

when a DelayedEvent is created but the TimerThread will most likely reduce

the calls for sorting the DelayedEvents.

This solution works with a TimerID class. The class is just a wrapper class to store

which Event belongs to which Task. It simply contains a pointer to the Event and

the number of the Task in the TaskTable implemented in the original PathMATE

version 7.0.0. The TimerID class also has functions for easy access to the Event

pointer and the execution time.

The first prototype of the TimerThread solution works with a list, just as the

original solution in PathMATE version 7.0.0. It could be interesting to instead

implement a binary tree to optimize the sorting of TimerID objects. This will make

the registration of a new event go faster but at the same time some more effort is

required to balance the tree. Especially since most nodes in the tree will be removed

from only one side when timers expire, only a few are estimated to be remove

randomly in the tree by the function removeEvent.

21

4.2 The OSE signaling solution

In order to make it easy to include the function for OSE signaling, an OSE domain has

been created. This domain can easily be included in any PathMATE system and will

be generated through templates even though it is set as realized in the PIM. The

domain contains 4 public services:

• huntForPID(String processName)

• registerForOSESignal(int signalNumber, void* objectToRegister)

• unRegisterForOSESignal(int signalNumber, void* objectToUnregister)

• getReceiver(int signalNumber)

huntForPID will use the public function hunt in OSE to try to find the process ID

who’s process name matches the input.

registerForOSESignal is used to register an instance to receive the input from

a certain signal. Note that the instance must be of the same type as the object marked

for this signal since it will be type cast when the specified signal arrives.

unRegisterForOSESignal is used to unregister an instance that have subscribed

to a signal.

getReceiver will return a reference to the instance that is currently subscribing to

the specified signal.

These four services are all that the user will see in the PIM1. The OSE domain

consists of two main classes, OSEDomain and Receiver. OSEDomain takes care

of all interaction from the model to the OSE kernel and will basically handle the four

services above and the Receiver dispatches all incoming signals.

The receiver is built as a separate process so it can be blocked while waiting for

signals. It is started when the main thread2 in PathMATE is initiated. The receiver

process is simply a loop beginning with a blocking call to receive signals. The receive

call is followed by a switch block to find the corresponding signal representation in

the model and after creation of the representation dispatch it to the appropriate

instance or function. In case an invalid signal is received, it will just be deleted

without actions.

So far has the receiving of a signal been considered, the same principal will be valid

for sending signals but there is no need for explicit interaction with the OSE

dispatcher. If an application wants to send a signal it can just create the class

representation of the signal and specify the receiving process as an attribute and call

sendAsOSESignal() which is modeled as an abstract function in the class

representation. This function will be included through markings and create the class

representation’s equivalent OSE signal and send it to the specified address. To make

sure that the receiving application can answer the signal if necessary, the OSE

function send_w_s() (short for send with sender) is used to specify the

ProcessID of the process that Receiver is running on.

1 The model will still technically be Platform Independent but since the user have chosen to use the

OSE domain; a platform specific choice has been made. 2 The main thread is the process that all dynamic objects in the model will run on.

22

5 Results

5.1 Error discovered in PathMATE

Initially nothing was working as it should with the new, modified runtime library in

PathMATE. This led to a major search to locate one or many errors. Finally it was

discovered that the system could return negative values for the system time. This led

the author to speculate about a possible conversion error in PathMATE.

It was found that newer versions of PathMATE described time in seconds and

nanoseconds in the class PfdFineGrainedTime. When a time difference was

requested from the class, using the howMuchLaterThanMe function, it returned the

time in milliseconds represented as an int. Within the called operation was an

instance of PfdFineGrainedTime converted into an int when the target system

was set to OSE. This int represented the time in nanoseconds.

A signed 32-bit int can contain values between -231

and 231

– 1. The conversion

error that was searched for had by this been found since only a little more then 2

seconds can be describe in an int with a resolution of nanoseconds. The value from

the conversion was simply too big to fit in an int and could therefore generate

negative times due to the overflow.

This error is probably a result of further development in PathMATE where the support

towards OSE has been dropped. A comment found in the source code indicates that

someone working with the development of PathMATE had thought about the problem

but left it as it was. The comment said “raise exception on overflow?”.

When implementing the OSE signaling, code that had been made into comments in

pfd_os.cpp was found and gave a clear indication that Pathfinder’s customers are

no longer using OSE.

The overflow problem in OSE was solved by modifying the code to work directly

with the attributes for time without the conversion. This way allows times up to a little

more then 2 000 000 seconds (2 000 000 000 milliseconds) to be described. The

author consider this as satisfying since only the duration between two points are to be

described in the system. These two points have reasonable less then 2 000 000

seconds difference between them.

23

Figure 6 The error found in PathMATE when using OSE visualized to the right, new solution to the

left. (PfdFineGrainedTime contains more attributes and functions than in the figure but the figure only

shows the corrupt parts.)

5.2 Dependency on C++ standard library

When the OSE dispatcher is handling signals that are to be mapped to an instance

based action, it is important that the information about that instance can be accessed

fast. The first attempt to achieve this was to use PathMATE’s defined types. The two

suitable classes are PathMATE’s list class and the map class in PathMATE. One of

the primary tasks of these two is to store references to instances, for example with an

association holding many instances.

The list class is not an appropriate option for storing references to instances in the

OSE dispatcher. This would slow down the system due to the search time in lists.

Instead was an attempt made using the map in PathMATE.

This attempt failed due to the generic platform used at the large telecom company,

which didn’t fully support the C++ standard library. PathMATEs map is built with

support from the standard map in C++ and therefore kept failing at compilation.

To overcome this problem a template generated hash table was implemented. Since

this hash table will only be used for finding instances that subscribe on signals and

only one instance can subscribe at the time, the maximum number of posts the table

has to handle is the total number of signals in the system. This means that the hash

table can have a fixed size and doesn’t have to support dynamic size since the table

won’t grow. This project has therefore let the size depend on which prime number is

nanoseconds instance 1

- nanoseconds instance 2

???

New implementation of

howMuchLaterThanMe in OSE

Old implementation of

howMuchLaterThanMe in OSE

seconds*109

(overflow)

∆seconds *103

∆milliseconds 1

+ ∆milliseconds 2

time difference ??? * 10

-3

milliseconds

seconds instance 1

- seconds instance 2

∆seconds

∆nano

seconds*10-3

nano sec. instance 1

- nano sec. instance 2

∆nano seconds

24

the closest to three times the number of enumerated values that are marked with the

OSESignal marking in the model.

The hash function is kept simple since an optimization wouldn’t contribute in a

decisive way. The function is simply expressed as:

int key = (value * 3) % (hash table size);

The hash table class is generated from templates. These templates contain a list of

prime numbers up to 7919. Tables with a size up to 7919 can therefore be created with

prime numbers. It is still possible that the table can be larger than 7919 but in that

case it is not guaranteed that the size will be equal to a prime number.

5.3 Name conflicts

During the project some name conflicts were encountered due to names used both in

realized domains and analyzed domains.

5.3.1 Name conflicts with signal numbers

The signal numbers in the system are defined outside the PIM. Still, there is a need to

access the signal numbers in the PIM in order to subscribe. A modeled element was

needed to be introduced. This element would carry different integer values so the type

enumeration was a given candidate.

Unfortunately, enumerations are of the template type UserEnumerate and can not be a

realized type. This means that the signal numbers will be declared with multiple

values, one from the external code and one from the enumerated value in the analyzed

model. This is an obvious name conflict that needs to be solved. For this reason were

two successful attempts made.

The first one was simply to change the name of the analyzed enumeration and add an

X in front of each signal name. The templates were thereafter changed to ignore the

first X in the name of the enumerated value and the signal name, as it was declared in

the realized code, was printed to the generated source file.

This solution could in some aspects be seen as misleading by a developer. There

would be two similar names in the system with only an X separating the two and also

an enumeration with different values declared where the values were never used, only

the name of the value. Therefore was this solution replaced by extending the marking

IncludeFile and adding the marking OSESignals. With these two customizations of

the templates would the enumerated values not be declared in the analyzed code but

PathMATE would have a modeled element with the same name as the signal number.

25

5.3.2 Other name conflicts

When working with both analyzed and realized domains it can be almost impossible

to dodge all name conflicts that can appear. The best solution is to follow good design

practice and have the domains as independent of each other as possible. If name

conflicts still appear, consider realizing the analyzed type that is in conflict or change

the realized code. If the name conflict has a large impact maybe something can be

done on a template level, see the previous section.

The existing GPEH application was modeled in PathMATE during this project to

prove that it is compatible with the large telecom company’s existing products. It was

difficult to give the analyzed model enough functionality without extending the

modeled application out of the time frame for this project. A close relationship

between the analyzed domain and the realized domain was therefore sometimes

present. For example, type definitions of the boolean type were declared the same in

both domains. It was then easiest to remove the definition in the realized code and

make sure the definition got included from the analyzed code.

5.4 PathMATE’s template language

During the development of new templates to support the new OSE signal dispatcher,

some weaknesses in PathMATE’s template language were revealed. The limitations

when handling the primitive type String had a large impact. The functions that can act

on a String in templates are basically assignment, a split function and a function to

make numbers captured in Strings into Integers (the function STRTOINT). The last

function will only work on Strings like “1234”, the template will cause a

transformation error if it for example encounters “a”. It could be desirable with a

function that can give the corresponding ASCII representation in the last case.

There is no character type on the template level. In the author’s point of view, no

character type is needed since a character can be described in a one letter String. It is

not really needed to optimize PathMATE and save memory with characters since

these Strings will only be present when the transformation engine is running to

generate code and not when the application is running. The only need for characters at

this point would be how a possible implementation of a function for ASCII code

handling would look like.

The functionalities that are highly recommended to add, according to the author’s

experience, are proper functions to divide Strings into substrings and a function to

modify upper and lower cases in Strings. There is functionality in PathMATE that

allows the programmer to divide Strings but this functionality assumes that the

programmer can divide the String by only one separation character, for instance “;”.

Since this might not always be the case it would be convenient with an indexed based

separator and also a separator that could separate on a sequence of characters. For

instance SPLIT(“firstHalfDIVIDE_HEREsecondHalf”,”DIVIDE_HERE”) =

“firstHalf” + “secondHalf”. If this is put in the current transformation engine the

outcome would be; “first” + “alf” + “second” + “alf” since the current version see

each character in the separator string as an individual separator (in this case split on

each one of D,I,V,E,_,H,R).

26

A possible way to achieve a functional String-type in templates is to glance at a

String-type solution that is popular amongst programmers. In this case could for

example Java’s String-type be a role model. Suitable functions to add on a template

level could for example be the equivalence to Java’s charAt(int index),

compareToIgnoreCase(String str), contains(CharSequence s),

endsWith(String suffix), indexOf(int ch) and so on. The Java String

contains a lot of functions that would be nice to have in PathMATE’s templates.

5.4.1 Impact of weaknesses in template support

It is mention above that functions to manipulate upper and lower cases are missing.

This has made a severe impact on the usability of the OSE dispatcher. To make a

smooth transition from OSE signals to models, and the reverse, it is assumed that a

struct in a signal is defined with capital letter compared to its variable name. This is

the most common and also the recommended case for signaling in OSE. For instance:

struct SomeSignal{ int sig_no;

SignalStruct signalStruct;

}; ↑ ↑ (Note upper and lower cases)

Since the Signal has a class representation in the PIM named signal, it is easy on a

template level to create the code to find the data for signals contained in the incoming

signal. But since no upper/lower case modification exists in the template language

there is no other choice than to put constrains on all PIMs that includes the new OSE

functionality. These PIMs have to define each struct name in a marking. The

information needed is already in the PIM, but can not be handled in templates and has

to be defined by the user by hand!

This might not look so bad at a first glimpse but in a system with hundreds of signals

it will have a severe and unnecessary impact, after all, the information is already in

the PIM.

PathMATE disregards if an association has dual or single direction. This means that it

is impossible, on a template level, to create a link and distinguish an associated class

from a non associated class.

As a result, the developer could possibly be fooled by his or her own model where

single directed association will come out as dual directed. Probably will the

applications still work and pass most test cases, but there is a possible security threat

when objects can be accessed against a singled way association.

This project has suffered from the problem with associations in a different way. The

new templates that have been developed during this thesis supports complex signals

that can contain multiple structs in a complex pattern. When an OS signal is received

the OSE dispatcher will know, through markings, which signal class to create in order

to represent the signal. The OSE dispatcher will start in the signal class and search its

27

way through all associated classes and their associated classes and so on. For

complex, entangled structures this will create circular loops if singled way

associations are regarded as dual. The result is an error when the developer tries to

transform his or her model.

Figure 7

Even if associations are directed, as in the figure, PathMATE doesn’t consider this and a circular loop

will be present if SignalClass is created in an automatic way.

To solve this problem the developer is asked to mark every end of an association in

the class signal structures. One could argue for some other solutions with inheritance

involved for signal representation. But keep in mind that this could involve multi

inheritance which is not supported in PathMATE due to that the model would then be

implementation sensitive, for example is not multiple inheritances allowed in Java.

5.4.2 Weakness of new marking for OSE signaling

As mentioned in the previous section, the associations for a class representing a signal

need to be marked. These markings become very important if the system shouldn’t be

stuck in a loop during transformation. If the system gets stuck, it will most likely not

respond for a long time. In best case it will finally throw an Invocation error from the

UML editor. This error will not tell any details about the problem and could be very

hard to locate if the user hasn’t encountered this before. For example was a whole day

spent during the customizations of the templates just to find a lower case character in

the markings that should have been an upper case for one association in the modeled

signal. It is therefore very important to be accurate when using the marking

endParticipantInRelationship.

5.5 PathMATE Action Language (PAL)

At present time of writing this report, work to introduce a standard for AL in xtUML

is taking place by OMG. This is an important step in the evolution of UML based

tools since some tool providers like BridgePoint and Pathfinder already have invented

their own AL. Some tools like Rose RT uses target language but a natural

development is that these tools will become platform independent and use AL. Even if

a study of AL isn’t the objective in this project the author has noticed following in

PAL.

28

PAL does not support [ELSEIF(condition)]. In one aspect this simplifies the language

with fewer commands. But the author’s experience, working in PAL, is that this will

sometimes create unnecessary, entangled control structure that is hard to follow. An

AL with [ELSEIF(condition)] is recommended by the author.

PAL does not support [SWITCH(variable)]. The author does not consider a support of

[SWITCH(variable)] necessary if [ELSEIF(condition)] is supported. It is better to

have an AL with fewer commands that is easy to learn. But the current PAL version

doesn’t support either [SWITCH(variable)] or [ELSEIF(condition)] which could be a

problem in some cases.

The question about how to express navigation to associated objects is interesting. This

is a new area since the developer at a modeling stage doesn’t know what type of

association he or she is dealing with. On a code level the programmer knows, for

example, that an association between two instances is connected through certain

pointers, references or container elements. PathMATE has solved the accessor issue

with the command FIND. For example FIND CLASS classname WHERE(condition).

This is a logic way to express accessors and it is quite easy to let go of the control

feeling of not having pointer, reference or container element to call.

5.6 Known limitations in the OSEDispatcher

It is common in OSE that one process supervises another process. This will allow

processes to recover if something happens to a process that they depend on. In OSE,

this is done by attaching a signal to a process. If something happens to that process,

the signal that has been attached will be returned to the supervising process.

Figure 8 The basic thought about attaching signals. Process A attaches a signal to B and gets the signal

back if something happens to B.

There is an OSE defined operation attach for this procedure. The call to attach

must be made from the supervising process that will receive the attached signal in the

event of something abnormal. There is no guarantee that the analyzed domain is

running on the same process as the OSEDispatcher. Therefore, the signal that is going

to be attached must first be sent as an encapsulated signal to the OSEDispatcher. The

signal can then be received and the signal to be attached can be extracted and attached

in a proper way.

This method is implemented in the new templates and used in the GPEH test

application which proves that it works. The GPEH application is however only

supervising one other process and in order to support multiple, simultaneous attach

calls it could be motivated to make a few changes. For example, add another marking

Atta

ch

A B A B

Atta

ch

A

Attach RIP

B

29

that specifies signals that can be attached. This marking could, together with a

template generated control structure in the OSEDispatcher, support more attach

signals. See the following code fragments from the OSEDispatcher’s main loop for

better understanding of the issue.

/* --- Generated code from customized tempates as of today (GPEH project) --- */ union SIGNAL* sig_pointer; case SIGNAL_TO_ATTACH : sig_pointer = alloc(sizeof(struct EmptyStruct), sig->signalToAttach.sigNo); attach(&sig_pointer, sig->signalToAttach.process); break;

/* --- Suggested way of supporting multiple attach --- */ union SIGNAL* sig_pointer; case SIGNAL_TO_ATTACH : switch(sig->signalToAttach.sigNo) case ATTACH_TO_PROC_A : sig_pointer = alloc(sizeof(struct EmptyStruct), sig->signalToAttach.sigNo); attach(&sig_pointer,sig->signalToAttach.process); break; case ATTACH_TO_PROC_B : ...

The same issue would also be valid for the procedure when ProcessIDs are hunted

for. This has however been avoided thanks to the use of the function hunt_from

where the receiving process can be set. Unfortunately, there is no equivalence to

hunt_from in the attach function.

5.7 PathMATE model of the GPEH application

As mentioned in section 3.5, the GPEH application is modeled in PathMATE to prove

that the solution with a template generated OSE dispatcher works. Even if this

application was one of the smallest candidates to model, it has still been a challenging

task to fit this into the project. The focus has therefore been on extracting the main

class and main functionalities in the application and reuse existing supporting

functionalities. The functionalities that have been used as realized code in the PIM are

mainly code for file handling and storing functionalities. All interaction with the

system is handled by the modeled part and modeling of the storage functionalities

won’t add anything to prove that the OSE dispatcher solution works.

The split into one analyzed domain and one realized domain from one unified

application has of course caused problems. Problems like close dependency between

domains, interaction problems between C code and generated C++ code, string

handling in C versus C++ and static C structures versus PathMATE dynamic

containers have all been common issues during the modeling of the GPEH. These

problems were more or less expected since a clean cut into realized and analyzed

domains are hard to accomplish from an existing application that is considered as one

30

closed unit. This was expected and only stresses how important domain separation is

and that the balance between functionality and making small independent units is an

art to master.

5.8 Differences between the model and the generated code

In section 5.4.1 a possible security threat was discovered when handling single

directed associations. Correctness between model and generated code has been

assumed and this project has not focused on investigating this further. By a coincident

it was however discovered that attributes set as protected in the model was generated

as public.

These two inconsistencies between model and generated code could indicate a

deceiving comfort on a model level in PathMATE.

5.9 Result of the Client-Server test

The Client-Server application was developed to compare PathMATE generated

applications and Rose RT generated applications. Due to disturbance from the

simulated version of the telecom company’s generic platform, the execution times in

OSE environment turned out to be unrealistic and unreliable. The elapsed time during

a test could, for example, be about 20 seconds while the system only reported a few

milliseconds.

The test was instead conducted in a Windows environment with the standard, out of

the box, templates with the following results. Please refer to section 3.6 for test

specification and references used in the tables.

Tool T1 1000x1q T2 1000x5q T4 3000x1q T5 3000x5q

PathMATE 93ms 1 063ms 875ms 9 828ms

Rose RT 47ms 109ms 140ms 328ms

T3 1000x5iq T6 3000x5 iq

RoseRT 219ms 656ms

Table 2 The result of test T1-T6 of the Client-Server application. For the PathMATE application, it

wasn’t any significant difference if the session was closed in between request or not. Therefore, only

the result for the uninterrupted cases displayed. These results have been visualized in Figure 9.

The results, presented in Table 2, were surprising. The PathMATE version had the

worst execution times in all test cases. The last result, T6 has such a large time

difference that it indicates that something must be seriously wrong. A new PathMATE

version was therefore implemented. The changes made in the new design will be

discussed in section 6.4. The result from this new version can be seen in Table 3 and

Figure 9.

31

Test Execution time in ms per tool

PathMATE Rose RT

T1 1000x1q 32 47

T2 1000x5q 62 109

T3 1000x5iq 125 219

T4 3000x1q 218 140

T5 3000x5q 312 328

T6 3000x5iq 485 656

T7 10x1000 47 140

T8 10x3000 156 437

T9 10x5000 281 734

T10 100x1000 1 031 1 500

T11 100x3000 3 094 4 515

T12 100x5000 5 188 7 485

T13 10x1000i 93 421

T14 10x3000i 297 1 281

T15 10x5000i 500 2 125

T16 100x1000i 2 359 4 157

T17 100x3000i 7 000 12 516

T18 100x5000i 11 734 20 875

T19 10x1000iq 94 421

T20 10x3000iq 312 1 265

T21 10x5000iq 516 2 125

T22 100x1000iq 1 922 4 297

T23 100x3000iq 5 750 12 812

T24 100x5000iq 9 672 21 422

Table 3 The results for the Rose RT version and the new PathMATE version discussed in section 6.4

Figure 9 Diagrams over some results presented in Table 2 and Table 3. In the upper left corner are the

results from Table 2 with the first PathMATE version. To the right are the results from the new

PathMATE version with 1 000 to 15 000 requests. At the bottom are some results from the new

PathMATE version with 10 000 to 500 000 requests.

0

2000

4000

6000

8000

10000

12000

1000 3000 5000 15000

T1 1000x1q T4 3000x1q T2 1000x5q T6 3000x5q

Requests

milliseconds

PathMATE

Rose RT

0

100

200

300

400

500

600

700

1000 3000 5000 5000 15000 15000

T1 1000x1q T4 3000x1q T2 1000x5q T3 1000x5 iq T5 3000x5q T6 3000x5 iq

Requests

milliseconds

PathMATE

Rose RT

0

5000

10000

15000

20000

25000

10000 30000 50000 100000 300000 500000

T19

10x1000iq

T20

10x3000iq

T21

10x5000iq

T22

100x1000iq

T23

100x3000iq

T24

100x5000iq

Requests

milliseconds

PathMATE

Rose RT

32

5.10 A summary of problems encountered in the project

• Using OSE signals instead of PathMATE’s semaphores in TimerThread

did not solve the runtime problem with PathMATE applications in OSE

environment.

• An error in the PathMATE class PfdFineGrainedTime.

• Weak support in PathMATE’s templates when operating on Strings.

• Invariance between PIM and generated code in:

- associations, causing circular loops in complex element structures.

- attributes, for example protected attributes in the model became public

in the generated code.

• Measurement problems of the execution time when running a simulated

version of the large telecom company’s generic platform.

• Lack of support for the C++ standard library in the large telecom company’s

generic platform.

• Hard to divide the GPEH application in one analyzed domain and one realized.

• Legacy problems in form of:

- name conflicts between analyzed and realized domains

- declaration of global attributes and structs in PathMATE versus

realized code

• The absence of an OSE operation attach_from caused a limited and

unnecessary complex solution to call attach from a PathMATE application.

• An ineffective way of handling deferred events lead to a design modification

of the original PathMATE version of the Client-Server application.

33

5.11 A summary of the results

• A new solution for handling delayedEvents was achieved through

TimerThread. This solution is:

- optimized with fewer calls for the system time.

- open for future optimizations if another structure than a list is desired

for the delayedEvent queue.

• A working PathMATE port to OSE and the large telecom company’s generic

platform.

• New markings and compile flags to keep the new, modified runtime library of

PathMATE platform independent were introduced.

• An error in PathMATE’s class PfdFineGrainedTime was discovered and

solved.

• A new way to compare two instances of the class PfdFineGrainedTime

has been implemented.

• An OSE dispatcher for communication between PathMATE applications and

other applications was implemented.

• The OSE dispatcher was expressed in templates for automatic inclusion in

applications.

• New markings to trigger the OSE dispatcher related templates were

introduced.

• The test applications, GPEH and Client-Server, were developed in PathMATE

• The GPEH application proved that the new solution works and interacts with

existing applications that have not been developed in PathMATE.

• The Client-Server application compared the performance of a PathMATE

model against a similar Rose RT model.

34

5.12 New markings introduced in this thesis

New markings introduced in this project

Marking name Type / Value Function (Object effected in bold)

Support_OSE “T” or “F”

(T)rue

(F)alse

Marks the system if it should support

OSE and activates the templates that

are used for OSE support (default is

“F”).

SignalType Name of a

signal number

Marks an object signal to connect it

with a signal number and also defines

which classes are signal

representations.

StructName Name defined

for the struct

Marks an object in a class signal

structure. Needed since the templates

in Pathmate can’t transform between

upper and lower cases, also allow

stucts to be named different from their

struct type.

workingDir Absolute path

to a directory

Marks the system in order to create a

build file with the right search path to

files to be compiled and included.

OSEDomain Name of the

OSE domain

Optional option to fill in if the user

changes the name of the default OSE

domain (default is “OSEDomain”)

OSESignals Name of the

enumeration

that contains

the model

representation

of the signal

numbers

The enumeration connected to this

marking will not be defined in the

generated code. External declaration

is needed; use this marking together

with IncludeFile. (default is

“OSESignals”)

IncludeFile Name of the

file where the

enumeration

is declared

An existing marking in PathMATE

that in this project has been extended

to be valid for enumerations which it

in previous versions wasn’t. This

allows external definitions of

enumerations.

OSESignalName Name of a

signal number

Marks a service to tell the dispatcher

which service should be called when a

certain signal is received. It could also

be a state signal (event) to trigger a

state transition in a state machine.

35

New markings introduced in this project

Marking name Type / Value Function (Object effected in bold)

typeDef The type

defined name

of the object

In some external code the name of the

struct has been defined by typdef.

This marking is used in that case and

structs of this object is generated

without defining that it is a struct.

MakeSignalFile “Extend”

“MakeNew”

The system needs a signal definition.

If there is an existing definition of

structs use “Extend” and type the files

containing the definition separated

with “;”. MakeNew will create a

signal definition with the signals in

the PIM only (default is

“MakeNew”).

CreatesOutsideAnalyzed “T” or “F”

(T)rue

(F)alse

Marking for an object that needs a

constructor and is included in the PIM

but not created in the PAL. “T” will

give the object a public constructor.

This will typically be used for a signal

class, it won’t be created in the PAL

but by the OSE Signal dispatcher

(default is “F”).

endParticipantInRelationship Name of a

class in an

association

Marks an association

(BinaryRelationship) in a signal

structure and has the name of the end

part of the class. This is to avoid

circular loops when a new class signal

is created.

36

6 Discussion This project has encountered several of positive and negative aspects of working with

PathMATE and customizing PathMATE. It has also experienced multiple legacy

problems and this chapter will highlight some of the gained knowledge and aspects of

PathMATE and xtUML tools.

6.1 Templates

Templates are necessary for code generation and gives great flexibility and an

effective way to develop software. In this thesis were PathMATE’s templates for C++

generation closely studied. By a minor error, during template implementation, it was

observed that a close relationship must exist between the static code and the generated

code in order to create a working system. During development of the templates

supporting OS signaling, the author to this report tried to generate a dynamic class to

keep track of all OS signals that were to be supported in the system. This class would

then relay the signal to the right instance in class representation. In order to make the

implementation as simple as possible, the OS signaling process was started in the

template generated system.cpp file in the sys folder (earlier described in section

2.3). This file works almost like an interface between the constant and the generated

parts in PathMATE. By including the new class to the file a circular dependency was

created.

A closer study of the system class shows that a circular dependency is already present

in the class but avoided by including some classes in the system.hpp and some in

system.cpp. This shows the close relation dynamic and static parts must have in

order to make xtUML tools work. The same conclusion is also mentioned in

Henriksson and Sabir (2007).

To summarize this section; it requires quite an effort of the designer to implement

new templates. It is sometimes hard to locate the right template if an error occur and a

thorough understanding of the xtUML tool and its dynamic and static parts is required

before any new templates can be deployed. It is also important that the templates are

made as general as possible and not just suitable for one project. This means that it is

recommended to only have one team customizing templates. A worst case scenario

would be an organization where each unit has customized their own templates and an

integration to make a working product would be close to impossible.

6.2 Recommended changes in PathMATE

In section 5.4.1 it was revealed that PathMATE does not distinguish dual and single

directed associations. As a result the object at the end of a single directed association

will have a pointer to access the object on the other side. This may or may not be a

security threat depending on the case. However it definitely throws off the meaning of

the PIM and the code is not generated the way the developer want it to be.

37

It has also been proved in the same section that it can affect customized templates and

lead to unnecessary markings.

6.2.1 Inheritance of the template type UserDefinedType

As mentioned in section 5.3.1, the template type UserEnumerate, which is a subtype

to UserDefinedType, can not be a realized type. The type UserNonEnumerate, which

is also a subtype to UserDefineType, can however be chosen as a realized type. In the

author’s opinion, this makes no sense! A UserDefinedType should be a type, defined

by the user and the user should therefore have the rights to define it as either a

realized or analyzed type. The attribute isExtern in UserNonEnumerate should

therefore be moved to the supertype UserDefinedType and be available for both

UserNonEnumerate and UserEnumerate.

An understandable argument for not having UserEnumerate as an UserDefinedType is

that all enumerations need to be declared in the analyzed model. This is true in most

cases and realized and analyzed parts sharing enumerations might be a bad design in

many cases. But through this project it has been shown that global properties, like

signal numbers, sometimes needs to be expressed in enumerations and PathMATE’s

definition of enumeration might not be general enough.

6.3 Compiling PathMATE’s runtime library

PathMATE’s runtime library is compiled together with the code generated from the

PIM. This has its advantage as well as disadvantage. By compiling all code together it

can be assured that the compiled code from the static runtime library is up to date with

the current compile flags. Some markings will for example change compile flags and

the runtime library will always be up to date when it is recompiled every time the

system is built.

These markings that will result in compile flags can be target specific and for example

only compile the code for a specific OS. They can also sometimes be used to optimize

the application in different aspects. For example can the user define the compile flag

PATH_USE_MAP in order to use a map instead of a linked list3. It is also possible to

do different memory configurations through these compile flags.

It can obviously be good to recompile the runtime library. However, this will result in

long compiling times even for small changes. This can be quite annoying if the

developer has constructed a complete PIM and only makes small changes in the

model, for example during test phases. It could therefore be desirable to have

PathMATE’s runtime library be compile separately and not every time the PIM or

PSM has changed. At the same time, this puts more responsibility on the user to be

aware of any changes made in the markings and in the model.

3 This project hasn’t used this compile flag due to problems using the C++ standard library on the large

telecom company’s generic platform. The same problem is discussed in 4.2 Dependency on C++

standard library.

38

The compile time for the runtime library will however in many cases be relative short

compared to the compile time for the rest of the system in large applications. The

analyzed code will be regenerated every time a new transformation is made which

means that files with generated code will get a new timestamp every time a

transformation is made and has to be recompiled.

Maybe long compile times is the price of having flexible models that easily can be

transformed into code. The price might not be too high since a build can take place

over night or while the user is working in different applications. If this compile time

would have a severe affect on business, it could be discussed if it is possible to check

the PSM and compare it to the last time it was generated. This would be similar to the

way many compilers work today.

6.4 Comments on the Client-Server test

The execution times for the PathMATE and Rose RT version of the Client-Server

application are presented in section 5.9. The first result in Table 2 gives a surprisingly

high execution time for the PathMATE version, which can be seen in Figure 9. This

was suspected to be unreasonable and a new version of the PathMATE was therefore

modeled.

The first PathMATE version of the Client-Server application worked with deferring

events in some states (see Table 1). Since the first model was developed without

really knowing how deferred events were handled in PathMATE, it was interesting to

model the new version without using deferred events. This solution has the same

structure as the first version but, on a model level, a clumsier way to receive events

that should be deferred. The new version simply stores any attributes from the event

that should have been deferred and then generates a new event in the appropriate state.

This new model made a huge difference in the execution time which can be seen in

Figure 9 and in Table 2 to Table 3. The reason why the new model performs better is

because of the class PfdTask, mentioned in section 2.4. This class contains one

queue for all deferred events. When a state transition takes place in an instance of the

class PfdActiveObject will this instance call the function

PfdTask::releaseEventsForDestination(PfdObject*).

This function will then go through all events that have been deferred for any instance

that are running on that PfdTask. This is obviously an inefficient solution when

thousands of events can be deferred in the Client-Server application that also makes

many state transitions.

Rose RT also has a function to defer events. In this case, the events will not

automatically be released at a transition but the developer has to explicit write code

for when deferred events should be released.

PathMATE has, in the author’s opinion, a more elegant way of handling deferred

events, where the developer doesn’t have to remember to release them later in the

code. But it is of course unacceptable with such a large impact on the performance.

The best way might be to keep the function to automatically release deferred events

39

but to implement it so that instances and states are flagged if they have deferred

events. In this way, unnecessary checks for every state transition will be avoided.

The conclusions that can be drawn from Figure 9 and Table 3 are that the PathMATE

version can handle more events faster and that Rose RT might be better for handling

many clients. The only time Rose RT is faster is in the case with 3000 clients and only

1 request per client (Test 4). This result is most likely because Rose RT works with a

fixed number of clients and has, on a code level, an array while the PathMATE

version has a list. Since all clients start requesting at the same time, Rose RT will

have direct access in the array by just increasing its array pointer while PathMATE

has to traverse the list. It is traversing in order, but will have to update a forward

iterator as well as a backwards iterator.

Rose RT would most likely be superior for a test case where random clients are

requesting since it has direct access to that client with its array index. But keep in

mind that PathMATE can, through markings, easily swap its instance list to an

instance map4 which would decrease the search time. Another benefit of PathMATE

is to have a dynamic number of instances.

These results give an indication that PathMATE has a better performance in terms of

short execution time. One should however keep in mind that due to different sets of

rules in PathMATE and Rose RT the models are alike but not identical. For example,

a state machine can’t easily be added to an object in Rose RT. The active part in Rose

RT is called a capsule and has to be modeled separately to control a class. Therefore is

the session not an active object in the Rose RT version and has to be initiated for

every new session. This is most likely why the difference between having an open

session for all requests and closing the session between each request is bigger for the

Rose RT version. PathMATE simply keeps the same session, but in an active or

dormant state depending on if the session is open or closed.

Another difference between the PathMATE version and the Rose RT version is that

they are developed by different developers. Since the author has focused on

PathMATE in this project and has no experience of development in Rose RT, that

version has been developed by expertise on the large telecom company. However,

intense and close communication to reduce the differences has taken place.

The short developing time speaks in favor of PathMATE. Since the PAL is general

and abstract, combined with easy editable graphs was the development time for the

PathMATE version a little more than half of the development time for the Rose RT

version. In one aspect took the two the same time since the PathMATE version had to

be remodeled. But a new and effective way of handling deferred events would

definitely allow even better PathMATE models.

4 This project has not been able to use the PathMATE instance map, see section 5.2.

40

6.5 Risk of becoming dependent on PathMATE

This project has focused a lot on legacy problems when introducing PathMATE to a

system where it needs to communicate with other applications. According to the

result, one can overcome this problem. But there are two scenarios that one has to

consider before introducing PathMATE in software production.

1. Imagine a junction between two software companies, one using PathMATE

and one using another tool. Is PathMATE open enough to be replaced by

another tool? Will there be the same kind of legacy problems like the one this

project has solved in the future if PathMATE needs to be replaced?

2. The software industry continually evolves. Is PathMATE ready for the future

and new technology?

The answer to the first scenario is most likely that PathMATE is open enough to

provide a smooth transition to another tool. PathMATE’s templates are fully

accessible at source code level and old models can be renewed to interact with other

applications through a new code generation with customized templates. The flexibility

of templates is a great advantage.

If PathMATE is ready for the future depends of course on how the future will be.

MDA seems to be here to stay and PathMATE should not have any problems working

with different UML tools. PathMATE currently supports UML 2.0 and it would be a

fair guess that Pathfinder will stay updated with any new standards. The only risk

would be if Pathfinder suddenly stops its business. But this is a general issue

depending on the tool provider and will not be further discussed.

A standard for AL will most likely change the PAL in the long run. This means that

the PAL has to be re-written or possible translated or mapped in some automatic way.

This could be a major project that would affect the normal business negatively. The

forecast that some kind of automatic mapping or translation is possible should

however look good since both AL will have a similar meta-model. This assumes that

the PAL is abstract enough and that no severe name conflicts with different

functionalities are present. In this way could PAL coexist with, or be replaced by, a

possible new AL.

PathMATE is a powerful tool in object-oriented programming which could be seen as

the main programming paradigm in many industries today. One possible future that

PathMATE most likely isn’t ready for is if the object-oriented program paradigm

suddenly becomes unpopular. The behavior of a model in PathMATE would for

example be hard to translate into a non UML based form of programming. This is

most likely a common problem in all tools and no candidate is better than the other in

this aspect.

41

7 Conclusions

7.1 Legacy problems and OSE signaling solutions

This thesis has shown that an interaction through OS signaling is possible between

PathMATE generated applications and other applications. However, it is not

reasonable to recommend a full scale launch of PathMATE in the large telecom

company’s software development. Generic tools will in general never work straight

out of the box for customers. PathMATE is a strong candidate for xtUML tools but

can not be recommended for the large telecom company today without further

customizations.

The large telecom company is too dependent on its current tools. An eventual

transition from other tools to PathMATE would have a too big of an impact today.

This project has shown how PathMATE can interact with applications developed in

other tools through OS signaling. But in order to make the large telecom company less

dependent on current tools, a more effective way to develop OSE compatible

PathMATE applications need to be used. The most important issue to solve is more

automatic handling of signal definitions. A possible way of doing this is discussed in

section 8.4.

There is also a non technical aspect when introducing a new tool in the development;

how it will be received by the employees. From the author’s own experience of

learning how to work with PathMATE, it is quite easy to learn for a developer with

some modeling background. Reeducation from Rose RT to PathMATE should

therefore be smooth for the employees of the large telecom company. The GUI in

PathMATE can be interpreted as more appealing and easier to use accordingly to

Henriksson and Sabir (2007). No major impact in the business should occur in this

non technical aspect if PathMATE was to be introduced.

Chapter 8 presents some areas that could be interesting to look into before a full scale

launch of PathMATE. In the chapters 5 and 6 there are also some changes of

PathMATE that are recommended. Otherwise PathMATE is definitely a strong

candidate to be used at the large telecom company.

7.2 Benefits and disadvantages of PathMATE

This section will try to answer to the question if PathMATE will result in less work

and better code. Of course this varies from case to case. For large projects it is quite

possible that PathMATE can contribute both to less work in coding and more reuse of

old solutions. At the same time a new kind of programming is introduced in xtUML –

the coding of templates.

Smart, general and effective templates must be created and can not always be bought

from a third party. This means a trade off between resources put into templates and

resources saved by computer generated code and reuse of models. In one aspect, the

same amount of work could still be present but moved from traditional coding to the

42

making of templates. However, large projects and companies with potential to reuse

old solutions will most likely benefit from xtUML. It will also be easier to make

changes and optimizations in the code since this can be done automatically.

It depends of course on the templates if a code generated from PathMATE is better

then hand typed code in some aspects. In aspects of common runtime errors, like

“Array out of bound”, PathMATE is superior since the developer doesn’t have to keep

track of indexes in arrays. Everything is sorted through the templates. The issue with

memory leaks could still be present when using PathMATE but memory leaks due to

wrapped classes will not be an issue for PathMATE. The short answer is simply that

PathMATE generated code will most likely be larger than hand typed code but most

likely have fewer errors of human characteristics. This is a major advantage and can

save a lot of resources in debugging.

This project also indicated that using PathMATE could lead to shorter developing

times. In section 6.4 is the development time for the PathMATE version of the

Client-Server application estimated to half of the development time for Rose RT. This

might have several reasons, but due to PathMATE’s abstract way of developing,

where many details are generalized, is it possible for the developer to focus on only

the design and not on any target specific details like indexes and pointers. Based on

this should PathMATE be able to shorten the development time, and if the possible

reuse of models is considered, might PathMATE reduce the development time further.

Chapter 8 covers some future issues and improvements that can be implemented in

PathMATE. Amongst others is a hidden overflow problem that won’t affect the

system until year 2038. Aspects like this are also important to consider when choosing

a tool that might be used for a long period and the code of which might be running for

several decades.

43

8 Future Work

8.1 Problems in year 2038

The error in the class PfdFineGrainedTime, that could return negative times,

was solved satisfying with minor modifications since only the difference between two

times needed to be returned. Still there is a problem in this class that this thesis has

not investigated. The author fears that PathMATE applications will crash during the

year 2038. This is because of that PfdFineGrainedTime has an int representing

the amount of seconds with the system time as reference when the system runs on

OSE. This is usually the time from the 1st of January 1970. In 2038 will the amount of

seconds from 1970 exceed the capacity of a 32-bits int. To investigate how common

this problem is in the system and what the possible impact could be is recommended

before 2038.

8.2 New tools for developing templates

xtUML tends to shift the programmer’s workload from producing code in a target

specific language to developing templates. Templates saves a lot of time in software

development once they are in place. But during the introduction of new templates in

this thesis it was noticed that some errors in the templates couldn’t be detected when

generating code in PathMATE. First when compiling outside PathMATE would these

errors appear in one or many files and then the errors needed to be backtracked to the

right template. It would be nice to have some kind of IDE for templates with features

like a pre-check whether the template will generate code according to the target

specific language’s structure and that the templates code follows the template

semantic.

8.3 xtUML for critical systems

Does xtUML mean that control over how the system works is lost with an increased

abstraction level? Can xtUML be used for time critical systems where lives are at

stake or do we have to depend on hand coded programs to be certain that a system

responds quickly enough? Can time complexities be calculated and guaranteed with

PIMs and templates as reference or is it necessary to review xtUML generated code

for this purpose?

8.4 XMI Bridge

The solutions in this report work but there is still some manual work needed to

introduce new signals in PathMATE. The scope of this thesis did not include this

problem and it has therefore not been covered. In order to make PathMATE efficient

at the large telecom company, a bridge between C code to PathMATE elements

should be developed to overcome the legacy problem with signal representation.

44

Since the signals are already defined in .sig files according to the OSE pattern for

signals, it would be possible to parse out the information needed from the signals that

are defined in the .sig files. This could then be translated into XMI code and markings

and introduced in PathMATE domains. A sketch for a possible solution of this

problem is presented below.

Figure 10 A possible solution to automate introduction of signals in PathMATE.

8.5 Hybrid PathMATE – Rose RT tool

The previous investigation by Henriksson and Sabir (2007) focused on creating a

hybrid environment where PathMATE generated code and Rose RT generated code

could be compiled and built together. This project showed that a hybrid was possible.

The next step could be to create a hybrid solution where PIMs from both PathMATE

and Rose RT could coexist on a modeling level with interactions between the PIMs.

8.6 Improvements to PathMATE

This section covers PathMATE specific improvements of some weaknesses

discovered throughout this project.

8.6.1 Validate correctness between model and generated code

This thesis has shown two cases of inconsistency between model and generated code.

These two cases refer to association and attributes in models and are described in

section 5.8. The work to validate consistency between model and generated code

could probably be done by Pathfinder. But before a full scale launch of PathMATE,

one should consider a small investigation to secure that consistency exists. An

investigation of this kind will hopefully catch any inconsistencies that might be

specific to the current development environment at the company. Section 5.8 also

stresses the importance of having control and knowledge of third party tools and to

not simply trust them.

Needs to be developed

.sig file containing

all signals that will

be used.

Parser built up

according to the struct

and signal pattern XMI code

PathMATE

representation

of the signal

Markings

45

8.6.2 New way of handling deferred events

Section 6.4 brings up the issue that PathMATE has a smooth function to defer events

on a modeling level. This function is however very inefficient on a code level and

should be improved. One way to do this would be to let each active instance that can

defer events have its own queue for deferred events. In this way, search through other

instances’ events is avoided. It could also be more efficient to let the Transformation

Engine analyze which states can receive the deferred events and then modify the

templates so that the generated code only checks the deferred queue in the appropriate

states.

The solution to have one queue for each instance could be bad due to aspects of

concurrency since events would lose their internal order if there was no common

queue. The best solution might be to have a common queue but supported by different

flags to make sure that every transition doesn’t trigger a search for deferred events.

Whichever solution is the better, the author recommends that deferred events are to be

handled better in PathMATE.

46

9 References

Bath, Graham, Congress seminar 2007-10-03 Model-Based-Testing from a manager’s

perspective, T-Systems, Linköping, Sweden.

Doby, Carolyn, 2005, Accelerate Embedded Software Development

with Model Driven Architecture version 1.3, PathMATE Series, Foxboro, USA.

Enea OSE Systems AB 2000, OSE ver. 4.3 Documentation Volume 1 – Kernel.

Henriksson, Andreas and Sabir, Ghulam Murtaza 2007 exUML – Model Driven

Software Improvements For Real-Time Applications, KTH Department of Electronic,

Computer and Software Systems, Stockholm, Sweden.

Martin, Robert C., 2003, Agile Software Development, Principles, Patterns, Practices,

New Jersey, USA, ISBN: 0-13-597444-5.

Mellor, Stephen J. and Balcer, Marc J., 2002, Executable UML, A Foundation for

Model-Driven-Architecture, Addison-Wesley ISBN: 0201748045.

Pathfinder, 2002-2007, Technical Notes, Pathfinder Solutions LCC, Foxboro, USA.

Pathfinder, 2005, Effective MDA Training course version 4.52, Pathfinder Solutions

LCC, Foxboro, USA.

http://www.pathfindermda.com (March 3, 2008)

47

APPENDIX A: Way of Working with PathMATE

This section will describe the procedures that are recommended when working with

PathMATE.

The design process starts with defining use cases. At this phase actors are identified.

An actor is any external unit that is acting on the system that is being modeled. This

could be a user, an external application or something else that is affecting the system.

With these actors we can define different interactions that will appear. These

interactions can be formulated in to goals, preconditions, triggers, postconditions and

a summary for each interaction. This structure will help the designer in the next phase

which is domain modeling.

Domains can be either realized or analyzed. The realized domains are domains that

are developed outside the system, for example an already existing application. The

framework for PathMATE that was referred to as “constant source code in the folder

mechanisms” in section 2.3 is also included in the system and added through

markings as a realized domain. Analyzed domains are any domain that is going to be

developed in PathMATE.

In order to decide the domains, one needs to set up boundaries within the system in

aspects of responsibility and possible future reuse. A good domain design, where all

domains can exist in a meaningful way by themselves, makes the domains more likely

to be reused in other systems. Of course the domains need to interact to create a

system but try then to sort the domains after abstraction and which domain depends

on another. Try also to describe each domain to see if it has a well defined meaning.

Next step is class modeling within each domain and as usual it is good to have the real

world as a reference when to come up with classes. Suitable class candidates can in

the real world be represented of physical things, roles, events and specifications like

rules and definitions. Make sure to ask the question if the class belongs in the

specified domain and take also note if one domain starts to contain a large number of

classes. Maybe it is needed to step back to the domain modeling phase to see if it is

justified to break up a large domain into several smaller domains.

Also add attributes for the classes and create associations between interacting classes

and specify the associations’ multiplicity. Try to generalize classes with inheritance

but please note that multi inheritance is not supported in PathMATE due to constrains

in the target language. Once all the classes are in place it is time to start modeling the

behavior of each class.

The behavior modeling will in the model be expressed as operations and state

machines. Any operation or state machine added to a superclass will as usual be

inherited to its subclasses.

Operations, or services as they are called in PathMATE, look and work about the

same as in any developing tool or target language. They can be defined with or

without return parameters and one or multiple in parameters. In likeliness with general

48

programming, each operation will have its on action language code to be performed

when the operation is called.

During the design of state machines there are a few guidelines to consider:

• Initial state must be defined.

• Try to imitate the behavior in the real world with a valid life cycle for the

machine and with a focus on state dependent behavior.

• Consider all reasonable error cases for all states and introduce recovery states.

• Transitions can be triggered or non-triggered but if there are multiple

transitions out from a state, they all need to be locked by different triggers.

• The main types of state machines are “circular” or “born to die” avoid any

“spider” shapes. Please see Figure 11 for clarification. The “spider” shape is

usually function dependent instead of state dependent and should therefore be

avoided in state machines.

Figure 11 The figure shows the principals for the different state machines. From the left: “born to die”-

state machine, “circular”-state machine and “spider”-state machine. The spider should be avoided.

The last step of the modeling in PathMATE is action modeling. An action can be

performed at:

• The initialization of the system

or a domain.

• A domain service

• A class service

• A state or state transition in an

active class

PathMATE has its own action language for implementing actions. This action

language is, from the author’s experience, quite easy to learn if you have some kind of

programming experience from before. Most common base data type exists in

PathMATE’s action language but containers like vectors, lists, trees and arrays does

not exist. Instead PathMATE works with “Group”-types within a statement block and

associations when interacting outside the block. These types eliminate classical index

errors like “out of boundary” that usually are made by programmers. Associations that

were made during the domain and class modeling phases and objects can be accessed,

linked or unlinked with the action language.

Born

to

die

machine state

Circular

Spider

left back leg right back

leg

right front

leg

left front leg

49

The observant reader might now question what associations really are if regular

containers doesn’t exist. The answer is that they do exist but on a PIM level. Since the

PIM doesn’t consider the final target language, it can’t reasonable know which

containers are available. The question what an association ends up being are left for

the markings and templates that will be used to answer.

Services can easily be called on both domain and class levels with the action

language. It is also very easy to create signals that can be sent to different instances in

the system. These signals can for example trigger a state transition in an active class.

The modeling is now done and a complete PIM is achieved. Before transforming to a

PSM that can be complied can take place, it is necessarily to mark the PIM. This is

done in the file properties.txt where it can be specified how the transition will

be made.

The commands in the file properties.txt will have the following pattern:

<Effected object type>,<The name and position of the object in the system>,<Name

of the marking>,<Value of the marking>

In code this can for example look like:

System,MyFirstSystem,ImplementationLanguage,cpp This will mark out the target language for the model.

or:

Domain,MyFirstSystem.SoftwareMechanisms,RealizedPath, c:\pathmate\design\cpp\mechanisms This will direct the transformation engine to the path where source code for the

realized domain SofthwareMechanisms can be found.

50

Appendix B: Test applications and GUI in PathMATE There are two intentions with this appendix; show parts of the GUI in PathMATE

when using Rational System Developer and describe the test applications GPEH and

Client-Server. Parts of some figures in this appendix have been covered in respect for

the large telecom company.

B1 The GPEH application

The GPEH has, as described in section 5.7, been split into one analyzed domain and

one realized domain. The PIM also includes the OSE domain that was referred to in

section 4.2. Below follows a diagram over the system. The domain scanner is the

analyzed domain and FileHandler is the realized domain.

Figure 12 The system design of the modeled GPEH.

51

The realized domain FileHandler only consists of functions that will relay the calls to

the realized code. In order to briefly show what kind of function is present in

FileHandler, see Figure 13.

Figure 13 Domain services in FileHandler. The observant reader might notice that the service

activateGpehScanner() seems to be misplaced and should belong in the scanner domain. This is correct

but in order to reuse some code that initialize the system and doesn’t need to be modeled in order to

show the effect of signaling in OSE, this realized code is included in FileHandler since it is a realized

domain.

Confidential

52

Figure 14 A compressed picture of the analyzed domain scanner. The intention is not to show any

details to the reader but to give a general view of how the GUI in PathMATE looks like.

Worth noticing in Figure 14 is the “web shape” at the lower half. This represents

different signals that are used in the system. All have the attribute senderID and

IndexID inherited from the class in the middle and some have functions as

sendAsOSESignal() and attachSignal() together with the signal specific attributes.

The figure indicates the importance of importing signal representations automatically,

see section 8.4, for effective usage in the large telecom company. Remember that

even if the GPEH was a fairly large project to model within this project’s scope, it is

still just a small application on the large telecom company’s systems where many

more signals exist.

Figure 14 contains a class named WorkFlowHandler. This class exists to secure

concurrency. It is an active class and its state machine is shown in Figure 15.

Confidential

Confidential

Confidential Confidential

53

Figure 15 Without paying any attention to details, the general appearance of a state machine can be

observed in the figure. Note the spider shape (as described in Appendix A) with the large state in the

middle as body. Even if the “legs” don’t have states and only “effects or actions” it is still a spider. All

these actions should be performed as domain services and were at the first attempt implemented this

way. But due to SuspGpehReq (the states in the lower part of the figure) it was necessary to defer

incoming events while SuspGpehReq was hunting for a server’s process ID.

Figure 12 through Figure 15 have given a glimpse of how the GPEH model turned

out. To also give a short example of behavior modeling in PAL, the code to handle the

incoming signal BcGpehScanActReq is revealed below in Figure 16. This signal can

be received in the ready state which is the largest state in Figure 15. The code is

simply expressed as an effect in a transition since it doesn’t have any concurrency

with other actions in the system.

54

Figure 16 An example of PAL used in the GPEH.

B2 The Client-Server application

This application has been developed in both PathMATE and Rose RT to study any

performance differences between the two. A thorough investigation has not taken

place but general assumptions and observations can be made from this simple test

application. The figures in this section are all from the first PathMATE version of the

Client-Server application. The second version looks about the same with just a few

more attributes and a slightly different state machine for the class Session.

The test will consider one server that can host multiple sessions with clients. The

clients will send requests to the server and it can be compared which tool has created

the fastest code to handle the execution. It would be interesting to study how the

system acts when events are queued. Therefore is the server limited to only handle a

certain number of sessions a time. Any clients trying to connect to the server when the

server has reached the max capacity will be queued.

A session ends when either the client disconnects or the session times out after being

inactive for a specified time. Any queued sessions will now have a chance to connect

to the server. The session contains most of the behavior in the application since the

Domain service GENERATE WorkFlowHandler:ScanActReq(inSignal) TO (FIND FIRST CLASS WorkFlowHandler);

Reference to signal representation from OSE dispatcher (int inSignal)

The action activate in the state machine of WorkFlowHandler Ref<bcGpehScanActReq> recSig = FIND CLASS bcGpehScanActReq WHERE (IndexID == inSignal); Ref<selfS> p_procData = FIND FIRST CLASS selfS; IF (p_procData.scannerActivationStatus != ACTIVATED){ p_procData.tempMaxFileSize = recSig.maxFileSize * 1024; p_procData.tempMaxStorageSize = recSig.maxStorageSize * 1024; p_procData.tempMeUserLabel = recSig.meUserLabel;

p_procData.tempMeLogicalName = recSig.meLogicalName; p_procData.tempGpehFileLocation = recSig.gpehFileLocation; } RbsResultT StartResult; IF (p_procData.scannerActivationStatus == PMSI_UP){ StartResult = FileHandler:activateGpehScanner(p_procData); // setting up files

IF(StartResult == RBS_OK){ p_procData.scannerActivationStatus = ACTIVATED; }ELSE{ p_procData.scannerActivationStatus = ACTIVATE_REQ_RECEIVED; }

}ELSE{ // scanner is activated, do nothing } // we're done send response Ref<bcGpehScanActRsp> sendSig = CREATE bcGpehScanActRsp(senderID = recSig.senderID,

clientId = recSig.clientId, result = StartResult); sendSig.sendAsOSESignal(); DELETE recSig; DELETE sendSig;

55

client is only sending a request to the server to increase an integer by one as a

symbolic payload. The state machine of a session is shown in Figure 19.

The Client-Server application is a very small and simple model and is all handled in

the same domain. No specific protocols are used for the communication between the

client and the server and regular associations are used.

Figure 17 The domain in the Client-Server application.

Figure 18 Another example of the PAL to exemplify the “accessors” (or navigations as they are called

in PathMATE) in PAL.

PAL in the class Client’s doRequest() service Ref<Session> session = FIND this ->A1; IF(session == NULL){ session = CREATE Session(); LINK this A1 session; LINK session A2 FIND FIRST CLASS Server; } GENERATE Session:StartSession() TO (session); GENERATE Session:handleCall(ID) TO (session);

56

Figure 19 The state machine for a session.