Figure 3 – uploaded by Ella Roubtsova

See full PDF downloadDownload figure

Fig. 3. Using properties as join point for ASM adornments static or monitored, and that if a property is derived (attribute isDerived is set to true) then the attribute kind is empty. — Figure 3 Using properties as join point for ASM adornments static or monitored, and that if a property is derived (attribute isDerived is set to true) then the attribute kind is empty.

Related Figures (46)

Fig. 1 shows a very small fragment of the AsmM metamodel representing the structure of an ASM model. In addition to its mathematical-based foundation, a metamodel-based definition for ASMs is also available. The ASM metamodel, called AsmM (Abstract State Machines Metamodel) [33,15,17,2], provides an abstract syntax for an ASM language in terms of MOF concepts, and has been defined with the goals ot developing a unified abstract notation for the ASMs, independent from any specific implementation syntax and allowing a more direct encoding of the ASM mathematical concepts and constructs.

Fig. 2. Using operation bodies as join points between data and behaviour Fig. 2 shows how simply the composition may be carried out. The MOF Operation class resembles the AsmM RuleDeclaration class. The name Opera- tion has been kept instead of RuleDeclaration to ensure UML conformance; similarly, the name Parameter has been kept instead of VariableTerm. Finally, the new property isMain has been added in order to designate, when set to true, a closed (i.e. without formal parameters) operation as (unique) main rule of an active class (the main class) to start model execution.

Table 1. W mapping: from UML*t to AsmM

R1.3 This means that you will not receive two entry ows (orders, entries it stock). The stock and the set of orders are always given to you in an up-to-dat state!!.

Listing 1.1. IOS behaviour: single-order strategy Many other strategies and particular scheduling algorithms can be defined and refined as well, in order to get a sufficiently precise, complete and minimal. executable PIM model which can serve as a basis for the implementation of var- ious PSMs. Appendix A reports the complete AsmetaL specification associated to the IOS class model in Fig. 4.

Fig. 1. Sequence diagram example.

We assume here that the Facade Controller pattern [4] was used in the desigr process. The user interaction was built according to the general MVC pattern. We repeat once more that the PIM level is assumed so no specific GUI framework i: chosen and so on. Due to all this we represent the whole GUI layer by one “abstract’ GUI controller class SystemGUI. The class FacilityManager plays the role of Fagad« Controller for this use case. The sole domain-specific class visible in the sequenc« fragment is Facility. According to general principles frequently used in MVC, al invocations from/to GUI level are asynchronous (more precisely, without return), bu all other ones are synchronous (with return).

An operation invocation is specified in a textual style, with arguments as in sequence diagrams. The invocation without return (a thick filled arrow head at one end) has no more options, but for invocation with return (an open arrow head at the other end too) an assignment can be combined with the invocation (in a syntax similar to the one used in UML 1.4 sequence diagrams). If required, the returned value can be specified on the invoke-return arrow. Explicit assignments are not frequently needed in this notation but can be used if required. Other data related actions (Add action in Fig. 3) are defined in the same Java-like style we propose in sequence diagrams. The syntax for loop head is also the same as we propose for sequence diagrams. If required, subdiagram invocation can be used for structuring of the description as in standard activity diagrams. One more specific facility is the definition of local variables within operation bodies. In contrast to attributes, such variables can not be defined in the class diagram. Certainly, the use of Boolean variables (available in Fig. 3) is not very typical at this level of abstraction, but nevertheless it illustrates the intended use of

Fig. 1. UML Behavior Diagrams

Fig. 2. CSP Composition

Fig. 4. Bank Account with a Derived State Because there is no restriction on how the state of a protocol machine may be determined, we allow machines to have derived states as well as the more usual stored states driven by the transitions of the state machine. Figure 4 shows an example of a Bank Account described as two machines composed using CSP ||. The right hand machine, A2, uses derived states (in credit and overdrawn) calculated on the basis of the balance attribute owned and maintained by Al.

Fig. 5. Mobile Phone - Dynamic View

Fig. 6. Mobile Phone - Static View

Fig. 1. Architecture: models and their meta-layer relationships A second aspect in the framework’s architecture is the differentiation between the (fixed) abstract syntax of a language and its evolving runtime configurations. Runtime models are again defined by a metamodel (the runtime metamodel) and manipulated through actions. Note that although there is technically no differ- ence between abstract syntax models and runtime models, changes shall only be applied to the runtime model for ease of having a clear separation between language concepts and execution concepts. Hence, all information required for model execution goes into the latter, for example value domains, program coun- ters, data structures such as stacks-frames, and so on. The (meta-)models and their relationships are shown in figure 1.

Fig. 2. The Ping-Pong state machine model: (right) sender, (left) responder This section illustrates the application of M3Actions along an example DSL: a finite state-machine language. The language was inspired by Martin Fowler’s upcoming book on DSLs (currently published on his website [17]). The DSL defines a typical state/transition language with state-machines communicating via exchanged events. The approach how to define the execution semantics will be explained along a simple Ping-Pong example model shown in Figure 2.

Fig. 3. Simple StateMachine Metamodel The structure of the state machines is defined by the metamodel shown in figure 3 (blank classes). The definition of all concepts should be intuitive and straightforward, except that labels as defined in (1) are mapped as string values to corresponding attributes <guard> and <action> of metaclass Transition.

Fig. 4. EventBroker#dispatchEvents

Fig. 6. StateMachinelnstance#evalGuards

Fig. 2. Diagrams of II(a, 6), A(a, a, 6), Q(a, a) and respective syntax tree construction

In this section we consider the structuring problems imposed by our common example. The first problem is a very complicated graph structure of the flow diagram.

Theorem 2. Every flow diagram can be transformed into an equivalent strongly decomposable (well-formed) flow diagram by node duplication (proof see [13]).

Fig. 6. Two strongly decomposable (well-formed) extended flow graphs equivalent to the flow graph in Fig. | and respective final syntax trees.

Table 1. Example cases for the complexity measuring implementation (n is the number of nodes in the flow graph and V is the complexity measure proposed in the Section 3.3). The bold line (case #3) represents the example from Figure 1. transitions, respectively (as compared with 8 transitions for the first simple case). This shows that the potential advantages of the approach, in terms of graph transformations, could be applied in practice.

generation of the behavior parts of a model; bottom-up approaches that can be don by extending programming environments, and top-down approaches that can be don by extending the modeling language, i.e. UML. This article proposes a combine approach; the top-down approach by applying recursive refinements of activit elements in an activity diagram and the bottom-up approach by defining executors o the lowest level of activities. The reminder of the article is organized as follows: Section 2 gives a brief definition of models. Next, in Section 3 we present an overview of what modeling and programming languages are. In Section 4 we present our approach to how the code can be generated from both structure and behavior models, including an example of modeling a simple calculator application. We use UML2.1 notations and Java in the example. Section 5 is devoted to related work including the ISIS project. Finally, we draw our conclusions in Section 6.

Fig.2. Models and modeling languages

Figure 3 shows the modeling process that is done in an interlaced (weaving) way between the structural and behavior parts. The behavior models are used to strengthen the structural models. For example, an activity entity in an activity diagram could be transformed into an operation in a class diagram. Fig.3. Weaving between structural and behavioral.

Of course, there are many other activity entities (elements). With this transformation rules, a developer has defined implicitly structural models when he models the behavior part.

The table above shows examples of possible translation code of different patterns of activity in Java. Note that the X0, X1, and X2 are objects that can be type of any. The notion of the transformation rules follow patterns as shown in Table 2. We consider that an activity diagram can be seen as a collection of patterns. Here the patterns are used to simplify the code generation from activity diagrams.

Fig.5. Activity diagram of the Calculator To add more code, we need to model the behavior part. In this first iteration, we can model the calculator behavior in a high abstraction level, as for example shown in the following figure. Behavior modeling

The basic rule is very simple (see Table 1, Section 4.1). All activities are transformed into operations of classes. The complete transformation, i.e. including the operation arguments, is presented in Table 2, Section 4.2. Based on the activity and class diagrams above, one possible generated code for the Calculator class (Figure 4) is demonstrated as follows. We now have more lines of code in the Calculator class. We do not, at the moment, think about race condition, for example interpretation of flows outgoing from a fork.

To interpret the activity diagram above, we need explicit labels to indicate whether the flow is control flow or object flow. In the example we use X1, X2, X3, X4, and X5 to indicate the object flows. The following figure shows the structure part of the model as a result of automatic refinement of the activity diagram. Here, the activity diagram (behavior) is used to strengthen the structure.

Fig.8. Sub activity diagram of Compute operation At the same iteration step, we refine manually the behavior part of the model. The refinement is done by defining sub activities of all activities we have defined, for example defining a sub activity of compute, shown in Figure 8. Note that not all activities notations are shown as in add activity.

4.3.3 Third to n™ Iteration The following shows an example of possible generated code (expanded) for compute operation on the Processor class, based on the sub-activity we have defined above. Note that some lines (other operations) are not shown in this code. The more iteration and the deeper refinement of the activity are done the more code that can be obtained. However, the code is not complete enough regarding the arithmetical operations. The reason is there are no mathematical expressions in the model. To amend this situation, we propose notations for basic logical operations, basic arithmetical operations, and basic string manipulation as shown in Table 3.

From this sub activity diagram we can refine the structural model by introduce new classes, as we did in the previous iteration. In this case, the Compute activity is automatically be transformed into Compute class which has operations of add(), sub(), mul(), div(), and error();

activities at implementation levels should be abstracted into models. In this context as long the activities are not mapped into executors then the model is still PIM. See Figure 10 for a more complete behavior model, which includes the arithmetic notations. SysML (UML profile) [14] has defined a parametric to model mathematical expressions. But the expression itself uses text which might be difficult to interpret.

Fig 11. An example of Arctis models Fig 10. More completed behavior model of the Calculator

Fig. 1. A process node represented in the design pattern. The single program code fragments refer to the node’s name and type, a transition declaration and an empty guard. [he foundation of process models is the graph structure of process nodes and tran sitions between them. In the object-oriented program code fragments for the patterr -ach process node is represented by a class definition which implements the given in erface 1processNode (“node class” in the following). This interface defines no methods yut allows to distinguish between node classes and arbitrary other classes type-safely [he class name corresponds to the process node name. Process nodes (except activit 10des, see below) are decorated with meta data denoting their type (one of the enumer ition constants START, END, FORK, JOIN, DECISION, or MERGE).

Fig. 2. Two exemplary activity methods. The first returns a value which is used as an output parameter of this activity node by calling a setter method in the variables facade. The second has an input parameter which is represented by a getter method. First, the actor which is a type that encapsulates business logic of the surrounding ap plication; second, an implementation of the variables interface.

Fig. 3. A guard represented by an expression in the body of a transition method. tions of variable values to allow for decisions. For our pattern we define that these are represented by the method body of transitions methods. The body can therefore contain expressions as defined in section 2.2, but with calls to getter methods of the variables type. For example, the guard expression value1>value2 would be represented in the source code as variables.getValuel () >variable.getValue2(). The according rules apply for interleaving of expressions. An example is shown in figure 3.

Fig. 4. A process model extracted from a pattern in the JWT editor. The example application shown here is discussed in detail in section 5.

Listing 1.1. The variables interface for the load generator example with the according get and set methods