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.

XMLBeans Practice--Automate Exchanging data between XML's & Java (1)

Installation of XMLBEANS
I hope this section can help solve your problems, if not all, encountered when installing XMLBEANS. XMLBEANS installation is hard to deal with and I think most of people will encounter problems when installing it and I'm not an exception.
The XMLBEANS(here it's 2.0.0-beta1) binary archive package, by convention, contains directories, bin, docs, lib, etc. And you'll have to set your path and classpath just like installing other java tools. But after that I think 90% people can't run XMLBEANS correctly. There're some points to notice and I hope your encountering problems are listed below (OS:WIN XP SP2) :

• About your jdk directory. My jdk directory is under the "Program Files" directory. And when I run XMLBEANS with "scomp...." in the command line prompt, errors saying roughly like this(on my PC erro message is in Chinese): "'E:\program' is not a internal or external command, neither is it a executable or a batch file." This error message reminded me of the caution information I read when I was installing Weblogic 8.1. The information said "Don't leave a white space in your weblogic path, for it may cause severe problems". Since both of XMLBEANS and Weblogic are produced by BEA. So I move my "JAVA_HOME" to the root directory of one of my partition.
• About your "PATH". When I thought I would make it. The fact again let me down. When I run "scomp...", XMLBEANS threw IOException saying "'javac' is required on the path.java.io.IOException : CreateProcess: c:\xmlbeans-1.0.2\schemas\javac @c:\DOCUME~1\alex\LOCALS~1\Temp\javac20992 error=2nulljava.io.IOException: CreateProcess: c:\xmlbeans-1.0.2\schemas\javac @c:\DOCUME~1\alex\LOCALS~1\Temp\javac20992 error=2 ", something like this. And this time I checked FAQ at here .I followed its advice but I couldn't find JAVA_HOME in my scomp script(in the bin folder). I think it's for old version of XMLBEANS and the information was not timely refreshed. And another piece of information solved my problem. There is a precedence among your JRE and JDK when java program finds java path. The former would be first located by default. So I put my JDK directory at the left most of my PATH variable.
• About your "XMLBEANS_LIB". The official installation guide doesn't mention this. I found it in the scomp script. So I add a new environment variable called XMLBEANS_LIB pointing to my lib folder.

After the three steps I'm processing my XML Schema files with XMLBEANS. In addition, I wonder why BEA don't make it easier to install it just as install other java tools. Do they want to test our patience of using their tools?

Coming soon: XMLBeans Practice--Automate Exchanging data between XML's & Java (2): Working With XMLBeans

The origin of foo & bar which almost everywhere in the demonstrating codes

The etymology of hackish `foo' is obscure. When used in connection with `bar' it is generally traced to the WWII-era Army slang acronym FUBAR (`Fucked Up Beyond All Repair'), later bowdlerized to foobar. (See also FUBAR.)
...It has been suggested that this might be related to the Chinese word `fu' (sometimes transliterated `foo'), which can mean "happiness" when spoken with the proper tone (the lion-dog guardians flanking the steps of many Chinese restaurants are properly called "fu dogs").
...
Other sources confirm that `FOO' was a semi-legendary subject of WWII British-army graffiti more-or-less equivalent to the American Kilroy. ...
Earlier versions of this entry suggested the possibility that hacker usage actually sprang from "FOO, Lampoons and Parody", the title of a comic book first issued in September 1958, a joint project of Charles and Robert Crumb.
...
An old-time member reports that in the 1959 "Dictionary of the TMRC Language", compiled at TMRC, there was an entry that went something like this:
FOO: The first syllable of the sacred chant phrase "FOO MANE PADME HUM." Our first obligation is to keep the foo counters turning.
For more about the legendary foo counters, see TMRC. Almost the entire staff of what later became the MIT AI Lab was involved with TMRC, and probably picked the word up there.
Very probably, hackish `foo' had no single origin and derives through all these channels from Yiddish `feh' and/or English `fooey'.
Complete explanation can be found here.

How about writing your GUI as XML files?

I've got an idea from the previous project our lab is involved in. We can store all the information of a GUI, including both its layout appearance and logics behind it, in a bunch of XML files, from which then we can restore the GUI with both the same behavior and the same appearance.
As I said in my previous article, in VC++ environment we can't make it because of widely used user customed Controls in addition to lack of implementation of meta data protocol (in Java it's the reflection mechanism). But on JVM we can get every control's properties, if not all, through Java's reflection mechanism. So it is likely that we can replicate, of course not through copying binary files, a given control written in java.
However, technology is just technology and is useless if it is not practical. Now I just don't know where it can come into play. I know in MS's next generation OS Longhorn there will be a new graphical architecture, Avalon, which allows writing GUIs just like writing HTML files , and which, I wanna mention, uses XML files as the intermediate representation of GUI. That's very similar to my idea. But MS sets up an environment, a some kind of parser or engine, for use of these XML files. But in a common system not as large as a OS, I can't figure out what this technology can be used for, although I think it's not a bad idea and I subconsciously feel that it will be useful.
So I have to further think about it. And if anyone got idea on how to use this technology, please leave a comment. You'll be very appreciated.

Spending Hours Writing a Testing GUI.

It's a part of our lab's arrangements. It's supposed to be finished this morning. But as I said in the last post I put off it till now.
Wirting here, I wanna talk about the project our lab recently involved in, which now proved to be infeasible. The project is to provide a very vivid environment for the user to practise or test their mastering of operating large scale Windows based ERP software. Simply speaking, what we supposed to do is to emulate the targeted ERP software, not only the user interfaces, but also some logic, which the users are interested in, behinde them.
It is not easy to write a software like that. We do a lot of experiments in which we capture as much information of kinds of control as we can from a third party software which will be finally targeted on SAP's ERP. We identify the type of a control according to its internal class name which, if not by default, arbitrary. Obviously, It's a mission impossible. Because user customed controls are everywhere, even in MS's software. So considering this, the type of a control can't be automatically identified.
My advisor has decided to turn down the project. To clarify that we really made a lot efforts and to tell our customer that this project is not feasible we have to integrate what we've done into one prototype to demonstrate our judgement.
And that's why I write the GUI. It's sort of WIN32 programming. I don't use MFC.
ps: If someone know how to work out problems I mentioned above please contact me. Thanks for any reply in advance.

AOSD'05 - A great conference.

In the middle of March the Annual Aspect Oriented Software Development Conference 2005(also the fourth conference) was hosted in Chicago.
Almost all the important experts, practitioners and company in this field joined this conference and it also came with many reports online and offline.
I'm really excited about this conferece for seeing the rapid development of AO. Although I can't attend this conference I read news and blogs reporting the conferece. And I have strong confidence in AOP being more and more accepted by the industry.