A Formal Approach to Semantic Composition of Aspect-Oriented Requirements

Nathan WestonLancaster University

Lancaster, UKwestonn@comp.lancs.ac.uk

Ruzanna ChitchyanLancaster University

Lancaster, UKrouza@comp.lancs.ac.uk

Awais RashidLancaster University

Lancaster, UKawais@comp.lancs.ac.uk

Abstract

The goal of Aspect-Oriented Requirements Engineering(AORE) is to identify possible crosscutting concerns, and todevelop composition specifications around those concerns.These compositions can be used to reason about potentialconflicts in the requirements and to relate requirementsto architecture in semantically meaningful ways. Recentwork in AORE has moved from a syntactic approach tocomposition, which leads to fragile compositions andincreased coupling between aspect and base concerns, toa semantic composition approach, based on semantics ofthe natural language itself. However, such compositionsare at present only informally specified, and as such formalreasoning about the requirements and the subsequentderivations are difficult. We present a formal approach tothese semantic-based compositions which facilitates thisreasoning. We show that the approach especially lendsitself to identifying conflicts between requirements andmapping compositions to a derived architecture.

1. Introduction

Aspect-Oriented Requirements Engineering (AORE) hasat its heart the intuition that the composition of crosscuttingconcerns, including their mutual influences and trade-offs,can be identified and reasoned about during requirementsengineering. This can enable improved conflict detection,as well as providing valuable early insights into architecturederivation [4].

However, most current AORE composition mechanismsspecify compositions based on syntactic references torequirements, such as direct references to requirementidentifiers [17, 14] or use case elements [10]. For example,a composition may have a pointcut1 which refers to aparticular (named or numbered) extension point in another

1Here, a pointcut is an expression which can pick out one or morerequirements or other elements at which the composition applies.

use case. Our recent work [5] has shown that this leadsto several problems, including pointcut fragility, a lack ofexpressiveness and a loss of information concerning theintent of the stakeholders and the requirements engineer.

To combat these problems, we have proposed an ex-pressive composition approach based on the grammaticalsyntax and semantics of the natural language, called theRequirements Description Language (RDL) [5]. Using theRDL, compositions can be specified using natural-languageoperators, allowing engineers a semantically rich vocab-ulary instead of pure syntax. Composition pointcuts canbe specified using not only the syntactical elements of anatural language requirement statement (such as Subject,Object etc.), but also the semantic information such asthe verb type or the level of strength of the requirement(e.g. Must or May). The result of the composition canbe specified using semantically meaningful verb-basedoperators (based on those in [7]) such as affiliate , retainand maintain . Similarly, the mechanics of the compositioncan be specified using conditional or temporal operators(such as before and along).

The advantage of using semantically meaningful naturallanguage operators is that the composition mechanismencourages the engineer to think in terms of the systemrather than a requirements document when specifyingcompositions. This preserves the intent of the requirementsengineer and stakeholders and enables intuitive semanticreasoning for a speaker of the natural language, as well assignificantly reducing pointcut fragility.

Due to its focus on semantic composition, our ap-proach brings additional challenges for reasoning aboutrequirements. For example:

• Conflict identification cannot be performed purely on thebasis of shared syntactic composition points, but musttake into account the semantics of the compositions.That is to say, if two compositions apply to the samerequirement, their constraints are defined using naturallanguage verbs, whose precise semantics are oftenunintuitive or ambiguous.

• Relating requirements to architecture must also be done

16th IEEE International Requirements Engineering Conference

1090-705x/08 $25.00 © 2008 IEEE

DOI 10.1109/RE.2008.42

173

in semantically meaningful ways, rather than returningto a syntax-based mapping. The precise semanticsof a composition must be known for the architecturederivation to be done correctly, and thus we need a wayto explicitly define these semantics.

In order for these challenges to be met, the compositionmechanism must have a formal underpinning, such thatthe natural language semantics in the compositions canbe unambiguously understood, and reasoning techniques(such as specification refinement, conflict detection [13]and model checking [11, 15]) applied.

In this paper, we present the following contributions:

1. A framework for the formalisation of the naturallanguage-based compositions using predicate logicincluding explicit temporal elements, following work byAllen et. al. [1, 2] on actions and events,

2. The mapping of semantic roles to syntactic naturallanguage elements as part of this formalisation,

3. The ability to perform modular reasoning in require-ments conflict detection, by utilising both temporal andverb semantics to specify compositions,

4. The precise capture of composition intent in thearchitecture derivation process.

The remainder of the paper proceeds as follows. Webegin by presenting an introduction to semantics-basedAORE in Section 2, including the RDL on which ourwork is based. We outline our approach in Section 3. Wepresent a case study based on a non-trivial auction systemin Section 4, and show how the approach can be used tofacilitate formal reasoning. Section 5 examines relatedwork, and Section 7 concludes.

2. Semantics-based AORE

2.1. Need for semantics-based AORE

Until recently, work on aspect composition in AOREhas been based on syntactic references to requirementsin the base2. For example, recent approaches specifycompositions based on direct references to requirementidentifiers [17, 14] or use case elements [10]. An exampleof the approach in [14] is shown in Fig. 1. Here, thecaching composition (c) links the CacheAccess aspect(b) with the Customer viewpoint (a). Note that the com-position specifies which requirements it applies to usingthe syntactic references viewpoint="Customer" andid="1" - that is, requirement number 1 in the Customerviewpoint (line 4 in (c)). A similar example for the use caseapproach [10] is presented in [5].

2Where the base refers to those requirements which are affected by theaspects.

1 <Viewpoint name=”Customer”>2 <Requirement id=‘‘1”>The customer selects the3 room type to view room facilities and room4 rates .5 </Requirement>6 <Requirement id=‘‘2”> The customer makes a7 reservation for the chosen room type.8 </Requirement>9 </Viewpoint>

(a)

1 <aspect name=‘‘CacheAccess”>2 <Requirement id=‘‘1”>The system looks up cache3 when:4 <Requirement id=‘‘1.1”> room type data is5 accessed ; </Requirement>6 <Requirement id=‘‘1.2”> room pricing data is7 accessed ; </Requirement>8 </Requirement>9 </aspect>

(b)

1 <Composition>2 <Requirement aspect=‘‘CacheAccess” id=‘‘all”>3 <Constraint action=‘‘provide” operator =‘‘ for”>4 <Requirement viewpoint=‘‘Customer” id=‘‘1”/>5 </Constraint>6 </Requirement>7 ...

(c)

Figure 1. Composition in ARCADE

Our recent work [5] has highlighted the problemsendemic to these syntactic-based AORE approaches. Aswell as being cumbersome and difficult to construct,compositions based on syntactic elements suffer from twomajor problems.

Firstly, compositions are specified on the basis of thestructure of the requirements document rather than on thesemantics of the requirements themselves. This translatesinto a loss of intentional information from the requirementsengineer and the stakeholders, with a detrimental effect onthe subsequent analysis. As well as this, trade-off analysisis hindered, as syntax-based trade-off points must be usedto infer semantic interactions among aspects.

Secondly, syntactic composition models suffer frompointcut fragility, as changes in the base requirements ortheir numbering can invalidate aspect compositions. Thiscan lead to extra work for the requirements engineer, asevery time a modification or an addition is made, all aspectcompositions must be re-evaluated.

The development of semantics-based compositions for

174

AORE [5] has done much to ameliorate these issues. Usingthe Requirements Description Language (RDL) and a richvocabulary of natural language operators, compositionscan be specified both on the syntax of the natural languageand on the semantics of the requirements. This enablesa requirements engineer to specify the semantics of acomposition using natural language operators, whichretains his or her intent, and reduces pointcut fragility.

An example RDL composition is presented in Fig. 2.This performs a similar role to the ARCADE examplepresented in Fig. 1 - that is, accessing the cache whenfrequently accessed data is requested. Note that the com-position does not rely on requirements identifiers or similarsyntactic elements present in the requirements engineeringdocument to specify which requirements it applies to, buton the semantic structure of the requirements themselves.

Similarly, the composition provides extra semanticinformation in its operators - here apply, meets andsatisfied - to specify the mechanism and the outcomeof the composition:

• The constraint operator, apply (line 3), states thatthe concern in question (that is, any concerns whichinvolve looking things up in the cache) must be appliedto the base at a certain point. There are several potentialconstraint operators based on an adaptation of the naturallanguage verb categories proposed by Dixon [7].

• The base operator defines the point at which the con-straint is applied. Here, this is defined by the temporaloperator meets (line 7), which means that the cachelookup happens just before the accessing of the fre-quently used data. There are several temporal operatorsavailable which represent ordering (before, afteretc.) as well as overlapping and concurrent operators(along, finishes, starts etc.). As well asthese, conditional and unconditional operators such asif and ifNot are available to use.

• The outcome operator defines the final result of thecomposition. Here, the requirements which deal with theupdating of the cache must be satisfied (line 11) asa result of this composition.

We will return to the details of the RDL when wedescribe our approach in Section 3. Here it is sufficient tonote that RDL compositions are semantically meaningfuland more expressive in their definition than syntax-basedcomposition mechanisms.

2.2. Need for a formal approach

However, this more expressive composition mechanismbrings with it natural challenges for reasoning and analysis.For example, specifying compositions semantically facil-itates conflict detection and analysis at a semantic level.

1 <Composition name=‘‘CompositionAccessCache”>2 <Constraint operator=‘‘apply”>concern3 [ relationship =‘‘look up” object =‘‘cache”]4 </Constraint>5 <Base operator=‘‘meets”>subject=‘‘ frequently6 used data” or object =‘‘ frequently used data”7 </Base>8 <Outcome operator=‘‘ satisfied ”>9 relationship =‘‘update” and object =‘‘cache”

10 </Outcome>11 </Composition>

Figure 2. RDL composition for the cachingexample

In a syntactic system, certain classes of conflicts are verystraightforward to identify - if two or more compositionsapply to the same (numbered) requirement, then we canbe confident that a conflict may occur. However, in theRDL, the pointcut language is much richer than syntacticelements such as requirements numbers, and thus conflictdetection can be more difficult. To illustrate this, considertwo compositions, with base semantic queries of:

verb semantic=‘‘ affiliate ” and:subject =‘‘ user” and relationship =‘‘ join”respectively. Do these two compositions match the same

requirements? If so, which ones?Once we have detected a potential conflict, a further

difficulty arises in determining how the conflict will man-ifest itself. Dealing in operators based on natural languageverbs enables the requirements engineer to specify his orher intent much more clearly, but it also makes the precisesemantics of conflicts difficult to determine. For example,consider two further compositions, which we present herein part:

<Composition name=‘‘CarryComposition”><Constraint operator=‘‘ carry ”>...</Constraint><Base operator=‘‘ starts ”>...</Base>...

</Composition>

<Composition name=‘‘ThrowComposition”><Constraint operator=‘‘throw”>...</Constraint><Base operator=‘‘ finishes ”>...</Base>...

</Composition>

If we have convinced ourselves that these two com-positions apply to the same requirement r, the natureof their interaction is far from intuitive. The temporaloperator in the CarryComposition composition meansthat carrying must start at the same time as r; similarly,ThrowComposition requires throwing to end at the same

175

time as r. Is this a conflict? We could conceive of asituation where something is carried, and then thrown,rendering these two compositions co-operative; but it isalso conceivable that the act of carrying might preclude theact of throwing. Conflict analysis therefore depends on thesemantics of the two temporal base operators and the twoverb-base constraint operators, which is unclear from thetwo compositions themselves.

This same difficulty - of determining precise semanticsfrom potentially ambiguous natural language - rears itshead when progressing from requirements to later stagesin the development lifecycle. It has been shown that RDLcompositions can be used to drive mappings to systemarchitecture [4]. It is acknowledged that the semanticsof the constraint operators play a large part in guidingthe system architect on how roles taken by elements inthe system interact. However, the constraint operatorsdo not have an explicit counterpart in the architecturedescription language proposed in [4], as it is difficult tospecify precisely what the constraint operator means andwhat impact it has on the architecture. Therefore, althoughthe engineer’s intentionality is partly preserved acrossthe lifecycle, we so far lack the precision to be able tounambiguously retain complete intentional information.

Therefore, the semantics-based approach to AORE com-positions, while affording great power and expressivenessand presenting many advantages to the software developer,raises some interesting challenges which must be met ifthese advantages are to be fully harvested. We now presentour approach to formalising the compositions and thusmeeting the research challenges.

3. Formal composition approach

Our approach has as its basis a formal description of ageneric composition, the elements of which can then besubstituted for the specific elements of a particular compo-sition. We will illustrate the formalisation of a compositionusing a running example, that of the EnrolCompositioncomposition from the auction example we will exploremore thoroughly in Section 4:

<Composition name=”EnrolComposition”><Constraint operator=” affiliate ”>concern=”Enrol”

</Constraint><Base operator=”before”>all concerns</Base><Outcome operator=”ensure”/>

</Composition>

Informally, a composition applies the requirements orconcerns described by the constraint semantic query to therequirements or concerns described by the base semanticquery under the conditions of the base operator; whileat the same time ensuring that the constraint operator’s

semantic is correctly established and that the conditionsof the outcome’s semantic query are upheld (if they exist),under the conditions of the outcome operator.

This can be formally specified using the followingformula, which shows the application of Constraint c withconstraint operator γ to Base b, under the conditions ofbase operator β, with Outcome o under operator ω.

Composition(c, γ, b, β, o, ω) ≡∀r, s, t.Matches(b, r) ∧Matches(c, s)

∧Matches(o, t)→ β(s, r) ∧ ω(γ(s), t) (1)

In order to make this formulation useful, we need to definethe behaviour of the operators β, γ and ω. As well as this,the result of the Matches predicate will vary depending onthe class of the semantic query. It is to these issues we willturn now.

3.1. Semantic queries

Semantic queries can draw from a rich vocabularyof possible annotations provided by the RDL to selectrequirements:

Concern Matches all requirements which describe aparticular concern

SRO Matches requirements which have the specifiedSubjects, Objects or Relationships

Verb Matches the type (e.g., MOTION) or semantic (e.g.,Throw) of the verb relationship

Degree Matches the strength of the relationship or levelof relevance in terms of type (e.g., MAXIMIZER) orsemantic (e.g., Must)

Sequencing Matches the particular sequence of require-ments which need ordering in terms of type (e.g.,BETWEEN) or semantic (e.g., Prior)

These semantic queries can be combined using standardoperators such as and and or. In the case of our example,the semantic queries for both the constraint and the baseuse the Concern annotation, meaning that all requirementsassociated with the named concerns should be matched.Thus we can begin to formulate our EnrolCompositioncomposition:

EnrolComposition ≡ ∀r, s, t.(Concern(s) = “Enrol”)

∧Matches(o, t)→ β(s, r) ∧ ω(γ(s), t) (2)

176

3.2. Base operators

Base operators can take several forms, both temporal andnon-temporal, as specified in [6]. The temporally-specifiedoperators are based on Allen’s temporal relations[1, 2],which specify relations between time periods. To applythis to requirements, we specify a function Time(X) forevery requirement X which captures the time period of arequirement being satisfied, and thus we are able to specifythe temporal relationships between requirements. Thebenefit of explicit time periods, as opposed to implicit timeas in Linear Temporal Logic (LTL), is that concepts such asconcurrency and overlapping can be expressed much moresuccinctly.

The operator Meets is axiomised in [2], and is usedto represent the end of one time period signifying thebeginning of another. Using the symbolism t− to representthe beginning time point of a period t and t+ to representthe ending time point, Meets(s, t) → s+ = t−. In thefollowing definitions, we use the shorthand k = i + jto represent the concatenated time period such thatk− = i−∧ k+ = j+∧Meets(i, j). Using this axiom, wecan define the temporal base operators as shown in Fig. 3.

Conditional and unconditional operators are specifieddifferently, as they are not temporally constrained. Insteadwe introduce a function Satisfied(X) to denote that arequirement X is satisfied without having to say anythingabout its temporal nature3.

If(X,Y )→ (Satisfied(X) ∧ Satisfied(Y )) ∨(¬Satisfied(Y ) ∧ ¬Satisfied(X))

IfNot(X,Y )→¬(Satisfied(X) ∧ Satisfied(Y ))

We note that for the EnrolComposition composition, thebase operator β is “before”. In this case, the semantic queryrepresenting the base concern is “all concerns”. Thereforethe Matches(b, r) relation applies to all requirements inall concerns, and we can refine (2) to:

EnrolComposition ≡ ∀r, s, t.(Concern(s) = “Enrol”)

∧Matches(o, t)→ Before(s, r) ∧ ω(γ(s), t) (3)

We can thus apply our temporal operator definitions tofurther refine the formal definition of EnrolComposition:

EnrolComposition ≡ ∀r, s, t.(Concern(s) = “Enrol”)

∧Matches(o, t)→ ∃k.Meets(T ime(s), k)

∧Meets(k, T ime(r)) ∧ ω(γ(s), t) (4)

3The formal semantics of the indicative conditional - that is, theintuitive understanding of the natural language statement “if A then B” -is one of the classic unsolved problems in formal logic. Here we make noattempt to add to this literature, but instead present a formulation whichcaptures what we require to be true for a composition to be correctlyapplied - in the case of “if”, that either both requirements are satisfied, orneither of them are.

Before(X,Y )→ ∃k.Meets(T ime(X), k)

∧Meets(k, T ime(Y ))

(X finishes at some point before

Y starts)

During(X,Y )→ ∃k, l.Meets(k, T ime(X))

∧Meets(T ime(X), l)

∧ (k + T ime(X) + l = T ime(Y ))

(X starts and finishes while

Y is ongoing)

Starts(X,Y )→ ∃k.Meets(T ime(X), k)

∧ (T ime(X) + k = T ime(Y ))

(X and Y start at the same time)

Finishes(X,Y )→ ∃k.Meets(k, T ime(X))

∧ (k + T ime(X) = T ime(Y ))

(X and Y finish at the same time)

Overlaps(X,Y )→ ∃k.F inishes(T ime(X), k)

∧ Starts(k, T ime(Y ))

∧ T ime(X) 6= T ime(Y )

(X starts before Y, but Y starts

before X finishes)

Concurrent(X,Y )→ T ime(X) = T ime(Y )

(X and Y happen at precisely the

same time)

Figure 3. Formal definitions of base opera-tors

3.3. Constraint operators

Constraint operators are specified using English verbs,an adaptation of the semantic categorisation proposed byDixon [7]. These verbs are specified in terms of semanticroles which are inherent to the action in question. Forexample, in the verbs concerning communication, rolesinclude Speaker, Addressee, Message and Medium. Inorder to specify what it means for a particular operator tobe specified within the context of a requirement, we specifyseveral predicates on the requirement pertaining to the roleswhich are applicable to a certain verb type.

However, the requirements are specified not in terms ofsemantic roles, but in terms of natural language elements- that is, syntactic roles such as Subject, Object etc. Wetherefore need to match these semantic roles to the naturallanguage elements within the requirements such that we canestablish that the semantic is satisfied. To do this, we in-troduce several predicates on a requirement which map thenatural language roles, such as Subject , TransitiveSubject ,

177

Object , IndirectObject and PrepositionalPhrase. Withthese in place, we can define a match semantic (based onthe insights in [7]) which maps elements in syntactic rolesto their semantic equivalent. This match semantic can neverbe completely automatic, as there are several possibilitiesfor how the roles can map to language elements and a hu-man speaker is required to act as an expert on determiningwhich configuration is correct.

With a match semantic in place, we then define twofurther semantics - the time semantic and the verb semantic.The time semantic defines the temporal structure of theaction in terms of the conditions true before, during andafter the action, without specifying the actual nature ofthese conditions. The verb semantic defines what theseconditions are, but says nothing about their temporal struc-ture. Satisfaction of the semantic is therefore equivalentto satisfying these conditions in both the verb and the timesemantic. We follow [2] in separating the two semantics,the advantage of which is the ability to reason separatelyabout the temporal and semantic nature of the verb withoutunnecessary entanglement.

To demonstrate this, take the example of the verb Carry,which has the semantic roles Moving - the object whichis being carried - and Causer - the object (whether humanor not) doing the carrying4. The match semantic statesthat a requirement can be known to be a carry action ifthe relationship type is one of a number of “carrying”synonyms, and if this is the case, we can surmise that theCauser is in the transitive subject position and the Movingthing is in the transitive object position:

∀r.Requirement(r) ∧ (Relationship(r) = “carry”∨Relationship(r) = “bear” ∨ ...)→Carry(r)→∃c,m.Causer(c) ∧ TransitiveSubject(r) = c ∧Moving(m) ∧Object(r) = m

The verb semantic states that the effect of the action is thatthe Causer has the Moving thing and both are in the samemotion. There are conceivably two pre-conditions whichcould hold - either the Causer does not have the Movingthing, or the Causer has the thing but one or the other is notin motion:

∀r.Requirement(r) ∧ Causer(c) ∧Moving(m)→pre(r) = (¬Has(c,m) ∨ (Has(c,m)

∧ (¬InMotion(c) ∨ ¬InMotion(m)))) ∧post(r) = (Has(c,m) ∧ InMotion(m)

∧ InMotion(c) ∧ SameMotion(c,m))

In order to formulate the time semantic, we introduce pred-icates to indicate the pre-conditions (pre), post-conditions

4A further role, Locus, is also permissible, which can specify the placewith respect of which the motion takes place. We omit this here for clarityof the example.

(post) and invariants (inv ) of the action, as well as apredicate to specify conditions that are true during theaction (con). Here, the time semantic states that thepre-condition holds true until the requirement starts - assoon as the carrying begins, the post-condition holds true.

∀r.Requirement(r) ∧ Carry(r)→Meets(pre(r), T ime(r)) ∧ Starts(T ime(r), post(r))

These three semantic definitions combined thereforerepresent the mapping of the semantic roles to the naturallanguage elements, the temporal structure of the actionand the necessary conditions for it to be satisfied. For ourEnrolComposition example, the constraint operator isaffiliate , representing someone or something becominga member of a group that he/she/it was not a member ofbefore. This yields the following semantics:

Match semantic

∀r.Affiliate(r)→∃m, g, c.Member(m) ∧Group(g) ∧ Causer(c)∧(TransitiveSubject(r) = m ∧Object(r) = g)∨(TransitiveSubject(r) = g ∧Object(r) = m)

Time semantic

∀t, r.Requirement(r) ∧ T ime(r) = t→Affiliate(r)→Finishes(pre(r), t) ∧Meets(t, eff(r))

Verb semantic

∀r, g,m.Requirement(r) ∧Group(g) ∧Member(m)→Affilate(r)→ pre(r) = ¬In(m, g)∧post(r) = In(m, g)

With these definitions, we can extend the semantic forour composition from Eq. 4:

EnrolComposition ≡ ∀r, s, t.(Concern(s) = “Enrol”)

∧Matches(o, t)→ ∃k.Meets(T ime(s), k)

∧Meets(k, T ime(r)) ∧ ω(Affiliate(s), t) (5)

In order to find the semantic roles, we note thatMatches(c, s) is satisfied by the Enrol concern, and assuch we have a structure on which to use our match seman-tic to determine roles. In this case, Member(s) = “users”and Group(s) = “system”. Applying the verb semanticto the roles yields:

Affiliate(s)→ pre(s) = ¬In(“user”, “system”)∧post(s) = In(“user”, “system”) (6)

To expand our formalisation further, we need to examinethe final element of the composition, the Outcome operator.

178

3.4. Outcome operators

The outcome operators specify the result of a compo-sition occurring. Recall that in the general form of thecomposition (Eq. 1) the outcome operator determines notonly the satisfaction of the outcome’s semantic query,but also the satisfaction of the constraint. There are threeoutcome operators: Ensure, Satisfy and Monitor .

The simplest operator is Ensure, which takes no seman-tic query and states that the conditions of the constraintmust hold in the composition. Therefore:

∀s, t.Ensure(γ(s), t)→ γ(s) (7)

The operator Satisfy is equally straightforward, simplystating an extra set of requirements that must be renderedtrue by the application of the constraint:

∀s, t.Satisfy(γ(s), t)→ (γ(s)→ t) (8)

However, Observe is considerably more complex. Thisstates that after the composition has been applied, a periodof observation must follow to ensure that the constraint hasbeen upheld. We must therefore introduce a time elementto the composition rule:

∀s, t, c.Composition(c)→ Observe(γ(s), t)→∃i, j.Meets(i, j) ∧ T ime(c) = i

∧Monitor(γ(s), j) ∧Monitor(t, j) (9)

Where Monitor describes the active observance of the con-straint after the composition has occurred. The definitionof Monitor is necessarily context-dependent.

With these definitions in place, we can extend Eq. 5 withthe outcome operator:

EnrolComposition ≡ ∀r, s, t.(Concern(s) = “Enrol”)

∧Matches(o, t)→ ∃k.Meets(T ime(s), k)

∧Meets(k, T ime(r)) ∧ Ensure(Affiliate(s), t) (10)

Substituting in our definition of Ensure (7) yields:

EnrolComposition ≡ ∀r, s.(Concern(s) = “Enrol”)

→ ∃k.Meets(T ime(s), k)

∧Meets(k, T ime(r)) ∧Affiliate(s) (11)

Now we can introduce the time and verb semantic ofthe constraint operator affiliate to produce the finalcomposition:

EnrolComposition ≡ ∀r.∃s.(Concern(s) = “Enrol”)

→ (∃k.Meets(T ime(s), k) ∧ (Meets(k, T ime(r))

∧ pre(s) = ¬In(“user”, “system”)

∧ post(s) = In(“user”, “system”)

∧ Finishes(pre(s), T ime(s))∧Meets(T ime(s), post(s)) (12)

4. Case study and discussion

The case study is based on an online auction systemsourced from http://lgl.epfl.ch/research/fondue/case-studies/auction/. The sys-tem was expressed in the RDL in [6], to which wehave made a few small changes, and we have for-malised the compositions using the approach outlinedabove. For space economy reasons, the results of thisformalisation process can be found online at http://www.comp.lancs.ac.uk/˜westonn/rdl/.

LoggingComposition ≡∀r, s.(Concern(s) = “Security”)

→ (∃k.Meets(T ime(s), k) ∧ (Meets(k, T ime(r))

∧ pre(s) = In(“user”, “system”)∧¬Authenticated(“user”, “system”)

∧ post(s) = In(“user”, “system”)∧Authenticated(“user”, “system)

∧ Finishes(pre(s), T ime(s))∧ Meets(T ime(s), post(s))

Figure 4. Formalisation of the LoggingCom-position

4.1. Conflict detection

We illustrate the potential for conflict detection usingthe two compositions EnrolComposition (as presentedin Section 3) and LoggingComposition (see Figure 4).The basic method for revealing potential conflicts is toexamine the logical conjunction of the two compositions(EnrolComposition ∧ LoggingComposition), but thegranularity of our approach allows a more refined strategy.First, we examine purely the temporal structure of theconjunction, considering only the time semantic of theconstraint operator as well as the base operator:

EnrolComposition ∧ LoggingComposition→∀r, s, s′.(Concern(s) = “Enrol”)

∧ (Concern(s′) = “AccessControl”)

→ (∃k.Meets(T ime(s), k) ∧ (Meets(k, T ime(r))

∧ (∃k′.Meets(T ime(s′), k′) ∧ (Meets(k′, T ime(r))

∧ Finishes(pre(s), T ime(s)) ∧ Meets(T ime(s), post(s))

∧ Finishes(pre(s′), T ime(s′))∧Meets(T ime(s′), post(s′))

(13)

The time structure presented in 13 allows for many poten-tial scenarios, as it simply states that before any and all

179

requirements, both the concerns s and s′ must be satisfied.Therefore, this formalism axiomatically allows for s′ to besatisfied before s - in other words, that post(s′) holds at thesame time as pre(s). While this is not in itself indicative ofa conflict, it does represent a potential interaction. In orderto determine whether a conflict has indeed been detected,we can compare the verb semantic of the two compositions:

EnrolComposition ∧ LoggingComposition→∀s, s′.(Concern(s) = “Enrol”)

∧ (Concern(s′) = “AccessControl”)

→ pre(s) = ¬In(“user”, “system”)

∧ post(s) = In(“user”, “system”)

∧ pre(s′) = In(“user”, “system”)∧¬Authenticated(“user”, “system”)

∧ post(s′) = In(“user”, “system”)∧Authenticated(“user”, “system) (14)

If our time semantic allows for post(s′) and pre(s)to occur at the same time - which it does - weindeed have a conflict, as our compositions statethat there can be a time when we must satisfy¬In(“user”, “system”) ∧ In(“user”, “system”). Infor-mally, this represents a user logging in before he/she is en-rolled in the system, which is not possible. With this conflictdetected, we can emend our composition to reflect that wemust enforce the order of enrolling first and then logging in:

<Composition name=‘‘LoggingComposition”><Constraint operator=‘‘ affiliate ”>

concern=‘‘AccessControl”</Constraint><Base operator=‘‘before”>all concerns

except Enrol</Base><Base operator=‘‘ after ”>Enrol</Base><Outcome operator=‘‘ensure”/>

</Composition>

Constructing the semantic as before and performingthe conjunction yields no conflict, as the pre-conditionof logging in: pre(s′) = In(“user”, “system”) mustnecessarily occur after the process of enrolling.

This conflict detection tactic - comparing time structurebefore verb semantic - has several benefits. In largesystems with several compositions, it allows for a modularapproach to conflict detection, as interferences based ontime structure can be inferred from just the time semanticof the constraint and the base operator and semantic query.This brings with it the potential to identify many differenttemporal classes of interaction with which the second step- comparing the verb semantic - can be refined. As we areable to infer potential overlaps of logical conditions thatmust hold, we can then use the verb semantic to determinewhether a logical conflict must or may occur as a result oftwo or more compositions being applied.

4.2. Mappings to architecture

Recent work in refining the software development lifecy-cle has highlighted the importance of a strong mapping be-tween requirements and architecture that can be constantlyre-evaluated in the presence of change. Such an interleav-ing is crucial in order to develop architectures that are bothstable and adaptable when specifications evolve, as theyare prone to do. Nuseibeh et. al. have developed the “TwinPeaks” model [16] - the peaks referring to requirements andarchitecture - which requires a strong mutual link betweenthe two peaks which is utilised to incrementally evolvethe system as it becomes more detailed and closer to theimplementation. Garcia et. al. [9] have proposed that cross-cutting concerns, once identified within the requirementsof a system, can and should be the driving force behindarchitectural decisions, with the benefits of promotingreuse and evolvability in the software development process.

As the authors of the latter paper note, one practical im-plementation of this philosophy would be mappings fromrequirements-level aspects to Architecture DescriptionLanguages (ADLs) for modelling software architectures.However, most ADLs do not have the capacity to modelthese crosscutting concerns, or if they do, many arehighly implementation language-dependent. In responseto this, Chitchyan et. al. [4] have presented AO-ADL,an Architecture Description Language which takes acomposition-centric approach to modelling architectures.This same work showed that requirements in the RDLcould be mapped to AO-ADL elements via the SROpattern inherent in all RDL requirements. In the classicalcase, Subjects and Objects can be mapped to AO-ADLComponents, and the Relationships to connections betweenthese Components. Separate cases were identified forsituations where one of the SRO elements is not specified,or where they do not represent tangible objects.

In this mapping, there is a close to 1-1 mapping betweenRDL compositions and AO-ADL aspect bindings. How-ever, the constraint operator has no explicit reference in theAO-ADL, which may lead to a loss of engineer intent whenit comes to the architecture. Given the ambiguity of naturallanguage, the transferral of the constraint operator withoutexplanation may not be enough to convey the originalmeaning.

The advantage of our approach is that it encouragesan unambiguous formal specification of what constraintoperators represent in terms of their effect on appropriatesemantic roles. This information could then be introducedinto the AO-ADL within the aspect binding in order toretain the engineer’s intent for the roles that are explicitlymentioned within the AO-ADL. This would provide aprecise mapping between the semantics of the RDL andthe AO-ADL, with all the benefits in terms of stability and

180

adaptability that we have mentioned above.In order to achieve this, we present an extension to the

AO-ADL which explicitly retains this information. To seethis, consider the AO-ADL definition of the LoggingCom-position concern presented in Figure 5 (this is reproducedfrom [4], but includes adaptations based on work inthis paper). We extend the aspectual-componentelement (lines 26-33) with the pre- and post-conditiondefinitions transferred from our formal semantic definition(see Figure 4). As well as this, we can preserve the timesemantic with an operator showing how the time of theaspect relates to it pre- and post-conditions. This preservesthe engineer’s intentionality with respect to the semanticroles of the composition, and thus forges a stronger linkbetween requirements and architecture. Similarly, the useof temporal operators in the AO-ADL can be specified moreformally with the definitions we presented in Section 3,creating another semantically meaningful link betweenrequirements and architecture.

5. Related work

Some existing research has considered the problem ofrequirements composition and both formal and informalapproaches have been proposed. Araujo et. al. [3] modelcrosscutting concerns as scenarios, which are then com-posed with non-aspectual scenarios by transforming bothsets of scenarios into state machines and performing statemachine synthesis. Laney et. al. [12] introduce a new formof Problem Frame called a Composition Frame, whichexpresses the requirements of composition. This allows thedomains of two Problem Frames to be combined, enablingconflict detection and arguments for satisfaction to be statedand checked. These approaches clearly aim to address thesame problem as we do, with the major difference that ourcompositions are based on natural language semantics andthus can retain the intent of the requirements engineer moreintuitively.

Within the field of requirements engineering, there existsvaluable work on the formalisation of requirements forvarious ends. Nelken and Francez [15] have presented asystem for the automatic translation of natural languagesystem specifications into temporal logic, with the aim ofproducing input for model checking. Similarly, Katz andRashid [11] have proposed a method for producing tempo-ral logic proof obligations from aspectual requirements andthus detecting conflicts using a model checker. However,neither approach can perform the conflict detection at therequirements engineering stage as ours can; nor can theyprovide much insight or preserve intent in the architecturederivation stage. Letier and van Lamsweerde [13] have pro-posed an approach which can derive operational softwarespecifications from system goals, guaranteeing correctness

1 <connector name=‘‘...”>2 <required−role name=‘‘User”>3 <role−specification>4 component−name=‘‘User” and5 (operation−name=‘‘buy” or6 operation−name=‘‘sell”)7 </role−specification>8 </required−role>9 <aspectual−role name=‘‘AccessControl”>

10 <role−specification>11 component−name=‘‘AccessControl” and12 operation−name=‘‘login”13 </role−specification>14 </aspectual−role>15 <aspectBindings>16 <aspectual−binding name=‘‘LoginComposition”>17 <pointcut−specification>18 required−role−name=‘‘User”19 required−role−name=‘‘”System”20 </pointcut−specification>21 <binding operator=‘‘ before*”>22 <aspectual−component>23 aspectual−role−name=‘‘AccessControl”24 criticality =‘‘ critical ”25 advice−name=‘‘login”26 <pre operator=‘‘ finishes ”>27 ‘‘ In(User,System) and28 not Authenticated (User,System)”29 </pre>30 <post operator =‘‘meets”>31 ‘‘ In(User,System) and32 Authenticated (User,System)”33 </post>34 </aspectual−component>35 </binding>36 </aspectual−binding>37 </aspectBindings>38 </connector>

Figure 5. Extension to the AO-ADL withformal composition semantics

via incremental construction; but the method must startwith formally-specified goals and not natural-languagerequirements.

There has been much work outside of the requirementsengineering community on the formalisation of natural lan-guage. As we acknowledge earlier, our work owes a debt tothat of Allen, both in the field of temporal intervals [1] andin modelling action verbs [2]. We have shown the benefitof using a predicate logic with explicit temporal elements,and the separation of time semantics from verb semantics,both of which ideas were introduced to us through Allen et.al.’s work. There is a huge body of work on the modelling

181

of temporal events, notably from Galton [8], who criticisesAllen’s use of temporal intervals and proposes a revisionwhich includes continuous time. For our purposes, wefind that using temporal intervals allows us to accuratelyexpress temporal relationships, and gives the ability to seepotential conflicts clearly.

6. Future work

Future directions for the formal approach will focus ontwo main areas. One is the creation of an automated methodof transforming RDL compositions into the formalisationswe have derived by hand for this paper. This can be furtherdeveloped by the production of a tool which can generateproof obligations in the Linear Temporal Logic (LTL)based on the predicate logic formulae, which can be usedwith a model checker to verify properties of the resultingsystem implementation. The second area of developmentis the continued effort in formalising natural-language verboperators, a notoriously difficult task due to the inherentambiguity of the natural language.

7. Conclusion

The semantics-based composition mechanism for aspect-oriented requirements brings with it crucial benefits inthe retention of intent of the requirements engineer andin combating pointcut fragility. We have shown that theintroduction of an approach to formalise such compositionsenhances those benefits by facilitating semantic reasoning,especially in the fields of conflict identification and se-mantically meaningful mappings to architecture. We havepresented a framework by which RDL compositions canbe formalised, including formalisations of natural languageverb operators. We have shown how this approach candeliver the benefits of semantic reasoning, detectingconflicts between requirements in the auction systemcase study and proposing an extension to the AO-ADL tofacilitate semantically meaningful and precise mappingsto architecture. These formalisations can also be usedto derive proof obligations for the system by generatingLinear Temporal Logic (LTL) formulae which can then beused as input to tools such as model checkers.

Acknowledgement

This work is supported by the AOSD-Europe Networkof Excellence, IST-2-004349.

References

[1] J. F. Allen. Maintaining knowledge about temporalintervals. Commun. ACM, 26(11):832–843, 1983.

[2] J. F. Allen and G. Ferguson. Actions and events in intervaltemporal logic. Technical Report TR521, 1994.

[3] J. Araujo, J. Whittle, and D.-K. Kim. Modeling andcomposing scenario-based requirements with aspects. In RE’04: Proceedings of the Requirements Engineering Confer-ence, 12th IEEE International, pages 58–67, Washington,DC, USA, 2004. IEEE Computer Society.

[4] R. Chitchyan, M. Pinto, A. Rashid, and L. Fuentes. Com-pass: Composition-centric mapping of aspectual require-ments to architecture. Transactions on AOSD, 1(4), 2007.

[5] R. Chitchyan, A. Rashid, P. Rayson, and R. Waters.Semantics-based composition for aspect-oriented require-ments engineering. In AOSD ’07: Proceedings of the 6th in-ternational conference on Aspect-oriented software develop-ment, pages 36–48, New York, NY, USA, 2007. ACM Press.

[6] R. Chitchyan, A. Sampaio, A. Rashid, P. Sawyer, andS. S. Khan. Initial version of aspect-oriented requirementsengineering model. Technical Report AOSD-EuropeDeliverable D36, AOSD-Europe-ULANC-17, LancasterUniversity, 14 February 2006 2006.

[7] R. M. W. Dixon. A Semantic Approach to EnglishGrammar. Oxford University Press, 2nd edition, 2005.

[8] A. Galton. A critical examination of allen’s theory of actionand time. Artificial Intelligence, 42(2-3):159–188, 1990.

[9] A. Garcia, T. Batista, A. Rashid, and C. Sant’Anna.Driving and managing architectural decisions with aspects.SIGSOFT Softw. Eng. Notes, 31(5):6, 2006.

[10] I. Jacobson and P.-W. Ng. Aspect-Oriented SoftwareDevelopment with Use Cases (Addison-Wesley ObjectTechnology Series). Addison-Wesley Professional, 2004.

[11] S. Katz and A. Rashid. From aspectual requirementsto proof obligations for aspect-oriented systems. In RE’04: Proceedings of the Requirements Engineering Con-ference, 12th IEEE International (RE’04), pages 48–57,Washington, DC, USA, 2004. IEEE Computer Society.

[12] R. Laney, L. Barroca, M. Jackson, and B. Nuseibeh.Composing requirements using problem frames. In RE ’04:Proceedings of the Requirements Engineering Conference,12th IEEE International, pages 122–131, Washington, DC,USA, 2004. IEEE Computer Society.

[13] E. Letier and A. van Lamsweerde. Deriving operationalsoftware specifications from system goals. SIGSOFT Softw.Eng. Notes, 27(6):119–128, 2002.

[14] A. Moreira, A. Rashid, and J. Araujo. Multi-dimensionalseparation of concerns in requirements engineering. In RE’05: Proceedings of the 13th IEEE International Conferenceon Requirements Engineering (RE’05), pages 285–296,Washington, DC, USA, 2005. IEEE Computer Society.

[15] R. Nelken and N. Francez. Automatic translation of naturallanguage system specifications. In CAV ’96: Proceedings ofthe 8th International Conference on Computer Aided Verifi-cation, pages 360–371, London, UK, 1996. Springer-Verlag.

[16] B. Nuseibeh. Weaving together requirements and architec-tures. Computer, 34(3):115–117, 2001.

[17] A. Rashid, A. Moreira, and J. Araujo. Modularisation andcomposition of aspectual requirements. In Proceedingsof the 2nd International Conference on Aspect-OrientedSoftware Development, 2003.

182