Always Start with the Use Cases

You usually come into any project with somewhat of an idea of what you want the thing to do. The first step, therefore, is to get these ideas down on paper. This process can encompass a mission statement, feature list, or other textual description of what you want to get done. We are in the brainstorming phase here, so anything you write is good. Let the ideas flow.

Now when you are ready to sit down and actually begin work (making sure your coffee cup is filled first) the first step should be use case diagramming. We are still in the brainstorming phase at this point, but use cases make the application begin to take shape, with early definitions of actual application components emerging.

Many of the use cases will be obvious. Some will become evident once the more obvious ones are defined. For use cases, there will certainly be “view available quizzes”, “take quiz” and of course some sort of authentication / log in behavior.

The initial data model can be developed in parallel with the use cases. Remember, both of these models will evolve throughout the life of the project. We are not doing big upfront design here, just enough architecture to get going. But some formal design is always a good idea.

As you go through the use case modeling, keep a note of the domain objects that you start describing. Start building your domain / class model now as well. Some of these will be obvious. In my cases, things like Quiz, Answer, Question, and of course the always present object User, were things I didn’t need to think much about. But the relationships between the two are not obvious. Is user related to quiz, quiz to question, or is there something more complex going on.

As soon as a few main uses cases are defined, it is time to jump into coding. Besides the fact that this is what I like to do, early coding will help you solve early problems and answer unknowns related to new technologies. You just want to make sure you are on the right track. This is called the vertical slice approach, where you build out a piece of functionality, generally a couple of use cases, from start to finish (from the web page to the database, the full stack). Plus it is always nice to have a working application to show. I won’t go into a full discussion of this topic. Just see any of the Agile literature for more information.

The quiz application is not yet an earth shattering innovation (but I do have a few things planned that could very well be). However, one goal is to implement the latest best practices in web application development. As such, I finally have the luxury to take the time and do it right. Of course, there are time pressures for this one as well, there always are. Even if there aren’t any dictated timelines, technology will eventually move ahead, you can’t stop that, and you will always be chasing the latest and greatest technology and practices.

The Complete Rewrite

Have you ever worked on a project and not thought that is would really benefit from a complete rewrite? It would be nice if that was not the case, but I believe reality dictates that what we wind up releasing is less than ideal.

One reason for this is changes in technology. New tools, techniques, and frameworks are constantly being developed. How many projects out there using Struts would not prefer a rewrite in a more modern framework.

The second reason is time constraints. We just do not always have the time to implement things the way we would like in the ideal world. There is always pressure to get things done yesterday. Much of programming wisdom is in finding the right balance between quick development and a well designed application, and delivering as much of both as possible.

We also seem to like the complete rewrite, such as when a new release of a product comes out. Check out this announcement from Spectral Core for their excellent Full Convert product.

Full Convert 5.0 released:

1-Conversion engine rewritten so that .NET framework is no longer required. This considerably reduces installation size and memory consumption, improves conversion speed and user interface responsiveness.

I feel good about this new feature, after all, it is a complete rewrite.

When I wrote Domuswap, I didn’t have the luxury of a complete rewrite. Domuswap was developed concurrently with the XX framework 1.1 and 2.0. Once the framework proved successful in Domuswap, it was released. However, I was still using the underlying framework and legacy code. Some was rewritten, but the time certainly wasn’t there for a complete rewrite. Indeed, I was very happy with how easily the existing code fit into the Spring MVC components that were added.

Would I have liked to do a complete rewrite? Definitely. I’d probably like to prove that XSL could indeed be speedy, or get rid of that approach entirely. I’d also like to enhance the multi threading techniques. I did this to some extent for version 2.0, in conjunction with my Sarasota Java Users Group presentation on concurrency. But that feature is still in experimental stages.

If I was to do a complete rewrite of the XX Framework, I would probably start with pure Spring MVC and just weave in some of the more interesting XX features, all the while sticking to their interfaces as much as possible.

All that being said, I find myself with the luxury of doing a complete rewrite at this very moment with the New Project. I plan to do this, in addition to satisfying the necessary functionality, as an implementation of what I see as the current best practices in web application development. I’ll have much more to say about this project in future columns.

The New Project

I began a new project today. We’ll really last weekend; I am just getting to write about it now.

The projects not in relation to my current full time consulting gig (which is a GTW project for the insurance industry). The new project will be an education testing program for a local community college, essentially online quizzes. I am also using this project as an opportunity to explore new tools and frameworks.

When we think education application, Flex comes to mind, and it is certainly a frontrunner, especially for the interface/testing component and if multimedia is incorporated.

For the back end, I am moving away from the XX Framework. While I think the framework is awesome, I need to get additional experience on more industry standard tools. Of course, XX is built on Spring MVC. But I want to get some additional experience in pure Spring apps.

Spring Web Flow is another possibility. The more I read about Spring MVC and Spring web flow, the more in common I see with what is in the XX Framework. Regarding Web Flow, I don’t know if I want to write so much in their XML/Expression based DSL. I don’t mind specifying this stuff for control reasons (like what XX does) but getting into defining variables doesn’t seem the place for XML based grammars.

Spring web flow does lend itself to a graphical editor. I haven’t tried Spring IDE, but since they were a recent SunJug sponsor, I took a quick spin in Skyway Builder , an eclipse based GUI for generating Spring MVC/Spring Web Flow apps. It is really an impressive product. However, being impressive doesn’t mean it is useful (sort of how I feel about GWT most of the time). Why try to graft a GUI over what is a perfectly capable and expressive language (Java / XML). In some cases, this will make sense, but in many or most, just writing plain old Java is quicker and quite understandable.

I need to work more with these tools to really make a judgment on them, however.

The one thing I always start with is a bit of upfront UML modeling. I use Enterprise Architect, which is a really inexpensive and reasonable good UML tool. Just brainstorm out the use cases and draw up some classed. It always helps to diagram these out before putting them to Java , and it doesn’t take too long to get to the Java stage.

One thing I did take away from reading some of the Web Flow docs was the use of UML state diagrams. I have always used Use Case diagrams and activity diagrams almost exclusively, but the web flow authors showed how State diagrams can more easily model the overall flow of the entire applications.

So I will most certainly do a Spring MVC / Hibernate / MySQLback end. Build out the model and services. I haven’t decided on the front end. It may be Flex, with BlazeDS or web service interface. Maybe JSF, which I have the least experience in and would like to learn. Most likely a portion will be in a Spring MVC view technology, namely JSF, Velocity, or Freemarker. Most likely, the application wills involve several of the above tools.

Java Versus PHP

One of my main interests is in web frameworks, or more simply put “what is the best way to implement a given application?”.

I like Java, love the IDE’s available and what they can do, and believe that a good Object Oriented design is the foundation of a good application, irrespective of the technologies used.

That being said, there are some really great PHP applications out there (WordPress, Joomla. Drupal, etc). You really can’t point to as many open source, easily available Java applications.

The main selling point of the PHP is the ease of installation and deployment. Most of the popular programs just require you to upload the source code and run an installation script.

Java on the other hand is a bit more involved. If all goes well, you should just be able to copy a War or Ear file to your server and you are all set. Of course, there are issues with restarting the application and such architecture is of questionable ease to extend with plug-ins the way PHP seems to be. I’d like to think that all the good Java developers are too busy building really cool corporate applications, which might actually be the case.

I bring all this up due to my recent experience in finalizing the XX Framework. I have two demo applications that are part of the distribution, a guestbook and an implementation of Java Pet Store. I’ve successfully converted these to XX 2.0, and they can easily be deployed as a War file.

My intention was to have the demos available online. This is always a nice to have when looking at a new framework or product.

I use and love Eapps.com for hosting. I’ve been able to run Domuswap.com on their shared VPS environment, but soon outgrew them and moved to a GoDaddy dedicated box.

Since I don’t want to spend much money to keep the demo apps online, I attempted to deploy the War to a shared 256MB server. It deployed and ran fine, but quickly blew through available CPU, so I had to back it out before I received a phone call from Eapps support “suggesting” that I upgrade.

I thought, if this was a PHP application, it would likely work fine and be quite fast. Is this just the nature of PHP versus Java, PHP being more suitable for the low end and Java more for the high end. I think this is probably the case. I should add, that the XX framework is a known CPU hog, being entirely dependent on XSL transformation and those can certainly spin up the processor.

I’d like to compare apples to apples some day and deploy a simple and lean Java app, with and without additional frameworks like Spring and Hibernate. I could rewrite the demos to do this and hopefully someday I will have the time to do just that.

XX Framework V2.0 is Released

After several years of work, the latest release of the XX Framework is now available.

The major change to the framework is that it is now ported to SpringMVC. This should allow greater flexibility and easier incorporation into existing or new Spring applications.

One of the first comments I heard when I released the framework back in 2006 was “how does this differ from Spring”. I didn’t think it was much like the Spring core, but he must have meant SpringMVC. Over the years, Spring MVC turned out to be one of the few frameworks that made perfect sense in almost every manner (as does Spring itself). Much of the early work on XX, and most frameworks, is in developing the plumbing (servlet routing, data marshalling, transactions, security, etc). This was all built into XX, but Spring already does it and much better I am sure.

A while back, I made the decision to port the framework to sit on top of SpringMVC and let it handle all the plumbing and let XX do what Spring does not: automatically marshall data from the web layer to the database layer and back, and provide an XSL centric view paradigm.

The migration was surpisingly smooth and would have happened much sooner if I can the time or additional resources. After the servlet mapping layer was migrated, most of the XX controller and database functionality just worked as is. The one main change I made was to incorporate Spring Hibernate integration (DAO stuff) and dependency injection.

The framework has powered Domuswap.com, in both its Spring and pre-Spring incarnations. While a site’s performance is certainly related to the hardward available, we did get some 4000 visitor days at its peak.

I still think the key differentiators of the XX framework continue to be valuable. Further integration into Spring is needed to where it is more of a plug in to Spring rather than a separate framework built on top of Spring (like Grails).

Check out the XX Framework.