Anda di halaman 1dari 9

Using a fUML Action Language to construct UML models

C.-L. Laz ar, I. Laz ar, B. P arv, S. Motogna and I.-G. Czibula Department of Computer Science Babes -Bolyai University Cluj-Napoca, Romania Email: {clazar, ilazar, bparv, smotogna, istvanc} One approach was to replace the behavior with opaque expressions expressed in the destination programming language (Java, C++) and add them directly in the UML model. Another approach was to ll in the behavior after code generation, in the special marked places. These types of models will not react well to changes in the target programming languages or frameworks. Also, simulating the execution of these types of models and testing them is not easy. The fUML standard provides a simplied subset of UML Action Semantics package (abstract syntax) for creating executable UML models. It also simplies the context to which the actions may be applied. For instance, the structure of the model will consist of packages, classes, properties, operations and associations, while the interfaces and association classes are not included. The fUML standard enforces a data ow abstract representation for the behavior of the methods. This means that instead of accessing the values of parameters or variables from certain reserved locations, the values (or the references) of these types of entities will ow as tokens on edges. If a parameter or variable is used in multiple places, its value is copied using a fork node and sent to each action that needs it. To assign a new value to the entity, a new point that provides the value is created (with a new fork node). To access the properties of an object or invoke its operations, the specialized actions from the UML Action Semantics package are reused by the fUML standard. A concrete textual syntax is not yet standardized and, without an easy-to-use concrete syntax, the creation of executable UML models remains a difcult task. A textual syntax enforces a certain way of constructing models, which means that a lot of elements that need to be created explicitly in the graphical UML Activity Diagram can be implicitly derived from the syntax and created automatically. The control ow between the statements is implicit in structured programming languages. Accessing the parameters and variables is done with a simple name reference in text, while the model will contain all the object ow edges and fork nodes needed to represent them. And the examples can continue. OMG issued an RFP for a concrete syntax for an action language based on fUML. This means that in one or two years, if everything goes well, there will be a standardized

AbstractIn this paper we introduce a fUML based action language and describe its concrete syntax. The action language uses only elements allowed by the fUML standard for its abstract syntax. The concrete syntax resembles the syntax of existing structured programming languages, with some elements inspired by OCL. The action language is part of the ComDeValCo framework and we are using it to model the functionality of the components, to simulate the execution of the models and to test the models. Keywords-fUML; UML; Action Semantics; Structured Activities; Action Language; DSL.

I. I NTRODUCTION The Executable Foundational UML (fUML [1]) is a computationally complete and compact subset of UML [2], designed to simplify the creation of executable UML models. The semantics of UML operations can be specied as programs written in fUML. We introduce an action language based on fUML, with a concrete syntax similar to the concrete syntax of the structured programming languages (e.g. Java, C++). Some elements of the concrete syntax are inspired by Object Constraint Language (OCL) [3]. Currently, there is no standardized concrete syntax for a fUML based action language. A few action languages exist, some of them being proprietary. Some of these action languages are based on the Action Semantics package from UML, but none is based strictly on fUML, as the standard is still in Beta version. OMG issued a Request for Proposal (RFP) [4] for a concrete syntax. The remainder of the paper is organized as follows: section II presents the general context for a fUML based action language and section III presents the research problem. Then, section IV describes the action language we propose. Section V presents the existing work related to ours and section VI gives the conclusions of this paper. II. BACKGROUND Creating executable UML models is difcult, because the UML primitives intended for execution (from the UML Action Semantics package) are too low level, making the process of creating reasonable sized executable UML models close to impossible. In order to speed up the process of writing the behavior, different approaches have been used.

action language. When the standardized action language will be available, we will try to align our action language to the standard, if there are no major differences. The action language we propose is part of a framework: ComDeValCo (Framework for Software Component Denition, Validation, and Composition) [5], [6], [7], [8]. We are using it to model the functionality of the components, to simulate the execution of the models and to test the models. The main advantage is that we are able to test our models without having to generate code. III. R ESEARCH PROBLEM The research problem is to investigate the creation of an action language based on the fUML standard. This means that only the UML elements allowed by fUML should be used for the abstract syntax and the extra constraints imposed by the fUML standard should be considered. The fUML standard also provides a non-normative annex showing the general principles for building an action language with a Java syntax, which should be considered. Also, the OMGs RFP for the concrete syntax provides other guidelines that should be followed, in order to create an action language that will be similar to the action language that will be standardized by OMG. An action language that follows the principles of the structured programming is going to be easy to use by many programmers familiar with structured programming languages. Thus, we consider this an important factor in the design of the action language, even though the fUML standard allows non-structured control ow. Because many programmers are familiar with objectoriented languages like Java or C++, having a similar syntax will make the language much easier to be used. Also, the effort for learning the new language will be very much reduced. The action language will need to create the abstract representation for the statements and control structures as provided by the programming languages mentioned above, it must support complex expressions and easy access to parameters and variables. The fUML standard chooses a data ow abstract representation of the behavior. Though a difcult task, the action language needs to hide all the data ow aspects of the abstract representation. This aspect is more obvious in the case of parameters and variables that are represented in the behavior with rather complex systems of output pins (that provide the values), fork nodes (that duplicate the values), input pins (that use the values) and object ows. We understand that such an action language might not suit all needs, and that the language might not be usable in certain domains, but this is a compromise, we believe, that needs to be made in order to create an action language that allows the users to quickly create executable models and

POS +makeNewSale() +addSaleItem( code : String, quantity : Integer ) : Boolean SaleItem +quantity : Integer * +item 0..1 +currentSale Sale +addItem( product : Product, quantity : Integer ) * +product +product 1 Product +code : String +price : Integer

Figure 1.

POS Example Model

that the majority of users could adopt with almost no time investment. If the resulted action language has a well structured abstract representation, it will be possible to apply model transformations and generate code to structured programming languages with little effort. Thus, the executable models for which the behavior is created with such an action language can be converted to a multitude of platforms. IV.


In this section we present our fUML based action language. We use a Point-of-Sale (POS) example model, presented in g. 1. The example model consists of a POS (Point of Sale) class, which contains a list of Products and is the entry point of the system. The user can make a new Sale (stored in POS as the currentSale) by invoking the makeNewSale operation and by adding SaleItems to the current sale in the form of product code and quantity. The POS object nds the Product associated with the given product code by using a private findProduct activity, and, if present, passes the product and quantity to the currentSale. The Sale creates a new SaleItem instance and adds it to its list of sale items. The rest of the gures present the implementation of the operations and the findProduct activity, which is private and not visible in the class diagram. The gures show the implementation as it is written using our action language, followed by gures showing the abstract representation in fUML. To present the concrete textual syntax in this article, we use the Extended Backus-Naur Form (EBNF). A. Types The action language supports all the UML primitive types (Boolean, Integer, UnlimitedNatural and String). Lists (arrays) of elements are also supported. The lists have ordered elements (FIFO order) and they are indexed from 1. The action language supports adding and removing

1 2 3

makeNewSale() { self.currentSale := new Sale; }

Figure 2. POS::makeNewSale Activity Concrete Syntax

activity makeNewSale MAIN_BLOCK [lines 1-3] ASSIGN_STMT [line 2] <<readSelf>> result result <<createObject>> self Sale

elements from a list and checking the list size. To access (get/set) a value from a specic index position, the square parentheses syntax is used. In the syntax snippet below, the list nonterminal can be any expression that returns a list type. The item nonterminal can be any expression and index can have any integer value. list expr ::= list item list add list list list list | list size | | list rem ;
Figure 3.

value object <<addStructuralFeatureValue>> currentSale

POS::makeNewSale Activity - fUML Abstract Syntax

list list list list

item add rem size

::= ::= ::= ::=

[ index ] ; .add( item (, index)? ) ; .remove( (item | index) ) ; .size ;

Because the lists are represented in fUML as tokens that ow on the edges, and because the null values are represented by having no token at all, the lists cannot contain null values. An empty list is represented by having no token. The fUML standard provides a model library with default operations (primitive function behaviors) on these primitive types (e.g. +, -, And, Or, ListGet, ListSize). These behaviors are function behaviors, meaning that they contain no implementation, and the fUML execution frameworks will execute them according to their specication from the fUML standard. The equality test is done using the TestIdentityAction, which compares the values (in case of primitive types), or the references (in case of objects). The textual syntax makes use of the = operator: identity expr ::= expr = expr ;

The textual syntax provides the self keyword to be used to access the instance on which the operation or activity was invoked. In fUML it is represented with a ReadSelfAction. The textual syntax also provides the null keyword, used to represent no value. The null value is represented in the abstract syntax with a ValueSpecificationAction using a LiteralNull as its value. Testing that a variable is null, however, is done in a different manner, as shown in g. 4 [line 3] and g. 5. The value is seen as a list, which may have the size 0 (if the element is null) or 1. B. Expressions The action language allows the user to construct complex expressions in order to write conditions or assignment values. The fUML standard provides primitive operations for the supported primitive types inside an fUML Model Library. These primitive operations use one or two arguments and produce one result. Most of them are used as operators in the textual syntax, the unary operators having the argument on the right side, while the binary operators being binary inx operators. The arguments may be simple value literals, variable values, instance properties, operation calls or other operator expressions, as seen in the syntax snippet below for expr. expr ::= unary expr comp expr var expr prop expr oper expr identity expr | | | | | ; binary expr create expr list expr enum expr act expr | | | | |

The user dened classiers need to be Classes or Enumerations. There is no notion of a constructor, as in the object-oriented programming languages. The user will need to create an instance of a Class by passing no parameters, as seen in g. 2 [line 2], and in g. 6 [line 2], then initialize its properties, so that the instance will be in a valid state (g. 6 [lines 3, 4]). To create an instance, the CreateObjectAction is used in the abstract syntax (see g. 3 and 7). The user can access the properties of a Class instance and invoke its operations, and access the literals of an Enumeration. The general syntax of the instance creation expression is shown below. The class name represents a valid class name, either in simple form, or using the fully classied name of the class. create expr ::= new class name ;

To group the expression operands so that the order of evaluation be enforced, the action language uses round parentheses. The abstract syntax correspondent of the parentheses is the StructuredActivityNode, which is used to group the actions that correspond to the operand expression.

2 3 4 5 6 7 8 9

addSaleItem(code:String, quantity:Integer ) : Boolean { def product:Product := self->findProduct(code); if (product = null) { return false; } else { self.currentSale.addItem( product, quantity); return true; } }
Figure 4. POS::addSaleItem Activity Concrete Syntax

activity addSaleItem ( code : String, quantity : Integer ) : Boolean MAIN_BLOCK [lines 1-9] DEF_STMT [line 2] code findProduct return : Product

code code : String test IF_STMT [lines 3-8]

product result first ListSize <<testIdentity>> second list = <<valueSpecification>> 0 result : Boolean result THEN_BLOCK [lines 3-5] RETURN_STMT [line 4] <<valueSpecification>> result false



comp expr


( expr ) ;

quantity : Integer

ELSE_BLOCK [lines 5-8] CALL_OP_STMT [line 6] quantity product

The general syntax of the unary (e.g. -100) and binary (e.g. 10 + price) operator expressions is shown below. The op nonterminal is the operator symbol used to represent the functions from the fUML Model Library. unary expr binary expr C. Activities The action language allows the user to construct UML Activities, using only the elements included in the fUML standard. The Activities may be declared either in Packages or Classifiers, and they may be set as the methods of Operations. Fig. 2, 4 and 6 present the activities that are set as methods of their corresponding operations. Fig. 8 shows a private activity of the POS class (findProduct), which is not set as the method of an operation. An Activity may have Parameters, and for each Parameter there will be one input / output ActivityParameterNode or both, depending on the direction of the corresponding Parameter (in [default value], inout, out, return). The value of the Parameter will get in or out of the Activity through the ActivityParameterNodes. The value of the parameter will be exposed to the actions in the activity using ForkNodes (similar to variables). Fig. 5 shows that the addSaleItem activity has two in parameters: code and quantity, and for each one there is an input ActivityParameterNode. Their values are exposed to the actions using a ForkNode, each having the name of the corresponding parameter. The activity has also a return parameter for which there is an output ActivityParameterNode, named return. Because a return value can come into the node from different actions, a MergeNode is placed before the parameter node, so that any return token may ow in the node, without having to ::= ::= expr op op expr ; expr ;


addItem <<readSelf>> result self target object <<readStructuralFeature>> currentSale result RETURN_STMT [line 7] result

<<valueSpecification>> true

return : Boolean

Figure 5.

POS::addSaleItem Activity - fUML Abstract Syntax

wait for the tokens on the other edges, which might never come (see g. 5 and 9). The Activity will be structured in statements, using StructuredActivityNodes and ControlFlow edges to enforce the sequential ow between the statements (blocks of statements). The actions for each statement will be grouped inside one StructuredActivityNode. The only exception is represented by the ForkNodes that expose the variable / parameter values, and which are placed on the same level as the statement nodes, though no ControlFlow edges connect to them, only ObjectFlow edges. Fig. 4 shows that the activity has a main block of statements, which contains two statements: the denition of a variable and an if statement. The if statement has a block for each branch: then branch contains one return statement and else branch contains one call operation statement and one return statement. The same structure of statements, this time represented with StructuredActivityNodes, is seen in the abstract representation of the activity in g. 5.

1 2 3 4 5 6

addItem(product:Product, quantity:Integer) { def newItem : SaleItem := new SaleItem; newItem.product := product; newItem.quantity := quantity; self.item.add(newItem); }
Figure 6. Sale::addItem Activity Concrete Syntax

activity addItem ( product : Product, quantity : Integer ) MAIN_BLOCK [lines 1-6] DEF_STMT [line 2] result : SaleItem <<createObject>> SaleItem newItem product : Product ASSIGN_STMT [line 3] value <<addStructuralFeatureValue>> object product product quantity : Integer ASSIGN_STMT [line 4] value <<addStructuralFeatureValue>> object quantity quantity ADD_STMT [line 5] result result <<readSelf>> <<valueSpecification>> self * object insertAt <<addStructuralFeatureValue>> value item

The UML model structure described above and presented in g. 5, will be created behind the scenes by a conforming editor. The textual syntax, as shown in the syntax snippet below, requires only the signature (activity name and the list of parameters). The act name and par name nonterminals should be proper identier names for the activity and parameter, respectively. The type can be any classier. The default direction of a parameter is in. The direction of the return parameter is return. activity ::= act name ( (params)? ) : ret param block ; param ( , param )* ; (direction)? par name : type ; in | inout | out ; type ; { (stmt)* } ;

Figure 7.

Sale::addItem Activity - fUML Abstract Syntax

params param direction ret param block D. Statements

::= ::= ::= ::= ::=

(e.g. Java, C++) from the models created with the action language. This is true because the functionality of each statement is nested inside a node, which, also, has a nice structure (e.g. the complex operands of expressions are grouped in nodes). E. Access Properties, Call Operations and Activities 1) Access Instance Properties: To access the instance properties, the action language uses the usual concrete syntax from the structured programming languages. The access is handled behind the scenes with the specic fUML actions for structural features: ReadStructuralFeatureAction and AddStructuralFeatureValueAction. The latter action is used to set values. When setting a value to a single value feature, it has the isReplaceAll ag set to true. If the feature is a list, then the isReplaceAll ag is set to false and the effect is that the value is inserted in the list at the position specied by the insertAt property. The textual syntax is shown below. The obj nonterminal can be any expression that has a Class return type. If the object is missing, then self is assumed. Fig. 8 [line 2 and 3] shows how to read a multi-value property (self.product) and a simple property (prod.code). Fig. 6 [lines 3-5] shows how to set values to simple value properties (newItem.product and newItem. quantity) and how to access a multi-value property to add a value to it (self.item.add(newItem)).

The activity is composed of blocks of statements, some of which may be composed of other blocks of statements (e.g. if statement from g. 5; foreach statement from g. 9). Each statement is represented using a StructuredActivityNode, that contains all its actions and edges that provide its functionality. The statements are executed as a sequence, the control being enforced with ControlFlows (this is best seen in g. 7). The only exception to this structure is the presence of ForkNodes that are used to simulate the variables (e.g. newItem from g. 7) and parameters (e.g. product and quantity from g. 7), which are placed after the statements that declare them or set values to them. stmt ::= block | assign prop stmt | call oper stmt | call act stmt | def var stmt | assign var stmt | if stmt | while stmt | f oreach stmt | return stmt ; This structure (blocks of statements) gives the possibility to apply with ease a model transformation or perform code generation towards structured programming languages

1 2 3 4 5 6 7 8

findProduct(code:String): Product { foreach (prod in self.product) { if (code = prod.code) { return prod; } } return null; }
Figure 8. POS::ndProduct Activity Concrete Syntax

activity findProduct( code : String ) : Product MAIN_BLOCK [lines 1-8] FOR_EACH_STMT [lines 2-6] result <<readSelf>> self object <<readStructuralFeature>> result product

<<iterative>> FOR_EACH [lines 2-6] BLOCK [lines 2-6] prod code : String test first IF_STMT [lines 3-5] second result object <<readStructuralFeature>> code

prop expr


(obj .)? property ;


assign prop stmt ::=

(obj .)? property := expr ; ;

<<testIdentity>> = result : Boolean body

2) Access Enumeration Literals: To access the Enumeration literals, a ValueSpecificationAction is used, with the value being an InstanceValue. This instance value uses as its instance specication the EnumerationLiteral. The textual syntax we use is the usual syntax: enum expr ::= enum . literal ;

BLOCK [line 3-5] RETURN_STMT [line 4] return : Product

RETURN_STMT [line 7] <<valueSpecification>> result : Product null

3) Call Instance Operations: To call instance Operations, the usual concrete syntax is used, as seen in g. 4 [line 6]. If the object on which the operation is invoked is missing, then self is assumed. oper expr args ::= ::= (obj .)? oper ( (args)? ) ; expr (, expr)* ; ::= oper expr ; ;
Figure 9.

return : Product

POS::ndProduct Activity - fUML Abstract Syntax

call oper stmt

In abstract syntax, the CallOperationAction is used, which results in executing the method of the operation (of Activity type). The operations are visible to the outside according to their visibility property, as specied by the UML. 4) Call Activities: To call instance behaviors (Activities) not associated with Operations, a concrete syntax similar to calling operations is used, but with a different separator: -> (see g. 4 [line 2]): act expr ::= (obj ->)? act ( (args)? ) ; ::= act expr ; ;

call act stmt

In abstract syntax, the CallBehaviorAction is used. The behavior needs to be of Activity type. If it is set as the behavior of a Class, its visibility needs to be set to private and it may only be accessed from within the same class. The Activity may be contained directly by a Package, in which case it may be public and can be invoked as a procedure. F. Variables Fig. 4 [line 2] and g. 6 [line 2] present examples of the concrete textual syntax for declaring a variable. The textual

syntax allows to declare a simple variable or a list (array) variable and to set an initial value, or to default to null or an empty list. Fig. 7 presents the fUML model that represents the textual syntax for declaring a variable newItem:SaleItem (the rst variable declaration statement). The OutputPin return:SaleItem has the multiplicity 0..1 and forwards the initialization value from the CreateObjectAction to a ForkNode named newItem (the name of the variable), which duplicates the value and sends it along each outgoing ObjectFlow edge, to the subsequent actions that use it (as shown in the gure). The lower bound of the output pins providing values for the single value variables or the input pins receiving values from the single value variables might be 0. This is because the value of a variable can be null, which means that there is no token. When declaring a list variable, the OutputPin has the multiplicity of the variable, as declared in text. The standard way from UML of declaring the multiplicity is used in the textual syntax, limited to mentioning only the upper bound. The lower bound is set to 0. If no default value is provided, a ValueSpecifica-

tionAction, having as value the LiteralNull null is used implicitly (the action has a result OutputPin with the same multiplicity as the declared variable). The syntax for the variable denition statement and variable assignment is presented below. The var nonterminal is the variable name and the type can be any classier. The expr result type must match the type. The mult up (multiplicity upper bound) can be any positive integer value (size), or *, which means the variable list is unbounded. def var stmt mult up ::= ::= def var : type (mult up)? (:= expr)? ; ; [ (size | *) ] ; var := expr ; ;

when the else clause is missing). And it is determinate, meaning that at most one test will succeed (this is needed when else clause is present, so that, if the test of then clause passes, the body of else clause will not be executed, as the test of else clause will always succeed). 2) While Statement: The action language uses a concrete syntax similar to Java for this statement, also. The condition is evaluated at each iteration. while stmt ::= while ( cond ) block ;

assign var stmt ::=

To access the value of a variable, it is simply referenced by name (the var nonterminal below). In abstract syntax, accessing the value of a variable is done using an ObjectFlow from the last accessible ForkNode that provides a value for the variable (it has the same name as the variable). var expr G. Control statements 1) If Statement: The action language uses a concrete syntax similar to Java for this statement. The condition expression (cond nonterminal in the syntax snippet below) must return a boolean value. If the condition evaluates to true, the then branch is executed (the rst block ), otherwise the else branch is executed, if present (the second block ). if stmt ::= if ( cond ) block (else block )? ; ::= var ;

The While statement is represented with a tested rst LoopNode. The LoopNode has a built-in system of loop input/variable/output pins, which is used to pass in and out the outer variables that are used and updated inside. The LoopNode contains no action for the setupPart. It contains all the actions for the test and bodyPart properties, which will simply reference the used actions (contained as nodes). The test actions will have to output a boolean value. The decider pin for the test will always be the output pin of its test actions (the condition expression). The bodyPart contains the actual body actions (inside one block node) and, if needed, the extra actions and control nodes needed to update the loop input/variable/output pins. 3) ForEach Statement: This statement is similar to the While statement, with the difference that this action is specialized to iterate over lists of elements. It will execute its body actions for each element in a list, in sequential order (g. 8). f oreach stmt ::= foreach ( var (: type)? in list ) block ;

The If statement is represented with a ConditionalNode, with one Clause object if only then branch is present (see g. 8 [lines 3-5]), or with two Clause objects if else branch is also present (see g. 4 [lines 3-8]). The clauses will be properly ordered by using their successor / predecessor properties. The ConditionalNode will contain all the test and body executable nodes, and the clauses will properly reference them as test or body nodes. The decider pin for a test clause will always be the output pin of its test node. The else clause will always have a true clause test, meaning that the test node will consist of one ValueSpecificationAction for the true LiteralBoolean. The body node for each clause is a block of statements and is represented with a single StructuredActivityNode, which will contain the actions for the statements. The ConditionalNode is not assured, meaning that it is possible that no test will succeed (this is needed

The ForEach statement is represented with a StructuredActivityNode containing the actions that produce the collection and the iterative ExpansionRegion (g. 9). The list of elements is passed to the input ExpansionNode of the ExpansionRegion, and the region executes the body actions for each element. The element is made available inside using a ForkNode (similar to having a variable). 4) Return Statement: Every activity that has a return parameter must have a Return statement at the end of every possible navigation path through the code. If there is no return parameter, there is no need to have an explicit Return statement. The type of the return expression must conform to the type of the return parameter (see g. 4 and 8). return stmt ::= return (expr)? ; ;

The expression actions inside a Return statement send the result value to a MergeNode found directly in the Activity, which forwards it to the return ActivityParameterNode. Also, the Return statement gives the control to the MergeNode placed before the Activity-

FinalNode, which forwards it to the nal node, forcing the execution of the activity to end (see g. 5 and 9). There is a need to use the MergeNodes before the return parameter node and nal node, because there could be multiple return statements in the activity, which means there will be multiple edges going to these nodes. And these nodes will not execute unless all the edges pass a token, which is an impossible situation. The MergeNodes will pass each token on outgoing edge immediately as it arrives, which means that the tokens are able to get to their intended destination. V. R ELATED W ORK Only a few action languages exist and some of them are proprietary. Some of these action languages are based on the Action Semantics package from UML, but none is based strictly on fUML, as the standard is still in Beta version. Currently, there is no standardized concrete syntax for a fUML based action language. One powerful action language is the Object Action Language (OAL) [9] from Mentor Graphics BridgePoint product. OAL is very simple and readily understandable by non-programmers. The language is proprietary and the abstract syntax on which it is based is not available for us to compare it with fUML. From the concrete syntax, we observe that the language contains more data types not mentioned by fUML, and that it uses the concepts of Interface and AssociationClass, that were removed from fUML. Thus, we can conclude that the abstract syntax of OAL is not compatible with fUML. The Action Specication Language (ASL) [10] from Kennedy Carters iUML product is also a powerful action language. The abstract syntax is also not available for this language. The concrete textual syntax implies that types and elements not compatible with fUML are used. Shlaer-Mellor Action Language (SMALL) [11] is an action language that was never implemented by anyone. It uses a data ow principle as fUML, but the language is not based on UMLs Action Semantics package. Platform Independent Action Language (PAL) [12] from Pathnder Solutions PathMATE product is another action language, with the same issues as OAL. ITU-T Recommendation Z.109 [13] denes a UML prole that maps to SDL semantics so that UML can be used in combination with SDL (Specication and Description Language - used for real time systems). The language maps to the Action Semantics package from UML, but it uses stereotypes for every action and other elements not compatible with fUML. The Z-109 recommendation is not meant to provide a general purpose UML action language. OCL4X [14] uses OCL as its abstract syntax, enhanced with meta-model actions for altering the state of a system (it adds side-effects to OCL). Thus, it does not use the fUML abstract syntax. Also, the OCL types and collections are

reused, which are not compatible with those mentioned by the fUML model library. An extension of an OCL-based action language that includes array types and corresponding operations is presented in [15]. An action language with this extension has the same issues as OCL4X. +CAL [16] is intended to be a more generic action language, though it is focused at Distributed and Real-time Embedded systems. It uses UML Action Semantics as its abstract syntax, but not only fUML, and there are not enough details about its concrete syntax and the abstract syntax constructs. Action Language for Business Logic (ABL) [17] is an action language inspired by Java, though it has some differences regarding types and variables. The action language is converted to actions from UML Action Semantics, but uses elements that were not included in fUML. A code generator was also developed for the intermediate UML model, as there was none at that moment. Good conclusions are drawn regarding the fact that a general transformation from an arbitrary UML Action Semantics model to a given language can become a very complicated process. This is because of the ne granularity and low level of abstraction of UML Action Semantics. This means that in order to produce good platform dependent code, the code generator will need to take into consideration the model constructs generated with a specic action language. Big steps have been taken by OMG towards the standardization of an fUML action language. OMG issued a Request for Proposal for a concrete syntax for an action language based on fUML [4]. VI. C ONCLUSIONS AND F URTHER W ORK Creating reasonable sized executable UML models is hard, because the UML primitives from the UML Action Semantics package are too low level. The fUML standard provides a simplied subset of UML Action Semantics package and it also simplies the context to which the actions need to be applied. However, an easy-to-use concrete textual syntax is still needed in order to speed up the process of creating executable models. In this article, we have presented an action language that is based on fUML and that follows the structured programming principles, with a concrete textual syntax similar to the most popular object-oriented programming languages (e.g. Java, C++). In the future, we plan to create a fully functional editor based on this action language and integrate it into our ComDeValCo framework. We already have a prototype editor implemented as an Eclipse plug-in that we used to create simple activities, which we managed to successfully execute using an implementation of the fUML standard that supports the execution semantics [18].

Also, we plan to further investigate the possibilities of applying transformations to the models created by our action language, and to generate code in different programming languages. ACKNOWLEDGMENT This work was supported by the grant ID 546, sponsored by NURC - Romanian National University Research Council (CNCSIS). R EFERENCES
[1] Semantics of a Foundational Subset for Executable UML Models, Object Management Group Standard, Rev. 1.0, Beta 1, 2008. [Online]. Available: FUML/ [2] UML Superstructure Specication, Object Management Group Standard, Rev. 2.1.2, 2007. [Online]. Available: [3] Object Constraint Language Specication, Object Management Group Standard, Rev. 2.0, 2006. [Online]. Available: [4] Concrete Syntax for a UML Action Language, Object Management Group Request For Proposal, 2008. [Online]. Available: [5] B. P arv, S. Motogna, I. Laz ar, I.-G. Czibula, and C.-L. Laz ar, ComDeValCo - a Framework for Software Component Definition, Validation, and Composition, Studia Universitatis Babes -Bolyai, Informatica, vol. LII, no. 2, pp. 5968, 2007. [6] I. Laz ar, B. P arv, S. Motogna, I.-G. Czibula, and C.-L. Laz ar, iComponent: A Platform-independent Component Model for Dynamic Execution Environment, 10th International Symposium on Symbolic and Numeric Algorithms for Scientic Computing, 2008. [7] I. Laz ar, B. P arv, S. Motogna, I.-G. Czibula, and C.-L. Laz ar, An Agile MDA Approach for Executable UML Structured Activities, Studia Universitatis Babes -Bolyai, Informatica, vol. LII, no. 2, pp. 101114, 2007. [8] C.-L. Laz ar and I. Laz ar, On Simplifying the Construction of Executable UML Structured Activities, Studia Universitatis Babes -Bolyai, Informatica, vol. LIII, no. 2, pp. 147160, 2008. [9] Object Action Language Reference Manual, Mentor Graphics, 2009. [Online]. Available: object-action-language-reference-manual-38098 [10] UML ASL Reference Guide, Kennedy Carter Limited, 2003. [Online]. Available: [11] Shlaer-Mellor Action Language, Project Technology, Inc., 1997. [Online]. Available: downloads/small.pdf [12] Platform Independent Action Language, Pathnder Solutions, 2004. [Online]. Available: PAL04.pdf

[13] SDL combined with UML, International Telecommunication Union, 2007. [Online]. Available: T-REC-Z.109-200706-I/en [14] K. Jiang, L. Zhang, and S. Miyake, OCL4X: An Action Semantics Language for UML Model Execution, Computer Software and Applications Conference, vol. 1, pp. 633636, 2007. [15] S. Motogna, B. P arv, I. Laz ar, I.-G. Czibula, and C.-L. Laz ar, Extension of an OCL-based Executable UML Components Action Language, Studia Universitatis Babes -Bolyai, Informatica, vol. LIII, no. 2, pp. 1526, 2008. [16] I. Perseil and L. Pautet, A Concrete Syntax for UML 2.1 Action Semantics Using +CAL, The 13th IEEE International Conference on Engineering of Complex Computer Systems, pp. 217221, 2008. [17] C. Heitz, P. Thiemann, and T. W ole, Integration of an Action Language Via UML Action Semantics, Trends in Enterprise Application Architecture, pp. 172186, 2007. [18] Foundational UML Reference Implementation,, 2009. [Online]. Available: http://portal.