Software Design & Architecture

2
 3

Abstract Classes

Abstract class is a class that can not be

instantiated, it exists extensively for inheritance
and it must be inherited. There are scenarios in
which it is useful to define classes that is not
intended to instantiate; because such classes
normally are used as base-classes in inheritance
hierarchies
 4

Inheritance

 It implies the functionality of data sharing between

super and sub class.

 All the data members and methods of super class are

available for use in sub class but not vice-versa.

 Subclass extends the functionality of super class to use

the base class methods.
 5

Polymorphism
 In the context of object-oriented programming, is the ability to
create a variable, a function, or an object that has more than one
form.

 Polymorphism is the ability to process objects differently

depending on their data types.

 Polymorphism is the ability to redefine methods for derived

classes.
 6

Types of Polymorphism

Compile time Polymorphism

Compile time Polymorphism also known as

method overloading

Method overloading means having two or more

methods with the same name but with different
signatures
 7

Example of Compile Time Polymorphism

 8

Runtime Polymorphism

Run time Polymorphism also known as method

overriding

Method overriding means having two or more

methods with the same name , same signature
but with different implementation
 9

Example of Run-time Polymorphism

 10

Example of Abstract class and Inheritance

In an object-oriented drawing application, you

can draw Triangle, rectangles and other graphic
objects. They have behavior commonality i-e
area calculation but implementation is
different.
 11

Abstract Class
Figure

Triangle Area
 12

Open / Close Principle

Bertrand Meyer:

“Software entities like classes, modules and

functions should be open for extension but
closed for modifications”
 13

 The “Open/Closed principle” – Usage in

an object oriented paradigm

The Open/Closed principle can be applied in be applied

in object oriented paradigms with the help of inheritance
and polymorphism:

 The interface of the module becomes an abstract

class A

 If needed new Subclasses of A can be derived; these

subclasses may extend A
14
15
 16

Example
 We have to implement the banking system such that there will be an
interface for the customer and the bank will be handling different type
of accounts in it like savings, current etc; each type of account is having
it’s own business logic to implement and policy. Bank foresee the
emergence of new type of accounts, we have to design the system
which should take into consideration the current requirements and
should be able to adopt to future changes.

 We have to design it using Open / Close Principle

 Provide Java coding for it, design client interface for opening
new account
17
 18

Unified Modelling Language (UML)

 Unified Modeling Language (UML) is a standardized
general-purpose modeling language in the field of
software engineering. The standard is managed, and was
created by, the Object Management Group.
 The Unified Modeling Language (UML) is used to
specify, visualize, modify, construct and document the
artifacts of an object-oriented software-intensive system
under development
 19

UML Continue
 UML offers a standard way to visualize a system's architectural
blueprints, including elements such as:
i. activities
ii. actors
iii. business processes
iv. database schemas
v. (logical) components
vi. programming language statements
vii. reusable software components.
20
 21

Categories of UML Diagrams (3)

Static
Use case diagram
Class diagram

Dynamic

Object diagram
State diagram
Activity diagram
Sequence diagram
Collaboration diagram
 22

Implementation

Component diagram
Deployment diagram
 23

Unified Modelling Language (UML)

 Unified Modeling Language (UML) is a standardized
general-purpose modeling language in the field of
software engineering. The standard is managed, and was
created by, the Object Management Group.

 The Unified Modeling Language (UML) is used to specify,

visualize, modify, construct and document the artifacts of
an object-oriented software-intensive system under
development
 24

UML Continue
 UML offers a standard way to visualize a system's architectural
blueprints, including elements such as:
i. activities
ii. actors
iii. business processes
iv. database schemas
v. (logical) components
vi. programming language statements
vii. reusable software components.
25
 26

Use Case Diagram

When looking at the system as a whole, Use Case
Analysis identifies all the major user of the system. It
is a functional description of the entire system.
Use case diagrams provide a high-level visual
representation of the major tasks that system
provides to the users.
 27

Use Cases
Actions on a system initiated by an actor. These
are the main tasks performed by each actor. Use
cases represent complete functionality of a task.
A use case describes a discrete, standalone
activity that an actor can perform to achieve
some outcome of value.
Example: Register for course
 28

Use Cases

Use Cases are the main tasks performed by the users

of the system.
Use Cases describe the behavioral aspects of the
system.
Use Cases are used to identify how the system will be
used.
Use Cases are a convenient way to document the
functions that the system must support.
Use Cases are used to identify the components
(classes) of the system.
 29

Roles in Use Case

Actor: A role that a user can play. An actor is a
person (or sometimes another software system
or a hardware device) that interacts with the
system to perform a use case.
Examples: instructor, advisor, student
Actors do not have to be human. An actor such as
a sensor may cause a system reaction.
An actor is always outside of the system
boundary, an external entity.
 30

User

Someone who uses the system. The same user

can play multiple roles
A user is an instance of an actor.
Example Prof. John Doe plays the role of an
instructor and the role of an advisor
 31

Views
• Two or more actors interacting with a use case

Example Register for Course involves both the

Student registering for the course and the
Registrars office sending out a notification for it.
Each actor views this task from a different
perspective.
 32

Use Case Diagram Symbols

 33

UML use case relationship symbols

 34

Include Relationship

A use case may include another use case. A

use case that is included is generally a
common behavior that many use cases may
need. One use case will use the services of
another use case.
 35

Extends

A use case may extend a use case by adding new

actions to the base use case.

Extension is on the basis of conditions attached

to it.
 36

Example - 1
• Use Case: “Take Customer Order”
Primary Flows:
i. Actor enters Customer details
ii. Identify either customer is new or existing one
iii. Actor enters code for product required
iv. System displays Product details
v. Actor enters quantity required
vi. Actor enters Payment details
vii. System saves Customer Order
viii. Customer may return faulty goods
 37

Alternative Flows:
In Case of Multiple products:

i. After step 5, when the Actor enters the

quantity required,
ii. Repeat steps 3 to 5 for additional Products
iii. Resume at step 6, to enter Payment details
 38

Possible Solution
 39

Example – II
Special Case: Customer specified product

At step 4, when the System displays the Product details, if

the product requires customer specified features,

1. Actor enters customer specified requirements, such as

size and color.

Resume basic flow at step 5, to enter quantity required,

2. At step 7 where the Customer Order is saved, the

additional customer-specific product details must also be
saved.
 40

Possible Solution
 41

Generalization
42
43