\RevA{ - Using the appendix, please give conceptual definitions of the characteristics of the problems/issues that you have observed, and use these in the main document. } In order to evaluate our design criteria, we present a challenge problem. We illustrate how the criteria are necessary properties for an elegant solution. On a formal level, we are evaluating \emph{our solutions} in the pertinent languages, rather than the languages themselves, but we have attempted to solve the problem as idiomatically as possible, and maintain that the solutions are indicative of the languages they are written in. \begin{figure*}[tb] \begin{lstlisting}[caption={Base Program in Java},mathescape=true,frame=,label=Listing:container]{} \end{lstlisting} \begin{tabular}{l|r} \hline \begin{minipage}[t]{.43\linewidth} \lstinputlisting[frame=]{examples/base/Item.java} \end{minipage} & \begin{minipage}[t]{.50\linewidth} \lstinputlisting[first=3,frame=,firstlabel=\thelstlabel]{examples/base/Main.java} \end{minipage} \\ \hline \end{tabular} \end{figure*} The problem put forth is to verify that no \type{Container} is over its capacity limit. A \type{Container} may contain a number of \type{Items}. An \type{Item} is either a \type{Simple} leaf or a \type{Container}. Each \type{Simple} item has a weight, while a \type{Container} has a capacity, which describes the maximum total weight it can contain in its nested subcontainers. The challenge is to introduce caching code so that we only perform minimal necessary recomputation to check the constraints. We focus on three main concerns that seem both intrinsic to the problem, and worthy of reuse on their own. At first glance, it may seem that the differences in interfaces between the concern solutions---and thus the need to be careful when integrating them---are somewhat contrived. The justification is the observation that we are also modeling the reuse of COTS software: in such scenarios, the interfaces are going to be what the designer of the software thought best. %******************************************************************************************** \ssssect{Capacity concern.} The fundamental---or base---concern is the checking whether any container's capacity has been exceeded. This concern can be easily implemented in plain Java using a recursive algorithm and the \textsc{Composite} design pattern~\Cite{Gamma:Helm:Johnson:Vlissides:93}. \Ref{Fig}{cachebase} illustrates the base collaboration's class graph as a UML diagram. The complete code is shown in \Ref{Listing}{container}, and is common for all three solutions ({\aj}, {\hj}, and {\ACs}). \begin{figure}[hbt] %%% \RevC{ %%% On page 13, figure 2, there are several problems: %%% - the code in Listing 10 says that the return value of Item::check and Container::check is of type integer. However, figure 2 has the return type for both of these methods as boolean. Please fix this discrepancy. %%% - there is no check method for class Simple in figure 2, although it does exist in Listing 10 %%% } \scalefigfrom{0.3}{cache}% \caption{A UML representation of \collab{base}.}% \label{Fig:cachebase}% \end{figure} %The core of the application is written in pure Java, and is common for the solutions. %both check the capacity (print out a complaint if exceed the capacity) and also The common superclass \type{Item} declares an abstract method \java{weight} which is implemented in the concrete subclasses \type{Simple} and \type{Container} to return the total weight of the container and its contained \type{Item}s. The concrete subclasses differ in that \type{Container} has a (possibly empty) \type{Vector} of contained \type{Item}s and a maximum capacity, while \type{Simple} has a weight but cannot contain any other \type{Item}s. \type{Container} calculates its weight by recursing into each of its contained \type{Item}s, and summing their weights. %******************************************************************************************** %%% %%% DL Nov 20: s/Efficiency/Caching/ %%% \ssssect{Caching concern} The weight is hence computed from the subcontainers every time an item is added or deleted. An optimization that comes to mind is to cache the weight of each container. Whenever an item is added to a container, the weights of its sub- and sister containers remain valid, but the cached weight of itself and its supercontainers must be invalidated. %%% %%% DL Nov 20: Added "for efficiency" %%% As a general solution, this concern for efficiency can be described in terms of the class \type{Cached}, containing the method that should be cached, as sketched in \Ref{Fig}{cachesketch}. The concern places a number of requirements on the context of its instantiation, which is illustrated at a high level in the figure. An implementation of the concern needs to be provided with the ability to intercept calls to the method to be cached and to intercept calls to methods that invalidate the cached method's result. (Method interception is illustrated by the half-head arrows.) Also, it needs to call an external method, which returns all objects that have cached methods that depend on this object's cached return value (suggested by italics in the name \java{\itshape allInvalidated}). %%% %%% DL: What does italics suggest? %%% JO Nov 17: that the member is abstract in UML -- for us it is expected %%% Given these imports, the concern provides the functionality of managing the method's cached result: intercepting the result on first invocation, intercepting subsequent calls to return the cached result (dotted arrow) instead of invoking the cached method, and invalidating the cache when forced to do so by dependence on other cached values or direct invalidation -- likewise it will also inform dependent caches when it has become invalidated (normal name and arrow for \java{clearCache}). %%% %%% KL: what do the different kinds of arrows mean in the two concern figures. Why so many kinds? %%% KL: we should explain all kinds. %%% DL: Perhaps a legend? %%% JO Nov 17: There is a terse description in the text %%% \begin{figure}[htb] \scalefigfrom{0.3}{cachesketch} \caption{A schematic sketch of the Caching concern.} \label{Fig:cachesketch} \end{figure} %******************************************************************************************** \ssssect{Backlink concern.} In order to invalidate the proper containers, we need to identify all the supercontainers of an item: i.e., all the \type{Container} objects that the \type{Item} object is inside of. This would be possible if we tracked which \type{Container} an \type{Item} is added to. %%% %%% JO Nov 15, s/objects -- and /objects, and/ %%% \Ref{Fig}{backsketch} illustrates the concern: given a \type{Source} object, containing a number of \type{Target} objects, and a method to retrieve them~(\java{\itshape getTargets}), the concern should augment the \type{Target} class with a \type{Source} field whose value can be retrieved by external behaviors~(\java{getSource}). For any modification to the vector of \type{Target}s (\java{associate} half-head arrow), we need to determine whether the affected \type{Target} object was added to or removed from the vector, and set the \type{back} field to the \type{Source}, if added, or \java{null}, if removed. \begin{figure}[htb] \scalefigfrom{0.3}{backsketch} \caption{A schematic sketch of the Backlink concern.} \label{Fig:backsketch} \end{figure} %******************************************************************************************** Next, we illustrate the implementation of these concerns as aspects in {\aj} (\Ref{Section}{aj}) and as hypermodules in {\hj} (\Ref{Section}{hj}), %%% %%% DL: Added "and then we evaluate their performance" %%% and then we evaluate their performance (\Ref{Section}{reqprops}). The {\ac} solution is deferred to \Ref{Section}{ac}.