INF5120 – Modellbasert
Systemutvikling
 F10-1: ADM, Architectural Patterns, Design
Patterns and Refactoring
Forelesning 12.04.2010
Arne-Jørgen Berre
ICT
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)
ICT
2
Agenda
 ADM
 Architecture Driven Modernisation
 Patterns
 GRASP patterns
 Design principles
 Design Patterns
 Refactoring
ICT
ADM – Architecture-Driven
Modernization (Reverse MDA)
ICT
IT Architecture
ICT
Business Architecture
ICT
Business architecture models in OMG
in the Zachman framework
Data
(What)
Function
(How)
SBVR
Network
(Where)
List of locations
VDMwhich
the business
Scope
(Contexts)
List of things
important
to business
List of processes
that the business
performs
operates
Business
(Concepts)
Semantic Model
Business
Process
Model
Business
Logistics
System
Distributed
System
Architecture
ODM
People
(Who)
Time
(When)
Motivation
(Why)
List of events/cycles
important to the
business
List of business
goals/strategies
Workflow
Model
Master
Schedule
Business
Plan
Human
Interface
Architecture
Process
Structure
Business Rule
Model
OSM
List of organizations
important to the
business
BPMN
BMM
CMPM
System
(Logic)
Logical Data Model
Application
Architecture
Technology
(Physics)
Physical Data Model
IMM
(CWM)
System Design
Technology
Architecture
Presentation
Architecture
Structure
DTFV
Control
Rule
Design
Component
(Assemblies)
Data Definition
Program
Network
Architecture
Security
Architecture
Timing
Definition
Rule
Definition
Operation
(Instances)
Data
Function
Network
Organization
Schedule
Strategy
SoaML
UML
ICT
SBVR
IT Architecture Ecosystem
ICT
IT/Business architecture transformation
ICT
Modernization horse shoe model
ICT
Modernization scenarios
ICT
ADM Framework
ICT
ADM Standards in OMG
ICT
KDM & ASTM
ICT
Pattern Recognition and SMM
ICT
Visualisation, Refactoring and
Transformation
ICT
Convergence to Cloud Computing
Enterprise Apps
Virtualization
Microsoft, IBM, Oracle,
Tibco
VMware, Citrix
Desktop
Apps
Google, Zoho
Utility
Computing
Rackspace,
Terremark,
Savvis, IBM
Desktop as a
Service
Simtone, Desktone
Cloud
Computing
Adaptive Data
Centers
Grids
Univa Ud,
Gigaspaces,
IBM
IBM, HP, Sun
Infrastructure
as a Service
Software
as a Service
Amazon.com
Saleforce.com
Platform
as a Service
Google, Microsoft
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
ICT
Government Cloud Framework
ICT
Service Model Overview
Model
SaaS
Capability Provided
Example Services
 Citizen Engagement (Wikis,
Blogs, Data.gov)
To use the provider’s applications running on a cloud  Government Productivity (Cloud
infrastructure and accessible from various client
based tools)
 Business Enablement
devices through a thin client interface such as a Web
(Salesforce.com)
browser
 Enterprise Applications (Core
Mission & Business Svcs
PaaS
To deploy onto the cloud infrastructure consumercreated applications using programming languages
and tools supported by the provider (e.g., java,
python, .Net)
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
 Database and Database
Management Systems
 Developer / Testing Tools
 Virtual Environments
• Computing
• Storage
• Application hosting
ICT
REMICS Overall process
Service mediation for
adaptation
Model Driven
Interoperability
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.
Source
Architecture
Migrate
Target
Architecture
for Service
Cloud platform
SoaML with REMICS extensions
for Service Clouds,
Links to Business Models
Forward MDA
through
Recover
Validate,
Control and
Supervise
Legacy
Artifacts
SOA and Cloud Computing
Patterns applied,
Legacy Components Replacement
and Wrapping,
Design by Service Composition
Model Transformation, Code
Generation, Traceability
PIM4Cloud
Service
Cloud
Implementa
tion
[email protected] for application
management,
Model Checking, Model-based
Testing for validation
ICT
RESERVOIR, Joyant, Amazon,
Google, Microsoft
REMICS Metamodel extensions
ICT
Patterns: From Analysis to
Implementation
Analysis
Design
Implementation
Architecture Patterns
(Macro Architecture)
Analysis
(Domain)
Patterns
Domain Framework
Idioms
(Language
dependent
patterns)
Design Patterns
(Micro Architecture)
(OO) Reusable
Components
ICT
Patterns on various design levels
Module level patterns: Architecture Patterns
Refactoring
Collaboration level patterns: Design Patterns
Object level patterns: GRASP
ICT
General Responsibility Assignment
Software Patterns.
Responsibility assignment.
1. knowing (answering)
2. or, doing
Guidance and evaluation in
mechanistic design.
1. Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Polymorphism
7. Pure Fabrication
8. Indirection
9. Don’t Talk to
Strangers
ICT
Patterns – Abstract Factory
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
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."
ICT
28
Design Pattern
A design pattern describes a basic scheme for structuring
subsystems and components of a software architecture as
well as their relationships. It identifies, names, and abstracts
a common structural or functional principle by describing
its 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
ICT
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
31
Windows Explorer Screen Shot
FolderView
ContentsView
ICT
32
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
33
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.
ICT
34
The “Composite” pattern
 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
35
The “Composite” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
Component
Client
Operation( )
Add(Component)
Remove(Component)
GetChild(int)
Leaf
Operation( )
children
Composite
Operation( )
Add(Component)
Remove(Component)
GetChild(int)
for all g in children
g.Operation();
ICT
36
The “Composite” pattern
 Use of the pattern in Spelunker
 Both File and Folder share a common interface: Node.
 Spelunker UML
Node
Resource Tree
children
getSize( )
File
getSize( )
Folder
size =
total of size
of each child
getSize()
getContents()
ICT
37
The “Composite” pattern
 Use of the pattern in Spelunker, cont.
 Code examples
public 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;
ICT
38
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
39
The “Strategy” pattern
 How the pattern solves the problem
 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.
ICT
40
The “Strategy” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
strategy
Context
ContextInterface()
ConcreteStrategyA
AlgorithmInterface()
Strategy
AlgorithmInterface()
ConcreteStrategyB
ConcreteStrategyC
AlgorithmInterface()
AlgorithmInterface()
ICT
41
The “Strategy” pattern
 Use of the pattern in Spelunker
 ContentsView delegates the task of arranging the icons to ViewManager.
 Spelunker UML
ContentsView
updateVisibleNodes()
strategy
ViewManager
updateVisibleNodes()
IconViewManager
updateVisibleNodes()
ListViewManager
updateVisibleNodes()
ICT
42
The “Strategy” pattern
 Use of the pattern in Spelunker, cont.
 Code examples
public interface ViewManager
{
public void updateVisibleNodes(Folder activeFolder);
}
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);
}
}
ICT
43
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.
ICT
44
The “Observer” pattern
 How the pattern solves the problem
 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
45
The “Observer” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
Observer
Subject
Attach(Observer)
Detach(Observer)
Notify( )
Update( )
observers
ConcreteSubject
SubjectState
GetState( )
return SubjectState
ConcreteObserver
ObserverState
subject
Update( )
ObserverState = subject.GetState()
for all o in observers
o.update();
ICT
46
The “Observer” pattern
 Use of the pattern in Spelunker
 ResourceTree notifies all ResourceTreeViews whenever its
state is modified.
 Spelunker UML
ResourceTreeObserver
resourceTreeChanged(Folder)
observers
ResourceTree
ResourceTreeView
activeFolder
AttachObserver(ResourceTreeObserver)
DetachObserver(ResourceTreeObserver)
NotifyObservers( )
resourceTreeChanged(
Folder activeFolder)
subject
Enumeration e = observers.elements();
while (e.hasMoreElements()) {
ResourceTreeObserver o = (ResourceTreeObserver)e.nextElement();
o.resourceTreeChanged(activeFolder);
}
updateVisibleNodes(activeFolder);
repaint();
ICT
47
The “Observer” pattern
 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();
}
ICT
48
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
49
The “Proxy” pattern
 How the pattern solves the problem
 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).
ICT
50
The “Proxy” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
Subject
Request()
RealSubject
Request()
realSubject
Proxy
Request()
...
RealSubject->Request();
...
ICT
51
The “Proxy” pattern
 Use of the pattern in Spelunker
 NetworkDrive acts as a Proxy for a remote LocalDrive.
 Spelunker UML
Folder
getContents()
Note:
NetworkDrive delegates to
LocalDrive indirectly through
ConnectionOpenedState.
LocalDrive
getContents()
realSubject
NetworkDrive
getContents()
...
localDrive.getContents();
...
ICT
52
The “Proxy” pattern
 Use of the pattern in Spelunker, cont.
 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
53
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.
ICT
54
The “State” pattern
 How the pattern solves the problem
 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
55
The “State” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
Context
Request( )
state.HandleRequest()
State
state
HandleRequest( )
ConcreteStateA
HandleRequest( )
ConcreteStateB
HandleRequest( )
ICT
56
The “State” pattern
 Use of the pattern in Spelunker
 The NetworkDrive delegates operations to its
ConnectionState.
NetworkDrive
 Spelunker
UML
changeState(ConnectionState)
getContents()
return
connectionState.getContents()
ConnectionState
state
getContents( )
ConnectionOpenedState
getContents( )
ConnectionClosedState
getContents( )
ICT
57
The “State” pattern
 Use of the pattern in Spelunker, cont.
 Code examples
public 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);
}
ICT
58
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
59
The “Command” pattern
 How the pattern solves the problem
 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.
ICT
60
The “Command” pattern
 How the pattern solves the problem, cont.
 Gang of Four UML [GHJV94]
Invoker
Client
Command
Execute()
Receiver
Action()
receiver
ConcreteCommand
Execute()
state
receiver->Action();
ICT
61
The “Command” pattern
 Use of the pattern in Spelunker
 Used to implement user operations on files and folders.
 Spelunker UML
Skylight
Spelunker
CommandButton
Command
execute()
ContentsView
getSelectedNodes()
receiver
DeleteCommand
execute()
...
Vector selectedNodes = contentsView.getSelectedNodes();
...
if (!node.deleteNode(node)) {
...
ICT
62
The “Command” pattern
 Use of the pattern in Spelunker, cont.
 Code examples
public abstract class Command extends Object {
public abstract void execute();
}
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 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);
}
ICT
63
Basis Litteratur (Pattern kataloger)
Design Patterns, Elements of Reusable Object-Oriented Software
Gamma et. al. Addison-Wesley, ISBN 0-201-63361-2
Analysis Patterns, Reusable Object Models
Martin Fowler, Addison-Weslwy, ISBN 0-201-89542-0
Pattern-Oriented Software Architecture
F. Buschmann et. al, J. Wiley, ISBN 0-471-95869-7
AntiPatterns - Refactoring Software, Architectures, and Projects in Crisis
W. Brown et. al, J. Wiley, ISBN 0-471-19713-0
http://st-www.cs.uiuc.edu/users/patterns/patterns.html
http://c2.com/ppr/index.html
ICT
Tilleggs litteratur
Pattern Languages of Program Design 1
J. Coplien, Douglas Schmidt
Addison-Wesley, ISBN 0-201-60734-4, 1995
Pattern Languages of Program Design 2
J. Vlissides, J. Coplien, N. Kerth
Addison-Wesley, ISBN 0-201-89527-7, 1996
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 issue
October 1996, Vol. 39, Number 10
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
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
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
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
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)
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)
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
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
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
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
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
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
Movie1
Rental1
priceCode : int
daysRented : int
1
0..*
Customer1
1 + statement()
0..*
ICT
extract from
statement()
public String statement() {
/ ….. Determine amounts for each rental
Switch (each.getMovie().getPriceCode()) {
case Movie.REGULAR
thisAmount += 2;
…..
// add frequent renter points
frequentRenterPoints ++;
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,
ICT
Extracting and Moving
methods
Rental1
daysRented : int
Movie1
priceCode : int
0..*
1
getCharge()
0..*
getFreqRentPoints()
Rental1
daysRented : int
Movie1
priceCode : int
1
0..*
Customer1
1 + statement()
Customer1
+ statement()
getCharge()
0..* 1 + getTotalCharge()
getFreqRentPoints()
+ getTotFreqRentPoints()
ICT
Move calculation of charge
and points
to the “expert”
Movie1
priceCode : int
Rental1
daysRented : int
Customer1
+ statement()
getCharge(days : int)
10..* getCharge()
0..* 1 + getTotalCharge()
getFreqRentPoints(days : int)
getFreqRentPoints()
+ getTotFreqRentPoints()
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
Movie1
priceCode : int
Price
getCharge(days : int)
getFreqRentPoints(days : int)
1
getCharge(days : int)
getFreqRentPoints(days : int)
1
RegularPrice
ChildrensPrice
getCharge(days : int)
getCharge(days : int)
NewReleasePrice
0..*
getCharge(days : int)
getFreqRentPoints(days : int)
Rental1
daysRented : int
getCharge()
getFreqRentPoints()
Customer1
0..*
+ statement()
1 + getTotalCharge()
+ getTotFreqRentPoints()
+ htmlstatement()
ICT
Descargar

INF5120 – Modellering med objekter