[Main Page]

Glossary

From AOSD Wiki

Main Page | Recent changes | View source | Page history | Log in / create account |

Printable version | Disclaimers | Privacy policy

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

Table of contents

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 Oriented Software Development

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

   the process of combining elements to make a whole.

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 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

Performing the weaving process at load time. This means that the virtual machine or interpreter must be aware of aspects and control the weaving process.

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

The process of enclosing elements inside a larger entity. Its primary goal is to group related elements (elements part of the same Concern) together. A procedure is an encapsulated set of program instructions. An object-oriented class declaration encapsulates data and operations on that data. An aspect encapsulates a concern that crosscuts a particular decomposition of the program structure. See more...

Feature

A feature is a particular kind of concern. Features often crosscut the primary decomposition of a system, which is why they are particularly relevant in AOSD.

Feature Interaction

Join Point

Join points are those elements of the programming language semantics which the aspects coordinate with. Nowadays, there are various join point models around and still new under development. They heavily depend on the underlying programming language and AO language. See more..

Join Point Shadow

A join point shadow is the static projection of a join point onto the program code. Thus it is the code region which the existence of a join point depends on.

Module

See modularity.

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 separation between the individual units (modules). The code that implements a concern is modular (is a module) 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 tangled 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

Performing the weaving process at compile time. This is similar to static-inlining of method bodies and results in the compiled code advised by the aspect directly containing instructions to run applicable advice.

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.

Retrieved from "http://www.aosd.net/wiki/index.php?title=Glossary"

This page has been accessed 655,416 times. This page was last modified 21:45, 7 March 2011.


Wiki

Instant Feedback

Edited by the AOSD Steering Committee.  Maintained by the webmaster