Content deleted Content added
No edit summary |
→top: Clean up/copyedit |
||
(35 intermediate revisions by 24 users not shown) | |||
Line 1:
{{Short description|Feature linked to many parts of a program, unrelated to program's primary function}}
{{Refimprove|date=June 2008}}▼
{{single source|date=June 2008}}
In [[computer
Aspect-orientation is not limited to programming since it is useful to identify, analyse, trace and modularise concerns
▲In [[computer science]], an '''aspect''' is a part of a program that cross-cuts its [[core concern]]s, therefore violating its [[separation of concerns]]. It is a feature linked to many parts of a program, but which is not necessarily the primary function of the program. For example, logging code can cross-cut many modules, yet the aspect of logging should be separate from the functional concerns of the module it cross-cuts. Isolating such aspects as [[Data logging|logging]] and [[persistence]] from [[business logic]] is the aim of [[aspect-oriented software development]] (AOSD), of which the [[aspect-oriented programming]] (AOP) [[programming paradigm|paradigm]] is the most widely employed.<ref>{{citebook|title=Aspect-Oriented Database Systems|author=Awais Rashid|year= 2004|publisher=Springer|isbn=3540009485}}</ref>
One view of
▲Aspect-orientation is not limited to programming since it is useful to identify, analyse, trace and modularise concerns (e.g., PREview) through requirements elicitation, specification and design. Aspects can be multi-dimensional by allowing both functional and non-functional behaviour to cross cut any other concerns, instead of just mapping non-functional concerns to functional requirements{{fact}}.
▲One view of [[aspect-oriented software development]] is that every major feature of the program, core concern (business logic), or [[cross-cutting concern]] (additional features), is an aspect, and by [[aspect-oriented programming#Weaving|weaving]] them together (a process also called composition), you finally produce a whole out of the separate aspects. This approach is known as pure aspect programming, but hybrid approaches are more commonly used, perhaps since there is less of a paradigm shift between object- and aspect-oriented programming. There is a similar situation with early aspect software development (e.g., requirements), with traditional methods being enhanced for aspect-orientation and new models proposed. Non-functional concerns (e.g., security) can crosscut functional concerns (e.g., door must be present). It is possible for functional concerns to crosscut non-functional or functional concerns (e.g., need for more features harms mobility). A uniform approach to representation and composition, similar to the pure approach in AOP, is termed multidimensional representation.
== References ==
{{reflist}}
▲{{Refimprove|date=June 2008}}
{{aosd}}
[[Category:Aspect-oriented software development]]
[[Category:Aspect-oriented programming]]
|