Model Driven Development Approaches:
Comparison and Opportunities
Nikola Tanković
Superius d.o.o., Ćirilometodske družbe 1
HR-52100 Pula, Croatia
Email: nikola.tankovic@superius.hr
Abstract—Application modeling is gaining its share as the next
generation software development methodology. Model Driven
Development (MDD) approaches use abstract models of software
systems to yield concrete implementations. This process can be
achieved in two fundamentally different ways: by generating
end artifacts like programing code and database schemas, or
by applying model interpretation in which the models itself are
interpreted like the programming code. Regardless of approach
used, MDD still needs to surpass certain challenges to gain
further appreciation among community. Models are still very
difficult to understand and manage, with end results still being
limited compared to manual programmed solutions. Therefore,
software modeling should position more towards end-user market
targeting simpler solutions. Object-Process Methodology (OPM)
is an adequate candidate yielding results in that direction. This
paper will assess the positive characteristics of OPM as a software
modeling tool, and briefly propose some further characteristics
that could make software modeling more user friendly.
Index Terms—Model Driven Development, Generative MDD,
Interpretive MDD, Object Process Methodology
I. I NTRODUCTION
Software development can be described as a complex
process which involves knowledge of specific technologies:
programming languages, development environments, coding
paradigms like object-oriented or functional programming and
other information exchange standards for integration with
other software services. Software developer requires education
and experience with different design patterns and how to
apply them in solving domain problems; he is faced with a
challenge of creating bridges between two opposite worlds
of surrounding reality and IT solutions. Main tool for this
job was through many years usage of specific programming
languages by mastering their usually complex syntax and
semantics. These languages, with each step of their evolution
became more abstract and simplified so they could easily
undertake more complex tasks. Through that evolution many
programming “idioms” remained in use, they are repeated
across different phases of application development together
with a set of many written and unwritten rules of good
programming.
The problem with third and fourth generation programming
languages is that they fail to provide easier representation of
business or requirements rules because they are still designed
for describing algorithmic and technical lower level computer
commands. E.g. the structural requirement “Customer has
many points of sale” must be achieved in several places:
database layer, domain-logic layer, user interface layer, etc.
Expressing the problem domain in such languages can be very
verbose and hard to maintain because statements like conditional branches and loops are not well suited for describing
domain problems. The need for further abstraction arose, but
targeting domain problems, not execution commands. Results
were an introduction of software models - an abstract representation of problems at hand. Model is a form of description
which is closer to domain experts then programmers. This
way, domain experts can describe concepts and relationships
in a visual and more intuitive form which makes software
development oriented at solving domain problems rather then
dealing with programming idioms.
In an idealistic situation, domain problem could be described using plain native language or such a model and modeling tool that is understandable and self-describing. The goal
of software modeling should be creation of meta-models and
models that are closer to end-users and domain problems rather
than to programmers and programming language specifics.
Unfortunately, due to high level of complexity and technical
specialties that both software and hardware systems posses,
the solution of translation between such higher level models
and classical programming code is even more complex.
A. Modeling Characteristics
Using models in software development is not a warranty for
achieving better results. There are many modeling solutions
that fail to provide effective development. For a modeling
approach to be useful and effective, there are certain desirable
characteristics to mention:
•
•
•
abstraction - the most important part of any model is
the ability to reduce complexity by hiding or removing
unnecessary details irrelevant for a given viewpoint,
understandability - clear representation of model by
using appropriate form. High quality models in a form
carefully chosen provide substantial reduction in effort
for understanding. Just like classical programming code
with its syntactical details which demand significant intellectual effort, models with inadequate notation, syntax
or representation can require similar effort, despite the
abstraction;
models should be inexpensive - meaning that to achieve
results they require less time and financial resources.
Fig. 1.
Comparison of Iterative and Generative MMD environments
Providing an effective solution means to choose an adequate level of abstraction to yield simplicity but also keeping
expressivity within desirable levels. Too much abstraction
can produce solutions with inadequate flexibility. On other
hand, less abstract solutions can be very hard to understand
and manage, but quite powerful and flexible. The key is in
choosing right characteristics for each modeling task. Certain
solutions also enable custom definition of meta-models, thus
managing model abstraction and complexity levels, but those
require more effort to master.
only that they provide modeling capabilities, but also finetunning of the model translation towards end result. This is
especially useful in modeling more complex solutions, but
managing multiple models for same problem can be somewhat cumbersome. Both model and transformation rules are
instances of their appropriate meta-models which are fixed and
different across different vendors. Some generative solutions
like MetaEdit+1 also provide capabilities to define these metamodels.
A typical generative MDD workflow can be represented
with several steps from design to result:
1) Define or use existing meta-model for model and transformation rules.
2) Create a model using meta-model.
3) Create or use existing transformation rules.
4) Make other necessary artifact templates (various code
templates).
5) Start code generation and deployment.
A. Standards
B. Modeling Approaches
There are two “schools” or different ways for achieving
desired modeling results. First approach advocate transformation from high-level models to lower level artifacts like
programming code, database schemas or configuration files;
where second approach implies implementation of an execution engines capable of model interpretation at run-time.
Former solutions are referred as Generative MDD, and latter
as Interpretative MDD.
Fig.1 displays the main difference between running environments with interpretive and generative MDD. In Interpretive
MDD case, on the left, modeling and runtime environments
are the same, unlike in generative case where all three environments differ. Because of the same modeling and runtime environment, interpretive models are most accurate in
producing end results, where in generative approach end
results can differ.
Both approaches will be described in following two sections
together with their key representatives, and positive and negative sides. Fourth section will describe a holistic approach to
modeling called Object Process Methodology, and fifth section
will bring the challenges that modeling solutions are facing
together with suggestions that could possibly yield positive
progress in tackling these challenges.
II. G ENERATIVE MDD
Generative MDD endorses the idea that models should be
used only to describe domain problems, and that the results
should be achieved with generated programming code, which
can be, if necessary, manually tailored further. Modeling environment is completely separated from execution environment.
Generative solutions tend to generate applications by using
many different models as input, and some of these models
are also used to specify transformations between models and
generated end-result. That is why generated solutions are
considered to have a second degree of freedom, because not
MDA initiative2 , launched by the OMG 3 group in 2001, is
de facto a standard in this approach. MDA defines functionality using appropriate domain-specific language (DSL) which is
used to compose a platform-independent model (PIM). PIM is
platform agnostic and concentrates only at describing domain
problem which should make it easy to understand and manage
with end-users during analysis phase. It is often described
using UML, and typically object-oriented with behavior additionally expressed mostly in state charts. PIM is further
transformed into many platform-specific models (PSM) which
are tailored for specific platforms and technologies on which
the final solution will run onto.
In MDA, models are the main artifacts or “ingredients”
integrated into the development process through the chain of
transformations starting from PIM through many PSM’s to
final generated programming code and artifacts. To enable this,
the MDA requires models to be expressed in a MOF-based
language [1]. MOF stands for Meta-Object Facility, an OMG’s
specification to define universal meta-model for describing different modeling languages. This specification guarantees that
despite having different vendor tools, all models can be stored
in a MOF-compliant repository, parsed and transformed by
MOF-compliant tools, and transported over a network in XMI
standard4 . This does not constrain the types of models you
can use. MOF-based languages are used to model application
structure, behavior (in many different ways), and data. UML
language applied in MDA is a good example of MOF-based
modeling language, but there are also other to choose from.
Fig.2 displays the main concept behind MOF: its four layers
of abstraction. The MOF specification offers an arrangement
1 Available
at http://www.metacase.com/
Driven Architecture, available at http://www.omg.org/mda
3 OMG is a open-membership computer industry specifications consortium,
founded in 1989 by 11 companies including Hewlett-Packard, IBM, Sun
Microsystems and Apple Computer, http://www.omg.com
4 OMG XMI Specification http://www.omg.org/spec/XMI
2 Model
UML is often criticized to be more complex than needed,
and still as such it cannot satisfy the verbosity that can
be expressed with third generation languages so there is
always some uncertainty on the code generation results.
MDA is the most popular representative of the Generative
MDD principle, and is actively being developed to solve
mentioned issues. MDA targets complex systems and it is
flexible to adapt to many technologies, which comes with a
fee: having high level of complexity.
There are many proprietary solutions to application composing using graphical interfaces that do not conform to the
principles of MDA specification, but they have provided custom solutions. These include: Wawemaker6 , Caspio7 , Iceberg8 ,
Ironspeed9 , Antenna AMP Platform10 and Omnibuilder11 .
These solutions are quite easier than MDA principles in
modeling and usage. They rely on generation of standard
SQL databases and classical programming code but within
a set of in front defined capabilities. Most of them target
web application generation, and some also concentrate on
building mobile applications. The problem remains in their
background so modeling is coupled with terms specific to
relational databases and user interface specifics, which targets
them at narrow audience of software developers.
•
Fig. 2.
MOF layers of abstraction
of all models in three levels: M1 is the level that holds
the model elements for particular domain; such element is
noted as “Creator”. Schema definition languages reside on
layer M2 - a metadata meta-model; can be considered as
“model of a particular modeling system”. The top-most level
M3 contains universal modeling languages in which modeling
systems are specified. For metadata instances that describe real
word (information) objects, e.g., “Leonardo DaVinci”, MOF
introduces the M0 level. Except from the M3 level where the
model is defined reflexively, there are instance-of relationships
placed between the elements of a model on one level and the
elements of the model on the level above: a metadata instance
(M0) is an instance of a metadata model (M1), which is an
instance of a metadata meta-model (M2), which again is an
instance of a metadata meta-meta-model (M3).
Currently OMG is working on the QVT5 (Query, Views,
Transformations) specification to support this idea. In other
words, QVT allows the transformations performed by vendors
between PIM, PSM and code to be standardized. This solves
one greater problem in MDD initiative: specific vendor lockin. By using QVT specifications, user can incorporate different
tools in single process.
OMG standardization efforts are much appreciated, but the
architecture and modeling approach itself has some concerns
that should be addressed:
• platform-independent models are very complicated to
understand and require specialized personnel with high
level of expertise;
• once developed, further adjustments are hard to achieve
due to code-generation nature; once PIM is transformed into implementation artifacts (e.g. executable
code, database schema) in an automated step, it is later
quite difficult to maintain compatibility as system evolves
[2] - a more lightweight solution is needed which is more
flexible to changes
• although specifications exist, specific MDA vendors are
reluctant to engineer compatible co-operable tools which
could be a great obstacle for choosing MDA approach;
5 OMG
QVT Specification http://www.omg.org/spec/QVT/1.0
B. Rationale
Generative approaches often lead to faster execution because
they translate abstract models to optimal target candidate
specific for the task at hand. E.g. BPEL12 can be chosen for
process execution, or SQL for query execution. In contrast,
interpreted approaches tend to use their own data storage space
which is rather universal, non optimized. Although, this can
be compensated by choosing modern solutions like NoSQL13
storage in which a schema can be adapted dynamically in runtime, or can even not be needed at all [3], [4].
Generative MDD is more appropriate for deployment which
require protection of intellectual property, because once you
define your model and transformations to produce end-results,
these results can be delivered without the ability for modeling
solution being exposed. In interpretive MDD, final deployment
also includes installation of executing engines with models for
interpretation. This makes them exposed so they must seek
another way of intellectual protection.
The downside of generative approach is the difficulty to
extract model back from generated code to continue developing through model. Solutions that fail to provide round6 Available
at http://www.wavemaker.com
at http://www.caspio.com
8 Available at http://www.geticeberg.com
9 Available at http://www.ironspeed.com
10 Available at http://www.antennasoftware.com
11 Available at http://www.omnibuilder.com
12 Business Process Execution Language is a standard executable language
for specifying actions within business processes with web services. Available
at http://www.oasis-open.org/committees/tc home.php?wg abbrev=wsbpel
13 NoSQL stands for database management system solutions that differ from
classic relational database systems. These data stores may not require fixed
table schemas, they usually avoid costly join operations, and typically scale
horizontally. They are also known as structured storage.
7 Available
trip engineering are considered almost useless, because once
model is transformed, it is often abandoned even for documentation purposes. Other solutions in which models are
expressive enough and code generation fast enough do not
require manual corrections of the programming code. These
solutions are sometimes referred with term complete code
generation. Solutions which are not complete, are rarely used.
With complete code generation, there is rarely need to examine
or modify the generated program, just like there is rarely
a need to examine or modify compiled machine code from
programming languages.
executing engines for specific platform, but using portable
technologies like Java can leverage this problem.
The end verdict between generative and iterative solutions
rely on specific needs. Modern solutions tend towards hybrid
approaches [8] with generation and interpretation techniques
integrated and combined. This can be achieved by either
improving the interpreters with partial code generation or
by improving the generators in executing speed so that endartifacts can be held in main memory and generated on request.
III. I NTERPRETIVE MDD
Comparing Interpretive MDD with MDA approach, it can be
observed as a set of PIM models which are directly interpreted
instead of translated further to PSM’s and source code. There
is no additional executing language, the model itself is the
execution language. A well known representative of this MDD
group is Executable UML [5]. In general, a model compiler
can compile several executable UML models, each capturing
a single cross-cutting concern to yield the running system.
In this sense, executable UML makes use of the concepts in
aspect-oriented programming by having specific UML models
each describing certain aspect [6]. Some approaches also tend
to provide a single model describing whole application like
Open Process Graph [7]. OPG is a general purpose executable
graph model that incorporates every aspect of an application,
including process, user interface, and database in single graph
structure. No coding or database design is required to handle
any part of application. Interpretive MDD principles are being
met because there is no code generated since the graph itself
is treated as the code. Instead, an server-side engine interprets
the graph alongside user executing the application online.
OPG model includes several standard paradigms in classical
development:
• object-oriented paradigm: classes and methods,
• relational database aspects: tables, columns, joins, foreign
keys, data merges and splits,
• and common interface elements like text labels, dropdown menus, etc.,
None of these elements get transformed into other implementation artifacts; instead, they are stored in an objectoriented database and processed on user request.
The key advantage of Interpretive MDD is the ability for
changes to be immediately effective and visible. Since executing engine interprets model one part at a time, system can
be adapted immediately. Also, new solutions can be deployed
very quickly with just an simple installation of executing
engine, or in case of SaaS14 solutions, just by loading a new
model.
Interpretive approach is often criticized for being more
platform specific [2], because it is considered easier to implement additional generators in Generative MDD then whole
This section introduces a different kind of modeling
methodology called Object-Process Methodology (OPM) [9]
together with a simple assessment of different positive aspects
which are introduced with OPM and their possible application
in field of software modeling. OPM has been applied to
modeling generic web applications [10], as well as to modeling
data-driven web and mobile applications [4]. Empirical results
from tests conducted software modeling students [11] also
suggest that OPM is more suitable than UML for modeling
software applications, especially dynamic aspects.
OPM is an universal modeling approach which exposes
objects and processes as two main and equally important
entities for describing structure and behavior. It is a reflective
modeling language with capability to specify system under
study using a single model in uniform way. It was proven
as a robust modeling methodology and its interdisciplinary
nature makes it capable for handling wide range of domain
problems. It simultaneously provides structural design using
stateful objects, as well as the behavioral design of these
objects - processes. OPM has a model representation also in
simple English language called OPL which is fully equivalent
to graphical representation. OPL helps some non-technical
consumers by making parts of models easier to understand
and manage.
OPM describes system by using Objects - things in existence, and Processes, which transform objects states. Objects
and processes have equal importance in defining complete
model. Further, it declares five possible relationships between
objects and processes, they will be reviewed on exemplary
business process of ordering products in logistics domain:
• Effect - process can affect object, e.g., “Ordering changes
stock size”,
• Result - process can yield object, e.g., “Ordering creates
order document”,
• Consumption - process can consume object, e.g., “Transportation consumes resources”,
• Agent - process is handled by object, e.g., “Ordering is
handled by sales representative”,
• Instrument - process can require object, e.g., “Ordering
requires product catalog”,
Relationships connecting objects also exists defining structural relationships or static properties of system. To describe
them better, they will be reviewed on the domain of automobile
industry:
14 Software as a service or SaaS is a software delivery model in which
software and its associated data are hosted centrally and accessed by users
using a thin client, normally a web browser.
IV. OPM M ETHODOLOGY
Aggregation (participation), e.g., “Car consists of engine”,
• Exhibition (characterization), e.g., “Car exhibits make,
model and year”,
• Generalization (specialization), e.g., “SUV is a car”,
• Classification (instantiation), e.g., “Toyota Corolla 09 is
a type of car”,
• Unidirectional tagged structural relation, e.g., “Factory
is the creator of car”,
• Bidirectional tagged structural relation, e.g., “Car cylinders are connected”.
To provide process orchestration, with the goal of describing
the dynamics of a system, links between processes also exist,
called events: Agent - event when process is triggered by
user, State change - event triggered by object changing state,
General event - additional custom specified events, Invocation
- ability for a process to trigger other processes.
These are most important OPM entities and links that make
elementary building blocks. Full OPM ontology is available at
[12].
There are several reasons why OPM is a good candidate for
modeling software applications:
1) application can be modeled using only a single model;
having multiple models can introduce confusion and
unnecessary redundancy,
2) it is reflective, has the ability to describe itself, meaning
same execution engines can be used on different levels of
abstraction; this enable changing the model as an integral
part of end-application, something not many modeling
environments can provide;
3) its zooming capabilities provide easier way to manage
several levels of detail, thus user can handle large models
quite efficiently,
4) it combines structure with behavior providing better
understanding of modeled system,
5) has representation in both lingual and graphical form.
In following section, those capabilities will be assessed in
solving some of fundamental modeling issues: complexity,
complicated modeling language and inadequate representational form.
•
V. M ODELING CHALLENGES
There are quite a few problems that modern software
modeling is facing. Despite its ability to significantly shorten
development time and costs, there are some problems that are
preventing the modeling tools from breaking into wider usage.
A. Modeling complexity
Models should have their greatest value for people who
cannot program, but unfortunately this is not the case. They
are simpler to understand than programming code, not because
they are more expressive, but because they simplify things.
For a model to completely specify an useful application that
meets users’ expectations, it would mean too much detail and
complexity for an average user to understand. This results in
difficulties with modeling and yields additional education.
(a) OPM diagram zoom-ed out
(b) OPM diagram zoom-ed in
Fig. 3.
Sample OPM diagrams
To help leverage this model flaw, OPM introduces several mechanisms to handle complexity efficient. Rather than
introducing a separate model for each system aspect, OPM
handles complexity within single model through the usage
of abstracting-refining mechanisms. These enable viewing the
modeled system at various levels of detail and it is achieved
by zooming in and out of diagrams - folding and unfolding
additional details. This enables having a detailed model while
maintaining “big picture” view. Fig.4 reveals a sample OPM
diagrams in both states: overview of models’ big picture is displayed in Fig.3a, followed by Fig.3b which displays diagram
with “ePaper System” process “zoomed-in” by introducing
new objects and processes which can be correlated with toplevel diagram.
This kind of approach to modeling enables easier complexity management than classical UML approaches, because it
allows modeling from any level of detail working your way
up or down, or slowly building on several levels of detail
in parallel with gathering facts of system at study. This kind
of modeling approach resembles real life scenarios, where
TABLE I
S OME OF AVAILABLE MDD T OOLS
classical linear “top-down” or “bottom-up” approaches are
unnatural, thus inefficient.
Product
B. Modeling language
Generative approach
Modeling language is an artificial technical language used to
specify knowledge and information about systems or processes
in consistent and structural way following a set of rules defined
by meta-model specification. Certain modeling tools allow
meta-models to be customized, which makes modeling approach called meta-modeling [13]. Expressiveness and nature
of modeling language is a direct outcome of its meta-model.
Finding an adequate modeling language, or meta-model for
a specific modeling domain is the key to easier and natural
modeling that requires less symbols to define a system. OPM
methodology uses a single common meta-model which can
also be defined by OPM itself. This is why OPM is called
reflective: it is complete and expressive enough to define
own symbols using nothing but its own symbols. With a
reflective modeling tool, the classical meaning of meta-model
is quite different because the same meta-model can be the
very part of model itself [14], meaning that there is no need
for separate meta-models to define systems at hand. Users are
only faced with a single modeling tool and consistent set of
symbols from OPM notation. A modeling language that is
complete, comprehensive and expressive enough to describe
itself, promises enough expressiveness to model almost any
system [12].
Another important aspect of modeling language is its representational form. It can be graphical or textual. Graphical
modeling languages use graphical diagrams with elements
represented as named symbols together with lines connecting these symbols representing relationships or constraints
between them. Textual modeling languages use standardized
keywords arranged by specified grammars making them computer interpretable. Despite the adage “A picture is worth a
thousand words”, research has shown that graphical languages
are not inherently superior to textual languages [15] and that
both types of languages have their benefits. Indeed, textual
language greatly enhances our ability to understand systems
and communicate our understanding with others. Therefore
many programming modeling languages use natural English
language as starting base.
Authors of OPM methodology used the benefits of the
textual modeling language and created both equivalent forms
of languages: Object Process Diagram as graphical language,
and a complete textual counterpart of the graphic language
called Object Process Language (OPL). These two forms are
completely equivalent, and automatic translation between them
is standard part of OPM tools. This way, OPM models can be
comprehended by non-technical personnel more easier.
RUX Tool
WebRatio
WebML
BPMN
Blue AGE
iMo
CodeFluent Entities
Care Technologies Tools
EMF
OpenEDGE
GMF
AndroMDA
PathMATE
IBM Rational Rhapsody
iQgen
OpenMDX
smartGENERATOR
Mendix
MetaEdit+
C. Modeling forms for static and dynamic aspects
The process of modeling involves manual input of desired
model using desired modeling tool and language. The most
common way of defining the model among analyzed tools
Url
http://www.homeria.com/rux-tool
http://www.webratio.com
http://www.webml.org
http://www.bpmn.org
http://www.bluage.com
http://www.my-imo.com
http://www.codefluententities.com
http://www.care-t.com
http://www.eclipse.org/modeling/emf
http://web.progress.com
http://www.eclipse.org/modeling/gmp
http://www.andromda.org
http://www.pathfindermda.com
http:/ibm.com/software/awdtools/rhapsody
http://www.innoq.com/iqgen
http://www.openmdx.org
http://www.bitplan.com
http://www.mendix.com
http://www.metacase.com
Interpretive approach
AlphaSimple
Executable UML - fUML
Alf
Leonardi
http://alphasimple.com
http://www.omg.org/spec/FUML
http://www.omg.org/spec/ALF/Current
http://www.leonardi-free.org/fr
Hybrid approach
Abstract Solutions Tools
Bridge Point
OOA Tool
http://www.kc.com/PRODUCTS
http://www.mentor.com/products/sm
http://ooatool.com/OOATool.html
displayed in Table I includes drawing and connecting modeling symbols on canvas, together with providing names for
relationships and objects, as well as choosing some parameters
(e.g. cardinality) from in-front defined set of properties. The
problem with this approach is that it requires acquaintance
with objects defined in meta-model, as well with their meaning
and visual or textual representation. Further, semantic value
of elements is also important to define the model behavior
and structure. These characteristics make modeling process
an almost impossible task for average end-user, targeting only
domain experts that are educated for using these appropriate
tools.
MDD is in need for better forms of model input. Some
solutions go as far as extracting models from pencil sketches
[16]. Main idea is to enhance the process of modeling with
instruments that end-user is familiar with, based on more appropriate metaphors. One solution could be exposing domain
objects with well-known common user interface elements like
text input boxes, drop down menus, elements that end-user
is familiar with. Similar principle used in Domain Driven
Development methodology is called Naked Objects [17]. The
philosophy behind Naked Objects is automatic interface gen-
(b) OPM graphical form
(a) User interface as modeling form
(c) OPM textutal form
Fig. 4.
Different model representations for modeled object
eration by extracting information from object-oriented classes
that define domain objects. In [4] an automatic interface
generation from OPM model has been achieved which can be
seen as similar approach to Naked Objects, but done in MDD
environment. What should be done further is to invert this
principle in a sense that end-user should define user interface
of certain domain object yielding an automatic creation of
OPM model defining this object. This standardized interface
elements would enable a far better metaphor for domain
objects then symbols from any kind of modeling tool. Fig.4
explains this approach on a set of isomorphic representations
of exemplary object called “Tviit” used to transfer messages:
Fig.4a shows interface elements; same object in form of OPM
diagram is displayed in Fig.4b, and textual OPM form is
visible on Fig.4c.
Inverse Naked Objects principle covers static modeling of
a system. In OPM words, it defines Objects together with
structural links connecting them. For modeling dynamic aspects, another approach is required. To avoid classical process
modeling like in UML, BPMN15 , or even OPM, which all
use graphical symbols and relationships, a more user friendly
approach is necessary. Such approach is observed in PbE, Programming by Example [18], [19], principle which emphasizes
programming a software system in its own user interface, or in
this example, by interacting with previously placed interface
objects. In PbE, user writes a program by giving an example
of what the program should do; the system remembers the
sequence of actions, and can perform it again. Succinctly,
programming by example is telling the system “Do What I
Did”. This principle can be used to define OPM processes
in more understandable way, with underlying OPM model
composed in background automatically.
15 Business Process Model and Notation, OMG Standard for modeling
business processes. Available at http://www.bpmn.org/
16 CBSE is branch of software engineering concentrated at on separation of
concert introduced with components.
D. Solving complex problems
PbE and Naked Object principle are much easier to comprehend for end-user but they are difficult to model complicated
applications with. MDA targeted complicated and detailed
modeling with a goal to cover almost every use case, but
paying a high price for it: losing average user as target
market. To make our proposal applicable for solving more
complex solutions, a third principle is also needed: Component
Based Modeling [20] based on principles of Component Based
Software Engineering16 . It is founded on a paradigm common
to all engineering practices: complex systems can be obtained
by assembling simpler building blocks. For this principle
to be user friendly, every component should be represented
with some form of interface which makes that component
self describable. Internally, components can be represented by
OPM Process blocks.
To recapitulate, using this approach makes a proposed
modeling direction based on three isomorphic forms:
1) Graphical representation with OPM diagrams,
2) Textual representation with OPM language,
3) “By example” representation based on PbE using components exposed as common user interface elements.
This makes software modeling a very powerful solution for
end-users with three parallel representation forms to choose
from. Ideas displayed here will be explored in future research
following the principles of simplicity and clarity, starting
from simple, more limited solutions, making progress towards
complexity.
VI. C ONCLUSION
Model Driven Development is centered around usage of
models - simplified representations of certain system. Models
are further used to automate the process of software development, partially or fully. There are two main methods of getting
end applications from models: code generation or model interpretation. Former methods tend to produce applications with
higher performance, because they generate classical programming code, while latter methods enable quicker modeling with
faster and more accurate response. Choosing the right path
depends on modeling task: large enterprise systems are more
likely to choose generative approach, while smaller solutions
tend to use interpretive approach to avoid complexities. Trends
also show hybrid approaches that emphasize on drawing
positive sides from both.
Object Process Methodology is a holistic approach to modeling. It enables modeling of any kind of system, but it is specially interesting to apply in interpretive modeling approach.
OPM is reflective, has solid complexity management, and is
able to describe system within single diagram, both static and
dynamic aspects.
Modeling solutions in general are still quite complex. Next
step in yielding simplicity would be to seek better user
interfaces with better metaphors to achieve more user friendly
modeling. One example of such solution could be modeling
the domain objects by composition of common user interface
elements and extracting the underlying model from such
compositions. Structural or static part of application could
then be modeled more intuitively. To achieve modeling of
dynamic aspects, composing components with “programming
by example” methods could be used. These two proposals
could yield positive steps in simplifying and bringing modeling
process closer to end-users.
R EFERENCES
[1] Object Management Group, “Meta object facility (mof) core specification,” 2001. [Online]. Available: http//www.omg.org/spec/MOF/2.0/
[2] T. Meijler, J. Nytun, A. Prinz, and H. Wortmann, “Supporting
fine-grained generative model-driven evolution,” Software and Systems
Modeling, vol. 9, pp. 403–424, 2010, 10.1007/s10270-009-0144-1.
[Online]. Available: http://dx.doi.org/10.1007/s10270-009-0144-1
[3] M. A. Rodriguez and P. Neubauer, “Constructions from dots and
lines,” Bulletin of the American Society for Information Science and
Technology, vol. 36, no. 6, pp. 35–41, 2010. [Online]. Available:
http://dx.doi.org/10.1002/bult.2010.1720360610
[4] N. Tankovic, D. Vukotic, and M. Zagar, “Executable graph model for
building data-centric applications,” in Information Technology Interfaces
(ITI), Proceedings of the ITI 2011 33rd International Conference on,
june 2011, pp. 577 –582.
[5] Object Management Group, “Semantics of a foundational subset for
executable uml models specification, version 1.0,” 2011. [Online].
Available: http//www.omg.org/spec/FUML/
[6] R. E. Filman, T. Elrad, S. Clarke, and M. Akşit, Eds., Aspect-Oriented
Software Development. Addison-Wesley, 2004.
[7] S. A. Gold, D. M. Baker, V. Guser, and H. Liang, “Object process graph
system,” US Patent US 7 316 001, 01 01, 2008. [Online]. Available:
http://www.patentlens.net/patentlens/patent/US 7316001/en/
[8] D. Riehle, S. Fraleigh, D. Bucka-Lassen, and N. Omorogbe,
“The architecture of a uml virtual machine,” SIGPLAN Not.,
vol. 36, pp. 327–341, October 2001. [Online]. Available: http:
//doi.acm.org/10.1145/504311.504306
[9] D. Dori, Object-process methodology: a holistics systems paradigm.
Springer, 2002, no. s. 1.
[10] I. Reinhartz-Berger, D. Dori, and S. Katz, “Opm/web object-process
methodology for developing web applications,” Annals of Software
Engineering, vol. 13, pp. 141–161, 2002, 10.1023/A:1016597410642.
[Online]. Available: http://dx.doi.org/10.1023/A:1016597410642
[11] I. Reinhartz-Berger and D. Dori, “Opm vs. uml - experimenting with
comprehension and construction of web application models,” Empirical
Softw. Engg., vol. 10, pp. 57–80, January 2005. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1032622.1032628
[12] R.-B. I and D. D., “A reflective metamodel of object-process methodology: The system modeling building blocks,” in Green P, R. M, Ed. s.
Business Systems Analysis with Ontologies. Hershey, PA: Idea Group;
p, 2005, pp. 130–173.
[13] D. Karagiannis and H. Khn, “Metamodelling platforms,” in Third
International Conference ECWeb Dexa 2002, LNCS 2455. SpringerVerlag, 2002, p. 182.
[14] A. Sturm, D. Dori, and O. Shehory, “The application-based domain
analysis approach and its object-process methodology implementation.”
International Journal of Software Engineering and Knowledge Engineering.
[15] L. Engelen and M. van den Brand, “Integrating textual and
graphical modelling languages,” Electron. Notes Theor. Comput.
Sci., vol. 253, pp. 105–120, September 2010. [Online]. Available:
http://dx.doi.org/10.1016/j.entcs.2010.08.035
[16] D. Wüest and M. Glinz, “Flexible sketch-based requirements
modeling,” in Proceedings of the 17th international working conference
on Requirements engineering: foundation for software quality, ser.
REFSQ’11. Berlin, Heidelberg: Springer-Verlag, 2011, pp. 100–105.
[Online]. Available: http://dl.acm.org/citation.cfm?id=1987360.1987377
[17] K. Lufer, “A stroll through domain-driven development with naked
objects,” Computing in Science and Engineering, vol. 10, pp. 76–83,
2008.
[18] D. C. Halbert, “Programming by Example,” Ph.D. dissertation, University of California, Department of Electrical Engineering and Computer
Sciences, 1984.
[19] H. Lieberman, Your wish is my command: programming by
example, ser. Morgan Kaufmann series in interactive technologies.
Morgan Kaufmann Publishers, 2001. [Online]. Available: http:
//www.google.com/books?id=wM2JYafw11gC
[20] G. Gssler and J. Sifakis, “Composition for component-based modeling,”
Science of Computer Programming, vol. 55, no. 1-3, pp. 161 –
183, 2005, formal Methods for Components and Objects: Pragmatic
aspects and applications. [Online]. Available: http://www.sciencedirect.
com/science/article/pii/S0167642304001492