1. AWSA04 - 1 G J Kennedy 2004 Design Patterns in Information System Development Geoffrey J. Kennedy School of Information Technologies The University of Sydney, NSW 2006 gkennedy@it.usyd.edu.au The Fifth Australasian Workshop on Software and Systems Architectures

2. AWSA04 - 2 G J Kennedy 2004 University Accommodation: Room Allocations 1112 21 3132 22 x x x x x x One and only one student for each room

3. AWSA04 - 3 G J Kennedy 2004 Shirt Orders x x x x One and only one order for each size

4. AWSA04 - 4 G J Kennedy 2004 Best Practice Questionnaire One and only one answer for each question

5. AWSA04 - 5 G J Kennedy 2004 Three applications 1. SouthTech: Allocating students to rooms in a university residence 2. SuperShirts: Ordering shirts for a set of sizes from SM (small men’s) to XL (extra large) 3. Best Practice: Entering questionnaire responses from a form One common problem

6. AWSA04 - 6 G J Kennedy 2004 ‘Magic blocks’ in information system design Just like building with ‘Lego’! Kennedy, 1993

7. AWSA04 - 7 G J Kennedy 2004 The building blocks are all there …

8. AWSA04 - 8 G J Kennedy 2004 … you just have to learn when and how use them

9. AWSA04 - 9 G J Kennedy 2004 Hierarchy of system design elements A: User interface: interface idioms B: Conceptual elements: conceptual idioms C: Design architecture: architectural idioms D: Solutions to specific problems: design patterns

10. AWSA04 - 10 G J Kennedy 2004 Design idioms In systems design an idiom describes ‘how particular design components or the relationships between them may be implemented using the features of the given language or tool’. Buschmann et al. (1996) “Pattern-Oriented Software Architecture: A System of Patterns”

11. AWSA04 - 11 G J Kennedy 2004 A: Interface idioms Standard Windows dialog options A1 Text Box A4 Check Box A7 Menu Bar A2 List Box A5 Radio Button A8 Message Box A3 Combo Box A6 Command Button ?? etc., etc.

12. AWSA04 - 12 G J Kennedy 2004 Conceptual idioms Affect the way we think about design and development Are not necessarily implemented in all tools Help us to form mental models about mechanisms (what is going on ‘inside’) Affect ease of use of the tool and productivity, hence quality of product If not provided, may have to be implemented in some other way

13. AWSA04 - 13 G J Kennedy 2004 B: Conceptual idioms Conceptual system features that are assumed or actually supported B1 Buffered Input B4 Screen Navigation B7 Record Complex B2 Processing Mode B5 Parameter Passing B8 Screen Oriented Processing B3 File Types B6 Control Break B9 File Oriented Processing

14. AWSA04 - 14 G J Kennedy 2004 Architectural idioms An architectural idiom expresses a fundamental structural organisation or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organising the relationships between them. Buschmann et al. “Pattern-Oriented Software Architecture: A System of Patterns”, 1996

15. AWSA04 - 15 G J Kennedy 2004 C: Architectural idioms Relate to the way in which screens, etc. may be assembled C1 Main Screen C3 Driver Screen C5 Popup Screen C2 Data Screen C4 Master Detail Screen

16. AWSA04 - 16 G J Kennedy 2004 Design patterns A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context. F. Buschmann et al. “Pattern-Oriented Software Architecture: A System of Patterns”, 1996

17. AWSA04 - 17 G J Kennedy 2004 A true software pattern should satisfy the following criteria: (i)it solves a real recurring problem, (ii)it has a proven ‘track record’ of success, (iii)it is not obvious; it may be in some way indirect, (iv)it describes a relationship, for example between structures or mechanisms, and (v)it has a significant human component, either appealing to aesthetics or utility. J. Coplien, “ Software Design Patterns: Common Questions and Answers”, 1995

18. AWSA04 - 18 G J Kennedy 2004 Ten essential elements 1. Name Abstract 2. Problem 3. Context 4. Forces 5. Solution Variants 6. Examples 7. Resulting Context 8. Rationale 9. Related Patterns 10. Known Uses B. Appleton, “ Patterns and Software: Essential Concepts and Terminology”, 2000

19. AWSA04 - 19 G J Kennedy 2004 D: Design Patterns ‘Nuggets of design’ D1 Parameter Table D3 Template Driven Input D5 Statement D2 Multilevel Parameter D4 Active Array D6 Valid Combinations “A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces”. [Appleton, 2000]

20. AWSA04 - 20 G J Kennedy 2004 Six Design Patterns D1: Parameter Table Last order number (Office furniture) D2: Multilevel Parameter Discount based on quantity purchased

21. AWSA04 - 21 G J Kennedy 2004 Quantity discounts: 5 or more items5% 10 or more items10% 20 or more items15% Multilevel Parameter rst.MoveFirst Do While Not rst.EOF If inQuant >= rst!CutOffLevel Then DiscRate = rst!DiscountRate Exit Do End If rst.MoveNext Loop

22. AWSA04 - 22 G J Kennedy 2004 Six Design Patterns (Continued) D3: Template Driven Input Room allocation Shirt orders Practitioner questionnaire D5: Statement Jobs and payments (electronics servicing)

23. AWSA04 - 23 G J Kennedy 2004 The Statement Pattern (2) Underlying data structure

24. AWSA04 - 24 G J Kennedy 2004 The Statement Pattern (1) Required output

25. AWSA04 - 25 G J Kennedy 2004 The Statement Pattern (3) Union query SELECT 1 as t_type, c.client_id, j.job_num, j.job_start_date as t_date, 'Invoice '+str(j.job_invoice_num) as t_desc, sum(jd.jdet_amount) as t_amt FROM CLIENT c, JOB j, JOB_DETAIL jd WHERE j.JOB_NUM = jd.JOB_NUM AND c.CLIENT_ID = j.CLIENT_ID AND j.JOB_STATUS > 0 GROUP BY c.client_id, j.job_num, J.JOB_START_DATE, J.JOB_INVOICE_NUM ORDER BY c.client_id, j.job_num UNION SELECT 2 as t_type, c.client_id, j.job_num, p.pay_date as t_date, 'Payment, thankyou' as t_desc, p.pay_amount as t_amt FROM CLIENT c, JOB j, PAYMENT p WHERE c.CLIENT_ID = j.CLIENT_ID AND j.job_num = p.job_num GROUP BY c.client_id, j.job_num, p.pay_date, p.pay_amount;

26. AWSA04 - 26 G J Kennedy 2004 Six Design Patterns (Continued) D4: Active Array Theatre bookings D6: Valid Combinations Product and colours (Office furniture)

27. AWSA04 - 27 G J Kennedy 2004 Valid Combinations Pattern Underlying data structure ProductColour

28. AWSA04 - 28 G J Kennedy 2004

29. AWSA04 - 29 G J Kennedy 2004 Benefits of recognising and using design patterns (1) Saves wasting time solving problems whose solution is already known (‘re-inventing the wheel’) Improves productivity, since less time required to implement a solution and less time required for testing Improves quality, since known solution is ‘good’ having been checked by other developers

30. AWSA04 - 30 G J Kennedy 2004 Benefits of recognising and using design patterns (2) Facilitates porting between implementation media, and between development tools since general structure and algorithms remain the same Provides a communication ‘language’ for discussion between developers Leads to consistency within and between application systems and across platforms.

31. AWSA04 - 31 G J Kennedy 2004 Discussion questions (1) 1. Can the design patterns described in this proposal be considered as “patterns” in the sense intended by Gamma and others? 2. Are these patterns sufficiently ‘recurring’ to merit further attention? 3. Do the Interface idioms, Conceptual idioms and Architectural idioms contribute to the ‘state of knowledge’ about system development? 4. Are the six design patterns proposed specified sufficiently completely?

32. AWSA04 - 32 G J Kennedy 2004 Research questions (2) 5. Are there any further design patterns or is the list exhaustive? If not, what are they? 6. Can we demonstrate that the lists of idioms and design patterns is in any sense complete? 7. How useful would the design patterns be to professional system developers? 8. Do the solutions proposed translate adequately to other computer languages and development tools?

33. AWSA04 - 33 G J Kennedy 2004 Research questions (3) 9. Does the current discipline of software patterns need to be modified/expanded to incorporate the design patterns described here, or are they sufficient to stand in their own right? 10. If the design patterns described here fail to meet the requirements of software patterns how else should they be dealt with, given the evidence for their existence in everyday applications?

34. AWSA04 - 34 G J Kennedy 2004 Definition of a software pattern A pattern is the abstraction from a concrete form which keeps recurring in specific non- arbitrary contexts. [Riehle and Zullighoven,1996] A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces. [Appleton, 2000]

35. AWSA04 - 35 G J Kennedy 2004 ‘Lego’ works like a language http://www.ncf.carleton.ca/~aa333/lang.html “Putting smaller parts together to make larger parts is another interesting thing about languages. They are made up of many layers, each layer being built of the simpler layer below. In written languages, we put letters together to make words, we put words together to make sentences, we put sentences together to make paragraphs, and we put paragraphs together to make stories. In each layer, we have a set of parts, rules for putting the parts together, and we use particular arrangements of parts to communicate ideas to other people”. “Putting smaller parts together to make larger parts is another interesting thing about languages. They are made up of many layers, each layer being built of the simpler layer below. In written languages, we put letters together to make words, we put words together to make sentences, we put sentences together to make paragraphs, and we put paragraphs together to make stories. In each layer, we have a set of parts, rules for putting the parts together, and we use particular arrangements of parts to communicate ideas to other people”.

36. AWSA04 - 36 G J Kennedy 2004 Design patterns ‘Good’ solutions to recurring ‘knotty’ problems Help improve developer productivity Assure system quality If we choose not to adopt pattern solution, we need to be sure alternative solution is correct alternative solution is better If in doubt, we should try both solutions and compare them. Perhaps we have discovered a new pattern!

37. AWSA04 - 37 G J Kennedy 2004 “Magic blocks” (Kennedy, 1993) Identified standard solutions to commonly occurring problems encountered in the development of transaction processing systems Found surprisingly few distinct patterns, which recur frequently in a wide variety of applications Solutions were originally implemented using a 4GL tool called Axiant. Today you saw them implemented in Access. Analogous to software patterns as described by Gamma et al. for object-oriented software but concerned with transaction processing systems

38. AWSA04 - 38 G J Kennedy 2004 Ideas about program design “The Gang of Four” “One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again”. [Gamma, Helm, Johnson & Vlissides, 1995] “One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again”. [Gamma, Helm, Johnson & Vlissides, 1995]

39. AWSA04 - 39 G J Kennedy 2004 Alexander’s idea of pattern in architecture Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the 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 [Christopher Alexander, 1977]