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:

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 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:

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:

Finally, we also need: