UNIVERSITY of GREENWICH

Design Class Diagrams.

Inheritance

Dr E. I. Popa
E. I. Teodorescu 1
UNIVERSITY of GREENWICH

Fundamental OO design questions

➢What objects?
➢What do the objects need to know
(attributes)
➢What do the objects need to do (operations)
➢Whom (other objects) do the objects need to
know (links, visibility)

E. I.DrTeodorescu
E. I. Popa 22
UNIVERSITY of GREENWICH

The process dimension

Number of steps to follow
Diagrams are related:
Use Case Diagram <-> Sequence diagrams (child)
Class Diagrams <-> Sequence diagrams (class
identification)
Sequence diagrams <-> Class diagrams (feed back
operations)
… more to come

E. I.DrTeodorescu
E. I. Popa 33
UNIVERSITY of GREENWICH

A possible process Implementation code:

code classes, their attribute
variables, methods and
visibility variables, UI,
storage etc..
Apply Patterns
Class Pseudocode

Design class diagrams: Pseudocode:

Design classes, their Class definition Pseudocode classes, their
attribute variables, methods
attributes, operations and and visibility variables and
visibility associations method logic

Start Conceptual class diagrams:

Business classes, their Interaction logic/ sequence
attributes and associations
Feed operations to classes
Requirements

and visibility/ also new classes

CRC Cards
Feed classes

Start Sequence Diagrams:

Use Case Diagrams: Scenatios, interactions
External classes between objects, State Chart Diagrams:
Explode Use cases
(Actors),external messages :events, States, transitions
interactions (Use Cases) operations, creation, (ebent/action) for each
destruction class

E. I.DrTeodorescu
E. I. Popa 44
UNIVERSITY of GREENWICH

Analysis vs. Design

Analysis models:
represent people, physical things and concepts
important to the application domain
show connections and interactions among these
people, things and relevant concepts
allow us to check whether the functions we will include
in the specification will satisfy the requirements
Design
Represents the system that needs to be built

E. I.DrTeodorescu
E. I. Popa 55
UNIVERSITY of GREENWICH

Design Class Diagrams (DCDs)

During analysis, emphasize domain concepts

During design, shift to software artifacts
a transition from what the system must do, to how
the system will do it
UML has no explicit notation for DCDs
Uniform UML notation supports smoother
development from analysis to design
Parts of UML are more useful for capturing
analysis models (e.g. Use case diagrams)
E. I.DrTeodorescu
E. I. Popa 66
UNIVERSITY of GREENWICH

Class diagrams: Analysis vs design

Conceptual : analysis level
Logical
Business classes and associations
Design
Physical
Design / implementation
more UI, storage etc specific
Can be different or..
Derived gradually from each other

E. I.DrTeodorescu
E. I. Popa 77
UNIVERSITY of GREENWICH

Conceptual model vs.

Design Class Diagram – differences?
To create and evolve a conceptual class diagram, you need to iteratively
model:
Good candidates for Business/ Model Classes
entity classes : these are relevant things in the domain
Responsibilities
Some Associations
Some Composition and aggregation associations
Inheritance relationships -maybe
To create and evolve a design class diagram, you need to iteratively model:
All necessary classes
Including Boundary/Interface classes and Control classes
Responsibilities
All Associations
All Composition and aggregation associations
Inheritance relationships

E. I.DrTeodorescu
E.Figure
I. Popa 16.2 88
UNIVERSITY of GREENWICH

Example of a analysis class vs design class

E. I.DrTeodorescu
E. I. Popa 99
UNIVERSITY of GREENWICH

Design classes
At design level
Most of analysis classes will be kept in the class diagram
entity classes - people, places, events, and things about which
the system will capture information
they need to be revised/completed
However, discard classes for concepts which:
Are beyond the scope of the analysis
Refer to the system as a whole
Duplicate other classes
Are too vague or too specific
e.g. have too many or too few instances
every entity class full behaviour is defined
Set visibility for each all the class’ elements

E. I.DrTeodorescu
E. I. Popa 10
10
UNIVERSITY of GREENWICH

Design classes
At design level
more classes are introduced
Become necessary when designing sequence diagrams
specific objects like databases or windows and forms
that are used to build the system
Improve the design in terms of maintainability,
usability, flexibility
Introduced when applying patterns –next lecture
Introduced by a specific programming environment

E. I.DrTeodorescu
E. I. Popa 11
11
UNIVERSITY of GREENWICH

Adding behavior and new class example

myUI myPerson
UI Person
aUser
Click
:NameGenerator
[If Name selected] answerName():String
CreateName()
[If Sex Selected] answerGender():String

[If Age Selected] answerAge():String

findAge():int

UI Person
NameGenerator
-Name: string 1 1
*
-Gender: string
-Age:int
Ask_Click() +AnswerGender()
+AnswerName() +Create Name()
E. I.+AnswerAge()
E. I.DrTeodorescu
Popa 12
12
-findAge()
UNIVERSITY of GREENWICH

Visibility
Encapsulation: Data and methods “live” together.
Main visibility types for attributes and methods
Public : is directly accessible by any instance of a class.
Private: can only be accessed by an instance of the
class that includes it.
Other classes cannot access it and directly make changes to
it.
Protected: can only be used by instances of that class
or of a subclass.

E. I.DrTeodorescu
E. I. Popa 13
13
UNIVERSITY of GREENWICH

Visibility. Public or private?

Public makes the methods available to other pieces of
program
Private: nobody can access the private variables.
private string Name
private string gender
private int age
Fields (variables)
public Person() Person()
constructor constructor
public string answer_name() answer_name()
public string answer_age() answer_gender()
public string answer_gender() answer_age()
private int find_age()
methods
methods

Class Person seen by the programmer Object seen by other pieces of program

E. I.DrTeodorescu
E. I. Popa 14
14
UNIVERSITY of GREENWICH

Using Access Modifiers to Implement

Encapsulation: Data Fields
As a general rule, no instance variables should be declared public
Any changes to the object's state (its variables) should be accomplished
by that object's methods
We should make it difficult, if not impossible, for one object to "reach
in" and directly alter another object's state
public private

Violate Encapsulation
variables Enforce encapsulation
Unless properties

provide services to clients –support

for other methods
methods example, other classes in the class

E. I.DrTeodorescu
E. I. Popa 15
15
UNIVERSITY of GREENWICH

Visibility comes from sequence diagrams

Who sends messages to whom?

<<UI>> <<Business>> <<Business>>

cmdStrokePet aPerson thePet
Button Person Pet
aUser
click
stroke_pet():String make_a_noise():String

Animal Noise

<<Business>>
Person
-Name:String
-Surname:String
-Sex:int <<Business>>
-yob:int Pet
-breed:int
+answer_name():String
+answer_gender():String +make_a_noise():String
+answer_age():String
-find_age():int
E. I.DrTeodorescu
+stroke_pet():String
E. I. Popa 16
16
UNIVERSITY of GREENWICH

Class Diagram
visibility One way association. Objects of the class
Private Person need to call messages of objects
of the class Pet but not vice versa.
Public
<<Business>>
Person <<Business>>
Pet
-Name:String 1 owns 0..1
-Surname:String -breed:int
-Sex:int
-yob:int +make_a_noise():String
+answer_name():String
+answer_sex():String
+answer_age():String
-find_age():int
+stroke_pet():String

E. I.DrTeodorescu
E. I. Popa 17
17
UNIVERSITY of GREENWICH

Relationships between classes

association: a usage relationship
association
aggregation
composition
generalisation: an inheritance relationship
inheritance between classes

E. I.DrTeodorescu
E. I. Popa 18
18
UNIVERSITY of GREENWICH

Links & Associations

There are instances of associations, just as there
are instances of classes
Instances of a classes are called objects;
Instances of associations are called links in UML
A Link is a physical or conceptual connection
between object instances.
Example: “Elena owns Jassie”
An association describes a group of links with
common structure and semantics
Example: “A Person owns a Pet”
E. I.DrTeodorescu
E. I. Popa 19
19
UNIVERSITY of GREENWICH

Relationship Example
Person
What attribute does
Person implicitly contain?

0..1 owner
Naming the association,
or the roles
How does owns
navigability
clarify this design? 0..*
Pet

E. I.DrTeodorescu
E. I. Popa 20
20
UNIVERSITY of GREENWICH

Multiplicity
Shows how many instances of 1 Class Exactly one
one class can relate to a single
instance of an associated class * Class Many (zero or more)
Similar to relationships in ERD’s
We can specify: 0..1
Class Optional (zero or one)

an exact number (just write it: 1)

A range of numbers using two 1..* Class
One or more
dots between the numbers (1..2)
an arbitrary,unspecified number,
1..4,100..*
using * Class
Numerically specified

A combination of the above

comma delimited

E. I.DrTeodorescu
E. I. Popa 21
21
UNIVERSITY of GREENWICH

Aggregation
Aggregation: a specialized form of Programme
association
is known as a “part of” or containment
relationship and follows the “has a” 1..*
heuristic
whole-parts
6..*
the part(s) can “live” without the whole
Course

E. I.DrTeodorescu
E. I. Popa 22
22
UNIVERSITY of GREENWICH

Composition
Composition: is a stronger version of
aggregation Board
the “part(s)” may belong to only ONE
whole
The whole strongly owns its parts
1
the part(s) are usually expected to
“live” and “die” with the whole
9
Square

E. I.DrTeodorescu
E. I. Popa 23
23
UNIVERSITY of GREENWICH

Developing a from Conceptual Class Diagram

to Design Class Diagram:
1. Identify software classes
2. Include the attributes from the domain model
3. Include obvious methods
4. Add methods
—from interaction diagrams
—conceptual class & interaction diagrams
in parallel

E. I.DrTeodorescu
E. I. Popa 24
24
UNIVERSITY of GREENWICH

Developing a from Conceptual Class

Diagram to Design Class Diagram:
6. Adding classes
7. Removing classes (that are not used)
8. Add associations and navigability
—Navigability implies visibility of attributes
9. Adding dependency relationships
10.Check / add Association
• Including aggregation and composition
11.Interfaces Classes
—Interface is a predefined «stereotype»

E. I.DrTeodorescu
E. I. Popa 25
25
UNIVERSITY of GREENWICH

Inheritance

Dr E. I. Popa
E. I. Teodorescu 26
UNIVERSITY of GREENWICH

More relationships between classes/objects

Inheritance

Inheritance – the concept wherein:

methods and/or attributes defined in an object class
can be inherited or reused by another object class.
A class can add new variables and functionality on top
of the inherited one

Used terms: Generalisation/ Specialisation

E. I.DrTeodorescu
E. I. Popa 27
27
UNIVERSITY of GREENWICH

Inheritance
A Generalization follows a “is a” or “is a kind of”
heuristic from a specialization class to the
generalization class. (e.g., student “is a” person,
video “is a kind of” item).
Common attributes, operations and relationships are
located in the generalization class and are inherited by
the specialization classes
Unique attributes, operations and relationships are
located in the specialization classes.

E. I.DrTeodorescu
E. I. Popa 28
28
UNIVERSITY of GREENWICH

UML
Representation
of
Generalization/
Specialization

Super

E. I.DrTeodorescu
E. I. Popa 29
29
UNIVERSITY of GREENWICH

Specialization

Superclass or parent class - Person

Subtclass or child class – Student

E. I.DrTeodorescu
E. I. Popa 30
30
UNIVERSITY of GREENWICH

Poor Generalization Example

(violates the “is a” or “is a kind of” heuristic)

Person
attributes
operations

Arm Leg Head

attributes attributes attributes

operations operations operations

E. I.DrTeodorescu
E. I. Popa 31
31
UNIVERSITY of GREENWICH

Visibility modifiers: protected

A class can be used in two ways:
for creating instances of the class,
for creating subclasses by extending the class.
Although we want to hide the attributes of a
superclass from ordinary clients, we usually want
to make them visible in the subclass.
Members should be
private if they are not intended for use from outside
the class.
public if they are intended for the users of the class.
protected if they are intended for the extenders of
the class but not for the users of the class.

E. I.DrTeodorescu
E. I. Popa 32
32
UNIVERSITY of GREENWICH

Overriding methods
Subclasses inherit those superclass members
declared as public or protected
Subclasses don't inherit a superclass's member if
the member is declared private
In the case of member variables, the member variable
in the subclass hides the one in the superclass.
In the case of methods, the method in the subclass
overrides the one in the superclass.
Polymorphism – the concept that different objects can
respond to the same message in different ways.

E. I.DrTeodorescu
E. I. Popa 33
33
UNIVERSITY of GREENWICH

Abstract Classes
Must be a superclass
Often, the superclass does not have a "meaning" or does
not directly relate to a "thing" in the real world
represents an abstract concept that does not exist "as
is" in the real world (e.g. Animal, Vehicle, Shape)
abstract classes cannot be instantiated
Because it contains at least one abstract method

Vehicle
Abstract superclass:

Car Boat

E. I.DrTeodorescu
E. I. Popa 34
34
UNIVERSITY of GREENWICH

Abstract Methods
An abstract method is one to which a signature has been
provided, but no implementation for that method is
given.
An abstract method is just a placeholder
no meaningful implementation for that method
Any class which contains an abstract method MUST also
be abstract
you cannot instantiate abstract objects
Abstract classes can contain both concrete and abstract
methods.
Who should provide the implementation for an abstract
method?

E. I.DrTeodorescu
E. I. Popa 35
35
UNIVERSITY of GREENWICH

Abstract Method Example

Example: a Vehicle's number of wheels can be computed,
but there is no meaningful implementation that can be
defined within the Vehicle class.
How the no of wheels is computed is dependent on
the vehicle's type
Note: This is polymorphism.
Vehicle Note:
an abstract method is shown
+computeNoWheels(): int in italics or you can use
{abstract} after its name

Car Train
+ computeNoWheels(): int + computeNoWheels(): int

E. I.DrTeodorescu
E. I. Popa 36
36
UNIVERSITY of GREENWICH

Polymorphism
The third pillar of object-oriented programming,
after encapsulation and inheritance
literally means "having multiple shapes“
Create objects that have more than one form.
At run time, objects of a child class may be treated
as objects of a parent class
For example in places such as method parameters and
collections or arrays.
When this occurs, the object's declared type is no longer
identical to its run-time type.

E. I.DrTeodorescu
E. I. Popa 37
37
UNIVERSITY of GREENWICH

Inheritance/ polymorphism Example

(all about frogs)
A frog has a frog behaviour
however, when a frog is young it is really a
tadpole and the behaviour is very immature
what do you expect from a tadpole? Probably a
tadpole behaviour
But frogs grow, as everything with time (maybe
not in size, but definitely in age and hopefully in
wisdom)
So when a frog grows, we would expect a different
behaviour - an adult frog behaviour

E. I.DrTeodorescu
E. I. Popa 38
38
UNIVERSITY of GREENWICH

A class diagram for frogs

<<abstract>>
Frog FrogBehaviour

-Behaviour: FrogBehaviour *
+growUp():bool
+grow ():void + abstract: grow();
+abstract: swim();

<<concrete>>
TadpoleBehaviour <<concrete>>
AdultFrogBehaviour
+growUp():bool
+ grow(); + grow();
+swim(); +swim();

E. I.DrTeodorescu
E. I. Popa 39
39
UNIVERSITY of GREENWICH

Froggy Notes
Composition.
A frog behaviour would not exist without frogs (a frog
has a behaviour).
Polymorphism
Frogs have more than 1 behaviour (well, if they live
long enough)
Both tadpoles and adult frogs grow, but...
Only tadpoles need some growing up - to be come adult
frogs
Tadpoles and frogs grow and swim in different ways

E. I.DrTeodorescu
E. I. Popa 40
40
UNIVERSITY of GREENWICH

Guidelines for Designing Classes

Containment versus Inheritance
Class A “Has-A” Class B
Class A “Is-A” “Is-A-Kind-Of” Class B
“Is-A-Kind-Of” - is it really inheritance?
Be careful not to over use abstract classes
Every abstract class increases the complexity of your
design
Every subclass increases the complexity of your design
Ensure that you receive acceptable return in terms of
functionality given the added complexity.

E. I.DrTeodorescu
E. I. Popa 41
41
UNIVERSITY of GREENWICH

Is-a or Has-a ?
Inheritance vs. Aggregation/Composition
It is advisable to use inheritance, if you need to reuse
almost all of the functionality of a class without major
changes.
use aggregation if you need to override many methods (to
avoid an illogical situations)
What happens if requirements change (which is very
likely)?
Your choice (inheritance/aggregation) can be a wrong one
and changing your design at later stages is difficult
Inheritance tends to be a worse choice as it’s more
constraining – but it does have its place!

E. I.DrTeodorescu
E. I. Popa 42
42
UNIVERSITY of GREENWICH

Is-a or Has-a ?
Inheritance vs. Aggregation/Composition
Bill Venners: That extra flexibility of composition over
inheritance is what I’ve observed, and it’s something I’ve
always had difficulty explaining.
Erich Gamma: We call this black box reuse. You have a
container, and you plug in some smaller objects. […] The
increased flexibility comes from the fact that you can
plug-in different strategy objects and, moreovers, that
you can even change the strategy objects dynamically at
run-time.

more to read: http://www.javaworld.com/article/2076814/core-

java/inheritance-versus-composition--which-one-should-you-choose-
.html

E. I.DrTeodorescu
E. I. Popa 43
43
UNIVERSITY of GREENWICH

The end

Dr E. I. Popa
E. I. Teodorescu 44