The challenge of Web application development is to adapt and develop methodologies and tools that fulfill the requirement of high quality software and that are accessible to non-technical domain experts (end-user programmers). The computer science discipline of software engineering makes important contributions in advancing from programing to engineering based on solid foundations. These include agile and lean methodologies as well as approaches to place the model and particularly the domain model at the center of the development process and developer's view. There exist many modeling languages in the fields of the Web and software engineering. This paper examines the use of statecharts and their XML encoding, State Charts XML (SCXML), as a language for modeling the behavioral aspects of a reactive system.
The platform-independent and open suite of XML technologies is primarily considered for encoding and manipulating structured data and metadata. Additionally, the XML world offers several XML related technologies for software development and formal system specifications. Our research group Engineering Publishing Technology (EPT) at Technische Universität München leverages XML technology for Web applications. In recent years, we have focused on adapting software engineering modeling approaches to the XML context [BW04], [BST07], [BS08], [PB09], [BDPT10], [BRS12]. Based on our previous and current research, we believe that XML supports evolving trends in the areas of formal methods and modeling languages. Part of our agenda is to base not only the implementation of Web applications but also the development process itself on XML technology. Our rationale is that this approach makes modern software engineering methods more amenable to XML-savvy end-user programmers.
Statecharts were introduced by Harel [HP98] and later taken up by UML to model the behavior of reactive systems. The World Wide Web Consortium (W3C) is developing an encoding language for statecharts called State Chart XML (SCXML) [SCXML14] that is currently in last call. Implementations of SCXML provide generic state-machine based execution environments. In this paper we demonstrate how the behavior of Web applications can be modeled with statecharts at the domain level of abstraction. The SCXML-encoded model can then be used to drive the implementation. We use the principles of domain-driven design [E04] and domain-specific languages [F11] to empower domain experts to develop Web applications.
We illustrate our approach with a case study, a browser game named GameX, presented at Balisage 2014 [SKB14]. GameX belongs to the class of “serious” games and is intended to develop systemic thinking in players. GameX is almost exclusively implemented with XML technologies (XML, XForms, SVG, XSLT, XQuery and XProc). Now we extend the use of XML technologies to modeling behavioral aspects of GameX in a reverse engineering approach.
The remainder of the paper is organized as follows: In section “Domain-driven design in the context of XML technologies”, we introduce our modeling vision in terms of domain-driven design. In section “Statecharts and State Chart XML for modeling Web applications”, we introduce the basic concepts of statecharts and the syntax of State Chart XML. We present the event-driven gameplay of GameX as our use case and demonstrate how to model it with statecharts following the principles of domain-driven design. Specifically, we propose an approach that we call step-by-step modeling using statecharts. Finally, in section “Conclusion and future work”, we draw some conclusions, discuss limitations and raise ideas for future work.
Domain-driven design in the context of XML technologies
Domain-driven design (DDD) is a systematic approach proposed by Eric Evans in his book [E04] of the same name, which envisions a way to work with complex models during the software development lifecycle. The approach addresses complexity that arises from the sophisticated features or the domain. Evans argues the significance of domain modeling as the central focus of software development based on two observations:
First, the importance of the core domain and the domain logic is highlighted as the primary focus of a software project. Second, all system models and even the implementations are defined based on a domain model.
In terms of domain-driven design, our vision is to define models not only in their conventional/traditional sense as a diagram or a visual representation of the (individual) system modules and their intercommunication. We aim also to provide concepts built up in the heads of stakeholders, with terms and relationships that reflect domain insight: a domain model as shown in Figure 1. This figure shows that the domain model is a more abstract view of the system model towards the environment. Eventually, the architecture and the implementation of the final system will closely reflect the domain model. Working from the domain model provides clarity and precision on a high level that guide further steps of conventional modeling and implementation.
The domain model is not a particular diagram; it is the concept that the diagram is intended to deliver. It is not just the knowledge in a domain expert's head; it is an structured and selective abstraction of that knowledge. A diagram can represent and communicate a model [E04].
The transition from conventional models to domain models is beneficial in two ways. On the one hand, the domain model is technology-independent. On the other hand, the domain model uses domain terminology as a shared vocabulary between domain and system experts. This usage pervades the complete development process from modeling to implementation, which significantly increases the benefits of the model. These two aspects are discussed next in detail.
Figure 1: Domain model is more than a class diagram
Technology-independent modeling: The term of technology-independent modeling refers to an approach that is not bound to the actual implementation. Many modeling languages such as ERD and XSD modeling target or depend on particular technologies. To define a truly universal standard model, there might be some initial solutions to handle this issue. For example, the conceptual model based on Unified Foundational Ontology (UFO) can be used, which has no suitable form for being physically implemented [G05], [GW08]. However, it seems to have a considerable shortcoming regarding domain specific modeling, because of its general nature.
Domain-specific modeling: As mentioned before, the approach of domain-driven design is interesting for software developers, especially when the business logic and its terminology are complex. Here, the domain-specific modeling plays a central role in terms of data-structuring. It describes the data and structure of the domain by bundling the element of the structure and their interactions, which are mapped in the respective domains. The domain models make these special constructors ready to be fitted to the domain. This approach of domain-specific modeling has several advantages, namely reduced complexity, easy comprehensibility and support for system design.
Domain-driven design is not bound to a specific technology or a "supporting framework". It is firmly focused on the process of developing good software with object-oriented modelling. Therefore, every language and environment that supports object-oriented-programming is suited for DDD.
Statecharts and State Chart XML for modeling Web applications
In this section we briefly introduce the concepts and semantics of statecharts and the syntax of their encoding language, State Chart XML (SCXML). We present the event-driven gameplay of GameX as our use case. Then, we show how to model this event-driven system using statecharts.
In previous work [BDPT10][BRS12], we have considered domain models in relation to classical data models, using reverse modeling and forward modeling techniques. Using GameX as a case study, we now expand our focus to behavioral aspects, for which statecharts are considered the appropriate modeling technique. We start with a pre-existing conceptual model, namely a UML class diagram that has also been translated into XML Schema, and some use case diagrams [SKB14][K14]. Then we extract from the conceptual model and from the system itself a domain model, as shown in Figure 2. The core part of the domain model is a statechart that uses domain vocabulary (events, conditions, actions) which is defined in a UML class diagram.
Figure 2: Extracting a domain model from an existing system and its conceptual model
Originally, statecharts have been introduced by Harel for modeling the behavioral aspects of so-called reactive systems that need to respond to external signals or events that are generated independently of the system and that may have duration. Event-driven, interactive systems such as GameX can be considered as a special case of reactive systems in that they have a way of making the environment wait and consider new inputs at their own speed, thus giving rise to an event-response cycle. A completely different category of systems are the classical transformational systems that follow the much simpler input-computation-output paradigm.
Modeling the essential features of reactive systems, which are generally concurrent in nature and can be deterministic or nondeterministic, is commonly recognized in software and system engineering communities as difficult but important [BCG88][B89][H93]. A reactive system can be concurrent at three levels: to run in parallel with its environment, to be implemented on distributed hardware and to be described as a set of concurrent processes. When modeling a reactive system, Harel [HP98] recommends to organize the system specification into three views: functional, behavioral, and structural. The functional view focuses on the system functions and information flow. The structural view describes the decomposition of the system into subsystems, modules and objects. At the heart of the specification is the behavioral view, expressed in a statechart, that captures the system behavior over time: the activities, their control and timing and the states and modes of the system.
Statecharts and State Chart XML (SCXML)
As has been mentioned above, SCXML is an XML encoding of statecharts, also incorporating a formal definition of semantics. While SCXML semantics mostly follow Harel statecharts semantics, there are subtle differences [C14]. Since these differences in interpretation are not relevant at the abstract level of modeling the gameplay of GameX, we use Harel statechart diagrams to draw SCXML-encoded statecharts in this paper.
Harel statecharts add several extensions to the basic concepts of
state machines. For example, statecharts may perform actions while
executing transitions between states and while transitioning into or out
of states. Furthermore, transitions may be guarded by conditions. Thus,
transitions will be selected only if an event is raised whose name
matches the '
event' attribute and if the
cond' condition on the transition is
The following figure shows example SCXML code and its corresponding statechart diagram.
Figure 3: A first statechart
<state id="s"> <transition event="e" cond="x==1" target="s1"/> <transition event="e" target="s2"/> <transition event="*" target="s3"/> </state>
Here, the system will transition to
s1 when both event
e occurs and
x is equal to 1, but it will
s2 if event
e occurs and
x is not equal to 1. Finally, it will transition to
s3 if any other event occurs. [W3CSCXML14].
The most powerful concept in Harel statecharts is the notion of hierarchy where compound states may contain nested states. A compound state is a grouping of atomic or other compound states that represents shared behavior, thus avoiding redundancy and enabling overriding and specialization of transitions. Consider the following two equivalent statecharts: The second one has a compound state D consisting of two atomic states A and B. The transitions on event c in the first figure are abstracted into a single transition from the compound state D in the second figure. This clustering of two or more states in a new parent state seems trivial in this example but it is beneficial in large and complex systems. Compound states affect the way that transitions are selected. For example, assume that events d and c are the same in the second figure of the previous example. Here, the handling of Harel statechart differs from that of SCXML to avoid this no determinism. In Harel statecharts "the higher-level transition has priority over the internal transition" [HP98]. However, the SCXML prioritizes the lower-level transition since "the state machine first looks in the most deeply nested active state" [W3CSCXML14].
To illustrate this compound states concept, consider the following two semantically equivalent statecharts given in Examples 1 and 2. The second statechart has a compound state D consisting of two atomic states A and B.
Figure 4: Example 1
<state id="A"> <transition event="c" target="C"/> <transition event="d" target="B"/> </state> <state id="B"> <transition event="c" target="C"/> </state> <state id="C"> <transition event="a" target="A"/> <transition event="b" target="B"/> </state>
Figure 5: Example 2
<state id="D"> <state id="A"> <transition event="d" target="B"/> </state> <state id="B"></state> <transition event="c" target="C"/> </state> <state id="C"> <transition event="a" target="A"/> <transition event="b" target="B"/> </state>
A further powerful concept of Harel statecharts is parallelism. With parallel states a system's module can be decomposed into components. When this module becomes active, all of its components are activated and run simultaneously. Parallel states also describe orthogonality. They reduce the infamous state blowups of traditional state machines.
Graphically, parallel states are separated by dotted lines, als shown in Figure 6.
Figure 6: Example with parallel states
<scxml> <parallel id="Y"> <state id="A" initial="B"> <state id="B"> <transition event="a" target="C"/> </state> <state id="C"> <transition event="b" target="B"/> </state> </state> <state id="D" initial="F"> <state id="F"> <transition event="a" target="E"/> <transition event="b" target="G"/> </state> <state id="E"> <transition event="a" target="G"/> </state> <state id="G"> <transition event="b" target="F"/> </state> </state> </parallel> </scxml>
With this example, we conclude our introduction of the essential concepts of statecharts and SCXML.
GameX as a case study
As mentioned in the previous chapter, we demonstrate our approach to modeling the behavior of a complex reactive system with statecharts and SCXML by modeling the gameplay of GameX. Computer games provide a good case studies that involve interaction between the system and the environment.
The gameplay of GameX is driven by user events and a system clock for the rounds of the game. In this paper, we focus on modeling the behavior of one module of GameX with statecharts, namely the processing of user interface events. Our paper at Balisage 2014 [SKB14] describes how the user events are handled at an architectural and at a technical level. As a reminder, we give a short overview of GameX itself.
Gameplay overview of GameX
GameX provides players with a map of towns and fields. Players administrate their own towns and the surrounding fields to increase the growth rate of town population and the revenue that it generates. Players can construct different types of buildings in their towns such as industrial plants, schools, recreational buildings or environmental facilities. These buildings affect a number of parameters such as industrial value, satisfaction of the population and, ultimately, the revenue (gold) that a town generates. Players can communicate with and fight against each other, to form strategic coalitions or to conquer each other's towns, respectively. GameX challenges players to understand interdependencies and consequences of their actions, and thus developing their systemic thinking skills [SKB14].
At its core, the graphical user interface (GUI) of GameX consists of a two-dimensional partial view of the world that is divided into tiles. Users can select one of two views: The world map and the local map as shown in Figure 7 [SKB14].
Figure 7: World vs. local map
When the player logs into the game after registration, the default settings are loaded. We call this state the initial state. In this state, a new player becomes the mayor of a new town, consequently administrating this town and the surrounding fields to increase the growth rate of the town's population and the revenue that it generates. Throughout the game the player can conquer other towns.
To better understand the concept of the game, it is useful to divide the parameters of the game into two categories. We distinguish between user related parameters and town specific parameters. The user related parameters are the amounts of gold, iron, wood and corn available. The town specific parameters are amount of troops, population and the set of parameters for measuring the progress, which are Industry, Environmental Impact, Knowledge, Satisfaction and Growth Rate.
An important town-specific constraint is that players can construct at most six buildings per town. While the number of buildings per town is limited, their sizes can be grown, though. There are twelve building types to choose from, each belonging to a category: industrial plants, schools, recreational buildings or environmental facilities. The numbers, sizes and types of these buildings determine parameters such as industrial value, satisfaction of population and, ultimately, revenue (gold) that a town will generate.
In addition to the above-mentioned properties of GameX, players have the possibility to communicate with and/or fight against each other, to form strategic coalitions or to conquer each other's towns. GameX challenges players to understand interdependencies and consequences of their actions, thus develops their systemic thinking skills.
The gameplay of GameX is organized into rounds. Rounds finish at discrete points in time, currently every two hours. At the end of each round, the values of the parameters for measuring progress are recalculated.
After this brief overview, we introduce a step-by-step modeling approach to create a statechart and SCXML-encoding for GameX.
Step-by-step modeling using SCXML
In the process of developing a SCXML model in terms of domain-driven design, we propose an approach that we call step-by-step modeling using statecharts.
Based on our experience of modeling GameX with SCXML, we have identified certain steps that one would follow to model any system with SCXML.
Since software systems have many different views and aspects, it is vital to choose the aspect that should be modeled or in other words, to determine the focus of the model. Then, we need to decide which characteristics are important for the model and which ones can be left out (scope of the model).
The next step is to document the system behavior in a clear way and keep this documentation updated until the model is completely done. In this step, we identify the system states and possible transitions and study the system until we get a detailed understanding of all states and transitions.
It is highly recommended to create a Harel statechart for the system before developing the SCXML code. The state diagram provides a clear overview of the system states and transitions and the overall structure of the system. It may be complicated to create a statechart for complex systems which consider a lot of reactions and user inputs. Thus, it may be helpful to use hierarchical and parallel states, because compound states reduce the number of transitions and thus reduce the complexity of the model. The more compact the statechart diagram is, the less effort it will take to develop the SCXML code.
After finalizing the statechart, it can be translated with SCXML.
We recommend to repeat steps 2 through 4 to add newly discovered states and/or transitions, or to document changes in the SCXML code.
A final step would be to run the model with an SCXML engine.
The SCXML model of GameX
In this section, we discuss modeling the case study GameX using SCXML. We present our experience in each step of step-by-step modeling already explained in the previous section.
We focus on the gameplay or the player's perspective of the GameX. Thus, the main characteristics we are concerned with, in terms of the model, are the ways the user interacts with the system. As result, we consider the GameX as a reactive system and thus all possible inputs and outputs must be identified. The inputs are typically player actions on the GUI. The outputs are pairs of the graphical changes and their corresponding changes in the system data. From an architectural perspective, we model the controller in a model-view-controller architecture.
Next, we determine the features that will be included in the model and those that will be left out. For example, we skip messaging module since it does not affect the gameplay or in other words, it is out of our focus. On the other hand, there are features that are included but considered as a black box such as map loading, tiles placing and assigning their coordinates, and game clock. They were not completely skipped since we will refer to them in the model. At the same time, they are not modeled in detail since its internal implementation is out of our scope. Finally, we model the parameter update process as a gray box. We model its inner structure, but without going into details and mathematical terms corresponding to each parameter update.
At the end of this stage, the developer has a good understanding about the aspects of the system that will be modeled and at which level of detail.
After determining the model scope and focus, relevant parts of the system are fully documented. This documentation is based on all available resources of the system such as requirements, system design, user manual, implementation documents and the deployed system itself. Since GameX is already deployed and its documentation is not thoroughly descriptive, we build and write such documentation in detail based on the system's behavior. We run the game and tried many test cases so that we covered all actions and responses of the concerned features in the documentation.
In this step, we build a statechart for the whole system. We reduce the system complexity by using parallel and compound states and exclude game features that cannot be modeled with SCXML. Here we will present modeling of a part of the GUI as an example. This module handles display of and navigation around the map and options of tile transformation. We call this module “screen”.
The UI of a player's town is shown in Figure 8. We name buttons in left and top menu bars by letters from A to I as shown in the figure. Clicking on these buttons correspond to transitions among system states.
Figure 9: The graphical user interface: local view
The landscape view of GameX GUI is shown in Figure 9. We can summarize the following possible actions on this screen:
|Button B: displays a pop up window to choose between the parameter values, all buildings or the troops.|
|Button C: navigates to the player's town center.|
|Button D: changes to world map view.|
|Button E: transforms the tile type to another type, if possible.|
|Button F: no change of the state in this view.|
|Button G: displays a pop up window to choose between the parameter values and the buildings sorted by type.|
|Since they do actions out of the concerned scope, buttons A, H and I are not considered in our analysis.|
Although there are two ways to navigate around the map using the compass or by clicking on tiles, we represent them as a single navigation event because it does not differ in the functionality. However, the player selects one of three types of tiles: either the town center of one of his towns, another players' town center, or a normal tile. We can model this by combining the event with a condition as follows:
|n.1 = navigate [normal tile]|
|n.2 = navigate [tile is another towns‘ center]|
|n.3 = navigate [tile is one of my towns‘ center]|
In the world map view, the following actions are possible:
|Button B: displays a pop up window to choose between the parameter values, all buildings or the troops.|
|Button C: no change of state in this view.|
|Button D: no change of state in this view.|
|Button E: leads us to manage build orders.|
|Button F: switches back to landscape view and centers the screen on the tile that was last selected.|
|Button G: displays a pop up window to choose between the parameter values and the buildings sorted by type.|
GameX consists of various types of tiles. A tile can be the main building of a town or one of seven other types. The tile type determines the possible transformations which needs different amount of time and resources to be accomplished. Thus, we describe all options of the field transformation in the SCXML model. But to keep the general overview of the statechart diagram, we name the event of selecting an option from the tile transformation menu by transf_to_... and do not distinguish between them in the diagram.
The screen module of the GameX system is shown in Figure 10. It consists of the initial state, the state game_over, the state initialize, the landscape_map, the world_map, and the menu transform_field. We have modeled it according to Harel statechart notation.
Figure 10: Statechart representation of the "screen" module
Now, we transform the statechart into an SCXML model. First, we built the data model of the game based on the class diagram, as shown in Figure 11 [SKB14], and observations of the gameplay. The data model consists of three information blocks: player related, town related and map. The player related information includes the user name and the amount of gold, wood, iron and corn the player has. The town related information includes Id, their coordinates of main building, the number of troops and residents, a list of buildings and its level and parameter values (i.e., Industry, Entertainment, Knowledge, Pollution, and Growth). The map or tiles information includes the coordinates of each tile and its type of all tiles in the map. The map provides an overview of all contained objects, such as towns, tiles, armies and orders which can be divided into three classes: OrderTerraform converts a field to a different type. OrderSend sends troops from one place to another and OrderBuild gives an order to build with reference to a town not a player, so the building orders will persist after transfer [SKB14].
Figure 11: Class diagram for GameX
The following code shows the SCXML data model of GameX where
information blocks are nested in the <
tag and binding in initializes state. As a result, the transformation
of statechart into the SCXML model is straightforward but we give an
example of how to model conditions that refer to the data
<datamodel> <data id="towns"/> <data id="users"/> <data id="tiles"/> </datamodel> <state id="initialize"> <onentry> <assign location="towns"> <town tID="123456" mayor="me" coordinates="A5" current_town="yes"> <troops number="0"/> <residents number="100"/> <parameter industry="0" pollution="0" amusement="2" knowledge="0" growth="0"/> <buildings number="0"> <blacksmith level="0"/> <market level="0"/> <sawmill level="0"/> <inn level="0"/> <bathhouse level="0"/> <residence level="0"/> <park level="0"/> <sewerage level="0"/> <filter level="0"/> <library level="0"/> <townhall level="0"/> <laboratory level="0"/> </buildings> </town> <town tID="78910" mayor="notme" coordinates="B8"/> </assign> <assign location="users"> <user name="me"> <gold amount="100"/> <material amount="10"/> <iron amount="2"/> <corn amount="100"/> </user> <user name="others"/> </assign> <assign location="tiles"> <tile name="mainBuilding" tileType="0" coordinates="B8" next_to_town="123456" locked="no"/> <tile name="grass" tileType="1" coordinates="C1" next_to_town="123456" locked="no"/> <tile name="mine" tileType="2" coordinates="C2" next_to_town="123456" locked="no"/> <tile name="cornfield" tileType="3" coordinates="C3" next_to_town="123456" locked="no"/> <tile name="woods" tileType="4" coordinates="C4" next_to_town="123456" locked="no"/> <tile name="woodcutter" tileType="5" coordinates="C5" next_to_town="123456" locked="no"/> <tile name="water" tileType="6" coordinates="C6" next_to_town="123456" locked="no"/> <tile name="fishery" tileType="7" coordinates="C7" next_to_town="123456" locked="no"/> <tile name="selected_Tile" tileType="0" coordinates="$towns/town[@mayor='me']/@coordinates"/> </assign> </onentry> </state>
As an example, we concern the system module landscape_map of a
town. In the
beginning, the landscape map is displayed and centered in the main
building of the player's town, The module starts with the state
s0 and sends the information to the data element
selected_tile. This occurs in the
<onentry> tag and
it assigns the coordinates and tile type. Also, there is no transition
to other states, but rather they are the same for the sub-states of
landscape_map and thus are denoted at the end of the state
declaration. When the menu button E is clicked, the module moves to
s_field and goes to
transform_field. However, it moves to
s_foreign but under the condition that the selected
tile is the main building of the town and the player is not the mayor
of this town and has troops.
<state id="landscape_map" initial="s0"> <history type="shallow" id="history_landscape"> <transition target="s0"/> </history> <state id="s0"> <onentry> <assign location="$tiles/selected_tile/@coordinates" expr="$towns/town[@mayor='me']/@coordinates"/> <assign location="$tiles/selected_tile/@tileType" expr='0'/> </onentry> </state> <state id="s_field"> <transition event="E" target="transform_field"/> </state> <state id="s_foreign"> <transition event="E" cond="$tiles/selected_tile[@tileType] = '0' and $towns/town[@coordinates= '$tiles/selected_tile[@coordinates]']/@mayor !='me' and $towns/town[@current_town='yes']/troops/@number >= 1" target="Tab_Troops"/> </state> <transition event="navigate" cond="$tiles/selected_tile/@tileType >= '1'" target="s_field"/> <transition event="navigate" cond="$tiles/selected_tile/@tileType = '0' and $towns/town[@coordinates= '$tiles/selected_tile/@coordinates']/@mayor='me'" target="s0"/> <transition event="navigate" cond="$tiles/selected_tile/@tileType = '0' and $towns/town[@coordinates= '$tiles/selected_tile/@coordinates']/@mayor !='me'" target="s_foreign"/> <transition event="D" target="world_map"/> </state>
In the navigation transitions, the player can navigate to another
tile on the map (i.e., any of those states). This can be done through
compass or clicking on the tile, which are indistinguishable in the
system model. Since we focus on modeling how navigation changes the
system states and behavior, assigning values to
“tileType” and coordinates and centering the screen in
the selected tile are considered as a block box. However, we
distinguish between three target states for this state transition
based on the type of target tile. The user can navigate to a normal
tile, or a tile which hosts a town' main building, but the reaction is
different if the user is the mayor of this town or not. We represent
this conditional transitions as follows:
<transition event="navigate" cond="$tiles/selected_tile/@tileType >= '1'" target="s_field"/> <transition event="navigate" cond="$tiles/selected_tile/@tileType = '0' and $towns/town[@coordinates= '$tiles/selected_tile/@coordinates']/@mayor='me'" target="s0"/> <transition event="navigate" cond="$tiles/selected_tile/@tileType = '0' and $towns/town[@coordinates= '$tiles/selected_tile/@coordinates']/@mayor !='me'" target="s_foreign"/>
Next, we refer to the data model to check the tile type and if the user is the mayor of the town whose main building is currently selected. At the end, the player can navigate to the world_map view by clicking button D. To model actions triggered from transitions, we consider this event of building a black smith.
<state id="display_buildings"> <transition event="build_blacksmith" cond="$towns/town[@current_town='yes']/buildings/@number <= 6 and $tiles/tile/[@tileType = '2']/@next_to_town = '$towns/town[@current_town='yes']/@tID' and $users/user[@name='me']/gold >= '20'" target="display_buildings"> <send event="start_clock_building"/> <assign location="$users/user[@name='me']/gold" expr="'$users/user[@name='me']/gold'-20" /> </transition> </state>
This transition is only executed if the condition holds (e.g.
amount of gold is more than 20 and number of buildings are less or
equal 6). If so, then the event
triggered and the amount of gold is reduced. In SCXML, this is modeled
tags within the
During this step, we iterated over steps 2 through 4 to add newly discovered states and/or transitions in the model.
The final step in system modeling with SCXML is to run the model with an SCXML engine. Then a set of use cases is selected to verify that the system model depicts the observed system behavior. However, the SCXML is a fairly new technology and there are only few engines that allow us to run SCXML code.
Another indirect way to verify the SCXML model is to implement it in oXygen and construct a statechart by considering only the SCXML code. A comparison between this statechart and the statechart constructed in Step 3 of this process will verify the model's correctness.
Since we model an already deployed system, we found that constructing statechart model will facilitate identifying parts that are designed inefficiently, such as duplicated data elements or states. Therefore, it is recommended that a statechart or SCXML model is developed during the design phase of the system. These models will help later in the verification phase by running use cases on the model and the implemented system and compare results.
Conclusion and future work
Using State Chart XML as a modeling technique in Web engineering is recommended to work with complex models during the software development process. Also, modeling already deployed systems provides deeper understanding about their behavior.
In this Paper, we proposed a step-by-step modeling approach to create a SCXML for GameX, as a case study.
The goal is that all stakeholders working within complex software projects would be involved in the development process. Indeed, they are involved in different degrees but with a common goal to have collaboration among all domain and software experts.
Based on our research, it's a good general practice to construct a statechart or, even better, a SCXML model of a system in the beginning phase of its development cycle, as well as after the system is deployed. Furthermore, the system behavior could be observed and used in the reification process to extend the model. Both approaches, modeling a system before and after, can be used for verification by running the current system and comparing the result.
However, the SCXML is a fairly new technology, which comes with some challenges when using it. For example, there is only few professional development environments that allow building and running such models. There is an extension for oXygen that supports editing SCXML documents with a processor that runs the model for completeness and consistency would facilitate the usage of SCXML models. We plan to investigate other SCXML tools in future work.
[B89] Gérard Berry. Real time programming: Special purpose or general purpose languages. [Research Report] RR-1065, 1989.
[BCG88] Gérard Berry; Philippe Couronné; Georges Gonthier. Synchronous programming of reactive systems: an introduction to ESTEREL. Proceedings of the first Franco-Japanese Symposium on Programming of future generation computers. Elsevier Science Publishers B. V. Amsterdam, The Netherlands, The Netherlands ©1988.
[BDPT10] Anne Brüggemann-Klein; Tamer Demirel; Dennis Pagano; Andreas Tai. Reverse Modeling for Domain-Driven Engineering of Publishing Technology. Balisage: The Markup Conference 2010. Available from http://www.balisage.net/Proceedings/vol5/html/Bruggemann-Klein01/BalisageVol5-Bruggemann-Klein01.html. doi:https://doi.org/10.4242/BalisageVol5.Bruggemann-Klein01.
[BRS12] Anne Brüggemann-Klein; Jose Tomas Robles Hahn; Marouane Sayih. Leveraging XML Technology for Web Applications. Balisage: The Markup Conference 2012. Available from http://www.balisage.net/Proceedings/vol8/html/Bruggemann-Klein01/BalisageVol8-Bruggemann-Klein01.html. doi:https://doi.org/10.4242/BalisageVol8.Bruggemann-Klein01.
[BS08] Anne Brüggemann-Klein; Lorenz Singer. Hypertext Links and Relationships in XML Databases. Balisage: The Markup Conference 2008. Available from http://www.balisage.net/Proceedings/vol1/html/Bruggemann-Klein01/BalisageVol1-Bruggemann-Klein01.html. doi:https://doi.org/10.4242/BalisageVol1.Bruggemann-Klein01.
[BST07] Anne Brüggemann-Klein; Thomas Schöpf; Karlheinz Toni. Principles, Patterns and Procedures of XML Schema Design — Reporting from the XBlog Project. Proceedings of Extreme Markup Languages (2007). Available from http://conferences.idealliance.org/extreme/html/2007/BruggemannKlein01/EML2007BruggemannKlein01.html.
[BW04] Anne Brüggemann-Klein, Derick Wood. Balanced Context-Free Grammars, Hedge Grammars and Pushdown Caterpillar Automata. Proceedings of Extreme Markup Languages (2004). Available from http://conferences.idealliance.org/extreme/html/2004/Bruggemann-klein01/EML2004Bruggemann-Klein01.xml.
[C14] Zlatina Cheva. Statecharts for Modeling XML-Applications. Master Thesis, TU München, 2014.
[D14] Lyuben Dimitrov. Exploring XML Technology for Model-based User Interfaces. Master Thesis, TU München, 2014.
[E04] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.
[F11] Martin Fowler. Domain-Specific Languages. Addison-Wesley, 2011.
[G05] Giancarlo Guizzardi. Ontological Foundations for Structural Conceptual Models. Dissertation University of Twente, 2005.
[GW08] Giancarlo Guizzardi; Gerd Wagner. What's in a Relationship: An Ontological Analysis. 27th International Conference on Conceptual Modeling Barcelona, Spain (2008). Available from http://www.inf.ufes.br/~gguizzardi/ER2008-CR-GuizzardiWagner.pdf. doi:https://doi.org/10.1007/978-3-540-87877-3_8.
[HP98] David Harel; Michal Politi. Modeling Reactive Systems with Statecharts: The STATEMATE Approach. McGraw-Hill, 1998.
[K14] Martin Kuhn. Lerning Systemic Thinking: Design and Implementation of a Browser Game based on XML Technology. Master Thesis, TU München, 2014.
[MZD08] Christine Mayr; Uwe Zdun; Schahram Dustdar. Reusable Architectural Decision Model for Model and Metadata Repositories. 7th International Symposium, FMCO 2008, Sophia Antipolis, France, October 21-23, 2008, Revised Lectures 2009, Springer Berlin, Heidelberg. doi:https://doi.org/10.1007/978-3-642-04167-9_1.
[PB09] Dennis Pagano; Anne Brüggemann-Klein. Engineering Document Applications — From UML Models to XML Schemas. Balisage: The Markup Conference 2009. Available from http://www.balisage.net/Proceedings/vol3/html/Bruggemann-Klein01/BalisageVol3-Bruggemann-Klein01.html. doi:https://doi.org/10.4242/BalisageVol3.Bruggemann-Klein01.
[RBBG06] Erkuden Rios; Teodora Bozheva; Aitor Bediaga; Nathalie Guilloreau. MDD Maturity Model: A Roadmap for Introducing Model-Driven Development. Proceeding: ECMDA-FA'06 Proceedings of the Second European conference on Model Driven Architecture: Foundations and Applications 2006, Springer-Verlag Berlin, Heidelberg. doi:https://doi.org/10.1007/11787044_7.
[SKB14] Marouane Sayih; Martin Kuhn; Anne Brüggemann-Klein. GameX — Event-Based Programming with XML Technology. Balisage: The Markup Conference 2014. Available from http://www.balisage.net/Proceedings/vol13/html/Bruggemann-Klein01/BalisageVol13-Bruggemann-Klein01.html. doi:https://doi.org/10.4242/BalisageVol13.Bruggemann-Klein01.