Design Patterns in Information System Development

1. The Fifth Australasian Workshop onSoftware and Systems Architectures Geoffrey J. KennedySchool of Information TechnologiesThe University of Sydney, NSW 2006gkennedy@it.usyd.edu.au Design Patterns in Information System Development G J Kennedy 2004

2. 31 32 x x x 21 22 x x 11 12 x University Accommodation: Room Allocations One and only one student for each room G J Kennedy 2004

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

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

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

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

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

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

9. 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 G J Kennedy 2004

10. 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” G J Kennedy 2004

11. A: Interface idiomsStandardWindows dialog options ?? etc., etc. G J Kennedy 2004

12. 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 implementedin some other way G J Kennedy 2004

13. B: Conceptual idiomsConceptual system features that are assumed or actually supported G J Kennedy 2004

14. 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 G J Kennedy 2004

15. C: Architectural idiomsRelate to the way in which screens, etc. may be assembled G J Kennedy 2004

16. 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 G J Kennedy 2004

17. 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 G J Kennedy 2004

18. Name Abstract Problem Context Forces Solution Variants Examples Resulting Context Rationale Related Patterns Known Uses Ten essential elements B. Appleton, “Patterns and Software: Essential Concepts and Terminology”, 2000 G J Kennedy 2004

19. D: Design Patterns‘Nuggets of design’ “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] G J Kennedy 2004

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

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

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

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

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

25. 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; G J Kennedy 2004

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

27. Valid Combinations PatternUnderlying data structure Product Colour G J Kennedy 2004

28. G J Kennedy 2004

29. 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 G J Kennedy 2004

30. 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. G J Kennedy 2004

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

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

33. Research questions (3) • 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? • 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? G J Kennedy 2004