Aspect Oriented Software Design extends Object Orientation by further
simplifying the design of complex software.

In object orientation, objects are categorised or classified into a
classification hierarchy. Every object class forms a monolithic unit
of behaviour, refining any behaviour inherited from its parent in the
hierarchy. But what do you do when an object has multiple facets,
participating in more than one sphere of activity or interest? OO
addresses this by introducing multiple inheritance, though this can
be confusing because of the divided loyalties. To limit multiple
inheritance through the use of interfaces is a common compromise,
allowing state variables to be inherited from only one superclass but
methods (required behaviours) from many. Multiple inheritance and
interfaces share a common problem - any activity which is requested
of an object may affect any part of its state.  There is no isolation
between the state variables that affect different facets of an objects
behaviour - the object is monolithic.

Aspect orientation separates the multiple facets of an object, allowing
a single object to have many facets, each belonging to a different
aspect. Each facet of an object may define state and expose methods
relevant to that aspect, but the facets are relatively independent
of each other. By organising the facets, the confusion of multiple
inheritance can be removed. A deeper separation of concerns may be
achieved and the difficulty in describing the required behaviour is
reduced.

In hierarchical aspect orientation, aspects are arranged as a
hierarchy. A facet can only use or affect facets defined in the same
aspect, or in parent aspects. In this way, the various behaviours of an
object can be isolated from one another, and each behaviour can instead
be related to just the relevant facets of other objects with which it
interacts. The aspect hierarchy cuts across the object hierarchy. Thus
an aspect may be defined as a collection of related interactions, and
the facets of the objects which interact.

This usage of the term aspect falls very naturally in line with plain
English, and is directly acceptable to non-technical people. The
identification and classification of aspects becomes a very early step
in the design process; a useful classification may result from the
first brainstorming session with the client. As each candidate object
is identified, its roles as a participant in different aspects of the
system may also be discussed.

Existing research being undertaken under the banner of Aspected Oriented
Software Development seeks various goals:

* Infrastructure problems.
  These include Tracing & Logging program flow; things that shouldn't
  affect the behaviour of the software being extended.

* Integration or composition problems.
  These problems involve making existing software artifacts operate
  together on overlapping data sets, including synchronisation and
  concurrency.

* New design
  Aspect Orientation has its most potential in new designs, but many
  researchers are stuck trying to retro-fit aspect oriented features into
  existing languages, like UML.