Chapter 3

Class Diagrams:
The Essentials

1
 Terms and Concepts
• A class is ...
– The most important building block of any object-
oriented system.
– A description of a set of objects that share the same
attributes and behaviors.
– A blueprint for creating an object.
– An abstraction (simplification) of reality.
– A representation of a software thing, a hardware thing,
or even a conceptual thing.
– Graphically represented as a rectangle.

2
 Terms and Concepts
• All classes have …
– Names - Used to distinguish one class from another. A
class must have a name.
– Attributes - Member data
– Operations (behaviors) - Member functions (C++) or
methods (Java)
– Responsibilities
• Class names are …
– extracted from the problem domain (statement)
– nouns or noun phrases
– concise and descriptive
3
 Terms and Concepts
• Class attributes are …
– usually nouns or noun phrases.
– extracted or inferred from the problem statement.
– used to represent properties of the enclosing class.
– determine the state of an object
– usually notated using the format
• visibility name: type multiplicity = default {property string}
• example: - firstName: String = ‘Bob’ {read only}
– optionally notated as associations

4
 Terms and Concepts
• Class operations (behaviors) are …
– named using a verb or verb phrases.
– inferred from the problem statement.
– Provide a requested service.
– usually notated using the format
• visibility name (parameter-list) : return-type {property-string}
• example: +printFirstName( ) : void
• Class responsibility…
– Is a contract or obligation of a class to the users of the
class.
– Maps directly to the Responsibility field of a CRC card.
• CRC - Class Responsibility Collaboration
5
Class Artifact

6
Simple
Class
Diagram

7
 Common Modeling Techniques
• Identify the classes that are to be included in the
design.
– Formulate a problem statement. The problem
statement may be scenarios associated with use cases.
– Identify the nouns in the problem statement.
– Use CRC (Class, Responsibility, Collaboration) cards
or use-cases to isolate each class.
• Determine the responsibilities of each class.
– Even out the work load between classes.
• A class with too much responsibility should be broken up into
multiple classes.
• A class with too little responsibility should be absorbed into
another class.
8
 Common Modeling Techniques
• Classes should exhibit high cohesion and low
coupling.
– A class should have a single well-defined purpose.
• This promotes software reusability
– A class should interact with a limited number of other
classes.
• This simplifies modifications to the program.
• Feel free to model abstract (non-software) things
(such as people) that are outside of the system
boundaries.

9
 Associations
• An association is …
– a type of relationship that can exist between one or more
classes.
– used to show a ‘knows-a’ relationship.
– either unidirectional or bidirectional.
– graphically represented by a solid line which may
optionally be labeled and have a name direction
indicator or navigability arrows.
– an alternative notation for a class attribute
• Association names are verbs or verb phrases.
• The same class can be on both ends of an
association.
10
 Associations
• Associations may optionally have role names and
multiplicity symbols on either end of the
association line (next to the class icon).
• Role
– The face that a class on one end of an association
presents to the class on the other end of the association.
– A class can participate in many associations and thus
have multiple (different) roles.
– Role names are nouns.
– Role names are usually used in place of association
names.

11
Attributes Modeled as
Associations

12
 Multiplicity
• Multiplicity
– Indicates how many object may be connected across an
instance of an association.
– Commonly used multiplicities
• 1
• 0..1
• *
– The default multiplicity of an attribute is ‘1’

13
Terms and Concepts

14
 Generalization
• Generalization is …
– a type of relationship that can exist between two classes.
One of the classes is the base (or parent) class; the other
class is the derived (or child) class.
– used to show a ‘kind-of’ relationship.
– another name for inheritance.
– graphically represented by a solid line with an open
triangular arrowhead on the base class end.
• The parent class has no knowledge of the child class.
• All OO programming languages support single
inheritance; some (C++) also support multiple
inheritance.

15
 Common Modeling Techniques
• Modeling inheritance (generalization)
– Make it a priority to look for possible inheritance
relationships. This will reduce code redundancy.
• Use the “ClassA ‘is-a-kind-of’ ClassB” test.
– Do not model relationships using multiple inheritance
unless the implementation language supports multiple
inheritance. This will save programmers having to
develop messy work-arounds.
– Look for classes that have similar attributes and
behaviors and then factor those attributes and behaviors
into a common base class.

16
 Notes and Comments
• Use notes to embed comments into UML
diagrams.
– The comment may contain links to other documents.
• A note may stand alone or be attached to a
graphical element.
– A dashed line is customarily used as the connector
• Use notes when a picture is not enough.

17
 Dependency
• A dependency is ...
– A type of relationship that can exist between two classes.
– An indication that one class ‘uses’ another class.
– If the ‘used’ class changes it can have an impact on the
‘using’ class.
– Graphically represented as a dashed line with an open
arrowhead on one end.
– Rarely labeled.
• The ‘used’ class is frequently an argument to one
of the member functions of the ‘using’ class.
• The “used” class has no knowledge of the “using”
class.
18
Dependency Relationships

19
Common Class Relationships

20
Terms and Concepts

21