I think I can give a reasonable overall picture of AOP.

Think about it from a top-down view-point, as a form of weaving code together, 
as opposed to the traditional manner of building one block on top of another. 
So lets say you want to monitor employees. So you create a model of an 
employee, then you create a logging mechinism, and say a visualizer. AOP 
allows you to weave these components together describing how they interact, 
without requiring you to specifically modify any of the code within them. 
Traditionally you would have built the logging mechinism on top of, or 
integrated into, the employee model, and likewise with the visualizer. AOP 
allows you to have much cleaner Seperations Of Concerns --and that's the real 
point of AOP.

So an *aspect* then, is one of these concerns, and is said to be orthogonal to 
the other concerns. The weaving is accompished by describing where code is to 
be "interwoven" into other code. The code that gets "inserted" is called 
*advice* (in practice it is defined much like one does a method). This is 
accomplished by selecting join-points. *Join-points* are specific places in 
code that can have other advice code inserted into it, and are selectable by 
some descriptive syntax. This syntax will select a set of joint-points; a set 
of join-points so selected is reffered to as a *point-cut*.

HTH,
T.