F10-1: ADM, Architectural Patterns, Design Patterns and ... · F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 ... Tibco Desktop as a Service

19.04.2010

1

ICT

INF5120 – Modellbasert

Systemutvikling

F10-1: ADM, Architectural Patterns, Design

Patterns and Refactoring

Forelesning 12.04.2010

Arne-Jørgen Berre

ICT 2

INF5120 - Lecture plan - 2010 1: 25/1: Introduction to MBSU, MDA, OO and Service/SOA modeling, Overall EA, 4 parts: MDE/SSS/MS/MDI

(AJB)

Part I: MDE – Model Driven Engineering

2: 1/2: MDE I: Metamodeling. DSL and UML profiles, MDA technologies (XMI, Eclipse, EMF/GMF) (AJB/BRE)

Part II: SSS – Service Science and Service/SOA technologies

3: 8/2: SSS I: Service science (top down) - Service and SOA Technologies (bottom up) (AJB)

Part I continued: MDE – Model Driven Engineering

4: 15/2: MDE II: Model transformations with MOFScript, ATL and other technologies (GO/JO)

5 :22/2: MDE III: Code generation with MOFScript, ATL and other technologies (GO/JO)

Part III: MOS – Modeling of Services - with SoaML

6: 1/3: MOS I: Business Process Modeling (CIM) - with BPMN 2.0, and BMM, EA with UPDM (AJB)

7: 8/3: MOS II: Soaml, UML2 and SysML, Modelio SOA and Scope, –Collaboration and Component models (AJB)

8: 15/3: MOS III: SoaML (PIM) and Requirements modeling , CIM->PIM and SoaML (AJB)

9: 22/3: MOS IV: Method Engineering and SPEM / EPF - for Service systems (BRE)

EASTER

Part IV – Model Driven Interoperability

10: 12/4: MS V: SOA and Service Design, MDA and ADM - Intro to MDI (AJB )

11: 19/4: MDI I: Semantic Web with Ontologies and Model Driven Interoperability (TIR)

12: 26/4: MDI II: Semantic Services and Model Driven Interoperability (TIR)

13: 3/5: MDE IV: Evolution and industrial practice of modelbased technologies (AJB++)

14: 10/5: Course summary and preparation for Exam 31/5 (AJB)

Exam: May 31st, 2010 (Monday), 0900-1200 (3 hours)

19.04.2010

2

ICT

Agenda

ADM

Architecture Driven Modernisation

Patterns

GRASP patterns

Design principles

Design Patterns

Refactoring

ICT

ADM – Architecture-Driven

Modernization (Reverse MDA)

19.04.2010

3

ICT

IT Architecture

ICT

Business Architecture

19.04.2010

4

ICT

Data

(What)

Function

(How)

Network

(Where)

People

(Who)

Time

(When)

Motivation

(Why)

Scope

(Contexts)

Business

(Concepts)

System

(Logic)

Technology

(Physics)

Component

(Assemblies)

List of things

important

to business

List of processes

that the business

performs

List of locations

which the business

operates

List of organizations

important to the

business

List of events/cycles

important to the

business

List of business

goals/strategies

Semantic Model

Business

Process

Model

Business

Logistics

System

Workflow

Model

Master

Schedule

Business

Plan

Logical Data ModelApplication

Architecture

Distributed

System

Architecture

Human

Interface

Architecture

Process

Structure

Business Rule

Model

Physical Data Model System DesignTechnology

Architecture

Presentation

Architecture

Control

Structure

Rule

Design

Data Definition ProgramNetwork

Architecture

Security

Architecture

Timing

Definition

Rule

Definition

Operation

(Instances)Data Function Network Organization Schedule Strategy

BMM

SBVR

VDM OSMSBVR

DTFV

BPMN

UMLIMM

(CWM)

CMPM

SoaML

ODM

Business architecture models in OMG

in the Zachman framework

ICT

IT Architecture Ecosystem

19.04.2010

5

ICT

IT/Business architecture transformation

ICT

Modernization horse shoe model

19.04.2010

6

ICT

Modernization scenarios

ICT

ADM Framework

19.04.2010

7

ICT

ADM Standards in OMG

ICT

KDM & ASTM

19.04.2010

8

ICT

Pattern Recognition and SMM

ICT

Visualisation, Refactoring and

Transformation

19.04.2010

9

ICT

Convergence to Cloud Computing

Adaptive Data

CentersIBM, HP, Sun

Infrastructure

as a ServiceAmazon.com

Cloud

Computing

VirtualizationVMware, Citrix

Software

as a ServiceSaleforce.com

Platform

as a ServiceGoogle, Microsoft

Utility

ComputingRackspace,

Terremark,

Savvis, IBM

GridsUniva Ud,

Gigaspaces,

IBM

Enterprise AppsMicrosoft, IBM, Oracle,

Tibco

Desktop as a

ServiceSimtone, Desktone

Desktop

AppsGoogle, Zoho

ICT

Cloud Computing Definition

“Cloud computing is a model for enabling convenient, on-demand

network access to a shared pool of configurable computing

resources (e.g., networks, servers, storage, applications, and

services) that can be rapidly provisioned and released with

minimal management effort or service provider interaction. This

cloud model promotes availability and is composed of five essential

characteristics, three service models, and four deployment models”.

5: On-demand self-service, Broad network access, Resource

pooling, Rapid elasticity, Measured Service

3: IaaS, PaaS, SaaS

4: Private, Community, Public, Hybrid

NIST

Definition of Cloud Computing, Draft version 15, Oct 7, 2009

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

19.04.2010

10

ICT

Government Cloud Framework

ICT

Service Model Overview

SaaS

To use the provider’s applications running on a cloud

infrastructure and accessible from various client

devices through a thin client interface such as a Web

browser

Citizen Engagement (Wikis,

Blogs, Data.gov)

Government Productivity (Cloud

based tools)

Business Enablement

(Salesforce.com)

Enterprise Applications (Core

Mission & Business Svcs

PaaS

To deploy onto the cloud infrastructure consumer-

created applications using programming languages

and tools supported by the provider (e.g., java,

python, .Net)

Database and Database

Management Systems

Developer / Testing Tools

Virtual Environments

IaaS

To provision processing, storage, networks, and

other fundamental computing resources where the

consumer is able to deploy and run arbitrary

software, which can include operating systems and

applications

• Computing

• Storage

• Application hosting

Model Capability Provided Example Services

19.04.2010

11

ICT

REMICS Overall process

Recover

Legacy

Artifacts

Source

Architecture MigrateTarget

Architecture

for Service

Cloud platform

Forward MDA

through

PIM4Cloud

Service

Cloud

Implementa

tion

Model Driven

Interoperability

Validate,

Control and

Supervise

Knowledge: REMICS KDM

Business Process and Rules

Components: SoaML

Implementation: UML, U2TP

Knowledge Discovery,

Reverse Engineering

Source code, binaries,

documentation, users

knowledge, configuration files,

execution logs and traces.

SOA and Cloud Computing

Patterns applied,

Legacy Components Replacement

and Wrapping,

Design by Service Composition

Service mediation for

adaptation

SoaML with REMICS extensions

for Service Clouds,

Links to Business Models

Model Transformation, Code

Generation, Traceability

RESERVOIR, Joyant, Amazon,

Google, Microsoft

Models@Runtime for application

management,

Model Checking, Model-based

Testing for validation

ICT

REMICS Metamodel extensions

19.04.2010

12

ICT

Analysis(Domain)Patterns

Architecture Patterns (Macro Architecture)

Design Patterns (Micro Architecture)

Domain Framework

(OO) Reusable Components

Analysis Design Implementation

Idioms(Languagedependentpatterns)

Patterns: From Analysis to

Implementation

ICT

Patterns on various design levels

Object level patterns: GRASP

Collaboration level patterns: Design Patterns

Module level patterns: Architecture Patterns

Refa

cto

ring

19.04.2010

13

ICT

General Responsibility Assignment

Software Patterns.

Responsibility assignment.

1. knowing (answering)

2. or, doing

Guidance and evaluation in

mechanistic design.

1. Expert2. Creator3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Don’t Talk to

Strangers

ICT

Patterns – Abstract Factory

19.04.2010

14

ICT

Design patterns

(with UML & Java examples)

Based on: Gamma/Helm/Johnson/Vlissides (GoF): Design Patterns, 1995

R. Ryan:, D. Rosenstrauch:Design Patterns in Java, 1997

ICT 28

What are patterns?

"A solution to a problem in a context"?

Insufficient, says the “Gang of Four” (GOF)

What’s missing? 3 things:

Recurrence

Teaching (e.g., implementation consequences, trade-offs, and variations)

A name

GOF:

Patterns contain 4 essential elements

pattern name

problem

solution

consequences

Christopher Alexander (as quoted in the GOF book):

"Each pattern describes a problem which occurs over and over again ... and then

describes the core of [a] 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."

19.04.2010

15

ICT

Design Pattern

A design pattern describes a basic scheme for structuringsubsystems and components of a software architecture aswell as their relationships. It identifies, names, and abstractsa common structural or functional principle by describingits different parts, their collaboration and responsibilities.

ICT

GOF (Gang of Four) 23

Patterns

Creational Patterns (5)

Abstract Factory, Builder, Factory Method, Prototype,

Singleton

Structural Patterns (7)

Adapter, Bridge, Composite, Decorator, Façade,

Flyweight, Proxy

Behavioural Patterns (11)

Chain of responsibility, Command, Interpreter,

Iterator, Mediator, Memento, Observer, State,

Strategy, Template method, Visitor

19.04.2010

16

ICT 31

Skylight Spelunker

“Skylight Spelunker” is a Java framework for a file browser

similar in appearance to the “Windows Explorer” included

with Windows 98.

Spelunker has two views:

Disks and folders in tree structure (FolderView - Left pane)

All contents of selected folder (ContentsView - Right pane)

Spelunker provides support for :

Multiple ways of arranging ContentsView icons

Accessing network drives as well as local

Deleting, renaming and viewing disk contents

ICT 32

Windows Explorer Screen Shot

FolderView ContentsView

19.04.2010

17

ICT 33

Patterns in Spelunker example

Composite

used to model the file tree data structure

Strategy

used to layout the file and folder icons in ContentsView

Observer

used to re-display FolderViews and ContentsViews after user

requests

Proxy and State

used to model password-protected network disk drives

Command

used to carry out user requests

ICT 34

The “Composite” pattern

Problem

What is the best way to model the Spelunker file tree?

The Spelunker file tree is a classic tree structure.

Thus we need a leaf class (File) and a tree class (Folder)

which contains pointers to the Files and Folders in it.

However, there are many operations that are relevant

to both a File and a Folder (e.g., getSize()).

The user doesn’t treat Files and Folders differently,

so why should calling modules have to?

The design would be less complex and more flexible

if the calling module could initiate operations on a target object,

without knowing whether the target was a File or a Folder.

File and Folder should share a common interface.

19.04.2010

18

ICT 35


How the pattern solves the problem

Intent

“Compose objects into tree structures to represent part-whole

hierarchies. Composite lets clients treat individual objects and

compositions of objects uniformly.” [GHJV94]

Explanation

The Composite pattern works by having leaf and tree objects share a

common interface.

Create an abstract base class (or interface) that represents both File

and Folder.

Files and Folders need to provide implementations for the same

operations, but they can implement them differently.

E.g., leaves usually handle an operation directly, while trees usually

forward the operation to its children (and/or perform additional work

before or after forwarding)

ICT 36


How the pattern solves the problem, cont.

Gang of Four UML [GHJV94]

children

Leaf

Operation( )

Client

Composite

Operation( )

Add(Component)

Remove(Component)

GetChild(int)

Component

Operation( )

Add(Component)

Remove(Component)

GetChild(int)

for all g in children

g.Operation();

19.04.2010

19

ICT 37


Use of the pattern in Spelunker

Both File and Folder share a common interface: Node.

Spelunker UML

children

File

getSize( )

Resource Tree

Folder

getSize()

getContents()

Node

getSize( )

size =

total of size

of each child

ICT 38


Use of the pattern in Spelunker, cont.

Code examplespublic class File extends Node{

private long size = 0;

public long getSize(){

return size;}

}

public class Folder extends Node{

private Vector contents;

public long getSize(){

long size = 0;

if (contents != null) {Enumeration e = contents.elements();while (e.hasMoreElements()) {

size += ((Node)e.nextElement()).getSize();}

}return size;

}}

19.04.2010

20

ICT 39

The “Strategy” pattern

Problem

The way in which the icons are arranged varies according to user

preference - the user may choose an iconic view only, or a

short/long detail view.

Including the algorithms to arrange the icons as methods in

ContentsView would make it cumbersome to add new icon

arrangement algorithms to ContentsView; ContentsView would

have to be subclassed and some implementation details might

have to be unnecessarily exposed.

A switch statement would most likely be used to choose the

correct arrangement algorithm.

ICT 40



Intent

“Define a family of algorithms, encapsulate each one, and make them

interchangeable. Strategy lets the algorithm vary independently from

clients that use it.” [GHJV94]

Explanation

The algorithms for arranging the icons are encapsulated into a

separate interface.

The correct arrangement algorithm is chosen polymorphically.

ContentsView neither knows nor cares which arrangement is

presently in use.

19.04.2010

21

ICT 41




Strategy

AlgorithmInterface()

ConcreteStrategyC


ConcreteStrategyB


Context

ContextInterface()

strategy

ConcreteStrategyA


ICT 42


Use of the pattern in Spelunker ContentsView delegates the task of arranging the icons to ViewManager.

Spelunker UML

ViewManager

updateVisibleNodes()

ListViewManager


IconViewManager


ContentsView


strategy

19.04.2010

22

ICT 43



Code examples

public class ContentsView extends ResourceTreeView

{

private ViewManager viewManager;

public void showIconView()

{

viewManager = new IconViewManager(this);

}

public void showListView(boolean showDetail)

{

viewManager = new ListViewManager(this, showDetail);

}

public void updateVisibleNodes(Folder activeFolder)

{

viewManager.updateVisibleNodes(activeFolder);

}

}

public interface ViewManager

{

public void updateVisibleNodes(Folder activeFolder);

}

ICT 44

The “Observer” pattern

Problem

What is the best way to keep all views of the file tree in sync?

We need to be able to re-draw the display window after the user

modifies a file/folder (e.g., when user clicks on a folder to select it)

However, there may be several windows and panes that display the

same file/folder. We need to re-draw all of them.

To do this, the tree needs to keep a list of all of its views, and notify

each one after a modification is done.

However, the tree and view objects might:

have little other relationship besides this notification

need to have their code modified independently

need to be reused separately

So it would be preferable not to make them too tightly coupled to each

other.

19.04.2010

23

ICT 45



Intent

“Define a one-to-many dependency between objects so that when one

object changes state, all its dependents are notified and updated

automatically.” [GHJV94]

Explanation

The Observer pattern works by defining an abstract class (or

interface) with a single method signature. The method will be used as

a mechanism for “observer” objects to be notified of changes in their

“subject”.

Concrete observer sub-classes will each provide their own

implementation of what to do when the notification occurs.

The subject can notify each observer the same way, without caring

which specific sub-class of observer the object actually is.

ICT 46




subject

observers

Observer

Update( )

Subject

Attach(Observer)

Detach(Observer)

Notify( )

ConcreteSubject

SubjectState

GetState( )

ConcreteObserver

ObserverState

Update( )

return SubjectStateObserverState = subject.GetState()

for all o in observers

o.update();

19.04.2010

24

ICT 47



ResourceTree notifies all ResourceTreeViews whenever its

state is modified.

Spelunker UMLResourceTreeObserver

subject

observers

resourceTreeChanged(Folder)

ResourceTree

activeFolder

AttachObserver(ResourceTreeObserver)

DetachObserver(ResourceTreeObserver)

NotifyObservers( )

ResourceTreeView

updateVisibleNodes(activeFolder);

repaint();Enumeration e = observers.elements();

while (e.hasMoreElements()) {

ResourceTreeObserver o = (ResourceTreeObserver)e.nextElement();

o.resourceTreeChanged(activeFolder);

}

resourceTreeChanged(

Folder activeFolder)

ICT 48


Use of the pattern in Spelunker, cont. Code examples

public class ResourceTree {private Vector observers;

public void setActiveFolder(Folder folder){

if (activeFolder != folder) {activeFolder = folder;notifyObservers();

}}

public void notifyObservers(){

Enumeration e = observers.elements();while (e.hasMoreElements()) {

((ResourceTreeObserver)e.nextElement()).resourceTreeChanged(activeFolder);}

}}

public abstract class ResourceTreeView extends Panel implements ResourceTreeObserver {

public void resourceTreeChanged(Folder activeFolder){

updateVisibleNodes(activeFolder);repaint();

}}

19.04.2010

25

ICT 49

The “Proxy” pattern

Problem

Network drives might require the user to login before the drive can

be accessed - however, the protocol for accessing a network drive

when logged in might not differ from accessing a local drive.

LocalDrive should not contain network code - this code should be

moved to a separate class, i.e. NetworkDrive.

Creating NetworkDrive as a subclass of LocalDrive would be

complicated and unwieldy - we would have to check access

everytime a drive operation was requested.

Creating NetworkDrive as a subclass of Folder would force us to

duplicate all drive access operations already in LocalDrive.

ICT 50



Intent

“Provide a surrogate or placeholder for another object to control

access to it.” [GHJV94]

“A Protection Proxy controls access to the original object.

Protection Proxies are useful when objects should have different

access rights.” [GHJV94]

Explanation

The network protocols necessary for logging in and out are

moved into a subclass of Folder called NetworkDrive.

NetworkDrive contains the code necessary for logging in and

out of a network drive.

After logging in, NetworkDrive delegates drive access requests

to LocalDrive (indirectly through ConnectionState).

19.04.2010

26

ICT 51




Subject

Request()

Proxy

Request()

RealSubject

Request()

realSubject

...

RealSubject->Request();

...

ICT 52



NetworkDrive acts as a Proxy for a remote LocalDrive.

Spelunker UML

Note:

NetworkDrive delegates to

LocalDrive indirectly through

ConnectionOpenedState.

Folder

getContents()

NetworkDrive

getContents()

LocalDrive

getContents()

realSubject

...

localDrive.getContents();

...

19.04.2010

27

ICT 53



Code examples

public class NetworkDrive extends Folder{

private ConnectionState connectionState;

public Vector getContents(Folder folder){

return connectionState.getContents(folder);}

}

public class ConnectionOpenedState extends Object implements ConnectionState{

private LocalDrive localDrive;

public Vector getContents(Folder folder){

return localDrive.getContents(folder);}

}

ICT 54

The “State” pattern

Problem

What is the best way to perform password-protection processing

on network drives?

Network drives need to act differently depending on whether the user

has logged in or not; e.g., the user cannot examine or modify a

network drive until they log in.

This can be accomplished by checking a condition before executing

each operation; e.g., “if (loggedIn())”. But this is ugly code, as well as

being inefficient and repetitive.

This is also difficult to extend: what if we need to implement another

set of checks for another condition; e.g., “if (!disconnected())”?

The design would be less complex and more flexible if we could

isolate in one location all behavior related to a particular state of the

object.

19.04.2010

28

ICT 55



Intent

“Allow an object to alter its behavior when its internal state changes.

The object will appear to change its class.” [GHJV94]

Explanation

The State pattern works by creating an abstract class (or interface) with

method signatures for every state-dependent operation in the main object, and

concrete sub-classes that provide implementations for these methods. The

main object then delegates each of these operations to the state object it is

currently using.

Each state class can implement each operation in its own way (e.g., perform

unique processing, disallow the operation, throw an exception, etc.).

The main object can change its behavior by changing the state object it is

using.

This is a very clean design - and also extendible: we can simply add new state

classes to add additional behavior, without modifying the original object.

ICT 56




state

Context

Request( )

ConcreteStateB

HandleRequest( )

State

HandleRequest( )

ConcreteStateA

HandleRequest( )

state.HandleRequest()

19.04.2010

29

ICT 57



The NetworkDrive delegates operations to its

ConnectionState.

Spelunker UML

state

NetworkDrive

getContents()

ConnectionClosedState

getContents( )

ConnectionState

getContents( )

ConnectionOpenedState

getContents( )

return

connectionState.getContents()

changeState(ConnectionState)

ICT 58



Code examplespublic class ConnectionClosedState implements ConnectionState {

public void login() {LocalDrive localDrive = null;

// login and initiate localDrive

networkDrive.changeState(new ConnectionOpenedState(networkDrive, localDrive));}

public Vector getContents(Folder folder) {login();return networkDrive.getContents(folder);

}}

public class ConnectionOpenedState implements ConnectionState {public void login() {

// display error}

public Vector getContents(Folder folder) {return localDrive.getContents(folder);

}}

19.04.2010

30

ICT 59

The “Command” pattern

Problem

A request might need access to any number of classes.

The initiator of the request should not be tightly coupled to

these classes.

Requests should be storable to support undoable

operations; therefore, requests must be accessible through

some common interface.

How do we implement requests without coupling them to the

initiator or target, or requiring the initiator to know the

implementation details of the request ?

Implementing the code for all requests in one class would

centralize the application and make it difficult to create new

requests.

ICT 60



Intent

“Encapsulate a request as an object, thereby letting you parameterize

clients with different requests, queue or log requests, and support

undoable operations.” [GHJV94]

Explanation

Places the implementation of a request into a separate class.

Initiators of the request do not know any implementation details of the

request - they simply fire it off by calling the execute() method.

The targets of the request do not need to know anything about the

request.

All requests are accessible through a common interface.

The correct implementation is chosen polymorphically.

19.04.2010

31

ICT 61




Command

Execute()

ConcreteCommand

Execute()

Receiver

Action()receiver

Client Invoker

receiver->Action();

state

ICT 62



Used to implement user operations on files and folders.

Spelunker UML

Command

execute()

DeleteCommand

execute()

ContentsView

getSelectedNodes()receiver

Skylight

Spelunker

CommandButton

...

Vector selectedNodes = contentsView.getSelectedNodes();

...

if (!node.deleteNode(node)) {

...

19.04.2010

32

ICT 63


Use of the pattern in Spelunker, cont. Code examples

public class CommandButton extends Button {private Command command;

public CommandButton(String label, Command command) {super(label);this.command = command;

}

public boolean action(Event e,Object what) {

command.execute();return super.action(e, what);

}}

public class DeleteCommand extends Command {private ContentsView contentsView;private ResourceTree resourceTree;

public void execute() {(code for retrieving all selected Nodes

from ContentsView and deleting them)}

}

public abstract class Command extends Object {public abstract void execute();

}

ICT

Basis Litteratur (Pattern kataloger)

Design Patterns, Elements of Reusable Object-Oriented SoftwareGamma et. al. Addison-Wesley, ISBN 0-201-63361-2

Analysis Patterns, Reusable Object ModelsMartin Fowler, Addison-Weslwy, ISBN 0-201-89542-0

Pattern-Oriented Software ArchitectureF. Buschmann et. al, J. Wiley, ISBN 0-471-95869-7

http://st-www.cs.uiuc.edu/users/patterns/patterns.html

http://c2.com/ppr/index.html

AntiPatterns - Refactoring Software, Architectures, and Projects in CrisisW. Brown et. al, J. Wiley, ISBN 0-471-19713-0

19.04.2010

33

ICT

Tilleggs litteratur

Design Patterns for Object-Oriented Software Development,Pree, Addison-Wesley, ISBN 0-201-42294-8, 1995

CORBA Design Patterns, T. Mowbray, R. Malveau, j. Wiley, 1997, ISBN 0-471-15882-8

Communications of ACM, “Software Patterns” - special issueOctober 1996, Vol. 39, Number 10

Pattern Languages of Program Design 1J. Coplien, Douglas SchmidtAddison-Wesley, ISBN 0-201-60734-4, 1995

Pattern Languages of Program Design 2J. Vlissides, J. Coplien, N. KerthAddison-Wesley, ISBN 0-201-89527-7, 1996

ICT

Refactoring - Improving the design of

existing code 1. Refactoring - a first example

2. Principles in refactoring

3. Bad Smells in Code

4. Building Tests

5. Toward a catolog of refactorings

6. Composing Methods

7. Moving Features between objects

8. Organizing data

9. Simplifying Conditional Expressions

10. Making Method calls simpler

11. Dealing with Generalization

12. Big Refactorings

13. Refactoring, Reuse and Reality

14. Refactoring tools

M. Fowler, with K. Beck, J. Brant, W. Opdyke, D. Roberts, Addison-Wesley, August 1999

Refactoring: Improving the design of existing code

19.04.2010

34

ICT

Refactoring - What and

Why ?

Refactoring is the process of changing a software

system in such a way that it does not alter the external

behaviour of the code yet improves its internal

structure.

Improving to make it easier to understand and cheaper

to modify

ICT

When should you

refactor

The rule of three - Three strikes and you refactor

Refactor when you add function

Refactor when you need to fix a bug

Refactor as you do a code review

19.04.2010

35

ICT

Why refactoring

works

Programs that are hard to read are hard to modify

Programs that have duplicated logic are hard to modify

Program that require additional behaviour that requries

you to change running code are hard to modify

Programs with complex conditional logic are hard to

modify

We want programs that are easy to read, that have all

logic specified in one and only one place, do not allow

changes to endanger existing behaviour, and allow

conditional logic to be expressed as simply as possible

ICT

Refactoring

strategies

Composing Methods

Moving features between objects

Organizing data

Simplifying conditional expressions

Making method calls simpler

Dealing with generalization

Big refactorings

19.04.2010

36

ICT

Composing

Methods

Extract method

Inline method

Inline temp

Replace temp with query

Introduce explaining variable

Split temporary variable

Remove assignments to parameters

Replace method with method object

Substitute algorithm

ICT

Moving Features between

objects

Move method

Move field

Extract Class

Inline Class

Hide Delegate

Remove middle man

Introduce foreign method

Introduce local extension

19.04.2010

37

ICT

Bad Smells in

Code (1/4)

Duplicated Code (extract method, extract class, pull

up method, form template method)

Long Method (extract method, replace temp with

query, replace method with method object,

decompose conditional)

Large Class (extract class, extract subclass, extract

interface, replace data value with object)

Long ParameterList (replace parameter with method,

introduce parameter object, preserve whole object)

Divergent Change (extract class)

ICT

Bad Smells in

Code (2/4)

Shotgun Surgery (move method, move field, inline class)

Feature Envy (move method, move field, extract field)

Data Clumps (extract class, introduce parameter object,

preserve whole object)

Primitive Obsession (replace data value with object, extract

class, introduce parameter object, replace array with object,

replace type code with class/subclasses, replace type code

with state/strategy)

Switch Statements (replace conditional with polymorphism,

replace type code with subclasses/state/strategy, replace

parameter with explicit methods, introduce null object)

19.04.2010

38

ICT

Bad Smells in

Code (3/4)

Parallell Inheritance Hierarchies (move method,

move field)

Lazy Class (inline class, collapse hierarchy)

Speculative Generality (collapse hierarchy, inline

class, remove parameter, rename method)

Temporary Field (extend class, introduce null

object)

Message Chains (hide delegate)

Middle Man (remove middle man, inline method,

replace delegation with inheritance)

Inappropriate Intimacy (move method, move field,

change bidirection to unidirectional)

ICT

Bad Smells in

Code (4/4)

Alternative classes with different interfaces (rename

method, move method)

Incomplete Library Class (introduce foreign

method, introduce local extension)

Data Class (move method, encapsulate field,

encapsulate collection)

Refused Bequest (replace inheritance with

delegation)

Comments (extract method, introduce assertion)

19.04.2010

39

ICT

Organizing data Self encapsulate field

Replace data value with object

Change value to reference

Change reference to value

Replace array with object

Duplicate observed data

Change unidirectional association to bidirectional

Change bidirectional association to unidirectional

Replace magic number with symbolic constant

Encapsulate field

Encapsulate collection

Replace record with data class

Replace type code with class/sublasses

Replace type code with state/strategy

Replace subclass with fields

ICT

Simplifying Conditional

Expressions

Decompose conditional

Consolidate conditional expression

Consolidate duplicate conditional fragments

Remove control flag

Replace nested conditional with guard clauses

Replace conditional with polymorphism

Introduce null object

Introduce assertion

19.04.2010

40

ICT

Making Method calls simpler

Rename method

Add parameter

Remove parameter

Separate query from modifier

Parameterize method

Replace parameter with explicit methods

Preserve whole object

Replace parameter with method

Introduce parameter object

Remove setting method

Hide method

Replace constructor with factory method

Encapsulate downcast

Replace error code with exception

Replace exception with test

ICT

Dealing with Generalization

Pull up field

Pull up method

Pull up constructor body

Push down method

Push down field

Extract subclass

Extract superclass

Extract interface

Collapse hierarchy

Form template method

Replace inheritance with delegation

Replace delegation with inheritance

19.04.2010

41

ICT

Big refactorings

Tease apart inheritance

Convert procedural design to objects

Separate domain from presentation

Extract hierarchy

ICT

The rhythm of

refactoring ...

test, small change, test, small change, test, ….

… allows refactoring to move quickly and safely

19.04.2010

42

ICT

AntiPatterns

Refactoring Software, Architectures , and Projects in

Crisis: W. Brown, R. Malveau. H. McCormick, T. Mowbray, Wiley, 1998

AntiPattern: A commonly occuring patterns or solution that generates decidely

negative consequences. An AntiPatterns may be a pattern in the wrong context.

When properly documented, an AntiPattern comprises a paired AntiPattern

solution with a refactored solution.

ICT

Software Development

AntiPatterns The Blob (from the film)

Continuous Obsolescence

Lava Flow

Ambiguous Viewpoint

Functional Decomposition

Poltergeists

Boat Anchor

Golden Hammer

Dead End

Spaghetti Code

Input Kludge

Walking through a Minefield

Cut-and-Paste Programming

Mushrooom management

19.04.2010

43

ICT

Software Architecture

AntiPatterns Autogenerated Sovepipe

Stovepipe Enterprise

Jumble

Stovepipe System

Cover your Assets

Vendor Lock-In

Wolf Ticket

Architecture by Implication

Warm bodies

Design by Committee

Swiss Army Knife

Reinvent the Wheel

The Grand Old Duke of York

ICT

Software Project Management

AntiPatterns

Blowhard Jamboree

Analysis Paralysis

Viewgraph Engineering

Death by Planning

Fear of Success

Corncob

Intellectual Violence

Irrational Management

Smoke and Mirrors

Project Mismanagement

Throw it over the wall

Fire Drill

The Feud

E-mail is dangerous

19.04.2010

44

ICT

Practical Refactoring

exercise

ICT

Example:Video rental

Bad smells:

Long Method

Feature Envy

Switch statements

Temporary Fields

Support change ?: Add HTML

statement, change classification of

films

Customer1

+ statement()

Rental1

daysRented : int

0..* 10..* 1

Movie1

priceCode : int

1 0..*1 0..*

19.04.2010

45

ICT

extract from

statement()

public String statement() {

/ ….. Determine amounts for each rentalSwitch (each.getMovie().getPriceCode()) {case Movie.REGULAR thisAmount += 2;

…..

// add frequent renter pointsfrequentRenterPoints ++;

if (each.getMovie().getPriceCode() -----

// show figures for this rental

// add footer lines

}

ICT

Refactorings:Video

rental

Create Tests to check refactoring correctness

Decomposing and redistributing the statement

method (extract method, moving the amount

calculation amountFor() (move the method from

customer to rental), rename variables (I.e each ->

aRental)

similar: extracting frequent renter points, removing

temps (totals) replaceTempWithQuery

totalAmount/freqRentPoint,

19.04.2010

46

ICT

Extracting and Moving

methods

Customer1

+ statement()

Rental1

daysRented : int

getCharge()

getFreqRentPoints()0..* 10..* 1

Movie1

priceCode : int

1 0..*1 0..*

Customer1

+ statement()

+ getTotalCharge()

+ getTotFreqRentPoints()

Rental1

daysRented : int

getCharge()


Movie1

priceCode : int

1 0..*1 0..*

ICT

Move calculation of charge

and points

to the “expert”

Customer1

+ statement()

+ getTotalCharge()


Rental1

daysRented : int

getCharge()


Movie1

priceCode : int

getCharge(days : int)

getFreqRentPoints(days : int)

10..*10..*

19.04.2010

47

ICT

Refactorings:Video

rental

replace conditional logic on price code with

polymorphism, using inheritance - problem: a movie

can change its classification during its lifetime -> use

the state pattern for price code object (or strategy) ->

replace type code with state/strategy, move method

(switch into price class), replace conditional with

polymorphism to eliminate switch

ICT

Customer1

+ statement()

+ getTotalCharge()


+ htmlstatement()

Rental1

daysRented : int

getCharge()


ChildrensPrice


NewReleasePrice



RegularPrice


Movie1

priceCode : int



1

0..*

1

0..*

Price


getFreqRentPoints(days : int)11

F10-1: ADM, Architectural Patterns, Design Patterns and ... · F10-1: ADM, Architectural Patterns, Design Patterns and Refactoring Forelesning 12.04.2010 ... Tibco Desktop as a Service

Documents