% intro % motivation (as per my talk): % goal: (write/maintain large and complex software) % So want both. We want the following properties: % External Composition % Encapsulation % Flexible Reuse % Separate analysis & compilation % Somehow control scattering / tangling % f.ex oblivious methods with flexible joinpoints % Thesis: % combining the two isn't really a problem. Just cater to scattering and % tangling control as concerns subjugated to modularity. % i.e.,: there _is_ a dominant concern of decomposition. % Roadmap: % (as per this outline) A fundamental goal of software engineering is to enable the construction of large and complex software in a timely fashion. Several approaches to this goal are under investigation by researchers. Examples are programming methodologies, modeling tools, and advanced development tools. This paper investigates a fourth approach: novel programming constructs. Specifically, we investigate the intersection of {\MP} and {\AOP}. We show in the context of an illustrative example how aspectual mechanisms work in {\aj} and {\hj} and we show how combining modules with aspects provides better aspect-oriented modularity. We offer a concrete language design, {\AC}, both to demonstrate the feasibility and to investigate the details of such a combination. \Ssect{Modular Programming}{intromod} % tool: modularity % introduce vocabulary briefly: encapsulation, composition, explicit, structural concern % controls interfaces of language units % teams can work in parallel; prog. language controls their interaction % reuse is helped by language features % external assembly promotes hierarchical design, flexibility % mostly compositional understanding (understand submodules in isolation), % use hierarchy to determine which need to be understood. Compose % understanding to understand whole program {\MP} allows large projects to be constructed in a timely fashion by providing constructs that split the program into smaller units: modules. These modules are assembled to create the final deliverable. Modules promote safety at the expense of ad-hoc flexibility. The power of modularity springs from three fundamental abilities: \begin{smallenum}[% \noindent] \litem{Decomposability.} A key benefit from modularizing program development is to ease the burden of understanding the program by allowing pieces to be understood in isolation. This property additionally isolates development teams from each other, allowing development to proceed in parallel without danger of teams interfering with each other. \litem{Composability.} While small applications can be written monolithically, larger applications need to be assembled from individual modules in order to be manageable. It is natural to want to apply modular reasoning recursively to larger modules: constructing them not monolithically, but from smaller constituent modules. This allows the programmer to balance flexibility, which is maximal in a flat architecture, against comprehensibility, which is easiest in a deeply nested hierarchical architecture. \litem{Adaptability.} Developing and understanding a module costs considerable resources, so it is important to be able to amortize that expenditure over several uses of the module. A module system that allows modules to be reused in a wide variety of situations---including when names and assumptions between importee and importer may not match precisely---is important to realize a win from module systems. \end{smallenum} \johan{explicit behavior: foreseen extension. This defn excludes classes} \Ssect{Aspect-Oriented Programming}{introaop} \johan{I don't think we emphasize the risks of tight coupling in AOP enough.} % tool: AOP % vocab: crosscutting, scattering, tangling, implicit, behavioral concern % captures complex interactions by providing much more powerful grouping operations % for modules. Scattering and Tangling are no longer a problem % bad: these features seem to be anti- encapsulation: need to look inside previous def % of modules to be able to talk about interaction points {\AOP} improves comprehension and maintainability of complex programs by localizing behaviors that would otherwise be scattered and tangled. These behaviors are referred to as \emph{concerns} (as per Parnas \Cite{Parnas:1972:OCU}). Crosscutting at the concern level leads to scattering and tangling at the implementation level. Kiczales et. al.~\Cite{Kic:2001:WellModConc} define an \emph{aspect} as ``a well modularized implementation of a crosscutting concern.'' Aspects promote ad-hoc flexibility at the expense of safety. The power of aspect-oriented software development lies in managing crosscutting concerns by controlling scattering and tangling: %%% %%% DL: Footnote removed. Seems out of place and doesn't add much. %%% %%% JO Nov 17: I disagree. but not strongly enough to add it back in. %%% %%% ~\footnote{However, not all Aspect-Oriented languages have module %%% systems that fulfill our requirements, so some care must be taken when %%% using such definitions.} \begin{smallenum}[% \noindent] \litem{Crosscutting.} Crosscutting concerns are issues that the programmer cares about, but cannot localize to one instance of a programming construct. For example, a trivial synchronization concern is not crosscutting if it merely talks about one section of the program text, but a more advanced synchronization concern that specifies that some set of methods can simultaneously execute in a critical section as long as some condition holds, will typically be crosscutting. Such a concern will be crosscutting as the ad-hoc implementation of the policy will likely be spread out over each of the affected methods. \litem{Scattering.} Scattering is the condition where a concern is implemented in several non-contiguous places in the program. Aspects control scattering by specifying places in the program's execution (\emph{joinpoints}) where certain code, called (\emph{advice}), is to be executed. \johan{careful, cannot imply that this is separate from rest of program.} \litem{Tangling.} Tangling, the dual of scattering, occurs when several concerns overlap at a region in the program text. This hampers maintainability, as the programmer must mentally categorize statements in the program text by which concern they belong to. Aspects reduce tangling by localizing concerns. \end{smallenum} \Ssect{Combine Modules and Aspects}{introthesis} {\MP} and {\AOP} are different approaches to a common goal of constructing large, complex software quickly. Unfortunately, neither is solely sufficient. On one hand, module systems alone fall prey to (significant) scattering and tangling. The ability to distribute pre-compiled software requires foreseeing how a module will be used and extended. For example, in a GUI (Graphical User Interface) application, one may need to provide enough hooks for the subject-observer design pattern~\Cite{Gamma:Helm:Johnson:Vlissides:93} to allow all interesting events to be captured. Thus, to avoid crosscutting, one would need the prescient ability to predict all future uses of a pre-compiled module. On the other hand, {\AOP} alone, in its current form, lacks lingual support for reuse and composition. Teams can no longer efficiently work in parallel relying only on common module interfaces.~\footnote{% %%% %%% KL: of course they can. One team per use case. %%% DL: I added a footnote. %%% JO Nov 17: Independently implies no interaction. Are use cases guaranteed not to interact? %%% DL: That's precisely the point made. %%% JO: No the point made that IF they don't interact THEN ... %%% The point of modules is to GUARANTEE this property %%% .... or I may still be completely wrong about use cases %%% (What a strange place for a discussion this is) %%% Teams can work independently, one team per use case. However, interactions would require some form of aspectual interfaces. } However, the biggest lost benefit is the ability to understand programs in a modular manner. If advice can be added to a joinpoint by any aspect, we must discover and understand \emph{all} aspects globally in order to comprehend a method's local behavior. We thus need omniscient reasoning to understand the program's local behavior. The obvious remedy is to combine the two. The complex nature of the interactions between concerns makes it seemingly cumbersome to apply language constructs to control how aspects interact. Notably, protection and the mechanisms to capture scattering appear to be in direct contradiction: the former places strong emphasis on differentiating the interior of a module from the exterior, while the latter wants to allow external effects to the internals of a concern. We show that this conclusion is a fallacy, and that the abilities of modules and aspects are synergistic. We argue that this is the right thing to do, and that such a combination can be both simple and powerful. A system combining the two will provide a significant step towards reaching our goal of being able to conveniently write and reason about large and complex programs. We illustrate our argument by presenting a concrete system, called {\AC}, combining modular and aspect-oriented features. We evaluate our design choices by comparing its performance on a challenge problem to the performances of two existing systems, {\aj} and {\hj}, on the same problem. \subsection{Outline}\label{Section:introout} The paper is split into three major parts. The first part identifies the need to combine {\MP} and {\AOP}, while deriving in \Ref{Section}{properties} a list of desired properties. To evaluate these claims, a challenge problem is presented in \Ref{Section}{challenge}, and two solutions are investigated. The first part of the paper concludes, by comparing the solutions against our identified properties, that neither solution is able to compensate for the features it lacks but are found in the other. The second part of paper presents a concrete system combining all the properties identified in the first part. \Ref{Section}{syntax} presents {\ACs}, as motivated by those properties. \Ref{Section}{ac} evaluates the performance of {\ACs} using the challenge problem, presents implementation sketches to illustrate the conceptual model of the implementation, and suggests future research directions. In the third part of the paper, \Ref{Section}{lesson} compares {\ACs} against related work, and \Ref{Section}{conc} concludes.