-While aspect-oriented programming (AOP) addresses introduction of “aspects” at the code level, we argue that addressing this at the level of software architecture is conceptually more adequate, since many aspects, that is, “crosscutting concerns”, are formulated already in the requirements, and therefore can be dealt with in a more controlled manner in the “earlier” phase of software architecture design. We use Fiadeiro and Maibaum's [11] precise concept of software architectures organized as diagrams over a category of component specifications, where architecture semantics is defined as the colimit specification of the diagram. The diagram structure suggests aspect introduction via an appropriate variant of graph transformation. Single-pushout rewriting in categories of total homomorphisms has previously already been used for different kinds of “enrichment” transformations; we identify “zigzag-path homomorphisms” as underlying a category where many practically useful aspect introductions turn out to be such single-pushout transformations, and present the relevant theorems concerning pushout existence and pushout construction. Practical aspect introduction (e.g., privacy) always breaks some properties (e.g., “message can be read in transit”); therefore, aspect introduction transformations cannot be designed to be semantics preserving. Our special categorical setting enables selective reasoning about property preservation in the transformed specifications, and property introduction from the introduced aspects. This method enables us to detect and resolve both conflicts and undesirable emergent behaviors that arise from aspect introduction or interaction. Index Terms-Software architecture, aspect introduction, graph transformation
I. INTRODUCTION
The relationship between the requirements and the
components of a system is not always straightforward. Regardless
of the size of the system, sometimes in practice a single
requirement might not be implemented by a single
component and some components might implement more than one
requirement [
In spite of the wide acceptance of separation of concerns
as a good software engineering principle, most attempts to
define concerns try to relate them to programs [
Aspect-oriented programming [
Though the aspect-oriented community claims that AOP
has some commendable characteristics, unfortunately, it has
some significant drawbacks as well. For the very same reason
for which [
We can mitigate the problems in aspect-oriented software development by introducing aspects in the earlier stages of software development, in particular at the software architecture level (a comprehensible higher level abstraction of an overall system structure).
Introducing aspects at the architecture level streamlines the process of aspect-oriented software development and has some other potential advantages. Our methodology mitigates the complexity of system evolution by making the system evolution mechanical instead of manual. Aspects at the architecture level allow developers and other stakeholders to recognize, represent, analyze and evaluate its abstract representation at the earlier stages of software development. As a consequence, the system representation at this level is more comprehensive/all inclusive, and the design decisions will be clearly captured in the actual code. It also induces some other benefits in terms of documentation (i.e., user, system, and design documentation) and cost. The technique we are using to define the system specification from component and connector specifications 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, we will be able to analyze the new architecture by proving its safety and liveness properties, check its conformance with the old architecture, and detect conflicts, if any exists, due to feature interactions.
In this paper, we address the following problem: “How to introduce aspects at the software architecture level?”. Our solution is to develop a technique to deal with aspects by encapsulating them as graph transformation rules on the diagram representing the architecture and applying the aspect by performing the graph transformation. In order to implement our solution, we need to answer the following challenging question:
Research Question (How to Introduce Aspects). What transformation technique will allow us to introduce aspects at the architecture level and verify the properties that need to be preserved from the old architecture and the properties introduced by the aspect?
An effective solution to our research question depends on a
few considerations, such as how do we specify the components
and connectors, and how do we define the architecture or
system specification. Fiadeiro and Maibaum introduce a logic to
describe (specify) architecture components and connectors and
a technique to specify the system or architecture specification
as a diagram involving component and connector
specifications [
Since none of the present graph transformation approaches (i.e., double-pushout, single-pushout, hyperedge replacement graph grammars) are applicable in our case, in order to perform the graph transformation, we are proposing a new transformation technique. This technique is somewhat inspired by the hyperedge replacement graph transformation technique. Besides that, the category-theoretic notions of Kleisli category, monad, and pushout also have some contribution to define the transformation, and, finally, help us to figure out a structured way to introduce an aspect at the architecture level by performing a diagram transformation.
This paper will proceed as follows: In Section II we briefly introduce the logic and formally define some of the essential terminology as a prerequisite for a better understanding of our research goal. Then, in Section III, we illustrate our research challenge and analyze the application of the established graph transformation techniques in our setting, followed by Section IV, where we formally introduce our zigzag graph homomorphism concept and its instantiation for system architectures. Section V contains two graph transformation rules and an example of aspect introduction. How to construct the resulting architecture by applying our transformation technique is explained in Section VI. The conformance check of the new system architecture to the old system architecture is introduced in Section VII.
In Section VIII, we discuss some related work along with the similarities and dissimilarities between different approaches. Finally, future work and conclusions are presented in Sections IX and X.
II. FORMAL DEFINITION OF SYSTEM ARCHITECTURES
The logic we are using was introduced by Fiadeiro and
Maibaum [
symbols in 2 that correspond to the symbols in 1.
specifications ( 1; 1) and ( 2; 2) is a signature
homomorphism from 1 to 2 such that for every axiom p 2 1 and
also for the locality axiom [
Fact 1: x[11, Prop. 3.1.7] Component specifications and their specification morphisms form a category SPEC.
Following Fiadeiro and Maibaum [
Definition 1: A (directed) graph G = (V ; E ; src; tgt) consists of a vertex set V , and edge set E , and the source and target mappings src; tgt : E ! V .
Definition 2: A diagram in a category C is a graph
homomorphism D : I ! jC j for some graph I . The graph
I is called the shape graph of the diagram [
In the following, we assume a choice of colimits in SPEC,
and follow [
category SPEC.
The properties of a system architecture are the properties of the colimit of the diagram.
In the view that considers diagrams as functors instead of just graph homomorphisms, the standard homomorphisms concept for these diagrams is just that of natural transformations:
H : (HV ,HE ,HSpecMap) consisting of: node mapping HV : A1:V ! A2:V , edge mapping HE : A1:E ! A2:E , transformation HSpecMap selecting for each node n1 : A1:V a specification homomorphism
such that for each edge e : A1:E we have the following:
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) is an isomorphism
Definition 5: SysArchs is the category where objects are system architectures and morphisms are system architecture homomorphisms.
The last condition of Def. 4 is sufficient to ensure that SysArchs has pushouts.
With this concept of system architecture in hand, introducing aspects at the system architecture level is now easily understood as a kind of diagram transformation.
III. ASPECT INTRODUCTION AS DIAGRAM
TRANSFORMATION For the system architectures as defined in the previous section, we now explore how aspect introduction can be performed via diagram transformation; in the current section we concentrate on the shape graph aspect of this. By considering a concrete example, we will demonstrate that the kind of aspect introduction we aim for is not covered by existing graph transformation concepts; in the following sections, we will then find an appropriate formalization for the kind of diagram transformation we need.
Literally, transformation of something means change in its shape or appearance. In graph transformation, the underlying entity whose form is changed is a graph, and this change is controlled by rules r = (L ! R) (often called production rules). The graph on which we apply the transformation rule is called the application graph (A). Rule application to some application graph (A) requires finding an occurrence of an instance of a left-hand side (L). The graph that is the outcome of the transformation is called the result graph (B).
Graph transformation is a powerful tool and it can be used to resemble all the common terminologies associated with aspect oriented programming. The term “aspect” has the same meaning for both AOP and the graph transformation technique, i.e., cross-cutting concerns. A graph rewriting rule can be considered as an aspect program. The join point and advice of AOP can be represented as the left-hand side and righthand side of a rule in the graph transformation technique. The matching of a left-hand side into the application graph corresponds to the term pointcut. The way a transformation step is generated is equivalent to weaving, and the combination of both the base and aspect programs is resembled by the result graph.
The primary motivation for our work is to streamline the process of aspect-oriented software development by developing a technique to introduce aspects in the early stages of software development, i.e., at the software architecture stage. To recall, aspects are concerns (priorities of stakeholders) that cross-cut through different core/functional concerns. Through the following example, we will illustrate what we mean by aspect introduction.
Consider the diagram in Figure 1. This diagram is an architecture for sender-receiver communication. Here the component Sender sends a message to the component transmitter (Trans), and the transmitter transmits it to the component Receiver. In order to synchronize/communicate, Sender and Trans share the sub-component SendTrans. The connection via this sub-component along with the two arrows ST2S, ST2T identifies the commonalities between Sender and Trans, and allows them to communicate. Similarly, the components Trans and Receiver synchronize by sharing the connector TR2T TransRec TR2!R.
Now, consider the architecture in Figure 2. Here the component Sender sends an enciphered message to the component transmitter (Trans), and the transmitter transmits it to the component Receiver, but the Receiver deciphers the message before its final acceptance.
SE2S SE2E ST2E ST2T TR2T TR2D DR2D DR2R
So, what did we do here? We introduced a security aspect
into an architecture where unsecured communication existed
and made the architecture “secured”. But the challenging
question is: How can we systematically introduce such aspects
into software architectures? Simple cases of this, as the one
shown in Figure 3, suggest that standard categorical graph
transformation concepts, such as the double-pushout (DPO)
approach [
However, with more complex application architectures, we find situations where we consider aspect introduction to still make sense, even though no total shape graph homomorphism exists from the left-hand side of the rule, and such total matchings would be required both for the single-pushout approach and for the double-pushout approach to graph transformation.
For example, given an architecture containing a “secure” communication channel, if we want to introduce reliability S2S SS2S ST2S ST2T TR2T
TR2R BR2R BR2B into this architecture through the DPO approach and make the architecture both secure and reliable, the transformation would have to look like Figure 4.
However, we notice that there is no structure-preserving matching XL from the “Rule LHS” to the “Application Architecture”, since we cannot find in the “Application Architecture” any match for the edges ST 2S and TR2R of the LHS. Hence, in this kind of setting, the conventional graph homomorphism “does not work”, and therefore the DPO and SPO approaches cannot be used directly.
The type of matching we require is pictured in Figure 5; the fact that we need this kind of “indirect” matching is the most obvious reason why conventional DPO/SPO is not directly applicable. Here, a single edge can map to a zigzag path and mappings between vertices are specification homomorphism. For further illustration see section IV.
IV. ZIGZAG PATH HOMOMORPHISMS
Although we are using directed graphs to underpin our system architectures, the paths we will be considering for
source2source matching egde2zigzag target2target
TR2D DR2D DR2R
modification by aspect introduction are not directed1, that is, 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; vki of vertices and directed edges, traversed in arbitrary directions, where the first and last element are always vertices, called the source and the target of the path; k 0 is the length of p; ei is incident with vi 1 and vi for i 2 1:::; k 1.
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 two functions, Hv : V1 ! V2, and Hep : E1 ! ZpathG2 such that the two diagrams in Figure 6 commute.
E1
Hep
Hv E1 V1
Hep
Hv src1 source2 tgt1
target2
V2 V1 Fig. 6. Zpath Graph Homomorphism V2
For the matchings as explained in the previous section, we now allow edges to be matched to zigzag paths. In the example there, this corresponds to identifying the zigzag path SendTrans ! Encipherer SendEnci ! Sender in the secured communication architecture in Figure 4 as “reasonably matching” the communication setup ST 2S : SendTrans ! Sender in the rule LHS.
is a tuple H = (HV ; HZ ; HSpecMap) consisting of a shape graph Zpath homomorphism (HV ; HZ ) , and the mapping HSpecMap that assigns to each vertex n : V1 a specification 1A directed path is a sequence of vertices connected by directed edges where all the edges are traversed along their direction. homomorphism HSpecMap n : A1 n ! A2 (HV n), such that source node specifications are preserved, that is, for each edge e : A1:E , the specification homomorphism HSpecMap(src e) is an isomorphism.
Note that we included no conditions on interaction between the range of HSpecMap and the specification homomorphisms 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 current paper.
Definition 9: We define ZpathGraphs is the category where objects are graphs and morphisms are Zpath graph homomorphisms.
There is an obvious embedding functor from Graphs into ZpathGraphs, and this preserves pushouts:
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 category that allows simple connections in architectures to be matched to zigzag paths over several components:
Definition 10: SysArchsZ is the category where objects are system architectures and whose morphisms are system architecture Zpath homomorphisms.
Theorem Theorem 1 carries over to this category: Theorem 2: For every span in SysArchs, a pushout in SysArchs for that span is also a pushout in SysArchsZ.
V. ASPECT INTRODUCTION RULES
Using the well-known example of sender-receiver
communication [
consists of two system architectures L and R connected by a single Zpath system architecture homomorphism : L ! R.
Such a rule can be applied to system architecture A via the matching Zpath system architecture homomorphism : L ! A with result system architecture B if a pushout in SysArchZ of the following shape exists:
L - R
X ? ?
A - B
mation step from A to B via the rule : L ! R.
For any given architecture where sender-receiver communication exists, if we want to introduce security into it by performing a Zpath graph transformation, the transformation rule we will apply is shown in Figure 7. In fact, transformation via this rule explains the security introduction shown in Figure 3.
TR2T
TR2R
For any given architecture where sender-receiver communication exists, the rule for introducing reliability into it is depicted in Figure 8. This is the rule we “tried to apply” in Figure 4, where the right-hand-side is not drawn.
SendTrans
TransRec ST2S ST2T
TR2T Sender
Trans
TR2R
Receiver SendTrans
TransRec ST2S R
TR2TP
TR2TP Sender Res
MS R2S R
MS R2M MontrSend Res
Left Architecture TransPlus Monitor
TM2M
TR2R
Receiver
TM2TP TransMontr
Right Arch
Fig. 8. Rule: Reliability Introduction
Consider we have a secured communication architecture as application graph, and we wish to introduce reliability on top of this to make the architecture both secured and reliable. Applying the rule of Figure 8 succeeds, since this pushout in SysArchZ exists; this is shown in Figure 9.
However, SysArchZ does not have all pushouts, so that aspect introduction via a chosen rule and matching may be
TR2TP
TR2TP impossible (if no commuting square completing this span exists), or may require additional design decisions (if no single “least” such commuting square exists).
Nevertheless, even if both rule and matching map LHS edges to non-trivial zigzag paths, SysArchZ pushouts still exist, as we investigate in more detail in the next section.
VI. AMALGAMATING SysArchZ PUSHOUTS
Although SysArchZ does not have all pushouts, many aspect introduction rule applications are still possible, and can be 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 zigzag paths on the RHS, while other LHS edges are preserved. These preserved edges can be matched to zigzag paths without creating conflicts — technically, without creating a rule-matching-span that has no pushout.
The general reason for this is that SysArchZ pushouts can be amalgamated along SysArch pushouts.
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
has a pushout in SysArchsZ, too.
L1 1 A1
L
L0 A0 A
R1
0 P1
L A
R0 P0
L2 A2
R R
P Fig. 10. Amalgamation Theorem L ! R
R2
X2 XP
P2 This amalgamation theorem allows us to decompose prospective rule application pushouts of rules like those of Figs. 7 and 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.
The situation is further simplified if we restrict ourselves to architectures with a connector-component bipartition, where each node of the shape graph either is a “connector” that has only outgoing edges, or is a “component” that has only incoming edges. For system architecture (Z-path) homomorphisms, we then restrict the specification homomorphisms associated with source nodes of edges in the source diagram to be isomorphisms. In this paper, for the sake of simplicity we strengthen this restriction further to only allow identity homomorphisms. For example, source2source in Figure 5 has to be an identity.
Working with subgraphs induced by node sets of the lefthand side is necessary for separating the context of a rule application from the modifications introduced by the rule, and 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.
In the situations we encountered so far, the following (rather obvious) theorem is sufficient, although it excludes context that is attached to connectors:
Theorem 4: A SysArchsZ span A L - R where L is discrete (no edges) and both and do not map any node of L to a source node of an edge in A respectively R always has a pushout in SysArchsZ.
If a single-edge LHS is mapped via a non-zigzag homomorphism containing only identity specification homomorphism S S
ST ST2S ST ST2S
L
A S SA
ST
ST2S ST2SA
ST ST ST
R Res
R Res
These two cases can actually be combined, as depicted in Figure 14:
Theorem 5: A SysArchsZ span A L - R where the shape of L is ! , one of and is a non-zigzag homomorphism, the source node of the edge in L is associated with identity specification homomorphisms in both and , always has a pushout in SysArchsZ.
(The identity specification homomorphisms can be replaced with isomorphisms, which however would make the drawings more confusing.)
For the above scenario in Figure 14, the component SAR is a pushout construct of the span SA S ! SR. Other for the components, a pushout obviously always exists, as indicated in Figure 12.
If we restrict both rule and matching to non-zigzag homomorphisms, but allow the target of the LHS edge to be mapped with arbitrary specification homomorphisms on both sides, we get an architecture pushout where that target is assigned the corresponding specification pushout, as sketched in Figure 13.
S S
IR1 IR1
CR1
CR2 IR2
IR2 CR1
CR2
ST2S
ST2SAST IR1
CR1
CR2
IR2 CR1
CR2 ST
R Res components, i.e., CR1,CR2 are direct copies of the preimages from the right architecture. All the connectors, i.e., IR1,IR2,ST in the result architecture are also the direct copies of their preimages.
Now, let us say, an edge is relaxed in both the Application and the Right hand side graph (relax-relax) by adding a couple of components and connectors and we want to contract them to a single zigzag path. If we preserve the connector-component alternating pattern and consider the mapping between architectures as a System Architecture Zpath Homomorphism then there are only two possibilities to contract them to a single zigzag path with the minimal components and connectors such that the above diagram commutes. These two possibilities are as follows: 1) Disconnect the target of the Application architecture and the source of the Right hand-side architecture and glue them to a single zigzag path (Res-2). 2) Disconnect the source of the Application architecture and the target of the Right hand-side architecture and glue them together (Res-1).
So, in this scenario, two design choices are available and the result architecture varies depending on the design decision (choice) one makes.
ST S ST2S
SEA
Whether this transformation is possible or not depends on the relationship between the connectors associated to establish a connection (in the result architecture) between the application and the right hand-side architecture. A connection is established in the result architecture by breaking two connections, one each for the application and the right hand-side architecture. In the above example, for Res-1 the connection
the right hand side architecture got disconnected to establish a connection SEAtoER in the result architecture. This transformation is obvious if a specification homomorphism SEA ! ST exists. In the other case, i.e., Res-2, the obvious transformation depends on the existence of the specification homomorphism
have to introduce new components and connectors to let the transformation take place and one of this scenario is pictured by Res-3 of the figure 15.
category does not have any pushouts.
We have two potential pushout candidates with minimal components and connectors, but neither of them is a pushout object. There are system architecture homomorphisms that exist between them but they are not unique up to isomorphism. In reality these two architectures could be completely different. Though we do not have a pushout, if we select/consider one of our design decisions, then the construction of the result architecture would be systematic and it could be one of the pushout candidates.
As far as pushouts can be constructed for single edges as discussed above, these can be amalgamated for rules with more complex left-hand sides due to Theorem Theorem 3.
For a defined set of production rules (e.g., security introduction, reliability introduction) and given an application architecture, if we apply our transformation technique, in all cases except one (Sect. VI-C), the result architecture we obtain after the transformation is a pushout object. If an aspect introduction matches an LHS-edge to a zigzag path with new components 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 the span consisting of that rule with that matching. In this case, the transformation is semi-automatic. The designer will have to make design decisions, which may result in different desirable and undesirable properties becoming valid for the transformation result.
VII. CONFORMANCE CHECK
One of the great advantages of our research work is that it makes the analysis of the system architecture properties feasible.
Conformance of the result system architecture with the application system architecture is not straight-forward. Figure 16 illustrates this statement: A system architecture Zpath homomorphism between two system architectures, e.g., system arch: zigzag hom: system arch: zigzag hom: colimit s: arch: hom : Host Arch s: arch: hom : Application S:A:Z: Hom!: Result, does not necessarily imply the existence of a specification homomorphism between the colimits of these diagrams. Proving properties of the result system architecture to check its conformance with the application system architecture is not exhaustive either. Depending on different scenarios, how aspect introduction modifies an edge, in some cases we can systematically (even automatically) check the conformance of the new result system architecture to the old application system architecture without proving any proof obligations. Propagation of RHS properties into the result architecture, also conforms to the same scenario.
VIII. RELATED WORK
(AOSD) first appeared at the University of Twente in the Netherlands at the code level. However, work in aspects is no longer limited to the implementation phase of the software development. Over the last decade, the AOSD community has tried to transfer this idea into earlier phases of the software development life cycle; namely in domain analysis, requirement analysis, architecture design, and modeling.
The modeling community is doing a large amount of work
to weave aspects in models, specifically, UML models [
Whittle and Jayaraman [
colimit which allowed them to write a rule on a single model instead of repeating unchanged elements in both the LHS and the RHS.
Morin et al. [
The work we are doing is to introduce aspects at the
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
work of the AOM community, our approach is completely
different from their approaches. The way [
Weaving is not a general transformation; it is a special type of transformation. It is usually a non-automatic laborious operation where both base and aspect models get composed to get a weaved model. In contrast, a transformation is automatic where predefined rules are applied to a bigger application system.
Most of the above AOM approaches claim that they can detect conflicts (unavailability to weave an aspect with a woven base) and resolve them by sequencing aspects or changing the rules. But the way they define the conflict does not work for system architecture. After introducing an aspect to an application architecture, further aspect introduction to the resultant architecture by general weaving/transformation technique might be unavailable to some of the re-defined rules though neither the rules nor the resultant architecture is wrong.
One of the potential solutions to this problem is to introduce a new transformation technique by keeping the nature of aspect introductions in mind. Our Zpath graph transformation technique is capable of addressing this issue. Besides that, it allows us to systematically verify the conformance (property preservation) of the old system architecture to the new.
IX. FUTURE WORK
Besides identifying the “Zigzag-path homomorphisms” and elaborating the “Zigzag transformation”, we have provided some meta-theorems that make it (sometimes) unnecessary to re-prove properties for transformation results, or make it easier to obtain result properties from component and aspect properties. From our example, we have experienced that proving the well-definedness and validating the properties of system architecture is a tedious redundant job. So, we are currently developing some tool support that will make our methodology mechanical and make our evaluation and validation process feasible. Since our methodology is independent of the underlying logic, one of the potential future steps would be application of the theory in industrial settings by applying widely used architecture languages, e.g., AADL, EAST-ADL.
X. CONCLUSION
Working with aspect introduction at the architecture level has many benefits including for documentation, product risk management, understandability, reusability and maintainability. The nature of aspects makes it impossible to apply any of the conventional graph transformation approaches, since those work with exact matchings. Our “Zigzag matching” and the “Zigzag transformation” methodology streamline the process of software system evolution by making aspect introduction into system architectures systematic. Besides, in terms of property preservation, it makes the conformance check of the new system architecture along with the detection and resolution of conflicts and undesirable emergent behaviors semi-automatic.