There are arguably too many methodologies and also too many
  ways of drawing diagrams of OO systems.  Rapid changes have
  occurred and probably will continue to occur.  In addition,
  some techniques are more suited to certain types of systems
  (e.g. real-time).  If you have the time, inclination, budget,
  etc., at least look at the key players, who currently include:
  Booch, Coad-Yourdon, Rumbaugh and Shlaer-Mellor.  Rumbaugh's
  OMT (Object Modelling Technique) is perhaps the front-runner
  for business applications.
  
  
  Another useful tool is to use CRC Cards.
  
  These are used to record information about each class:
  
       C  =  Class  (name and description of its purpose)
  
       R  =  Responsibilities
  
       C  =  Collaborators  (classes that help this class fulfil
                             its responsibilities)
  
       super classes / sub-classes
  
       attributes
  
       behaviours
  
       other info
  
  The exact form of a card and details kept on it are not very
  important: they're just an aid you may find useful.  They're
  typically the size of a file card or postcard, with all the
  information on one side (sometimes the back is used for
  notes).  You can re-arrange them easily, re-do one, and so on.
  Think of them as the semi-official version of the "back of an
  envelope".
  
  If you think these might be useful, try printing them yourself
  - it's the cheapest way!
  
  Here's an example:
  
  
       Class:              PrinterPage
  
       Description:   Holds one page of data to allow random access
  
       Super Class:   none
  
       Sub-classes:        none
  
       Responsibilities                        Collaborators
  
       Clear itself to spaces                  You might like something
       Accept a string at any row, column      like a Buffer, or you might
       Output its characters in order          not!
         (top to bottom, left to right)
  
  
  You tend to fill in more and more of a card as you go along.
  You make changes quite often, too.  Responsibilities are more
  important than Collaborators, initially.
  
  This discussion doesn't use any formal system at all yet,
  which at least has the advantages that no lengthy introduction
  of a formal system is needed and it won't be using a
  methodology you've rejected...