Architectural Views of Aspects* Mika Katara t Institute of Software Systems Tampere University of Technology, Finland
[email protected]
ABSTRACT S u p p o r t for t h e incremental design of aspects themselves has been neglected, even as the use of aspects in conjunction with underlying systems is gaining acceptance. T h e ways in which aspects can cooperate or interfere w i t h each other need to be m a d e explicit at the design level. A n aspect architecture, a new software architecture viewtype, is proposed, a n d its general principles are explained. A n ins t a n t i a t i o n for extending U M L is described, where designs of aspects provide m a x i m a l flexibility, a n d a new concern diagram is provided to show how aspects can be combined to t r e a t different concerns of a system. A n example shows aspect architecture views of a digital sound recorder.
1.
INTRODUCTION
While enabling b e t t e r m o d u l a r i z a t i o n of software artifacts t h a n conventional languages a n d notations, current aspectoriented design approaches either define t h e relationships between different aspects only implicitly, for instance by some composition rules, or are limited in their scope of applicability. T h e r e is no generic way to reason a b o u t the influence on one aspect caused by some other aspect of the same system. Moreover, a l t h o u g h the current approaches enforce a modular t r e a t m e n t of a u g m e n t a t i o n s or modifications to existing artifacts, no s u p p o r t is provided for designing aspects themselves incrementally. As in software architectures which emphasize relationships between c o m p o n e n t s c o n s t i t u t i n g t h e software, the relationships a m o n g aspects of the system need to be m a d e explicit. This is generally difficult because it c a n n o t be assumed t h a t aspects are always orthogonal. For example, a n aspect for t r e a t i n g overflow of d a t a values, and a n o t h e r for encoding values to increase security can b o t h involve the *This research was partially s u p p o r t e d by the Bar-Nir Bergreen Software Center of Excellence at the Technion and by the Academy of F i n l a n d (projects 79354 a n d 100005). t T h i s p a p e r describes research done during the a u t h o r ' s post-doctoral visit at the Technion.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AOSD 2003 Boston, MA USA Copyright ACM 2003 1-58113-660-9/03/002 ...$5.00.
Shmuel Katz Department of Computer Science The Technion, Haifa, Israel katz @ cs.technion, ac. il
same m e t h o d s or fields of a n underlying system, a n d m a y even have overlap in the modifications applied. Such overlap between different aspects introduces a new type of problem, not seen in conventional languages, where it is clear to which module each language segment belongs. It is also a m a j o r source of complexity w h e n composing and m a i n t a i n i n g t h e aspects. To alleviate t h e above problems we propose lifting aspects t h a t provide augmentations to existing designs to first class entities a t t h e design level. A n aspect can be seen as a n a u g m e n t a t i o n m a p p i n g an existing design artifact into a new one w i t h more details. T h e additions introduced by the aspect can Cut across existing module divisions. In this p a p e r we introduce a conceptual model called t h e aspect architecture which can be seen as a software architecture viewtype [4] providing a n aspect-oriented perspective on software architecture. In an aspect architecture t h e aspects serve as building blocks. T h e y can be seen as L E G O bricks t h a t can b e composed to form more complex aspects incrementally from simpler sub-aspects. Each concern is addressed in a m o d u l a r way by a collection of aspects, which can be composed w h e n needed. T h e overlapping p a r t s of the different concerns are given explicitly by the aspects comm o n to them. W h e n composing t h e collections c o r r e s p o n d ing to the different concerns, less reconciliation is needed because of t h e explicitly defined overlapping. This makes the composition more automatic. To s u p p o r t changing concerns over the software life c y c l e a n d between stake holders, the architecture also facilitates remodularizations [15], i.e., changing t h e aspects w i t h o u t necessarily changing the functionality of the system. If each aspect describes only a small i n c r e m e n t we can compose different collections of aspects to m a t c h w h a t e v e r concern is needed. B e c a u s e the aspect architecture model is conceptual it must be i n s t a n t i a t e d for some design language before being applicable, similarly to t h e Hyperspace model [22, 15]. In this p a p e r we outline a n i n s t a n t i a t i o n for U M L a n d introduce a new d i a g r a m type to s u p p o r t aspect architectures. T h e rest of the p a p e r is s t r u c t u r e d as follows. In Section 2 the aspect architecture a p p r o a c h is elaborated. In Section 3 the i n s t a n t i a t i o n for U M L is described a n d in Section 4 the a p p r o a c h is d e m o n s t r a t e d with a n example. Section 5 discusses the a p p r o a c h in the light of related work a n d draws conclusions.
2.
ASPECT ARCHITECTURES We a d a p t a view of [21] a n d emphasize the distinction
between concerns a n d software or o t h e r design artifacts implementing them. Concerns are conceptual m a t t e r s of interest, such as d a t a security, a n d can be t r e a t e d by one or more aspects, p e r h a p s using different techniques for different p a r t s of the system, a n d modifying different values in different ways. We use the t e r m aspect for a module t h a t is potentially able to encapsulate software or design artifacts t r e a t i n g a n otherwise cross-cutting concern. In t h e case of more t h a n one aspect corresponding to a concern the aspects can be called sub-aspects. Sub-aspects are usually shared by more t h a n one concern b u t can be composed w h e n needed to form a composite aspect m a t c h i n g a single concern. To enhance applicability in conjunction w i t h the existing b o d y of knowledge in software architectures, the aspect architecture model can be seen as a software architecture viewtype, as defined in [4]. A viewtype defines t h e types of elements a n d relationships which can be used to describe a software architecture from a particular perspective. For each viewtype several styles can b e defined. A style is a specialization of a viewtype t h a t defines a set of architectures containing some recurring forms, e.g., t h e pipe-and-filter style of the c o m p o n e n t - a n d - c o n n e c t o r viewtype. Binding a style to a particular system forms a view containing elements a n d relationships p e r t a i n i n g to t h e system.
2.1 Sub-Aspects and Overlapping A l t h o u g h current aspect-oriented approaches enforce m o d u l a r i t y to a u g m e n t or modify existing artifacts, there is only some preliminary s u p p o r t for designing aspects by composing simpler aspects [19]. However, aspects t h e m selves can be complex, a n d m u s t be a d a p t e d over t i m e to changing requirements, a n d thus need to be designed incrementally. Moreover, collections of aspects have interrelations a n d cooperate to t r e a t various concerns of the system, a n d these relations need to be explicit. As will be d e m o n s t r a t e d , the overlapping p a r t s of different aspects may contain some sub-aspects interesting in their own right. These sub-aspects can address some concerns t h a t were not initially identified b u t which become import a n t during the life cycle. This often justifies a remodularization where the c o m m o n p a r t s and t h e specialized p a r t s are t r e a t e d in separate aspects. For example, consider again a system i m p l e m e n t e d in a conventional non-aspect language w i t h two overlapping, system-wide, concerns: providing security of key variables a n d preventing overflow of variables. T h e security concern is addressed by encrypting and decrypting some values at sensitive points and the overflow by checking in advance t h a t the needed d a t a m a n i p u l a t i o n s stay within a fixed range of values. However, the artifacts addressing these two concerns are closely intertwined, in t h a t t h e encryption can assume values within those provided by the code i m p l e m e n t i n g the overflow concern, and needs to provide decrypted values within those limits. P e r h a p s initially t h e r e is no separately identified concern dealing with either security or overflow. A remodularization could make the locations a n d tasks dealing w i t h the concerns identifiable a n d separable from the rest of the system. W h e n the h a n d l i n g of the two concerns are isolated into aspects to ease m a i n t e n a n c e it is immediately recognized t h a t the aspects c a n n o t be orthogonal b u t there must be some overlap. T h e interest t h e n t u r n s to this overlap
which can be again isolated into a sub-aspect included in b o t h security a n d overflow concerns. T h e recognition of t h e sub-aspect can be vital if for i n s t a n c e the security scheme is changed and seamless co-operation w i t h t h e overflow prevention should b e guaranteed.
2.2 Modeling Aspects In a n aspect architecture, a n aspect is a m a p p i n g describing a possibly cross-cutting i n c r e m e n t to a n existing design. For example, consider a n artifact, given in a n objectoriented language, consisting of class C. Aspect 1 A which adds a class D, a subclass of C, a n d introduces a m e t h o d m to C, m a p s t h e artifact to a n a u g m e n t e d one consisting of C including t h e m e t h o d m a n d t h e subclass D. As used here, aspects are inherently generic, i.e., they can be i n s t a n t i a t e d several times. To s u p p o r t reuse, t h e y are split into two disjoint parts, similarly to [13]. T h e uses p a r t describes the "join points", to which t h e aspect is to be applied as well as t h e i r wider context, a n d can be seen as p a r a m e t r i c elements, b u t of design artifacts r a t h e r t h a n j u s t variables. T h e defines p a r t introduces t h e a u g m e n t a t i o n s . For instance, in t h e case of a generic version of the aspect A, above, t h e uses p a r t could consist of class C a n d t h e defines p a r t of subclass D a n d m e t h o d m. A could b e i n s t a n t i a t e d for any artifact containing a class, by binding C to t h e class a n d r e n a m i n g D a n d m if needed. Besides describing t h e points to hook up new s t r u c t u r e or behavior, t h e uses p a r t c a n be used to restrict t h e context in which the aspect is applicable. For instance, consider h a v i n g a n aspect e n c a p s u l a t i n g a n a l g o r i t h m which detects termin a t i o n of a c o m p u t a t i o n in a d i s t r i b u t e d system (see, for instance [5, 11]). T h e uses p a r t can s t a t e t h e s t r u c t u r a l a n d behavioral a s s u m p t i o n s a b o u t the underlying system which g u a r a n t e e t h a t t h e aspect is applicable, i.e., t h e t e r m i n a t i o n is detected. C o m p o s i t i o n of aspects is based on t h e superimposition principle. S u p e r i m p o s i t i o n is a n a s y m m e t r i c o p e r a t i o n in which one aspect is applied on top of a n o t h e r one. A superimposition of aspect B on t o p of A is d e n o t e d by B / A ( B over A). If no b i n d i n g between t h e elements is done B / A = A / B . However, if some element in the uses p a r t of B is b o u n d to a n element in A, B m a y have to b e applied on top of A. Concerning the architecture, this causes B to depend on A (and is t h e definition of t h e depend relation). For example, if a n aspect for m o n i t o r i n g a system defines new counter variables to record how often a variable is referenced, a n d a n aspect t r e a t i n g overflow needs to consider all numerical variables, clearly the overflow aspect m u s t b e on top (be applied after) t h e one for monitoring. O n t h e o t h e r h a n d , if t h e m o n i t o r i n g aspect only prints values occasionally, a n d has no new variables, t h e n t h e two aspects can b e applied in either order. T h i s is trivial to see if, say, x is monitored, while y is t r e a t e d for overflow. In fact, it holds even if b o t h t r e a t t h e same field, b u t t h e n d e p e n d s on the fact t h a t m o n i t o r i n g does not modify t h e field. In more detail, t h e elements in t h e uses p a r t of B (the numerical variables or m e t h o d s to b e t r e a t e d for overflow in t h e example above) can b e b o u n d to the elements in t h e uses a n d defines p a r t s of A (the elements of t h e aspect for monitoring, including t h e new counters, a n d t h e numerical 1An aspect consisting of only a small detail is seldom crosscutting. However, aspects can be cross-cutting as more complex ones a n d those composed of simpler aspects usually are.
variables which it may use from t h e underlying system to which it is applied). T h e uses p a r t of t h e composite aspect consists of t h e uses p a r t of A a n d u n b o u n d elements of t h e uses p a r t of B (i.e., numerical variables for overflow treatment, a n d others for monitoring). T h e elements defined in B using the b o u n d elements (e.g., m e t h o d s inside b o u n d classes), must b e added to the corresponding elements in A. T h e u n b o u n d elements of B are added to A as such. Additional details on t h e restrictions on orderings can be found in [18]. Here we conservatively define aspects as d e p e n d e n t if they c a n n o t be shown independent. T h e same generic aspect can b e utilized several times in one system. For example, aspect A can be applied twice in a generic composite aspect to a u g m e n t two disjoint classes with new subclasses and methods. Also, such a composite aspect can be i n s t a n t i a t e d several times for a specific design. In superimposition B / A , to provide greater flexibility a n d a c c o m m o d a t e m a i n t e n a n c e of designs, in addition to the regular binding described above, we allow a special type of binding between t h e elements defined by t h e aspects. A n element a defined by A can be replaced by elements bl,.., b~ defined by B, provided it is shown t h a t t h e properties of A which need to be preserved are preserved. Note t h a t this can also include replacing a single relation (e.g., a n arrow representing a transition) by a s u b s t r u c t u r e (e.g., a n encoding algorithm). W h e n a n element n a m e appears b o t h in A and in B, or r e n a m i n g is used to make previously distinct names identical, this m e a n s t h a t they are identified by t h e replacement binding. R e n a m i n g can also be used to prevent identifying elements t h a t in A a n d B j u s t h a p p e n to have the same n a m e b u t are unrelated. On the one hand, using the binding to replace a defined element with a s t r u c t u r e consisting of several elements corresponds to a sort of refinement. O n the o t h e r hand, a used element can serve as a n abstraction of a complex s t r u c t u r e defined by some other aspect. In this case, the element is b o u n d to (the elements constituting) the complex s t r u c t u r e when the corresponding aspects are composed. Additionally, rules should be given to ensure t h a t the binding preserves t h e s t r u c t u r e of superimposed elements (similarly to [17]). For example, if a class C is b o u n d to a n o t h e r class E , a m e t h o d in C (either defined or used) can either be left u n b o u n d or be b o u n d only to a m e t h o d in E.
2.3
Architecture
In aspect architectures t h e aspects are used as building blocks. Each concern is addressed in a m o d u l a r way by a collection of aspects, ordered by the depend relation. To deal with a concern, the aspects w i t h i n it can either be applied to a given underlying system one after t h e o t h e r in the indicated order, applying the given dependencies, or the aspects can be combined first a m o n g themselves into a complex aspect, t h a t in t u r n is applied to a n underlying system. Note t h a t an aspect w i t h o u t any uses elements is simply a regular design. Thus, if desired, any underlying system design can be viewed as a n aspect. Consider our earlier example with security and overflow concerns. In the absence of o t h e r concerns t h e architecture could comprise only three aspects: A n aspect C containing the p a r t s addressing b o t h concerns, a n d two others, S a n d O, containing the p a r t s addressing exclusively security and overflow, respectively. T h e s i t u a t i o n is illustrated in Figure 1. For instance, if there is a c o m m o n class with two m e t h o d s
.... . . . . . . . . :L. ~.:... 7 ............... ~..
/it ii //
"'
/
¢[s
.,,
,,
"'.
//
/"
/ /
/ .............. ...
J',
s'" J
".
I
/
'.
,
/
""
• "...
.." • ".. ...........
...""
Aspect .........
Overflow concern
...........
Security concern
D
app~adAudJonl~k +©tHeadet .op
F i g u r e 2: Slice corresponding to recording feature.
there is a considerable overlap between them. In fact, there are several kinds of overlappings. Firstly, the subsystems responsible for saving and retrieving the messages utilize the same classes but involve different operations in the classes. Secondly, in the user interface subsystem, the slices not only use the same classes but also the same operations. Thirdly, both contain a statechart for the AudioController class with a common state Idle. The slice corresponding to the alarm clock feature is depicted in Figure 4. It consists of subsystems for representing time and date, storing and keeping track of the alarm, and playing the alarm sound. Again, there are also the user interface classes which implement the inputting of time, date and alarm information as well as information shown to the user while the alarm sounds. It can be seen that some of the user interface classes and operations are the same as in the two previous slices. Also, the playing of the alarm is implemented largely as the playing of a message.
Sl-~cr ~techa~
[ plays~
AudioContmll~stau:charl [ la M~s c
I¢
-Iayingcla~ diagram
+playNoteO +PIaYC'h~dO +sil©+lce.O
Alarmclock elm diagram
[0~I
~..Z:~_....~
~ b = = = = J ~ ~ _ ~ r
- contenu of
*
i uza.lma.f*~
~.-7
...... 0 +fomO
I ''~ ...... ~qayings c q ~ c 6.agram
I
::+,%,o.0
,
I FZZZsq
playM~sagc gaAudioBl~k getS~pl¢
,>~
playS~pl¢ get.Sample playS~pl©
•
F i g u r e 4: S l i c e c o r r e s p o n d i n g t o a l a r m c l o c k f e a t u r e .
gclAudioBlock
>
g~ampl¢ phyS~ple geISmple
,..... ............................ )
>0
/..
/ 1 "/"
..."
~--.~..~'x\
..........
playSmple
', F i g u r e 3: Slice c o r r e s p o n d i n g
to playing feature.
/ ,'"
',,
/
~
++, ..../"
Although the slices provide views of different concerns as such, the overlap between them is hard to see and understand. Thus we will remodularize this system based on a decomposition into aspects grouped into concerns. First, considering the system bottom-up, each of the hardware components is modeled as a black box, i.e., as a class denoted as u s e s which is a wrapper for the hardware component, and a statechart (also denoted u s e s ) specifying its minimal expected behavior. The aspects we consider do not need to further design these components, but if desired, separate, more detailed, aspects could be written for them. In this way, the new design can facilitate hardware/software codesign by using aspects. Similarly to hardware components, some fundamental classes can be identified describing the low-level software, e.g., UserInterface and AudioController. Each of these singleton classes is denoted as u s e s and could be introduced in a separate aspect. Turning to a top-down analysis, as already noted, the concerns of the system can be divided into Recording, Playing, and Alarmclock functionality, seen in the slices in Figures 2 - 4, respectively. However, now we consider these concerns as collections of generic aspects. In Figure 5 one possible
........
Recording concern
.....
Playing concern
.......""
............ A]a.rmclock concern
F i g u r e 5: C o n c e r n d i a g r a m :
Main features.
concern diagram consisting of the main features is depicted. The simplest aspects have been left out. The concerns are all overlapping because all three include the GUI aspect. Now the details of the component aspects are considered. The main functionality of the graphical user interface is captured in one aspect, called GUI. The class diagram of the aspect in Figure 6 u s e s empty class UserInterface, class Keyboard containing a public operation getLastKey and class Display containing public operations on and off. The aspect d e f i n e s six new classes and several operations and relations. For instance, public setUserMode operation is added to the UserInterface class. Additionally, behavioral diagrams could be given specifying the behavior of instances of both used and defined classes. The common parts treating recording and playing are captured by a Memory aspect describing how messages are represented in the memory. The Memory aspect illustrated in Figure 7 u s e s the AudioController class, and introduces
GUI classdiagram ]
If Recordclassdiagram 1 ....K~+:~i;r+" ................."]
t Userlmeffac~
/
[...t.~!~!!
[.............. A~i,.K;ontroller
I
.........
f~+ax~++i+~ +~off~r
+meonilVless~e
++getl~stKcyO ]
UserM~xte
+rccordAudioBlock
+activateO +deactivateO +update()
?
GraphicsContext
[
+drawLine0 +drawPoint0 +drawText0 +foreGroundColor0 +baekGroundColor0 +font() +clear() +setViewPort0
I
l RecordingUserMode
LL F i g u r e 8: R e c o r d aspect.
F i g u r e 6: G U I a s p e c t .
Outpmclassdiagntm" i s~t~iz~EX;L~3gi;iJi +phyNo~0 [:+:+;~:i ~yCh~rd0 +silea~0
Memory
Memoryclass diagram
I
Amt,,O.~p,t
,...:.t+"++f' .............. ~:;~:--l
.!+~'^'di+'~°~,,~,o+.~,~ P+"~°'+'+
[i!'ili!'!'i'i.!!'iii~ii!.!.iiiii'~-me~" J-~MessageMemOry onten~
F i g u r e 9: O u t p u t
*
aspect.
is a sequenceof*
F i g u r e 7: M e m o r y aspect. Playclassdiagram
]
i:iiiii:+;+ii!iiiiiil+ .......... "+++ three classes and four relations. The Record aspect, in Figure 8, defines class AudioInput and adds new operations to AudioController, Message and AudioBlock classes which are needed to implement the recording feature. The used association between the AudioController and Message classes serves as an abstraction of a more complex relationship defined in the Memory aspect. The aspect defines new relations between classes and a new state Record-on to the statechart of class AudioController. Furthermore, the aspect introduces a new subclass RecordingUserMode for the class UserMode introduced in the GUI aspect. Additionally, the sequence diagram shown in Figure 2 is included in the aspect, but omitted from the Figure. The Output aspect in Figure 9 captures the common parts of playing and alarm clock features related to outputting sound. The aspect introduces classes AudioOutput and Synthesizer. The Play aspect, in Figure 10, adds new operations to AudioController, Message and AudioBlock classes which are needed to implement the feature. It also defines a new state Play-on in the statechart of class AudioController. Further-
_ _ ~ playlVlcssag¢ (..!!.Uv...~ _ i ~'p]~- ~
t
,
........................................................ +playAudtoBIock,) +.ml~'tOuJputFitte~) I I~ayingUserMode
F i g u r e 10: P l a y a s p e c t .
more, the aspect introduces a new subclass PlayingUserMode for the class UserMode defined in the GUI aspect. The sequence diagram shown in Figure 3 is also included in the aspect, but omitted from the Figure. We have divided the design of the Alarmclock concern into two aspects, in addition to the GUI and the Output. The Clock aspect describes the clock using the hardware timer. The aspect is depicted in Figure 11. It defines Time and Date classes to encapsulate the representation of time. Additionally, two new subclasses SettingTimeUserMode and SettingDateUserMode of UserMode are introduced for in-
Clock classdiagram
AudioControllerstatech~ 7 ......................J~
Time
Date
+get() +sctO
+gctO +sctO
+nextDay0
+nextSccondO +cycleMinuteO +cyclcHourO
+cyclcMonthO +cyclcYcarO
play Alarm
May&Alarmsequencediagram I •Ala~N~k
[ :1l~erlnlerfJ~:~.
press play
SettingDateUserMode
:~.di~"nntmlhr
)
~-
pluyMessage
alarm
)
Figure I I : Clock aspect.
playAlarm
display alarmindicat~
( press stop
stop
Alarmclass diagram now
[
AlarrnClock
+g~mmeO
+getDate0 +setAlarm0 +gctAlarmState0 ]+sctAhrmStatc0
alarmtime I
~:3
| f'~
today
I
~ l l e r
t.~
F i g u r e 13: P l a y & A l a r m a s p e c t .
l
Alarmwhilephym8 concern
r' '"'"t""~
(i"
...............................1
AudioContro]stat¢chart ] ~...._..,~ playAlarm [ +selec((h)ipuWilwr,)
)
F i g u r e 14: A l a r m w h i l e p l a y i n g c o n c e r n .
F i g u r e 12: A l a r m a s p e c t .
putting the corresponding information. The Alarm aspect (Figure 12) uses the Time and Date classes introduced in the Clock aspect. Among other things, it defines the AlarmClock class with operations to set and get the alarm and to query the state of the alarm. After depicting the aspects comprising the prime concerns of the system, the concerns and aspects defining the interactions of the concerns are given next. Because of the physical characteristics of the device, playing and recording features cannot interfere with each other. However, the alarm clock feature interferes with both of them. It must be decided what should happen if the alarm occurs while the user is playing or recording a message. Each of the problematic feature combinations is resolved in a concern treated by a single new aspect in addition to the interacting concerns, which may often prove a valuable strategy. In case of playing and alarm, the alarm is given the priority. This is indicated in the statechart of class AudioController by adding a transition from state Play-on to state Alarm-on triggered by a playAlarm event. However, we do not add a transition in the opposite direction, which means that the system does not automatically resume playing after an alarm. The aspect, depicted in Figure 13, includes a sequence diagram illustrating the scenario when the alarm occurs while playing a message. The corresponding concern
is shown in Figure 14. Similarly, an aspect (Figure 15) and a concern (Figure 16) are given to specify what should happen if the alarm occurs while recording a message. The situation here is somewhat different from alarm/playing interference. Because there are separate sound channels for inputting and outputting audio, it might be feasible to just let the alarm sound while recording. However, to ensure that a recording is not ruined because of the alarm, we have decided only to display the alarm indicator on the display and not to output sound. When the user stops recording, the AudioController goes to state Alarm-on and starts to play the alarm sound. To stop the alarm, the user has to push the stop button again. This behavior is modeled by adding two substates to the statechart of AudioController. Substate AlarmInRecord-on indicates displaying the alarm indicator. If the alarm does not occur while recording, the stop event triggers the transition to the Idle state (guard condition IN Normal). However, if it does, the event triggers the transition taking to the Alarm-on state (guard condition IN AlarmInRecord-on). The design of the complete system is obtained by composing all the aspects addressing the concerns. Figure 17 illustrates the composed AudioController statechart. It contains all the states, transitions, triggering events and guard conditions added in various aspects. If some element has been defined in more than one aspect, identity binding is used in their composition. This applies, for instance, to the stop operation, corresponding to the stop event', in class Au-
AudioController statechart [ AudioController statechar~
stop[IN Normal] r
stop
I
r~:~9
F~]21< I I
stopl I playAlarm
--
•[
~
/(Re¢ord-onjl ]
/I
#~°~d-°~T /
L
"
.......
)
I
.......~ .,s!,o,t!INAlarmlnRecord--on] Marm..on I f
! Record&Alarm seq. . . . diagram [
...................
:Ala~CI~k
l_IzeL
'l
I~erlnt~rfa~
' AudinC'nnhroller
F i g u r e 17: C o m p o s e d A u d i o C o n t r o l l e r s t a t e c h a r t .
press mcord recordMessag¢
alarm
)
) playAlarm
display alarm indicator
< press stop
) stop
)
press stop
H
) stop
)
F i g u r e 15: R e c o r d $ z A l a r m a s p e c t .
...... .........................................
. . . . . . .
F i g u r e 16: A l a r m while r e c o r d i n g c o n c e r n .
dioController. Alternatively, the operation could have been introduced in a separate aspect and included in the u s e s parts of the aspects defining recordMessage, playMessage, and playAlarm operations.
5.
DISCUSSION
The aspect architecture model is based on the superimposition principle [5], first incorporated into a language construct in [11], which has a close connection with aspect orientation [12, 18]. Superimposition, as well as other methodologies based on stepwise refinement, provide support for traceability of cross-cutting concerns across the intermediate design descriptions obtained by applying the steps (aspects). Using the concern diagram it is easy to trace requirements in the design, because the collection of aspects addressing each requirement can be made visible, as was shown in the example. Moreover, to support reusability, the u s e s part can express the context in which the aspect is applicable. For instance, the GUI and Memory aspects, described in the example, could be easily reused in a totally different design. To minimize change propagation, the overlapping parts of the different cross-cutting concerns are stated explicitly.
Thus, if a cross-cutting concern needs to be changed, disjoint concerns should be unaffected. Moreover, the effects on the overlapping concerns can be examined using the concern diagram. If the changes are made to an aspect that is not shared between concerns, for instance the Play aspect in the example, it reduces to the case with disjoint concerns. However, if a change is made to a shared aspect, for instance the GUI aspect in the example, the effects on the concerns sharing the aspect must be dealt with. In [2], change management utilizing a similar architecture in the DisCo setting is discussed in depth. "Mix-and-match" of features to suit different members of a software family is achieved by composing different collections of the aspects constituting the family (similarly to [14]). For instance, a lower-end version of the digital sound recorder, not including the alarm clock feature, can be obtained by excluding the Alarmclock concern and any aspects unique to it (here, the Alarm and Clock aspects) from the composition of the aspects. Alternatively, a high-end product containing hierarchical memory supporting compressed messages could be modeled by composing an aspect describing that design instead of aspect Memory. An aspect architecture enhances parallel development. The concern diagrams can be used to coordinate different teams working on different concerns. Only the common aspects of overlapping concerns need to be decided jointly by the teams working on the concerns. The common aspects effectively deride an interface between the concerns. As with conventional interfaces, it must be anticipated that some iteration is needed before the common aspects are established. In addition to DisCo and OPM/Web, the main aspectoriented development approach with explicitly defined aspect relationships is Aspect-Oriented Component Engineering (AOCE) [6, 7] which supports aspect-orientation throughout the life-cycle of specification, design, implementation, and deployment in the software component domMn. Aspects are used to describe systemic properties, like distribution, security and persistence, that components provide functions for or require functions from other components [7]. The d e f i n e s and u s e s parts in our approach correspond to the provided/required services method in AOCE and grouping of aspects provided by AOCE can be used to capture concerns. However, instead of utilizing these techniques in a restricted domain, our approach defines a more generally applicable model which can be instantiated for different domains, like the Hyperspace model [22, 15], and provides support for architectural views of aspects in a particular domain. We have also outlined an instantiation for UML, corresponding roughly to Theme/UML [3] which can be seen as an instance of the Hyperspace model. Compared with
A class-independent module mechanism. In ECOOP 2002 - Object-Oriented Programming 16th European Conference, volume 2374 of LNCS, pages 62-88. Springer-Verlag, 2002. [10] H.-M. J£rvinen, R. Kurki-Suonio, M. Sakkinen, and K. Syst£. Object-oriented specification of reactive systems. In Proc. 12th International Conference on Software Engineering, pages 63-71. IEEE CS Press, 1990. [11] S. Katz. A superimposition control construct for distributed systems. A CM Transactions on Programming Languages and Systems, 15(2):337-356, Apr. 1993. [12] S. Katz and J. Gil. Aspects and superimpositions. Position paper in Aspect Oriented Programming workshop in ECOOP'99, Lisbon, Portugal, June 1999. [13] P. Kellom/iki. A structural embedding of Ocsid in PVS. In Theorem Proving in Higher Order Logics, number 2152 in LNCS, pages 281--296. Springer-Verlag, 2001. [14] P. Kellom£ki and T. Mikkonen. Separating product variance and domain concepts in the specification of software product lines. Position paper in ECOOP 2000 workshop on Aspects and Dimensions of Concerns, Sophia Antipolis and Cannes, France, June 2000. [15] H. Ossher and P. Tarr. Multi-dimensional separation of conceims and the Hyperspace approach. In M. Aksit, editor, Software Architectures and Component Technology. Kluwer Academic Publishers, 2001. [16] I. Porres Paltor and J. Lilius. Digital sound recorder: A case study on designing embedded systems using the UML notation. Technical Report 234, TUCS Turku Centre for Computer Science, 1999. [17] I. Reinhartz-Berger, D. Dori, and S. Katz. Open reuse of component designs in OPM/Web. In Proe. COMPSAC 2002, pages 19-24, Oxford, England, Aug. 2002. IEEE CS Press. [18] M. Sihman and S. Katz. A calculus of superimpositions for distributed systems. In Proc. 1st International Conference on Aspect-Oriented Software Development, pages 28-40, Enschede, The Netherlands, Apr. 2002. [19] M. Sihman and S. Katz. Superimpositions and aspect-oriented programming. Submitted, 2002. [20] S. M. Sutton, Jr. and I. Rouvellou. Modeling of software concerns in Cosmos. In Proc. 1st International Conference on Aspect-Oriented Software Development, pages 127-133, Enschede, The Netherlands, Apr. 2002. [21] S. M. Sutton, Jr. and P. Tarr. Aspect-oriented design needs concern modeling. Position paper in the Aspect Oriented Design workshop in conjunction with AOSD 2002, Enschede, The Netherlands, Apr. 2002. [22] P. Tart, H. Ossher, W. Harrison, and S. M. Sutton, Jr. N degrees of separation: Multi-dimensional separation of concerns. In Proc. 21st International Conference on Software Engineering, pages 107-119, Los Angeles, CA, USA, May 1999. ACM Press. [23] R. J. Walker. Eliminating cycles from composed class hierarchies. Technical Report TR-2000-07, Dept. Comp. Sci., Univ. of British Columbia, Canada, 2000. [24] DisCo W W W site. At h t t p : / / d i s c o . cs. r u t . f i .
Theme/UML, we do not define "composition patterns" as separate entities. Instead, behavioral inter-aspect relationships in composition can be captured as generic aspects and new concerns in the design, as was demonstrated in the example. Furthermore, Theme/UML, like other UML-based aspect-oriented design approaches, does not provide architectural support, other than that of standard UML, for aspects and their interactions. Cosmos is a general purpose concern modeling schema [20]. Schemas are built from concerns, relationships and predicates. In future work, we hope to investigate how to map requirements described using Cosmos schemas to aspect architectures. The concerns at the design level can and should be reflected in the programs, by using programming level constructs for aspects. Otherwise, most of the power of aspectorientation is lost. Towards this end, we envision mapping our design aspects to superimposition steps of SuperJ [19] or modules of Mix Juice [9]. The aspect architecture model provides an aspect-oriented perspective on software architecture. On the one hand, the model can been seen as a software architecture viewtype [4]. On the other hand, as demonstrated with the example in the UML context, aspects can contain views of other viewtypes thus contributing to modularizing multiple views. Future work includes further development of the model in relation to the existing methodologies for architecting software.
6.
REFERENCES
[1] T. Aaltonen, M. Katara, and R. Pitk~nen. DisCo toolset - the new generation. Journal of Universal Computer Science, 7(1):3-18, 2001. [2] T. Aaltonen and T. Mikkonen. Managing software evolution with a formalized abstraction hierarchy. In Proc. Eight IEEE International Conference on Engineering of Complex Computer Systems, Greenbelt, MD, USA, Dec. 2002. IEEE CS Press. [3] S. Clarke. Extending standard UML with model composition semantics. Science of Computer Programming, 44(1):71-100, July 2002. [4] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford. Documenting Software Architectures: Views and Beyond. Addison-Wesley, 2002. [5] E. W. Dijkstra and C. S. Scholten. Termination detection for diffusing computations. Information Processing Letters, 11(4):1-4, Aug. 1980. [6] J. Grundy. Multi-perspective specification, design and implementation of software components using aspects. International Journal of Software Engineering and Knowledge Engineering, 10(6):713-734, 2000. [7] J. Grundy and R. Patel. Developing software components with the UML, Enterprise Java Beans and aspects. In Proc. 2001 Australian Software Engineering Conference, pages 127-136, Canberra, Australia, 2001. IEEE CS Press. [8] W. Harrison, P. Tarr, and H. Ossher. A position on considerations in UML design of aspects. Position paper in Workshop on Aspect-Oriented Modelling with UML in conjunction with AOSD 2002, Enschede, The Netherlands, Apr. 2002. [9] Y. Iehisugi and A. Tanaka. Difference-based modules: 10
