Analysis and Design Briefing

Normally the course Object-Oriented Design and Programming using C++ (or Java, C# or Smalltalk) is a follow-up to the Object-Oriented Analysis and Design course. For mixed C++, etc. courses where there are participants who have not followed the analysis and design course alongside participants who have, we have prepared these notes to brief those participants who have not been on the analysis and design course.

People going on the five-day intensive course might also benefit from reading this although the material will be covered.

The Themes of Object-Orientation

We established some crucial characteristics of an object.

• It is an inversion of typical earlier approaches. Rather than units of code being "in charge", invoking each other and managing the data, we put encapsulated and secretive data structures in charge, they send messages to other data structures, and it's the data structures that manage the code.
• Objects are encapsulated and information hiding.
• Objects don't tell other objects what to do (i.e. objects don't use sub-routine calls); objects indicate their needs with messages to other objects, but it's the objects receiving the messages who figure out what method code to run in order to answer the message.
• If at all possible, for maximum flexibility, we would like late binding. The determination of what method to run is made by the receiving object, at run-time, based on its actual class. We don't have to tie the recipient down to a single class in order that the compiler can make the determination.
• We would like some degree of conformance control however. We don't want to give up and leave it that it could be any object of any class at run time. We would like some confidence that the object which turns out to receive the message will belong to a class that has a response to that message.
• The class system is only part of the solution. Another very important part is the type system.
• Inheritance is not the instant magic bullet for increasing reuse. In fact inheritance is very difficult to get right. In fact you can have a perfectly decent OO solution involving no implementation inheritance whatsoever.
(Notice that caveat, however; in object-oriented C++ interface inheritance is unavoidable.)

The Development Stages

We planned some stages to get us from the original need to the technology of the day.

• We capture requirements. Each requirement makes a distinct statement about a required and observable (boundary crossing) characteristic of the system-to-be. Each requirement would still stand if the implementation technology were radically altered. These "atomic" or irreducible requirements may be brought to life for readers via use cases.
• We analyze the subject matter. The first purpose is to uncover a structure so that we can base the structure of the solution upon it. The second purpose is to ensure we understand the subject matter and to convey that understanding.
• We start the invention of the new system. We begin by extracting from our analysis ideas for objects and ideas for those characteristics of the objects-to-be that are likely to most closely match their subject counterparts -- existence, state and conformance.
• We complete the invention of the new system. We move on to the characteristics where objects bear less resemblance to their subject matter counterparts -- service interface, messages, methods, variables and, eventually, inheritance.

The Case Study

Our case study concerns a small restaurant.

You have decided to retire from full-time software engineering and are going to open a small restaurant. You're still interested in object-oriented programming however, and are planning to write a Smalltalk application, to run on a Mac, that will help administer the restaurant.

You have realized that initially the system can help with booking, printing the menu and the inventory.

You expect to interface to some standard accounting packages and do not anticipate developing the sales, purchase or financial accounting yourself.

You anticipate using the system in the kitchen to help the chef with scheduling but you're not yet sure if that is likely to be successful.

With the increasing availability of hand-held radio-linked terminals you anticipate being able to handle order entry as well, at some point in the future.

We analyzed the subject matter and applied some object criteria and derived this first design (using the Unified Modelling Language):

(This is a very superficial sketch. The design was eventually a much improved version of this, but that's another course (or book).)

We then carried out some CRC sessions (Class, Responsibility and Collaboration) and discovered the following interaction pattern for one of the key use cases:

(Again, there were improvements to the above.)

In the light of these discoveries the first cut design was modified to this:

So this is the situation we will be starting to implement, in C++ (or whatever), during part 1 of the design and programming course. Don't assume the above is correct. There is plenty of scope for improvement.

If any questions occur to you, do write them down and ask the lecturer during a break on the course.

The Unified modelling language

A full guide to the UML can be found at http://www.johndeacon.net/UML. Basically the rectangles in the type-relationship diagrams are types -- service provisions soon to be implemented with classes. The lines between the types indicate linkages which we suspect the implementing classes' objects will have to possess. The arrows indicate the direction in which the links will be used (message passing direction).

The diamond, rather confusingly, is not an elaborated arrowhead; indeed the arrow, if you drew it would be at the other end. Think of the diamond as a symbolic indication when the role name of the relationship would have been "has"; i.e. the diamond is placed next to a composite object, and we expect the composite object to send messages to its component objects. (There's much more to the relationships than this; but, once again, that's another course.)

In the "ladder" diagram, the vertical rails represent objects (not classes), and the horizontal rungs the messages they send to each other during an example scenario. Time runs down the page.

[ Briefings Home Page | Training Courses from John Deacon | Books by John Deacon | JDL Home Page ]