1

CM602: Effective Systems Development

Lecture 10: Reuse, Design Patterns & Component-Based Development

2

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

3

Question

Why is reuse regarded as important?

4

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.

5

Problems with Reuse

Inappropriate project choice Planning for reuse too late Level of coupling between classes Lack of standards

6

Jacobson’s 6 Levels of Reuse Adoption

1. None Everything developed

from scratch.

2. Informal Code Reuse Programmers who

trust each other swap code to save time during development.

3. Black Box Re-use Some pieces of code

engineered for re-use. Their use is mandated.

4. Managed Workproduct Reuse An organisational

structure is put into place to manage re-useable code

5. Architected Reuse A common architecture is

used for all development processes.

6. Reuse Driven All software development

is geared for maximum possible re-use.

Ref: Jacobson et al, 1997

7

Terminology

Design patterns General solutions that can be applied to

specific problems Frameworks

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

8

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)

9

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.

10

Categories of Patterns

Creational about construction of object instances

Structural 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)

11

Patterns - Motivation for Use Simpler maintenance, less to learn

Standard methods of implementing functionality. Increase flexibility:

Avoid creating objects directly “Abstract Factory”

Avoiding hard coded operation requests “Command”

Location independence “Proxy”

Loose Coupling: “Observer”, “Command”

Easier to alter existing classes “Decorator”, “Adapter”

Ref: Gamma et al (1994).

12

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

13

Behavioural Patterns: State

Contains the object identifier of the current state object

CampaignState

addAdvert( )

calcCosts( )

Commissioned

addAdvert( )

calcCosts( )

Campaign

currentStateIdentifier

addAdvert( )

changeState( )

calcCosts( )

Active

addAdvert( )

calcCosts( )

Completed

addAdvert( )

calcCosts( )

Paid

addAdvert( )

calcCosts( )

State pattern applied to the class Campaign

14

General form of State Pattern

State

operation( )

ConcreteStateA

operation( )

ConcreteStateB

operation( )

Context

operation( )

15

Problems with Patterns

Can limit creativity Uncontrolled use may lead to over-design Need culture of reuse

16

Other patterns Analysis patterns

E.g. Party, Organization Hierarchies (Fowler, 1996) Interaction patterns

E.g. Favourites, Step-by-Step Instructions (van Welie & Traetteberg, 2000)

Organisational patterns Organisational structure and process, especially for

development processes (Coplien, 1995) Architectural Patterns (both types!)

Architectures for various kinds of systems. http://www.opengroup.org/architecture/togaf8-doc/arch/p4/

patterns/patterns.htm Anti-patterns

Common bad solutions Why they don’t work; what to do instead

17

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)

18

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)

19

Granularity of components Can be

Small-scale, e.g.Common business routines, e.g. date handlingGUI widgets, e.g. VBX

Larger business routines, e.g.Label printingMeeting scheduling

General purpose modules, e.g. Database connectivityWeb mail

Entire application system/subsystemContact managementFinancial instruments

20

Sources of components

Built for the purpose Re-used from previous developments Bought Re-engineered from existing software

Repository of available components

21

CBD claims Delivers usable software more quickly Reduces risk, raises reliability, because pre-

existing components have already been tested. Is this all that’s needed for reliability?

Maintainable – individual components can be replaced or redeveloped without affecting others

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

22

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?

23

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?

24

Standards & Protocols Essential to ensure interoperability. E.g.

CORBA Web services SOAP XML Java, Java Beans, EJB COM, COM+, DCOM Etc.

25

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

26

Approaches to CBD Revolutionary

Business wide set of generic components are produced from scratch.

Architectural approach. Organisation-wide redevelopment, or component

suppliers. Evolutionary

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)

27

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.

28

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.

29

To Read

On reuse: Bennett et al. (2005), chapter 20.

On patterns: Bennett et al. (2002), chapter 15.

Interesting perspective on component based development:

DSDM Consortium (2003), “DSDM and Component-Based Development,” http://www.dsdm.org/en/products/white_papers.asp [accessed 23/11/05].

30

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_User_Interfaces.pdf