Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | dale-murphy |
View: | 220 times |
Download: | 1 times |
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