Checking timing constraints in software system using AOP

Cheeking timing constraints in software
system using AOP
D o T u a n A n h
Faculty of Information Technology
College of Technology
Vietnam National University, Hanoi
Supervised by
Dr. Truong Ninh Thuan
A th e s i s s u b m i t te d in fulfillm en t o f t h e re q u ir e m e n t s for th e d e g r e e o f
M a s te r o f I n fo r m a ti o n T ec h n o lo g y
D e c e m b e r, 2 0 0 9
DAI HOC QUÔC GIA HÀ NÔI
TRUNG TÂM THÔNG TIN THU VIÊN
i 'L o / 6
(n

-

.

-
r a b l e o f C o n t e n t s
I n t r o d u c t i o n 1
1.1 M o t i v a tio n 1
1.2 O b je c t i v e s 2
1.3 C o n t r i b u t io n s 3
1.4 O utlin e of th e thesis 3
B a c k g r o u n d 5
2.1 U M L an d U M L T im in g D iag ra m 5
2.1.1 O v erv iew of U M L 5
2.1.2 U M L T im ing D i a g r a m 6

2.2 A s p e c t O rien ted P ro gr a m m in g an d A spect.) 8
2.2.1 A spect O rien te d P r o g r a m m in g 8
2.2.1.1 T erm in o lo gy 9
2.2.1.2 I m p l e m e n t a tio n 10
2.2.1.3 S om e lim ita tio n s of O O P
11
2.2.1.4 B en efits of A O P 14
2/2.2 A s p e c t , ) 16
2.2.3 R e m a r k s 17
2.3 S um m a r y 18
C h e c k i n g t h e c o n f o r m a n c e o f t im i n g c o n s t r a i n t s 19
3.1 G e ne ratin g verification as p e c ts to check th e c o n f o r m a n c e

19
3.2 A chiev ing tim e from sp ec ification an d i m p le m e n ta tio n 21
3.2.1 T h e o rder of e v e n t s 21
3.2.1.1 O rde r of e v e n ts in a a p p l i c a t i o n 21
3.2.1.2 O rd er of ev e n ts in several a p p l i c a t i o n s

22
3.2.2 R ea d ing tim ing c o ns train t in specification 23
3.2.3 C a lc ulatin g e x e cu tio n tim e from im p le m e n ta tio n

25
iv
3 .2 .‘5.1 T h e before a d v i c e
25
3.2.3.2 T h e after a d v i c e 2(5
3.3 C ase s t u d i e s 26
3.3.1 A u to m a te d Teller M achine for b ank ing p u r p o s e

26
3.3.1.1 O bjec tiv e of this case s t u d y
2(5
3.3.1.2 T im in g co n strain ts in W ith d ra w a l s c e n a r io

27
3.3.2 T ak in g off p ro ce ss of a n a ir p la n e 29
3.3.2.1 O bje c tive of th is case s t u d y
29
3.3.2.2 T im in g co n strain ts of tak in g off pro c e ss 29
3.4 S u m m ary 31
4 I m p l e m e n t a t io n 32
4.1 T h e arc h itec tur e of the sup p ort t o o l 32
4.2 O b sta cles in th e im p le m e nta tio n of su p po rt t o o l 36
4.2.1 D ifficulties in rea d in g tim in g co n stra int from th e T im in g D i
a g r a m 36
4.2.2 Aspect.) co de for checking tim ing c o n s t ra in ts 37
4.2.3 So m e resu lts an d r e m a r k s 38
1.3 S um m ary 39
5 R e l a t e d W o r k 41
5.1 B uilding a set of tool and m eth o ds for c h e c k i n g 41
5/2 B u ilding form al facilities for c h e c k i n g 42
5.3 C hecking an d eva lu ating in som e rea l-tim e s y s t e m s 13
6 C o n c lu s i o n a n d p e r s p e c ti v e 44
6.1 C o n c lu s io n 44
6.2 F ur th er r e s e a rc h 45
T A B L E O F C O N T E N T S v
L i s t o f F i g u r e s
2.1 U M L 2.0 D i a g r a m s 6

2.2 U M L J o nc is e T im i n g D iag ram 7
2.3 U M L lo b u s t rim in g D i a g r a m 8
2.4 A n e xu np lc of code t a n g l i n g 12
2.5 A n e xam ple of cod e s c a t t e r i n g 13
3.1 U M L S equ ence T im i n g D ia g ra m 20
3.2 T em plate for th e V erificatio n A s p ec ts 21
3.3 T h e event E i is se p a ra te d from t h e event E 2 22
3.4 T h e event E i is cov e re d by th e even t E -2 22
3.5 T h e event Ei is ov erla pp ed to th e event E *2 22
3.6 O rd e r r e l a t i o n 23
3.7 T h e relation ov e r l a p 1 ' befo re’’ 23
3.8 T im in g co n s tr a ints a re re pre s e n ted in a tim ing d i a g r a m 24
3.9 User is us in g A TM 27
3.10 UM L S equ e n c e D iag ra m o f th e W ith draw al s c ena rio

28
3.11 U M L T im in g D ia g ra m of th e W ith dr a w al sc e n ario 28
3.12 An airp la n e is ta k in g o f f 29
3.13 T im in g D iag r a m of a ir p la ne ease s t u d y 30
1.1 T h e g ene ral ch ecking p r o c e s s 33
4.2 T h e tim e sta m p s o f tw o p a r t s 34
4.3 T h e arc h itect ure of p ro po sa l tool
34
4.4 A piece of co d e to read th e tim ing co n s tra ints i n f o r m a t i o n

38
4.5 G en era ted V erification A sp e c ts 39
vi
C h a p t e r 1
I n t r o d u c t i o n

1.1 M o tiv a t io n
T h e development- of soft w an ' in recent y ears d e m an ds softw are sy s te m s m ore and
m o re reliable a n d ro b u st. Beside th e benefit of softw are, the d am ag e m ay b e severe if
so ftw are erro rs ap p e ar in th e exe cu tion. T h is challenge req u ire s softw a re develop ers
h a v in g efficient m et hods to verify softw are sy s te m s before u sin g th em in pra ctice.
S oftw are verification is th e pro cess to ensu re th e co rrec tn e ss of software. T he re
are m an y pr o pe r tie s to b e verified like in v a rian t, p re /p o s t c o nd itio n , p ro toc o l exec u 
tion , etc. B eside th e verification of o th e r p ro pe rtie s of so ftw are sy s te m , th e tim in g
c o nstra ints are im p o rta n t, p artic ula rly in e m b e d de d s o ftw are an d r e a l-tim e so ftware
like the airc ra ft flight con trol sy s tem . T h e checking of tim in g c on stra ints in so ftware
sy s te m m o r e a nd m o re im p o rtan t in softw are eng in eerin g tod ay.
In so ftw are d ev elop m en t, spe cification is th e process use d to desc rib e overview
s t r u c tu re an d co n str a in ts of so ftw are system s. T h is process allow s sta k e h old e rs u n 
d er s ta nd in g fu n ction s, tasks and activit ies of th e sy ste m . B ased on th e specification ,
p r o g ra m m er s th en im plem ent th e sy ste m u sing p ro g ra m m in g lan g uages. T h e im 
p lem e n tatio n m a y lead to error. A ccordingly, we need som e a u to m a tic m eth o d s to
verify if th e im ple m en tatio n satisfy its specification.
T im i n g co ns tra in ts are one of th e m o st im p o rta n t charac teristics in real-tim e,
e m b ed d e d s y stem s. D esigning su ch sy s te m s requ ires tim in g co n s tra ints in specifica
tio n d o cu m e n ts, which are so m e tim e s referred to as critical sections. It is d es irab le
to b e au to m a tic all y checked as p r o g ram are be in g d ev e lo p e d a n d late r m ain ta in ed .
S om e s ta tic an alysis m e th od s have been p rop o s ed (W eg en er & G ro ch tm a n n,
1
2
C h a p t e r 1 . I n t r o d u c t i o n
1998) to predict the w o rst-case a n d be st-eas e ex ecu tion tim es of a ta sks code or to
e st i m a te the tim e e x ecu tio n of a piece of sou rce code. T he s e m e th o d s an a lyzes th e
e x ec u tio n p ath s a n d sim u la tin g p ro ce ssor c h ara c te ristics w itho u t ever ex e c u tin g the
p ro g r a m oi requ irin g th e pro g ram s in p u t.
T h e lim ita tion of st a tic analysis is th a t, th is m eth o d is u n a b le to ap ply to large or

c o m plex softw a re sys te m s . It can w ork on ly w ith s o m e sim ple p redefin ed langu ages.
In a d d ition , th e h ard w ar e configu ration m u st be des crib e d b efore usin g th e m eth o d.
O u r ap p ro ac h is ba s e d o n the d yn a m ic checking m e th o d in w hich pro gra m s are
ch e ck e d a t ru n - ti m e a n d the tim in g analy sis is pe rfo rm ed w h e n th e p r o gra m is
ex e c ute d ; th e user ca n be inform ed o f an y p o ten tia l tim ing c o ns tra in t violations.
T h is p rom ise s to solve th e lim ita tio n s of sta tic an a lysis ap pro a c h es.
T h e r e a re som e o th e r w ays to check tim ing c on stra ints o f a sys tem , like using
P etri n e ts ( B e rth om ieu Diaz, 1991) or real tim e logic (A nd rei et a L 2004). T od a y
w ith th e ap p ly ing U M L in specification of so ftw are s y stem , espe cially th e d evelo p 
m en t of U M L 2, th e c heckin g of tim ing c o nstra ints is p erfo rm ed in U M L d iag ra m s.
U M L is used p art icularlv in so ftw are sy s te m s built using th e o b jec t- o rien ted style.
T h e U M L rep rese nts a collection of th e best eng in e e ring p ra c tices tha t h ave prov en
successful in th e m o d eling of large an d com plex system s. It is used p artic ula rly in
so ftw are sy ste m s built using the ob ject-o rien te d style.
In a w ork (T rin h et al 2009b) th e co m bin a tio n be tw een A sp ect O rie n ted P ro 
g ra m m in g (A O P ) a n d th e U M L specification is c re ate d in or d er to verifyin g the
c o nf o rm ity b etw ee n th e im p lem e nta tio n a n d its specification. O b je c t inv a ria n ts an d
p ro to co l ex e cu tio n of m eth od s are p ro pe rtie s of softw are p r o gra m s w h ich ha v e been
ch ec ked usin g A O P technology.
In th is th e s is w e p ro p os e an a p pr o ac h to d y n a m ic ch eck ing a p r o p e rty of rea l-tim e
so ftw a re sy s te m s, th e tim in g co n strain ts. Ch e c k ing tim in g c o n stra ints is difficult for
so m e so ftw a re sy stem s . W e can n ot hoo k into th e s y stem , especially w ith large
sy stem s. F rom benefit of AO P, we p ro p o se a n a p pr o ac h to ach ieve th is goal.
1.2 O b je c t i v e s
T h is th e sis aim s at checking the tim in g co ns train ts of a softw are sy stem in A O P, or
m ore d et a ile d, th e con fo rm ance b etw een the sp ecification a nd th e im p le m en ta tio n
of a so ftw are s y s te m . T h e following are specific o b jectiv es th a t w e will s tu d y in th e
1 . 3 . C o n t r i b u t i o n s
3
th e s is prcgress:

• S tilly A s p e c t O rie n ted P ro g ram m in g , a m e th od olo gy su p p o rt O b je c t O rie nte d
P ro g ra m m ing to resolve th e cro ssc u ttin g concerns.
• Study U M L Specification, especially T im ing D iag ra m s, a new d iag ra m of
UML2
• Prop ose a n a p pro a ch to che cking th e tim ing co n str a in t s of so ftw are s y stem
usirg A O P
• Design some case studies to illustrate approaches
• B u id a tool for checking au t o m atic a lly th e tim ing c o n s tr a in ts of so ftw are sys
terns.
1.3 C o n trib u tio n s
T h e m a in c on tribu tion of th is t hesis is pro posin g a n ap p ro ac h t o check th e ex e cu tio n
of task s in Ja va w ith the ir tim in g c o n strain ts. T h is a p p r o a c h c a n b e su m m a riz e d
by following ste p s
• Specifying the tim in g co nstra ints of ta sk s u sing U M L T im in g D iag ra m .
• A pplying A sp ect O rien ted P ro g r a m m in g to c a lcu la te ex ec u tion tim e of task s;
using A sp e c tJ, an as p ect o rien te d ex tensio n for th e J a va p ro g r a m m in g lan 
guage.
• R u ntim e weav ing th e A sp e c t J cod e into th e so ftw are s y ste m an d ch eck in g
w he th er it satisfies tim in g c o nstra in t.
In ad d tio n, we have built a su p po rt to o l to check tim in g co n fo r m an ce betw een
specification a nd im p l e m en tatio n au tom atica lly . W e hav e also d e v elop e d so m e case
stud ie s to illustra te th e ap p ro a c h .
1.4 O u tli n e o f t h e th e s is
T h e rem a in d er of th is the sis consists of:
C h a p t e r 1 . I n t r o d u c t i o n
• C h a p te r 2 B ackg round . T h is c h ap te r in tro d u ce s som e basic con c e p ts of
A sp ec t O rien ted P ro gr a m m in g (A O P ) a n d U ML T im in g D ia g ram s - o ne of
new d ia g ram typ es o f U ML .
• C h a p t e r 3 - P ro po sed ap p roa c h of checking tim ing co ns tra in ts . In the last of
this c h a p te r we present two case s tu d ies to illustrate th e ap p roa ch .

• C h a p t e r 1 - Im p lem e nta tio n. We show th e a rch itec tu re of ou r too l bas ed on
th e ap p r o ac h in ch a p ter 3 a n d som e difficulties when we im p le m e nt th is tool.
S o m e ex pe rim e n ta l results an d ev a lu ation are also presented.
• C h a p te r 5 - Related work. C h a p t er 5 discusses some re lated w orks. W e an a lyze
th e a dv a n ta g e s an d d isavant ages of e a ch work.
• C h ap te r 6 - C o n clusio n an d p erspective. T h is ch a p ter sh o w s th e conclusion of
th e th esis a n d som e fu ture works.
C h a p t e r 2
B a c k g r o u n d
T his c h a p te r gives so m e co nce p ts of tim e and tim ing c o ns tra in t. Follow ing an
overview ab o u t th e IJML T im in g D iag ra m th at be ust'd to specify tim ing con straint
in th e p ro p os e d ap pro ac h . A fter t h at, we intro du c e A sp ec t-o rien ted pro g ram m ing , a
p ro g ra m m in g pa rad igm that increases m od u larity by e n ab ling improv e d se pa ra tio n
of c o n cern s an d A sp ect.). a sim ple a n d pra ctica l a sp e c t-o rie n te d ex tensio n to Java.
2.1 U M L a n d U M L T i m i n g D ia g ra m
2.1.1 Overview of UML
T h e Unified M o d e lin g Lan g u a g e (U M L) is a s ta n d ard from th e O bje ct M a n a g e m e n t
G ro up (O M G ). p rop osed as a sem i-form al specificatio n lan gu ag e for o bje c t orien ted
specificat ion an d design. U M L co n tain s several different d ia gra m type s, for e x am 
ple S ta te D iag ram , C ollab oration D ia g ram , S eq u en ce D iag ram , Class D ia g ram an d
othe rs. I f U M L 1.x has 9 dia g ra m typ e s. U M L 2.0 e xp an d s to 13 d iag ra m types. It
is d ivid ed in to tw o grou ps: s tru ct u re dia g ram s an d b eh av io r dia g ra m s.
F ig u re 2.1 sho w s th e U M L 2.0 an d chan g e s from th e U M L 1.5 (Shi & T orn g re n ,
2005). It sho w s tw o m a in p a rts of U M L 2.0: static p ar t ( S tr u ctu ra l D iag ra m s) an d
d y na m ic pa rt (B eha v io ral D iagram s).
• S triu c tu r a l D iag r a m s show th e bu ildin g blocks of sy stem , fea tures th a t do not
c h a n g e w ith tim e. Str u ctu ra l D iagra m s consist of 6 diag ra m s: Class D iagra m ,
O b je c t D ia g ra m . P ackag e D iagra m , C o m p o site S tru ctu re D iag ra m , Deploy
m em t D ia g ra m . C o m po ne n t D iagram
6

C h a p t e r 2 . B a c k g r o u n d
F igu re 2.1: U M L 2.0 D iag ra m s
• B eh avio ral D iag ra m s co n s ist of 7 d iagram s: A c tiv ity D ia g ram , S t a te M a ch in e
D iag ra m , Use C ase D ia g ram , Inte ra c tio n O v erview D ia g ram , Se qu e n ce D ia 
g ram , T im in g D iag ram a n d C om m u nic atio n D iag ra m .
S o m e w orks (C honoles & S c h ard t, 2003) s e pa r a te In te rac tio n d ia gr a m gro up
from B e h a v io ral D iag ra m s. If Be hav ioral D iag ra m s show h ow sy ste m r e sp o n d s to
re q ue sts or oth erw is e evolves ov er tim e. In tera c tion D ia g ram s d e p ict th e e x ch a n ge
of m e ssag e s w ithin a co llab o rat ion en r o ute to acc o m p lish ing its goal.
2.1 .2 U M L T i m in g D ia g r a m
T im in g D ia gr a m is one of th e new d ia g ram typ es a d d ed to U M L 2.0. alt h o u g h th e y
hav e b ee n one of th e core dia gra m s w ithin th e h ard w are design an d rea l-tim e co m 
m u nitie s for de c ad e s. It is b ase d on ha r d w are tim in g d ia gra m o rigin a lly d ev e lo p ed
by electrical en g inee rs. It is a specific ty p e of in terac tio n d iag ra m . It is use d to
ex plo re th e b eh a vio rs of on e or m ore ob jects th ro u gh o u t a g iven p erio d o f tim e s
(A ke rho lm et al 2006). T im in g D iag ra m sho w s th e ch a n g e of o b j e c t’s s t a t e in a
give n tim e p erio d e m ph asiz in g th e tim in g co n s tra in ts. Also it sho w s m essa g e s which
m o dify th a t sta te , l im in g di a g ra m is o ften used to design em b e d d e d so ftw are, such
2 . 1 . U M L a n d U M L T i m i n g D i a g r a m 7
as control so ftw are lor fuel injection system in an a u tom o bile , a lth o ug h it occa
sio n a lly lave its uses for busine ss softw are too (B aldw in & S cragg. 2004). S oftware
m od e lers ca n use a T im in g D ia g ram to precisely d oc um en t a sched ule of intera c tio n s
or st a te changes. T im in g D iag ra m is also a special form of a se q u e n c e d ia g ram . T h e
difference be tw een tim in g d iag ra m an d sequ ence dia g ram is th e axes are reversed so
t h a t th e tim e is increase fro m left to right an d th e lifelines are show n in se p ara te
c o m p artm en ts a rra n ge d vertically.
T im in g D ia g ram h a s tw o types: concise n ota tio n a n d r o bu st no ta tion . T h e
con cise n ota tion sho w s th e tim eline qu ite clearly. T im in g D iag ram in th e concise
n ota tio n sh o w s the lifecycle of lifelines over a period of tim e. In th is no ta tion , th e
T im in g D iag ra m will only sho w you th e sta te s of th e lifelines, th e tra n sitio n point

b etw een those» sta te s (as ind ic a te d by two lines crossing o ne an o th er) a n d th e tim e
co ns tra in t of th e dia g ra m .
sd Project Management^
{12/2008}
Create ProjecyCreate Project
Project p|an V
F ig ure 2.2: U M L C o ncise T im in g D iag r a m
T h e co ncise n o tatio n is good to be used w hen you need to ex p lo re a gen eral
beh a v ior of o ne or m ore o b jects th ro ug h o u t a period of tim e w hile original view
is used w hen you need to d r a w more d etailed in f o rm a tio n ab ou t th e tra n s itio ns
betw ee n the sta tes of the lifelines.
T h e robust no tatio n exp lores th e d e ta ils of w h at h a p p e n in a lifeline. M ore
lifelines are m od e led easily by ad din g oth er se ction to th e frame*.
B oth n ota tio ns hav e th eir pu rp o ses, alth ou gh th e robust n o ta tio n seem s th e m ore
useful o f the tw o p a r tic u larly for ob jec ts th at move b ack an d forth betw een state's.
8
C h a p t e r 2 . B a c k g r o u n d
F igure 2.3: U M L R o bu st T im in g D ia g ram
How ever, th e m ore lifelines are tried to m odel a t once th e h ar d e r it is to d ra w th e
d ia g ra m .
2.2 A s p e c t O r ie n te d P r o g r a m m in g a n d A s p e c tJ
2.2.1 A s p e c t O r ie n te d P r o g r a m m i n g
A s oftw are a rc h itect, w hen asked to design s o m e thin g new, first a d d re sses the pri
m a ry core functionality, w hich in a b usiness app lica tio n is th e basic busine ss logic.
In a b an k ing application , for insta n c e , core m od u les are des ign e d to m a n ag e the
ban kin g tra n sa c tio n s th a t eac h cu sto m er m akes. In a retail ap plica tio n , the core
m od ules deal with th e p u rc h a se s a n d inve n tory m an ag e m en t. In b o th ap p lica tion s,
th e sy s tem -w ide conce rn s involve such featu res as logging, a uth o riz a t io n, persistenc e,
an d o t h er elem en ts c o m m on to m a n y o f th e core business m o d u les.
L ets look at an o th e r so ftw a re exam ple. If th e arch ite c t is d e s ignin g a robo tics

ap p licatio n , th e core con c erns are th e m o tio n m an ag e m en t an d pa t h c o m p uta tion .
T h e co n c e rn s th a t arc co m m on to m a n y of th e core m o d ules invo lve fea tu res such
as logging, rem ote m a na g em en t, an d p a th op tim iz a tio n . T hese syste m -w ide con 
cerns t h a t sp an m ultiple m o d ules are called crosscutting concerns. A s p e ct-orien ted
p ro gram m ing (A O P ) m an a g es the se c ro ssc u ttin g concerns.
W h i e ob je c t-o riented p r o gra m m in g (O O P ) is th e m ost co m m o n m e th o d olo g y
em ployed tod ay to m a n ag e co re concerns, it is not sufficient for m any c ro ssc u ttin g
concerns, especially in co m plex ap p lica tion s. So A O P has em erg ed as a n im p ro v e
m e nt to existing so ftw a re so ftw are en g in ee ring techno log ies such as O O P.
A spect-orien ted pr o gra m m in g (A O P ) is a p ro gra m m in g p a r a d igm t h a t increases
m od ularity by en a b lin g im prov e d se pa ra t ion of conc ern s. T h is ent ails break in g do w n
a prog ra m into d istin c t p arts (so-called con cerns, cohesive areas o f fu n c tio n ality).
All p ro g ram m ing p a r a d igm s su p p o rt som e level of g r o u ping an d en ca p s u latio n of
concerns into se pa ra te , in de pe nd en t entities bv p rovidin g a b s tr a cti o ns (e.g. pro 
cedures, m o d ules, classes, m e tho d s ) th a t ca n be u sed to im plem en t, a b str a c t an d
co m pose these con cerns. B u t som e c o n cerns defy th ese fo rm s of im ple m e n tatio n a n d
a re called c ro sscu ttin g co n c e rn s bec a u se they cut across* m ultiple a b stra c tio n s in
a p rog ram .
In co m p ute r science, a n aspect is a p art of a p r o g ram th a t cross -cuts its core
co ncern s, th erefore violating its s e p ara tio n of concern s. For ex a m ple, logging co d e
ca n cross-cut m an y m od ules, vet th e a s p ec t o f logging sh o u ld be se p ar a te from th e
fu n c tional co n cerns of th e m o d ule it cross-cuts. Isolating such a sp e cts as logging
a n d persisten ce from b u siness logic is th e aim of th e asp ect-o r ie n ted softw are d evel
o pm e n t (A O SD ), of w hich th e A O P p ara dig m is th e m ost es ta b lishe d area.
2 .2.1 .1 T e r m i n o l o g y
T h e follow ing are som e s ta n d a r d term ino lo g y u sed in A sp e c t-o rien ted p rog ra m m in g :
• C ross-cut ting con cerns: E v en th ou gh m ost classes in an 0 0 m odel will p erform
a single, specific function , th ey often sh are com m on , s e c o nd a ry re q uire m e n ts
w ith oth er classes. For ex a m p le , we m ay w ant to ad d logging to classes w ithin
th e da ta -a c c e ss layer a nd also to classes in th e UI layer w hen e v e r a th r e ad

en ters or ex its a m e tho d . Ev en th o ug h th e p rim ar y fu nc tio n ality of each class
is very different, th e c o de n ee ded to perfo rm th e se c o nd a ry f u n ction ality is
often identical.
• Advice: A dvice is th e ac tion an d d ecision p a rt o f t h e cro ssc u tting puzzle. It
helps us define " w h at to d o ’\ A dvice is a m etho d -lik e co ns tru ct th at prov ides
a way to express c ro ssc u tting actio n at th e jo in p o ints th at are c a p tu re d by a
p o intcu t. T h e th ree kin d s of advice arc' as follows:
2 . 2 . A s p e c t O r i e n t e d P r o g r a m m i n g a n d A s p e c t J 9
— Be-ore advice exe c u te s p rior to the join point.
— After advice exe c u te s following the join po int.
Around advice su rro un ds th e join p oin ts ex ecu tion. T h is advice is sp e
cial in th at it has th e ability to b y pass e xecu tio n , co n tinu e th e original
execution, or ca u s e exec u tio n w ith an altered co ntex t.
• P o intc m : T his is th e te rm given to th e point of ex ecu tio n in th e a p plication
at which cro ss-c u tting con c ern ne ed s to be app lied.
• A sp e c t: I'he c o m bina tio n of th e po in tcu t a nd the adv ice is te rm ed an asp e ct.
2 .2 .1 .2 1 m p l e m e n t a t io n
T h ere a re tw o different w ays A O P p rog r a m s can affect o the r p ro g ra m s, de p en d ing
on th e un d erly in g languag es an d e n v iro n m e n ts:
1. A co m b in ed pro gram is pro d uce d , valid in th e original lan g u age a n d ind istin
g u isha b le from an o rd in ary p r o gra m to th e u ltim a te inte rp re te r;
2. T he u lt im a t e in te rp re ter or en viro nm en t is u p d a t e d to u n d e r s t a n d a n d im 
plem en t A O P features. T he difficulty of c h ang in g en v iro n m en ts m ea n s m ost
im p lem e n tatio ns p rod uc e co m p a tib le co m bin ation p r o gra m s th ro ug h a p ro 
cess t h a t has com e to be know n as w eaving. T h e sam e A O P lang u a g e can be
im p le m en te d th ro u gh a. variety of w eaving te chniqu e s, so the sem an tics of a.
lan gu a ge shou ld never be u n de rsto od in term s of th e w eav ing im ple m en ta tio n.
O nly t h e spee d of an im ple m e nta tion a n d its ('ase of d e p loy m en t a re affected
by w hich m e tho d of com bina t ion is used.
Source-level we aving c a n be im ple m e n te d usin g p rep ro ces so rs (as C m was im p le

m en ted orig ina lly in O F ro n t) th at requ ire access to pro gra m sou rc e files. How ever,
J a v a ’s w ell-defined b inary form ena b les b yte co d e w eavers to w ork w ith an y J a va
p r o gra m in .cllass-file form . B ytec o de w eavers c a n b e dep loye d d u rin g th e bu ild pro 
cess or, if th e weave m od e l is per-class. d ur in g class loading. A sp ec tJ s ta rte d w ith
source-level w eav ing in 2001. d elivered a per-class by te c o de w eav er in 2002, and
offered a d va nc e d loa d -tim e s u p p ort a fter th e in te g ratio n of A s p ectW erk z in 2005.
B u t in our a p p roa c h we use a n o th er way to weave. It is ru n - tim e weaving. W ith
ru n - tim e w eaving, th e dis tin ctio n betw een a p plic a tio n o bje c ts an d as p ec ts is clearly
1 0 C h a p t e r 2 . B a c k g r o u n d
2 . 2 . A s j ' C t O r i e n t e d P r o g r a m m i n g a n d A s p e c t J
11
establish*! d u rin g th e execu tio n . A ru n- tim e weaver is a pro g ram t h a t is able to
o rc h estra^ th e ex e c u tio n of th e se tw o ty p es of entities. In o th e r w ords, th e w eaver
e x ec ut e s ithei th e app lica tio n co d e or th e aspect code, d e p en din g on th e defined
w eav in g cireet ives.
T h e jrocess of w eav ing a s p ects at run tim e can be c o m p a re d to m a in tain in g
a relationship betw een a set of a p p lic a tio n o bjec ts a nd a set o f as p ec t instan c es.
A n a p p lia tion o b jec t th a t is bo un d to an aspect in stan ce is asp e c tizcd by this
asp e ct. Ai aspect in stan c e c an be b ou nd to several a p plic a tio n o b jec ts (the aspect
crosscutssev e ral lo c a tio n s of th e a p plica tio n) an d, conversely, an app lic a tion object
ca n b e bain d to several aspect insta n c e s (m ore th an o n e asp e c t applies to th e sam e
location)
T h e advantage of ru n-tim e w eaving is th at t h e re la tio n sh ip s b etw een ob je c ts
a n d aspects ca n be d y n am ica lly m an a g ed . By ad din g or rem ov ing a binding, we
ca n weav* o r u n w eav e a co n c e rn while the a p plic a tio n is ru n n ing . T his d y na m ic
q u ality is-particularly useful for a p p lication s, such as w eb servers, th a t m us t be
highly available an d th a t c a nn ot b e sto p p ed for long tim e fram es.
In moit cases, ru n -tim e w eav ers tra n sfo rm t he a p p lic a tio n’s co d e or its by te c o d e
before ru in ing it. T h e p urp o se of th is ad a p ta tio n is to m ak e th e classes read y
for run-time w eaving. All th e co d e ele m e n ts th a t c a n be a d a p te d at run tim e arc

modified o in tro d uc e hooks. A hook is a piece o f code t h a t re d ire c ts th e ex ecu tion
How of tic ap p lica tio n to w ard an asp e c t. Hoo ks are intro d u ce d at th e beg in n ings
of m ethods, for ex a m p le, or just before m e th od calls. T h e ty p es of location s where'
hooks car be in tro du c ed d e p en d on th e weaver. N ote th a t h ook s arc* not n ecessarily
location s w here a sp e cts ap ply b u t loc ations w h ere a s p ec ts po te ntia lly apply.
A m ong all th e hook s in tro du ced by a ru n -tim e w eaver, o n ly a selected su bset
will redirect th e ex e c u tion How to w a rd an asp e c t. T h e a s pe ct p ro gra m m e r d ecide s
which hooks effectively p e r fo rm this red irection.
2 .2 .1 .3 S o m e li m i ta t i o n s o f O O P
W h e n wre im p lem e nt the cro ss-c o n c ern in g by O O P , s y ste m h a s tw o m a in pro blem s:
code tang ling an d co d e sc a tterin g
• Coca tangling: C o d e tan g ling is cau se d w hen a m o d ule is im ple m e nte d tha t
handle's m u ltiple co n c ern s sim ultan eo u sly . A de v e lo p e r often co n sid ers con
cerns such as busine ss logic, perfo rm a n c e , s y n ch ro niz a tio n , logging, security,
12
C h a p t e r 2 . B a c k g r o u n d
a n d so fcth while im plem e n tin g a m odule. This leads to the s im u ltan e o us
p r e se n ce f elem ents from each co n cerns im p le m en ta tion an d res u lts in code
tan g lin g .M gu re below illustrates code tan g ling in a m odule.
Businei logic
Security
F igu re 2.4: An ex a m p le of code tan g ling
• Code scatering: C od e s c a tterin g is caused w hen a single issue is im p le m e n te d
in mu ltipe m odules. Since cro sscu ttin g concerns, by definition, are spre a d
over man; mo du les, related im p lem en tation s are also s c attere d over all th o se
m o du les. For exam ple, in a s y s te m using a da tabase , perfo rm an ce con c e rn s
m ay afiec all th e m od u les accessing the d a tab a se .
W e can cassify the cod e sc atterin g into two distin c t categories: d u plic ate d
co d e bloccs a n d com p le m e n tary cod e blocks. T he first k ind is ch ara c te riz e d
by repeated cod e of a nearly identical n ature. For exa m ple, reso u rc e poo ling

will ty p ia lly involve ad ding n early identical code to m u ltiple m od u les to fetch
a re s o u r a from a pool and re tu rn t he resource back to th e pool. F ig u re below
illu strates th e sc a tte red d u p licat ed code blocks.
C o d e ta ngliig and code s c a tterin g tog e th er im pact software design an d devel
opm en t in m an ways: p o or traceabilitv. lower pro d u ctivity, lower c o d e reuse, poo r
quality, and ha d e r ('volution. W hile we will discuss each im plication separately,
the y stron g ly ¿fleet one ano th e r. For ex am ple, p o or trace a b ilitv co ntrib ute s to
lower prod u c ti\ity an d po or quality :
Logging
4-
Persistence
• Pour truaubility: Sim ultan eo u s im plem en ta tion of several co n c ern s ob scures
th e m a p pn g of th e concern to its im p lem enta tion . T his cau se s difficulty in
2 . 2 . A s j e c t O r i e n t e d P r o g r a m m i n g a n d A s p e c t . )
1 3
Accounting
Internet
banking
“Check tor author 70(1
access'
— 1
y \ \
; \ \
Teller
Ả s- V
operations
X \
\ >
\
Figure 2.5: An ex am ple of co de sc atte rin g

tracing requirem ents to th e ir im p lem e n ta tion , a nd vice versa. For exam ple,
von w ould have to po te n tia lly ex a m in e all m odu le s to tr a c e th e im p le m en ta tion
of an au th e n tic a tio n concern.
• Lower productivity: S im ulta n e o u s im ple m en tatio n of m ultip le con c ern s also
shifts the focus from tin* m ain con cern to the p eriph e ra l con cerns. T h e lack of
focus then leads to lower p ro d uc tiv ity as d evelo p ers are side trac k ed from th e ir
prim ary o b jective in o rd er to h a n d le th e cro ssc u tting co ncern s. F urthe r, since
different concern im p le m e nta tio n s m a y need different skill sets, e ith er several
people will have to co llab ora te on th e im p l e m en tatio n of a m o d ule or th e
dev elope r im p lem en ting t he m od ule will need kno w ledg e of each do m a in . T h e
m ore concerns yo u im ple m e n t tog e th e r, th e lower y ou r p ro bab ility of focusing
on an y one thing.
• Lower codc reuse: If a m o du le is im plem e n tin g m u ltip le con cerns, o the r sys
tem s requ irin g sim ilar fu n ction a lity m ay no t b e a b le to read ily use th e m o dule
d u e to a different se t of concern s the y might n eed to im plem en t. Co n sider
C h a p t e r 2 . B a c k g r o u n d
a d a ta b l e access moduli*. O ne project m ay need one form of a u th en tic a 
tio n to ac es s th e da ta ba se , a no the r project m a y need a different form, a nd
still another m ay nee d no au th e ntic a tion at all. T h e varia tion of cro s sc u ttin g
requirem ents m ay ren d er an oth e rw ise useful m o d ule un u sab le.
• Poor (¡unity: ( ’o d e tan glin g m akes it m ore difficult to e x am in e c o d e an d spo t
p ot en tial p ro blem s , a n d pe rfo rm in g code reviews of su c h im ple m e nta t ions is
h ard er, hi e x a m p le , review ing th e co d e of a m od ule t h a t im p le m en ts m ultip le
c o nc e rn s will req u ire th e p a rt icipation of an e xp er t in e a ch of th e concerns.
O fte n no all of th e m a re available a t th e sa m e tim e, an d th e o n es w h o are
m a y n o t >ay sufficient a tte ntio n to th e co n c erns t h a t a re o uts id e the ir area of
ex pe rtise
• Difficult evolution: An in c o m p lete p e rsp ective an d lim ite d resou rce s often
result in \ desig n th a t ad dresses only cu rre n t concerns. W h e n fu tu re req u ire
m e nts a rse, the y often require rew orking the im p lem en tatio n. B e c ause im 

plem ent a ion is not m od u la rized , this m ay m e a n m od ify in g m an y m odules.
M odifying ea ch s u bs y ste m for such cha n g es can lead to incon sistencies. It also
requ ires sp end in g co nsid erab le te s tin g effort to en su re th a t this im p le m e nta 
tion change d o es not intr o d uc e regression bugs.
All of these p ro blem s lead to a search for b e t te r ap pr o ac h es to arc h ite c tu re,
design ai d im plem e n tatio n . A sp ect-o rie n te d p r o gr a m m in g offers o ne viable
solution.
2 .2 .1 .4 B e n e f its o f A O P
A O P prov ides se p ar a tio n of conce rn s in softw are by in tro d uc in g th e aspect th a t
crossc u ts other m o d u les. W i th A O P we im ple m e n t cro ssc u tting c o nce rn s in as
p e c ts in s te a d of fusing t h e m in the co re m odules. An aspect weaver, w hich is a
com piler-like entity, co m po s es the final sy s te m by co m b in in g th e core a nd cro ssc u t
ting m odu les thro u g h a proce ss called weaving. T h e re su lt is th a t A O P m o d u larize s
the cro ss c u ttin g c o n cern s in a clear-cut fashion, yielding a sy s t e m a rc h itec ture th a t
is e asier to design, im p le m e nt, and m a in tain.
A O P d e m an ds th e d e v elop e rs th in kin g ab ou t th e syste m desig n an d im plem e n 
ta tion in a new way. It has m a n y bene fits an d a m o ng the se are so m e m a in b en efits
(L ad da d . 2003):
2 . 2 . A s p e c ( r i e n t e d P r o g r a m m i n g a n d A s p e c t J
1 5
Cleaner "'esonsib Hit,/es of the individual module: A G P allows a m od u le to tak e
resp on sibilit/ cdv for its core co nccrn; a m od ule is no longer liable' for oth er cro ssc u t
ti n g c o nc e rn , or exa m ple. a m od u le accessing a d at a b a s e is no longer responsible
for p o olin g ianba.se connec tions as well. Th is resu lts in c leaner assig n m e nts of
respon sibilities.leading to improv e d trae ea bilit v.
Higher noadarization: A O P provides a m e c h an ism to add ress each conce rn
s e p a ra te l y w th m in im al cou pling. T h is results in m o du lariz ed im ple m en tatio n even
in th e preseicc of cro ss c u ttin g concerns. Such im p le m en tatio n resu lts in a system
w ith m uch bss d u p licate d code. Because th e im p lem e n tatio n of each conc ern is
s e pa rate , it dse helps avoid cod e c lu tte r. M o du la rized im p lem e nta tio n res u lts in an

ea sier-to -u nce n ta n d and e a s ie r-to -m aintain sy stem .
Easier systmi evolution: A O P m od ularizes th e ind iv id u al as p ec ts a nd m akes
core m o d u les oblivious to th e a sp ec ts. A dd in g a new fun ctio n ality is now a m a tte r
of inc lu d in g a new as p ec t a n d requ ires no chan g e to th e co re m odules. Fu rth e r,
w hen w e add a new core m o d ule to th e sy ste m , th e e x isting a s p ec ts c ro ss cu t it.
help ing to create a coh erent evo lution. T h e overall effec t is a faster resp o n s e to new
re q u irem en ts
Lute binding of design decisions: W it h A O P . the architec t can delay ma k in g
design decisions for fut ure req u irem en ts b eca u s e it is po ssib le to im plem en t tho se a,s
•separate flsp ffK A rchitects can now focus on the cu rre nt core re q u irem e n ts of the?
sy ste m . New requirem ents of a cro s sc uttin g n a tu r e c’an b e ha n dle d by cre a ting new
as pec ts. IrnfJernent ing a fe a tu re just bec a u se you m a y need it in th e fu tu re often
resu lts in w aited effort be cau se you w on t ac tu ally n e e d it. W ith A O P , if y ou do
need functionality later, you can im p lem e n t it w ith ou t sy s te m w ide modific ations.
More codc reuse: T h e key to g rea te r c o d e reuse is a m o re loosely coup led im
plem en ta tio n B ecause A O P im plem en ts each a s p ec t as a s ep a r a te m o d u le, each
m od u le is m ore loosely cou p led th an equ iv alent con v ention a l im plem e n tatio n s. In
partic u lar, core m od u les are n t aw a re of each o th ero n ly th e w eaving rule sp ecification
m od u le s are aware of any coupling. By sim ply ch a ng in g th e w ea ving specificatio n
instead of multiple core m odu les, you can ch a n g e th e sy stem configuration. For
exam ple, a da tab a se m o d ule c a n be used w ith a differen t logging im p le m en tatio n
w itho u t change to either o f th e m odules.
Improved f inn tn-inarkf t: L ate bin d in g of design decisions allow s a m uch faster
design cycle. C lean er se p ara tio n of resp o n sibilities allow s b e t te r m a tch in g of the'
m od ule to the developers skills, leading to im prov ed pro d u ctivity . M ore co d e reu se
1 6
C h a p t e r 2 . B a c k g r o u n d
lead s to rd u ce d deve lop m en t tim e. E asier evo lution allow s a q uicker resp o n s e to
new rc q uir m cn ts. All of th e se lead to system s th a t arc faster to develop an d deploy.
Raducd costs of feature implementation: By avoiding th e cost of m od ifying m an y

m o d u les t< im plem ent a c ro ss c u ttin g concern . A O P m ake s it ch e a p e r to implem ent
th e cro sscutting feature. By allow in g each im ple m e n ter to focus m o re on the conc ern
of th e m olule and m ake th e m o st of his or her exp e rtise, th e cost of th e core
re q u irem e its im p le m e n tation is also red u ce d. T he en d effect is a ch e a p er overall
feat ure irn)lernent at ion.
2.2.2 A sp ectJ
A O P h a s H'en widely a p p lied to different lan guag e s b u t t h e m ost influential im-
p le m c n ta tb n is Aspect.] (Kiczalcs ct al., 2001). A spect J is a sim ple an d practica l
asp ec t-oriented extension to Ja va (E< lipse.org, 2009). It is a se am less a s p ect-o rien te d
ex te n sion )f th e Ja v a p rog r a m m in g lan g u a g e th a t e n ab les cle a n m o d ula riza tion of
the se crosscutting con cerns. A n A sp ec tJ com piler p rod uce s class files tha t con form
to th e Java bytc-cod e specification, allow ing a n y co m plian t Jav a virtua l m a ch in e
(J V M ) to e x e cu te those class files. By using Jav a as th e ba s e lan g u ag e , A sp ec tJ
passes on all the benefits of J a va an d m akes it easy for J a va p ro g ram m ers to u nd er
sta nd th e A spec tJ lan guage. T h e ta sk of in te g ratin g th e cro ssc uttin g con c ern code
an d th e prim ary a p plica tion to ru n as a co m p le te sy stem is ca lled weaving.
A spect J is designed a-s a co m p a t ible exten sio n to Ja v a so th at it will fac ilitate
ad o ptio n by cu rren t Ja v a pr o g ram m e r s. T h e c o m pa tib le m ea n s four things:
• U pw ard com patib ility - all legal Ja v a p ro g ram s m ust b e legal A sp ec tJ pro 
grams.
• Platfo rm co m p atibility - all legal A spect J p ro g ram s m ust ru n on st a n d ar d Jav a
virtual m achines.
• Tool c o m p a tib ility - it m ust b e possible to ex ten d ex isting too ls to su p p o r t
A sp ectJ in a n at u ra l way: this inc lud es ID Es, d oc u m e nta tio n tools a n d design
t ools.
• Pro g ra m m er c om p atib ility - p ro g ram m in g w ith A sp ec tJ m ust feel like a n a t 
ural ex ten sio n of p ro gr a m m in g w ith Jav a
11
p. f
2 . 2 . A s p e < O r i e n t e d P r o g r a m m i n g a n d A s p e c t J

1 7
Dynamic lo g e n t ting in Aspect,] is based on a sm all pow erful set of c o ns truc ts.
•J oin-points ire w ell-defined po in ts in th e ex e cution of th e p rog ra m ; point cuts are
a. m e an s o f eferring to collections of jo in po in ts a n d ce rtain values at th o se join
p o ints: advie are m etho d -lik e c on stru c ts used to define ad ditio na l be h av io r a t join
p oi n ts a n d spects are u nits of m o d ula r cro s sc uttin g im p lem en tatio n, co m p o sed of
p oin tcu ts, alvice a n d o rdin a ry Ja v a m e m be r dec lara tio n s.
A spe c t-o rie rtation is not lim ited to p ro gra m m in g since it is useful to identify, a n a l 
yse, tra ce aid m o d ularise co n c erns (e.g., P R E v ie w ) t h ro u g h req u irem e n ts elicitatio n ,
specification an d design. A spects can be mult i-dim cnsion a l by allowing b o th fu n c 
tiona l a n d inn -func tiona l beh a v io u r to cross cut an y o th er con cerns, instead of just
m a p pin g non-functional con cern s to funct ional re q u irem en ts .
O ne viev- of A O P is that every m a jor fea tu re of th e p ro g ram , co re conce rn
(bu sines s logic), or cro ss-c u ttin g con cern (ad ditio na l fea tures ), is a n as p e c t, a n d by
w eaving them tog e th er (also called com po sition ), you finally pro du ce a w ho le o u t of
th e se p ara te asp ec ts. T his ap p roa ch is kno w n as p u re a s p ec t p ro g ram m in g, but h y 
brid a p proa ch es are m ore co m m o nly u sed, p e r h ap s since th ere is less of a p a ra d ig m
shift between object- a n d as p ect-o rie n ted p r o g ram m ing . T h er e is a sim ilar si tu a 
tion with early as p e ct software dev elop m e nt (e.g re qu ire m e n ts), with tr a di tio na l
m e th od s being en h ance d for as p ec t-o rien ta tion an d n ew m od e ls p ro po se d . N o n
functional co nc erns (e.g., security) can crosscut fun c tio n a l concerns (e.g., do o r m ust
be present ). It is possible for fu n ctional concerns to c ro ssc u t n o n-fu n ction a l or func
tional concerns (e.g., need for m ore feature s h arm s m o b ility). A u n ifo rm a p pro ac h
to re p re sen tation a n d com po sition, sim ilar to th e p u re a pp ro a ch in A O P , is term e d
m ultidim ensional rep resen tatio n .
N ote th at A O P does not replace O O P ab solu te ly (E lra d et al., 200 1). T he
goal for A O P is built on O O P. by su p p ortin g s e p a r a tio n of tho se co ncern s th a t
O O P handle's poorly. W hen pro gra m m ing in A O P we use procedure's, o b je cts a n d
asp ec ts, each when most ap p ro p riate . A O P will no t b e th e last w ord on th e pro b le m
of se p aratio n of co n cerns either.

2.2.3 R em ark s
DA I HOC OUÔC GIA HÀ NÔI
TRUNG TÂM ÎHÔNG Tin THU VIÊN
1 8 C h a p t e r 2 . B a c k g r o u n d
2.3 S u m m a r y
In th is ch a pte r we pre se n ted som e basic c o ncep ts for h elp ing US to resolve the p r o b 
lem. U M L 2.0 w ith ad d ition typ e s of dia g ram inc lud es a set of gra p hica l no ta tion
tec h niq ue s to create visual m odels of softw are sy s tem s. T h e g rap hic a l n ota tio n is
easy to u nd er s ta nd an d favourab le w ith users. It can m o d e l th e c o n s tra ints of so ft
w are s y ste m well: from ty p e , to tim in g c o n stra in t. ( M L 2.0 is go od for m od elling
tim in g co n strain t .
A s p ec t O rien ted P r o gra m m in g is a p ro g ram m in g p ara d ig m th a t increases m o d u 
larity by e n a b ling improved se p ara tio n of concerns. It resolve th e cod e ta n glin g an d
co de sc att e rin g p ro b lem s w hich O O P ca n no t resolve. A seam less asp e c t-orie n te d
e x ten s io n to th e J a v a p r o gra m m in g lan g u age is A sp e c tJ. It will be ap plied for ou r
a p p r o ac h in th e next ch a p ter.
C h a p t e r 3
C h e c k i n g t h e c o n f o r m a n c e o f
t i m i n g c o n s t r a i n t s
In th is chap ter, we pre s e n t an a pp roa c h for check ing the co n fo rm ance of tim e betw een
th e sp e cification a n d th e im p le m en tatio n of a softw are system . Firs tly th e d e ta il of
maim co n tribu tio ns of this th e sis is presented: ap pro ach to check th e ex e c u tio n of
ta s k s in a J av a ap p lica tio n w ith their tim in g c o n s tra in ts. A fter t h a t we illu stra te
ou r ap p ro a ch by tw o case studies.
3.1 G e n e r a tin g v e rific a tio n a s p e c ts to c h e c k th e
c o n f o rm a n c e
T h e in p ut of che cking process is tim in g specification a n d a p rog ram , th e im p lem en 
ta tio n of softw a re sy stem . In specification som e tasks hav e the ir tim in g constra in ts .
W e \want to check th e con form a n c e betw een specification and im p le m en tatio n au to 
m a tica lly . In ord e r to weave as p ec t into th e code of p ro g ra m , we n e ed a te m p la te for

a s pe c t to realize th is work. A te m p late w ritten in A sp ec tJ is defined. It is able to
ac h iev e tim in g co n stra int from U M L T im in g D iag ram a n d ex e cutio n tim e of ru nn in g
taskns. W he n w eaving A sp ect J c o d e into p ro gra m , it can check tim in g con form a n c e
betw /een specification a n d im p le m en tatio n .
T h e m ain step s fur g en er a tin g asp e ct are sum m a riz e d as follow’s.
• T im in g co ns tra in ts a re exp re sse d by U M L T im in g D ia g ram s e xp o rte d to X M L
form at.
19
2 0
C h a p t e r 3 . C h e c k i n g t h e c o n f o r m a n c e o f t i m i n g c o n s t r a i n t s
G etiin g a list of m e th o d s nam e a n d co rre s p o nd in g tim in g co n stra ints from
XM L files to p ro duce as p ects in Aspect.!.
Defi ling th e advices in th ese as p ects th a t is able to ge t tim in g e x e c u tio n of
m eth od s in th e ru nn ing a p p lic ation .
Seq Timing diagramj
Objectl
Task1(.)
Task3( )
Object2
{r1,r2}s
Task2(.)
(b1.b2)s
_ Æl.rgjK
Task4( )
-4*1**218
__
0 1 2 3 4 n
F igure 3.1: U M L S eq u en ce T im in g D iagra m .
In o rd er to g e n e rate verification as p e c t from UM L T im ing D iag ra m p rese nted in
F igu re 3.1, we build a te m p la te . In this te m p la te, first, we d e c lare several p rivate

v ariables used to c a lcu late th e tim ing exe cu tion w hen a m eth od is exe c u ted. W e
also define two advices of th e as p ect. T h e first one. ad v ic e before().execution, add
a c om m a n d to get the tim e before e x e cutin g th e m eth od (in m illiseconds). T h e
se co nd adv ice, aftcr().execution, g et th e tim e after exe cu tin g the m eth od . T h e
tim in g exe cu tion of the m e tho d is m ea su re by th e su btra c tion result of these tw o
m o m en ts. T h e tem p late is show n in F ig u re 3.2.
This a sp e c t state's th a t w hen a m e th od is invoked, we can ru n ad ditio na l picces
of cod e befo re or after ex e c u tin g a m e th o d. S up po se th a t t(a) is th e exe c u tio n tim e
of th e ta sk a. If a , (i two seq uen tia l ex e cution tas k s th en t(a\(i) = t(a) -f ¿(/3).
a n d t is th e u pp e r b o u n d on tim in g of th e se que nce task s. W e form alize th e tim ing
c on str a in ts of th e scen a rio th a t c a n be checked as follows:
• T im in g co ns tra ints of ea ch task, r 1 < t(cv) < r2 . W h ere r l , r2 be th e lower
a n d u pp e r bo un d o n tim in g of th e ta sk a .
• T im in g c on s tra in ts of som e seq u entia l tas k s ex e c u ted , t(a) -f /(/i) < t.
• W e also Check th e early a c co m p lishm en t of parallel tasks: t(a) < t{(3). In
w h ic h a , 0 are1 two parallel ta sks bein g sta rte d a t th e sa m e tim e.
Com peosing an d tra n sla ting th e abo ve tim in g c on stra in ts to th e logical ex p re s
sions, a nd add the m as th e c o n dition s to the template* in Fig ure 3.2 to check if tim ing
ex ec u tion of m e th od s satisfv th eir co nstra in ts.
3 . 2 . A c l i e v i n g t i m e f r o m s p e c i f i c a t i o n a n d i m p l e m e n t a t i o n
21
im p o rt o rg.asp ectj.lan g.Jo inP o in t;
variables
Variables arc declared here;
aspect AspeetName {
before () : (exec u t ion (* *.*( ))) !w ith in ( Aspect Name)
{
- Get 11;/ / the current system time :
}
a fte r() : (e xe cu tion (* *.*( )))&& !w ith in ( AspeetName) {

- Get ¿2 ;/ / the current system time:
- Get method name from XM L tile(taskl, task2, );
- Get lower and upper bound on timing from X ML file (rj, r2 );
- t — t2 - t\;//C alculate the execution time of the method;
if ( i (¿1 H , 7*2 , ) false)// Timing constraint conditions;
- Produce violation reports;
}
F ig ure 3.2: T e m p late for th e V erificatio n A spec ts.
3.2 A c h ie v in g t i m e fro m sp e c ific a tio n a n d im p le 
m e n t a t i o n
3.2.1 T h e o rd e r of e v e nts
3 .2 .1 .1 O r d e r o f e v e n ts in a a p p l ic a ti o n
F irstly we look into a co n c ep t co n cern in g th e tim e of ev e n t (or task ) in a system .
O ne of features of process in a system is de term in ing th e e x ec u tio n ord e r of ev en ts or
processes. We use th e tim es t a m p s assign ed to each even t: (i) th e t im e of beg in ning
of event exe cu tion; (ii) th e tim e of end in g of th e ex e cu tion.
T h e even ts E t are tim in g ch ara c te rize d by (t \ , tl2)- It m e a n s th e p ro cess corre
sp o n d in g to Ei is e x ecu ted in th e interval (t.\, U ), in w h ich t\ <V2. W i th the tim in g
definition for th e events, we ca n d isting u ish ev en ts by the e xe c u tio n order.
• E 1 is s e pa rate d from E 2 iff tj >t\ or t\ >t\;
• Ei is covered by E 2 iff tj, t^ E ( tf , tj);
• E| is ov erlap p ed to E 2 ill (tj € (tf. t|) an d t.^ ^ (tj\ t^)) o r (tj G (t/f. tj) and