mentioned earlier that semantic structures arise from
meta-models. To these semantic structures we add
syntax in order to create different languages specific
for the domain (DSML). Using these specific
languages, we can describe models in terms of them.
Different syntaxes can be used for specific purposes:
verbose class descriptions, XML structured schemas,
JavaScript procedural descriptions, OCL, JSON or
comma separated lists of properties, mathematical
expressions, etc. For instance, we have languages to
regulate state transitions, to specify the composition
of an interface dialog, to bind databases, to compose
diagrams, etc. This capability allows us to represent
models in terms of DSMLs and, therefore, can
transform Models into Languages (M2T) to create
Information Systems. In this way, each model can
be transformed to a set of DSMLs that fully
represent it. The opposite cannot be true, because
correct syntactical expressions in language could not
be allowed by meta-model rules, so cannot be
reverse engineered from the Text to the Model.
A System m* is an instance of a model m (or the
union of models) plus an execution architecture and
the time dimension. m* will be composed of
instances o*in the sense that for all o* in m*,o* is an
instance of an object o in m. Additionally, every
instance o* has a unique state, selected from the o
states list, in a given instant of time. The changes of
an object state are defined by applying the state
transition rules. The combination of time, states and
object instances creates a different global state of m*
for each t.
The system M*. Let consider the problem of
describing the meta-model S as an object of Reality.
A meta-model can be seen as a model by itself,
given that it is a description of the reality by means
of a predefined semantic. So we can take S and
generate models that describe S and use S as the
meta-model of reference, namely
. Given that
is a model itself, it can be generated as a
solution
∗
, i.e.
∗
. This solution is able to
represent any model that has been declared under the
S meta-model, so it is a collection of models, and
can manage the transformation of M in M* in the
corresponding DSMLs. All this procedure drives us
to a very interesting situation: for each S there exists
a
∗
, that can contain any model which conforms S
and
∗
is able to generate itself.
2.1 Execution Architecture
The Execution Architecture is the set of programs
that are able to interpret and execute the DSMLs
generated from models. Such architecture can run
any model that has been serialized in L, avoiding the
codification of any ad-hoc program. Therefore, we
build models of the reality we want to codify; then
we convert these models to different DSMLs, which
can be executed without neither any additional
technical effort nor development. We will call
Model Engines to the components of the
Architecture.
In our common practice we use three Model
Engines: E3 for core structures, SABLE for web
user interfaces, and an SQL engine (different
providers) for relational database management.
Other components can be used as needed, depending
on the characteristics of the model.
In summary, only one computer system (the set
of Model Engines) will solve any Enterprise
Information System, composing a binary Solution:
the Model Engine plus the DSMLs. The benefits of
this architecture are huge: (1) all the of system’s
development processes are truncated, eliminating
technical designs, programming and unit testing and
redesigns; (2) scalability, reliability and performance
of the Solution is guaranteed by the Engine, not by
the Model; (3) Flexibility of the Solution, as the
adaptation to new requirements, is guaranteed by the
Model, not by the Engine and (4), Model definition
is a problem in the scope of Knowledge
Management and Representation Techniques, and no
in the domain of the technologies. Therefore, any
Model that can be defined can be executed, which
eliminates the systemic risk in systems development.
2.2 The Scoop Meta-Model
and Modelling Technique
The SCooP metamodel has been developed by our
company in order to produce Enterprise Application
Systems from any business sectors and functional
areas. At present, SCooP is able to represent
business realities in many different areas such as
Banking, Insurance, Health Care, Manufacturing,
Services, Utilities, etc. and in functions such as
Finances, Customers Management, Operations,
Resources Management, Materials Management,
Project Management, Procurement, Disease
Management, etc. SCooP is divided in a number of
subdomains, namely: Conceptual Model, States
Model, User Interface Model, Technical Interface
Model, Execution Model, Security Model and Data
Model. Other meta-models are under analysis.
We call Models of Reference to those models
that are used in a common way in most of the
Solutions we build, for instance, management of
technical functions such as command line operators,
MDEforEnterpriseApplicationSystems
255