AGILE DEVELOPMENT /

o m
. c
AND UI/UX DESIGN e s s
SUBJECT CODE: 3171610 p r
r d
o
UNIT-2 . w
il t
t e
AGILE DESIGN p a
a j
: / /
p s
t t
h PREPARED BY: AMITKUMAR J PATEL
What Is Agile Design? /
o m
s . c

e s
If agility is about building software in tiny increments,
how can you ever design the software?
p r

r d
How can you take the time to ensure that the software
o
has a good structure that is flexible, maintainable,
. w
it
and reusable?
e l
If you build in tiny increments, aren’t you really setting
t


a
the stage for lots of scrap and rework in the name of
p
refactoring?
a j

/
Aren’t you going to miss the big picture?
The big:/picture evolves along with the software. With each


p s
tittis as good as it can be for the system as it is now.
iteration, the team improves the design of the system so that

h
What Goes Wrong with Software? /
o m
s . c
You start a project with a clear picture
e s of what you
want the system to be.
p r

r
The design of the system is a vital d image in your mind.
Then, something goes wrong. o The software starts to
. w


spreads and grows. li

t
rot like a piece of bad meat. As time goes by, the rot

t e
Ugly festering soresa and boils accumulate in the code,
pand harder to maintain.
making it harder j
a required to make even the simplest
The sheer /

: / becomes so onerous that the developers
effort
s
of changes
andtp
t
front-line managers cry for a redesign.
h redesigns rarely succeed
Such
Symptoms of Poor Design /
o m
s . c
Rigidity: The design is hard to change.s

r e
Fragility: The design is easy to break p
Immobility: The design is hardrd



o to reuse.
Viscosity: It is hard to do.w

l i t the right thing.
 Needless Complexity:
t e Overdesign.

p
Needless Repetition:a Mouse abuse.
j



/a
Opacity: Disorganized expression.
s :/
t tp
h
Design Smells -The Odors of Rotting Software /
o m
s . c


e
Rigidity: The system is hard to change because every s change forces
many other changes to other parts of the system.
p r

d changed.
Fragility: Changes cause the system to break
conceptual relationship to the part thatrwas
in places that have no

o

. w
Immobility: It is hard to disentangle the system into components that
can be reused in other systems.t
l i
t
Viscosity: Doing things righte is harder than doing things wrong.
Needless Complexity:aThe design contains infrastructure that adds


no direct benefit. jp


/ a

: / under a single abstraction.
Needless Repetition: The design contains repeating structures that
s
could be unified
p

t t
Opacity: It is hard to read and understand. It does not express its
h
intent well
Principles /
o m
s . c
Object-oriented design that help developers
e s
r


p
eliminate design smells and build the best designs
d
for the current set of features.
o r
 The principles are as follows:
. w
il t Principle
1. SRP: The Single Responsibility
2. OCP: The Open-Closed t e Principle.
p a
a j
3. LSP: The Liskov Substitution Principle.

/
4. DIP: The Dependency Inversion Principle.
5. ISP: The:/Interface Segregation Principle.
p s
t t
h
SRP: The Single Responsibility Principle /
o m
s . c
Each class should only be responsible for s
e is an axis of
a single

p r
cohesive responsibility. Each responsibility
change. When the demand changes,
be reflected as the change in o r d the change will
the responsibility of the
class. A class should have.w
change. If a class liassumest only one reason for its

e will be multiple reasons for its

more than one
t
change, which pisa equivalent to coupling these
responsibility, then there

a j
/
responsibilities together. Designs that violate SRP can
usually be/reconstructed
: using facade mode or agent
mode tosseparate business responsibilities.
t t p
h
 SRP: The Single Responsibility Principle /
o m
s . c
e s
p r
r d
o
. w
il t
More than one responsibility

t euse the Rectangle class.

One application doesacomputational geometry. It uses Rectangle to
Two different applications

j p
ascreen.
help it with the mathematics of geometric shapes. It never draws the
rectangle on/
/
The other: application is graphical in nature. It may also do some
the


p s
t t
computational geometry, but it definitely draws the rectangle on the

hscreen
SRP: The Single Responsibility Principle /
o m
s . c
e s
p r
r d
o
. w
il t
t e

a
A better design is to separate the two responsibilities into two
p classes as shown above.
j
completely different
a


: / /
This design moves the computational portions of Rectangle into

Now p
s
the GeometricRectangle class.

t t changes made to the way rectangles are rendered
h
cannot affect the ComputationalGeometryApplication.
 SRP: The Single Responsibility Principle /
o m
s . c
Responsibility:
e s
r


p
 We define a responsibility to be “a reason for change.”
d
If you can think of more than one
r motive for changing a
class, then that class has moreothan one responsibility.
t . w
l i
interface Modem {
t e
public void dial(Stringapno);
j
public void hangup(); p
/ a
public void send(char c);
/
public char:recv();
p s
}
t t
h
OCP: The Open–Closed Principle m /
o c
s .

e s
Software entities (classes, packages, modules, etc.)

p r
should be extensible, but unmodifiable, that is, they are

r d
open for expansion and closed for modification. When
o
expanding the behavior of an entity, there is no need
. w
it
to change the source code or binary code, that is The

e l
Open-Closed Principle. The key to the principle of

a t
opening and closing is abstract design. It is impossible
j p
for complete OCP. The most likely and most frequent

/ a
changes should be abstracted. Following the principle
:/
of opening and closing, rejecting immature abstraction
s
t tp
is as important as abstraction itself.

h
OCP: The Open–Closed Principle m /
o c
s .
A module will be said to be opens if it is still

r e it should be
available for extension. For example,
d p
possible to add fields to the r data structures it
o the set of functions it
contains, or new elements to
. w
performs. il t
A module will be said t e to be closed if it is available
a


for use by other

j p modules. This assumes that the
module hasa been given a well-defined, stable
: /
/ (the interface in the sense of information
s
description
p
t
hiding)
t
h
OCP: The Open–Closed Principle m /
o c
s .
public class Circle { }

e s
public class Square { }
p r
public static class Drawer {
r d
o
public static void DrawShapes(IEnumerable<object> shapes) {

. w
foreach (object shape in shapes) {

it
if (shape is Circle) {

l
DrawCircle(shape as Circle);

e
t
} else if (shape is Square) {

a
DrawSquare(shape as Square);

p
}
}

a j
/
}

:/
private static void DrawCircle(Circle circle) { /*Draw

s
circle*/ }

tp
private static void DrawSquare(Square square) { /*Draw

t
Square*/ }
}
h
OCP: The Open–Closed Principle m /
o c
s .
public interface IShape { void Draw(); }

e s
p r
public class Circle : IShape { public void Draw() { /*Draw

d
circle*/ }}

o r
public class Square : IShape { public void Draw() { /*Draw

. w
Square*/ } }

public static class Drawer {

lit
t e
public static void DrawShapes(IEnumerable<IShape> shapes) {

a
foreach (IShape shape in shapes) {

p
shape.Draw();
}

a j
/
}

:/
}

p s
t t
h
OCP: The Open–Closed Principle m /
o c
s .
e s
But the real challenge is anticipation, anticipating is
r


p
hard In real world, when you anticipate the risk is
d
high that:
r
We do anticipate variationso that won’t vary.: Always
implement things when you.w


t
you just foresee that liyou need them. Developing and
actually need them, never when

t e
a
maintaining an abstraction has a cost and if we won’t need
p
j
it this cost is negative.
a

/ be needed. But once the need for variation
The risk is also
that will:/really
high that we don’t anticipate the variation

p
becomess real this is your developer responsibility to refactor
t
t create the right abstractions and the right stable code
and
h that will act upon these abstractions
LSP: The Liskov Substitution Principlem /
c o
s .
Subtypes must be able to completely replace s
e principle
their
base types. The types satisfying the rLiskov
satisfy the following properties: ifdp
r of type S, so that in
there is an object
O2 of type T for every object o O1
. w
il tthe program Change, then S
all programs written for T, after replacing O2 with O1,

eIS-A relationship in OOD is in

the behavioral function of
is a subtype of T. The
a t
j
terms of the behaviorp mode. The behavior mode can
be reasonably
/ a assumed and is dependent on the client
program. /The
s : effectiveness of the model can only be

t t
designs
p
reflected through its client program. Some inheritance
that violate the LSP can use the method of
h
extracting common parts instead of inheritance.
LSP: The Liskov Substitution Principlem /
c o
s .
There are other, far more subtle, wayssof violating

r e uses the
the LSP. Consider an application which
d p
Rectangle class
o r
class Rectangle
t . w
{
l i
t e h) {itsHeight=w;}
public: void SetWidth(double w) {itsWidth=w;}

a
void SetHeight(double

j
double GetHeight()
p const {return itsWidth;}
const {return itsHeight;}

a
double GetWidth()
private:
: / /
s
Point itsTopLeft;

p
double itsWidth;

}; t
t
double itsHeight;

h
LSP: The Liskov Substitution Principlem /
c o
s .
Imagine that this application workss well and is

r e case with all
installed in many sites. As is the
d p
r
successful software, its users demand changes
o demand the ability
from

. w
time to time. One day, the users
to manipulate squares iint addition to rectangles.
l
It is often said tethat inheritance is the IS-A
a words, if a new kind of object


relationship. In p
j other
can be saidato fulfill the IS-A relationship with an
/
old kind:/of object, then the class of the new object
p s
t t
should be derived from the class of the old object.
h
LSP: The Liskov Substitution Principlem /
c o
s .
For all normal intents and purposes, sa square is a


rectangle. Thus, it is logical to viewrthee Square class

d p
as being derived from the Rectangle
o r class.

t . w
This use of the IS-A relationship
i


is sometimes thought lto be one

t e
a
of the fundamental techniques
p analysis: A
j
of object-oriented
square is /aarectangle, and so
: / class should be
s
the Square
p
t t
derived from the Rectangle Square inherits from Rectangle

h
class.
ISP: Interface Segregation Principlem /
c o
s .
Customers should not be forced to srely on the

r e
methods they do not use.
p
d and harmful
 Fat interfaces can cause abnormal r
o programs. When a
coupling between their client
. w
client program requires il t a change to the fat
e other client programs.
interface, it will taffect
p a
Therefore, client
a j programs should only depend on
/
what they actually call The method can achieve this
goal by:/separating the fat interface into multiple
p s
t t
specific client program interfaces.
h
ISP: Interface Segregation Principlem /
c o
s .
Each client-specific interface only sdeclares the

r e to call, and
methods that its client program needs
d p
the implementation class implements
o r all client-
specific interfaces, releasing
relationships so that ithe t . w these coupling

e l client programs do not

depend on each other.
a t
 Common methods
j p of separating interfaces include
the use of adelegate separation and the use of
/
multiple :/ inheritance separation. The key to
p s
t t
separating interfaces is to group the customers of
h interface.
the
ISP: Interface Segregation Principlem /
c o
s .
Consider a security system. In this system, s
e unlocked, and
there are
r


Door objects that can be locked and

which know whether they are ropen
p
d or closed
o
Security Door class Door
t . w
{
i
public: virtual lvoid Lock() = 0;
t e
a
virtual void Unlock() = 0;

j
virtual bool
p IsDoorOpen() = 0;

a
};

:
This class /
/ abstract so that clients can use objects
is
s to the Door interface, without having to


that p
conform
t t on particular implementations of Door.
h
depend
ISP: Interface Segregation Principlem /
c o
s .
Let’s consider TimedDoor, needs to sound s
e too long. In
an alarm
r


when the door has been left open for

d p
order to do this, the TimedDoor
with another object called aoTimer.
r object communicates

t . w
class Timer {
l i
public:
t e timeout, TimerClient* client);
a
void Register(int
};
j p
/ a
/
class TimerClient {

s :
public:

}; p
virtual void TimeOut() = 0;

t t
h
ISP: Interface Segregation Principlem /
c o
s .
When an object wishes to be informed s
e of the Timer.
about a
r


p
time-out, it calls the Register function
d
The arguments of this function r are the time of
o a TimerClient object
the
time-out, and a pointer to
. w
whose TimeOut function il t will be called when the
time-out expires. te
We force Door,panda therefore TimedDoor, to inherit


a j
/
from TimerClient. This ensures that TimerClient can
register :/itself with the Timer and receive the
p s
t t
TimeOut message.
h
ISP: Interface Segregation Principlem /
c o
s .
Chief among these is e s
r


that the Door class

d p
now depends on r
o of Door
TimerClient. Not all varieties
need timing. Indeed, ithe t . w
l original Door
e whatever to do
t
abstraction had nothing
a
with timing. If p
a j timing-free derivatives of

have :/to /
Door are created, those derivatives will
provide degenerate
p s
t t
implementations for the TimeOut
h
method-a potential violation of the LSP.
ISP: Interface Segregation Principlem /
c o
s .
Moreover, the applications thats use those


derivatives will have to import therdefinition e

d p of the
TimerClient class, even though
o r it is not used. That
smells of Needless Complexity
. w and Needless
Redundancy il t
t e
p a
a j
: / /
p s
t t
h
DIP: The Dependency Inversion Principlem /
c o
s .
High-level modules should not depend
e s on low-
r


p
level modules, both should rely on abstraction;
Each higher level declares anrdabstract interface
o the lower level


for the services it needs,

. w
il t interfaces, and each
implements these abstract
high-level class usest e the next layer through this
p a
depend on a
j
abstract interface, so that the high level does not

/ / the lower level, but the lower level

instead :Depends
s on the abstract service interface
p by high-level.
t
declared
t
h
DIP: The Dependency Inversion Principlem /
c o
s .
Example:
e s
r


 The high-level Policy layer uses

d p
a lower-level Mechanism layer,
which in turn uses a detailed- o r
. w
it
level Utility layer. While this

e l
may look appropriate, it has

a t
the insidious characteristic that the Policy layer is sensitive to

j p
changes all the way down in the Utility layer.

/ a
 Dependency is transitive.

:/
 The Policy layer depends on something that depends on the
s
t tp
Utility layer; thus, the Policy layer transitively depends on the
Utility layer. This is very unfortunate.
h
DIP: The Dependency Inversion Principlem /
c o
s .
 Each of the upper-level
e s
layers declares an abstract
interface for the services that
p r
it needs.
r d
The lower-level layers are o
w

then realized from these
it .
abstract interfaces
This is sometimes known ase
l


a t
p
the Hollywood principle:
j
“Don’t call us, we’ll call
The lower-levela modules
you.”

: /
/ that are
provide the implementation
s
for interfaces
p
t upper-level modules.
declared
by,tthe
within, and called

h
DIP: The Dependency Inversion Principlem /
c o
s .

e s
Abstraction should not depend on details, details should
depend on abstractions;
p r

r d
All the dependencies in the program should end in an
o
abstract class or interface, that is:
. w
it
 No variable should hold a pointer or reference to a specific
class;
e l


a t
No class should be derived from a concrete class;

j p
No method should override the methods already implemented in

a
any of its base classes;
/
:/
 If a concrete class is unlikely to change, and other similar
s
derived classes will not be created, then relying on it will
p
t t
not cause damage. For example: java.lang.String.
h
DIP: The Dependency Inversion Principlem /
c o
s .
 Consider the case of the Buttonre
s
object and the
Lamp object
d p
Figure shows a naive design. r
o The Button object
w


i .
receives Poll messages, tdetermines if the button has
been pressed, and e l
then simply sends the TurnOn or
t
TurnOff messageato the Lamp.
j p
/ a
: /
p s
t t
h
 /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h
 /
o m
s . c
e s
p r
r d
o
. w
lit
te
pa
a j
:/ /
p s
t t
h