Glossary

(Difference between revisions)

Revision as of 16:56, 15 May 2005

Put a one or two sentence description on this page. For more detailed explanations, add a link.

Advice

In a number of AOP languages, advice consists of a pointcut and a body. The body executes at join points the pointcut matches. This pointcut may expose runtime information to the advice body.

AOSD

Aspect

Aspects are one kind of concern in software development. With respect to a primary or dominant decomposition aspects are concerns that crosscut that decomposition.

Aspect and Concern Mining

Aspect-Oriented Middleware

Composition

Concern

A concern is an area of interest or focus in a system. Concerns are the primary criteria for decomposing software into smaller, more manageable and comprehensible parts that have meaning to a software engineer. Examples of concerns include requirements, use cases, features, data structures, quality-of-service issues, variants, intellectual property boundaries, collaborations, patterns and contracts. There are many formulations used to capture concerns as well-identified separate units, aspects are one such mechanism, that are tuned to capturing crosscutting concerns. See More.

Concern and Feature Interaction

Concern Graph/Model

A Concern Graph is a representation of source code that abstracts the implementation details of a concern and makes explicit the relationships between different parts of the concern. The abstraction used in a Concern Graph allows an obvious and inexpensive mapping back to the corresponding source code. For more information, see the Concern Graph Project and the FEAT plugin for Eclipse.

Crosscutting

A structural relationship between representations of a concern. In this way it is similar to other kinds of structure, like hierarchical structure and block structure. Crosscutting is a different concept from scattering and tangling. See More.

Dominant Decomposition

Traditional languages and modularization mechanisms suffer from a limitation called the Tyranny of the Dominant Decomposition: the program can be modularized in only one way at a time, and the many kinds of concerns that do not align with that modularization end up scattered across many modules and tangled with one another.

This description is paraphrased from IBM's T. J. Watson Research center's research on Morphogenic Software. See also, Multi-Dimensional Separation of Concerns.

Dynamic Weaving

Early Aspects

The notion of Early Aspects means it is important to consider aspects early on in the software engineering lifecycle during analysis and design, as opposed to only at the implementation and testing stages.

Encapsulation

Feature

Join Point

In a number of AOP languages, a join point is a region in the dynamic control flow of an application. Thus a join point can for instance represent

• a call to a method,
• execution of a method,
• the event of setting a field,
• the event of handling an exception ...

Join points can be picked up by an AOP program by using pointcuts to match on them. Depending on the pointcut language the AOP language provides, it may be possible to pick up more or less of those join points. Since join points are dynamic, it may be possible to expose runtime information such as the caller or callee of a method from a join point to a matching pointcut.

Many AOP languages implement aspect behavior by weaving hooks into the join point shadows, which is the static projection of a join point onto the program code.

Join Point Shadow

A join point shadow is the static projection of a dynamic join point onto the program code. Thus it is the code region where a specific join point may occur during runtime when the control flow happens to pass through this region. If a join point really occurs at its shadow may be dependent on runtime evaluation. For instance a join point that would match any event of setting a field f to a value of null would yield a static join point shadow of all places where f is set. At this shadow, the implementation of the AOP language would insert a dynamic check to assure that a join point is only created if the passed value is indeed null.

Module

Modularity

Modularity is another term for talking about separation of concerns. The term modularity is used when talking about formal artifacts, such as code, and refers to achieving a high degree of clarity in the separattion between the individual units (modules). The code that implements a concern is modular if:

• • it is textually local,
  • there is a well-defined interface that describes how it interacts with the rest of the system,
  • the interface is an abstraction of the implementation, in that it is possible to make material changes to the implementation without violating the interface,
  • an automatic mechanism enforces that every module satisfies its own interface and respects the interface of all other modules, and
  • the module can be automatically composed – by a compiler, loader, linker etc. – in various configurations with other modules to produce a complete system.

Pointcut

In a number of AOP languages, a pointcut is a predicate over dynamic join points, meaning that given a certain dynamic join point, a pointcut can either match this join point or not (at runtime). Another view of pointcuts is often, that they represent sets of join points. A pointcut may expose runtime information to a piece of advice.

Product line

Quality-of-Service Aspects

Scattering

The representation of a concern is scattered over an artifact if it is spread out rather than localized. The representation of concerns are scattered within an artifact if they are intermixed rather than separated. Scattering and tangling often go together, even though they are different concepts. See More.

Separation of Concerns

In his opening keynote at the first AOSD Conference, Michael Jackson pointed out that Djikstra is the man credited with reminding us of the Roman principle of divide and conquer. Put another way, separation of concerns (SOC) is a long standing idea that simply means a large problem is easier to manage if it can be broken down into pieces; particularly so if the solutions to the sub-problems can be combined to form a solution to the large problem.

SOC can be supported in many ways: by process, by notation, by organization, by language mechanism and others. Within the broad theme of SOC, AOSD is distinguished by providing new insight on the separation of crosscutting concerns, in particular the idea that single hierarchical structures are too limiting to effectively separate all concerns in complex systems.

Static Weaving

Tangling

See Scattering.

Weaving

The process of coordinating aspects and non-aspects. In a language like AspectJ, one part of weaving is ensuring that advice executes at the appropriate dynamic join points. Weaving can be done explicitly or implicitly, and can be done at a variety of times ranging from by-hand weaving when code is written, through compile-time, post-compile time and load time, up to runtime.

A detailed description of how to edit can be found on the Help:Editing page.