SEKE 2012 Proceedings - Knowledge Systems Institute

deployment view) that is r eified in a physical network.
Properties such as reliability and bandwidth of this connector
may be subject to change over time. This kind of changes in
properties of architectural elements is often ignored in the
architectural models. We advocate that the evolution of these
properties should be reflected in the models, as it allows us to
(i) monitor the evolution of these properties, which in turn can
be used to t rigger adaptations, and to (ii) analyze the actual
characteristics of a system using its architectural models. This
alignment between what was designed (the initial model) and
the actual implementation/deployment can help identify and
reduce architectural erosion [15]. A particular research field
that considers the evolution of the properties of architectural
elements is that of service-oriented architectures. For instance
[4][8] match services properties with non-functional
requirements for selecting which services to use.
Some modeling languages that are not considered ADL can
also be used for architectural modeling. Architectural behavior
has been defined in languages such as Statecharts,
ROOMcharts, SDL, Z, Use-Case, Use-Case Maps, Sequence
diagrams, Collaboration diagrams and MSCs [2]. For instance,
Statecharts can be used to describe the different states of a
component, as well the transitions between them; Use-Case
diagrams can express the different activities performed by an
element of a system, from the user’ point-of-view. Thus, when
dealing with architectural evolution, we cannot neglect these
languages. Similarly, the use of goal-based notations such as
Kaos and i* for architectural modeling has been promoted in
some research endeavors [12][18].
III. CONCEPTUAL FRAMEWORK
Based on a review of the architectural modeling approaches
mentioned in the previous section, we devised a framework for
empowering architectural evolution through model
transformations, which can be applied to different modeling
languages. This framework comprises a conceptual model,
used to classify the different constructs of a modeling language,
as well as a set of basic architectural evolution operations
defined upon the conceptual model.
Architectural models are composed of architectural
elements – e.g., components, services, classes and states – and
links that define connections between these elements – e.g.,
connectors, requests, association links and events. Both
elements and links may have properties, which can be used to
provide a detailed description of elements and links. Moreover,
elements may have sub-elements, i.e., elements that are part of
them. Fig. 1 shows a model that represents these concepts.
Using the graph terminology, elements can be considered typed
nodes, links can be considered directed edges and properties
can be considered labels of a node/edge.
This conceptual model can be applied to different
architectural description languages, as well as to other
modeling languages that are used for architectural modeling
(e.g., Statecharts, Sequence diagrams, Use-Case and i*). The
(meta-)metamodel of the VPM language [3] resembles our
conceptual model, being essentially composed by elements
(entities) and links (relations) but neglecting their properties.
That work provides a metamodeling language, whereas our
conceptual model is used to classify the constructs of existing
Figure 1. Conceptual Model
metamodels in o rder to guide the creation of transformation
rules. Thus, our approach is n ot tied to any particular
metamodeling nor transformation specification language.
A. Basic Architectural Evolution Operations
This conceptual model enabled us to define 7 basic
operations required to s upport architectural evolution with
model transformations: Add Element, Remove Element, Add
Link, Remove Link, Add Property, Remove Property and
Change Property. These operations support the 2 different
types of architectural model changes described in Section 2 –
structural/topology changes and property changes. These
operations are described next.
1) Add Element
Inserts a new element in a model. A particular case is when
the new element is a sub-element of another element. Usually,
an element has a name or an identifier.
2) Remove Element
Deletes an element from a model. Caution should be taken
when removing elements from a model, as it is important to
maintain the integrity of the model. For instance, if an element
is removed, it is most likely that it will also be necessary to
remove the links associated with that element.
3) Add Link
Inserts a new link connecting elements of the model.
4) Remove Link
Deletes a link from a model. Here again caution should be
taken, as elements without links may result in invalid models.
5) Add Property
Inserts a property in an element or in a link. Usually, the
property has a name or an identifier, as well as other attributes
such as value, default value and type.
6) Remove Property
Deletes a property from an element or from a link.
7) Change Property
Modifies the content of an attribute of a property, e.g., the
actual value, or its type. A similar effect could be achieved by
combining the Remove Property and the Add Property
operations. However, as modifying a property is conceptually
449