In June 2003, I began a series of articles titled "UML Basics," designed as an introduction to the Unified Modeling Language. The first article in this series provided high-level introductions to the most widely used diagrams in the UML; the second article offered an in-depth look at the activity diagram.
In this third article, I will focus on the class diagram. Although almost every UML-knowledgeable person claims to understand this diagram, very few actually know the diagram's proper notation set and consequently do not know how to use the diagram. The discussion that follows should enable you to understand and draw a proper class diagram using the UML v1.4 notation set.
This article assumes you have a rudimentary understanding of object oriented design. For those of you who need a little assistance with OO concepts, you might try the Sun brief tutorial about Object Oriented Programming at http://java.sun.com/docs/books/tutorial/java/concepts/. Reading the sections "What Is a Class?" and "What Is Inheritance?" should give you enough understanding to read this article. In addition, David Taylor's book, Object-oriented Technologies: A Manager's Guide, offers an excellent, high-level explanation of object-oriented design without requiring an in-depth understanding of computer programming.
In this third article, I will focus on the class diagram. Although almost every UML-knowledgeable person claims to understand this diagram, very few actually know the diagram's proper notation set and consequently do not know how to use the diagram. The discussion that follows should enable you to understand and draw a proper class diagram using the UML v1.4 notation set.
This article assumes you have a rudimentary understanding of object oriented design. For those of you who need a little assistance with OO concepts, you might try the Sun brief tutorial about Object Oriented Programming at http://java.sun.com/docs/books/tutorial/java/concepts/. Reading the sections "What Is a Class?" and "What Is Inheritance?" should give you enough understanding to read this article. In addition, David Taylor's book, Object-oriented Technologies: A Manager's Guide, offers an excellent, high-level explanation of object-oriented design without requiring an in-depth understanding of computer programming.
The purpose of the class diagram is to show the static structure of the system being modeled. The diagram specifically shows the entities in the system -- and I literally mean entities, as in "discrete things," not to be confused with "database entities" -- along with each entity's internal structure and relationships with other entities in the system. Because class diagrams only model the static structure of a system, only types of entities
are shown on a class diagram; specific instances are not shown. For example, a class diagram would show an Employee class, but would not show actual employee instances such as Donald Bell, Mike Perrow, or Jimmy Buffett.
Developers typically think of the class diagram as a diagram specifically meant for them, because they can use it to find out details about the system's coded classes or soon-to-be-coded classes, along with each class's attributes and methods.
Class diagrams are particularly useful for business modeling, too. Business analysts can use class diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy.
are shown on a class diagram; specific instances are not shown. For example, a class diagram would show an Employee class, but would not show actual employee instances such as Donald Bell, Mike Perrow, or Jimmy Buffett.
Developers typically think of the class diagram as a diagram specifically meant for them, because they can use it to find out details about the system's coded classes or soon-to-be-coded classes, along with each class's attributes and methods.
Class diagrams are particularly useful for business modeling, too. Business analysts can use class diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy.
