Sunday, July 30, 2006

Why CRUD use cases are intrinsically evil

When performing analysis for a new system, many people find useful to shrink several use cases in a single one, and tagging it with the CRUD stereotype. This choice has a clear advantage in terms of readability of the use case diagram, while the stereotype (often associated with a different color) just triggers a multiplication factor when defining estimates for development time.

Readability and estimates are just a small part of the game when it comes to actually design the overall system. A Use Case is intended not only to be a measurement of the overall complexity of the system, but also a useful tool to capture the real goal (for a good exploration on the matter, please read Alistair Cockburn’s Writing Effective Use Cases) of the different parties involved in the use case. Just a simple order-invoice combination cannot be well represented by two CRUDs due to the many interactions possible between the two data types.

A system made up by a pile of CRUD usually ends up in a data-centric application, where part of the complexity of the interaction between different data types becomes a burden on the user, instead of a system’s responsibility. A user-focused use case (or an XP-like user story) should instead capture the flow of the interactions between different data types. If you’re not modeling what lies beneath a CRUD and another one, you’ll simply have to face it later on in terms of cluttered implementation or a not-so-usable application.

Separating use cases concerns
In nontrivial systems I found useful to separate the different concerns by defining two layers of use cases:
  • Business Level use cases focus on the user interaction with the system, they provide a detailed description of the user’s goal as well as other party’s, and span across multiple data types;

  • Implementation Level use cases focus instead on the artifacts needed to realize the use case, such as web pages, persistence methods, complex data manipulation and so on, generally tied to one or few data types.
The first layer depends on the second one for the implementation, and in trivial cases there is no need to separate them.

Testing the resulting system
A not-so-small difference in the two styles is that we can choose which use case layer is best suited to provide the specifications for building our test suite: at the business case level we can probably test more with less effort, and catch some awkward combination of data that tests based on the implementation level couldn’t catch. Of course the better combination is to define (unit) tests for the implementation level to be used as bricks for the business level tests.

If acceptance test are to be run by a real user, they’ll probably follow some path defined in business level use cases, instead of merely trying to add or modify some data and see what happens.

Enter the domain model
Such a modeling style, prepares the background for a domain model type of system (as opposed to the data-centric one). If we are to model something which lies in the correlation between two or more different data types, the best place to define it is in the domain model, be it in the component behavior or in the use case controller class. The default choice for data centric systems I’ve seen so far, has always been presentation layer… :-(

A significant exception
Apart from very simple systems, data centric applications (and thus CRUD-like use case modeling) are the best choice when the overall business processes aren’t completely defined, so instead of having a complex, but incomplete, system driving the user (possibly to a dead end) it’s probably better to have the expert users in control, and let them the possibility to tweak the system as they need (a possibility greatly appreciated in call centers, for example). However, this situation it’s not a great symptom of the whole organization’s health (but might be the driving force in a startup, for example), more often it is a sign of a poorly done analysis.

Tags: , ,

Saturday, July 29, 2006

Java Conference presentation available

SUN has published the presentation we gave at the last Italian Java Conference. The downloadable material is here.

Tags: ,

Monday, July 10, 2006

FIFA World Championship 2006

Campioni del mondo!!!

Campioni del mondo!!!
Campioni del mondo!!!
Campioni del mondo!!!
Campioni del mondo!!!
Campioni del mondo!!!
(Who cares about J2EE....)

Sunday, July 09, 2006

New challenges for the J2EE web developer

Recent technologies such as Java Server Faces and AJAX are causing a positive earthquake in the Java web technologies arena. As far as I can see, the first victim is the Struts framework: just an year ago it was the de-facto standard for a generic J2EE web application and was backed by a good support my many different IDEs, now it looks like nobody is starting a Struts project any more.

The leading factor for establishing a prevalence of JSF over Struts has been the pursuit of productivity, which was the weak point of many web application frameworks. Overall team efficiency paid a double fee to open source standards:
  • high development speed were achievable after a long training: the stack of competencies necessary to a generic web developer was definitely too high and fragmented (Servlets, Java Server Pages, tag libraries, HTTP, HTML, MVC and the framework in use).

  • Integration with IDEs has never been good: first it comes the framework and then comes some form of support from the IDE, but far from being sufficient. So the standard situation is to have the IDE perform some sort of trivial task for you and then start digging in runtime case mismatch error in some XML file (I guess you know what I mean)

JSF nowadays starts straight from the IDE offering a developer a way to efficiently design web application in a way that has been forgotten for a long time (most developers I know find still more productive to manually edit web pages or tags instead of delegating it to the IDE). After a couple of projects, our experience shows that JSF impacts positively on development speed, so …goodbye Struts.

Re-enter usability
In the meanwhile, components are evolving, exploiting possibilities allowed by the AJAX technology. A new level of interactivity is possible for the web platform where it has been neglected for years (with some niche exceptions like ActiveX, Flash etc.), particularly in the enterprise software field, where you don’t have to attract users to your software (“I pay my employees to w-o-r-k, not to have a satisfactory user experience”).

Now the situation is different: in this scenario a web software can be comparable to a fat client in term of interactivity and usability. The problem is that web developers have been working without these possibilities for years (forced to choose only between combos and radio buttons) forgetting what an easy-to-use user interface should be. The move to a new paradigm has been taken only on the technology side, but doing “the same old stuff” with a new framework is only half of the job: the other half is using the new tools to produce better software.

The following months will tell if this will be achieved by improving developer’s awareness of man-machine interaction mechanism or having software analysts provide a more detailed level of specifications in the early stages of the project.

Tags: , , ,

Tuesday, July 04, 2006

Java Conference Afterthoughts

It took me quite a few time to recover from the Italian Java Conference. I was involved in a 3 hour seminar and a 45 minutes speech. Seminar’s title was “migrating applications from Delphi to Java”, while the short speech one was “Migrating development teams from Delphi to SUN Java Studio Creator”. The night before I met with Filippo Bosi and Giuseppe Madaffari, my co-speakers and with Mokabyte’s egghead Giovanni Puliti, to finalize the presentations. As expected, I went to sleep not before 3.00am. And woke up angry and disappointed 4 hours later.

Not so many people attended the seminar, probably because
  • you had to pay SUN 200€ for that

  • James Gosling was speaking in another conference hall
We had some troubles configuring my laptop with the projector, this made us lose some time which I tried to recover at the end… so we finished late. But then I was the first speaker of the afternoon, guess what? No lunch (I hate that). The smaller speech was unpredictably stuffed up with people, probably waiting for the following speech about XP and TDD, I suppose. I regretted shaping the slides in a too serious way for this one, while I had more funnier slides in our “private” performance. As a result the speech sounded a bit more boring than I wanted, but I really was too hungry and tired to add an extra verve to the speech.

After the speech (and the long awaited lunch) we hanged around the Mokabyte stand, where I bumped into Filippo Diotalevi, that was a speaker on the following day. He has been doing a lot of cool things since I knew him in BPM… chapeau!

Tags: ,