Conference PaperPDF Available

Controlling View Editability in Projection-Based Modeling Environments

Authors:

Abstract

In projection-based modeling environments, users work with views of the modelled system or enterprise that are generated dynamically, on demand, from a Single Underling Model (SUM). Moreover, they usually cannot change the SUM directly, but can only influence its contents indirectly via views. This means that at least some of the views need to be editable so that they can be used to evolve the SUM to a new state. However, this is not always possible when the transformations used to project SUM content into view content do not provide the information needed to unambiguously map view changes into SUM changes. Therefore, mechanisms are needed to identify and take appropriate measures to ensure that the integrity of the SUM is not comprised, and it is not updated in unintended ways, when insufficient information is available. This paper illuminates the basic nature of the problem, categorizes the different kinds of situations in which editing ambiguities can arise and discusses potential strategies for dealing with them. These techniques contribute to the creation of user-friendly, yet dependable, projection-based modeling environments. Index Terms-multi-view specification, enterprise architecture modeling, model-driven development, views, viewpoints.
Controlling View Editability in Projection-Based
Modeling Environments
Colin Atkinson, Christian Tunjic and Arne Lange
Chair of Software Engineering
University of Mannheim
Mannheim, Germany
{atkinson, tunjic, lange}@informatik.uni-mannheim.de
Abstract—In projection-based modeling environments, users
work with views of the modelled system or enterprise that are
generated dynamically, on demand, from a Single Underling
Model (SUM). Moreover, they usually cannot change the SUM
directly, but can only influence its contents indirectly via views.
This means that at least some of the views need to be editable
so that they can be used to evolve the SUM to a new state.
However, this is not always possible when the transformations
used to project SUM content into view content do not provide
the information needed to unambiguously map view changes into
SUM changes. Therefore, mechanisms are needed to identify and
take appropriate measures to ensure that the integrity of the
SUM is not comprised, and it is not updated in unintended
ways, when insufficient information is available. This paper
illuminates the basic nature of the problem, categorizes the
different kinds of situations in which editing ambiguities can
arise and discusses potential strategies for dealing with them.
These techniques contribute to the creation of user-friendly, yet
dependable, projection-based modeling environments.
Index Terms—multi-view specification, enterprise architecture
modeling, model-driven development, views, viewpoints.
I. INTRODUCTION
As the complexity of software systems and enterprise
architectures grows, and Digital Twin (DT) / Internet-of-
Things (IoT) technologies move to the center stage in software
intensive systems, modeling environments need to become
more “view-based”. The importance of “views” in modeling
IT systems was recognized in the 1970s [1] and is enshrined in
the ISO 42010 standard [2] for modeling the architectures of
software intensive systems as well as other aligned standards
such as ISO 12207 [3] for software lifecycle processes, ISO
15288 [4] for systems engineering and ISO 10746 [5], known
as RM-ODP, for enterprise/distributed systems.
As well as introducing the notion of “viewpoints” to capture
the “concerns and the representations/modeling techniques”
portrayed by views, and the term “viewpoint framework” to
represent a coherent set of view types used to represent all
aspects of a complete systems, ISO 42010 also identifies
two fundamental strategies for realizing view-based modeling
environments (VMEs) – “synthetic” approaches, in which
views are independent “islands” of information whose contents
collectively describe the system of interest, and “projective”
approaches, in which there is only one primary source of
information (i.e. truth) about the system from which all views
are generated on demand. Like most of the aforementioned
standards, ISO 42010 is agnostic about whether VMEs should
be realized in a synthetic or projective way, but the RM-
ODP standard explicitly promotes the synthetic approach. In
practice, most contemporary VMEs realize views synthetically
as heterogeneous ecosystems of propriety tools using standards
such as Open Services for Lifecycle Collaboration (OSLC) [6]
for tool interoperability.
Although the synthetic approach is the most widely used
today, and is convenient when the number of views is fairly
small, it does not scale up well to large systems because, in
general, the number of pairwise consistency relationships that
have to be preserved grows exponentially with the number
of views. In contrast, once a suitable Single Underlying
Model (SUM) has been defined, the number of consistency
relationships that have to be preserved in projective approaches
is linearly proportional to the number of views. However,
this superior scalability is achieved at a cost. Not only do
developers need to define a SUM which is free of, or at least
only has a small number of, internal redundancies (otherwise
the exponential scalability problem is simply shifted from the
views to internal sub-models within the SUM) they have to
ensure that at least some of the views are editable and can be
used to update the SUM securely (otherwise users would have
to edit the SUM directly).
Creating fully editable view types in a projective VME
(PVME) is difficult because the defined view projection trans-
formations (VPTs) can result in view types for which the
intended SUM targets of changes to a view are unclear. Such
ambiguity can easily arise from the abstraction, expansion or
compression operations that are performed to portray informa-
tion in the SUM in the ways required by different viewpoints.
As a first step to providing guidelines for designing unambigu-
ously editable view types, this paper provides an analysis of
the different situations in which ambiguity problems can occur
and discusses different practical strategies for addressing them.
We present our analysis in the context of our fully-projective
view based-modeling environment, DOREEN, designed to
support the so called Orthographic Software Modeling (OSM)
approach [7], [8]. However, since this is based on a gen-
eral purpose modeling language with a UML-like graphical
notation the analysis is not limited to this approach, but
is relevant to any projective view-based modeling language
supporting a UML-like language or a MOF-like infrastructure.
978-1-6654-3579-6/21/$31.00 © 2021 IEEE
Component
name : String
Operaon
name :String
SUM Metamodel
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
SUM
ValidaonService : Component
name = ValidaonService
State
SubState
Component
name : String
VIEW Metamodel
VIEW
ValidaonService : Component
name = ValidaonService
PayCreditCard:State
CheckCard:SubState
CheckPIN:SubState
Error:State
Init:State
End:State
Operaon
name :String
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
acquires
Inventory : Component
name = Inventory
acquires
acquires
acquires
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
Fig. 1: Projection of a View from a SUM
The rest of the paper is structured as follows. In the next
section we present an overview of our projective modeling
approach through a small example. The following section,
Section III, then outlines the different categories of problems
that can cause editing ambiguities in views, while Section IV
discusses some strategies for addressing them. Finally, Section
V discusses some related work while Section VI closes with
some concluding remarks.
II. PRO JE CT IO N-BASED VME EXAMPLE
In projective VMEs (PVMEs), all views are generated on
the fly from a SUM that represents the single point of truth
about the system of interest. In the DOREEN tool [9], [10]
developed at the University of Mannheim to support this
approach, the View Projection Transformations (VPTs) are
defined using a variant of the ATL transformation language
known as deep ATL [11], while the back propagation of
information from the view to the SUM is realized using
delta-based lenses [12]. Changes applied to views are thus
computed, transferred and merged into the SUM by applying
the rules defined in their view type’s VPTs. Figure 1 shows
a simple example that illustrates a minimal SUM, a minimal
view type and view instance, and a minimal transformation
between them. The example illustrates a simple e-commerce
system revolving around the notion of a shopping cart. All the
associations and composition relationships in Figure 1 have the
default multiplicity of ‘0..*’, except for the aggregate ends of
composition relationships which have a multiplicity of ‘1’.
The top left-hand side of Figure 1 shows the SUM meta-
model that describes the language (i.e. metamodel) used to
represent content in the SUM, while the bottom left-hand
side of the model shows the SUM content which describes
the system of interest, in this case our small e-commerce
system. These model elements are usually types, as can be
seen in the figure, since in a running software system created
from this model, multiple instances of them will be created
at run-time1. However, in accordance with current practice,
these instances are not modelled in this example since it is
assumed that the types in the SUM will ultimately be mapped
to an implementation technology such as a programming
language or database management system which can support
their instantiation at run-time. The DOREEN technology can
actually also accommodate the representation of instances of
the modelled types in a so called multi-level model, but since
this is not relevant to the topics discussed in this paper we do
not elaborate upon it.
The top right-hand side of Figure 1 shows a view metamodel
defining the language used to represent a particular type of
view, while the bottom right-hand side shows the use of this
language to represent the contents of a view of this type. The
1This is why the language definition is referred to as a metamodel rather
than a model in Figure 1
shown example is an abstracting view type since its language
(i.e. metamodel) is a subset of the SUM language. Individ-
ual instance of this view type therefore essentially shows a
subset of the information in the SUM without combining or
modifying it in any way. However, in general, a view type’s
language does not have to be related to the SUM language,
and any kind of transformation can be used to populate its
instances with information from the SUM. The dotted arrows
in Figure 1 define the mappings between metamodel (i.e.
language) elements in the SUM and the view type, while the
dashed arrows define the correspondences, or traces, between
the model elements in the SUM content and the view content.
The VPT that completes the definition of the view type
is shown in Listing 1. As mentioned above, the language
used to define VPTs in DOREEN is deep ATL, since the
SUM and views can in general be multi-level (i.e. deep).
However, as this example is restricted to the traditional two-
level way of describing systems (which is a special case), this
transformation uses standard ATL transformation constructs
which are a subset of deep ATL’s features.
As can be seen in the listing, the example features a simple
three rule VPT which uses three helper functions to identify
the roles and relationships between model elements to be
displayed in an instance of the view type. The isSubject()
helper is used to identify and retrieve access to the component
that has been chosen as the subject of the view, the belongsTo-
Subject() helper is used to identify whether a component
belongs to (i.e. is a sub-component of) another component, and
the operationBelongsToSubject() is used to identify whether
an operation belongs to the subject component. Since the
implementation of these helpers is trivial we do not show them
here.
helper def: isSubject(c: SUM!Component) ...
helper def: belongsToSubject(c: SUM!Component) ...
helper def: operationBelongsToSubject(o: SUM!Operation) ...
rule ComponentSum2SubjectComponentView{
from
s : SUM!Component (thisModule.isSubject(s))
to
t : VIEW!Component(
name <- s.name,
contains <- s.contains,
component <- s.component
)
}
rule ComponentSum2ComponentView{
from
s : SUM!Component (thisModule.belongsToSubject(s))
to
t : VIEW!Component(
name <- s.name,
contains <- s.contains,
subject <- s.subject
)
}
rule OperationSum2OperationView{
from
s : SUM!Operation (thisModule.operationBelongsToSubject
(s))
to
t : VIEW!Operation(
name <- s.name
)
}
Listing 1: Transformation from the SUM to the View
When a user of the DOREEN VME calls up an instance
of the presented view type on a particular component in the
SUM (i.e. the subject component they want to analyse/edit
via the view), the tool applies this transformation in Listing
1 to the model element representing the subject component to
generate the view content shown on the bottom left-hand side
of Figure 1, with the associated traces to the model elements in
the SUM from which they were derived. The problem we are
addressing in this paper occurs, in general, when users want
to evolve the SUM as part of the system development process
using the usual CRUD operations (i.e. create, read, update and
delete) on model elements. The read operation is supported as
part of the view creation process, but the create, update and
delete operations require changes to be made to the SUM that
reflect the intent of the user. For this small example, since the
mapping between SUM and view model elements is so simple
there is no ambiguity about what changes should be made to
the SUM when the user deletes or updates a model element
in the view. In other words, for these operations there is no
ambiguity about how to “back propagate” changes made in a
view to the SUM. However, in the case of creation operations
the situation is not so clear. Since operations must always
belong to a component, even in the view, the back propagation
of operation creations is clear. But what about component
creations? If users were allowed to create components via the
defined view type, where would the new SUM components be
placed in the SUM, and what relationships would they have
to other already existing components?
III. CATEG OR IE S OF BAC K PROPAGATION PRO BL EM S
In this section we analyse the nature of this problem in more
detail and categorize the different kinds of back propagation
ambiguities that can arise when attempting to update a SUM
by editing a view [10].
A. Missing Context
One of the main motivations for using a view-based ap-
proach is to “zoom in” on individual entities within the SUM
so that their properties can be analyzed and developed in
isolation. In other words, it is useful to be able to focus on a
part of a system without having to worry about where it fits
into the system as a whole. However, this can result in views
in which the SUM context of the portrayed content is not
available. For example, a view used to specify an operation
(e.g. to define pre-/postconditions) does not have to include
information about the owner of the operation. However, the
context of the operation in the view is then no longer the
same as in the SUM. The context for the operation in the view
essentially becomes the top-level container in the view, while
in the SUM the operation is probably contained in another
entity like a component, as in our example. While the creation
of a new operation in the view is not problematic per se,
updating the SUM with this new operation could violate the
definition of the SUM language. In the back propagation of the
view to the SUM it might not be clear where the operation
should be placed, since the view may not identify the right
location for the new operation as this information has not been
included.
Figure 2 shows the described example in more detail.
SUM represents the initial SUM while SUM’ shows the
SUM after changes have been made to the view. Similarly,
VIEW represents the initial view which is a projection of
a particular part of the SUM. The projection is described
by the solid lines with arrows pointing from the elements
in the SUM to their projections in the view. VIEW’ shows
the modified view after some changes has been made by a
system developer. In this case, only one change is made –
the creation of a new Operation with the name AddItem.
While the new view is consistent with the view language the
back propagation of the new Operation into the SUM could
make SUM’ inconsistent with the SUM language. In the figure,
the ambiguities with the back propagation are shown by dotted
lines pointing from the new element in the VIEW’ model
to the possible locations of the new element in the SUM’
model. There are at least three feasible options for the back
propagation of the new Operation
1) the new Operation can be placed in the ShoppingCart
Component since Pay belongs to this Component
too,
2) the new Operation can be added to the Validation-
Service Component,
3) a new Component can be created as the container for
the new Operation.
Since these are all plausible, it is unclear how the back
propagation should be implemented.
B. Information Abstraction
The opposite problem to the aforementioned missing con-
text problem can also occur. It is possible, and in some cases
useful, to have abstractions in views which are less detailed
than the SUM. This means that when showing an element
that contains other elements in the SUM, a view can “abstract
away” from those contained elements by not showing them.
Thus, whereas the previous problem was caused by a lack
of information about what was outside an entity of interest,
this problem is caused by a lack of information about what is
inside.
Using the example with components and operations, a view
whose goal is to describe the relationship between components
does not have to contain the operations of the components in
order to achieve its goal. A view showing which operations
belong to which components is useful for understanding the
capabilities of components but does not show the relationships
between them. The problem in omitting information when
projecting a view is the loss of contextual detail. When
components are deleted in the view, for example, then the back
propagation step should delete the components in the SUM as
well, in order to reflect the changes. However, when deleting
components it is not clear what changes are intended in the
SUM. The back propagation could result in a violation of the
SUM language or in semantic problems caused by unwanted
changes.
Figure 3 shows an example of this problem. Again SUM
represents the initial SUM and SUM’ represents the new
SUM after changes have been propagated from a modified
view. Similarly, VIEW shows the projected view containing
the Components from the SUM, as denoted by the solid
lines with arrows pointing from elements in the SUM to their
projections in the view, while VIEW’ presents the view after a
change has been made to it by system developers. The action
in question is the deletion of the Component ShoppingCart.
While the model VIEW’ is still consistent and compliant
with its view language, the back propagation may result in
unwanted behaviour. Since the Component ShoppingCart
must be deleted in the SUM in order to reflect the changes
from the view, it is not clear how the Operation Pay should
be handled. One possibility is to delete the Operation
together with its container, but this is not clear from the
perspective of the view and could lead to a semantic problem.
However, leaving the Operation in the SUM would cause
an inconsistency since Operation is not a top-level element
and must have a Component as a container. Therefore, once
again the semantics of back propagation in the example is
unclear.
C. Information Adaptation and Combination
A further problem case occurs when relationships between
elements are shown in the view. Relationships can occur
between any given elements as long as they are allowed
in the SUM or view language. When creating a view from
the SUM, the relationships between entities in the SUM can
be projected into, and thus shown in, the view. Moreover,
sometimes relationships between elements contained by top-
level elements can be shown in a view, even if these contained
elements are not shown. Figure 4 shows this situation in terms
of States that are top-level concepts, SubStates which
are contained in these States and three different relationship
– a relationship between two States, a relationship between
two SubStates and a relationship between a State and
aSubState. This scenario is adapted from [13] which
addresses a similar problem using the Janus Transformation
Language (JTL).
SUM in Figure 4 shows States describing a simplified
installation process for a software system. The State Init
triggers the installation through the transition to the InstallSoft-
ware State, which contains a Substate,ConfigInstall, for
configuring the installation in terms of setting the installation
path etc. When the configuration has been completed, the
transition from ConfigInstall to Install triggers the actual
installation. Depending on the condition of the underlying
system, the installation may succeed or it may fail. Success
triggers the transition to the End State, i.e. the final state.
Failure triggers the transition the the Error state in which the
problem is reported to the user followed by a transition the
End State.
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
Pay : Operaon
name = Pay
SUM VIEW
ValidaonService : Component
name = ValidaonService
(a)
ShoppingCart : Component
?
?
name = ShoppingCart
Pay : Operaon
name = Pay
Pay : Operaon
name = Pay
SUM' VIEW'
AddItem : Operaon
name = AddItem
ValidaonService : Component
name = ValidaonService
?
? : Component
name = ?
(b)
Fig. 2: Missing Context
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
ShoppingCart : Component
name = ShoppingCart
SUM VIEW
ValidaonService : Component
name = ValidaonService
ValidaonService : Component
name = ValidaonService
(a)
?
Pay : Operaon
name = Pay
SUM' VIEW'
ValidaonService : Component
name = ValidaonService
ValidaonService : Component
name = ValidaonService
?
? ?
(b)
Fig. 3: Information Abstraction
InstallSoware:State
SUM VIEW
CongInstall:Substate
Install:Substate
Error:State
Init:State
End:State¹
transionsTo
transionsTo
Init:State
InstallSoware:State End:State
Error:State
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
(a)
?
SUM' VIEW'
Init:State
InstallSoware:State End:State
Error:State
?
?
InstallSoware:State
CongInstall:Substate
Install:Substate
Error:State
Init:State
End:State
transionsTo
transionsTo
transionsTo
transions To
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
transionsTo
(b)
Fig. 4: Information Adaptation and Combination
A simplified abstraction of the installation process is shown
in VIEW. The projection used to generate the view abstracts
away from the Substates but preserves the transitions
between the Substates and the States. In particular, the
target of a transition, which is a Substate in the SUM, is
changed to the Substate’s parent State in the view. This
preserves the flow of transitions by abstracting away from their
targets. The transitions from the Install state are both projected
into the view with InstallSoftware as their source state and the
End and Error States as their target states respectively.
VIEW’ represents the updated view after a developer has
changed it by adding the transition from the Error state
to the InstallSoftware State. This transition extends the
functionality of the installation process so that users can try
to fix the problem that caused the installation to fail. The
question, again, is how to reflect this change in the SUM.
Possible ways of back propagating this change are shown in
SUM’ by the three dashed lines relating the Error State
with the InstallSoftware State and its Substates. From a
semantic point of view, the optimal solution would probably
be to add the transition to the ConfigInstall Substate, since
this state allows the configuration of the installation to be
altered to avoid the error. The transition to the parent State
InstallSoftware would execute the whole step again although
only the configuration step is relevant and the transition to
the Install Substate would probably lead to a cycle in
which the user is not given the chance to fix the problem.
Executing the step again would cause the recurrence of the
error since the installation configuration is not changed. From
the consistency point of view, the only valid solution is
probably to add the transition to the InstallSoftware State.
However a consistency problem occurs when relating some of
the Substates with the new transition, since the type of
the transition’s target in the view is a State whereas in the
SUM it must be a Substate. Since there are several potential
ways to reflect the change, the back propagation semantics are
unclear.
D. Non-Unary Transformation Cardinalities
The previous subsections presented some examples of the
semantic problems that can occur with projected views that are
used to update the SUM. The problems arise when abstracting
away from particular concepts in the SUM when generat-
ing the content of the view and back propagating changes.
The number of model elements related in a VPT defines
the mapping cardinality, which can be one-to-one,many-to-
many,many-to-one or one-to-many. In general, VPTs with
cardinalities involving many elements lead to problems when
editing views as explained in the following subsections.
1) Many-to-One Projections: A VPT with a many-to-one
cardinality maps many elements from the SUM to only one
element in a view. Such rules can be used to gather information
which is distributed over many (type-different) model elements
in the SUM and summarize it in a view in a merged way within
a single model element. In [14] this technique is referred
to as information compression. Figure 5 shows an example
where the operations of a component are presented in a single
view. The model SUM shows the content of the SUM, while
VIEW shows the projected view. Since operations of different
components can have the same names due to the distinct
namespaces of the components, a two-to-one cardinality VPT
is used to include the fully-qualified name in the view, which
is a combination of the component name and operation name.
This allows the operations to be distinguished, even if they
have the same local name in the SUM.
When views are edited, the usage of many-to-one VPTs may
lead to problems. Even if changes applied to the concatenated
name could be reflected back to the SUM as shown in [15],
the back propagation of a newly created element in the view
may lead to problems as shown in Figure 5. In the example,
VIEW’ shows the view after a system developer has created
a further Operation for which they have entered the text
Reset. The problem is that it is not known whether the
user who added the new operation was aware of the name-
concatenation principle used to label the operations in the
view, and intended for it to be applied in the back propagation
step, or was unaware of the principle and just intended to
enter the operation name. In the former case, assuming the
user is aware of the components already in the SUM, the
user clearly does not want the new operation to belong to
ShoppingCart or ValidationService, but then how should the
supplied string (i.e. “Reset”) be split into the component name
and operation name for the new elements in the SUM? In the
latter case, it is clear that name of the operation is intended to
be Reset, but unclear what component it should be added to,
ShoppingCart,ValidationService or a new component whose
name is unknown. The back propagation requirements are
therefore unclear, as shown in Figure 5b, even if the creation of
the new element does not violate the semantic and consistency
conditions of the view.
2) One-to-Many Projections: A VPT with a one-to-many
cardinality can be used to project information which exists
only once in the SUM to multiple places in a view. In [14] this
case is referred to as information expansion and is the basis for
avoiding redundancy in the SUM, since it allows information
that appear multiple times in a view, or in many views, to
be stored in only one place in the SUM. Figure 6 shows an
example of a one-to-many projection. The Component with
the name ShoppingCart from the SUM, represented by model
SUM is projected to the view (model VIEW). The VPT uses
the name property of the SUM Component to set the name
of the corresponding Component in the view. In the view,
the former appears in the title compartment of the element and
the latter in the name attribute.
A change to a piece of information that exists twice in
a view but has exactly one origin in the SUM may lead to
unpredictable behaviour when propagating it back to the SUM.
The lower part of Figure 6 shows the problem. Changing the
ontological name of the Component in model VIEW creates
the new version of the view, VIEW’. The back propagation
to the SUM, leading to SUM’, has two possible solutions as
denoted by the question marks. Since both name values from
the Component in the view are mapped to a single name
value in the SUM, what happens when the two values are
different? If the back propagation is implemented in a naive
way, the final name value stored in SUM’ may depend on the
order in which the model elements are propagated back. The
last value propagated back would overwrite any changes that
were made before. Since there are usually several options for
back propagating one-to-many VPTs, the correct mapping is
unclear.
3) Many-to-Many Projections: The two previous cases
identified problems caused by VPTs in which only one of
the cardinality limits was many (i.e. one-to-many or many-
to-one). Rules in which both cardinality limits are many (i.e.
many-to-many) are even more complicated and often combine
the problems occuring in the simpler cases. They are also non-
deterministic therefore.
IV. SOLUTION STR ATEGIES
The previous section identified the different categories of
mapping situations which can cause ambiguities when attempt-
ing to back propagate changes made in a view to the SUM. In
this section we discuss practical and theoretical strategies that
can be used to address this question and create VMEs which
allow SUMs to be updated from views in a secure, intuitive
and productive way.
A. Avoid Problematic VPTs
The most obvious and direct way in which the observations
from the previous section can be used to avoid any ambiguities
arising in the back propagation of view changes to the SUM is
to ensure that none of the views have any of the problematic
properties described above. In particular, this means that none
of the VPTs should involve mappings with cardinalities greater
that one or which do not include the containment context of
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
ShoppingCartPay : Operaon
name = Pay
SUM VIEW
ValidaonService : Component
name = ValidaonService
(a)
SUM'
?
ShoppingCartPay : Operaon
name = Pay
VIEW'
Reset : Operaon
name = ?
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
ValidaonService : Component
name = ValidaonService
?
?
(b)
Fig. 5: Many-to-One Projection
ShoppingCart : Component
name = ShoppingCart
Pay : Operaon
name = Pay
ShoppingCart : Component
name = ShoppingCart
SUM VIEW
ValidaonService : Component
name = ValidaonService
(a)
ShoppingCart : Component
?name = ShoppingCart
Pay : Operaon
name = Pay
SUM' VIEW'
ValidaonService : Component
name = ValidaonService
ShoppingCart : Component
name = ShoppingCartService
name = ShoppingCartService
?
? ?
(b)
Fig. 6: Projection One-to-Many
model elements in a view. At first sight this may seem to be a
trivial observation (if you have a problem, avoid it), but there
are two reasons why this insight can be helpful when designing
the viewpoint framework for a VME (i.e. the overall collection
of view types used to model a system)
1) Pragmatic SUMS: The first reason stems from the fact
that, at least for the foreseeable future, most PVMEs will not
be based on essential SUMs (i.e. monolithic SUMs that are
100% redundancy free [16]), but rather on pragmatic or virtual
SUMs (V-SUMs) of the kind supported by VITRUVIUS [17],
in which the SUM is organized internally into several semi-
independent models. When this is the case most, if not all,
views tend to focus on portraying information from just one
internal model, and do this in a direct way which uses few,
if any, of the problematic mappings outlined in the previous
section. An example of this kind of view type is described in
[18]. For example, a pragmatic VME that supports a typical
UML-to-Code development cycle (i.e. in which a system is
first modelled using UML diagrams and then implemented
using a programming language like Java) would probably
have a V-SUM with two internal models – one focused on
representing the UML part and one focused on the Java
part. Since the V-SUM infrastructure takes care of ensuring
that consistency relationships between the two sub-models are
preserved, the views generated from them can be very simple
and essentially avoid most, if not all, of the problems discussed
previously.
The downside of such a pragmatic approach, of course,
is that the scalability advantage of fully projective VMEs is
diluted or lost altogether. This relies on a SUM having as little
internal redundancy as possible. However, to support the same
rich set of view types as a pragmatic VME more elaborate
VPTs are needed, giving rise to the kinds of editability
problems mentioned in the previous section. In a nutshell,
therefore, the trade off is between having a simple SUM with
complex VPTs or a complex SUM with simple (and therefore
ambiguity-free) VPTs. Since VMEs are more likely to employ
the latter in the near future, the problem of view editability is
likely to be limited.
2) Limited View Editability: The second reason stems from
the fact that it is not necessary for every model element to be
editable in every view in which it is portrayed. On the contrary,
full evolvability of the SUM is guaranteed as long as every
model element can be edited in at least one view. Thus, the
problem of ensuring that the SUM can be fully updated via the
views is as much a problem of defining the optimal viewpoint
framework (i.e. the optimal set of view types) as it is a problem
of ensuring unambiguous editability of model elements within
a single view type. For example, an optimal set of views for the
typical UML-to-Code development environment mentioned
above would be to have a large number of non-editable
views showing information drawn from the UML and Java
information, and a smaller number of editable views which
focus on supporting unambiguous editing of model elements.
Such an approach would essentially take an “all or nothing”
approach to view editability in which views are regarded
as either being fully editable (because there are no back
propagation ambiguities) or completely uneditable, due to the
presence of at least one back propagation ambiguity. This
approach would certainly be effective, but it needs to be
coupled with extensive user interface support so that users
are directed to the view they need to edit in order to update a
model element from the SUM. In the extreme case, it would
be possible to define view types optimized towards editing one
and only one model element from the SUM metamodel at a
time. Such view types would be analogous to the “properties”
forms which most modeling tools offer for the purpose of
changing individual model elements.
B. Fine-grained Editability Attributes
Instead of controlling editability at the level of entire views,
a more precise and flexible approach is to move the level of
control down to the granularity of individual model elements.
This is the approach taken in the DOREEN tool, which extends
the underlying metamodel of the environment so that all model
elements can be labelled as having one of four editability
properties based on the classic CRUD operations. The label is
stored using attributes of an enumeration type with the four
corresponding values –
creatable – an instance of a model element in the view
type metamodel can be instantiated in the view content,
readable – a model element in a view can only be read,
updatable – a model element in a view can be updated
and read but not deleted,
deletable – a model element in a view can be deleted,
updated and read.
Creatability is obviously a property that has to be defining
at the metamodel level. However, the other properties are all
associated with model elements at the view content level. Ob-
viously, depending on the degree of editability associated with
each model element, one or more of the problems outlined
above need to be avoided in order to ensure ambiguity-free
back propagation. In the case of a model element that is only
readable, of course, no restrictions are necessary. However, for
a model element to be updatable and deletable it is important
that its mapping from the SUM be one-to-one. Finally, for a
metamodel element to be creatable, it is also necessary for
the metamodel element corresponding to the owner or creator
element to be included in the SUM (i.e. the context), and that
the actual container of a model element be shown when it is
added to a view.
C. Assisted Editing
Even though the aforementioned attributes provide much
finer grained control over editability of model elements in a
view, and can identify things to avoid in the VPTs that project
information from the SUM, it is not possible to fully guarantee
editability just by ensuring that the VPTs and the language
definition of a view type adhere to certain properties. For
example, although the inclusion of a model element’s container
type in the view language is necessary for that model element
to be creatable without any back propagation ambiguity it is
not always sufficient. For example, perhaps the container of a
creatable model element should also be created within a view.
In such a circumstance, how is it possible to ensure that it
has in fact been created and that the required containment
relationship exists to provide the context for unambiguous
back propagation.
For this reason, as well as to enhance the usability of
PVMEs, it is highly desirable to support an assisted editing
mechanism in which modellers are given immediate feedback
on whether changes they have attempted to make can be
unambiguously propagated back to the SUM, or if there is
a problem. In the latter case, a PVME should at the very
least provide feedback about the nature of the problem (e.g.
missing context, many possible mapping targets, etc.) and
ideally should enter into a dialog with the modeller to help
identify which of the alternative possible back propagation
is desired. However, this is difficult to achieve in general
because in extreme cases the model elements appearing in
the view may not even exist in the same form in the SUM, so
ascertaining the user’s intent through a dialog is highly domain
and application specific.
D. Smart, Fine-grained VPTs
In the long-run, therefore, what is required is a new form
of semi-automated, bi-directional transformation in which the
reverse mappings are defined at a fine-grained level to include
potential interactions with users to disambiguate conflicts. The
reverse transformations would therefore technically be semi-
automated in the sense that they would proceed without human
input when there is no ambiguity, but would seek human input
through a dialog with the user where the back propagation
is ambiguous. This would essentially be the mechanism by
which the designers of the view types used to model a system
could include the domain knowledge needed to deal with the
potential back propagation ambiguities in an intelligent and
user-friendly way.
V. REL ATED WO RK
Cicchetti et al. [19] developed a hybrid synthetic/projective
approach which uses model differences to propagate changes
between views in order to keep them consistent. However, the
approach is quite complex due to the additional consistency
relationships needed to support the synthetic views. Further-
more, projective view types are defined as sub-portions of the
overall model which hinders the definition of views tailored
to specific domains. In order to define a new view type, the
modeling environment must be extended with new code.
Another approach that enhances ATL to support bidirection-
ality is described by Xiong et al. [20]. In their approach, one
model is the source and the other the target of a model transfor-
mation. In order to trace the model elements from the source
model to the target model and back, an identifier is assigned to
each model element. The realization of the approach extends
the ATL Virtual Machine (VM) and introduces new functions
to propagate changes between the two models. The solution
has been successfully tested on many official ATL examples.
The approach manipulates ATL transformation bytecode and
needs a modified version of the ATL-VM which recognizes
the newly introduced functions. However, the approach does
not directly address the problems described in this paper.
The VITRUVIUS (VIew-cenTRic engineering Using a VIr-
tual Underlying Single model) approach, first presented in
[17], supports flexible views which can involve multiple mod-
els conforming to different metamodels. This approach creates
a virtual SUM (V-SUM) which is usually not redundancy free
and allows multiple metamodels to be combined and reused.
These independent models are kept in sync via MIR (map-
ping/invariant/response) definitions that create the transforma-
tions for synchronising the involved artifacts automatically. As
with the previous approaches, however, the problems described
in this paper can still arise when views are projected from a
virtual SUM.
Meier et al. [21] use a chain of configured operators to keep
the SUM in sync with all the changes made in their viewpoints.
It is possible to reuse the configured operators so that creating
new viewpoints is just a matter of adding a new operator to the
transformation chain. Reuling et al. [22] created an approach
for projective software product line modeling. To keep the
internal model consistent with the external representations
they create a 150% model with superimposed elements of the
internal model. To propagate the changes back into the internal
structure they perform delta operations that are declaratively
specified as parameterized graph-based transformation rules.
Our approach uses a similar parameterization technique to
specify the subject of a view.
Although QVT [23] is the OMG standard for defining
transformations between meta-models, we use a dialect of ATL
which is aware of the deep modeling paradigm and build on
the Eclipse Modeling Framework (EMF). Stevens [24] shows
that it is possible to construct bidirectional transformation
with QVT in order to keep multiary relationships consistent.
In theory, this approach should also work in our framework,
but the QVT language would have to be modified to fit our
modeling paradigm.
VI. CONCLUSION
In order to cope with the growing complexity and scale of
software intensive systems, including cyber-physical systems
and enterprise systems, future view-based modeling environ-
ments will need to adopt much more “projective” ways of
supporting views which have the potential to dramatically
reduce information redundancy, and thus the number of consis-
tency relationships that need to be preserved. This will require
SUMs to become more “essential” to avoid the duplication of
information within multiple sub-models and VPTs to become
more elaborate and varied in order to support the same
richness of views from more concentrated information sources.
However, the richer and more elaborate VPTs become, the
greater the number of ambiguities that can arise when the
resulting views are used to evolve the SUM.
In this paper we discussed the different categories of editing
ambiguities that can arise when trying to change the SUM by
editing views, and observed that they boil down to two basic
issues – non-binary mappings within VPTs which make it
unclear which model element(s) in the SUM should be updated
or deleted as a result of a change to a view, and missing context
information which makes it unclear where model element(s)
should be created in the SUM in response to the creation of
a model element in a view. Without practical and reliable
strategies for addressing these ambiguities when they arise,
PVMEs will fail to deliver their full scalability and flexibility
benefits.
As discussed in Section IV, practical strategies for dealing
with editing ambiguities can address the problem at the
viewpoint framework level as well as at the view type level
and at different level of granularity, depending on the degree
of sophistication and flexibility required. At one extreme, it
is possible to tackle the problem at the viewpoint framework
level by designating entire views as either being editable or
non-editable and making the former as simple as possible to
avoid back propagation problems. As long as each element
in the SUM is mapped unambiguously and context-fully in at
least one view type in the viewpoint framework, this is suffi-
cient. At the other extreme, it is possible to tackle the problem
at the level of individual view types and views by controlling
editability properties at the granularity of individual model
elements. This affords maximum flexibility and productivity
since it allows more elaborate editing options to be offered in
a way that precisely matches the skills and needs of different
stakeholders. However, as pointed out in the paper, to make
this additional flexibility and power helpful to users, rather
than a hindrance, more sophisticated transformation languages
are required in order to define VPTs that embody the domain
and application knowledge need to resolve any ambiguities
through smart and efficient dialogues with the user.
At the time of writing, our DOREEN PVME supports
the fine grained approach to view-based editability control
by allowing CRUD-level editability attributes to be assigned
to model elements in views and/or view types. Moreover,
it does this in a “deep” way so that editability properties,
like other properties of model elements, can be explicitly
controlled over multiple classification levels using the same,
minimal set of concepts. The ability to support deep SUMs
and views is important in order to allow PVMEs to seamlessly
cover multiple phases of a system’s lifecycle, in the sense of
DevOps and continuous development, integration, deployment
and operation. Our next goal is to extend the deep ATL
dialect used to define VPTs in the DOREEN PVME to support
the fine-grained disambiguation and user dialogue information
needed for the smart back propagation approach outlined in
this paper.
REFERENCES
[1] D. T. Ross, “Structured analysis (sa): A language for communicating
ideas,” IEEE Transactions on software engineering, no. 1, pp. 16–34,
1977.
[2] ISO/IEC/IEEE, “Systems and software engineering – architecture
description,” ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC
42010:2007 and IEEE Std 1471-2000), pp. 1 –46, 1 2011.
[3] R. Singh, “International standard iso/iec 12207 software life cycle
processes,” Software Process: Improvement and Practice, vol. 2, no. 1,
pp. 35–50, 1996.
[4] S. Arnold and H. W. Lawson, “Viewing systems from a business man-
agement perspective: The iso/iec 15288 standard,Systems engineering,
vol. 7, no. 3, pp. 229–242, 2004.
[5] ISO/IEC, “RM-ODP. Reference Model for Open Distributed Process-
ing,” ISO/IEC 10746, ITU-T Rec. X.901-X.904, 1997.
[6] OSLC, “Open Services for Lifecycle Collaboration,” http://open-
services.net/, Retrieved 2019.
[7] C. Atkinson, D. Stoll, and P. Bostan, “Orthographic software modeling:
A practical approach to view-based development,” in Communications
in Computer and Information Science. Springer Science & Business
Media, 2010, pp. 206–219.
[8] C. Atkinson, C. Tunjic, D. Stoll, and J. Robin, “A prototype implementa-
tion of an orthographic software modeling environment,” in Proceedings
of the 1st Workshop on View-Based, Aspect-Oriented and Orthographic
Software Modelling - VAO ’13. New York, NY, USA: ACM, 2013, pp.
3:1–3:10.
[9] C. Tunjic, C. Atkinson, and D. Draheim, “Supporting the Model-Driven
Organization Vision through Deep, Orthographic Modeling,Enterprise
Modelling and Information Systems Architectures-an International Jour-
nal, vol. 13, no. SI, pp. 1–39, 2018.
[10] C. V. Tunjic, “A deep orthographic modelling environment,” Ph.D.
dissertation, University of Mannheim, Germany, 2021.
[11] C. Atkinson, R. Gerbig, and C. Tunjic, “Towards Multi-level Aware
Model Transformations,” in Lecture Notes in Computer Science (includ-
ing subseries Lecture Notes in Artificial Intelligence and Lecture Notes
in Bioinformatics), 2012, vol. 7307 LNCS, pp. 208–223.
[12] Z. Diskin, Y. Xiong, and K. Czarnecki, “From state- to delta-based
bidirectional model transformations: the asymmetric case,” Journal of
Object Technology, vol. 10, pp. 6:1–25, 2011.
[13] A. Cicchetti, D. Di Ruscio, R. Eramo, and A. Pierantonio, “JTL: A
bidirectional and change propagating transformation language,” Lect.
Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect.
Notes Bioinformatics), vol. 6563 LNCS, pp. 183–202, 2011.
[14] C. Atkinson, C. Tunjic, and T. Möller, “Fundamental Realization Strate-
gies for Multi-View Specification Environments,” 2015 IEEE 19th Int.
Enterp. Distrib. Object Comput. Conf., pp. 40–49, Sep. 2015.
[15] P. Inostroza, T. van der Storm, and S. Erdweg, “Tracing Program
Transformations with String Origins,” in Theory and Practice of Model
Transformations, 2014, pp. 154–169.
[16] J. Meier., H. Klare., C. Tunjic., C. Atkinson., E. Burger., R. Reussner.,
and A. Winter., “Single underlying models for projectional, multi-
view environments,” in Proceedings of the 7th International Conference
on Model-Driven Engineering and Software Development - MODEL-
SWARD,, INSTICC. SciTePress, 2019, pp. 119–130.
[17] M. E. Kramer, E. Burger, and M. Langhammer, “View-centric engineer-
ing with synchronized heterogeneous models,” in Proceedings of the 1st
Workshop on View-Based, Aspect-Oriented and Orthographic Software
Modelling - VAO ’13, ACM. ACM, 2013, p. 5.
[18] A. Lange, C. Atkinson, and C. Tunjic, “Simplified view generation in
a deep view-based modeling environment,” in International Conference
on Systems Modelling and Management. Springer, 2020, pp. 163–179.
[19] A. Cicchetti, F. Ciccozzi, and T. Leveque, “A hybrid approach for multi-
view modeling,Electronic Communications of the EASST Proceedings
of the 5th International Workshop on Multi-Paradigm Modeling ( MPM
2011 ), vol. X, 2011.
[20] Y. Xiong, D. Liu, Z. Hu, H. Zhao, M. Takeichi, and H. Mei, “To-
wards automatic model synchronization from model transformations,”
Proceedings of the twenty-second IEEE/ACM international conference
on Automated software engineering - ASE ’07, p. 164, 2007.
[21] J. Meier, R. Kateule, and A. Winter, “Operator-based viewpoint defini-
tion.” in MODELSWARD, 2020, pp. 401–408.
[22] D. Reuling, C. Pietsch, U. Kelter, and T. Kehrer, “Towards projectional
editing for model-based spls,” in Proceedings of the 14th International
Working Conference on Variability Modelling of Software-Intensive
Systems, ser. VAMOS ’20. New York, NY, USA: Association for
Computing Machinery, 2020.
[23] “About the MOF Query/View/Transformation Specification Version
1.3.” [Online]. Available: https://www.omg.org/spec/QVT/About-QVT/
[24] P. Stevens, “Bidirectional transformations in the large,” in 2017
ACM/IEEE 20th International Conference on Model Driven Engineering
Languages and Systems (MODELS), 2017, pp. 1–11.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Projective modeling environments offer a more efficient and scalable way of supporting multiple views of large software systems than traditional, synthesis-based approaches to view-based development. However , the definition of the view projection transformations needed to create views, on demand, from the single underlying model and ensure that they remain synchronized is a complex and time-consuming process. In particular, to make views editable, the projection process involves the creation of "traces" to map view model elements to their sources in the single underlying model. While this is unavoidable for most view types, for a commonly occurring special case this level of complexity is not required. In this paper we therefore present a simpler approach, based on the OCL language, which simplifies the projection definitions for this kind of view. The approach is defined in the context of a deep, view-based modeling environment which combines support for views with multi-level modeling in order to seamlessly cover all phases of a system's life cycle.
Article
Full-text available
Multi-view modeling is a widely accepted technique to reduce the complexity in the development of modern software systems. It allows developers to focus on a narrowed portion of the specification dealing with a selected aspect of the problem. However, multi-view modeling support discloses a number of issues: on the one hand consistency management very often has to cope with semantics interconnections between the different concerns. On the other hand, providing a predefined set of views usually results as too restrictive because of expressiveness and customization needs. This paper proposes a hybrid solution for multi-view modeling based on an arbitrary number of custom views defined on top of an underlying modeling language. The aim is to benefit from the consistency by-construction granted by well-defined views while at the same time providing malleable perspectives through which the system under development can be specified.
Conference Paper
Full-text available
Program transformations play an important role in domain-specific languages and model-driven development. Tracing the execution of such transformations has well-known benefits for debugging, visualization and error reporting. In this paper, we introduce string origins, a lightweight, generic and portable technique to establish a tracing relation between the textual fragments in the input and output of a program transformation. We discuss the semantics and the implementation of string origins using the Rascal meta programming language as an example. We illustrate the utility of string origins by presenting data structures and operations for tracing generated code, implementing protected regions, performing name resolution and fixing inadvertent name capture in generated code.
Chapter
Bidirectional transformations (BX) serve to maintain consistency between different representations of related and often overlapping information, translating changes in one representation to the others. We present a brief introduction to the field, in order to provide some common background to the remainder of this volume, which constitutes the lecture notes from the Summer School on Bidirectional Transformations, held in Oxford in July 2016 as one of the closing activities of the UK EPSRC-funded project A Theory of Least Change for Bidirectional Transformations.
Conference Paper
All Enterprise Architecture Modeling (EAM) approaches revolve around the use of multiple, inter-related views to describe the properties of a system and its surrounding environment - that is, they are multi-view specification (MVS) approaches. However, there is still little consensus on how such modeling environments should be realized and on the pros and cons of the different fundamental design choices involved in building them. In this paper we identify the different design choices put forward in the literature, evaluate their mutual compatibility, and discuss the extent to which they scale up to large enterprise systems. Finally we present some additional choices and outline some of the key features that future multi-view modeling environments should ideally support.