Thoughts after Ivar Jacobson's speech. Is Agile Process really Agile?

25th Oct. Shanghai China, I heard Ivar Jacobson's speech about his understanding about the next generation of software process. IMHO, his key point is to make UP(Unified process) more agile than agile process, which he called "smart". Then I wasn't much convined, because I thought his understanding dpend too much on a intellegent product called "WayPointer" developed by one of his own company. But later when I went home and used WayPointer trial edition accompanied with the provided CD to work with Rational's product, I understand everything. It really can make RUP more agile. It's a intellegent agent acts as pair programmer, telling you when and what parts of RUP document to read.
And, another of his point supporting the key point is UP use explicit knowledge rather than tacit knowledge, which make ailge seem to be agile, used by agile process. With explicit knowledge you can learn and you can search for what to do next in the knowledge library. However, tacit knowlege is never documented and hard to be learned and harder to be searched. So the most experienced programmer have the most tacit knowledge, which make success of project primarily rely on key individuals. So, is Agile process really agile?（Anyone wants a PPT of his speech, email me at i.am.blogger at gmail dot com).
What a pity, Dr. Ivar didn't talk much about doing use case with aop, which he proposed in his latest papers and later turned out a book about AOSD(I got the book for free at the speech : ). So the following part of my blog will cover this aspect.
The report was received with complacency:" This is the nature of software--use case cross component--and there's nothing to be done about it."In RUP, use case play a very important role, elicitating requirements, coordinating stakeholder requests, measuring the grain of iteration. According to RUP, use cases are finded out, refined and then usually implemented in several components, that is, simply speaking, a use case is often devided into parts assigning to components(Classes, to simplify the matter) according to each component's reponsibility. However, that's not the end. In RUP test cases are derived from use cases, which means testing is usually conducted in terms of use case to verify every use case is correctly implemented. All we see is that it's really a use case driven way, but traditional components stands in the way, breaking down use cases. It seems if we are royal enough to use case technology, traditional component-centric development contribute negatively to the whole development process.And interestingly enough, in an AOP view, it's typically crosscutting, with every use case almost always cross cutting components. Dr. Ivar has his own way of solving this problem, which he proposed in this paper.
But I wonder if a use case driven method is widely adopted, otherwise it isn't worth much effort on this issue.
So here I wanna conduct a survey, how many companies use USE CASE technology and to what degree use case technology is adopted (only used to handle requirement issue or as a use case driven development way)?
Any comment about either my ideas or this survey would be very appreciated.

Is AOP a Programming paradigm

Edited by: I.Am.Blogger at gmail dot com

Prerequisite:
“A programming paradigm is a paradigmatic style of programming (compare with a methodology which is a paradigmatic style of doing software engineering). A programming paradigm provides (and determines) the view that the programmer has of the execution of the program.”
(http://en.wikipedia.org/wiki/Programming_paradigm)

Yes:
“I would argue that by any reasonable definition of paradigm, AOP is one. You can "think aspects" starting from fairly early in the design process (probably requirements too); you can design and develop those aspects; you can make the code look like the design; the aspects can be treated as independent units, with independently assessable properties and value. All the things that I at least thought made OO a paradigm seem to apply...”
By Gregor Kiczalse(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001001.html)

“…Note that the original meaning of "paradigm" entails the notion that two different paradigms are incompatible, which means that the qualification as paradigms does not depend on whether you can use them independently but rather that you _cannot_ use them together. From this perspective, none of the programming paradigms in computer science are really paradigms, because it's certainly possible to mix them altogether…The analogy that I'd propose is that AOP relates to OOP as OOP relates to imperative programming, and if you describe the move from imperative programming to OOP as a paradigm shift, you also have to describe the move from OOP to AOP as a paradigm shift to the same degree.”
By Pascal Costanza (http://aosd.net/pipermail/discuss_aosd.net/2004-July/001004.html)

No:
“Mathematically, aspects form a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, AOP enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension, rather than as an independent paradigm. Friedrich Steimann, for example, has proposed such a view.”
Wikipedia(http://en.wikipedia.org/wiki/Aspect-oriented_programming)

“..In OOP you have communicating objects with encapsulated state. In FP you have the notion of encapsulated functionality and side-effect-freeness, however no explicit notion of state…that all the paradigms noted above can exists "on its own". You can use FP without OOP…AOP, however as I see it, always (correct me, if I am wrong here) makes use of a kind of "host paradigm", that provides basic expressiveness and then kind of provides a way for second-order reasoning on that "host paradigm"…”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001003.html)
“…when moving from IP to OOP,one gains the new concept of encapsulated state together with the notion of messages. This changes the whole universe of reasoning: Instead of reasoning about loops or sequences of commands executed on a machine (IP) one now certainly talks about objects that are communicating via messages.…I see the difference in the fact that when moving from IP to OOP, we change the entities we are reasoning about (objects rather than commands) while with AOP we don't really. Of course AOP claims an aspect as the additional entity of reasoning. But can one really see an aspect as a single entity ,that is without any coupling of the outer world? Objects in OOP do so, also do functions in FP (due to side-effect-freeness), aspects however don't, since in all AOP languages you will always at some point have to conrecretize when and where your aspect synchronizes with the rest of the world…An object in OOP is fully compositional without exposing any of its subunits to the outer world. For functions in FP, the same holds. However, does that also hold for aspects?....”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001005.html)

Two citations above By Eric Bodden

Note: FP=Functional Programming, IP=Imperative Programming.