Debre Markos University

Institute : DmiT
Program: Software Engineering
Year: 4th
Course : Software Component Design
By Tilaye H.(MSc)
Address: Block 601 Office IV

1
 Chapter One

Introduction to the course

2
 Design :Primary Considerations
What is Design ?
 We have used this term in real life often. We say, we
design a specific device or we have a design of a
building.
 Design is the representation of something that is to be
built
 It is also a model for something
 Design has to be converted into implementation.
Design  Implementation

3
 Cont…
We first model the actual and conceptual model
that we call a design.
This design has to be then converted into
implementation. So design then gets converted
into implementation.
Therefore it is very important that we design such
that the design can be easily converted into
implementation

4
 Examples of design in real life
Blue prints for a building architecture
Manifests in the actual design of a building later
This has to be done the actual project has to be
executed as per the design
 A Plan for conducting a workshop
Workshop is executed as per a plan
You are conducting an event and the actual event is
your actual project or it is an implementation.
 E.g. conference program
Course syllabus
Course is taught to cover the syllabus

5
 Design In Software Engineering
There are two design approaches in Software
Engineering:-
a) Process Design:
 design for the process of carrying out
software development
b) Product Design:
 design of the product to be built

6
 Process Design
In software design you have design processes:
When do you actually design software?
 How do you go about designing?
How many people work on the design?
How do they go about designing?
Where do the start?
So you have to design this process itself.
Any process for that matter in the entire life cycle,
first you have to design.
Process design is an important discipline

7
 Process design cont…
It is a design for the process of carrying out software
development.
You need to design a process just as you design a product
itself. So product is different from a process.
The process is the one that brings out the product, but you
have to also design the process.
When you actually carry out the process then that is the
implementation of the process.
Therefore, you have to plan for the process and you actually
carry out the process which is the implementation of the
process

8
 Examples
Methodology selection
You might want to select the methodology that you
want to apply in your processes
 what tools you are going to use.
When you select the methodology your tools also
might follow your selection.
Project planning /execution plan
The entire project planning and how it is going to
be executed.

9
 Examples cont…
Process and documentation standards
 what are you going to follow in your entire software
development life cycle
Resource allocation charts
 when are you going to use your specific software engineer?
 where are you going to deploy them?
 Where are they going to work?
 On which site they are going to work?
 Which are the machines that will be kept aside for the
development?
 Which cabins that are going to be allot to your team?
 Where are they going to discuss?

10
 Examples cont…
Quality and reliability methods
 how do you ensure your quality of your software
development process and reliability of your
product?
 what are the different methods that would be
employed for quality and reliability methods.
Finally when you follow this design and follow this
method in your software development so that you
would get the good quality product which
implements what is desired and what is specified by
your software requirement specification.
11
 Product Design

When are you want describe our product

12
 What is covered in product design?
Product architecture
Subsystems, interconnections
Modules, packages and libraries
Components and classes
Files and executable binaries
Functions, data structures and algorithms
Tables
Interfaces
Concurrency ,parallelism and distribution
Networking , security architecture

13
 Cont…
Product architecture
 An Architecture is an overall design.
 It is a high level view of the design.
 Product architecture might be in terms of sub systems
and its components or various layers in your software
• Subsystems, interconnections
 You can design individual sub systems, what are the
ingredients of individual sub system and how they are
interconnected
Modules, packages and libraries
 Your design might consist of module design, package
design, and design of the libraries below the sub system
14
 Cont…
Components and classes
What about the specific individual classes and how
they are connected and how do they collaborate
what do they do. You can also talk of file level
design and executable binaries.
When you want to actually deploy your software,
you talk of executable binary.
You want to install your software and there are say,
in a typical UNIX system you would have /bin,
/user, /include and so on

15
 Cont…
Files and executables
 After deployment what is the architecture for this?
 What is the deployment architecture or what is the specific
design of your different files and how they are interconnected
 How the executables are organized ?
Functions, data structures and algorithms
 You have to design low level entities such as functions, data
structures and also algorithms.
 This is different from actually implementing them.
 Design is not a code but it is a high level specification
implementation that you are going to build

16
 Cont…
Tables
If you have a very data centric system where you
have persistent data in a typical business
application, you are developing your library
information system or you are developing your
academic system, then you have lot of data and
there are again relations among them.
You have tables, you can convert your models into
your relational table, you want to design them, a
table design or your data design

17
 Cont…
Interfaces
 at the high level (user level), this is the one interact with the
product? So does the user interact with the product?
 how the interfaces are organized and how the user is going to
interact with the software.
 Interface design is an important aspect of your entire software
design.
Concurrency, parallelism and distribution
 Which are the concurrent activities in your software?
 Are they also parallel, is there distribution?
 How are you going to distribute?
 What kind of architecture you have for the system?
 Is it a bus architecture or do you have ring architecture or do you have
mesh? If it is a parallel computing system, you may have further architecture
such as hypercube, specialized grids and so on
18
 Cont…
Networking, security architecture
 How are you going to network your systems?
What are the protocols that you are going to follow
and the physical and logical layer?
What is the security architecture?

19
 Analysis to Design
Designs are done after the analysis is done.
You have to come to design from the analysis and from
the design you go on to implementation
Analysis produces analysis models such as:
 E-R model
 Data flow model
 Use case model
 Agent oriented analysis models
Design models are built from analysis models
Design models then easily map to actual implementation
of the software
Note : designs are done after the analysis is done
Analysis Design Implementation
20
 Cont…
During analysis you have these products such as:
 The entity relationship model identifies the entities in the domain
and they are connected different relationships.
 Data flow model identifies the data and the flow of the data
through different processes.
 Use case model identifies how the user is going to interact with
the system.
 Agent oriented domain analysis model.
 What are the agents in the system and how they carry out different activities?
 Agents are mainly the animate agents; basically the human being.
 What activities do they carry out?
 If you want to automate something you want to automate an activity say
business model, then you have to first find out what are the different entities
and agents, how is it carried out currently and then you have to analyze the
system.
21
 Factors to Be Considered in Design
Does it meet the functional specification first of all? Is it
complete?
 How close is the design to the problem domain?
 Is it best possible design from performance point of view
within given constraints?
 is the analysis model traceable into corresponding design
model? Is there seamlessness ?
 Is there reuse?
 Is it well-structured?
 Is it evolvable?
 Is it well documented?
 Has it been reviewed?

22
 Factors
cont…
Does it meet the functional specification first of all? Is it
complete?
o Suppose in your library information system you want that the
fines must be automatically calculated and design does not
account for it, then the design is not complete.
o It is the most important fact that you have design for
everything.
o How do you make sure of it and who is going to test for this
the specification which may be in say plain English or in a
standard the IEEE software requirement standard?
o Somebody has to review and find out whether this design is
meeting the requirement.
o There are review processes to make sure that design meets
your specification it covers everything it is complete.
23
 Factors cont…
How close is the design to the problem domain?
o If the design is very close to the problem domain itself,
say for example you have objects such as books, users,
different floors, journals, CD ROMs, videos CDs in your
library system.
o In the design of the software, you could also have objects
which have the same name. Then it will be very easy for
even for the implementer to view what it is going to do.
o It is very close to the actual real life system
o this makes your design more understandable because it is
very close to the actual system how close is your design to
the actual problem domain and this is also sometimes
called seamlessness.
24 o Seamlessness -is a property of having no bump between
 Factors cont…
Is it best possible design from performance point of view
within given constraints?
o You may not always get the best design because your resources are
limited you have a deadline in front of you. So you have to make a
best attempt to get a high performance design which does not have
performance bottleneck.
o For example there is a server that accepts request from across the
internet. Everything has to come at the server and the server itself
executes the responses and sends them out.
o This one server which accepts all the requests and computes the
responses will be a bottleneck. Instead you could have gone for
parallelism and also distribution. So that in parallel you could have
carried out many activities and responded to many requests
simultaneously. You can make sure that your low level data is in
consistent state and you must get a high performance design even
with your resources and time constraints. This directly comes from
25 requirements specification
 Cont…
Is the analysis model traceable into corresponding
design model? Is there seamlessness ?
o Can you show how an entity in the entity relationship model
has been mapped on to another design entity?
o Where has it gone?
o Has it gone as an attribute in a class or has it become a class
itself or some collections of entities and relations being mapped
to tables or they being designed as separate table or data flow
diagrams or the data flow model, are the processes being
mapped to functions or they processes servers which are active
servers?
o A server typically goes in a loop. It is open for request as soon
as it gets a request it operates on the request and sends response
back. So you have to trace this analysis into your design.
26
 Cont…
Why is this important?
First of all the design is banking on the analysis model.
The analysis has to be converted into design and then whoever wants
to understand analysis and design, has to go through this if it is
traceable directly.
Again this traceability has to be seamless will not without bumps. If
you use the same methodology for design and analysis you might
benefit from seamlessness.
 For example if you apply object oriented analysis and design
processes, then use the same notations and same meta models for
your analysis and again use your same notations in your design. Then
there is seamlessness. So what do you start what do come up with
analysis you further refine and then it gets transformed into design.
So it has to be first traceable. And if possible, if its seamless that’s
also another advantage.
27
 Cont…
Is there reuse?
o when you design are you designing everything from scratch or
are you going to reuse some thing which you already have?
o When a software firm takes up a project, it may not be the first
time that it has taken up a project unless it is a startup firm.
o You carry out design often for different kind of projects and
different products. So when you get something new, are you
going to start from scratch or are you going to look at your
earlier results earlier designs
Is the design well structured ?
o How good the design is? Is there a good decomposition ?
o Is it very hard to understand the design?
o Are there too many interactions?
o One does not know where to start such designs are not good for
your health. You need to have a well structured design
28
 Cont…
Evolvability :
o Is it evolvable? This is very important because the
requirements also keep on changing quite often.
o The design should be evolvable and one should be able to
make a change into it very easily
o There are techniques to build evolvable design. For
example, if you have already structured your different
entities into a nice inheritance hierarchy, you will be able
to add a new subclass into inheritance hierarchy and
evolve the design.

29
 Cont…
Well documented
o Once should be able to take a design and should be able to
evolve a design.
o To be able to evolve, it has to be well documented.
o You must produce all the important documents or all the
documents for the design
o There are diagrammatic notations, you may also have text
based description, and you may also specify your designs.
There must not be any dark matter left out. If you document
well, then the rest can follow up on the documentation.
o Documentation is never for the sake of documentation. It is
for the sake of all the goodness properties that you want to
extract from a design such as, evolvability, maintainability
and understandability.
30
 Cont…
o You have to produce proper documentation.
o How to document top down approach must be taken.
o You must have high level document so that first quickly you
can grasp what the system is.
o After you grasp the whole system, you can then zoom on to
specific sub systems and then understand the system.
o You have to document the design.
o No dark matter in the software, you should not leave
something dark.
o Something that is not documented is dark because you do not
know what the system does.

31
 Cont…
Have you Reviewed the Design?
o You have to review your design so that you must
make sure that it is complete and you are not
missed out anything and so on.
o This is an important aspect of your design process.

32
 Process of complex system design
Decomposing /partitioning
o Split the system into many components
o Separation of concerns
Composition /coupling
o Connect the components and let them collaborate
to achieve the systems overall functionality

33
 Decomposition/partitioning
You might split this system into many components, but there might
be redundancies and lots of overlaps and it might result into a chaotic
situation.
 Nobody knows who is doing what. It has been decomposed and
some of random allocations of task have been done, but then there is
no good protocol or there is no consistency among themselves in
what they do.
Therefore, partition might be done that is very haphazard. Such a
system is not usable.
You have to separate the concern so that you have that modularity.
 Everyone does some specific task, it is not repeated elsewhere
and then they collaborate with each other. You have to
decompose into such systems.
34
 Typed of design approaches
There are two design approaches
1) Top-down approach
2) Bottom-up approach

35
 Top Down Design Approach
 Start from higher levels and decompose downwards identifying
connections/collaborations at every stage
 You start from a very high level design description and then
break it down further into different sub systems or modules and
then further break it down and go on designing that way
 Good for starting from a high level description and
understanding
 It is good for documentation, but most often if you don’t have
clear idea about your design, top-down design may not be
possible
 You may want to start at some top level go down and then you
get something new there and then again build up connect it back.
 Gives you good understanding of the problem
36
 Bottom Up Design Approach
• start from lower modules and then compose them
upwards
• Iterate upwards and downwards for refinements

37
 Composition /Interconnection
How do modules correspond with each other?
o What is the best way?
o How good is a given modular decomposition?
• Different ways of interconnecting
o E.g. peer to peer, client server, specialization,
generalization, aggregation, messaging, signals,
semaphores

38
 Composition ….
How can you have a system with many modules?
How good is a given modular decomposition?
What is the goodness property?
There are different ways for modules to interact.
You can have functional interfaces, if you have
processes, you have sockets, or you have remote
method invocations or you have services on internet,
amongst functions you call functions, function call,
there are recursions etc.

39
 Cont…
There are different ways of interaction and some of
these have been listed here.
There could be peer to peer interaction ‘A’
communicates with ‘B’ and ‘B’ also communicates
with ‘A’.
‘A’ can send a message to ‘B’ and ‘B’ can also send a
message to ‘A’.
This is not about just reply.
This is a message that originates and asks for a
service. A asks for B’s service and B asks for A’s
service. That is peer to peer way of connecting.
40
 Cont…
Client-server – the client asks the server to provide specific
service. They send out the message and the reply in return.
Specialization-generalization for interconnection. Inheritance,
type of connection
Aggregation for whole part
You have different ways of messaging, message queues,
sockets and black boards.
You have synchronization methods, signaling, semaphore,
monitor etc.
There are different ways of interconnecting system or
composing them. Once you have decomposed, you have to
connect them
41
 Cont…
The composition of the decomposed modules or the
entities, interconnections in collaborations among
them are very important.
There are different ways of making them collaborate
and there are different ways of connecting them.
People have studied different kinds of connectors and
we will use different kinds of connectors for
connecting different kinds of entities. Those have to
be considered in your design.
Now we will look at the basic principles that you
apply during the design.
42
 Basic principles to be applied during design
There are different principles to be taken during
design phase
Some of them are :
o Abstraction
o Encapsulation
o Refinement
o Communication

43
 Abstraction
An external view of a system
To understand the lover level system through abstraction
that is easy to comprehend
To manipulate or operate on a system through an abstract
interface
Operating specific buttons, you have washing machines
or you want to operate a microwave oven. So, you have
the external perspective or the interface. Therefore the
users abstraction is different.
For example a person who builds the microwave, his
abstractions may be different and principles of abstraction
has to be applied for different roles.
44
 Cont…
Abstraction is not only used for understanding but important for
manipulation
Example : in data structures like stack, you can think of stack in terms
of behavior of its push and pop method. Whatever is push goes on top
of the stack and whatever is pop comes out from top of the stack.
When you describe this behavior, you do not worry about how it is
implemented inside.
What is the data structure used for this stack? Is there a linked list or
is there a static data structure? How many pointers are you using?
How are you implementing them? How are you initializing? Are they
automatically initialized by the language itself?
These are the internal views. But when you want to describe the data
structure you want to describe it from abstract point of view or from
as you want to describe it as an abstraction rather than an
implementation.
45
 Examples of abstraction
Some examples are:
 Types and variables
 Functions
 Classes and objects
 Files and processes
 Control constructs
 Packages

46
 Cont…
Use these abstractions and then build similar programming
which is abstract programming. But for your given problem
domain you have to find out abstractions in the problem
domain. How do you describe these abstractions?
You can use abstract data types, you can describe them into
interfaces, and you can also describe the exceptions or the
exceptional behavior that the entity will project.
Describing abstractions
o Abstract data types
o Interfaces
o Exceptions
o Messaging protocols
o Contracts, preconditions and post conditions

47
 Cont…
Suppose you are asking for a service and if the server
is unable to provide that service, what is the behavior
that you expect from server is also the part of
abstraction because it is an externally observable
behavior exception that you are going to expect from
server.
What are the messaging protocols?
What we send first and what do you send later and
what is expected response?
The protocol, handshakes are also be part of the high
level view
48
 Cont…
Contracts that are provided, pre-conditions and
post-conditions:
When you ask for a service, what is expected from
you, what are the parameters that are expected from
you? and what is guaranteed to you in return?
Pre conditions and post conditions are also part of
contract or abstraction of the given entity.

49
 Encapsulation
Hiding lower layers
Security
Enforces abstraction
Examples: local state within local scope, non-
exported or invisible variables, private member
functions in object oriented classes or object oriented
program.
Therefore, encapsulation is a manifest. You want to
hide something so that you want to only project the
external abstraction that you have thought of to the
user and the internal implementations are hidden.
50
 Refinement
Iterative refinement of a given concept should be
easy to achieve without much redo work
E.g. 1 a software process with revisitable design
phase
o How do you refine?
o What are the principles of refining?
o What are the ways of refinement?
o How are you going to apply this into your designs?
In the above example, a software process with
revisit-able design phase you can come back again
and again in the process and you apply this
iterative refinement.
51
o Implementation is open for refinement but the
 Refinement ….
Inheritance and refinement
Open-close principles for components
o Implementation is open to refinement
o Inheritance is closed
o E.g. Next version of A component may be refined
with respect to implementation or specialized through
inheritance
o Changing the implementation without affecting the
contract or guaranteed for the outside user
Macroscopic Model vs. Microscopic model refinement
e.g. state diagrams(UML)  separate state
52
diagrams
 Cont…
Generic description to specific description
Different from inheritance
E.g. template classes or generic packages

53
 Refinement and change process
Change processes are provided to carry out
refinements
Example – inheritance mechanism
Encapsulation and separate compilation- enables
refinement of implementation
UML support for hierarchical state diagrams for
microscopic refinements

54
 Communication
Different kinds of interconnections called connectors
o For the components to collaborate and solve a
common problem of the system
Inter-class connectors(pointers, references), inter-
process connectors (sockets, proxies), inter-machine
connectors(TCP/IP, internet).

55
 Other kinds of communication
Shared memories /black boards
Synchronization
o Semaphores
o Message queues
o Monitors
o Signals and actions
Filters and pipes
 (Reading assignments)

56
 Design Patterns
Introduction to design patterns
The Gang of Four (GOF)
Benefits of design pattern
Components of a pattern
 Various patterns

57
 Design patterns …..
Motivation
The main motivation in using design patterns is to
minimize the design complexity of the system we are
building.
• Advantages to this include:
o Designs are more easily understood and
communicated
o More regular and simpler designs
o More capable analysis
o Shorter selection time
o Greater interoperability
o Enhanced re-use
58
 Architectural patterns and Design patterns
Architectural patterns only support limited portions of
software development and do not articulate why a system
is designed in a particular way, which complicates
subsequent software reuse and evolution.
We are interested in how an architect achieves particular
qualities. The quality requirements specify the responses of
the software to realize business goals. Our interest is in the
tactics used by the architect to create a design using design
patterns, architectural patterns, or architectural strategies.
Christopher Alexander's seminal and innovative work on
design patterns for architecture (the house-building kind)
served as the basis for the work on software design
patterns.
59
 Design patterns
A definition by Christopher Alexander (A Pattern Language,
1977)
 “Each 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 and over, without ever doing it in the same way twice”
A design pattern is a way of reusing abstract knowledge about a
problem and its solution.
A pattern is a description of the Problem and the
essence of its Solution.
Patterns solve specific design problems and make object-
oriented designs more flexible, elegant, and ultimately reusable.
Expert designers know to reuse solutions that have worked for
them in the past
60
 cont’d
• In Software Engineering, a design pattern is a general repeatable
solution to a commonly occurring problem in software design.
• A design pattern isn't a finished design that can be transformed
directly into code. It is a description or template for how to solve a
problem that can be used in many different situations.
• Design patterns represent the best practices used by
experienced object-oriented software developers
• Design patterns are solutions to general problems that
software developers faced during software development
• These solutions were obtained by trial and error by
numerous software developers over quite a substantial
period of time
• Learning these patterns helps unexperienced developers
to learn software design in an easy and faster way
61
 Who are the Gang Of Four
(GOF) ?
The Gang of Four are the authors of the book, "Design
Patterns: Elements of Reusable Object-Oriented
Software". This important book describes various
development techniques and pitfalls in addition to providing
twenty-three object-oriented programming design patterns.
The four authors were Erich Gamma, Richard
Helm, Ralph Johnson and John Vlissides.
These four authors initiated the concept of Design Pattern
in
Software development
These authors are collectively known as Gang of Four
(GOF).
62
 Benefits of design patterns
Design patterns make it easier to reuse successful designs
and architectures.
Expressing proven techniques as design patterns makes
them more accessible to developers of new systems.
Design patterns help you choose design alternatives that
make a system reusable and avoid alternatives that
compromise reusability.
Design patterns can even improve the documentation and
maintenance of existing systems by furnishing an explicit
specification of class and object interactions and their
underlying intent.
Design patterns help a designer get a design "right" faster!

63
 Elements of Design Patterns
Design pattern name: A meaningful pattern identifier. we can
use to describe a design problem, its solutions, and consequences
Problem description: Describes when to apply a pattern.
Explains the problem and the context.
Solution description:
o Describes the elements that make up the design, their relationships,
responsibilities, and collaborations.
o Does not represent a concrete design but a template for a design
solution that can be applied in many different situations.
• Consequences : The results and tradeoffs of applying the pattern.
They are critical for evaluating design alternatives and for
understanding the costs and benefits of applying the pattern.

64
 Application of design patterns
Wide variety of application domains:
o Drawing editors, banking, CAD, CAE, cellular
network
management, telecomm switches, program
visualization.
Wide variety of technical areas:
o User interface, communications, persistent
objects, O/S kernels, distributed systems.

65
 Types of Design Patterns

There are three basic types of design

66
 Creational design patterns
These design patterns provide a way to create objects while
hiding the creation logic, rather than instantiating objects
directly using operator.
This gives the program more flexible in deciding which objects
need to be created for a given use case.
Useful as system evolve: the classes that will be used in
the future may not be known now.
Examples
 Factory method

 Abstract factory
 Singleton
 Builder
 prototype
67
 Creational pattern…
Abstract Factory: The abstract factory pattern is used to
provide a client with a set of related or dependant objects.
The "family" of objects created by the factory are
determined at run-time.
Builder: The builder pattern is used to create complex
objects with constituent parts that must be created in the
same order or using a specific algorithm. An external class
controls the construction algorithm.
Factory Method: The factory pattern is used to replace
class constructors, abstracting the process of object
generation so that the type of the object instantiated can be
determined
68
 Cont’d
Prototype: The prototype pattern is used to
instantiate a new object by copying all of the
properties of an existing object, creating an
independent clone. This practice is particularly
useful when the construction of a new object is
inefficient.
Singleton: The singleton pattern ensures that only
one object of a particular class is ever created. All
further references to objects of the singleton class
refer to the same underlying instance.

69
 Structural Design Patterns
These design patterns concern class and object
composition.
Concept of inheritance is used to compose interfaces and
define ways to compose objects to obtain new
functionalities .
Ease the design by identifying a simple way to realize
relationships between entities
Techniques to compose objects to form larger structures
Example  Facade
 Adapter
 Flyweight
 Composite
 Proxy
 Decorator
 Bridge
70
 Cont’d
Adapter. The adapter pattern is used to provide a link
between two incompatible types by wrapping the
"adoptee" with a class that supports the interface required
by the client.
Bridge. The bridge pattern is used to separate the abstract
elements of a class from the implementation details,
providing the means to replace the implementation details
without modifying the abstraction.
Composite: used to create hierarchical, recursive tree
structures of related objects where any element of the
structure may be accessed and utilized in a standard
manner.
71
 Cont’d
Decorator. The decorator pattern is used to extend or alter the
functionality of objects at run-time by wrapping them in an object
of a decorator class. This provides a flexible alternative to
using inheritance to modify behavior.
Facade. The facade pattern is used to define a simplified interface
to a more complex subsystem.
Flyweight. The flyweight pattern is used to reduce the memory and
resource usage for complex models containing many hundreds,
thousands or hundreds of thousands of similar objects.
Proxy. The proxy pattern is used to provide a surrogate or
placeholder object, which references an underlying object. The
proxy provides the same public interface as the underlying subject
class, adding a level of indirection by accepting requests from a
client object and passing these to the real subject object as
72
necessary.
 Behavioral Design Patterns
These design patterns are specifically concerned with
communication between objects(common
communication patterns)
Describe complex control flow
Example
Chain of responsibilityState
Command Mediator
Iterator Observer
Interpreter Strategy
Template method
Memento
Visitor
73
 Cont’d
Chain of Responsibility. The chain of responsibility
pattern is used to process varied requests, each of
which may be dealt with by a different handler.
Command. The command pattern is used to express
a request, including the call to be made and all of its
required parameters, in a command object. The
command may then be executed immediately or held
for later use.
Interpreter. The interpreter pattern is used to define
the grammar for instructions that form part of a
language or notation, whilst allowing the grammar to
be easily extended.
74
 Cont’d
Iterator. Used to provide a standard interface for
traversing a collection of items in an aggregate object
without the need to understand its underlying structure.
Mediator. The mediator pattern is used to reduce
coupling between classes that communicate with each
other. Instead of classes communicating directly, and thus
requiring knowledge of their implementation, the classes
send messages via a mediator object.
Memento. The memento pattern is used to capture the
current state of an object and store it in such a manner
that it can be restored at a later time without breaking the
rules of encapsulation.
75
 Cont’d
Observer. The observer pattern is used to allow an
object to publish changes to its state. Other objects
subscribe to be immediately notified of any changes.
State. The state pattern is used to alter the behavior
of an object as its internal state changes. The pattern
allows the class for an object to apparently change at
run-time.
Strategy. The strategy pattern is used to create an
interchangeable family of algorithms from which the
required process is chosen at run-time.

76
 Cont’d
Template Method. The template method pattern is used
to define the basic steps of an algorithm and allow the
implementation of the individual steps to be changed.
Visitor. The visitor pattern is used to separate a relatively
complex set of structured data classes from the
functionality that may be performed upon the data that
they hold.

77
 Thank You !

78