Case study: Travel bookings
User and developer views of the system
What follows is a series of views illustrating different aspects of the system from the perspectives of the user and the developer. This is not a programming tutorial. Rather, it is an attempt to show the close correspondence that exists between the two views of a business system developed with the Naked Objects framework. From these screenshots it is possible to get a sense of just how easily a user-request can be translated into the necessary code changes.
An 'application' consists of nothing more than a set of business object classes. All user operations take the form of actions invoked upon an instance of one of those classes or upon the class as a whole. Any class that could form the start-point of a user activity is shown in the user's 'Classes' window, shown here on the left of the screen.
1. These are the six business classes that constitute the prototype reservations system.
2. Right-clicking on any class icon pops up a menu of class methods, including one to create a new instance of that class. The generic class methods shown here require no programming since they are automatically provided by the framework.
3. Other generic class methods allow the user to find particular instances or show all instances of that class.
4. This symbol represents a collection of objects: in this case, all seven of the cities in the system.
5. Where there are more instances than can be shown in one window, the collection would provide methods (greyed-out here) to page through the objects.
6. The code for this application is all held in a project folder called ecs.delivery.
7. There is one Java class
corresponding to each of the business object classes presented to
the user. The label on the user's class icon is (by default)
automatically derived from Java class name. Here
8. Each business object class must
9. The only code in this project that
is not a business class is
For most business scenarios, the user of the system will be dealing with individual instances of the business classes, and sometimes with collections of instances of the same type. By default, an instance uses the same icon as its class, but has an individual title. It is also possible to vary the icon according to the identity or the status of the object.
1. By default, instances use the icon of their class, but instances have titles to identify them. This instance is shown collapsed to its icon-only view.
2. The menu actions shown here provide different ways to view the object. The viewing options offered will depend upon the type of object. All the viewing options are created automatically by the framework.
3. The default view is the 'form' view shown here.
4. Instances have titles that are usually derived from one or more of their identifying attributes and/or their current state
5. Each class is defined by the set of methods it can fulfil. All these methods deliver specific business value, and result directly from a user requirement. The underlying technical methods needed to manage the objects can all be inherited from the framework and need never be seen by application developers.
6. Each business class needs a
7. The title method must return a
Open a view of any object and you will see a set of fields. Some of these fields contain simple values (such as dates, numbers or text strings), which the user may be able to enter or edit. Other fields will contain business objects, shown as icons. Even where an icon appears inside another object view, that icon still represents a fully functional object: you can invoke its behaviours in situ or open up a new view of it.
1. An empty 'value' field.
2. The grey hole indicates that a City can be dropped in here.
3. This field contains another business object - a City.
4. Here the user has typed some text into the value field.
5. If you attempt to drag the right type of object into a field, (here a City) the drop zone will flash green. A red flash indicates that the framework will not let you drop that object there, either because it is the wrong type or due to some other programmer-specified rule.
6. Each field in the user view is
determined by the existence of a
7. A business object field will require a
9. The framework provides a set of generic
We have just seen how a field can contain a reference to another business object. Naked Objects can also handle more complex relationships such as multiple associations, where one object knows multiple instances of another type, and bi-directional associations, where two objects both know about each other.
1. The Customer can have multiple Locations associated with it.
2. A new Location can be associated by dropping it onto the grey hole at the bottom of the collection.
3. Right clicking on any member of this collection offers the option to Remove Reference.
4. This is an example of a bi-directional association. When a Customer is associated with a Booking, a reference to that Booking is automatically added to the customer's list of bookings.
5. A multiple association is managed by an
6. A multiple association needs only a
7. Bi-directional associations (whether
singular or multiple) require the provision of
9. Adding a
The two principal mechanisms by which a user can invoke a business behaviour are by selecting an action from a pop-up menu on a business object and by dragging one object onto another. (The latter is not the same as dragging an object into an empty field inside an object.) It is also possible to invoke business behaviours at the class level - through the pop-up menu on that class - or by dragging an instance icon onto the class icon.
1. At the bottom of the pop-up menu for an object are the business methods that can be applied to that object.
2. An ellipsis ... following the menu action indicates that this will return another object as a new window.
3. Dragging Home, Boston directly onto Logan Airport, Boston will trigger the creation of a new Booking that uses those two locations as Pick Up and Drop Off respectively. This shortcut is most useful when both locations show up in a list of frequently-used locations inside a Customer.
4. The method name
6. This code swaps the pick-up and drop-off locations for the return booking.
7. If an action method requires an input
parameter (in this case another
8. This method, invoked when the user drops
one location onto on another, creates a new
9. If another object has invoked this
method then the newly created
Naked objects empower the user but that does not imply an absence
of controls. Different users will need access to different objects,
different fields within those objects and different behaviours on those
objects. It will also be necessary to enforce certain business rules,
such as preventing an action from being invoked unless the object is in
the right state. In Naked Objects these forms of control are
1. Here, the Confirm option is greyed out, but the user can Check Availability.
2. Check Availability resulted in the booking's status field changing to Available. Because of this the user now has the option to Confirm the booking.
3. The booking now has Confirmed status.
6. Availability may be determined by business rules or by user authorisation. The whole determination could be sub-contracted to an authorisation server.
8. Here, a reason is provided for the unavailability of the method. In the current version of the framework, this message shows up in the system log window. In a future release better use will be made of this capability, perhaps in the form of optional balloon help.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.