Information Technology Reference
In-Depth Information
cases, Jacobson and Ng define a joinpoint as a step in a flow of the use case. In
UCM terms, this translates directly into responsibilities (behavioral dimension)
optionally bound to components (structural dimension). Responsibilities are just
one kind of path node. Therefore, any path node could be a joinpoint (i.e., a
location on the path). Defining any path node as a joinpoint gives the most
flexibility to the requirements engineer without significantly increasing the com-
plexity of AoUCM or requiring additional modeling constructs. Figure 7 shows
UCM path nodes such as start points, dynamic and static stubs, responsibilities,
OR-forks and OR-joins, AND-forks and AND-joins, waiting places, timers, and
end points. Each of these path nodes is a joinpoint. The small diamonds in Fig. 7
do not indicate joinpoints but insertion points. An aspect can insert behavior
at an insertion point, i.e., either before or after joinpoints. An insertion point
is associated with exactly one joinpoint. Some joinpoints such as start and end
points can only have two insertion points, one before and one after the joinpoint.
Other joinpoints such as stubs, forks, and joins can have more than two insertion
points. The component in Fig. 7 indicates that the joinpoint model does not con-
cern itself only with behavioral specification but optionally also with structural
specifications.
C
dyS
w
r
[c1]
[c2]
s
e1
stS
t
e2
Fig. 7. Joinpoints and insertion points in UCMs
The small light-shaded diamonds indicate that more than one insertion point
exist before or after the path node (i.e., joinpoint). Note that even though the
figure only shows at the most three insertion points for one joinpoint, any join-
point with three insertion points may also have more than three insertion points.
The joinpoint model, however, does not need to concern itself with the number
of insertion points. The joinpoint model simply identifies all path nodes as join-
points. We will see in Sect. 3.4 how it is possible to reference each of these
insertion points individually.
3.2
Advice Map
An advice describes the behavior of an aspect triggered in a certain situation.
Intertype declarations identify the structural entities that either provide the ad-
vice or contribute to the advice. Describing behavior in UCMs is straightforward
as UCMs are meant to do exactly that: describe behavior with paths on top of a
structure of components. The semantic meaning of components in UCMs is cast
very wide — anything that can provide a service is a component from classes to
Search WWH ::




Custom Search