AWSA04 - 1 G J Kennedy 2004 Design Patterns in Information System Development Geoffrey J. Kennedy School of Information Technologies The University of

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


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


Shirt OrdersShirt Orders

xx

x

x

One and only one order for each size


Best Practice Questionnaire

Best Practice Questionnaire

One and only one answer for each question


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


‘Magic blocks’ in information system design

‘Magic blocks’ in information system design

Just like building with ‘Lego’!

Kennedy, 1993


The building blocks are all there …The building blocks are all there …


… you just have to learn when and how use them

… you just have to learn when and how use them


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


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”


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.


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


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


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


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


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


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


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


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]


Six Design PatternsSix Design Patterns

D1: Parameter Table Last order number (Office furniture)

D2: Multilevel Parameter Discount based on quantity purchased


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


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)


The Statement Pattern (2)Underlying data structure

The Statement Pattern (2)Underlying data structure


The Statement Pattern (1)Required output

The Statement Pattern (1)Required output


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;


Six Design Patterns (Continued)Six Design Patterns (Continued)

D4: Active Array Theatre bookings

D6: Valid Combinations Product and colours (Office furniture)


Valid Combinations PatternUnderlying data structure

Valid Combinations PatternUnderlying data structure

Product Colour



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




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.


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?


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?


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?

Documents

AWSA04 - 1 G J Kennedy 2004 Design Patterns in Information System Development Geoffrey J. Kennedy School of Information Technologies The University of