Naked Objects - The exploration phase

Naked Objects
By Richard Pawson and Robert Matthews

A development process

The exploration phase

The exploration phase has two main purposes: to explore business requirements and to explore object representations of the business domain. The naked objects approach is unique in making these two activities synergistic: exploring business requirements clearly helps you to identify candidate objects, but building an object model in concrete usable form also helps you explore business requirements.

Notice that we say 'explore' and not 'capture' business requirements. In our experience, the requirements specified by the user representatives after exploring the naked objects are very different from those that they would have specified, if asked to do so, at the start of the project - and also different from those they would have specified using more common forms of prototyping. The direct interaction with the object model seems to suggest new requirements and even new business possibilities. This is why a period of exploration must precede any form of specification of requirements.

Preparing for exploration

People often ask: 'How can you start a project without first having some idea of the scope of requirements, in order to make a first-level estimate of the overall project costs?' This line of thinking leads to many failed systems development projects. It is very difficult to get business sponsors and user representatives to specify up-front what it is that they require of a new system. This is not just - as some methodologies seem to assume - because the user has difficulty articulating the requirements; it is because the introduction of new technology into the business activity changes what is possible, but in ways that it is almost impossible to imagine in your head or on paper. Asking users to specify all their requirements for a system on paper, and to prioritize those requirements without having seen any of them implemented, or even simulated, just invites future problems.

Making the case for action

Using the Naked Objects approach, every project starts with a period of exploration, which is strictly time-boxed and which, once you have some experience of using the approach, can be fixed-price without needing to know anything about the application.

'Making the case for action' for a Naked Objects project should therefore mean making the case for undertaking an exploration phase. We recommend that you write this in a single paragraph or presentation slide that spells out the one most compelling reason for doing the exploration: a changing regulatory environment, a new line of business, a sudden and dramatic need for cost reduction, or simply a compelling vision of a new way of working. If you can't write a single paragraph (or slide) that is persuasive enough to justify a fixed-price four-week exploration exercise, then the project is probably not worthwhile.

Although this takes courage, it is more honest to refuse to make any estimate of overall implementation costs before the exploration phase has been undertaken, than to make a crude estimate and have to revise it by a factor of three, or ten, as the true requirements and complexity emerge. We are not the first to say this. However, one of the big advantages of the Naked Objects approach is that the customer gets a lot of value from the exploration: not just a specification, or feasibility study, or a set of static UML diagrams, but a working prototype that's fun to play with, and an object model that might also yield new insights into the business itself.

By the time you start the specification stage you will not only have a clearer idea of what's required and what's possible, but also of the costs involved in implementation. If necessary you can then write a more detailed justification for proceeding to the delivery phase.

Forming the exploration team

The exploration team includes systems developers and user representatives working closely together. Because the developers will be writing code and making modifications directly in front of the users, they need to be fluent with their tools: the Java programming language, the Naked Objects framework, and the chosen development environment. (Training developers by exploring a hypothetical business problem can be very effective, but we do not recommend going into a real business exploration phase until they have achieved some fluency with the tools).

The user representatives need to have a broad and deep understanding of their own business domain, and the trust of those they represent. Ideally they will be selected for their willingness to explore new ways of working, and will be confident and experienced users of information technology. And ideally, the group will include at least one person who is going to be an everyday user of the proposed system. Sometimes, the user representative will be an IT person such as an account manager, business analyst or consultant (sometimes known as 'subject-matter experts'). However, understand that the user representative is there to provide broad and deep business knowledge, and to represent the users, not to perform some kind of translation role between users and IT.

The exploration team also needs an experienced object modeller to lead all the modelling sessions. Some approaches to object design emphasize the idea of a 'facilitator': someone trained in group facilitation, who can ensure that everyone gets their say, that no ideas are rejected outright, that no-one dominates the group, and so forth. But object modelling is a design exercise, not a brainstorming exercise. It should be participatory design, certainly, so the lead object modeller does need reasonable interpersonal skills. But he or she can and should be willing to give immediate feedback on any suggestion: "Yes, that helps," "No, that's not an object" and so on.

A good rule of thumb is that the lead object modeller should be sufficiently competent and confident to do the whole object model alone. This does not imply that the team exercise is just a pretence. The team will undoubtedly make useful suggestions that the lead modeller might not have thought of. There are also certain modelling activities that the team will do better than an individual - some of which are described in the next chapter. Even in dynamic periods where the lead modeller is taking many of the design decisions directly, just forcing him or her to think aloud in front of the group and justify those decisions will probably improve the modelling, as well as the group's understanding. Finally, other members of the team can and will give instant feedback on some of those decisions by mentally applying them to their own needs and business scenarios. If handled correctly, each member of the team will feel that they have made a useful contribution and will have a strong sense of ownership of the resulting model, but they will not be under any illusions that design is a democratic process.

One more thing about the lead object modeller: in our opinion this person needs to have programming experience, and in an object-oriented language. This does not mean that lead object modellers write code themselves (although they may do so), but they need to be very familiar with object-oriented design patterns right down to the programming level. Naked objects bring out the synergy between object-oriented analysis and object-oriented programming in a way that few other approaches do. The programming experience does not even need to be in Java - the basic syntax of which is very easy to learn once you've programmed in another object-oriented language. It is our observation (and others') that many of the best object modellers learned their technique from programming in Smalltalk, not from any design methodology. If you learned Java well, that can be just as good, but unfortunately many institutions and authors still teach Java as though it was procedural language.

Other roles are also needed on the exploration team. Depending on the application, it may be appropriate to have someone who has a broad familiarity with existing systems to which the new system might be interfaced, particularly existing databases. The more you can make use of realistic data during the exploration phase, the more effective it will be. In the Safeway case study even the prototype had a simple form of persistence that allowed the exploration team to work with a large and realistic set of Product and Location objects. This was important, because the rationale for the project had to do with managing the complexity of large numbers of potentially conflicting price adjustments and/or special promotions. Using a very small data set would have made it hard to understand the issues.

The exploration team will have many responsibilities - documenting the model, capturing the test scenarios, designing icons, giving demonstrations - several of which are described in detail later. These responsibilities might or might not translate into specialized roles: different teams will evolve their own styles. You need to find the right balance between the power of collective ownership, as championed by Extreme Programming, and the efficiency of having specialized expertise available.

Advance preparation

Before the team starts to explore the chosen business domain, it is important that it establishes a common vision of what the resulting system will look like. For example, one of the principles of Extreme Programming (XP) is that of 'system metaphor': all members of the team should have in mind a common picture of the resulting system that can be used to inform design decisions. The metaphor of a spreadsheet is cited as an example in several XP books. Yet many XP practitioners report that they have had difficulty identifying a suitable metaphor, or that the metaphor has been of little value in resolving real design issues.

Naked objects are, in themselves, a very strong metaphor. Once someone has understood one system designed from naked objects, they have a very clear mental model that they can translate into a new domain. Thus we recommend that all members of the team should be introduced to examples of naked object systems before beginning to explore the new problem domain. Ideally this will include reading the case studies in this book and playing with the demonstrations that you can download from our website. If this is not practicable, then kick off the exploration phase with a set of demonstrations to the team as a whole.

A useful preparation exercise is to get team members to classify a collection of Lego pieces according to their 'versatility' (i.e. the number of different models you could use them in) and 'contribution' (how much value the piece adds to the model on average). The same analogy can be applied to business objects. In a Naked Objects exploration exercise we are seeking to identify only the objects that belong in the top right hand corner: those that the user would deploy in solving a wide range of problems and yet which still yield a lot of value through their behaviour. Classical task-oriented systems design tends to focus on the top left quadrant, whilst classical object-oriented programming focuses on the lower quadrants.

It is possible to extend the generic naked object metaphor into a variety of more specific forms. Metaphors that we have used on several projects include the caseworker, visual network management, the workbench, and the parts catalogue.

The other area where we have found that preparation pays dividends is the physical environment. Exploration workshops are intense activities - poor lighting, ventilation, or ambient noise levels add to the stress and reduce your effectiveness. Try to use a room with natural light, preferably on two sides of the room [Alexander1977]. Arrange the furniture so that all participants can see each other: an open U-shaped table is much better than a long thin boardroom-style table.

Plenty of whiteboards and/or places to stick up flipcharts are always useful, but make as much use as possible of electronic projection. You'll need it to do demonstrations of the evolving prototype, and it will enable multiple developers to view the evolving code structure. Where possible, we like to have two projectors and two screens, so that we can see both the developer and the user view of the system at the same time.

We also recommend that you try to capture the ideas arising from design sessions directly into electronic form. Unless the scribe has very neat writing, electronic capture improves legibility. It also means that the output can be instantly available to all participants as soon as the workshop is over. But the biggest reason is that electronic note capture with projection makes it easier to edit the notes, and particularly to restructure them as the discussion progresses. Our preference is to use a structured text outliner such as Word, although we have also seen a variety of the 'mind mapping' tools used this way. Either can be effective if the user is fluent with the tool.

Planning and scheduling

Exploration is an iterative exercise, with each iteration comprising three principal activities:

Defining objects and their responsibilities.
Building the objects into a prototype.
Using the prototype to explore business scenarios.

It is possible, even desirable, to plan the exploration phase as a fixed set of formal iterations, perhaps four of five of them, and schedule the three activities within each iteration. But there may also be many informal iterations, where all three activities might be undertaken by a single individual in the course of a few minutes and where the boundaries between the activities is unclear and unimportant.

In ideal circumstances, during the exploration phase the whole team will be working full-time on the project and will be physically co-located. With such a set-up and with developers experienced in the Naked Objects approach, two weeks can be a realistic time-box for exploration. There is little need for formal planning as the team can decide its priorities and working style day by day.

Such ideal circumstances seldom arise. It is often hard to get user representatives to commit full-time to any systems project. In our experience it is far more important to get the right user representatives, who will be mentally engaged even if they can't apply themselves full-time, than it is to insist on a full-time user representative and end up with someone who 'won't be missed' by the business. But then there needs to be a slightly more formal plan: the whole team meets formally every three days for three hours, perhaps. The sessions start with a rehearsed demonstration of completed scenarios, a review of the whole object model and then a discussion of new avenues to pursue or problems to resolve. In between these meetings, individual user representatives and developers meet to work on a particular aspect of the model and prototype, or to specify and test new scenarios.

With such an approach, four weeks is more realistic for the time-box. And if it's your first go at designing systems this way or if there are many different stakeholders to be involved, then allow a little longer. Note, however, that none of the projects described in this book had an exploration phase of more than six weeks. Don't be misled by claims that the problem domain is especially complex. Naked objects thrive on apparently complex problems! (Some proposed business applications appear to be dauntingly complex precisely because they don't fit into the process-oriented paradigm that most development methodologies assume.)

We shall now look at each of the three elements of an iteration.

Defining objects and their responsibilities

Exploration starts by going straight for the objects. Don't attempt to capture use-cases before looking for the key objects. Our aim is always to get a first, crude, iteration of the complete business object model by the end of the very first day of exploration.

You don't need any formal preparation or documented input before you start, as you will rely on knowledge inherent within the team. Spend a couple of hours just talking about the selected business domain: what happens, what's difficult, how things are changing. This is informal, unstructured and undocumented. Its purpose it to get people warmed up, comfortable with each other, and familiar with the domain.

Initial identification of objects

A long established technique for identifying candidate objects [Abbott1983] [Booch1994] is to write down a very informal description of the business domain and the desired contribution of the system, and then to underline all the noun phrases. Probably, during our informal discussion, we will have begun to do some mental underlining of noun phrases, but we have found it unnecessary to recognize this formally or to document any of the discussion.

So, after a couple of hours of discussion, the lead object modeller invites the whole team to start suggesting candidate objects, and captures these as a mind-map or structured text document. (If you decide to have a separate 'scribe', then that person and the lead object modeller should have pre-agreed the format, and carefully rehearsed the process of capturing and editing object ideas.) At this stage, the emphasis will be on getting lots of suggestions and maintaining a high level of energy. However, the lead object modeller should feel free to provide immediate feedback on suggestions, and add several of his or her own.

This example, drawn from an exploration exercise undertaken by a North American electrical utility illustates how the object model may evolve rapidly in the first few hours.

The first cut of the object model featured a Network object connecting Generators to Households, Businesses and Industries. A separate demand-forecasting system balances the loads:

The team quickly realized that distributing responsibility for demand forecasting to each consumer - in the form of an active Power Profile object - would improve business agility. And by placing the responsibility for the delivery of electricity in a Contract object rather than the Network, the company could more easily sell electricity outside its principal territory.

We have never yet seen a group that didn't enter into this initial task of suggesting objects with enthusiasm and effectiveness. One hour is usually quite sufficient to generate a good list of candidates - typically between 20 and 40.

Shortening the list

After a short break, start to refine this list. The clearly stated aim is to cut the list down to between five and ten 'core' business objects. One reason for this is the oft-quoted principle about the number of peer-level ideas that people can keep in their heads at one time. The Naked Objects framework encourages this stance because, at least for the prototype, all the core business object classes will appear in the classes window on the screen, and ten is about the visual limit before the screen looks overwhelmingly complex. The simple act of forcing the list to be cut down will also encourage more abstraction in the modelling.

To shorten the list, you can run through a series of simple tests, either casually or formally:

Is it an instantiable class? Does this candidate class represent a type of business entity of which there are several instances? The concreteness of naked objects can make this easier to see. Ask the team: Would there ever be two or more of this type of object shown on the screen at once? Would the user ever say (pointing at the screen): 'Not that one, that one!' If so then you have an instantiable entity class and it can move forward. Another test is simply to ask how each instance is uniquely identified: in Naked Objects terms, what is the object's title? If a candidate fails these tests, then you may have a function that should perhaps appear as a method on one of the other objects. A simple rule of thumb is that you should be cautious of any candidate object that ends in 'er' or 'or'. InterestRateCalculator is probably not an instantiable class, whereas InterestRate could be. (Like any rule of thumb, there are exceptions - Customer, for example!)

Can you think of an icon for it? We insist that for all object candidates taken forward from the very first modelling session, the team agrees on an icon that will represent an object of this class. Icons are needed for the prototype simply in order to distinguish the different types of object. Discussing icons from the outset also focuses the team on the concrete nature of objects. Disagreement over suggested icons sometimes reveals a fundamental difference in understanding of the object's definition. If the project progresses to the delivery phase then it is important to draw up a good set of icons that will be acceptable to a broad set of users. The icons must be both individually aesthetically pleasing, and together form a visually coherent set. But during exploration there is no need to be so rigorous, and it is often expedient to use icons from standard libraries. (The Naked Objects distribution includes a modest library of icons suitable for use in exploration.)

There is a lot of talk about the need for icons to be 'intuitive'. They certainly need to be visually distinctive, so that no user would easily confuse one for another. And they need to be 'associative', so that once people have been told which icon stands for which type of business object they can easily memorize that association. But there is no need for users to be able to work out what an icon stands for without being told, and research shows that this goal is almost impossible to achieve anyway.

Are there any obvious synonyms? It is likely, given the way that the list was generated, that there will be candidates that are either identical or strongly overlapping. (Case and Claim were early examples in the DSFA exploration.) The differences may be subtle. The best strategy is to try to blend one into the other. Even when the two suggestions came from different members of the team, we have found that they are usually willing to accept the tentative merger, provided that a note is kept of the original distinction. Using an electronic outliner to drag notes around helps considerably here. It may subsequently prove necessary to split the composite object again, although more than likely you will find that the split occurs along different lines.

"Carve the problem at its natural joints" is the goal of most object modellers. The principle is hardly new: in Plato's Phaedrus Socrates advises that one should observe the natural articulation of a problem, "not mangling any of the parts like an unskillful butcher". But this is much easier said than done.

Consider the diagrams showing the different standards for jointing a carcass of beef in France, England and the United States. Why there should there be such differences in the three standards, when all have a common goal to maximize the total revenue from the carcass? One explanation is cuisine. Think of France and you think of casseroles; the English traditionally love their roasts; whilst Americans favour grilling. The three different standards reflect this preference somewhat.

Cuisine is changing, however. Few British families regularly sit down to a traditional roast lunch, and even the French are becoming less willing to spend several hours a day cooking. Increased affluence has created demand for more 'exotic' cuts. A further complication is that the industry structure has changed: most of the actual carving has shifted from the local butcher's shop to central meat-processing facilities. This provides greater economies of scale but has tended to reduce flexibility: the customer must choose from a range of pre-packaged joints instead of being able to ask the butcher for a particular cut or weight.

One major British supermarket chain has adopted an entirely new 'architecture' based on 10 larger constructs known as 'primals'. Carcasses are delivered to supermarkets already carved into the 10 primals, and the local meat manager decides how best to further sub-divide each primal. Thus, the new architecture not only addresses the fact that conditions have changed, but that they will continue to change. Can these supermarkets be said to have found the 'natural' joints? We doubt they would claim that the new system is perfect, but it is interesting to note that the primals follow the muscle groups of the carcass more closely than previous standards.

This is a good metaphor for business. The 'joints' of a business are reflected in its organizational boundaries (internal and external), product and service definitions, channel strategies and individual roles. Increasing competition and changing conditions of supply and demand have required new concepts that cut across those joints. Approaches such as business reengineering have left organizations better optimized to the conditions of the day, but no more able to respond to further changes.

In a Naked Objects project, the aim is the business objects should represent the 'primals' or muscle groups of the business, not the particular organising structure or product/service definitions of the day.

For example one reinsurance company that was implementing a new set of underwriting systems initially based its object representation on the industry-standard concepts of 'treaty' and 'facultative' business - the two main kinds of re-insurance underwriting, which were also reflected in its organizational structure. As the project progressed, the specification of the two elemental constructs was modified, and they were renamed as 'portfolio' and 'individual risk' - which that company saw as the more natural joints. These two new concepts could easily be mapped onto the treaty and facultative divisions in the business for the purpose of continuity, but the new representation opened up the possibility of constructing new hybrid insurance products in future. In other words, the criterion for judging the quality of the object representation was not the fitness for an immediate purpose, but the range of future situations that can be expressed using that representation.

There is no effective formula for finding the natural joints, despite the best efforts of many researchers to find one. The only way to achieve it is to keep merging related object candidates, then cleaving them along different lines to see what possibilities emerge. That most object representations fail to find the natural joints is largely because the designers do not believe in the value of the discipline.

Do a group of candidates share common behaviours? Several candidates may not be synonyms, but they may share common behaviours. If so, you can make use of abstract types. CheckingAccount and SavingsAccount are both types of BankAccount, for example. To cut the list down you may focus initially on defining Bank Account, only later dealing with the more specific implementations of that type.

A note of caution: try to avoid getting caught in the tar pit of discussions on inheritance hierarchies. Java distinguishes between 'inheritance', where one class actually inherits the means to fulfil a responsibility from its super-class, and 'interface implementation' where one class merely has the same type, meaning the same external interface, as another. The latter is a powerful construct, and in the context of a business object modelling session, is actually more powerful than the concept of inheritance. Again Naked Objects makes this more obvious: if class A and class B implement the same abstract interface, that means that anywhere you can drop an instance of class A you can also, by default, drop an instance of class B. Thus we may initially think about an Order being associated with a Customer, and then realize that the Order might be from an Agent or a Distributor. All we need to do is define an abstract interface such as TradingParty and ensure that Customer, Agent and Distributor all implement that interface. They may well implement other common interfaces such as Communicable, meaning that we know we can call upon any of them to provide a communication address.

Households, Businesses and Industries are all consumers of electricity. Consumers and Generators are both forms of trading Party. However, it would probably be better to implement this commonality as shared interfaces than as an inheritance hierarchy.

Implementing the trading Party interface would allow Consumers and Generators to be used interchangeable in certain contexts. By allowing the Power Profile to handle positive and negative demand, hybrid Generator/Consumers would become possible - something that electrical deregulation will encourage.

This helps us to avoid getting stuck on questions such as whether Customer is a sub-class of Party, or of LegalEntity; and Employee a sub-class of Party, or of Resource? We make very little use of this highly abstract form of inheritance. Our rule of thumb is that we only use inheritance when the users themselves would wholeheartedly support the statement that 'X is a specialized form of Y'. If the user merely says 'X seems to share something in common with Y' then we use interfaces.

Is one candidate just a component of another? Something may be a clear candidate for an object (it is instantiable, has real responsibilities, and no overlap with other objects) but it solely exists within the context of another object. The technical term is 'aggregation'. A good example is the relationship between Order and OrderLine. There is good reason to make OrderLine an object: it has real responsibilities such as checking stock levels and applying VAT. Making it an instantiable class makes it easy to add a new OrderLine to an Order (again Naked Objects makes it easy to visualize this concept). But an OrderLine need never exist outside the context of an Order. OrderLine is an important object, but it is not one of our top-level objects.

Aggregation should not be confused with association. A Customer object may contain references to multiple Bookings, but those bookings are not aggregated into the Customer: they exist in their own right.

A simpler example of aggregation would be that a Product object might have a UPC (Universal Product Code). Good modellers will point out that it is better to model the UPC as an object than as, say, a text string, because that would allow the UPC to be able to print out a barcode, look itself up against a database and so forth. Good points all, but the UPC is very much a secondary object that can be addressed later on in the process: it should not make it onto the list of five to ten core business objects. Just keep a note of it within the appropriate responsibility for the Product object.

Is this object a possible start point for a user activity? Objects that could form the start-point for a business scenario are more worthy of the term 'core' business object than those that don't. In our limousine-booking example we could certainly make the case that an operational business scenario might start with a new or existing Booking object, a Customer object, a City, or a specific Location. It would be much less likely to start with a CreditCard, but if we see CreditCard as implementing the more abstract type of PaymentMethod, which would also be extended to cover CompanyAccount, then PaymentMethod could easily form a start point of a scenario.

So, at the end of the first day of the exploration phase, you will aim to have a list of between five and ten core business object classes, each of which will be of key interest to the users and could potentially form the start point for some sort of business scenario. For some of these, specialized sub-classes may already have been identified. Some of them will also have what we call 'secondary' or 'aggregated' classes. You may also have identified some needs for common abstract interfaces that would allow different classes to be used interchangeably in certain contexts (i.e. you could drag either of them into the same field).

We usually find that during the first day we can make a useful start on defining and refining object responsibilities. In fact, doing so will typically either reinforce or challenge our initial choice of the core business objects. You may well find, for example, that two classes of objects appear to be sharing many of the same responsibilities and ought to be merged. Or you may find yourselves having to specify a responsibility for an object that doesn't seem to fit naturally with its name - a good indication that you should consider splitting that role into two.

Object responsibilities can conveniently be split into two categories: know-what and know-how-to.

Adding know-what responsibilities

Know-what responsibilities cover the attributes (simple values such as names, dates, and prices) and associations to other business objects.

Strictly speaking, we are referring only to those attributes and associations that are deliberately intended to be accessible from outside the object. Naked Objects helps to make this clear because anything with a public 'get' method is, by default, going to be displayed to the users when they open a view of that object. In fact, as Wirfs-Brock points out [Wirfs-Brock1989] these are attributes and associations that the object knows-how-to deliver to an external user, and/or allow the external user to specify or modify. So in fact all the responsibilities are really know-how-to's. The value of preserving the somewhat artificial distinction between the two types of responsibility is that it potentially encourages the modellers to push for richer behaviours.

In theory, it would be better to start by specifying those richer 'know-how-to' responsibilities: they are more in keeping with our goal of behavioural completeness. In practice, we have found that all but the most experienced object modellers find this hard to do. Allowing the team to give a candidate object a little more substance, in the form of some attributes and associations, can help to keep things moving along.

To identify the association responsibilities, ask the team: 'If you opened up one of these objects, what other objects would you expect to be able to get to directly from that object?' A common mistake by inexperienced object modellers is to include an attribute from another object instead of the object itself. Thus, they specify that an Order 'knows the name and address of the customer', when it should be 'knows the Customer' (which in turn, knows how to communicate). Encouraging the team to specify associations before simple attributes helps to avoid this mistake. It gets them used to thinking about navigating to things they can find out from an Order rather than being part of an Order.

For each association, ask also whether the association needs to be bi-directional or not. If a Booking needs to have an associated Customer, do you also want to be able to get directly to the Booking from the Customer object? Sometimes you won't see the need for this until you start walking through some business scenarios. If one object is aggregated into another then there is no need to do this: an OrderLine does not need to explicitly hold a reference to the Order it belongs to because it can never be accessed except through that Order. Bear in mind also that whilst it may be tempting to make all other associations navigable in both directions, it does incur some overhead in terms of both development effort and performance (because of database implications), so don't specify it without reason.

Turning to the simple data attributes, try to keep these to a minimum as long as possible. There is a great temptation to start listing lots of simple 'low-value' attributes, just because they are easy to think of: name, address, sex, date of birth, hair colour etc. These attributes seldom add much value, and they distract the team from concentrating on the higher-value responsibilities.

We recommend that, for the first iteration at least, you keep the basic attributes to the minimum necessary to identify the object uniquely and conveniently. A good rule of thumb for a Naked Objects implementation is this: add only those attributes that you need to use in the title method. Add other attributes as you need them to fulfil your operational test scenarios - but only after seriously questioning whether that attribute might not better be replaced by a know-how-to responsibility.

Adding know-how-to responsibilities

People find know-how-to responsibilities harder to conceive. You'll probably start with just a few simple ones, and then add some more as you consider business scenarios. One way to get started is to familiarize yourself with other examples. The DSFA's business object model would be a good starting point.

A useful technique is to look at each of your know-what responsibilities (i.e. the associations and attributes) and ask yourself if it could be better stated as a know-how-to responsibility. Some examples are shown in the panel.

Attempts to specify object responsibilities usually start with what an object needs to know. It is good discipline to cross these out and ask what it is the object should be able to do with that knowledge.

It can sometimes be valuable to take this principle to extremes. For example, on one occasion we challenged a public sector organization about why their Customer object definition included the date of birth as a know-what. The audience was incredulous. Date of birth was needed for lots of purposes, they said: for identification (have we got the right Fred Smith?), for authentication (is the person on the end of the phone who he says he is?), for determining if a client is an adult or not. We argued that each of those uses should have been modelled as explicit know-how-to responsibilities. It may be that the object uses a stored date of birth for these purposes, or it may not (the object might delegate the responsibility to an external agency). In fact, it is bad practice to base identification and authentication on the same data. Moreover, if they design the Customer object to be able to answer the question 'Is [the customer] over 18?' rather than 'What is [the customer's] date of birth?' then they are not leaving themselves vulnerable to charges of misuse of age information. (Anyone who thinks that is a spurious line of argument should read the European electronic privacy legislation.)

Avoid the temptation to fill up the page with responsibilities that are automatically provided by the framework. There is no need, for example, to specify for each attribute and association a corresponding know-how-to responsibility for reading and/or writing it - that should be assumed. The only reason you should specify that the Booking object 'knows how to choose a Seat [on the Flight]' is if it is the Booking object itself that will do the selection rather than, say, the user.

Similarly there is no need to specify the responsibility for the object to make itself persistent, or to manage authorization and security, distribution or version control. These are generic capabilities provided by the infrastructure and are presumed to apply to all classes of business object.

You can also omit the generic class responsibilities. All naked object classes automatically provide the generic class responsibilities (unless the programmer suppresses them):

Create a new instance of that class.
Retrieve a particular instance by its unique reference.
List all instances that match a set of criteria.
List sub-classes.

You can add class responsibilities specific to a business class - for example to create a particular kind of report on instances of that class - but the need for these is more likely to emerge later in the exploration phase.

Dealing with the concept of process

We have already made clear that we do not agree with the practice of translating use-cases into objects in their own right, nor of the split in roles between Entity or Model objects, and Controller objects. Using Naked Objects, only the former category of objects is permitted. To put it another way, all classes of business object should be thought of as persistent classes.

That said, it is quite legitimate to think about different broad categories, or stereotypes [Wirfs-Brock'Characterizing your objects'] [Coad1999] of business object. In particular, we often draw the distinction between purposeful and non-purposeful objects. Non-purposeful objects are things like Product, Customer, Employee, and Location. The state of those objects will change over time, and that state will be made persistent, but the changes don't go in any particular direction. They can be thought of as random.

The state of a purposeful object generally changes in a pre-ordained direction. Thus, an Order may go from the status of an Enquiry, to Committed, to Shipped, to Invoiced. The status may occasionally backtrack, or the Order may be terminated prematurely; but there is a clear intended direction. In general, whereas the state of a non-purposeful object is just the agglomeration of its various attributes and associations, a purposeful object is more likely to have an explicit state, represented by a single field that can take one of a finite set of pre-determined values. It is also often appropriate to model the behaviour of purposeful objects using state-transition diagrams, which specify the conditions under which the object will move from one of those pre-determined states to another. Indeed some people describe such objects as 'stateful' rather than purposeful.

So isn't a purposeful object just a process object, or a Controller, by another name? There is an important difference. In our approach both non-purposeful and purposeful objects are Entity objects. They are all made persistent by default. They continue to exist as objects even when they have reached their intended end-state. This is not a unique idea. We have had many conversations with experienced object modellers and well known authors who have reached the same conclusion: that Transfer, Withdrawal, and Deposit (in a banking application) are not use-cases or Controller objects, but persistent Entities in their own right. But that is not the way that the bulk of the object literature treats them.

Naked objects make the advantage of this way of thinking clearer. In most approaches to object modelling, once a transaction, process or use-case is completed, there is no way of referring to it explicitly. In an application developed using Naked Objects, these activities show up as icons in their own right: you can open them and inspect them, and invoke whatever valid actions remain available. Thus, even after a (bank) Transfer has been made, you could examine it, decide to reverse it, charge a fee for it, or notify the customer of its successful completion - all potential action methods.

Any business activity where the verb describing the activity can easily be mutated into a noun is a prime candidate for a purposeful object. Thus the users might have a requirement to adjust (verb) the prices. But they will also talk readily about 'making price adjustments'. This is a cue for thinking about PriceAdjustment as an instantiable entity object, rendered as an icon on the screen by the Naked Objects' viewing mechanism. Another good clue, as others have pointed out, is that verbs that can easily be modified into nouns are often embodied in paper forms in a manual system.

Building the objects into a prototype

The second of the three core activities during exploration is building the objects into a prototype. Your aim should be to get your object ideas implemented in the Naked Objects framework as quickly as possible, to help the team to visualize the attributes, associations and (most importantly) the behaviours of the objects.

For each of the business objects that you have identified, you will need to:

Define a NakedObject class.
Add one or more value fields that can be used to identify each instance of that class (e.g. a name or reference field).
Specify the most obvious associations between the new business object and any other types of business objects already specified.
Write a title method that will identify an object instance to the user.
Add the new class to the set of classes in a test application.
Specify two icons (one large and one small) to be associated with that class.

Once this is done for each of the identified classes then you can start the framework and use the application. This will provide immediate feedback, allowing you to confirm or question your design decisions, and indicating further possibilities. The next step is to enrich the application, for example by:

Adding further fields containing value objects or associated business objects.
Considering whether each field should be read-only or allow updates and deletes.
Adding object methods and perhaps additional class methods.
Adding about methods to control access to individual, classes, fields and methods based on business rules or user authorisation level.

Sometimes the prototyping takes place 'off-line'. Translating the initial list of candidate objects (produced on the first day) into a working prototype may take several hours of programming. The same may apply when, in subsequent iterations, new business object classes or responsibilities are identified, or there is a significant re-factoring of the object model, or reassignment of responsibilities.

However, many changes suggested by the team - a new sub-type, attribute, association or simple method - can be programmed in minutes, and Naked Objects makes these changes instantly visible to the user. It follows that it makes sense to try to make as many of these changes as possible in real time. Often we have observed programmers saying to the users: 'This will probably take a few minutes: you can come back later if you like', only to hear a user respond: 'I'll stay - I'm enjoying this!' The net result is that it is often possible to get through ten or twenty iterations with the users in a single day.

One of the reasons for prototyping in real time is that it encourages the team as a whole to explore more than one approach to a business issue. Object modelling exercises can often get bogged down in debates about two different ways to represent a problem domain [Riel1996]. With Naked Objects, much of this debate can be eliminated simply by offering to prototype both approaches and then showing them to users on the screen. When confronted with the two models as tangible icons that can be dragged and dropped, right-clicked and opened to view their contents, it is surprising how quickly the superior modelling solution - if there is one - becomes obvious.

Using the prototype to explore business scenarios

The third core activity of exploration is using the prototype to explore business scenarios. During each iteration, formal or informal, the evolving prototype should be tested against business scenarios. There are two main types of scenario, operational and what-if.

By envisioning the core business objects at the user interface, the electrical utility saw the possibility for creating new communities of Consumers that had common (or complementary) Power Profiles - literally by dragging and dropping icons on the screen. These communities could be offered special billing rates, or be sold to other power companies.

Operational scenarios

Operational scenarios are specific envisaged uses of the system. They cover both frequently-occurring tasks and one-off usages, such as: 'Mary Cahill has three children under 16 of which the younger two are twins, but one is living with Mary's mother. Work out how much Child Benefit is owing' or 'We have a 15% discount on all beer, wines and spirits in our hypermarket stores, and a "1.00 off" promotional offer on Australian wines in all stores. Resolve any arising conflict in prices.' Applying a range of these ad hoc scenarios is a much better way to test the power of the emerging object model than just emphasizing the oft-repeated tasks.

Operational scenarios should always be specified in concrete terms. This prevents the users from asking for impossible functionality. For example, consider a user requirement or story along the lines of 'the system should be able to identify and resolve conflicting price adjustments that arise from different sources.' The criteria for identifying conflicts may be straightforward (e.g. two adjustments for different amounts applied to the same product with overlapping time periods), but resolving that conflict may not be. Forcing the user to write one or more concrete test cases each giving an example of a conflict and specifying exactly how that particular conflict is to be resolved will either clarify the algorithm or persuade the user that the conflict can only be resolved by a human.

An operational scenario may well highlight the need for new object classes, sub-classes, or new methods and associations. Some of these will be prototyped during exploration - others may simply be flagged for consideration in the Specification phase. In such cases it is often appropriate to add, say, new method names to an object, so that they will show up as actions on the user's pop-up menu, but without necessarily writing any of the code necessary to implement that method.

Operational scenarios should be documented, because they will form a useful set of prompts during the specification phase. Those that are carried forward into the specification of a particular phase will be codified more formally as one or more executable user acceptance tests (explained in the Delivery section). Once you become fluent with the Naked Objects approach you may decide to capture the operational scenarios in this form right from the beginning - but it is not essential.

Demonstrations

Operational scenarios are useful as demonstration scripts. Throughout exploration, the rule is to demonstrate early and demonstrate often. These demonstrations may be within the team, to bring everyone up to speed on the latest version of the business objects model; or they may be outside the exploration team to test a particular idea or to help build political support. Because systems built from naked objects 'feel' very different from conventional systems, we have found that the first such project in an organization gains a lot of attention, with frequent demands for demonstrations even from those not involved in that business domain. You need to be ready to demonstrate the evolving prototype at the drop of a hat, and we have often charged a particular member of the team with being the demonstration specialist (though this can be combined with other roles or responsibilities). In some cases we have even dedicated a single machine for demonstrations, updating the demonstration at the end of every day when all the various modifications have been integrated.

You need to devise a 'general tour' demonstration that shows roughly what each of the objects knows and knows how to do. The rest of the demonstrations will typically be based on the operational test scenarios. Here again, the concrete nature of the scenarios helps. It saves the demonstrator from having to think up realistic example data on the fly. (Using unrealistic data in a demonstration is far more confusing to the observers than most people realize - most non-programmers don't naturally identify with customers or products called Foo and Bar!)

Paradoxically, although one of the motivations for providing the users with access to the naked objects is to provide them with more choice in how to tackle a particular problem, we recommend that demonstrations are very tightly scripted. Continually interrupting a demonstration of a test case with comments such as 'of course, I could have done that last bit this way, instead' is very confusing. Only do this if your observer asks about the possibility, or suggests that the way you just did something is counter-intuitive to him, or sub-optimal in some way. Another approach is to select a range of demonstration scripts to show problems being tackled in a variety of different ways, or from different start points.

What-if scenarios

What-if scenarios test the object model against future changes to the business. Such changes might arise from new technological capabilities such as smart cards, new generation mobile phones, or digital signatures. They might be driven by new government legislation, industry regulations, or internal rules and policies. Or they might reflect changes in the relationship with suppliers and partners, and in particular with customers. The panel shows a few real-life examples of such scenarios.

Some example what-if scenarios generated during exploration sessions:

The idea is not to ensure that the object model can cope with all these hypothetical what-if scenarios without modification, but to ensure that the required modifications would be easy to identify and are localized to one or perhaps two object classes, instead of being scattered across the whole system.

To be more specific, the aim of what-if scenario testing is not to ensure that you have specified all the responsibilities that will ever be needed of an object: new responsibilities will be added throughout the life of the system. The aim of what-if scenario testing is to ensure that you have got the boundaries between the objects right. In other words, that you have carved the problem at its natural joints.

The outputs from exploration

The primary deliverable from the exploration phase is the working prototype. Because Naked Objects renders the core business objects and their principal behaviours visible and accessible to the users, the prototype is itself the best documentation of the business object model. The one-to-one correspondence between what the user sees on the screen and the underlying Java class definitions eliminates the need for much of the documentation generated by conventional approaches. This is one reason why participants find exploration so enjoyable and rewarding. By contrast, most of the documentation produced in the early phases of conventional approaches is actually counter-productive: it is difficult to write, unrewarding to read, and very hard to keep in synchronization as the project evolves.

As well as the prototype, you must document the high-level responsibilities of the business object classes. Whilst some of these responsibilities will translate directly into visible attributes, associations and action methods, some do not translate so directly. Some responsibilities will have been identified but not simulated on the prototype. And some responsibilities are there to guide future development direction (a typical example is the required responsibility on a Customer object of 'being able to communicate [with the customer] using their preferred channel' - even though the prototype, and perhaps the first delivered implementation, will handle only post and telephone).

These responsibilities should be captured in a form that is easily readable. The DSFA's business object model provides a good example of such documentation. Another approach is to use XML to document the objects and their responsibilities, with specific tags for Class names, Methods and so forth. This would aid the subsequent production of an electronically navigable document.

The challenge is to keep this documentation in synchronization with the system itself as it evolves. There are sophisticated and expensive tools available for this purpose, but our preferred approach is to use the Java code as its own documentation. Write the high level responsibilities in the form of comment statements at the top of the code file for each class definition. If a responsibility is completely and obviously fulfilled by a specific method (such as the responsibility for the Customer object to know the Bookings made by that customer) then the description of the responsibility can be deleted - it is redundant. If a responsibility has not been implemented in code, or spans multiple methods, or is more abstract than the current implementation (as in our communications channel example above) then the responsibility definition should be kept in as a plain text comment.

Embedding these responsibility definitions in the code does not guarantee that they are consistent with the code, but makes it much more likely. Furthermore, you can use a tool such as JavaDoc to auto-generate some well-formatted and electronically-navigable documentation direct from the code, including both the high-level responsibility statements and the existing business-level methods. This is a very effective solution.

What about UML?

Readers may ask why we appear to make so little use of the Unified Modeling Language (UML) in this book, when its notation is now accepted as the standard way to document an object model.

Capturing your business object model directly as naked object definitions renders much of the object relationships immediately visible to the users: open any object and you can see the types of objects that it relates to. We have found this to be far more accessible to users than a UML class diagram. And of course the naked object representation is executable.

Admittedly, UML is much richer than the Naked Objects framework in its ability to specify different forms and constraints on relationships. UML also provides the ability to view sequence diagrams, state transition diagrams and many other useful forms. But many people do not make use of all these representations, and unless you have a sophisticated tool set, keeping them all in synchronization can be a nightmare.

A further argument for using UML, and the related Object Constraint Language (OCL) is that they are programming language-neutral. Naked Objects is written in Java 1.1. It is upwards compatible with Java 1.2, 1.3 or 1.4 - but it doesn't use any of the new features. This is a conscious choice. Using the latest features would have made our task of writing the framework easier. But Java 1.1 is highly portable: there are implementations for a huge range of hardware platforms from Palm Pilots to mainframes. Moreover, Java 1.1 is to all intents and purposes now a public standard: there are open source compilers available and even open-source Java Virtual Machines. In other words, the Java used to specify a Naked Objects application is just about as open as UML.

Specifying business rules, relationships and constraints directly into a well established, simple, and open-standard programming language, instead of some form of pseudo-code, has other advantages. It encourages a closer correspondence between object modelling and object-oriented programming, which we believe to be a good thing. For example, we have found that many of the object-oriented patterns widely considered to be good practice by experienced programmers (for example [Gamma1995]) are highly applicable at the level of business object modelling. See for example the use of the Strategy pattern in the 'Case study: Arrears and collections' - this pattern in the business object model corresponds directly to the same pattern in the code.

One thing that may change our view on UML is the recent emergence of tools (such as TogetherJ) that can translate UML diagrams automatically into Java code structures and back again. This not only saves time, but more importantly ensures that the two remain in synchronization.

At the OT2002 conference, we ran a workshop in which delegates had just two and a half hours to design an object model for a conference administration system and then build it into a working Naked Objects prototype. All four of the four-person teams were successful, and everyone was surprised by what they had achieved. One team chose to start by drawing UML diagrams on a flip chart, but their resulting prototype was poorer than the two teams who had represented their ideas directly into Naked Objects. The fourth team drew UML diagrams on TogetherJ and auto-generated the initial Java class definitions from these, ready for use by our framework. Many of the subsequent enhancements were made directly in the code, but the UML diagram was kept up to date by the tool. Theirs was in fact the most impressive of the prototypes, and is shown in the screenshots on this page.

This UML diagram models a simple conference-management application.

Using the TogetherJ tool the UML shown opposite was automatically converted into this Naked Objects prototype. (Thanks to Dan Haywood for supplying the screen captures.)

Such tools change the nature of UML. In effect, the UML now becomes an alternative view of the code - one that hides complexity and renders things like relationships more visible. We like that idea. Don't think about modelling and programming as two distinct activities: they are two different views of the same thing. Another useful move in this direction is the recent research work on UML virtual machines. As this idea progresses we see potentially more synergy between UML and Naked Objects.

Indeed, we have already made it clear that the user screenshots shown throughout this book are the output from just one of many possible viewing mechanisms. It is conceivable that another such viewing mechanism would be a UML diagram. Perhaps someone will be inspired to write one ...

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.