[Main Page]

Glossary

(Difference between revisions)

Main Page | Recent changes | Log in / create account |

Printable version | Disclaimers | Privacy policy | Current revision

(Dominant Decomposition)
(Concern Graph/Model)
Line 24: Line 24:
=== Concern Graph/Model ===
=== 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 [http://www.cs.ubc.ca/labs/spl/projects/concerngraph.html Concern Graph Project] and the [http://www.cs.ubc.ca/labs/spl/projects/feat/ FEAT] plugin for Eclipse.
=== Crosscutting ===
=== Crosscutting ===

Revision as of 22:52, 11 May 2005

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

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

Encapsulation

Feature

Join Point

Join Point Shadow

Module

Modularity

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.


Wiki

Instant Feedback

Edited by the AOSD Steering Committee.  Maintained by the webmaster