Model Design

At this point, designers of the RUP school might insist on the creation of various class diagrams. I generally do not create formal class diagrams.

In designing the View components, the visual representation of page flow and transition events shown previously, and the accompanying tables, were vital to analyze control flow within the application, and identify the required action processing. I contend that, for small projects, this is usually not the case where class structure and relationships are concerned.

Diagrams may usefully be drawn on an ad hoc basis, but are not particularly useful in ensuring good, clean design. A clearly worded class header, member descriptions and method headers are vital, and far more important for later maintenance and upgrading. The various standard UML representations of the model classes do little more than presenting some of this information in a visual form. Diagrams alone rarely capture the complexities of class function and inter-class relationships. The headers, in the form of Javadoc comment blocks, are the important artifacts of the model design process.

In many web applications, the task of designing the model starts by differentiating between two general categories of model object:

• “Business objects” whose architectures reflect the nature of the application, and which can designed for general purpose use, i.e. not tied to the particular application, or indeed to web application architectures in general. These objects are also the ones which interact with other backend tiers (SQL databases, mail servers, etc.)
• Objects which sit between the business objects, and the controller and view objects. The features of these objects are determined to a great degree by the view and controller architecture. In the case of a Struts application, this means objects whose methods are invoked either by controller objects (i.e. Action objects) in response to client request, or by view objects (compiled JSPs or tag objects) which render a new view reflecting the new internal state

In our case, the job is already done for us. The Javamail API defines the “business” objects. Our model design task is thus simplified to a consideration of:

• The interfaces available in the Javamail API
• Basic technical features of the web application specified at the outset, namely the decision that the web application will not provide a local disk cache for the contents of the folders.

The Javamail API provides Folder and Message classes, which act as proxies for corresponding structures on the IMAP server. The Message class itself represents the various headers of a message, while objects implementing the Part interface and its descendants contain the actual message content. When a folder page is to be generated, an array of Message objects is obtained using methods of the Folder. To generate the Read page for a selected message, the content of the message is retrieved from the IMAP server.

The address book must be considered on its own, since it is not a feature of the mail server. In this application, it resides as a table in a SQL database, modifiable only by the user who owns it. To minimize SQL accesses, a class will be provided to act as a cache.

The above considerations lead to the specification of:

• FolderWrapper: a class representing a Javamail Folder
• MessageWrapper: a class representing a single message
• AddressBook: a class providing a write-through cache of the address book table

The FolderWrapper and MessageWrapper classes provide access to the underlying Folder and Message objects respectively, and implement the getter and setter methods required by the controller and view components. But where are the methods which connect to the mail server to retrieve the Folder and Message objects, and wrap them in their respective wrapper classes? For this we need:

• MailManager: a class providing the interface to the mail server to retrieve the Folder and Message objects

Finally, we also need:

• AttachmentManager: a class to store uploaded attachments during composition of a message, and attachments retrieved from the Mail Server as parts of multipart messages