Transcript CM602 Effective Systems Development

CM602: Effective Systems
Development
Lecture 10: Reuse, Design Patterns &
Component-Based Development
1
Outline

In this lecture we will consider




Why re-use is regarded as important
Some of the problems with re-use
Re-use with design patterns
Component-based development
2
Question

Why is reuse regarded as important?
3
What Software Project
Artifacts Can Be Re-used?

OO designers are increasingly looking for opportunities to reuse old
solutions and to make their successful designs available for reuse.







Requirements
Architecture
Code; class libraries; frameworks
Designs; design (and other) patterns
Documentation
Tests
Legacy (heritage) systems.
The higher (more abstract) the level of the re-used artifacts, the
greater the savings.
4
Problems with Reuse




Inappropriate project choice
Planning for reuse too late
Level of coupling between classes
Lack of standards
5
Jacobson’s 6 Levels of Reuse
Adoption
1.
None

2.
Everything developed
from scratch.
Managed Workproduct
Reuse

Informal Code Reuse

3.
4.
Programmers who trust
each other swap code to
save time during
development.
5.

Some pieces of code
engineered for re-use.
Their use is mandated.
Architected Reuse

Black Box Re-use
6.
An organisational structure
is put into place to manage
re-useable code
A common architecture is
used for all development
processes.
Reuse Driven

All software development is
geared for maximum
possible re-use.
Ref: Jacobson et al, 1997
6
Terminology

Design patterns


Frameworks




General solutions that can be applied to specific
problems
Outline systems giving basic functionality
Slot in components for the specifics
E.g. component-based ERP systems
Idioms

Language-specific common techniques and
preferred ways of expression
7
What are Design Patterns?



Design patterns are ready made reusable OO
analysis/design fragments which can support faster
development of more efficient software.
They codify the ways in which expert designers tackle
& solve particular commonly occurring design
problems
Each pattern is a three-part rule which expresses a
relation between a certain context, a problem, and a
solution (ie a ready made pattern)
8
What are Design Patterns?


Documenting patterns is one way that reuse can be
used to share the information that has been learned
about how best to solve a specific design problem. I.e.
in a corporate pattern library
Many hundreds of patterns have been documented so
far.
9
Categories of Patterns

Creational


Structural


about construction of object instances
address issues concerned with the way in which
classes and objects are organised
Behavioural

address the problems that arise when assigning
responsibilities to classes
(Gamma et al., 1995)
10
Patterns - Motivation for Use

Simpler maintenance, less to learn


Standard methods of implementing functionality.
Increase flexibility:

Avoid creating objects directly


Avoiding hard coded operation requests


“Observer”, “Command”
Easier to alter existing classes


“Proxy”
Loose Coupling:


“Command”
Location independence


“Abstract Factory”
“Decorator”, “Adapter”
Ref: Gamma et al (1994).
11
Behavioural Patterns Example:
State





Consider the class Campaign. (Bennett et al, 2005)
It has four states—Commissioned, Active,
Completed and Paid
A Campaign object has different behaviour
depending upon which state it occupies
Operations have case statements giving this
alternative behaviour
The class factored into separate components —
one for each of its states
12
Behavioural Patterns: State
Campaign
CampaignState
currentStateIdentifier
addAdvert( )
addAdvert( )
changeState( )
calcCosts( )
calcCosts( )
Contains the object identifier
of the current state object
Commissioned
Active
Completed
Paid
addAdvert( )
addAdvert( )
addAdvert( )
addAdvert( )
calcCosts( )
calcCosts( )
calcCosts( )
calcCosts( )
State pattern applied to the class Campaign
13
General form of State Pattern
Context
State
operation( )
operation( )
ConcreteStateA
operation( )
ConcreteStateB
operation( )
14
Problems with Patterns



Can limit creativity
Uncontrolled use may lead to over-design
Need culture of reuse
15
Other patterns

Analysis patterns


Interaction patterns


Organisational structure and process, especially for development
processes (Coplien, 1995)
Architectural Patterns (both types!)



E.g. Favourites, Step-by-Step Instructions (van Welie & Traetteberg,
2000)
Organisational patterns


E.g. Party, Organization Hierarchies (Fowler, 1996)
Architectures for various kinds of systems.
http://www.opengroup.org/architecture/togaf8doc/arch/p4/patterns/patterns.htm
Anti-patterns


Common bad solutions
Why they don’t work; what to do instead
16
What is a component?


“A physical, replaceable part of a system that packages
implementation and conforms to and provides the
realisation of a set of interfaces. A component
represents a physical piece of implementation of a
system, including software code (source, binary or
executable) or equivalents such as scripts or command
files” (OMG, 1999)
“A component is an executable unit of code that
provides physical black-box encapsulation of related
services. Its services can only be accessed through a
consistent, published interface that includes an
interaction standard. A component must be capable of
being connected to other components (through a
communications interface) to form a larger group.”
(Allen and Frost, 1998)
17
What is a component? (2)


“A component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. Context dependencies are specified
by stating the required interfaces and the acceptable
execution platform(s). A component is subject to
composition by third parties. For the purposes of
independent deployment, a component needs to be a
binary unit.” (Szyperski, 1998)
“A component is a type, class, or any other
workproduct that has been specifically engineered to be
reusable.” (Jacobson et al., 1997)
18
Granularity of components

Can be

Small-scale, e.g.



Larger business routines, e.g.



Label printing
Meeting scheduling
General purpose modules, e.g.



Common business routines, e.g. date handling
GUI widgets, e.g. VBX
Database connectivity
Web mail
Entire application system/subsystem


Contact management
Financial instruments
19
Sources of components

Built for the purpose
Re-used from previous developments
Bought
Re-engineered from existing software

Repository of available components



20
CBD claims


Delivers usable software more quickly
Reduces risk, raises reliability, because pre-existing
components have already been tested.


Maintainable – individual components can be replaced
or redeveloped without affecting others



Is this all that’s needed for reliability?
E.g. for enhancements, updating, performance tuning.
Flexible – component based software can be
reconfigured to support changing business processes
Reusable software maximises return on investment
21
Activity


You are a developer in an organisation that is
about to begin CBD by ‘harvesting’ some
components from existing systems and using
these and purchased components in future
developments.
What might you be concerned about?
22
CBD Issues



Needs a good architecture
Locating and understanding components
Tool support




Now becoming available
Trust
Dependency management
People issues



Change in work pattern
Not Invented Here
More or less satisfying?
23
Standards & Protocols

Essential to ensure interoperability. E.g.







CORBA
Web services
SOAP
XML
Java, Java Beans, EJB
COM, COM+, DCOM
Etc.
24
Tool support for CBD

Which aspects of CBD?




Developing
Identifying & Managing
Integrating / Assembling
Useful facilities


Repository of components
Catalogue browsing, searching





Perhaps with interface to external sources
Business and design modelling – or interface to CASE tools
Graphical specification of how components are assembled
Configuration management
Build management
25
Approaches to CBD

Revolutionary




Evolutionary


Business wide set of generic components are produced from
scratch.
Architectural approach.
Organisation-wide redevelopment, or component suppliers.
Components are a ‘spin-off’ from development projects, and
can then be reused on others.
Assembly


Systems are developed by assembling existing components –
built, reused or bought.
Especially user organisations.
(DSDM Consortium, 2003)
26
Assembly CBD and DSDM




Focus is on reuse of business components.
Components provide business functionality and data
handling – interface is built.
Identify areas where components could be used
Identify suitable components




Browse a repository?
Need to be documented in business terms
Used in prototypes
Testing throughout development addresses trust issues.
27
Summary





A general overview of software reuse
What design patterns are, and how and when they are
used – reusable fragments of OO analysis/design.
The major advantages of using design patterns in an
OO software development project – speed, cost savings,
easier maintenance, higher quality, less to learn.
The purpose of some well known patterns and an
example of a behavioural pattern
The motivation for Component Based Development and
some of the issues involved.
28
To Read

On reuse:


On patterns:


Bennett et al. (2005), chapter 20.
Bennett et al. (2002), chapter 15.
Interesting perspective on component based
development:

DSDM Consortium (2003), “DSDM and ComponentBased Development,”
http://www.dsdm.org/en/products/white_papers.asp
[accessed 23/11/05].
29
References







Allen, P. and Frost, S. (1998), Component-Based Development for
Enterprise Systems: Applying The SELECT Perspective, CUP .
Bennett, S., McRobb, S. & Farmer, R. (2005), Object-Oriented Systems
Analysis and Design using UML, 3rd edn., McGraw-Hill.
Coplien, J.O. (1995), “A Development Process Generative Pattern
Language.” In J. O. Coplien and D. C. Schmidt, eds, Pattern Languages of
Program Design, chapter 13, 183-237. Addison-Wesley.
http://users.rcn.com/jcoplien/Patterns/Process/
Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1994), Design Patterns –
Elements of Reusable Object Oriented Software, Addison-Wesley,
Jacobson, I., Griss, M. & Jonsson, P. (1997), Software Reuse: Architecture,
Process and Organization for Business Success, Addison-Wesley.
Szyperski, C. (1998), Component Software, Wiley.
van Welie, M. & H Traetteberg, H. (2000), “Interaction Patterns in User
Interfaces”, Proc. Seventh Pattern Languages of Programs Conference:
PLoP 2000.
http://www.knowlesys.com/technology/design/Interaction_Patterns_In_Us
er_Interfaces.pdf
30