OOP Principles UML Class Diagrams: Object-Oriented Software Development SE 450 - Winter 2021

OOP Principles
UML Class Diagrams

Object-oriented Software Development
SE 450– Winter 2021
Vahid Alizadeh
Week 4
January 28, 2021
Announcements
Object-oriented Software Development – SE 450 – Winter 2021

2
Mid Term Exam
February 4, 2021
6 PM – 9 PM

3
Object-oriented Programming Principles
ABSTRACTION

5
Abstraction
▪Abstraction
• Real-life examples
• Driving a car, Expanding or remodeling a house (Completing the
incomplete work!)
• Abstract classes = incomplete classes

• Abstract methods = has declaration, no implementation
• Subclass must finish the incomplete tasks
• Used to define a generalized form shared between subclasses.
• A class that contains at least one abstract method must be
marked as an abstract class.
▪Example [package oopPrinciples.abstraction]

• An abstract class can also contain completed methods.
• Subclass may or may not override these completed methods.

6
Abstraction Discussions
▪ You can implement the concept of runtime polymorphism here as well.
▪ Abstract class can contain fields.
▪ You can use any type of access modifier in an abstract class.
▪ Must mark a class as abstract even with only one abstract method.
▪ You cannot create objects from an abstract class.
▪ If a class extends an abstract class, it must implement all the abstract methods.
• (Top Code Example)
▪ A concrete class is a class that is not abstract
▪ You cannot mark a method with both abstract and final keywords. Why?
▪ Constructors cannot be final or abstract or static. Why?
▪ You cannot reduce the visibility of an inherited method

• (Bottom Code Example)
• The access modifier of an overriding method must provide at least as much access as the
overridden method itself.

7
Interface
▪Interface
• A special type in Java
• Contains method signatures to define specifications
• Subtypes must follow the specifications
• Declares What to implement, not How to implement
• All methods are defined without body
• May contain only final fields
• Syntax:
• Using interface, we can support multiple inheritance in Java.
▪Example [package oopPrinciples.abstraction]

8
Interface Discussions
▪Abstract class using interface
• The class that is using the interface must implement all the
methods. If not, it is an abstract.
• Example [package oopPrinciples.abstraction.discussion]
▪Extend and implement at the same time

• positional notation:
• Extend before Implement
• Following this design, the compiler knows about the parent class first
and can point out any compilation errors in the parent class.

9
▪Multiple Inheritance using interface

• Interfaces’ names are separated by commas
• The method names can be the same and implementation
class provides a common implementation.

10
▪Interface can inherit but not implement another interface.

▪Note:
• An interface can extend multiple interfaces.
• A class cannot extend from multiple parent classes,
• A class can implement multiple interfaces.

11
Default Methods in Interfaces
▪After Java 8, you can have a method with body in an

interface.
• Default keyword
▪Example [package oopPrinciples.abstraction.discussion]
▪You can override the default method in your

implementation class. (Uncomment lines 24-28)

12
Avoiding Diamond Problem in Interfaces with Default Methods
▪How to avoid the diamond problem?

• If a class implementing from multiple interfaces, and
each interface has same default method, the class must
override it.
▪Example [package oopPrinciples.abstraction.discussion]

• You can call the default interface method like follows:

13
▪ You cannot make an interface final.
1
▪ You can use abstract before interface method (Optional) (Snippet 1)
• Interfaces by default are abstract.
▪ You can use constants inside an interface. (Snippets 2 and 3)

• They are public, static, and final by default.
▪ You cannot inherit an interface from a class.

▪ Difference between abstract class and interface?
• Concrete methods with default keyword
• Abstract can have only one parent and can extend abstract or concrete classes
• Interface can have multiple parents and can only extend interfaces.
Compile and Decompile

• Interface members are by default public.
• Variables in interface are by default static final.
▪ Summary of the interface’s benefits.

• Polymorphism, Multiple inheritance, loosely coupled systems, parallel
developments
▪ Summary of this section..

14
ENCAPSULATION

15
Encapsulation
▪Encapsulation
• Wrapping code and data together into a single unit
• What should you encapsulate in code?
• “Whatever changes encapsulate it”
• Why use encapsulation? Advantages?

• Establish the freedom of the client programmer
• Separating the interface from the implementation
• Read-only and Write-only classes
• Control over data
▪Encapsulation has both:

• Information hiding : Via access control modifiers
• Implementation hiding : Via creation of interface for a class
▪Encapsulation vs Abstraction
• Abstraction is more about ‘What‘ a class can do. [Idea]
• Encapsulation is more about ‘How‘ to achieve that functionality. [Implementation]
16
An overview of 4 pillars of OOP

17
Inheritance

18
Polymorphism

19
Abstraction

20
Encapsulation

21
Software Documentation
Types

22
Software Development Life Cycle
Planning 02
01 Analysis
Software 03
Maintenance
Development
Design
06 Life Cycle
(SDLC)
Testing &
Integration 04
Implementation
05
23
Types of documentation

26
Design Documentation
UML

27
UML Origin & History
▪Unified Modeling Language

• visual modeling language
• specifying, visualizing, constructing, and documenting
▪UML 1.0
• 1997
• HP, IBM, Microsoft, Oracle, …
▪UML 2.5
• Current version
▪https://www.uml-diagrams.org/ Source: visual-paradigm.com
• Version History
• Complete References & Examples

28
UML Building Blocks
▪UML building blocks
• Things
• Structural things
• Class, Object, Interface, Collaboration, Use case, Actor, Component, Node
• Behavioral things
• State Machine, Activity Diagram, Interaction Diagram
• Grouping things
• Package
• Annotational things
• Note
• Relationships
• Dependency, Association, Generalization, Realization
• Diagrams
• Structural Diagram
• Behavioral Diagram
• Interaction Diagram

29
UML Diagram Types
UML Diagram Types

▪Structure diagrams
• Objects
• Static view Structural Diagrams
• Class Diagram
▪Behavioral diagrams • Component Diagram
• Deployment Diagram
• objects interaction • Object Diagram
• Package Diagram
• Dynamic view • Profile Diagram
• Composite Structure Diagram
• Interaction Diagrams
• flow between various use case elements of a system
Behavioral Diagrams
• Use Case Diagram
• Activity Diagram
• State Machine Diagram
• Interaction Diagrams
• Interaction Overview Diagram
• Sequence Diagram
• Communication Diagram
• Timing Diagram
30
UML Class Diagram
▪What is UML Class Diagram?
• static view of an application | types of objects |
relationships between them
▪Purpose?
• analyses and designs | responsibilities | base for
other diagrams | forward and reverse eng.
▪Benefits?
• complex systems | reduces the maintenance time |
better understanding | desired code | helpful for the
stakeholders
General Java C++
▪Components
• Upper Section Name Name Name
Class Diagram Example: Order System
• Middle Section State Variable Members
Source: visual-paradigm.com
• Lower Section
Behavior Methods Functions

31
Class Diagram Relationships
▪Relationships
• Dependency
Dependency
• One class is dependent to another class

• “Uses-a”
Association
• Dotted line with arrowhead
• Generalization Multiplicity
Summary of types of relationships and their notation

• Inheritance Aggregation
• “Is-a-kind-of”, “is-a”
• Association Composition
• “Has-a”
• Aggregation
• “Has-a”, “is part of”
• Composition
• has-a”, “part of”, “belongs-to” Generalization

32
Dependency
▪Dependency
• Denotes dependence between classes
A B
• Temporary
• “uses a”
• Dotted line with arrowhead A depends on B
• Always directed (Class A depends on B) A uses object of class B
• Caused by class methods. Maybe caused by:
• Local variable
• Parameter
• Return value
• Method in Class A temporarily “uses an” object of type

Class B
• Change in Class B may affect class A Example: Class Driver depends on Class Car

33
Generalization
▪Generalization
• Denotes inheritance between classes
• “is a” relationship
• Solid line with open (triangular) arrowhead
Example: Laptop, Desktop, PDA inherit state & behavior from Computers
▪Generalization vs Specialization
▪Generalization vs Inheritance

34
Realization/Implementation
▪Realization/Implementation A «B»
• Denotes class implements Java interface
• Dotted line with open (triangular) arrowhead
A implements interface B

35
Association
▪Association
• permanent, structural relationship
• State of class A contains class B
Car and Engine classes know about each other
• Represented by solid line (arrowhead optional)
▪Navigation
• Represented by solid line with arrowhead
• Denotes “has-a” relationship between classes
• Example:
• “Gas Pedal” has an “Engine”
Gas Pedal class knows about Engine class
• State of Gas Pedal class contains instance of Engine class and can
Engine class doesn’t know about Gas Pedal class
invoke its methods

36
Multiplicity (Cardinality) of Associations
▪Multiplicity
▪Many to One
• Denotes how many objects
▪Notation
• Bank has many ATMs, ATM knows only 1 bank
•* => 0, 1, or more
▪One-to-many
•7 => exactly 7
• 3..8 => between 3 and 8, inclusive
• 2..* => 2 or more
Example: A house has exactly one kitchen, exactly one
bath, at least one bedroom (can have many), exactly
• Inventory has many items, items know 1 inventory one mailbox, and at most one mortgage (zero or one).

37
Aggregation
▪Aggregation
• Special kind of association
• whole- part model
• unidirectional (One-way) relationship

• “Has-a”, “is part of”
• Only one class is dependent on the other

• Both the entries can survive individually
• Illustrate composition with a hollow diamond
• The diamond end points toward the "whole" class
▪When to use Inheritance and Aggregation?

• Use property/behavior without modification or add functionality >
Aggregation
• Use and modify property/behavior and add functionality >
Inheritance

38
Composition
▪Composition
• “has-a”, “part of”, “belongs-to”
• Stricter form of aggregation
• Two classes are mutually dependent
• Cannot exist without each other / life span are same a class Car cannot exist without Engine,
it won't be functional anymore
• Illustrate composition with a filled diamond
• The diamond end points toward the "whole" class

40
Association vs. Aggregation vs. Composition
Attributes Aggregation Composition
Aggregation is denoted by a straight line with one end of The composition is denoted by a straight line with a full
Definition
the null-diamonded arrow mark. diamonded arrow mark at one end.
Dependency It explains the section of the association relationship. It explains the section of the aggregation relationship.
Type of Relationship The relationship established is very delicate. The relationship established is definitely strong.
In aggregation, the related objects are present In composition, the related objects are nor present within the
Associate Objects
independently within the entire system. entire system.
The linked objects present in the system are independent The linked objects present in the system are dependent on other
Linked Objects
to other objects. objects.
Deletion of one element in the aggregation doesn’t impact The deletion of one object impacts the presence of the other
Deletion of Objects
the other components present in the associative section. related objects in the compression.
For the proper functioning of a car, the wheel is a If an image is placed in a document and that document gets
mandatory element. But it doesn’t require the same wheel deleted, the image cannot be found again or used. The image
Examples
for the operation of the car. Even other wheels can be residing in the document also gets deleted at the same time at
substituted. the time of document deletion.
Representation

41
Relationships Comparison with Example
▪Dependency (references)
▪Association (has-a)
▪Aggregation (has-a + whole-part)
▪Composition (has-a + whole-part + ownership)

42
Describing class and attributes
▪Class attribute syntax

43
Describing class constructor
▪Method parameter syntax

44
Describing class methods

45
More Methods

46
Visibility of Class Members

47
Connections between classes
▪Connections
• Shown as arrows
• Show direction

48

49

50
Exercise
▪Tickets and Show Class Diagram
▪Implement the classes in this diagram

51
Exercise: Solution

52
Connection with no arrows

53
Connection with no arrows

54
Exercise
▪Student and university diagram

55
Exercise: Solution

56
Describing Inheritance with UML
▪Arrow with a triangle head
▪Points to the class being inherited from

57
Inheritance of Abstract Classes
▪Add the description <<abstract>> above the name of
the class.

58
Exercise
▪Player and Bot class diagram.

59
Exercise: Solution

60
Describing Interfaces with UML
▪<<interface>> NameOfTheInterface
▪Implement an interface with dashed arrows and a

triangle arrowhead.

61
Exercise
▪Interface Saveable and Class Person.
▪Implement this class diagram.

62
Exercise: Solution

63
Exercise
▪A larger diagram example.
▪Implement this class diagram.

64
Exercise: Solution

65
UML Examples: Veterinary System
▪Read UML class diagram
▪Try to understand relationships
1 or more Pets associated with 1 PetOwner

66
UML Examples: Computer System
• 1 CPU associated with 0 or more Controllers

• 1-4 DiskDrives associated with 1 SCSIController
• SCSIController is a (specialized) Controller

67
UML Examples: Banking System
• 1 Bank associated with 0 or more Accounts

• Checking, Savings, MoneyMarket are Accounts

68
UML Examples: Home Heating System
• Each Thermostat has 1 Room

• Each Thermostat associated with 0 or more Heaters
• ElectricHeater is a specialized Heater
• AubeTH101D is a specialized Thermostat

69
UML Examples: Printing System

70
UML Examples: Large Banking System

71
Resources
UML

73
UML - Tools & Utilities
▪ UML Tools List @ Wiki
▪ Desktop
• Your IDE (https://www.jetbrains.com/help/idea/class-diagram.html)
• Code Iris Plugin
• Sketch It Plugin
• PlantUML Plugin
• Modelio
• StarUML
• ArgoUML
• Umbrello UML Modeller
• Acceleo
• UMLdesigner
• PlantUML
▪ Online
• yuml.me
• GenMyModel
• visual-paradigm
• MS Visio
• Creately
• Draw.io
74
UML Cheat Sheets
▪UML RefCard from Dzone

• reference card, covers all major diagrams
• Uploaded on D2L
▪Microsoft Model References and Guidelines
▪Allen Holub’s Cheat sheet

• https://holub.com/uml/
• PDF version on D2L

75
UML Books
▪UML Distilled: A Brief Guide to the Standard Object Modeling

Language 3rd Edition (Link)
▪UML for Java Programmers (Link)
▪Enterprise Java with UML (Link)
▪Applying UML and Patterns: An Introduction to Object-Oriented

Analysis and Design and Iterative Development (Link)
▪Designing Software Architectures: A Practical Approach (Link)

76
81
Any Question
????????????????

82
83

OOP Principles UML Class Diagrams: Object-Oriented Software Development SE 450 - Winter 2021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOP Principles UML Class Diagrams: Object-Oriented Software Development SE 450 - Winter 2021

Uploaded by

Copyright:

Available Formats

OOP Principles

UML Class Diagrams

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

• Abstract classes = incomplete classes

▪Example [package oopPrinciples.abstraction]

Object-oriented Software Development – SE 450 – Winter 2021

▪ Abstract class can contain fields.

▪ You can use any type of access modifier in an abstract class.

▪ You cannot create objects from an abstract class.

▪ A concrete class is a class that is not abstract

▪ Constructors cannot be final or abstract or static. Why?

▪ You cannot reduce the visibility of an inherited method

Object-oriented Software Development – SE 450 – Winter 2021

▪Example [package oopPrinciples.abstraction]

Object-oriented Software Development – SE 450 – Winter 2021

▪Extend and implement at the same time

Object-oriented Software Development – SE 450 – Winter 2021

▪Multiple Inheritance using interface

Object-oriented Software Development – SE 450 – Winter 2021

▪Interface can inherit but not implement another interface.

Object-oriented Software Development – SE 450 – Winter 2021

▪After Java 8, you can have a method with body in an

▪Example [package oopPrinciples.abstraction.discussion]

▪You can override the default method in your

Object-oriented Software Development – SE 450 – Winter 2021

▪How to avoid the diamond problem?

▪Example [package oopPrinciples.abstraction.discussion]

Object-oriented Software Development – SE 450 – Winter 2021

▪ You can use constants inside an interface. (Snippets 2 and 3)

▪ You cannot inherit an interface from a class.

Compile and Decompile

▪ Summary of the interface’s benefits.

▪ Summary of this section..

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

• Why use encapsulation? Advantages?

▪Encapsulation has both:

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

▪Unified Modeling Language

▪https://www.uml-diagrams.org/ Source: visual-paradigm.com

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

UML Diagram Types

Object-oriented Software Development – SE 450 – Winter 2021

• One class is dependent to another class

Summary of types of relationships and their notation

Object-oriented Software Development – SE 450 – Winter 2021

• Method in Class A temporarily “uses an” object of type

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

Object-oriented Software Development – SE 450 – Winter 2021

• unidirectional (One-way) relationship