Click above to get retro games delivered to your door ever month!

  
  When you have to produce an application or set of applications
  for your customer or organisation, you're concerned with what
  the applications have to do.  This is why requirements
  specifications exist.  Having a good requirements spec. should
  help you a lot.  Not having one at all means you either "know"
  what's wanted (effectively an unwritten spec.) or you and your
  customer are taking a risk - possibly a big risk.
  
  The problem domain is the scope of the system you're trying to
  produce.  You're looking for classes within the boundaries of
  this system.  Part of your work is to understand and define
  the interfaces between the classes and the interfaces with
  what's outside your system.
  
  The focus of OOA is modelling your problem domain, whereas OOD
  is about picking mechanisms and abstractions to make your
  model work.  As usual, software development involves various
  choices and trade-offs, so you shouldn't be surprised if you
  identify more than one way of modelling your system or more
  than one way of implementing it.  There are guidelines below
  to help you make useful choices, for example to help you
  understand what makes a good class.
  
  You can reach a point where you've considered everything
  (including present and likely future requirements), but still
  have a choice.  If so, just pick: you're unlikely to be badly
  wrong unless the system requirements change substantially -
  and there's not a lot you can do about that.
  
  Some people like to do OOA / OOD in a sort of "feedback loop",
  where they influence each other, and you keep going round the
  loop for as long as you're able to identify more detail.  Some
  people like to do some OOP (programming), too, although
  usually only at a high level.  There's nothing inherently
  wrong with these approaches, but you do have to be careful not
  to get obsessed with petty details.  The bigger the project
  and the team, the more care you have to take that you're
  designing a system that is sensible.
  
  Hopefully, you want to produce "good" software, where "good"
  means some or all of: correct, robust, extensible, reusable,
  scalable, maintainable.  (Also known as "working" software.)
  
  You want to do this quickly, reliably, cheaply, and so on.
  Very likely, your users expect more features than ever before,
  and may well want your software to work in a GUI environment -
  in which case it will have to be event driven.
  
  If you're to implement a system successfully, you need to
  understand it "sufficiently".  You have to decide for yourself
  just what this means, but knowing too much is far less
  dangerous than knowing too little (despite the saying to the
  contrary).  As mentioned above, a requirements specification
  is a good start.  Talking to intended users is often a good
  idea, if you're allowed to, and if you're able to understand
  each other properly.
  
  Your aim is to model the system, starting with "the big
  picture", and going into more detail as work proceeds.  This
  model is going to be in terms of the objects it consists of
  and the interactions between them.
  
  To produce this model, you should look for inputs, outputs,
  physical/conceptual things, responses, and services used and
  provided.
  
  Inputs, outputs and physical/conceptual things include
  documents (orders, invoices, statements, reports, picking
  lists, etc.) as well as user actions.  They also include
  things like EDI and transactions on disk/tape.
  
  Initially, you should consider the main requirements of your
  system, because you want to identify the main classes.
  
  Until well into the design, you're really identifying
  potential, or candidate, classes.  Some of the things you
  initially think are classes may later turn out not to be.
  This is a relatively minor nuisance, because you shouldn't be
  discarding much work in these early stages when you make this
  sort of mistake.  You're throwing away more work if you get
  carried away and do too much design of a class, so resist the
  temptation.
  
  A description of the system, e.g. the requirements spec., can
  steer you in the right direction.  If you reduce the
  description to short, simple sentences you may find it helps
  most.  Try examining the nouns to see if they highlight
  candidate classes.  (Later on, the verbs can help you find the
  methods.)  Some commentators criticise this technique, but try
  it for yourself.  The examples above used it, the last one
  being:
  
  (a) The browse application is a kind of MDI application.
  (b) The application has a main window.
  (c) The main window has a (bar) menu.
  (d) The bar menu consists of popup menus and menu items.
  (e) The menu contains an item to allow a browse to be started,
      as well as standard items expected of Windows applications.
  (f) The main window has a status (message) bar.
  (g) More than one browse can be active at a time, even for the
      same file.
  
  As you can see, these are short, terse sentences, avoiding
  most of the variety of the English language.  They're also in
  a form chosen to accentuate the essentials from an OO viewpoint,
  which you can say is a form of cheating if you like.
  
  If you can't find classes including application, window, menu,
  browse (or browser), and status bar then this technique's
  definitely not for you!
  
  You're not worried about the fine detail of the classes yet.
  You're certainly not worried about class hierarchies - that
  comes later.  There's no harm in making notes about any
  details or hierarchies that seem obvious, of course.  However,
  until you have some experience you should bear in mind that
  this is another temptation that's best resisted.
  
  Don't hesitate to draw diagrams if you find it helps.  If
  you're a "visual" person or part of a team, diagrams can be
  especially helpful.  Check out some of the OO techniques, such
  as OMT or the CRC cards mentioned previously.
  
  Remember that a class is a description of related data (or
  attributes) and some behaviour.  Remember also that there are
  two sides to a class: its interface defines its public data and
  public behaviour, and its implementation defines how it works
  internally.  You're not interested in its implementation yet.
  
  Identify responsibilities, because classes carry them out.
  
  Identify services used or provided, because classes are
  involved in the using and in the providing of services.
  
  You may notice that you're identifying things that seem
  uncomfortably large, or which seem to contain unrelated data
  and/or behaviour.  Don't panic yet; further work had better
  resolve the reason.  Sometimes you really have made a mistake,
  but other times you've found a cluster of classes that is a
  sub-system of the whole system.  Applying more OOA/OOD will
  tell you if that's the situation.
  
  Identify physical/conceptual things.  These are also potential
  classes.
  
  Notice the word "things" (you can use "entities" if you
  prefer).  When looking for classes, you're not really looking
  for actions and behaviours, except that they help you to find
  the things.
  
  You may have seen these physical/conceptual things described
  as "real-world" things by some people.  You may also have seen
  criticism of this "real-world" description.  It's little
  wonder that beginners are confused when this kind of
  disagreement occurs.
  
  My own opinion is as follows.  If you're producing a system
  that has parts that are closely analogous to a real-world
  system, then the physical things in the real-world system are
  likely to be present in your model of it, and are therefore
  good candidate classes.  Similarly, if you're processing any
  real-world inputs or producing any real-world outputs, then
  they also make good candidate classes.  So, an invoice class
  is a good bet.  If you happen to be receiving invoices by EDI
  they're not physical things, but they're still real-world.  An
  invoice class still looks a good bet.
  
  Documents, whether physical or not, are suitable candidate
  classes.  Database tables and records are also suitable.  So
  is a data dictionary.  Other examples are bank accounts,
  customer details (here "customer" is the thing and the details
  the data), and user interface items (you've probably met these
  before).
  
  OO has been called a "natural" way of describing systems.
  This may be because of the correspondence between classes and
  physical/conceptual things, or it may be because of the
  parallels that exist between class hierarchies and the
  taxonomies of the natural world.
  
  Despite all the above, you may miss some classes.  You'll be
  doing some checking up later that should reveal this.