EAST WEST INSTITUTE OF TECHNOLOGY

# 63 Off Magadi Main Road, Vishwaneedam Post, Bangalore-91

(Affiliated to VTU, Belagavi, Approved by AICTE, New Delhi & Recognized by Govt. of Karnataka)

Department of INFORMATION Science and Engineering

SADP NOTES
(17IS72)

VII Semester B.E

Prepared by,
Mr. Sanju D J
Asst. Prof
Dept. of ISE
Software Architecture and Design Patterns (17IS72)

Module 1 - Introduction
Design pattern
“A proven solution to a common problem in a specified context”

Example: We can light a candle if light goes out at night

Christopher Alexander (Civil Engineer) in 1977 wrote

“A pattern describes a problem which occurs over and over again in our environment, and
then describes the core of the solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same way twice”

Essential Elements:

The pattern name is a handle we can use to describe a design problem, its solutions, and
consequences in a word or two.

The problem describes when to apply the pattern.

The solution describes the elements that make up the design, their relationships,
responsibilities, and collaborations. The pattern provides an abstract description of a design
problem and how a general arrangement of classes and objects solves it.

The consequences are the results and trade-offs of applying the pattern.

Example Pattern:

Pattern Name – Iterator

Problem – How to serve Patients at a Doctor’s Clinic

Solution – Front-desk manages the order for patients to be called

 By Appointment
 By Order of Arrival
 By Extending Gratitude
 By Exception

Consequences

 Patient Satisfaction
 Clinic’s Efficiency
 Doctor’s Productivity

7th Semester, Department of ISE Page : 2

Software Architecture and Design Patterns (17IS72)

Describing Design Patterns

Pattern Name & Classification – Conveys the essence of the pattern concisely

Intent – What design issue the pattern addresses

Also Known As – Other well-known names for this pattern

Motivation – A scenario illustrating a design problem and how it’s being solved by the
pattern

Applicability – Known situations where the pattern can be applied

Structure – OMT (Object Modelling Technique) based graphic representation of the classes
in the pattern

Participants – Classes and objects in the pattern with their responsibilities

Collaborations – How the participants collaborate to carry out their responsibilities

Consequences –

 How does the pattern support its objectives?

 What are the trade-offs and results of using the pattern?
 What aspect of system structure does it let you vary independently?

Implementation – Hints on implementation of the pattern like language dependency

 What pitfalls, hints, or techniques should you be aware of when implementing the
pattern?
 Are there language-specific issues?

Sample Code – Code fragments to implement the pattern in specific language (C++or C# or
java).

Known Uses – Examples of the pattern found in real systems.

Related Patterns – Other patterns closely related with the pattern under consideration

 What design patterns are closely related to this one?

 What are the important differences?
 With which other patterns should this one be used?

7th Semester, Department of ISE Page : 3

Software Architecture and Design Patterns (17IS72)

The Catalog of Design Pattern

Abstract Factory: Provide an interface for creating families of related or dependent objects
without specifying their concrete classes.

Adapter:

 Convert the inter face of a class into another interface client’s expect.
 Adapter lets classes work together

Bridge: Decouple an abstraction from its implementation so that two can vary independently.

Builder: Separates the construction of the complex object from its representation so that the
same construction process can create different representations.

Chain of Responsibility: Avoid coupling the sender of a request to it‘s receiver by giving
more than one object a chance to handle the request. Chain the receiving objects and pass the
request along the chain until objects handles it.

Command: Encapsulate a request as an object, thereby letting parameterize clients with

different request, queue or log requests, and support undoable operations.

Composite: Compose objects into tree structures to represent part-whole hierarchies.

Composite lets clients treat individual objects and compositions of objects uniformly.

Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a

flexible alternative to sub classing for extending functionality.

Façade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a

higher-level interface that makes the subsystem easier to use.

Factory Method: Defines an interface for creating an object ,but let subclasses decide which
class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Flyweight: Use sharing to support large numbers of fine-grained objects efficiently.

Interpreter: For the given language, it defines the representation of its grammar to interpret
sentences in the language.

Iterator: Provide a way to access the element of an aggregate object sequentially without
exposing its underlying representation.

Mediator: Define an object that encapsulates how a set of objects interact. Mediator
promotes loose coupling of objects and allows to vary their interaction independently.

Memento: Without violating encapsulation, capture and externalize an object‘s internal state
so that object can be restored to this state later.

Observer: Define a one-to-many dependency between objects so that when one object
changes state, all it‘s dependents are notified and updated automatically.

7th Semester, Department of ISE Page : 4

Software Architecture and Design Patterns (17IS72)

Prototype: Create new objects by copying existing objects.

Proxy: Provide a surrogate or placeholder (substitute) to control the access to the original
object.

Singleton: Ensure a class has only one instance, and provide a point of access to it.

State: Allow an object to alter its behavior when its internal state changes. The object will
appear to change its class

Strategy: Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Template Method: Define the Skelton of an operation, deferring some steps to subclasses.
Template method subclasses redefine certain steps of an algorithm without changing the
algorithms structure

Visitor: Represent an operation to be performed on the elements of an object structure.

Visitor lets you define a new operation without changing the classes of the elements on which
it operates.

Organizing the Catalog

We classify the design patterns by two criteria.

The first criterion, called purpose, reflects what a pattern does.

1. Creational patterns concern the process of object creation.

2. Structural patterns deal with the composition of classes or objects.

3. Behavioral patterns characterize the ways in which classes or objects interact and
distribute responsibility.

The second criterion, called scope,

 Specifies whether the pattern applies primarily to classes or to objects.

 Class patterns deal with relationships between classes and their subclasses.

 These relationships are established through inheritance, so they are static— fixed at
compile-time.

 Object patterns deal with object relationships, which can be changed at run-time and
are more dynamic.

7th Semester, Department of ISE Page : 5

 Software Architecture and Design Patterns (17IS72)

How Design Patterns solve design problems

 Finding Appropriate Objects

 Determining Object Granularity
 Specifying Object Interfaces
 Specifying Object Implementations
 Class versus Interface Inheritance
 Programming to an Interface, not an Implementation
 Putting Reuse Mechanisms to Work
 Relating Run-Time and Compile-Time Structures
 Designing for Change

1. Finding Appropriate Objects

 An object packages both data and the procedures (code), where the Procedures are the
methods or operations to be performed.
 Objects are encapsulated during the execution and therefore objects cannot be
accessed directly, and its representation is invisible from outside.
 Decomposing a system into objects is the hard part because the parameters like
encapsulation, granularity, dependency, flexibility, performance, evolution,
reusability era to be considered in the object-oriented design.
 Object-oriented design methodologies includes different approaches
 We can write problem statement, single out nouns and verbs, and create
corresponding classes and operations

7th Semester, Department of ISE Page : 6

 Software Architecture and Design Patterns (17IS72)

 Focus the collaborations and responsibilities in the system

 Strict modeling of the real world and translating the objects found during
analysis into design.
 Object-oriented design end up with low level classes like arrays
 The abstractions are necessary to make the design flexible
 Design pattern helps us to identify less-obvious abstractions.
 Strategy pattern describes how to implement interchangeable families of
algorithms.
 State pattern represents each state of an entity as an object

2. Determining Object Granularity

 Objects can vary tremendously in size and number
 Facade pattern describes how to represent subsystems as objects
 Flyweight pattern describes how to support huge numbers of objects
 Abstract Factory and Builder take the responsibilities of creating other objects
 Visitor and Command pattern implement a request on another object or group of
objects.

7th Semester, Department of ISE Page : 7

 Software Architecture and Design Patterns (17IS72)

3. Specifying Object Interfaces

 Every operation declared by an object specifies: the operation's name, the objects it
takes as parameters, and the operation's return value. This is known as the
operation's signature.
 The set of all signatures defined by an object's operations is called the interface to
the object.
 Any request that matches a signature in the object's interface may be sent to the
object.
 A type is a name used to denote a particular interface.
 Subtype inheriting the interface of its Supertype.
 Objects are known only through their interfaces.
 The run-time association of a request to an object and one of its operations is
known as dynamic binding.
 Design patterns help programmers to define interfaces by identifying their key
elements and the kind of data that get sent across an interface. A design pattern can
also tell what not to put in the interface

Interface:

 Set of all signatures defined by an object’s operations

 Any request matching a signature in the objects interface can be sent to the object
 Interfaces may contain other interfaces as subsets
Type:
 Denotes a particular interfaces
 An object may have many types
 Widely different object may share a type
 Objects of the same type need only share parts of their interfaces
 A subtype contains the interface of its super type

Dynamic Binding, Polymorphism

Binding

 Operation to be performed depends on the request and the object

 Run-time association of a request to an object and this operation is known as dynamic
binding
 Requests does not allow to a particular implementation until run-time

Polymorphism

 Simplifies the definitions of Clients

 Decouples the objects from each other
 Objects vary their relationships to each other at run-time

7th Semester, Department of ISE Page : 8

 Software Architecture and Design Patterns (17IS72)

An object’s implementation is defined by its class

The class specifies the object‘s internal data and defines the operations the object can
perform

Objects is created by instantiating a class

 An object = An instance of a class

Class inheritance

 Parent class and subclass

Memento Pattern define two interfaces

 Restricted one that lets clients hold and copy

 Privileged one that only the original object can reuse to store and retrieve state

Decorator and Proxy patterns are used for interfaces of objects

Visitor is used to reflect all classes of objects that visitors can visit

4. Specifying Object Implementations

 An object's implementation is defined by its class.
 The class specifies the object's internal data and representation and defines the
operations that the object can perform.
 A dashed arrowhead line indicates a class that instantiates objects of another class.
The arrow points to the class of the instantiated objects.

7th Semester, Department of ISE Page : 9

Software Architecture and Design Patterns (17IS72)

Inheritance
 New classes can be defined in terms of existing classes using class inheritance. When
a subclass inherits from a parent class, it includes the definitions of all the data and
operations that the parent class defines. Objects that are instances of the subclass will
contain all data defined by the subclass and its parent classes.
 We indicate the subclass relationship with a vertical line and a triangle.
Abstract Class

 Abstract Class is one whose main purpose is to define a common interface for its
subclasses. The operations that an abstract class declares but doesn't implement are
called abstract operations.
 The names of abstract classes appear in slanted type. Slanted type is also used to
denote abstract operations.
 The implementation of the operation is represented by dog-eared box, the code will
appear connected with a dashed line to the operation it implements

7th Semester, Department of ISE Page : 10

Software Architecture and Design Patterns (17IS72)

Concrete classes

 Classes that are not abstract are called concrete classes

 A concrete classes implement creation methods of the abstract factory

Override an operation

 Subclasses override an operation defined by its parent classes

 Subclasses redefines the behavoirs of their parent classes

Mixin Class

A Mixin class is a class that's intended to provide an optional interface or functionality to

other classes. Mixin classes require multiple inheritances

Augmented class:

Allows user to create own projects without having any previous knowledge

7th Semester, Department of ISE Page : 11

 Software Architecture and Design Patterns (17IS72)

5. Class versus Interface Inheritance

 The class defines the object's internal state and the implementation of its operations.
 In contrast, an object's type only refers to its interface—the set of requests to which
it can respond.
 An object can have many types, and objects of different classes can have the same
type.
 An object is an instance of a class; we imply that the object supports the interface
defined by the class.
 Class inheritance defines an object's implementation in terms of another object's
implementation.
 Interface inheritance (or subtyping) describes when an object can be used in place
of another.

Examples: Chain of Responsibility, Composite pattern, Command, Observer, State, and

Strategy.

6. Programming to an Interface, not an Implementation

 Class inheritance is a mechanism for extending an application's functionality by
reusing functionality in parent classes.
 When inheritance is used all classes derived from an abstract class will share its
interface.
 All subclasses can then respond to the requests in the interface of this abstract class

Benefits

 Clients remain unaware of the specific types of objects they use

 Clients remain unaware of the classes that implement these objects, clients only
know about the abstract classes defining the interface.

7th Semester, Department of ISE Page : 12

 Software Architecture and Design Patterns (17IS72)

This leads to the first principle of reusable object-oriented design:

Instantiation of Concrete classes

 Abstract Factory, Builder, Factor method, Prototype and Singleton are the
creational patterns
 Creational patterns ensures that the system is written in terms of interfaces, not
implementations
7. Putting Reuse Mechanisms to work
The challenge lies in applying the concepts like objects, interfaces, classes and inheritance
to build the design patterns to be flexible and reusable

 Inheritance versus Composition

 Delegation

 Inheritance versus Parameterized Types

Inheritance verses composition

 Two techniques for reusing the functionality in object-oriented systems are class
inheritance and object composition

 class inheritance

 White-box reuse

 object composition

 Black-box reuse

White-box reuse:

 Reuse by sub classing (class inheritance)

 Internals of parent classes are often visible to subclasses

 works statically, compile-time approach

 Inheritance breaks encapsulation

Black-box reuse:

 Reuse by object composition

 Requires objects to have well-defined interfaces

 No internal details of objects are visible

7th Semester, Department of ISE Page : 13

Software Architecture and Design Patterns (17IS72)

 Class inheritance define the implementation of one class in terms of the other
 Class inheritance: Reuse by sub classing is often referred to as “white-box reuse”.
 The term "white-box" refers to visibility: With inheritance, the internals of parent classes
are often visible to subclasses.
 Defined at compile-time. and straightforward to use
 “Inheritance breaks encapsulation” (superclass implementation exposed to subclasses)

Advantages

 Static, straightforward to use

 Make the implementations being reuse more easily

Disadvantages

 The implementations inherited can’t be changed at run time, because inheritance is

defined at compile time

 Parent classes often define at least part of their subclasses physical representation

 Breaks encapsulation

 Implementation dependencies can cause problems(limits flexibility and reusability)

when we try to reuse a subclass

Object composition:

New functionality is obtained by assembling or composing objects to get more complex

functionality. This style of reuse is called “black-box reuse”, because no internal details of
objects are visible.

 Defined at run-time by objects acquiring references to other objects.

 Must program to interfaces, so interfaces must be well thought-out and stable.

 Emphasis on interface stability encourages granular objects with single

responsibilities

Delegation

In delegation, two objects are involved in handling a request: receiving object delegates
operations to its delegate

7th Semester, Department of ISE Page : 14

Software Architecture and Design Patterns (17IS72)

 Advantages: Makes it easy to compose behaviors at run-time and to change the way
they are composed.
 Disadvantages: Dynamic, highly parameterized software is harder to understand than
more static software and there are also run-time inefficiencies
 Delegation is a good design choice only when it simplifies more than it complicates
 Delegation is an extreme example of object composition

Example: Several design patterns use delegation, such as:

a. State: Here an object delegates requests to a State object that represents its current
state
b. Strategy: Here an object delegates a specific request to an object that represents a
strategy for carrying out the request.

Inheritance versus Parameterized Types

 Another technique for reusing functionality is through parameterized types, also
known as generics in ADA and templates in C++
 Allows to define a type without specifying all the other types it uses, the unspecified
types are supplied as parameters at the point of use
 For example :
 To declare a list of integers, we supply the type "integer" as a parameter
 To declare a list of String objects, we supply the "String" type as a parameter.
 Parameterized types, generics, or templates
 Parameterized types gives us a third way to compose behavior in object-oriented
systems
 Many designs can be implemented using any of these three techniques.

7th Semester, Department of ISE Page : 15

 Software Architecture and Design Patterns (17IS72)

 An operation implemented by subclasses (an application of Template Method)

 The responsibility of an object that is passed to the sorting routine (Strategy)
 An argument of a C++ template or Ada generic that specifies the name of the
function is called to compare the elements.
 There are important differences between these techniques.
 Object composition lets us to change the behavior being composed at run-time,
but it requires indirection and can be less efficient
 Inheritance lets us to provide default implementations for operations and lets
subclasses override them
 Parameterized types let us to change the types that a class can use

8. Relating Run-Time and Compile-Time Structures

 An object-oriented program’s run-time structure often bears little resemblance to its
code structure
 The code structure is frozen at compile-time
 A program’s run-time structure consists of rapidly changing networks of
communicating objects

 Aggregation versus Acquaintance (Association)

Aggregation
 Aggregation implies that one object owns or responsible for another object
 Aggregation implies that an aggregate object and its owner have identical
lifetimes
 Generally we speak of an object having or being part of another object.
 Aggregation relationships tend to be permanent than acquaintance.
Acquaintance
 Acquaintance implies that an object merely knows of another object
 Acquainted objects request operations of each other, but they are not
responsible for each other.
 Acquaintance is a weaker relationship than aggregation and suggests much
looser coupling between the objects
 Acquaintances are made and remade more frequently,
 Sometimes Acquaintance is called "Association" or the "using" relationship.

 The distinction between acquaintance and aggregation is determined more by intent

than by explicit language mechanisms
 The system‘s run-time structure must be imposed more by the designer than the
language

7th Semester, Department of ISE Page : 16

 Software Architecture and Design Patterns (17IS72)

9. Designing for Change

 The key to maximizing reuse lies in anticipating new requirements and changes to
existing requirements, and in designing your systems so that they can evolve
accordingly.
 A design that doesn‘t take change into account risks major redesign in the future
 These changes involve class redefinition and reimplementation, client modification and
retesting
 Redesign affects many parts of the software system and unanticipated changes are
invariably expensive
 Design patterns help us to avoid this by ensuring that a system can change in specific
ways
 Each design pattern lets some aspect of system structure vary independently of other
aspects

 Here are some common causes of redesign along with the design pattern( s) that
address them:

Common Causes of Redesign

 Creating an object by specifying a class explicitly

 Dependence on specific operations

 Dependence on hardware and software platform

 Dependence on object representations or implementations

 Algorithmic dependencies

 Tight coupling

 Extending functionality by sub classing

 Inability to alter classes conveniently

7th Semester, Department of ISE Page : 17

Software Architecture and Design Patterns (17IS72)

Creating an object by specifying a class explicitly: Specifying a class name when you create
an object commits you to a particular implementation instead of a particular interface.

Dependence on specific operations: When you specify a particular operation, you commit to
one way of satisfying a request. By avoiding hard-coded requests, you make it easier to
change the way a request gets satisfied both at compile-time and at run-time.

Dependence on hardware and software platform: External operating system interfaces and
application programming interfaces (APIs) are different on different hardware and software
platforms. Software that depends on a particular platform will be harder to port to other
platforms. It may even be difficult to keep it up to date on its native platform. It's important
therefore to design your system to limit its platform dependencies.

Dependence on object representations or implementations: Clients that know how an

object is represented, stored, located, or implemented might need to be changed when the
object changes. Hiding this information from clients keeps changes from cascading.

Algorithmic dependencies: Algorithms are often extended, optimized, and replaced during
development and reuse. Objects that depend on an algorithm will have to change when the
algorithm changes. Therefore algorithms that are likely to change should be isolated.

Tight coupling: Classes that are tightly coupled are hard to reuse in isolation, since they
depend on each other. Tight coupling leads to monolithic systems, where you can't change or
remove a class without understanding and changing many other classes.

Extending functionality by subclassing: Customizing an object by sub classing often isn't

easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.).
Defining a subclass also requires an in-depth understanding of the parent class. For example,
overriding one operation might require overriding another.

Inability to alter classes conveniently: Sometimes you have to modify a class that can't be
modified conveniently. Perhaps you need the source code and don't have it (as may be the
case with a commercial class library).

Design patterns in Application programs

 If you're building an application program such as a document editor or spreadsheet,

then internal reuse, maintainability, and extension are high priorities.
 Internal reuse ensures that you don't design and implement any more than you have
to.

• Design patterns that reduce dependencies can increase internal reuse.

• Design patterns also make an application more maintainable when they are used to
limit platform dependencies and to layer a system

• Looser coupling boosts the likelihood that one class of object can cooperate with
several others

7th Semester, Department of ISE Page : 18

Software Architecture and Design Patterns (17IS72)

• Reduced coupling also enhances extensibility

For example, when you eliminated dependencies on specific operations by isolating and
encapsulating each operation, you make it easier to reuse an operation in different contexts.

Design patterns in Toolkits

 A toolkit is a set of related and reusable classes designed to provide useful, general-
purpose functionality.

 An example of a toolkit is a set of collection classes for lists, associative tables, stacks,
and the like.

 The C++ I/O stream library is another example.

 Toolkits emphasize code reuse

 Toolkits are the object-oriented equivalent of subroutine libraries

 Toolkit design is arguably harder than application design

 Toolkits don't impose a particular design on your application; they just provide
functionality that can help your application do its job.

 Toolkit design is arguably harder than application design, because toolkits have to work
in many applications to be useful.

 Moreover, the toolkit writer isn't in a position to know what those applications will be or
their special needs.

Design patterns in Frameworks

 A framework is a set of cooperating classes that makeup a reusable design for a specific
class of software.

 For example, a framework can be geared toward building graphical editors for different
domains like artistic drawing, music composition, and mechanical.

 Another framework can help you build compilers for different programming languages
and target machines.

 We can customize a framework to a particular application by creating application-specific

subclasses of abstract classes from the framework

 The framework dictates the architecture of the application. It will define the overall
structure; it’s partitioning into classes and objects, the key responsibilities thereof, how
the classes and objects collaborate, and the thread of control.

 The framework captures the design decisions that are common to its application domain.

7th Semester, Department of ISE Page : 19

Software Architecture and Design Patterns (17IS72)

 Frameworks thus emphasize design reuse over code reuse, though a framework will
usually include concrete subclasses you can put to work immediately.

 Frameworks emphasize design reuse over code reuse

 When we use a toolkit, we can write the main body of the application and call the code
which we want to reuse. When we use a framework, we reuse the main body and write
the code it calls.

 Advantages: Builds an application faster, easier to maintain, and more consistent to their
users

 Mature frameworks usually incorporate several design patterns

 The patterns help make the framework's architecture suitable to many different
applications without redesign

 An added benefit comes when the framework is documented with the design patterns it
uses.

 People who know the patterns gain insight into the framework faster.

 Even people who don't know the patterns can benefit from the structure they lend to the
framework's documentation.

 Enhancing documentation is important for all types of software, but it's particularly
important for frameworks.

 Frameworks often pose a steep learning curve that must be overcome before they're
useful.

Differences between framework and design pattern

Patterns and frameworks differ in three ways

1. Design patterns are more abstract than frameworks

 Frameworks can be embodied in code, but only examples of patterns can be embodied
in code.

 A strength of frameworks is that they ca n be written down in programming languages

and not only studied but executed and reused directly.

 Design patterns also explain the intent, trade-offs, and consequences of a design.

2. Design patterns are smaller architectural elements than frameworks

A typical framework contains several design patterns, but the reverse is never true.

7th Semester, Department of ISE Page : 20

Software Architecture and Design Patterns (17IS72)

3. Design patterns are less specialized than frameworks

 Frameworks always have a particular application domain.

 In contrast, the design patterns in this catalo g can be used in nearly any kind of
application.

How to Select a Design Pattern

 Consider how design patterns solve design Problems

 Scan Intent sections

 Study how patterns interrelate

 Study patterns of like purpose

 Examine a Cause of redesign

 Consider what should be variable in the design

Consider how design patterns solve design problems.

Determine object granularity; specify object interfaces, and several other ways in which
design patterns solve design problems.

Scan Intent sections

Read through each pattern's intent (purpose) to find one or more that should relevant to your
problem.

Study how patterns interrelate

Studying these relationships can help direct you to the right pattern or group of patterns.

Study patterns of like purpose

Study only those patterns which are of specific purposes ( creational patterns, structural
patterns, and behavioural patterns).

Examine a cause of redesign.

Look at the patterns that help you avoid the causes of redesign

Consider what should be variable in your design.

Consider what you want to be able to change without redesign.

7th Semester, Department of ISE Page : 21

Software Architecture and Design Patterns (17IS72)

How to Use a Design Pattern

 Read the pattern once through for an overview.

 Go back and study the Structure, Participants and Collaborations sections.

 Look at the Sample Code section to see a concrete

 Example of the pattern in code.

 Choose names for pattern participants that are meaningful in the application context.

 Define the classes.

 Define Application-specific names for operations in the Pattern

 Implement the operations to carry out responsibilities and collaborations in the

pattern.

1. Read overview of pattern

Pay attention to the Applicability and Consequences sections to ensure the pattern

is right for your problem.

2. Go back and study the Structure, Participants, and Collaborations sections

Make sure you understand the classes and objects in the pattern and how they relate

to one another.

3. Look at the Sample Code section to see a concrete example of the pattern in code

Helps you learn how to implement the pattern.

4. Choose names for pattern participants that are meaningful in the application context

It is useful to incorporate the participant name into the name that appears in the

application.

5. Define the classes

Declare their interfaces, establish their inheritance relationships, and define the

instance variables that represent data and object references.

6. Define application-specific names for operations in the pattern

Use the responsibilities and collaborations associated with each operation as a

guide. Also, be consistent in your naming conventions

7th Semester, Department of ISE Page : 22

Software Architecture and Design Patterns (17IS72)

7. Implement the operations to carry out the responsibilities and collaborations in the
pattern

The implementation section offers hints to guide you in the implementation.

7th Semester, Department of ISE Page : 23

Software Architecture and Design Patterns (17IS72)

What is Object-Oriented Development?

First computers

• First computers are developed mainly to automate a well-defined process (i.e., an

algorithm) for numerical computation, as systems became more complex, its
effectiveness in developing solutions became suspect.

• software applications developed in later years had two differentiating characteristics:

 Behavior that was hard to characterize as a process

 Requirements of reliability, performance, and cost that the original developers

did not face

• The ‘process-centred’ approach to software development used what is called top

down functional decomposition.

 The first step in such a design was to recognize what the process had to deliver
which was followed by decomposition of the process into functional modules.

 Structures to store data were defined and the computation was carried out by
invoking the modules, which performed some computation on the stored data
elements.

 The life of a process-centred design was short because changes to the process
specification required a change in the entire program.

 This resulted in an inability to reuse existing code without considerable

overhead

• Thus engineering disciplines started soon after, and the disciplines of ‘software
design’ and ‘software engineering’ came into existence.

• The reasons for this success are easy to see:

 Easily understandable designs

 Similar (standard) solutions for a host of problems

 An easily accessible and well-defined ‘library’ of ‘building-blocks’

 Interchangeability of components across systems,

 A software component is also capable of storing data,

 The components can also communicate with each other as needed to complete
the process

7th Semester, Department of ISE Page : 24

Software Architecture and Design Patterns (17IS72)

Key Concepts of Object-Oriented Design

1. The Central Role of Objects

2. The notion of a Class

3. Abstract specification of functionality

4. A language to define the System

5. Standard Solutions

6. An analysis process to model a system

7. The notions of extendibility and adaptability

Other Related Concepts

Modular Design and Encapsulation

Modular Design

 Modularity refers to the idea of putting together a large system by developing a

number of distinct components, independently and then integrating these to provide
the required functionality.

 This approach is easier to understand than one that is designed as a monolithic

structure. Such a design must be modular.

 The system's functionality must be provided by well-designed, Cooperating modules.

 Each module must perform functionality that is clearly specified by an interface.

 The interface also defines how other components may interact or communicate with
the module.

 We would like that a module clearly specify what it does, but not expose its
implementation. This separation of concerns gives rise to the notion of encapsulation,

7th Semester, Department of ISE Page : 25

Software Architecture and Design Patterns (17IS72)

Encapsulation

 Encapsulation, which means that the module hides details of its implementation from
external agents. Example of applying encapsulation.

 The abstract data type (ADT), is generalization of primitive data types such as
integers and characters.

 The programmer specifies the collection of operations on the data type and the data
structures that are needed for data storage.

 Users of the ADT perform the operations without concerning themselves with the
implementation.

Cohesion and Coupling

Cohesion

 Cohesion of a module tells us how well the entities within a module work together to
provide functionality. Cohesion is a measure of how focused the responsibilities of a
module are.

 If the responsibilities of a module are unrelated or varied and use different sets of
data, cohesion is reduced.

 Highly cohesive modules tend to be more reliable, reusable, and understandable than
less cohesive ones.

 In contrast, the worst approach would be to arbitrarily assign entities to modules,

resulting in a module whose constituents have no obvious relationship.

Coupling

 Coupling refers to how modules are dependent on each other.

 The very fact that we split a program into multiple modules introduces some coupling
into the system.

 Coupling could result because of several factors: a module may refer to variables
defined in another module or a module may call methods of another module and use
the return values.

 The amount of coupling between modules can vary.

 In general, if modules do not depend on each others implementation we say that the
coupling is low

 Low coupling allows us to modify a module without worrying changes on the rest of
the system.

7th Semester, Department of ISE Page : 26

Software Architecture and Design Patterns (17IS72)

 By contrast, high coupling means that changes in one module would necessitate
changes in other modules, which may make it harder to understand the code.

Modifiability and Testability

Modifiability

 The modification in software can be done to change both functionality and design.

 The ability to change the functionality of a component allows for systems to be more
adaptable;

 Improving the design through incremental change is accomplished by refactoring.

 In both cases, the organization of the system in terms of objects and classes has
helped develop systematic procedures that mitigate the risk.

Testability

 Testability refers to both falsifiability, and ease with which we can find bugs in

 Software and the extent to which the structure of the system facilitates the detection of
bugs.

Benefits and Drawbacks of the Paradigm

Advantages

1. Objects often reflect entities in application systems. This makes it easier for a
designer to come up with classes in the design. In a process-oriented design, it is
much harder to find such a connection that can simplify the initial design.

2. Object-orientation helps increase productivity through reuse of existing software.

Inheritance makes it relatively easy to extend and modify functionality provided by a
class. Language designers often supply extensive libraries that users can extend.

3. It is easier to accommodate changes. One of the difficulties with application

development is changing requirements. With some care taken during design, it is
possible to isolate the varying parts of a system into classes.

4. The ability to isolate changes, encapsulate data, and employ modularity reduces the
risks involved in system development.

7th Semester, Department of ISE Page : 27

Software Architecture and Design Patterns (17IS72)

Drawbacks

1. Object creation and destruction is expensive.

2. Interactions of many objects are complex Example: Banking application, Video game
that has often a large number of objects.

3. Objects tend to have complex associations, which can result in non-locality, leading to
poor memory access times.

4. Programmers and designers schooled in other paradigms, usually in the imperative

paradigm, find it difficult to learn and use object-oriented principles.

5. Programmers may need a year to start feeling comfortable with these concepts.

6. Some researchers are of the opinion that the programming environments also have
not kept up with research in language capabilities.

7. Editors and testing and debugging facilities do not directly support many of the
advances such as design patterns.

7th Semester, Department of ISE Page : 28

Software Architecture and Design Patterns (17IS72)

7th Semester, Department of ISE Page : 29