1 / 30

CM602: Effective Systems Development

CM602: Effective Systems Development. Lecture 10: Reuse, Design Patterns & Component-Based Development. 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. Question.

hazelle
Download Presentation

CM602: Effective Systems Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. None Everything developed from scratch. Informal Code Reuse Programmers who trust each other swap code to save time during development. Black Box Re-use Some pieces of code engineered for re-use. Their use is mandated. Managed Workproduct Reuse An organisational structure is put into place to manage re-useable code Architected Reuse A common architecture is used for all development processes. Reuse Driven All software development is geared for maximum possible re-use. Jacobson’s 6 Levels of Reuse Adoption 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. 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). Patterns - Motivation for Use

  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. Campaign CampaignState currentStateIdentifier addAdvert( ) calcCosts( ) addAdvert( ) changeState( ) calcCosts( ) Contains the object identifier of the current state object Commissioned Completed Active Paid addAdvert( ) calcCosts( ) addAdvert( ) calcCosts( ) addAdvert( ) calcCosts( ) addAdvert( ) calcCosts( ) Behavioural Patterns: State State pattern applied to the classCampaign

  14. Context State operation( ) operation( ) ConcreteStateA ConcreteStateB operation( ) operation( ) General form of State Pattern

  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 handling • GUI widgets, e.g. VBX • Larger business routines, e.g. • Label printing • Meeting scheduling • General purpose modules, e.g. • Database connectivity • Web mail • Entire application system/subsystem • Contact management • Financial 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

More Related