Android Application Part 3 - UML

This post is part 3 of a series.  Click here to go to part 2.

Before I go into the actual UML for this application, I first have to talk about my opinion regarding things like UML Diagrams, Sequence Diagrams, State Diagrams, Activity Diagrams and Object Diagrams.  As Software Engineers, we differ from other Engineers in a major way.  The only thing we produce that is a COMPLETE representation of the systems we build is the code.  In no other engineering endeavor is the completed product also the description of that product.

Based on this knowledge, it is my belief that all the diagrams and drawings and 'design' aides we use to build software are there not to completely document a system.  On the contrary, attempts to completely document a system using these tools is rather counter-productive.  So what are they supposed to be used for?  I like to think of all these diagrams and pictures as tools to be used for the following purposes:

• To allow the Software Engineer to organize his thoughts about the system, and aide in his decisions regarding the design.
• To provide a way to describe a PART of a system that may be important or complicated at a high leve
• To allow the view of a system at a higher, abstract level, without the details, to allow for a broad analysis of a system

That's it.  That's all.  That's what all these things are good for.  I know the very next question people will ask - What if we really need to understand the details?  What if we need to KNOW what the system is doing?  Well, there is only one reliable way for someone to know what a software system is doing - GO READ THE CODE!

So, when I produce UML, State or Sequence diagrams, I typically omit a lot of detail.  I intend for these things to convey limited messages and present limited data because they are simply tools of transition, there to help in the final build of the system.  Now I will get off my soapbox and present to you the simple designs for my app.

The UML

As you can see from the UML, this is a pretty simple object model.  We'll see if I need something more complex later, but this appears to be the basic outline for what I need. 

Notice that I added some auditable information to the Items.  I figured you would want to know who and when an item was added, removed, updated, etc.   

To the right, you will see my DAO UML diagram.  As you can see, I have declared a Dao interface that uses generics.  Each subclass will implement the generic type for its Type of object. I also chose to use a DaoFactory to create my objects.  You'll notice that I have not represented all the relationships, return types, arguments, etc, that would make this UML complete.  Isn't this version much less cluttered, though?  And isn't my intent straight forward?

I intend to use GWT for my Web site, so I have a set of RPC services that will extend RemoteServiceServlet.  As you can see, there is nothing magical here.  It is implied that each of these services will use the corresponding DAO associated with them.  I could add those relations to this UML, but I think it just adds complexity.


I am going to refrain from building the UML for the visual components of this system.  Why?  For one, the diagrams get pretty complicated pretty fast.  And two, because I already have plenty of diagrams showing the 'guts' of my system. 

The Sequence Diagram

I will demonstrate one sequence diagram that is representative of this design.  Most actions in this system will follow this pattern:

The first thing I want to point out about the sequence diagram, is that it is rather hard to model the AsyncCallback used by GWT RPC.  I supposed I can add a call to the AsyncCallback constructor from UserServiceAsyc, and fit the model that way, but this is another scenario where that tends to obscure the intent rather than enlighten it.  Instead, I just put a comment that the GWT magic is omitted.  I hope that other developers looking at this would be familiar with GWT.

By the way, my favorite modelling tool is called, Violet.  It is completely free.  It's simple, but makes for a rather quick and easy way to build your models so that you can get your thoughts together and start coding.

Next: We'll get into some coding. FINALLY!