1

Introduction to Classes
2
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.
3
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.
Stereotypes - Documentation used to categorized class
members.
Responsibilities - Documents the purpose of the class.
Attributes and operations are the most important
features of a class definition.
A class usually collaborate with other classes.
4
Terms and Concepts
Class names are
Extracted from the problem domain (statement).
Nouns or noun phrases.
Concise and descriptive.
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.

5
Terms and Concepts
Class operations (behaviors) are
Verbs or verb phrases.
Inferred from the problem statement.
Provide a requested service.
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
6
Class Artifact
7
Common Modeling Techniques
Identify the classes that are to be included in the
design.
Formulate a problem statement.
Focus on the nouns in the problem statement.
Use CRC (Class, Responsibility, Collaboration) cards
or use-cases to isolate each class.
8
Common Modeling Techniques
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.
Group together classes that work toward a common
goal.
Packages (directories) may be used to group related classes
into a higher level of abstraction.
Packages may contain other packages.

9
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.
10
Common Modeling Techniques
Feel free to model abstract (non-software)
things (such as people) that are outside of
the system boundaries.
Occasionally built-in data types (int, float,
char, etc.) are modeled as classes, although
this is rare.
11
Class Relationships
12
Terms and Concepts
13
Terms and Concepts
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.
14
Terms and Concepts
15
Terms and Concepts
A 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.
All OO programming languages support single
inheritance; some (C++) also support multiple
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.
16
Terms and Concepts
17
Terms and Concepts
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 bi-directional.
Graphically represented by a solid line which may
optionally be labeled and have a name direction
indicator.
A peer relationship.
Association names are verbs or verb phrases.
The same class can be on both ends of a binary
association.
18
Terms and Concepts
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.


19
Terms and Concepts
Multiplicity
Indicates how many object may be connected across an
instance of an association.
Aggregation is
A relationship between two classes.
A form of association.
Used to show a has-a or a whole-part relationship.
Graphically represented as a solid line with an open
diamond on the whole end.
Aggregations and associations are implemented in
exactly the same way. The difference is entirely
conceptual.
20
Terms and Concepts
21
Terms and Concepts
Composition is
A relationship between two classes.
A strong form of association.
Used to show a contains-a or a whole-part
relationship.
Graphically represented as a solid line with a solid
diamond on the whole end.
Composition relationships and associations are not
implemented in exactly the same way.
If the whole object is destroyed, the part object
will also be destroyed.
The whole and part have concurrent lifetimes.
22
Terms and Concepts
23
Common Modeling Techniques
Modeling inheritance
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.
24
Common Modeling Techniques
Modeling dependency, association, aggregation
and composition relationships.
It is not always easy to determine which is the best
relationship to use. It all has to do with your
perspective of the problem domain.
There is not always one best solution.
Personal experience is your most valuable modeling
tool.
CRC cards are helpful.