CSE2305/CSC2050 - Object-Oriented Software Engineering
Week 9

Topic 17: The Booch Notation

Synopsis

Booch's Notation
Representing classes ¤
Representing inheritance
Representing aggregation ¤
Representing client/server use
Representing other class ¤-like entities
Putting it all together
Representing objects
Representing object interactions: the Object Diagram
Representing object interactions: the Interaction Diagram
Other Booch notations
Reading

Booch's Notation

A way of capturing the relationships in an OO design.
A way of thinking about the relationships in an OO design.
But not (by itself) equivalent to an OO design
...also need text to explain the reasons for the structure, the purpose of various components, and the general nature of the interactions

Representing classes ¤

You already know how to represent classes¤ in Booch notation
They are "broken clouds"...
...labelled with the class¤ name...
...and possibly with its attributes and operations

[Diagram showing a cloud with a dashed outline, labelled with
the underlined word "Vehicle" and with a list of attributes
and operations beneath it]

That corresponds to the C++ code:


        	class Vehicle
        	{
        	public:
        		Vehicle(void);
        		virtual bool Register(string regnum);
        		string GetRego(void);

        	private:
        		string myRegNum;
        	};

Representing inheritance

You also already know how to represent inheritance
The arrow goes from the derived class¤¤ back to the base class¤¤

[Previous diagram with an extra "class cloud" labelled
"Car", and with additional attributes and operations]

That corresponds to the C++ code:


        	class Vehicle
        	{
        	public:
        		Vehicle(void);
        		virtual bool Register(string regnum);
        		string GetRego(void);

        	private:
        		string myRegNum;
        	};

        	class Car : public Vehicle
        	{
        	public:
        		Car(string make, string model);
        		virtual bool Register(string regnum);
        		string GetDescription(void);

        	private:
        		string myMake;
        		string myModel;
        	};

Representing aggregation ¤

There are several other possible class¤ relationships
The aggregation¤ relationship is the most common and represents the relationship where one class¤ has members¤ belonging to some other class¤.


        	class StudRec
        	{
        	public:
        		StudRec(int ID, string name, double mark);

        		int    GetID(void);
        		string GetName(void);
        		double GetMark(void);

        	private:
        		int    myID;
        		string myName;
        		double myMark;
        	};

The aggregation¤ relationship ("has") is represented by a line with a black disc at the "owner" object

[Diagram showing four class clouds, labelled "StudRec", "int", "double",
and "string", with a line from the StudRec cloud to each of the other
clouds. Each line has a black disc at the StudRec end.]

There are two "sub-types" of aggregation¤: by value and by reference¤.
If one class¤ aggregates another by value it actually has a member¤ of that other class¤:


        	class StudRec
        	{
        	public:
        		StudRec(int ID, string name, double mark);

        		int    GetID(void);
        		string GetName(void);
        		double GetMark(void);

        	private:
        		int    myID;
        		string myName;
        		double myMark;
        	};

This is represented by using a solid box at the other end of the "has" link

[Diagram showing four class clouds, labelled "StudRec", "int", "double",
and "string", with a line from the StudRec cloud to each of the other
clouds. Each line has a black disc at the StudRec end and a solid box at the
other end.]

On the other hand, a class¤ may store a pointer or reference¤ to some other class¤:


        	class StudRec
        	{
        	public:
        		StudRec(int ID, string name, double mark);

        		int    GetID(void);
        		string GetName(void);
        		double GetMark(void);

        	private:
        		int*    myIDPtr;
        		string* myNamePtr;
        		double* myMarkPtr;
        	};

This is called agregregation by reference¤ and is represented by a hollow box:

Representing client/server use

The client/server relationship ("uses") is represented by a line with a circle at the "owner" object

[Diagram showing three class clouds, labelled "StudRec", "istream"
and "ostream", with a line from the StudRec cloud to each of the other
clouds. Each line has a circle at the StudRec end.]


        	class StudRec
        	{
        	public:
        		StudRec(int ID, string name, double mark);

        		int    GetID(void);
        		string GetName(void);
        		double GetMark(void);

        		void   PrintMe(ostream& os);
        		void   ReadMe(istream& is);

        	private:
        		int    myID;
        		string myName;
        		double myMark;
        	};

The nesting relationship is represented by nesting clouds
For example, the BSTree class¤:


        	class BSTree
        	{
        	private:
        		class Node
        		{
        		public:
        			int   myValue;
        			Node* myLeft;
        			Node* myRight;

        			Node(void);
        		}

        	public:
        		// ETC...
        	};

[Diagram showing two class clouds, labelled "BSTree",
and "Node", with the Node cloud inside the BSTree cloud.]

Also note that we could indicate the "reflexive" relationship of the Node class¤ to itself (i.e. the fact that each Node contains pointers to other Nodes)

[Previous diagram with a loop added from the Node class
to itself. The loop has a black disc at one end and
a hollow box at the other.]

Representing other class ¤-like entities

Templates (e.g. List<Type>) are represented as "broken clouds" with "broken boxes" for the various template parameters

[Diagram showing a "class cloud" with a dashed box obscuring
the top right-hand corner]


        	template <class TYPE>
         	class ListOf
        	{
        	public:
        		bool First(void);
        		bool Next(void);
        		TYPE GetCurrent(void);
        		bool InsertCurrent(const TYPE& newelem);
        		bool DeleteCurrent(void);

        	private:
        		TYPE* myArray;
        		int   mySize;
        		int   myNextFree;
        	};

Actual classes¤ specialized from a template (e.g. List<string>) are represented like template clouds, except the box is now solid.

[Diagram showing a "class cloud" with a solid box obscuring
the top right-hand corner]


        	template <>
         	class ListOf<bool>
        	{
        	public:
        		bool First(void);
        		bool Next(void);
        		TYPE GetCurrent(void);
        		bool InsertCurrent(const TYPE& newelem);
        		bool DeleteCurrent(void);

        	private:
        		long* myPackedArray;
        	};

Class¤ utilities are non-OO components of a program (like the function main() or the math.h library).
Class¤ utilities are represented by a class¤ cloud with a shadow

$[Diagram showing a "class cloud" labelled math.h with a shadow below and to its right. In the cloud are a number of attributes (e.g. M_PI) and operations (e.g. sin())]$

Putting it all together

Of course, in a real design (even a simple one) you need to use most of these notations in the same diagram:

[Diagram showing a simple design illustrating most of the
features described above.]

Representing objects

In order to make clear the way in which a design is structured it is not enough just to show the class¤ relationships
It is often also important to show the actual objects that will be instantiated
In the Booch notation, objects are represented as "unbroken clouds":

[Diagram showing a cloud shape with a solid outline,
labelled with the name of the object and its attributes.

Representing object interactions: the Object Diagram

One way of describing the relationships between objects in a system is to represent each and then draw labelled arrows indicating who calls whom
This is called an Object Diagram:

[Diagram showing numerous cloud shape with solid outlines,
with arrows representing calls of members.]

Representing object interactions: the Interaction Diagram

Another approach emphasizes the time-line of calls
It is called an Interaction Diagram:

[Diagram showing a series of vertical dashed lines, each
labelled with an object name. Arrows between the lines
indicate member function calls, as time increased down
the diagram.]

Note that data is assumed to flow back up the arrows implicitly
Can also "thicken" the object life-lines to indicate which object(s) are the focus of control at any point:

[Previous diagram with swollen object lines whilst active.]

Other Booch notations

Booch also provides notation for many other aspects of system design, including...
...class¤ categories (higher level groups of classes¤)
...metaclasses¤ (classes¤ which represent the type of other classes¤ - not a C++ concept)
...state¤ transition diagrams (yet another way of capturing program flow of control)
...synchronization of method calls in threaded (parallel) systems
...modules (code level groupings of classes¤ - corresponds to namespaces and files in C++)
...processors and devices (harware level view of the system)
...annotations and adornments (convey extra information textually)

Reading

Booch, G., "Object-oriented Analysis and Design with Applications", Second Edition, Benjamin Cummings, 1994 (in particular: Chapter 5).

Last updated: Tue Jul 6 11:33:55 1999

Topic 17: The Booch Notation

Synopsis

Representing other class¤-like entities

Representing other class ¤-like entities