1. IM 2042 – Information Systems Modeling and Design Topic 4 – Refining the Requirements Model. Design Patterns Based on chapters 8 and 15 of Bennett, McRobb and Farmer:

2. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 2 In This Lecture You Will Learn: About reuse in software development; How object-orientation contributes to reuse; How to identify and model aggregation, composition and generalisation; An approach to modelling components; About ‘patterns’ in software development; How analysis patterns help to structure a model.  what types of patterns have been identified in software development  how to apply design patterns during software development  the benefits and difficulties that may arise when using patterns

3. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 3 Software development has concentrated on inventing new solutions Recently, the emphasis has shifted Much software is now assembled from components that already exist Component reuse can save money, time and effort Reuse in Software Development

4. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 4 Reuse in Software Development Achieving reuse is still hard ­Reuse is not always appropriate – can’t assume an existing component meets a new need ­Poor model organisation makes it hard to identify suitable components ­The NIH (Not-Invented-Here) syndrome ­Requirements and designs are more difficult to reuse than code

5. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 5 Reuse: The Contribution of OO Encapsulation makes components easier to use in systems for which they were not originally designed Aggregation and composition can be used to encapsulate a group of classes that collectively have the capacity to be reusable subassembly. Generalisation allows the creation of new specialised classes when needed Components are complex structures that are developed separately from each other and then simply ‘plugged together’ to achieve the desired functionality. ­It has to meet a clear-cut but general need ­It has one or more simple, well-defined external interfaces

6. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 6 Aggregation and Composition Special types of association, both sometimes called whole-part A campaign is made up of adverts: Campaign Advert 0..*1 Unfilled diamond signifies aggregation

7. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 7 Aggregation is essentially any whole-part relationship Semantics can be very imprecise Composition is ‘stronger’: ­Each part may belong to only one whole at a time ­When the whole is destroyed, so are all its parts Aggregation and Composition

8. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 8 Adding Generalisation Structure Add generalisation structures when: ­Two classes are similar in most details, but differ in some respects ­May differ:  In behaviour (operations or methods)  In data (attributes)  In associations with other classes

9. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 9 Standard UML techniques can be used to model components Component internals can be detailed in a class diagram Component interaction can be shown in a communication diagram Modelling Components in UML

10. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 10 Modelling Components in UML UML has icons for modelling components in structure diagrams (e.g. class diagrams) « component » Payments TakePayment « component » Bookings Provided interface offers servicesRequired interface uses services Ball-and-socket connector maps provided interface of one component to required interface of another

11. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 11 Modelling Components in UML Structure diagrams can mix component icons with other icons, e.g. interfaces «interface» Allocate Seats GetFreeSeats(seatType) AllocateSeat(seatRef) DeallocateSeat(seatRef) Flight Management «component» «realize»

12. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 12 Software Development Patterns A pattern: “describes a problem which occurs over and over again in our environment, 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.” Alexander et al. (1977) Are problem-centred, not solution-centred Are Discovered, not invented - they already exist Complement existing techniques and do not replace them Capture and communicate “best practice” and expertise

13. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 13 Software Development Patterns A pattern is proven solution to a problem that recurs in a particular context. A pattern has: ­A context = a set of circumstances or preconditions for the problem to occur ­Forces = the issues that must be addressed ­A software configuration that resolves the forces

14. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 14 Software Development Patterns Patterns are found at many points in the systems development lifecycle: ­Analysis patterns are groups of concepts useful in modelling requirements ­Architectural patterns describe the structure of major components of a software system ­Design patterns describe the structure and interaction of smaller software components

15. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 15 Application of Patterns Applied to software design since early 90’s Now used in in: ­Project management ­Organisation structures ­Requirements analysis ­System design ­General modelling approaches ­Programming – (called idioms) ­...

16. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 16 Patterns vs. Frameworks Frameworks are partially completed software systems that may be targeted at a specified type of application. Framework is a reusable mini-architecture that provides structure and behaviour to all applications of this type. However patterns ­are more abstract and general than frameworks ­cannot be directly implemented in a particular software environment ­are more primitive than frameworks. A framework can employ several patterns but a pattern cannot incorporate a framework.

17. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 17 Catalogues & Languages A pattern catalogue is a group of patterns that are related to some extent and may be used together or independently of each other The patterns in a pattern language are more closely related, and work together to solve problems in a specific domain

18. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 18 Key Principles Key principles that underlie patterns ­abstraction ­encapsulation ­information hiding ­modularization ­separation of concerns

19. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 19 Key Principles ­coupling and cohesion ­sufficiency ­completeness and primitiveness ­separation of policy and implementation ­separation of interface and implementation ­single point of reference ­divide and conquer Buschmann et al. (1996)

20. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 20 Pattern Template Name - meaningful that reflects the knowledge embodied by the pattern Problem - description of the problem that the pattern addresses (the intent of the pattern). Context - represents the circumstances or preconditions under which it can occur. Forces - embodied in a pattern are the constraints or issues that must be addressed by the solution Solution - description of the static and dynamic relationships among the components of the pattern

21. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 21 Other aspects of Templates An example of the use of a pattern that serves as a guide to its application The context that results from the use of the pattern The rationale that justifies the chosen solution Related patterns

22. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 22 Analysis Patterns First introduced by Fowler in 1997. “Analysis patterns are groups of concepts that represent a common construction in business modelling.“ An analysis pattern may be relevant to only one domain, or it may span many domains.

23. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 23 Simple Analysis Pattern Transaction transactionNumber transactionDate transactionTotal updateTransactionTotal ( ) TransactionLineItem TransactionLineNumber transactionLineQuantity transactionLineValue comprises *1 An analysis pattern is a structure of classes and associations that is found to occur over and over again in many modelling situations.

24. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 24 Accountability Analysis Pattern AccountabilityType Accountability Time Period Party Person Organization commissioner responsible ** * 1 1 1 * 1 Problem: Representing organization structures, employment, management, professional registration, and contracts with a similar structure. Solution: Create accountability as a directed relationship between two parties. Give it an accountability type to represent the kind of relationship.

25. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 25 GOF Design Patterns Catalogue of 23 design patterns presented by Gamma et al. (1995) patterns known as Gang of Four – hence GOF Patterns Classified as creational, structural or behavioural Typically address issues concerning changeability involves several different aspects maintainability, extensibility, restructuring and portability

26. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 26 Creational Patterns Concerned with the construction of object instances Separate the operation of an application from how its objects are created Gives the designer considerable flexibility in configuring all aspects of object creation

27. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 27 Creational Patterns: Singleton How does one ensure that only one instance of the company class is created? Company companyName companyAddress companyRegistrationNumber getCompanyDetails ()

28. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 28 Creational Patterns: Singleton Solution – restrict access to the constructor! Company - companyInstance - companyName - companyAddress - companyRegistrationNumber + getCompanyInstance() + getCompanyDetails() Class-scope (or static) attribute (or static) operation - Company() Private constructor The use of class-scope operations allows global access Class-scope

29. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 29 Creational Patterns: Singleton Company - companyInstance - companyName - companyAddress + getCompanyInstance() + getCompanyDetails() - Company() + getCompanyDetails():String - UkCompany():UkCompany - companyRegistrationNumber UKCompany + getCompanyDetails():String - USACompany():USACompany - companyRegistrationNumber USACompany + getCompanyDetails():String - FrenchCompany():FrenchCompany - companyRegistrationNumber FrenchCompany The attribute companyRegistrationNumber has been moved to the subclasses where it is defined differently in each. The operation getCompanyDetails() has been moved to the subclasses where it is polymorphically redefined in each. Different subclasses of Company can be instantiated as needed, depending on run-time circumstances

30. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 30 Creational Patterns: Singleton + getInstance() Singleton - uniqueInstance - singletonData + getSingletonData() + singletonOperation() - Singleton() Holds object identifier for the Singleton instance Returns object identifier for the unique instance Private constructor — only accessible via getInstance() General form of Singleton pattern

31. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 31 Structural Patterns Concerned with the way in which classes and objects are organized Offer effective ways of using object-oriented constructs such as inheritance, aggregation and composition to satisfy particular requirements

32. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 32 Structural Patterns: Composite MediaClip play() VideoClip play() SoundClip play() How can we present the same interface for a media clip whether it is composite or not?

33. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 33 Structural Patterns: Composite Delegates to the play() operation in the components. play() is polymorphically redefined VideoClip play() SoundClip play() AdSequence play() addClip() removeClip() getChild() * * 1 How can we incorporate composite structures?

34. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 34 Composite applied to Agate Collection of MediaClip object identifiers for all m in mediaClipCollection m.play() Delegates to the play() operation in the components. play() is polymorphically redefined AdSequence mediaClipCollection play() addClip() removeClip() getChild() changeSequence() * 1 MediaClip play() addClip() removeClip() getChild() VideoClip play() SoundClip play() Advert {ordered}

35. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 35 Composite Pattern General Form Collection of Component object identifiers for all c in componentCollection c.anOperation() anOperation() is polymorphically redefined Composite componentCollection anOperation() addComponent() removeComponent() getChild() * 1 Component anOperation() addComponent() removeComponent() getChild() Leaf anOperation() OtherLeaf anOperation() Client

36. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 36 Behavioural Patterns Address the problems that arise when assigning responsibilities to classes and when designing algorithms Suggest particular static relationships between objects and classes and also describe how the objects communicate

37. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 37 Behavioural Patterns: State Consider the class Campaign. 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

38. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 38 Campaign class: could have state pattern applied If commissioned then... If active then... If completed then... If paid then... Illustrative Structured English for the calcCosts() operation «entity» Campaign - title - campaignStartDate - campaignFinishDate - estimatedCost - completionDate - datePaid - actualCost - campaignOverheads - advertCollection - teamMembers + Campaign() + assignManager() + assignStaff() + checkCampaignBudget() + calcCosts() + checkStaff() + getDuration() + getTeamMembers() + linkToNote() + addAdvert() + listAdverts() + recordPayment() + getCampaignDetails() - getOverheads() + completeCampaign()

39. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 39 Behavioural Patterns: State State pattern applied to the class Campaign Contains the object identifier of the current state object CampaignState addAdvert() calcCosts() completeCampaign() Commissioned addAdvert() calcCosts() completeCampaign() Campaign currentStateIdentifier addAdvert() changeState() calcCosts() changeState() completeCampaign() Active addAdvert() calcCosts() completeCampaign() Completed addAdvert() calcCosts() completeCampaign() Paid addAdvert() calcCosts() completeCampaign()

40. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 40 Behavioural Patterns: State Some State pattern objects for Agate – note that there are 6 Campaign objects sharing the four State objects. a:Campaign c:Campaign e:Campaignb:Campaign f:Campaign d:Campaign :Commissioned :Active :Completed :Paid

41. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 41 General form of State Pattern State operation() ConcreteStateA operation() ConcreteStateB operation() Context operation()

42. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 42 Before Using Patterns Before using a pattern to resolve the problem ask ­Is there a pattern that addresses a similar problem? ­Does the pattern trigger an alternative solution that may be more acceptable? ­Is there a simpler solution? Patterns should not be used just for the sake of it ­Is the context of the pattern consistent with that of the problem? ­Are the consequences of using the pattern acceptable? ­Are constraints imposed by the software environment that would conflict with the use of the pattern?

43. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 43 Using Patterns After selecting a suitable pattern 1.Read the pattern to get a complete overview 2.Study the Structure, Participants and Collaborations of the pattern in detail 3.Examine the Sample Code to see an example of the pattern in use 4.Choose names for the pattern’s participants (i.e. classes) that are meaningful to the application 5.Define the classes 6.Choose application specific names for the operations 7.Implement operations that perform the responsibilities and collaborations in the pattern

44. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 44 Summary In this lecture you have learned about: How to identify and model aggregation, composition and generalisation Reusable components, and how to model them in structure diagrams What is meant by ‘pattern’, and how patterns are used in software development

45. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 45 Summary In this lecture you have learned about:  what types of patterns have been identified in software development  how to apply design patterns during software development  the benefits and difficulties that may arise when using patterns

46. © Bennett, McRobb and Farmer 2005 IM 2042 – Information Systems Modeling & Design Topic 4 Slide 46 References Bennett, McRobb and Farmer (2005) Ambler (2003) Cheesman and Daniels (2001) Coad (1997) Fowler (1997) (For full bibliographic details, see Bennett, McRobb and Farmer)