=Paper=
{{Paper
|id=Vol-2019/me_2
|storemode=property
|title=A Graph Transformation Approach to Introducing Aspects into Software Architectures
|pdfUrl=https://ceur-ws.org/Vol-2019/me_2.pdf
|volume=Vol-2019
|authors=Md Nour Hossain,Wolfram Kahl,Tom Maibaum
|dblpUrl=https://dblp.org/rec/conf/models/HossainKM17
}}
==A Graph Transformation Approach to Introducing Aspects into Software Architectures==
https://ceur-ws.org/Vol-2019/me_2.pdf
A Graph Transformation Approach to Introducing
Aspects into Software Architectures
1st Md Nour Hossain 2nd Wolfram Kahl 3rd Tom Maibaum
Dept. of Computing and Software Dept. of Computing and Software Dept. of Computing and Software
McMaster University McMaster University McMaster University
Hamilton, Canada Hamilton, Canada Hamilton, Canada
hossaimn@mcmaster.ca kahl@mcmaster.ca tom@maibaum.org
Abstract—While aspect-oriented programming (AOP) ad- apply to a whole system [18]. Some good examples of aspects
dresses introduction of “aspects” at the code level, we argue are performance, reliability, security, authorization, synchro-
that addressing this at the level of software architecture is nization, error handling [19], [26].
conceptually more adequate, since many aspects, that is, “cross-
cutting concerns”, are formulated already in the requirements, Aspect-oriented programming [18], [21] is a complementary
and therefore can be dealt with in a more controlled manner in programming technique to generalized-procedural program-
the “earlier” phase of software architecture design. ming languages ( [18]). It allows design and code to be
We use Fiadeiro and Maibaum’s [11] precise concept of more modular to reflect the developers’ view of the system
software architectures organized as diagrams over a category by modularizing away the cross-cutting functionality from the
of component specifications, where architecture semantics is
defined as the colimit specification of the diagram. The diagram base program into a separate module (also called aspect) [7],
structure suggests aspect introduction via an appropriate variant [9], [18], [21].
of graph transformation. Single-pushout rewriting in categories Though the aspect-oriented community claims that AOP
of total homomorphisms has previously already been used for has some commendable characteristics, unfortunately, it has
different kinds of “enrichment” transformations; we identify some significant drawbacks as well. For the very same reason
“zigzag-path homomorphisms” as underlying a category where
many practically useful aspect introductions turn out to be for which [8] in his famous letter considered goto statements
such single-pushout transformations, and present the relevant harmful, [3] characterize AOP as the modern-day “OOP goto”
theorems concerning pushout existence and pushout construction. and provocatively asks “AOP considered harmful?”. Besides
Practical aspect introduction (e.g., privacy) always breaks that, rather than making the system simpler, sometimes AOP
some properties (e.g., “message can be read in transit”); there- may increase the complexity of the system (to a certain degree)
fore, aspect introduction transformations cannot be designed
to be semantics preserving. Our special categorical setting and lead to almost untraceable problems [21]. However, not
enables selective reasoning about property preservation in the only the methodology, but also having to deal with aspects
transformed specifications, and property introduction from the at the programming language level, is one of the reasons that
introduced aspects. This method enables us to detect and resolve inevitably leads AOP to many of these problems.
both conflicts and undesirable emergent behaviors that arise from We can mitigate the problems in aspect-oriented software
aspect introduction or interaction.
Index Terms—Software architecture, aspect introduction, development by introducing aspects in the earlier stages of
graph transformation software development, in particular at the software architecture
level (a comprehensible higher level abstraction of an overall
I. I NTRODUCTION system structure).
The relationship between the requirements and the compo- Introducing aspects at the architecture level streamlines the
nents of a system is not always straightforward. Regardless process of aspect-oriented software development and has some
of the size of the system, sometimes in practice a single other potential advantages. Our methodology mitigates the
requirement might not be implemented by a single compo- complexity of system evolution by making the system evolu-
nent and some components might implement more than one tion mechanical instead of manual. Aspects at the architecture
requirement [26]. This is because functional decomposition level allow developers and other stakeholders to recognize,
“cuts across” other kinds of decomposition. represent, analyze and evaluate its abstract representation at the
In spite of the wide acceptance of separation of concerns earlier stages of software development. As a consequence, the
as a good software engineering principle, most attempts to system representation at this level is more comprehensive/all
define concerns try to relate them to programs [26]. “In inclusive, and the design decisions will be clearly captured in
fact, as discussed by Jacobsen and Ng (2004), concerns are the actual code. It also induces some other benefits in terms of
really reflections of the system requirements and priorities of documentation (i.e., user, system, and design documentation)
stakeholders in the system” [26]. If we relate concerns with and cost. The technique we are using to define the system
requirements, then aspects are cross-cutting concerns/system specification from component and connector specifications
concerns that cross-cut through different core concerns or will allow us not only to reuse small components but also the
whole system, i.e., make it a part of a larger system. Finally, transformation techniques in our setting, followed by Section
we will be able to analyze the new architecture by proving IV, where we formally introduce our zigzag graph homomor-
its safety and liveness properties, check its conformance with phism concept and its instantiation for system architectures.
the old architecture, and detect conflicts, if any exists, due to Section V contains two graph transformation rules and an
feature interactions. example of aspect introduction. How to construct the result-
In this paper, we address the following problem: “How ing architecture by applying our transformation technique is
to introduce aspects at the software architecture level?”. Our explained in Section VI. The conformance check of the new
solution is to develop a technique to deal with aspects by system architecture to the old system architecture is introduced
encapsulating them as graph transformation rules on the dia- in Section VII.
gram representing the architecture and applying the aspect by In Section VIII, we discuss some related work along
performing the graph transformation. In order to implement with the similarities and dissimilarities between different ap-
our solution, we need to answer the following challenging proaches. Finally, future work and conclusions are presented
question: in Sections IX and X.
Research Question (How to Introduce Aspects). What
II. F ORMAL D EFINITION OF S YSTEM A RCHITECTURES
transformation technique will allow us to introduce aspects
at the architecture level and verify the properties that need The logic we are using was introduced by Fiadeiro and
to be preserved from the old architecture and the properties Maibaum [11]. The specification of a component is a pair
introduced by the aspect? (θ, Φ) where θ is the signature of the component and Φ is a
finite set of formulas over θ.
An effective solution to our research question depends on a A signature homomorphism σ from θ1 to θ2 identifies the
few considerations, such as how do we specify the components symbols in θ2 that correspond to the symbols in θ1 .
and connectors, and how do we define the architecture or sys- A specification homomorphism between two component
tem specification. Fiadeiro and Maibaum introduce a logic to specifications (θ1 , Φ1 ) and (θ2 , Φ2 ) is a signature homomor-
describe (specify) architecture components and connectors and phism σ from θ1 to θ2 such that for every axiom p ∈ Φ1 and
a technique to specify the system or architecture specification also for the locality axiom [11] which asserts a useful kind
as a diagram involving component and connector specifica- of local control for the state transition semantics of θ1 , the
tions [10], [11]. The logic they introduce is similar to Modal translation σ(p) is a semantic consequence of Φ2 .
Dynamic Logic, except that here actions are propositions. The Fact 1: x[11, Prop. 3.1.7] Component specifications and
language has a special logical principle called “locality”. This their specification morphisms form a category SPEC.
notion of “locality” has been used successfully to represent Following Fiadeiro and Maibaum [11], we use colimits to
the software engineering principle of data abstraction, scope define the semantics of system architectures, which are defined
and encapsulation. In order to combine the components, the to be diagrams over this category. A diagram over a category
category theoretic notion of colimit is used. The technique is a “shape graph” together with an assignment of objects
used to specify the system specification from components to vertices, and of compatible morphisms to edges — the
and connectors is independent of the underlying logic and following definitions follow standard practice:
successfully modeled software engineering principles such as Definition 1: A (directed) graph G = (V , E , src, tgt)
modularity, inheritance, incrementality, reusability, and other consists of a vertex set V , and edge set E , and the source
related concepts [11]–[13]. Therefore diagram transformation and target mappings src, tgt : E → V .
implies aspect introduction. Definition 2: A diagram in a category C is a graph
homomorphism D : I → |C | for some graph I . The graph
Since none of the present graph transformation approaches
I is called the shape graph of the diagram [2].
(i.e., double-pushout, single-pushout, hyperedge replacement
In the following, we assume a choice of colimits in SPEC,
graph grammars) are applicable in our case, in order to
and follow [11] in referring to the logical consequences of the
perform the graph transformation, we are proposing a new
axioms of a specification as its properties:
transformation technique. This technique is somewhat inspired
Definition 3: A system architecture is a diagram in the
by the hyperedge replacement graph transformation technique.
category SPEC.
Besides that, the category-theoretic notions of Kleisli category,
The properties of a system architecture are the properties
monad, and pushout also have some contribution to define the
of the colimit of the diagram.
transformation, and, finally, help us to figure out a structured
In the view that considers diagrams as functors instead of
way to introduce an aspect at the architecture level by per-
just graph homomorphisms, the standard homomorphisms con-
forming a diagram transformation.
cept for these diagrams is just that of natural transformations:
This paper will proceed as follows: In Section II we briefly Definition 4: A system architecture homomorphism H :
introduce the logic and formally define some of the essential A1 → A2 from architecture A1 to architecture A2 is a triple
terminology as a prerequisite for a better understanding of our H : (HV ,HE ,HSpecMap ) consisting of:
research goal. Then, in Section III, we illustrate our research • node mapping HV : A1 .V → A2 .V ,
challenge and analyze the application of the established graph • edge mapping HE : A1 .E → A2 .E ,
• transformation HSpecMap selecting for each node n1 : To recall, aspects are concerns (priorities of stakeholders) that
A1 .V a specification homomorphism cross-cut through different core/functional concerns. Through
the following example, we will illustrate what we mean by
HSpecMap n1 : SpecHom (A1 n1 ) (A2 (HV n1 ),
aspect introduction.
such that for each edge e : A1 .E we have the following: Consider the diagram in Figure 1. This diagram is an
architecture for sender-receiver communication. Here the com-
A2 .src(HE e) = HV (A1 .src e)
A2 .tgt(HE e) = HV (A1 .tgt e)
HSpecMap (tgt e) ◦ A1 e = A2 (HE e) ◦ HSpecMap (src e) SendTrans TransRec
HSpecMap (src e) is an isomorphism
ST2S ST2T TR2T TR2R
Definition 5: SysArchs is the category where objects are
system architectures and morphisms are system architecture
homomorphisms. Sender Trans Receiver
The last condition of Def. 4 is sufficient to ensure that
Fig. 1. Unsecured communication
SysArchs has pushouts.
With this concept of system architecture in hand, intro-
ponent Sender sends a message to the component transmitter
ducing aspects at the system architecture level is now easily
(Trans), and the transmitter transmits it to the component
understood as a kind of diagram transformation.
Receiver. In order to synchronize/communicate, Sender and
III. A SPECT I NTRODUCTION AS D IAGRAM Trans share the sub-component SendTrans. The connection
T RANSFORMATION via this sub-component along with the two arrows ST2S,
For the system architectures as defined in the previous section, ST2T identifies the commonalities between Sender and Trans,
we now explore how aspect introduction can be performed and allows them to communicate. Similarly, the components
via diagram transformation; in the current section we con- Trans and Receiver synchronize by sharing the connector
TR2T TR2R
centrate on the shape graph aspect of this. By considering ←−−− TransRec −−−→.
a concrete example, we will demonstrate that the kind of Now, consider the architecture in Figure 2. Here the com-
aspect introduction we aim for is not covered by existing graph ponent Sender sends an enciphered message to the component
transformation concepts; in the following sections, we will transmitter (Trans), and the transmitter transmits it to the
then find an appropriate formalization for the kind of diagram component Receiver, but the Receiver deciphers the message
transformation we need. before its final acceptance.
Literally, transformation of something means change in its
shape or appearance. In graph transformation, the underlying SendEnci SendTrans TransRec DecRec
entity whose form is changed is a graph, and this change is
controlled by rules r = (L → R) (often called production SE2S SE2E ST2E ST2T TR2T TR2D DR2D DR2R
rules). The graph on which we apply the transformation rule
is called the application graph (A). Rule application to some Encipherer Decipherer
Sender Trans Receiver
application graph (A) requires finding an occurrence of an
instance of a left-hand side (L). The graph that is the outcome Fig. 2. Secured communication
of the transformation is called the result graph (B).
Graph transformation is a powerful tool and it can be used So, what did we do here? We introduced a security aspect
to resemble all the common terminologies associated with into an architecture where unsecured communication existed
aspect oriented programming. The term “aspect” has the same and made the architecture “secured”. But the challenging
meaning for both AOP and the graph transformation technique, question is: How can we systematically introduce such aspects
i.e., cross-cutting concerns. A graph rewriting rule can be into software architectures? Simple cases of this, as the one
considered as an aspect program. The join point and advice shown in Figure 3, suggest that standard categorical graph
of AOP can be represented as the left-hand side and right- transformation concepts, such as the double-pushout (DPO)
hand side of a rule in the graph transformation technique. approach [4], should be applicable. Different style and color
The matching of a left-hand side into the application graph edges are used in the diagrams to make the matching obvious.
corresponds to the term pointcut. The way a transformation However, with more complex application architectures, we
step is generated is equivalent to weaving, and the combination find situations where we consider aspect introduction to still
of both the base and aspect programs is resembled by the result make sense, even though no total shape graph homomorphism
graph. exists from the left-hand side of the rule, and such total match-
The primary motivation for our work is to streamline the ings would be required both for the single-pushout approach
process of aspect-oriented software development by develop- and for the double-pushout approach to graph transformation.
ing a technique to introduce aspects in the early stages of For example, given an architecture containing a “secure”
software development, i.e., at the software architecture stage. communication channel, if we want to introduce reliability
SensorSender SendTrans TransRec BreakReceiver TR2R
TransRec ReceiverL
S2S SS2S ST2S ST2T TR2T TR2R BR2R BR2B
Sensor Sender Trans Receiver Break
egde2zigzag
source2source
Application Architecture matching target2target
HOW?
SensorSender SendEnci SendTrans TransRec DecRec BreakReceiver
TransRec DecRec
S2S SS2S SE2S SE2E ST2E ST2T TR2T TR2D DR2D DR2R BR2R BR2B
TR2D DR2D DR2R
Sensor Sender Encipherer Trans Decipherer Receiver Break
Decipherer ReceiverA
Result Architecture
Fig. 3. Introducing communication security
Fig. 5. Matching single edge to undirected path
into this architecture through the DPO approach and make the
architecture both secure and reliable, the transformation would modification by aspect introduction are not directed1 , that is,
have to look like Figure 4. edges in such paths can be traversed in any direction:
Definition 6: A zigzag path p in a graph G is a alternating
list p = hv0 , e1 , v1 , e2 , v2 , ......ek , vk i of vertices and directed
SendTrans TransRec Gluing Arch
ΦL edges, traversed in arbitrary directions, where
ST2S ST2T TR2T TR2R • the first and last element are always vertices, called the
ΦR
Sender Trans Receiver
source and the target of the path;
• k ≥ 0 is the length of p;
Rule RHS
• ei is incident with vi−1 and vi for i ∈ 1..., k − 1.
Rule LHS
The set of all zigzag paths in G will be written ZpathG .
Definition 7: Given two graphs Gi = (Vi , Ei , srci , tgti ) for
i = 1, 2, a Zpath homomorphism H : G1 → G2 consists of
.....
SendEnci SendTrans TransRec DecRec
two functions, Hv : V1 → V2 , and Hep : E1 → ZpathG2 such
SE2S SE2E ST2E ST2T TR2T TR2D DR2D DR2R that the two diagrams in Figure 6 commute.
Sender Encipherer Trans Decipherer Receiver
Hep Hep
..... E1 ZpathG 2 E1 ZpathG 2
Application Architecture
Fig. 4. Adding reliability to secure communication
src1 source2 tgt1 target2
However, we notice that there is no structure-preserving
matching XL from the “Rule LHS” to the “Application Ar- Hv Hv
V1 V2 V1 V2
chitecture”, since we cannot find in the “Application Archi-
Fig. 6. Zpath Graph Homomorphism
tecture” any match for the edges ST2S and TR2R of the
LHS. Hence, in this kind of setting, the conventional graph For the matchings as explained in the previous section,
homomorphism “does not work”, and therefore the DPO and we now allow edges to be matched to zigzag paths. In the
SPO approaches cannot be used directly. example there, this corresponds to identifying the zigzag path
The type of matching we require is pictured in Figure 5; the SendTrans → Encipherer ← SendEnci → Sender in the
fact that we need this kind of “indirect” matching is the most secured communication architecture in Figure 4 as “reasonably
obvious reason why conventional DPO/SPO is not directly matching” the communication setup ST2S : SendTrans →
applicable. Here, a single edge can map to a zigzag path and Sender in the rule LHS.
mappings between vertices are specification homomorphism. Definition 8: A system architecture Zpath homomorphism
For further illustration see section IV. is a tuple H = (HV , HZ , HSpecMap ) consisting of a shape
graph Zpath homomorphism (HV , HZ ) , and the mapping
IV. Z IGZAG PATH H OMOMORPHISMS HSpecMap that assigns to each vertex n : V1 a specification
Although we are using directed graphs to underpin our 1 A directed path is a sequence of vertices connected by directed edges
system architectures, the paths we will be considering for where all the edges are traversed along their direction.
homomorphism HSpecMap n : A1 n → A2 (HV n), such that
SendTrans TransRec
source node specifications are preserved, that is, for each edge
e : A1 .E , the specification homomorphism HSpecMap (src e) is ST2S ST2T TR2T TR2R
an isomorphism.
Note that we included no conditions on interaction between Sender Trans Receiver
the range of HSpecMap and the specification homomorphisms Left Architecture
labelling the edges of the image paths of HZ — for different
kinds of property preservation, different and rather specialized Φ
conditions are necessary, which are beyond the scope of the Right Architecture
current paper.
SendEnci SendTrans TransRec DecRec
Definition 9: We define ZpathGraphs is the category where
objects are graphs and morphisms are Zpath graph homomor- TR2D DR2D DR2R
SE2S SE2E ST2E ST2T TR2T
phisms.
There is an obvious embedding functor from Graphs into Sender Encipherer Trans Decipherer Receiver
ZpathGraphs, and this preserves pushouts:
Fig. 7. Rule: Security Introduction
Theorem 1: For every span in Graphs, a pushout in Graphs
for that span is also a pushout in ZpathGraphs.
For defining graph transformations, we now move to the Reliability Introduction:
category that allows simple connections in architectures to be
matched to zigzag paths over several components: For any given architecture where sender-receiver commu-
Definition 10: SysArchsZ is the category where objects nication exists, the rule for introducing reliability into it is
are system architectures and whose morphisms are system depicted in Figure 8. This is the rule we “tried to apply” in
architecture Zpath homomorphisms. Figure 4, where the right-hand-side is not drawn.
Theorem Theorem 1 carries over to this category:
Theorem 2: For every span in SysArchs, a pushout in SendTrans TransRec
SysArchs for that span is also a pushout in SysArchsZ.
ST2S ST2T TR2T TR2R
V. A SPECT I NTRODUCTION RULES
Sender Trans Receiver
Using the well-known example of sender-receiver communi-
cation [1] that we already employed for the examples in sec-
tion III, we will now illustrate our Zpath graph transformation Left Architecture
based technique. Φ
Definition 11: A Zpath architecture transformation rule
consists of two system architectures L and R connected by a
SendTrans TransRec
single Zpath system architecture homomorphism Φ : L → R.
Such a rule can be applied to system architecture A via the ST2S R TR2TP TR2TP TR2R
matching Zpath system architecture homomorphism Ξ : L →
Sender Res TransPlus Receiver
A with result system architecture B if a pushout in SysArchZ
of the following shape exists: TM2TP
MS R2S R Monitor
L Φ- R MS R2M TM2M
Ξ X MontrSend Res TransMontr
? ?
A Ψ- B
Right Arch
Fig. 8. Rule: Reliability Introduction
Such a pushout is also called a Zpath architecture transfor-
mation step from A to B via the rule Φ : L → R.
Introduce Reliability on Secure Communication
Security Introduction: Consider we have a secured communication architecture as
For any given architecture where sender-receiver commu- application graph, and we wish to introduce reliability on top
nication exists, if we want to introduce security into it by of this to make the architecture both secured and reliable.
performing a Zpath graph transformation, the transformation Applying the rule of Figure 8 succeeds, since this pushout
rule we will apply is shown in Figure 7. In fact, transformation in SysArchZ exists; this is shown in Figure 9.
via this rule explains the security introduction shown in However, SysArchZ does not have all pushouts, so that
Figure 3. aspect introduction via a chosen rule and matching may be
SendTrans TransRec SendTrans TransRec
ST2S ST2T TR2T TR2R ST2S R TR2TP TR2TP TR2R
Sender Trans Receiver Φ Sender Res TransPlus Receiver
TM2TP
MS R2S R Monitor
Left Architecture
Ξ MS R2M TM2M
MontrSend Res TransMontr
.....
SendEnci SendTrans TransRec DecRec
SE2S SE2E ST2E ST2T TR2T TR2D DR2D DR2R
Right Arch
Sender Encipherer Trans Decipherer Receiver
.....
Ψ
Application Architecture
χ ....... SendEnci SendTrans TransRec DecRec
SE2S R SE2E ST2E ST2TP TR2TP TR2D DR2D DR2R
Sender Res Encipherer TransPlus Decipherer Receiver
TM2TP
MS R2S R Monitor
MS R2M TM2M
MontrSend Res TransMontr
.....
Result Architecture
Fig. 9. Applying Reliability Introduction to Secured Communication via Zigzag Matching
impossible (if no commuting square completing this span L2 → R2 have pushouts in SysArchsZ, then A ← L → R
exists), or may require additional design decisions (if no single has a pushout in SysArchsZ, too.
“least” such commuting square exists).
Nevertheless, even if both rule and matching map LHS ΦR
edges to non-trivial zigzag paths, SysArchZ pushouts still exist, Φ0 R0 R2
as we investigate in more detail in the next section.
L0 L2
VI. A MALGAMATING SysArchZ P USHOUTS
ΞL R1 R
Although SysArchZ does not have all pushouts, many aspect X2
introduction rule applications are still possible, and can be L1 L
completed via pushouts, due to the typical shape of aspect
introduction rules that can be observed already in the examples
provided so far: The left-hand side is usually a single zigzag
path, and some of the edges of the LHS are replaced with P0 P2
zigzag paths on the RHS, while other LHS edges are pre- Ξ1
served. These preserved edges can be matched to zigzag paths
A0 A2
XP
without creating conflicts — technically, without creating a
rule-matching-span that has no pushout. P1 P
The general reason for this is that SysArchZ pushouts can Ψ
be amalgamated along SysArch pushouts. A1 A
ΨA
Theorem 3: If the span A ← L → R in SysArchZ can be
factored via three pushouts in SysArchs as shown in Figure 10,
and if the two SysArchsZ spans A1 ← L1 → R1 and A2 ← Fig. 10. Amalgamation Theorem
This amalgamation theorem allows us to decompose prospec- for the components, a pushout obviously always exists, as
tive rule application pushouts of rules like those of Figs. 7 and indicated in Figure 12.
8 into little pieces induced by the subgraphs of the left-hand
side induced by single edges, or by node sets. We discuss the
different kinds of pieces in Sects. VI-A–VI-C. ST IR1 IR2 ST
Φ
The situation is further simplified if we restrict ourselves to ST2S
S S CR1 CR2
architectures with a connector-component bipartition, where
each node of the shape graph either is a “connector” that L R
Ξ χ
has only outgoing edges, or is a “component” that has only
incoming edges. For system architecture (Z-path) homomor- ST IR1 IR2 ST
phisms, we then restrict the specification homomorphisms Ψ
ST2S
associated with source nodes of edges in the source diagram S S CR1 CR2
to be isomorphisms. In this paper, for the sake of simplicity
we strengthen this restriction further to only allow identity A Res
homomorphisms. For example, source2source in Figure 5 has
to be an identity. Fig. 12. Component addition / identity matching
A. Discrete LHS If we restrict both rule and matching to non-zigzag homo-
morphisms, but allow the target of the LHS edge to be mapped
Working with subgraphs induced by node sets of the left-
with arbitrary specification homomorphisms on both sides, we
hand side is necessary for separating the context of a rule
get an architecture pushout where that target is assigned the
application from the modifications introduced by the rule, and
corresponding specification pushout, as sketched in Figure 13.
also for parts of the RHS that are not in the (zigzag-) image
of the LHS, as for example the monitor components of the
reliability introduction rules of Figure 8, for which we show
the corresponding rule fragment in Figure 11. ST ST
Φ
ST2S ST2SR
S SR
Sender Trans
L R
Ξ χ
Left Architecture
Φ ST ST
ST2SA Ψ
ST2SAR
SA SAR
Sender Res TransPlus
Monitor
MS R2S R TM2TP A Res
MS R2M TM2M
MontrSend Res TransMontr
Fig. 13. Component expansion both ways
Right Arch
These two cases can actually be combined, as depicted in
Fig. 11. Discrete-LHS Fragment of Reliab. Intro. Figure 14:
Theorem 5: A SysArchsZ span A Ξ L Φ- R where
In the situations we encountered so far, the following (rather
• the shape of L is • → •,
obvious) theorem is sufficient, although it excludes context that
• one of Ξ and Φ is a non-zigzag homomorphism,
is attached to connectors:
• the source node of the edge in L is associated with identity
Theorem 4: A SysArchsZ span A Ξ L Φ- R where L is
discrete (no edges) and both Ξ and Φ do not map any node specification homomorphisms in both Ξ and Φ,
of L to a source node of an edge in A respectively R always always has a pushout in SysArchsZ.
has a pushout in SysArchsZ. (The identity specification homomorphisms can be replaced
with isomorphisms, which however would make the drawings
B. Unproblematic Single-Edge LHS more confusing.)
If a single-edge LHS is mapped via a non-zigzag homomor- For the above scenario in Figure 14, the component SAR
Ξ Φ
phism containing only identity specification homomorphism is a pushout construct of the span SA ← − S − → SR . Other
Whether this transformation is possible or not depends on
ST IR1 IR2 ST
Φ the relationship between the connectors associated to establish
S
ST2S
SR CR1 CR2
a connection (in the result architecture) between the appli-
cation and the right hand-side architecture. A connection is
L R established in the result architecture by breaking two connec-
Ξ χ
tions, one each for the application and the right hand-side
ST IR1 IR2 ST architecture. In the above example, for Res-1 the connection
ST2SA
Ψ SEA → SA in the application architecture and ST → ER in
SA SAR CR1 CR2 the right hand side architecture got disconnected to establish
a connection SEA toER in the result architecture. This transfor-
Res
A
mation is obvious if a specification homomorphism SEA → ST
exists. In the other case, i.e., Res-2, the obvious transformation
Fig. 14. Component addition / component expansion
depends on the existence of the specification homomorphism
SE → ST. If neither of the homomorphisms exists, then we
have to introduce new components and connectors to let the
components, i.e., CR1 ,CR2 are direct copies of the preimages transformation take place and one of this scenario is pictured
from the right architecture. All the connectors, i.e., IR1 ,IR2 ,ST by Res-3 of the figure 15.
in the result architecture are also the direct copies of their Theorem 6: For “both-relax” case spans, the SysArchsZ
preimages. category does not have any pushouts.
We have two potential pushout candidates with minimal
C. Ambiguous Matchings components and connectors, but neither of them is a pushout
Now, let us say, an edge is relaxed in both the Application object. There are system architecture homomorphisms that
and the Right hand side graph (relax-relax) by adding a couple exist between them but they are not unique up to isomorphism.
of components and connectors and we want to contract them to In reality these two architectures could be completely different.
a single zigzag path. If we preserve the connector-component Though we do not have a pushout, if we select/consider one
alternating pattern and consider the mapping between archi- of our design decisions, then the construction of the result
tectures as a System Architecture Zpath Homomorphism then architecture would be systematic and it could be one of the
there are only two possibilities to contract them to a single pushout candidates.
zigzag path with the minimal components and connectors such
that the above diagram commutes. These two possibilities are D. User-Guided Rule Application
as follows: As far as pushouts can be constructed for single edges as
1) Disconnect the target of the Application architecture and discussed above, these can be amalgamated for rules with more
the source of the Right hand-side architecture and glue complex left-hand sides due to Theorem Theorem 3.
them to a single zigzag path (Res-2). For a defined set of production rules (e.g., security introduc-
2) Disconnect the source of the Application architecture and tion, reliability introduction) and given an application archi-
the target of the Right hand-side architecture and glue tecture, if we apply our transformation technique, in all cases
them together (Res-1). except one (Sect. VI-C), the result architecture we obtain after
So, in this scenario, two design choices are available and the the transformation is a pushout object. If an aspect introduction
result architecture varies depending on the design decision matches an LHS-edge to a zigzag path with new components
(choice) one makes. in the right-hand side architecture, and the matching of the
edge into the application architecture is also a zigzag path,
then the category SysArchsZ does not have a pushout for
ST SER ST
Φ the span consisting of that rule with that matching. In this
ST2S
S SR ER case, the transformation is semi-automatic. The designer will
Ξ L χ R have to make design decisions, which may result in different
desirable and undesirable properties becoming valid for the
SEA ST Ψ SER SEA ST
transformation result.
SA EA SAR ER EA
VII. C ONFORMANCE C HECK
A Res-1
One of the great advantages of our research work is that
SEA EN SER ST SEA SER ST
it makes the analysis of the system architecture properties
SAR EA New ER SAR EA ER feasible.
Res-3 Res-2
Conformance of the result system architecture with the
application system architecture is not straight-forward. Fig-
ure 16 illustrates this statement: A system architecture
Fig. 15. Component addition both ways Zpath homomorphism between two system architectures, e.g.,
system arch. zigzag hom. which allowed them to write a rule on a single model instead
LHS RHS of repeating unchanged elements in both the LHS and the RHS.
s.a.z.hom. Morin et al. [24] worked on a generic AOM approach
s.a.z.hom.
called GeKo (generic composition with Kermeta) to weave
aspects into any model with a well-defined metamodel. Here,
two models, the base and the advice are weaved with the
system arch. zigzag hom. help of a third model and two morphisms. The third mode
Application Result
. is called the pointcut, and the two morphisms are defined
om
s. a
rch rch. h from the pointcut to the base and the advice respectively. The
.h s. a morphisms prescribe the deletion, preservation/edition, and
om
colimit . Host Arch colimit addition. This weaving process is similar to defining a rule in
the Double-pushout graph transformation approach explained
colimit in [4].
The work we are doing is to introduce aspects at the
specification hom. specification hom.
System SpecApp System SpecHost System SpecRes earlier phase of the software development life-cycle, i.e., in
the architecture level, by performing a graph transformation.
Although in terms of goals, we have some similarity with the
Fig. 16. System Architecture and System Specification work of the AOM community, our approach is completely
different from their approaches. The way [20], [24] explained
S.A.Z. Hom.
aspects contradicts their traditional definition. A couple of vital
Application −−−−−−−→ Result, does not necessarily imply points that make our method divergent from AOM weaving are
the existence of a specification homomorphism between the the following:
colimits of these diagrams. Proving properties of the result • Weaving is not a general transformation; it is a special
system architecture to check its conformance with the applica- type of transformation. It is usually a non-automatic
tion system architecture is not exhaustive either. Depending on laborious operation where both base and aspect models
different scenarios, how aspect introduction modifies an edge, get composed to get a weaved model. In contrast, a
in some cases we can systematically (even automatically) transformation is automatic where predefined rules are
check the conformance of the new result system architecture applied to a bigger application system.
to the old application system architecture without proving • Most of the above AOM approaches claim that they
any proof obligations. Propagation of RHS properties into the can detect conflicts (unavailability to weave an aspect
result architecture, also conforms to the same scenario. with a woven base) and resolve them by sequencing
aspects or changing the rules. But the way they define the
VIII. R ELATED W ORK conflict does not work for system architecture. After in-
troducing an aspect to an application architecture, further
The paradigm of aspect-oriented software development aspect introduction to the resultant architecture by general
(AOSD) first appeared at the University of Twente in the weaving/transformation technique might be unavailable to
Netherlands at the code level. However, work in aspects is some of the re-defined rules though neither the rules nor
no longer limited to the implementation phase of the software the resultant architecture is wrong.
development. Over the last decade, the AOSD community One of the potential solutions to this problem is to introduce
has tried to transfer this idea into earlier phases of the a new transformation technique by keeping the nature of
software development life cycle; namely in domain analysis, aspect introductions in mind. Our Zpath graph transformation
requirement analysis, architecture design, and modeling. technique is capable of addressing this issue. Besides that, it
The modeling community is doing a large amount of work allows us to systematically verify the conformance (property
to weave aspects in models, specifically, UML models [5], preservation) of the old system architecture to the new.
[14]–[17], [22]–[25], [27]. Since model weaving is a special
case of transformation; some interesting works in weaving IX. F UTURE W ORK
aspects in models are explained in the following sections along Besides identifying the “Zigzag-path homomorphisms” and
with their similarities and dissimilarities with our work. elaborating the “Zigzag transformation”, we have provided
Whittle and Jayaraman [27] developed an aspect-oriented some meta-theorems that make it (sometimes) unnecessary to
modeling tool MATA (Modeling Aspects Using a Transforma- re-prove properties for transformation results, or make it easier
tion Approach) that uses an existing graph transformation tech- to obtain result properties from component and aspect prop-
nique over the concrete syntax of the UML modeling language erties. From our example, we have experienced that proving
to weave aspects. In order to write a graph rule, rather than the well-definedness and validating the properties of system
using general LHS and RHS, they defined three stereotypes, architecture is a tedious redundant job. So, we are currently
i.e., create, delete, and context (unchanged), (similar to the developing some tool support that will make our methodology
approach applied in VIATRA developed by Csertán et al. [6]) mechanical and make our evaluation and validation process
feasible. Since our methodology is independent of the underly- [15] R. France, F. Fleurey, R. Reddy, B. Baudry, and S. Ghosh. Providing
ing logic, one of the potential future steps would be application support for model composition in metamodels. In Enterprise Distributed
Object Computing Conference, 2007. EDOC 2007. 11th IEEE Interna-
of the theory in industrial settings by applying widely used tional, pages 253–253. IEEE, 2007.
architecture languages, e.g., AADL, EAST-ADL. [16] I. Jacobson and P.-W. Ng. Aspect-oriented software development with
use cases. Addison-Wesley object technology series. Addison-Wesley
Professional, 2004.
X. C ONCLUSION [17] P. Jayaraman, J. Whittle, A. M. Elkhodary, and H. Gomaa. Model
composition in product lines and feature interaction detection using
Working with aspect introduction at the architecture level critical pair analysis. In International Conference on Model Driven
has many benefits including for documentation, product risk Engineering Languages and Systems, pages 151–165. Springer, 2007.
management, understandability, reusability and maintainabil- [18] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M.
Loingtier, and J. Irwin. Aspect-oriented programming. Springer, 1997.
ity. The nature of aspects makes it impossible to apply any of [19] G. Kiczales and M. Mezini. Aspect-oriented programming and modular
the conventional graph transformation approaches, since those reasoning. In Proceedings of the 27th international conference on
work with exact matchings. Our “Zigzag matching” and the Software engineering, pages 49–58. ACM, 2005.
[20] J. Kienzle, W. Al Abed, and J. Klein. Aspect-oriented multi-view
“Zigzag transformation” methodology streamline the process modeling. In Proceedings of the 8th ACM international conference on
of software system evolution by making aspect introduction Aspect-oriented software development, pages 87–98. ACM, 2009.
into system architectures systematic. Besides, in terms of [21] J. Laukkanen. Aspect-oriented programming, 2008.
[22] B. Morin, O. Barais, and J.-M. Jézéquel. Weaving aspect configurations
property preservation, it makes the conformance check of for managing system variability. In 2nd International Workshop on
the new system architecture along with the detection and Variability Modelling of Software-intensive Systems, 2008.
resolution of conflicts and undesirable emergent behaviors [23] B. Morin, O. Barais, J.-M. Jézéquel, and R. Ramos. Towards a generic
aspect-oriented modeling framework. In Models and Aspects workshop,
semi-automatic. at ECOOP 2007, 2007.
[24] B. Morin, J. Klein, O. Barais, and J.-M. Jézéquel. A generic weaver
R EFERENCES for supporting product lines. In Proceedings of the 13th international
workshop on Early Aspects, pages 11–18. ACM, 2008.
[1] N. Aguirre, T. Maibaum, and P. Alencar. Extension morphisms for [25] C. Siobhan and B. Elisa. Aspect-oriented analysis and design: The
CommUnity. In K. Futatsugi, J.-P. Jouannaud, and J. Meseguer, editors, Theme approach, 2005.
Algebra, Meaning, and Computation: Essays dedicated to Joseph A. [26] I. Sommerville. Software Engineering. International Computer Science
Goguen on the Occasion of His 65th Birthday, volume 4060 of LNCS, Series. Pearson, 2011.
pages 173–193, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg. [27] J. Whittle and P. Jayaraman. MATA: A tool for aspect-oriented modeling
[2] M. Barr and C. Wells. Category theory for computing science, vol- based on graph transformation. In Models in Software Engineering:
ume 49. Prentice Hall New York, 1990. Workshops and Symposia at MoDELS 2007, Reports and Revised
[3] C. Constantinides, T. Skotiniotis, and M. Stoerzer. AOP considered Selected Papers, volume 5002 of LNCS, pages 16–27. Springer, 2008.
harmful. In 1st European Interactive Workshop on Aspect Systems
(EIWAS), 2004.
[4] A. Corradini, U. Montanari, F. Rossi, H. Ehrig, R. Heckel, and M. Löwe.
Algebraic approaches to graph transformation — Part I: Basic concepts
and double pushout approach. In Handbook of Graph Grammars, pages
163–246, 1997.
[5] T. Cottenier, A. Van Den Berg, and T. Elrad. The Motorola WEAVR:
Model weaving in a large industrial context. Aspect-Oriented Software
Development (AOSD), Vancouver, Canada, 32:44, 2007.
[6] G. Csertán, G. Huszerl, I. Majzik, Z. Pap, A. Pataricza, and D. Varró.
VIATRA — visual automated transformations for formal verification
and validation of UML models. In Automated Software Engineering,
2002. Proceedings. ASE 2002. 17th IEEE International Conference on,
pages 267–270. IEEE, 2002.
[7] J. A. Dı́az Pace and M. R. Campo. Analyzing the role of aspects in
software design. Communications of the ACM, 44(10):66–73, 2001.
[8] E. W. Dijkstra. Letters to the editor: go to statement considered harmful.
Communications of the ACM, 11(3):147–148, 1968.
[9] T. Elrad, M. Aksit, G. Kiczales, K. J. Lieberherr, and H. Ossher.
Discussing aspects of AOP. Communications of the ACM, 44(10):33–38,
2001.
[10] J. Fiadeiro and T. Maibaum. Towards object calculi. In Information
Systems— Correctness and Reusability, Workshop IS-CORE, volume 91,
pages 129–178, 1990.
[11] J. Fiadeiro and T. Maibaum. Temporal theories as modularisation units
for concurrent system specification. Formal aspects of Computing,
4(3):239–272, 1992.
[12] J. Fiadeiro and T. Maibaum. A mathematical toolbox for the software
architect. In Software Specification and Design, 1996., Proceedings of
the 8th International Workshop on, pages 46–55. IEEE, 1996.
[13] J. L. Fiadeiro and T. Maibaum. Interconnecting formalisms: Supporting
modularity, reuse and incrementality. ACM SIGSOFT Software Engi-
neering Notes, 20(4):72–80, 1995.
[14] F. Fleurey, B. Baudry, R. France, and S. Ghosh. A generic approach for
automatic model composition. In International Conference on Model
Driven Engineering Languages and Systems, pages 7–15. Springer,
2007.