Classes and Objects
What are objects?
“A discrete entity with a well-defined boundary that encapsulates state and
behavior in an instance of a class.”










An object is a cohesive packet of data and function.
Generally speaking, the only way to get to the data part of an object is by calling
one of the functions as operations in analysis and methods in design.
o In analysis – we are describing an abstract specification of a function
(operation)
o In design – we are describing the actual, physical implementation of a
function (method)
Objects hide data behind a layer of functions
o Called encapsulation or data hiding
o Not enforced in UML but is enforced in OO programming languages
Every object is an instance of some class that defines the common set of features
(attributes, and operations or methods) that are shared by all instances of a class.
Every object is uniquely identifiable
o Identity – this is the object’s unique existence in time and space. It is what
makes it different from all other objects.
 Every object will have some sort of object reference.
Every object has a state – this is determined by the attribute values of an object at
a particular point in time.
Attribute values hold the object’s data.
An object’s functions are called operations in analysis and methods in design.
o Invoking an operation or method will often cause a change in the values
of one or more of its attributes, and this may constitute a state transition.
An object’s behavior is “what it can do for us” – its operations.
Object’s generate system behavior by sending messages to each other over links –
this is collaboration.
1
Inheritance and Polymorphism
Generalization is a relationship between a more general thing and a more specific thing:
 The more specific thing is consistent in every way with the more general thing;
 The substitutability principle states that you can substitute the more specific thing
anywhere the more general thing is expected;
 Generalization applies to all classifiers and some other modeling elements;
 Generalization hierarchies may be created by generalizing from specific things or
by specializing from general things;
 All things at the same level in a generalization hierarchy should be at the same
level of abstraction.
Class inheritance occurs in a generalization relationship between classes:




The subclass inherits the following features from its parents
o Attributes (but NOT private attributes, only public and protected)
o Relationships
o Constraints
Subclasses may:
o Add new features;
o Override inherited operations:
 The subclass provides a new operation with the same signature as
the parent operation it wishes to override.
 The operation signature consists of an operation name, types of all
parameters in order, and return type.
Abstract operations are designed to have no implementations:
o They serve as placeholders;
o All concrete subclasses must implement all inherited abstract operations.
An abstract class has one or more abstract operations:
o Abstract classes cannot be instantiated;
o Abstract classes define a contract as a set of operations that concrete
subclasses must implement.
Polymorphism means “many forms”. It allows you to design systems to use with an
abstract class and then substitute concrete subclasses at run-time – such systems are very
flexible and easy to extend – just add more subclasses.

Polymorphic operations have more than one implementation:
o Different classes may implement the same polymorphic operation
differently;
o Polymorphism allows instances of different classes to respond to the same
message in different ways.
2

Object-Oriented languages allow us to define two functions (i.e., methods) with
the same name
o Provided they are in different classes but they must be subclasses and
superclasses.
o The system will choose the right version of the method to suit that
particular method instance.

We say that “The object knows its own type, so it knows what to do.”
Polymorphism and Overriding

We say that a subclass feature (attribute or method) overrides the corresponding
superclass feature.

That is, the subclass version of the feature actually replaces the superclass feature
for that subclass and all its descendants.
Static and Dynamic Binding

Some O-O languages store the code for the methods as partially-compiled object
code, which is then linked into the program at compile time.
o This means that there is a copy of the method code inserted into your
program when this happens.
o This is known as Static or Early Binding
o Since the method call is bound early to the code it will execute.

Other O-O languages store the code for the methods as fully-compiled binary
executable code, which is stored in the database at compile time.
o At Run Time (i.e., later), your program’s method call causes a jump to this
code, to execute it directly from where it is stored in the database.
o This means that there is no copy of the method code inserted into your
program.
o This is known as Dynamic or Late Binding,
o Since the binding of the code to the method call that will invoke it takes
place later at run time.
3
Early (Static) Binding


Means a larger program size, since all the method code is copied into every
program.
If you modify a method, it is not available for execution until each program has
been recompiled.
Late (Dynamic) Binding

The moment you modify a method and store the compiled method code in the
database, it is instantly available to any executing program.

(Late Binding is more like true Object-Oriented!)
4
Analysis Classes
* Classification is possibly the single most important way that human beings have
of ordering information about the world.
Class: “The descriptor for a set of objects that share the same attributes, operations,
methods, relationships, and behavior” or more simply put a class is a descriptor for a set
of objects that have the same feature.
Every object is an instance of exactly ONE class.
Here are some useful ways to think about class:
 Think of a class as being a template for objects – a class determines the structure
(set of features) of all objects of that class. All objects of the same class must
have the same set of operations, the same set of attributes, and the same set of
relationships, but may have different attribute values.
 Think of a class as being like a rubber stamp, and the objects as actual stamp
marks on a piece of paper; or think of a class as being like a cookie cutter, and the
objects as being the cookies.
* Finding the right classification scheme is one of the keys to successful OO
analysis.
Object Instantiation:

Object instantiation creates a new object using its class as the template.
5
UML Class Notation:
Name
Compartment
Attribute
Compartment
Operation
Compartment
Window
+size : Area = (100, 100)
#visibility : Boolean = false
+defaultSize : Rectangle
-xptr : XWindow*
+create()
+hide()
+display (location : Point)
Initialization value
Class scope
operation
(underlined)
Visibility
adornment
Adornment
Visibility Name
Semantics
+
Public visibility
-
Private visibility
#
Protected visibility
~
Package visibility
Any element that can access the class can
access any of its features with public
visibility.
Only operations within the class can access
features with private visibility.
Only operations within the classes, or within
children of the class, can access features
with protected visibility.
Any element that is in the same package as
the class, or in a nested subpackage, can
access any of its features with package
visibility.
6
Multiplicity:
Provides a concise way to express certain business constraints relating to “number of
things” participating in a relationship.
 Arrays – array of things
 Null values – an object that points “nowhere” versus an “empty” string
Examples:
Address[3]:String
an address is composed of an array of three Strings
Name[2..*]:String
a name is composed of two or more Strings
emailAddress[0..1]:String
an emailAddress is composed of one String or null
Operation Compartment:
Operations are functions that are bound to a particular class. As such, they have all of the
same characteristics of functions:
 Name
 Parameter list
 Return type
Syntax:
Operation signature
visibility name (parameterName : parameterType, …) : returnType
parameter list
7
Anatomy of an Analysis Class:


Analysis classes should present a very “high level” set of attributes. They
indicate the attributes that the resultant design classes probably have.
Analysis class operations specify, at a high level, the key services that the class
must offer. In design, they will become actual, implementable methods.
However, one high-level operation will often break down into more than one
method.
A minimal form for an analysis class consists of the following:
 Name – this is mandatory.
 Attributes – attribute names are mandatory although only an important subset of
candidates may be modeled at this point. Attribute types are considered optional.
 Operations – in analysis, operations might just be very high-level statements of
the responsibilities of the class. Operation parameters and return types are only
shown where they are important for understanding the model.
 Visibility - generally not shown.
 Stereotypes – may be shown if they enhance the model.
BankAccount
Class Name
Attributes
Operations
number
owner
balance
deposit()
withdraw()
calculateInterest()
Analysis Class Rules of Thumb:
Here are some rules of thumb for creating well-formed analysis classes:



About three to five responsibilities per class – typically, classes should be kept as
simple as possible, and this usually limits the number of responsibilities that they
can support to between three to five.
No class stands alone – the essence of good OO analysis and design is that classes
collaborate with each other to deliver benefits to users. As such, each class
should be associated with a small number of other classes which it collaborates to
deliver the desired benefit. Classes my delegate some of their responsibilities to
“helper” classes which are dedicated to that specific function.
Beware of many very small classes – it can sometimes be hard to get the balance
right. If the model seems to have lots and lots of very small classes with just one
or two responsibilities each, then you should look at this very carefully with a
view to consolidating some of the small classes into larger ones.
8




Beware of few but very large classes – the converse of the above is a model that
has few classes, where many of them have a large number (> 5) of
responsibilities. The strategy here is to look at these classes in turn, and see if
each can be decomposed into two or more smaller classes.
Beware of “functoids” – a functoid is a really normal procedural function
disguised as a class.
Beware of omnipotent classes – these are classes that seem to do everything.
Look for classes that with “system” or “controller” in their name. The strategy
for dealing with this problem is to see if the responsibilities of the omnipotent
class fall into cohesive subsets. If so, perhaps each of these cohesive sets of
responsibilities can be factored out into a separate class. These smaller classes
would then collaborate to implement the behavior offered by the omni class.
Avoid deep inheritance trees – the essence of designing a food inheritance
hierarchy is that each level of abstraction in the hierarchy should have a welldefined purpose. In analysis, inheritance is only used where there is a clear, and
obvious, inheritance hierarchy arising directly from the problem domain.
Noun/Verb Analysis:



Look for noun or noun phrases – these are candidate classes or attributes
Look for verbs or verb phrases – these are candidate responsibilities or operations
The procedure is to collect relevant information and then to analyze it.
CRC (Class, Responsibilities, Collaborators) Analysis:
Phase 1: Brainstorm – gather information
The participants are OO analysts, stakeholders, and domain experts. The procedure is as
follows:
1. Explain that this is a true brainstorm.
a. All ideas are accepted as good ideas.
b. Ideas are recorded but not debated – never argue about something, just
write it down and then move on. Everything will be analyzed later.
2. Ask the team members to name the “things” that operate in their business domain
– i.e. customer, product
a. Write each thing down on a sticky note – it is a candidate class, or
attribute of a class.
b. Stick the note on a wall or whiteboard.
3. Ask the team to state the responsibilities that those things might have – record
these things in the responsibilities compartment of the note.
4. Working within the team, try to identify classes that might work together.
Rearrange the notes to reflect this organization and draw lines between them.
Alternatively, record collaborators in the collaborators compartment of the note.
9
Phase 2: Analyze information
1. Look for other sources of classes, such as physical objects, paperwork, interfaces
to the outside world, and conceptual entities.
2. Create a first cut analysis model:
a. Compare noun/verb analysis results with CRC results and the results of an
examination of other sources of classes.
b. Resolve synonyms and homonyms.
c. Consolidate results into a first cut analysis model.
10