Brüggemann-Klein, Anne, Marouane Sayih and Zlatina Keskivov. “Statecharts and State Chart XML as a Modeling Technique in Web Engineering.” Presented at Balisage: The Markup Conference 2015, Washington, DC, August 11 - 14, 2015. In Proceedings of Balisage: The Markup Conference 2015. Balisage Series on Markup Technologies, vol. 15 (2015). https://doi.org/10.4242/BalisageVol15.Sayih01.
Balisage: The Markup Conference 2015 August 11 - 14, 2015
Balisage Paper: Statecharts and State Chart XML as a Modeling Technique in Web
Engineering
Domain-driven design is a methodology that attempts to improve
software development by focusing on domain terminology and
functionality. It encourages collaboration between technical and domain
experts by making an explicit technology-independent model that is
iteratively refined. Many modeling languages exist. 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 use case presented in this paper is GameX, an interactive
browser-based game where players operate on a map of towns and fields.
We demonstrate that SCXML-encoded statecharts can be used to describe
complex models during the software development process. Not only can
these models be used to drive new development, but modeling already
deployed systems in this way can provide a deeper understanding of their
behavior.
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
fulfilled.
The following figure shows example SCXML code and its corresponding
statechart diagram.
Here, the system will transition to s1 when both event
e occurs and x is equal to 1, but it will
transition to 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.
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.
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.
Step 1
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).
Step 2
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.
Step 3
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.
Step 4
After finalizing the statechart, it can be translated with
SCXML.
Iteration:
We recommend to repeat steps 2 through 4 to add newly
discovered states and/or transitions, or to document changes in
the SCXML code.
Step 5
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.
Step 1
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.
Step 2
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.
Step 3
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”.
Figure 8: Naming buttons in the menu bars
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
Step 4
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 <datamodel>
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
model.
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
the state 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.
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:
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.
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 start_clock_building is
triggered and the amount of gold is reduced. In SCXML, this is modeled
with the <send> and <assign>
tags within the <transition> markup.
During this step, we iterated over steps 2 through 4 to add newly
discovered states and/or transitions in the model.
Step 5
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[1] 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.
Recommendation
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.
References
[B89] Gérard Berry. Real time
programming: Special purpose or general purpose languages.
[Research Report] RR-1065, 1989.
[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.
[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.
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.
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.
