Click here to Skip to main content
12,299,086 members (46,544 online)
Click here to Skip to main content
Add your own
alternative version


271 bookmarked


, 20 Jun 2000
Rate this:
Please Sign up or sign in to vote.
An introduction to modelling OOP design concepts with UML



The purpose of this document is to provide you with information about UML and how to use it.

What is UML?

UML, Unified Modeling Language, is a standard notation for the modeling of real-world objects as a first step in developing an object oriented program. It describes one consistent language for specifying, visualizing, constructing and documenting the artifacts of software systems.

Why model?

Developing a model for a software system before you actually start programming the software, can be seen as having a blueprint for a large building you want to build. It is essential to have one. Although this doesn’t mean that you have to draw a model each time a simple class is introduced in your software. You have to think for yourself whether you want a model or not.

A few notation-rules

Graphs and their contents

Most UML diagrams are graphs containing nodes connected by paths. The information is mostly in the typology, not in the size or placement of the symbols. There are three kinds of visual relationships that are important:

  1. Connection (usually lines)

  2. Containment (2D shapes with boundaries)
  3. Visual attachment (one object being near another)

    UML notation is intended to be drawn on a 2D surface.

    There are basically four kinds of graphical constructs used in the UML notation:

    1. Icons – an icon is a graphical figure of a fixed size and shape. It does not expand to hold contents. Icons may appear within area symbols, as terminators on paths or as standalone symbols that may or may not be connected to paths

    2. 2D symbols – Two dimensional symbols have variable length and width and they can expand to hold other things, such as lists, strings or other symbols. Many of them are divided into compartments of similar or different kinds. Dragging or deleting a 2D-symbol affects its contents and any paths connected to it.

    3. Paths – Sequences of line segments whose endpoints are attached. Conceptually, a path is a single topological entity, although its segments may be manipulated graphically. A segment may not exist apart from his path. Paths are always attached to other graphic symbols at both ends (no dangling lines). Paths may have terminators, which are icons that appear in some sequence on the end of the path and that qualify the meaning of the path symbol.

    4. Strings – Present various kinds of information in an "unparsed" form. UML assumes that each usage of a string in the notation has a syntax by which it can be parsed into underlying model information. For example, syntaxes are given for attributes, operations and transitions. Strings may exist as singular elements of symbols or compartments of symbols, as elements in a list as labels attached to symbols or paths, or as stand-alone elements in a diagram.


Attributes and behavior

Each object has various attributes. An attribute is a name/value pair. For example, my age is 22. The attribute name is "age", the value is "22". Objects also have behavior. I can stand, walk, sleep etc.


There are different kinds of relationships:

Dependency is where one object must know about another.

In a simple dependency relationship, all we know is that one object has knowledge of another. For example: if one class requires the inclusions of the header for another, that establishes a dependency.

We draw a dependency using a dashed arrow. If a depends on b be sure the arrow points at b.

In association, the state of the object depends on another object.

In an association we say that, as part of understanding the state of one object, you must understand the relationship with the second object. There are many types of association which model real-world relationships, such as owns (Arjen owns this bike), works for (Raymond works for Harry) and so forth.

In an association the two objects have a strong connection, but neither one is a part of the other. The relationship is stronger that dependency; there is an association affecting both sides of the relationship.

An association between a and b is shown by a line joining the two classes:

If there is no arrow on the line, the association is taken to be bi-directional. A unidirectional association is indicated like this:

To improve the clarity of a class diagram, the association between two objects may be named:

Aggegration models the whole/part relation

Objects are often made up of other objects. Cars are made up of steering wheels, engines, transmissions and so forth. Each of these components may be an object in its own right. The special association of a car to its compoment parts is known as aggegration.

An aggregation relationship is indicated by placing a white diamond at the end of the association next to the aggregate class. If b aggregates a, then a is a part of b, but their lifetimes are independent:

Composition models a relationship in which one object is an integral part of another.

Often, the component parts of an object spring into existence only with the entire object. For example, a person may consist of a number of parts including the heart, lungs etc. If you were modeling a person, the lifetime of the heart and lungs would be directly controlled by the lifetime of the aggregating person.We call this special relationship composition.

In aggregation, the parts may live independently. While my car consists of its wheels and tires and radio, each of those components may have existed before the car was created. In composition, the lifetime of the contained object is tied to the lifetime of the containing object.

Composition is shown by a black diamond on the end of association next to the composite class. If b is composed of a, then b controls the lifetime of a.


Inheritance is a specialization/generalization relationship between objects.

We (humans) have inherited the ability to create categories based on the behavior and characteristics of the things in our environment. This is best shown with an example: If something breathes and moves, we say it’s an animal. If one of those things that move and breathe also has live young and nurses them, we say it’s a mammal. We know that mammals are kinds of animals, and so we can predict that if we see a mammal, it will in all likelihood breathe and move around.

If a mammal barks and wags its tail, we say it’s a dog. If it won’t stop barking and runs about our feet demanding attention, we figure it’s a terrier. Each of these classifications gives us additional information. When we’re done, we have created a hierarchy of types.

Some animals are mammals and some are reptiles. Some mammals are dogs and some are horses. Each type will share certain characteristics, and that helps us understand them and predict their behavior and attributes.

There is only one right way to draw this:

Once we have this categorization, we can see that reading up the animal hierarchy reveals the generalization of shared characteristics.

In the same way, we could create a model of a car. To do so, we must ask ourself some questions:

What is a car? What makes a car different from a truck, from a person, from a rock? One of the delights of object oriented programming is that these questions become relevant to us; understanding how we perceive and think about the objects in the real world directly relates to how we design these objects in our model.

From one perspective, a car is the sum of its parts: steering wheel, brakes, seats, headlights. Here, we are thinking in terms of aggregation. From a second perspective, one that is equally true, a car is a type of vehicle.

Because a car is a vehicle, it moves and carries things. That is the essence of being a vehicle. Cars inherit the characteristics moves and carries things from their "parent" type, which is "vehicle".

We also know that car specializes vehicles. They are a special kind of vehicle, one which meets the federal specifications for automobiles.

We can model this relationship with inheritance. We say that the car type inherits publicly from the vehicle-type; that a car is-a vehicle.

Public inheritance establishes a is-a relationship. It creates a parent class (vehicle) and a derived class (car) and implies that the car is a specialization of the type vehicle. Everything true about a vehicle should be true about a car, but the converse is not true. The car may specialize how it moves, but it ought to move.

What is a motor vehicle? This is a different specialization, at a different level of abstraction. A motor vehicle is any vehicle driven by a motor. A car is one such type, a truck is another. We can model these more complex relationships with inheritance as well.

Which model is better? Depends on what you’re modeling! How do you decide which model you want to use? Ask yourself questions. Is there something about "Motor Vehicle" I want to model? Am I going to model other, non-motorized vehicles? If you do, you should use the second model. To show this with an example: Suppose you want to create two classes for vehicles which are horse-drawn.

Public inheritance

A critical aspect of public inheritance is that it should model specialization/generalization, and nothing else! If you want to inherit implementation, but are not establishing an is-a relationship, you should use private inheritance.

Private inheritance establishes an implemented-in-terms-of rather than an is-a relationship.

Multiple inheritance

One of the capabilities available in C++, is multiple inheritance. Multiple inheritance allows a class to inherit from more than one base class, bringing in the members and methods of two or more classes.

In simple multiple inheritance, the two base classes are unrelated. And example of multiple inheritance is shown below. Also notice how the functions are displayed in this model.

In this rather simple model, the Griffin class inherits from both Lion and Eagle. This means a Griffin can eatMeat(), roar(), squawk() and fly(). A problem arises when both Lion and Eagle share a common base class, for example Animal.

This common base class, Animal, may have methods of member variables which Griffin will now inherit twice. When you call Griffin’s Sleep() method, the compiler will not know which Sleep() you wish to invoke. As the designer of the Griffin class, you must remain aware of these relationships and be prepared to solve the ambiguities they create. C++ facilitates this by providing virtual inheritance.

Without virtual inheritance

With virtual inheritance

With virtual inheritance, Griffin inherits just one copy of the members of Animal, and the ambiguity is solved. The problem is that both Lion and Eagle classes must know that they may be involved in a multiple inheritance relationship; the virtual keyword must be on their declaration of inheritance, not that of Griffin.


Using multiple inheritance when you need aggregation

How do you know when to use multiple inheritance and when to avoid it? Should a car inherit from steering wheel, tire and doors? Should a police car inherit from municipal property and vehicle?

The first guideline is that public inheritance should always model specialization. The common expression for this is that inheritance should model is-a relationships and aggegration should model has-a relationships.

Is a car a steering wheel? Clearly not. You might argue that a car is a combination of a steering wheel, a tire and a set of doors, but this is not modeled in inheritance. A car is not a specialization of these things; it’s an aggregation of these things. A car has a steering wheel, it has doors and it has tires. Another good reason why you should not inherit car from door is the fact that a car usually has more than one door. This is not a relationship that can be modeled with inheritance.

Is a police car both a vehicle and a municipal property? Clearly it is both. In fact, it specializes both. As such, multiple inheritance makes a lot of sense here:

Base classes and derived classes

Derived classes should know who their base class is, and they depend on their base classes. Base classes, on the other hand, should know nothing about their derived classes. Do not put the header for derived classes into your base class files.

You want to be very suspicious of any design that calls for casting down the inheritance hierarchy. You cast down when you ask a pointer for it’s "real" (run-time) class and then cast that pointer to the derived type. In theory, base pointers should be polymorphic, and figuring out the "real" type of the pointer and calling the "right" method should be left to the compiler.

The most common use of casting down is to invoke a method that doesn’t exist in the base class. The question you should be asking yourself is why you are in a situation where you need to do this. If knowledge of the run-time type is supposed to be hidden, then why are you casting down?

Single instance classes

You also want to be very aware of derived classes for which there is always only one instance. Don’t confuse it with a singleton, in which the application only needs a single instance of a type, for example only one document or only one database.

Drawing a class

Displaying members

Suppose you want to create a class CFloatPoint, which has two members: x and y, which are both of type ‘float’, and a function "Empty()" which resets both members to value 0.00000.

First of all, you draw the class itself:

Now, we want the members x and y to be visible in the model:

As you can see, x and y are both private (lock-sign) and have the type "float".

Now, we want to make the function Empty() visible in the model:


Suppose you need to give some additional information about your class. You can easily do this with adding a note, which looks like this:


Software used

Visual modeler

Keep in mind that these models are created with Visual Modeler, which is delivered with Visual Studio Enterprise Edition, so you can try and draw them yourself. I’m not going to explain how Visual Modeler works here, look in the manual or MSDN Library for more information.

Future versions of this document

I think this document is a good step in OOP and UML. Together with the document " Different styles of Programming " they provide a good first-step tutorial in the world of Object Oriented Programming.

There are many features of UML which are not covered in this document. One of them are so-called "use-cases" which is a story on its own. This will be explained in a new document which has yet to be written at this moment.

Alex Marbus



This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Alex Marbus
Netherlands Netherlands
No Biography provided

You may also be interested in...

Comments and Discussions

GeneralThanks, Alex Pin
Gary R. Wheeler8-Jun-02 0:56
memberGary R. Wheeler8-Jun-02 0:56 
GeneralTimetabling in VC++!!!!URGENT!!! Pin
Mark Shian6-Jun-02 5:35
memberMark Shian6-Jun-02 5:35 
GeneralRe: Timetabling in VC++!!!!URGENT!!! Pin
Daniel Turini7-Aug-02 1:40
memberDaniel Turini7-Aug-02 1:40 
Generalgood article, but i have a question- Pin
spoongirl9-May-02 5:25
memberspoongirl9-May-02 5:25 
GeneralRe: good article, but i have a question- Pin
jan larsen25-Jul-02 1:35
memberjan larsen25-Jul-02 1:35 
Generalah- thanx for the explanation Pin
spoongirl25-Jul-02 3:27
memberspoongirl25-Jul-02 3:27 
GeneralActually better (self?) explanation for composition could be: Pin
Kokeeno29-May-03 18:08
memberKokeeno29-May-03 18:08 
Generalurgent Pin
aris puji widodo4-May-02 6:40
memberaris puji widodo4-May-02 6:40 
GeneralRe: urgent Pin
AlexMarbus6-May-02 6:16
memberAlexMarbus6-May-02 6:16 
Generalpointers or objects Pin
sansingh3-May-02 4:00
membersansingh3-May-02 4:00 
GeneralRe: pointers or objects Pin
Rejeesh.T.S6-May-02 7:36
memberRejeesh.T.S6-May-02 7:36 
GeneralRe: pointers or objects Pin
Anonymous7-May-02 1:16
memberAnonymous7-May-02 1:16 
Generalshape class Pin
jdreamer30-Apr-02 2:22
memberjdreamer30-Apr-02 2:22 
Generalsahep class Pin
jdreamer30-Apr-02 2:21
memberjdreamer30-Apr-02 2:21 
GeneralSequence Diagrams Pin
Tom Archer25-Apr-02 19:55
memberTom Archer25-Apr-02 19:55 
GeneralRe: Sequence Diagrams Pin
jan larsen25-Jul-02 1:37
memberjan larsen25-Jul-02 1:37 
GeneralSequence, states, deployment, and many others Pin
Kokeeno29-May-03 18:11
memberKokeeno29-May-03 18:11 
GeneralI want to begin visual c and this is my question Pin
Anonymous21-Mar-02 10:08
memberAnonymous21-Mar-02 10:08 
GeneralC++ examples please Pin
Federico23-May-01 8:47
memberFederico23-May-01 8:47 
GeneralRe: C++ examples please Pin
benj200212-Jan-02 21:41
memberbenj200212-Jan-02 21:41 
GeneralRe: C++ examples please Pin
Clim8-Apr-02 11:46
memberClim8-Apr-02 11:46 
GeneralRe: C++ examples please Pin
Michael T. Babcock10-Jun-02 5:59
memberMichael T. Babcock10-Jun-02 5:59 
GeneralRe: C++ examples please Pin
AlexMarbus11-Jun-02 6:02
memberAlexMarbus11-Jun-02 6:02 
GeneralMicrosoft FoxPro Data Models Pin
Anonymous9-May-01 8:45
memberAnonymous9-May-01 8:45 
GeneralRe: Microsoft FoxPro Data Models Pin
BaelWrath4-Jul-01 5:21
memberBaelWrath4-Jul-01 5:21 
GeneralRe: Microsoft FoxPro Data Models Pin
Mark W. Holmes13-Jul-01 18:25
memberMark W. Holmes13-Jul-01 18:25 
Thanatos27-Apr-01 5:52
memberThanatos27-Apr-01 5:52 
GeneralRe: PROJECT UML Pin
jan larsen25-Jul-02 1:41
memberjan larsen25-Jul-02 1:41 
GeneralThanks 4 the high rating :) Pin
AlexMarbus5-Mar-01 12:28
memberAlexMarbus5-Mar-01 12:28 
GeneralTools Pin
Igor Proskuriakov28-Sep-00 0:44
sussIgor Proskuriakov28-Sep-00 0:44 
GeneralRe: Tools Pin
Alex Marbus28-Sep-00 5:18
sussAlex Marbus28-Sep-00 5:18 
Generalprotected inheritance Pin
Sayed29-Jun-00 7:24
sussSayed29-Jun-00 7:24 
GeneralRe: protected inheritance Pin
jan larsen25-Jul-02 1:44
memberjan larsen25-Jul-02 1:44 
GeneralHelpful [FREE] tool for modeling Pin
W. Scott Dillman27-Jun-00 9:20
sussW. Scott Dillman27-Jun-00 9:20 
GeneralRe: Helpful [FREE] tool for modeling Pin
Le Chi Thu30-Jun-00 2:46
sussLe Chi Thu30-Jun-00 2:46 
GeneralAnother [FREE] UML design tool Pin
Dave Rosen15-Feb-01 16:29
memberDave Rosen15-Feb-01 16:29 
GeneralRe: Helpful [FREE] tool for modeling Pin
BaelWrath4-Jul-01 5:30
memberBaelWrath4-Jul-01 5:30 
GeneralQuestion about aggregation Pin
Dave C.26-Jun-00 6:50
sussDave C.26-Jun-00 6:50 
GeneralRe: Question about aggregation Pin
Norbert Muench26-Jun-00 10:04
sussNorbert Muench26-Jun-00 10:04 
Generalsome technical questions Pin
Micha26-Jun-00 1:12
sussMicha26-Jun-00 1:12 
GeneralExcellent Article Pin
Florian W.22-Jun-00 22:52
sussFlorian W.22-Jun-00 22:52 
GeneralRe: Excellent Article Pin
Alex Marbus23-Jun-00 5:21
sussAlex Marbus23-Jun-00 5:21 
GeneralRe: Excellent Article Pin
Xtreme Programmer25-Jun-00 12:06
sussXtreme Programmer25-Jun-00 12:06 
GeneralRe: Excellent Article Pin
Roger1-Jul-00 19:53
sussRoger1-Jul-00 19:53 
GeneralStarting Point Pin
Prabhakar22-Jun-00 3:31
sussPrabhakar22-Jun-00 3:31 
GeneralSimply Fabulous Pin
Santosh Rao21-Jun-00 18:42
sussSantosh Rao21-Jun-00 18:42 
GeneralDeveloper.Dot Pin
Brad Bruce21-Jun-00 9:56
sussBrad Bruce21-Jun-00 9:56 
GeneralRe: Developer.Dot Pin
Alex Marbus21-Jun-00 11:35
sussAlex Marbus21-Jun-00 11:35 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.160525.2 | Last Updated 21 Jun 2000
Article Copyright 2000 by Alex Marbus
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid