Upload
jakeem-wolfe
View
34
Download
0
Embed Size (px)
DESCRIPTION
The Fifth Australasian Workshop on Software and Systems Architectures. Geoffrey J. Kennedy School of Information Technologies The University of Sydney, NSW 2006 [email protected]. Design Patterns in Information System Development. 31. 32. x. x. x. 21. 22. x. x. 11. 12. x. - PowerPoint PPT Presentation
Citation preview
AWSA04 - 1 G J Kennedy 2004
Design Patterns in Information System Development
Design Patterns in Information System Development
Geoffrey J. KennedySchool of Information Technologies
The University of Sydney, NSW [email protected]
Geoffrey J. KennedySchool of Information Technologies
The University of Sydney, NSW [email protected]
The Fifth Australasian Workshop onSoftware and Systems ArchitecturesThe Fifth Australasian Workshop onSoftware and Systems Architectures
AWSA04 - 2 G J Kennedy 2004
University Accommodation: Room AllocationsUniversity Accommodation: Room Allocations
ROOM NUM11122122313211 12
21
31 32
22
xxx
xx
x
One and only one student for each room
AWSA04 - 3 G J Kennedy 2004
Shirt OrdersShirt Orders
xx
x
x
One and only one order for each size
AWSA04 - 4 G J Kennedy 2004
Best Practice Questionnaire
Best Practice Questionnaire
One and only one answer for each question
AWSA04 - 5 G J Kennedy 2004
Three applications 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
AWSA04 - 6 G J Kennedy 2004
‘Magic blocks’ in information system design
‘Magic blocks’ in information system design
Just like building with ‘Lego’!
Kennedy, 1993
AWSA04 - 7 G J Kennedy 2004
The building blocks are all there …The building blocks are all there …
AWSA04 - 8 G J Kennedy 2004
… you just have to learn when and how use them
… you just have to learn when and how use them
AWSA04 - 9 G J Kennedy 2004
Hierarchy of system design elementsHierarchy of system design elements
A: User interface: interface idiomsA: User interface: interface idioms
B: Conceptual elements: conceptual idiomsB: Conceptual elements: conceptual idioms
C: Design architecture: architectural idiomsC: Design architecture: architectural idioms
D: Solutions to specific problems: design patternsD: Solutions to specific problems: design patterns
AWSA04 - 10 G J Kennedy 2004
Design idiomsDesign 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”
AWSA04 - 11 G J Kennedy 2004
A: Interface idiomsStandard Windows dialog options
A: Interface idiomsStandard 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.?? etc., etc.
AWSA04 - 12 G J Kennedy 2004
Conceptual idiomsConceptual 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
AWSA04 - 13 G J Kennedy 2004
B: Conceptual idiomsConceptual system features that are assumed or actually supported
B: Conceptual idiomsConceptual system features that are assumed or actually supported
B1 BufferedInput
B4 ScreenNavigation
B7 RecordComplex
B2 ProcessingMode
B5 ParameterPassing
B8 Screen Oriented Processing
B3 File Types B6 Control Break B9 File OrientedProcessing
AWSA04 - 14 G J Kennedy 2004
Architectural idiomsArchitectural 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
AWSA04 - 15 G J Kennedy 2004
C: Architectural idiomsRelate to the way in which screens, etc. may be assembled
C: Architectural idiomsRelate to the way in which screens, etc. may be assembled
C1 MainScreen
C3 DriverScreen
C5 PopupScreen
C2 DataScreen
C4 Master DetailScreen
AWSA04 - 16 G J Kennedy 2004
Design patternsDesign 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
AWSA04 - 17 G J Kennedy 2004
A true software pattern should satisfy the following criteria:
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
AWSA04 - 18 G J Kennedy 2004
Ten essential elementsTen 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
AWSA04 - 19 G J Kennedy 2004
D: Design Patterns‘Nuggets of design’
D: Design Patterns‘Nuggets of design’
D1 ParameterTable
D3 TemplateDriven Input
D5 Statement
D2 MultilevelParameter
D4 Active Array D6 ValidCombinations
“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]
AWSA04 - 20 G J Kennedy 2004
Six Design PatternsSix Design Patterns
D1: Parameter Table Last order number (Office furniture)
D2: Multilevel Parameter Discount based on quantity purchased
AWSA04 - 21 G J Kennedy 2004
Quantity discounts:
5 or more items 5%
10 or more items 10%
20 or more items 15%
Multilevel ParameterMultilevel Parameterrst.MoveFirst
Do While Not rst.EOF
If inQuant >= rst!CutOffLevel Then
DiscRate = rst!DiscountRate
Exit Do
End If
rst.MoveNext
Loop
Key CutOffLevel DiscountRate1 20 152 10 103 5 54 0 0
AWSA04 - 22 G J Kennedy 2004
Six Design Patterns (Continued)Six Design Patterns (Continued)
D3: Template Driven Input Room allocation Shirt orders Practitioner questionnaire
D5: Statement Jobs and payments (electronics servicing)
AWSA04 - 23 G J Kennedy 2004
The Statement Pattern (2)Underlying data structure
The Statement Pattern (2)Underlying data structure
AWSA04 - 24 G J Kennedy 2004
The Statement Pattern (1)Required output
The Statement Pattern (1)Required output
AWSA04 - 25 G J Kennedy 2004
The Statement Pattern (3)Union query
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;
AWSA04 - 26 G J Kennedy 2004
Six Design Patterns (Continued)Six Design Patterns (Continued)
D4: Active Array Theatre bookings
D6: Valid Combinations Product and colours (Office furniture)
AWSA04 - 27 G J Kennedy 2004
Valid Combinations PatternUnderlying data structure
Valid Combinations PatternUnderlying data structure
Product Colour
AWSA04 - 28 G J Kennedy 2004
AWSA04 - 29 G J Kennedy 2004
Benefits of recognising and using design patterns (1)
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
AWSA04 - 30 G J Kennedy 2004
Benefits of recognising and using design patterns (2)
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.
AWSA04 - 31 G J Kennedy 2004
Discussion questions (1)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?
AWSA04 - 32 G J Kennedy 2004
Research questions (2)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?
AWSA04 - 33 G J Kennedy 2004
Research questions (3)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?