Software Design Patterns in Theory

216
Yann-Gaël Guéhéneuc This work is licensed under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported License Some Theory and Practice on Patterns – In Theory NII, Tokyo, Japan 12/02/14

description

Following the previous lectures that focus on the practical uses of good and bad practices, we frame this practices in the context of the developers' cognitive characteristics. We first recall that developers' use sight first and foremost to acquire and reason about their systems. Then, we cast the use of patterns by developers and then discuss the visual system, memory models, and mental models.

Transcript of Software Design Patterns in Theory

Page 1: Software Design Patterns in Theory

Yann-Gaël Guéhéneuc

This work is licensed under a Creative Commons Attribution-NonCommercial-

ShareAlike 3.0 Unported License

Some Theory and Practice on Patterns – In Theory

NII, Tokyo, Japan12/02/14

Page 2: Software Design Patterns in Theory

2/216

Page 3: Software Design Patterns in Theory

3/216

Did you know that…

Page 4: Software Design Patterns in Theory

4/216

Vision is our dominant sense?

Page 5: Software Design Patterns in Theory

5/216

Page 6: Software Design Patterns in Theory

6/216

Page 7: Software Design Patterns in Theory

7/216

How does vision work?

Page 8: Software Design Patterns in Theory

8/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 9: Software Design Patterns in Theory

9/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 10: Software Design Patterns in Theory

10/216

Visual System

Vision Science: Photons to Phenomenology by Stephen E. Palmer

Page 11: Software Design Patterns in Theory

11/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

Page 12: Software Design Patterns in Theory

12/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

RegionAnalysis

Figure/GroupDistinction

VisualInterpolation

ItemsGrouping

Page 13: Software Design Patterns in Theory

13/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

RegionAnalysis

Figure/GroupDistinction

VisualInterpolation

ItemsGrouping

Comparison Decision

Page 14: Software Design Patterns in Theory

14/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

RegionAnalysis

Figure/GroupDistinction

VisualInterpolation

ItemsGrouping

Comparison Decision

Items(Visuo-spatial scratchpad)

ArticulatoryLoop

CentralExecutive

Long-termMemory

Page 15: Software Design Patterns in Theory

15/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

RegionAnalysis

Figure/GroupDistinction

VisualInterpolation

ItemsGrouping

Comparison Decision

Items(Visuo-spatial scratchpad)

ArticulatoryLoop

CentralExecutive

Long-termMemory

Page 16: Software Design Patterns in Theory

16/216

Visual SystemRetinalImage

Image-basedStage

Surface-basedStage

Item-basedStage

Category-basedStage

WorkingMemory

RegionAnalysis

Figure/GroupDistinction

VisualInterpolation

ItemsGrouping

Comparison Decision

Items(Visuo-spatial scratchpad)

ArticulatoryLoop

CentralExecutive

Long-termMemory

Page 17: Software Design Patterns in Theory

17/216

Visual System

Retinal image

Page 18: Software Design Patterns in Theory

18/216

Visual System

Retinal image

Page 19: Software Design Patterns in Theory

19/216

Visual System

Region analysis– Distinguish items based on their regions

Page 20: Software Design Patterns in Theory

20/216

Visual System

Region analysis– Distinguish items based on their regions

Zhuolin Jiang and Larry S. Davis ; Submodular Salient Region Detection ;Conference on Computer Vision and Pattern Recognition, IEEE, 2013

Page 21: Software Design Patterns in Theory

21/216

Visual System

Items grouping– Gestalt theory

• Gestalten: to put in form, to give structure

Fritz Perls*Berlin, July 8, 1893

†Chicago, March 14, 1970

Page 22: Software Design Patterns in Theory

22/216

Visual System

Page 23: Software Design Patterns in Theory

23/216

Visual System

Page 24: Software Design Patterns in Theory

24/216

Visual System

Page 25: Software Design Patterns in Theory

25/216

Visual System

Page 26: Software Design Patterns in Theory

26/216

Visual System

Items grouping– Laws of the Gestalt

Page 27: Software Design Patterns in Theory

27/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

Page 28: Software Design Patterns in Theory

28/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

Page 29: Software Design Patterns in Theory

29/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

• Continuity

Page 30: Software Design Patterns in Theory

30/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

• Continuity

Page 31: Software Design Patterns in Theory

31/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

• Continuity

• Proximity

Page 32: Software Design Patterns in Theory

32/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

• Continuity

• Proximity

Page 33: Software Design Patterns in Theory

33/216

Visual System

Items grouping– Laws of the Gestalt

• Good form

• Continuity

• Proximity

• Similitude

Page 34: Software Design Patterns in Theory

34/216

Visual System

Items grouping– Laws of the Gestalt

Page 35: Software Design Patterns in Theory

35/216

Visual System

Items grouping– Laws of the Gestalt

• Common destiny

Page 36: Software Design Patterns in Theory

36/216

Visual System

Items grouping– Laws of the Gestalt

• Common destiny

Page 37: Software Design Patterns in Theory

37/216

Visual System

Items grouping– Laws of the Gestalt

• Common destiny

• Closure

Page 38: Software Design Patterns in Theory

38/216

Visual System

Items grouping– Laws of the Gestalt

• Common destiny

• Closure

Completion

Page 39: Software Design Patterns in Theory

39/216

Visual System

Items grouping– Involvement of the memory

Page 40: Software Design Patterns in Theory

40/216

Visual System

Items grouping– Involvement of the memory

Page 41: Software Design Patterns in Theory

41/216

Visual System

Comparison– Involvement of the memory

Page 42: Software Design Patterns in Theory

42/216

Visual System

Comparison– Involvement of the memory

• Spatial

Page 43: Software Design Patterns in Theory

43/216

Visual System

Comparison– Involvement of the memory

• Spatial• Temporal

Page 44: Software Design Patterns in Theory

44/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 45: Software Design Patterns in Theory

45/216

Memory Models

One modelItems

(Visuo-spatial scratchpad)Articulatory

Loop

CentralExecutive

Long-termMemory

Page 46: Software Design Patterns in Theory

46/216

Memory Models

One modelItems

(Visuo-spatial scratchpad)Articulatory

Loop

CentralExecutive

Long-termMemory

EpisodicMemory

ProceduralMemory

SemanticMemory

Page 47: Software Design Patterns in Theory

47/216

Memory Models

One modelItems

(Visuo-spatial scratchpad)Articulatory

Loop

CentralExecutive

Long-termMemory

EpisodicMemory

ProceduralMemory

SemanticMemory

ObjectsRepresentations

CategoriesRepresentations

Page 48: Software Design Patterns in Theory

48/216

Memory Models

One model

EpisodicMemory

ProceduralMemory

SemanticMemory

ObjectsRepresentations

CategoriesRepresentations

Page 49: Software Design Patterns in Theory

49/216

Memory Models

Another model

Page 50: Software Design Patterns in Theory

50/216

Memory Models

Yet another model

Page 51: Software Design Patterns in Theory

51/216

Memory Models

Yet another model

Page 52: Software Design Patterns in Theory

52/216

Memory Models

Yet, yet another model

Page 53: Software Design Patterns in Theory

53/216

Memory Models

Miller, 1956

Page 54: Software Design Patterns in Theory

54/216

Memory Models

Miller, 1956

M R B X Q V L W Q K

Page 55: Software Design Patterns in Theory

55/216

Memory Models

Miller, 1956

?

Page 56: Software Design Patterns in Theory

56/216

Memory Models

Miller, 1956

?

Page 57: Software Design Patterns in Theory

57/216

Memory Models

Miller, 1956

The Magical Number Seven, Plus or Minus Two:Some Limits on Our Capacity for Processing Information

?

Page 58: Software Design Patterns in Theory

58/216

Memory Models

Brooks, 1978

Page 59: Software Design Patterns in Theory

59/216

Memory Models

Brooks, 1978– Problem domain

Page 60: Software Design Patterns in Theory

60/216

Memory Models

Brooks, 1978– Problem domain– Executing program

Page 61: Software Design Patterns in Theory

61/216

Memory Models

Brooks, 1978– Problem domain– Executing program

– Knowledge domains• Hypothesis-and-verify process• Importance of documentation

Page 62: Software Design Patterns in Theory

62/216

Memory Models

Brooks, 1978– Problem domain– Executing program

– Knowledge domains• Hypothesis-and-verify process• Importance of documentation

Page 63: Software Design Patterns in Theory

63/216

Memory Models

Soloway, 1983– Experts’ knowledge that novices do not have

• Programming plans– RUNNING TOTAL LOOP PLAN– ITEM SEARCH LOOP PLAN– …

• Rules of programming discourse– An IF should be used when a statement body is guaranteed

to be executed only once and a WHILE used when a statement body may need to be repeatedly executed

– …

Page 64: Software Design Patterns in Theory

64/216

Memory Models

Soloway, 1983

Page 65: Software Design Patterns in Theory

65/216

Memory Models

Soloway, 1983An IF should be used when a statement body is guaranteed to be executed only once and a WHILE used when a statement body may need to be repeatedly executed

Page 66: Software Design Patterns in Theory

66/216

Memory Models

Soloway, 1983An IF should be used when a statement body is guaranteed to be executed only once and a WHILE used when a statement body may need to be repeatedly executed

Page 67: Software Design Patterns in Theory

67/216

Memory Models

Soloway, 1983An IF should be used when a statement body is guaranteed to be executed only once and a WHILE used when a statement body may need to be repeatedly executed

Page 68: Software Design Patterns in Theory

68/216

Memory Models

Soloway, 1983An IF should be used when a statement body is guaranteed to be executed only once and a WHILE used when a statement body may need to be repeatedly executed

Page 69: Software Design Patterns in Theory

69/216

Memory Models

Pennington, 1987– Multiple abstractions for computer programs

(COBOL but may be true for other languages)• Abstraction of function• Abstraction of data-flow• Abstraction of control-flow• Abstraction of conditionalised actions

Page 70: Software Design Patterns in Theory

70/216

Memory Models

Pennington, 1987

Page 71: Software Design Patterns in Theory

71/216

Abstraction of function

Page 72: Software Design Patterns in Theory

72/216

Abstraction of data-flow

Page 73: Software Design Patterns in Theory

73/216

Abstraction of control-flow

Page 74: Software Design Patterns in Theory

74/216

Abstraction of conditionalised actions

Page 75: Software Design Patterns in Theory

75/216

Page 76: Software Design Patterns in Theory

76/216

Memory Models

Pennington, 1987– Programming knowledge

• Text structure knowledge– Sequences– Iterations– Conditionals

• Plan knowledgePlans are intermediate-level programming concepts

– Summing– Hashing– Counting– …

Page 77: Software Design Patterns in Theory

77/216

Memory Models

Pennington, 1987– Which knowledge and what abstraction?

Page 78: Software Design Patterns in Theory

78/216

Memory Models

Pennington, 1987– Which knowledge and what abstraction?

Text structure

Page 79: Software Design Patterns in Theory

79/216

Abstraction of control-flow

Page 80: Software Design Patterns in Theory

80/216

Memory Models

Van Mayrhauser, 1995– From previous works by

• Pennington• Soloway et al.• Rist• Van Mayhauser and Vans• Letovsky• Brooks• Schneiderman and Mayer

Page 81: Software Design Patterns in Theory

81/216

Memory Models

Van Mayrhauser, 1995

Page 82: Software Design Patterns in Theory

82/216

Memory Models

Van Mayrhauser, 1995

Integrated model

Page 83: Software Design Patterns in Theory

83/216

Page 84: Software Design Patterns in Theory

84/216

Page 85: Software Design Patterns in Theory

85/216

Page 86: Software Design Patterns in Theory

86/216

Page 87: Software Design Patterns in Theory

87/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 88: Software Design Patterns in Theory

88/216

Mental Models

“The image of the world around us, which we carry in our head, is just a model. Nobody in his head imagines all the world, government or country. He has only selected concepts, and relationships between them, and uses those to represent the real system.”

—Jay Wright Forrester, 1971

Page 89: Software Design Patterns in Theory

89/216

Mental Models

Page 90: Software Design Patterns in Theory

90/216

Mental Models

Mental models

Page 91: Software Design Patterns in Theory

91/216

Mental Models

Mental models Formal rules of inference

Page 92: Software Design Patterns in Theory

92/216

Mental Models

Mental models Formal rules of inference Domain-specific rules of inference

Page 93: Software Design Patterns in Theory

93/216

Mental Models

Mental models Formal rules of inference Domain-specific rules of inference Probabilities

Page 94: Software Design Patterns in Theory

94/216

Mental Models

Mental models Formal rules of inference Domain-specific rules of inference Probabilities…

Page 95: Software Design Patterns in Theory

95/216

Mental Models

Page 96: Software Design Patterns in Theory

96/216

Memory Models

Page 97: Software Design Patterns in Theory

97/216

Mental Models

Page 98: Software Design Patterns in Theory

98/216

Mental Models

Context matters!

Page 99: Software Design Patterns in Theory

99/216

Mental Models

Context matters!

Page 100: Software Design Patterns in Theory

100/216

Mental Models

Context matters!

Page 101: Software Design Patterns in Theory

101/216

Mental Models

Context matters!

Page 102: Software Design Patterns in Theory

102/216

Mental Models

Context matters!

Page 103: Software Design Patterns in Theory

103/216

Mental Models

Minsky, 1974– Frames

• “data-structure for representing a stereotyped situation”• “network of nodes and relations” and “slots”

– Frame-systems• Important actions are transformations between the

frames of a system • Different frames of a system share the same terminals

(and slots)– Matching process

Page 104: Software Design Patterns in Theory

104/216

Mental Models

Minsky, 1974– Vision– Speech– Knowledge– Control

Page 105: Software Design Patterns in Theory

105/216

Mental Models

Minsky, 1974– Vision– Speech– Knowledge– Control

Page 106: Software Design Patterns in Theory

106/216

Mental Models

Minsky, 1974– Vision

• A frame, once evoked on the basis of partial evidence or expectation, would first direct a test to confirm its own appropriateness

• It would request information needed to assign values to those terminals that cannot retain their default assignments

• If informed about a transformation (e.g., an impending motion), it would transfer control to the appropriate other frame of that system

Page 107: Software Design Patterns in Theory

107/216

Mental Models

Minsky, 1974– Vision– Speech– Knowledge– Control

Page 108: Software Design Patterns in Theory

108/216

Mental Models

Minsky, 1974– Knowledge

• Similarity networks

Page 109: Software Design Patterns in Theory

109/216

Mental Models

Minsky, 1974– Knowledge

• Similarity networks

Page 110: Software Design Patterns in Theory

110/216

Mental Models

Minsky, 1974– Vision– Speech– Knowledge– Control

Page 111: Software Design Patterns in Theory

111/216

Mental Models

Minsky, 1974– Control

• TOP-DOWN or LATERAL: Should one make a pass over all the terminals first or should one attempt a complete, detailed instantiation of some supposedly most critical one?

• CENTRAL CONTROL: Should a frame, once activated, "take over" and control its instantiation, or should a central process organize the operation

Page 112: Software Design Patterns in Theory

112/216

Mental Models

Soloway, 1986– In the context of analyzing problems and

constructing programs– Goals

• Requirements• Bugs

– Plans• “Canned” solutions• With “meaning”

Page 113: Software Design Patterns in Theory

113/216

Mental Models

Soloway, 1986“Master and novice chess players were shown a meaningful chess board, and asked to recall the pieces […]. The masters recalled more of the pieces than did the novices. Next, the masters and novices were shown a board in which the chess pieces were placed randomly on the board. […] The performance of the masters was the same as that of the novices.”

—Chase and Simon, 1973

Page 114: Software Design Patterns in Theory

114/216

Mental Models

Soloway, 1986– Micro-strategies

• Ask questions• Seek answers• RepeatDifficult with delocalised plans

– Macro-strategies• Systematic (scalability?)• As-needed (correctness?)

Page 115: Software Design Patterns in Theory

115/216

Mental Models

Rich and Waters, 1990(IBM’s Harlan Mills idea of “chief programmer teams”)

“[T]o provide software engineers with intelligent assistance.” (p. 2)

“The intended interaction between a software engineer […] is modeled after interaction with a human assistant.” (p. 2)

Page 116: Software Design Patterns in Theory

116/216

Mental Models

Rich and Waters, 1990

“Between the engineer and the Apprentice […], the key to effective cooperation is shared knowledge.” (p. 4)

– Shared knowledge• About the system being worked on• About concepts of software engineering

Clichés

Page 117: Software Design Patterns in Theory

117/216

Mental Models

Rich and Waters, 1990“[An algorithmic] cliché contains both fixed parts and parts that vary from one occurrence of the cliché to the next […], [it] may also include constraints […].” (p. 12)

“Non-algorithmic clichés are represented […] using standard frame-based knowledge representation techniques […].” (p. 21)

Page 118: Software Design Patterns in Theory

118/216

Mental Models

Rich and Waters, 1990– Key properties of algorithmic clichés

• Canonical form• Language independence• Convenient manipulation• Expressiveness

– A representation of clichés The Plan Calculus

Page 119: Software Design Patterns in Theory

119/216

Mental Models

Rich and Waters, 1990“The Plan Calculus is intended to be a blueprint language for software.” (p. 29)

• Formal representation for– Programs– Algorithmic clichés

Subroutines Program generators

MacrosFlowcharts Program schemas

Flowchart schemas Logic

Program transformation Data abstractionFormal grammars

Plan calculus

Page 120: Software Design Patterns in Theory

120/216

Mental Models

Rich and Waters, 1990

if:negative

T F

then:negate

end:join

T F

Page 121: Software Design Patterns in Theory

121/216

Mental Models

Rich and Waters, 1990

if:negative

T F

then:negate

end:join

T F

absolute-value

Page 122: Software Design Patterns in Theory

122/216

Mental Models

Rich and Waters, 1990

next:apply-function

next:

input:

input:continue:

generation

generation

generate

output:*

Page 123: Software Design Patterns in Theory

123/216

(On Gaming…)

Visual system Memory models Mental models

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 124: Software Design Patterns in Theory

124/216

(On Gaming…)

Visual system Memory models Mental models

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 125: Software Design Patterns in Theory

125/216

(On Gaming…)

Visual system Memory models Mental models

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 126: Software Design Patterns in Theory

126/216

(On Gaming…)

Visual system Memory models Mental models

“[G]amers [were] better at picking out details in a cluttered scene”

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 127: Software Design Patterns in Theory

127/216

(On Gaming…)

Visual system Memory models Mental models

“[G]amers [were] better at picking out details in a cluttered scene”“[G]amers were able to produce accurate estimates [of relative counts]”

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 128: Software Design Patterns in Theory

128/216

(On Gaming…)

Visual system Memory models Mental models

“[G]amers [were] better at picking out details in a cluttered scene”“[G]amers were able to produce accurate estimates [of relative counts]”“Gamers found it easier to perform mental rotations of geometric shapes”

http://arstechnica.com/science/2014/02/how-action-games-can-improve-our-visual-skills/

Page 129: Software Design Patterns in Theory

129/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 130: Software Design Patterns in Theory

130/216

Schema Theory

“The captain asked the passengers to fasten the seat belts. They were ready to take off.”

—Kohls and Scheiter, 2008

Page 131: Software Design Patterns in Theory

131/216

Schema Theory

Page 132: Software Design Patterns in Theory

132/216

Schema Theory

“This comprehensive situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”

—Kohls and Scheiter, 2008

Page 133: Software Design Patterns in Theory

133/216

Schema Theory

“This comprehensive situation is an interrelation of events and entities, and is stored in an internal data structure that can be activated by recognizing its typical features. Such data structures, or schemas, are mental representations in an individual’s mind.”

—Kohls and Scheiter, 2008

Page 134: Software Design Patterns in Theory

134/216

Schema Theory

“Human brains operate fundamentally in terms of pattern recognition rather than of logic. They are highly constructive in settling on given schema and at the same time are constantly open to error.”

—Edelman, 2006(With minor adaptation)

Page 135: Software Design Patterns in Theory

135/216

Schema Theory

Piaget, 1969– Child development theory– Schema and associated processes

Page 136: Software Design Patterns in Theory

136/216

Schema Theory

Piaget, 1969– Child development theory– Schema and associated processes

Page 137: Software Design Patterns in Theory

137/216

Schema Theory

Piaget, 1969– Schema and associated processes

• From Plato and Aristotle: essential commonalities, basic properties that are distinctive of an object

To Kant: link from stimuli to “pure” concepts– Perceived chair vs. “ideal” chair– No a-priori knowledge

• Gick and Holyoak: learning by examples and problem solving (like in mathematics)

Page 138: Software Design Patterns in Theory

138/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Abstract representation of multiple instances of the same kinds of

– Concept– Situation– Plan– Behaviour– …

to recognise similar / discriminate dissimilar experiences, access common concepts, draw inferences, create goals, develop plans, use skills

Page 139: Software Design Patterns in Theory

139/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Variables (or slots or attributes)

• (Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory

• Constraints among variables and their values

Page 140: Software Design Patterns in Theory

140/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Variables (or slots or attributes)

• (Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory

• Constraints among variables and their values

Page 141: Software Design Patterns in Theory

141/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Variables (or slots or attributes)

• (Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory

• Constraints among variables and their values

Page 142: Software Design Patterns in Theory

142/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Variables (or slots or attributes)

• (Constrained) Ranges of values– People’s experience– Constants – Optional or mandatory

• Constraints among variables and their values

Page 143: Software Design Patterns in Theory

143/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Prototypical object

• Object space and (mental) object generator

Page 144: Software Design Patterns in Theory

144/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Prototypical object

• Object space and (mental) object generator

Page 145: Software Design Patterns in Theory

145/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Prototypical object

• Object space and (mental) object generator

Page 146: Software Design Patterns in Theory

146/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Prototypical object

• Object space and (mental) object generator

Page 147: Software Design Patterns in Theory

147/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Prototypical object

• Object space and (mental) object generator

Page 148: Software Design Patterns in Theory

148/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Part-of

• Coupling

• Is-a

Page 149: Software Design Patterns in Theory

149/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Part-of

• Coupling

• Is-a

Page 150: Software Design Patterns in Theory

150/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Part-of

• Coupling

• Is-a

Page 151: Software Design Patterns in Theory

151/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Part-of

• Coupling

• Is-a

Page 152: Software Design Patterns in Theory

152/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Hierarchy– Contexts– Forces– Probabilities

Page 153: Software Design Patterns in Theory

153/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Hierarchy– Contexts– Forces– Probabilities

Page 154: Software Design Patterns in Theory

154/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Hierarchy– Contexts– Forces– Probabilities

Page 155: Software Design Patterns in Theory

155/216

Schema Theory

Piaget, 1969– Schema and associated processes

• Use

Page 156: Software Design Patterns in Theory

156/216

Page 157: Software Design Patterns in Theory

157/216

(Schema Theory Programming)

Papert worked with Piaget from 1958 to 1963 and afterwards– Constructionism

• Learning as a reconstruction rather than as a transmission of knowledge

• Learning is most effective when part of learner’s activity to build a meaningful product

http://www.lispcast.com/programming-language-stages-of-development

Page 158: Software Design Patterns in Theory

158/216

(Schema Theory Programming)

Papert developed the Logo programming language within the constructionism theory circa. 1967

Page 159: Software Design Patterns in Theory

159/216

(Schema Theory Programming)

Explanations of Logo programming using a simplified cognitive development modelCorporal Visual Symbolic

– The child learns to see her own perspective from the outside in the turtle

– The child sees the results of her commands immediately (cf. chick sexing)

– The child could think of the result of her commands before their execution

Page 160: Software Design Patterns in Theory

160/216

(Schema Theory Programming)

Explanations of object-oriented program-ming using the same simplified modelCorporal Visual Symbolic

– The ability to program from the perspective of a single object at a time

– The ability to think in terms of visual, archetypal interactions (client-server, MVC, etc.)

– The ability to build abstractions with simple yet powerful rules and meta-programming

Page 161: Software Design Patterns in Theory

161/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

Page 162: Software Design Patterns in Theory

162/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

Page 163: Software Design Patterns in Theory

163/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 164: Software Design Patterns in Theory

164/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 165: Software Design Patterns in Theory

165/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 166: Software Design Patterns in Theory

166/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 167: Software Design Patterns in Theory

167/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 168: Software Design Patterns in Theory

168/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Comprehension: pattern matching of memorised schema that cooperates and competes

• Animal face• human face• Bob’s face

Page 169: Software Design Patterns in Theory

169/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Accretion: specific situation or experience stored in schemas used to reconstruct original experience

– Episodic memory– Specific details

Page 170: Software Design Patterns in Theory

170/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Accretion: specific situation or experience stored in schemas used to reconstruct original experience

– Episodic memory– Specific details

곰세마리가한집에있어아빠곰엄마곰애기곰아빠곰은뚱뚱해엄마곰은날씬해애기곰은너무귀여워

Page 171: Software Design Patterns in Theory

171/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Accretion: specific situation or experience stored in schemas used to reconstruct original experience

– Episodic memory– Specific details

Why/How is specific information forgotten/replaced by generalised knowledge?

곰세마리가한집에있어아빠곰엄마곰애기곰아빠곰은뚱뚱해엄마곰은날씬해애기곰은너무귀여워

Page 172: Software Design Patterns in Theory

172/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Tuning: modifications to existing schemas– Variables– Ranges– Probabilities

Page 173: Software Design Patterns in Theory

173/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Tuning: modifications to existing schemas– Variables– Ranges– Probabilities

Page 174: Software Design Patterns in Theory

174/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Restructuring: ex nihilo / copy of existing schemas– Schema generation by analogies with existing schema, is-a– Schema induction from existing schema, has-a

Page 175: Software Design Patterns in Theory

175/216

Schema Theory

Rumelhart and Norman, 1978– Models of learning

• Restructuring: ex nihilo / copy of existing schemas– Schema generation by analogies with existing schema, is-a– Schema induction from existing schema, has-a

Page 176: Software Design Patterns in Theory

176/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 177: Software Design Patterns in Theory

177/216

Software Patterns

Schemas– Variables

– Ranges of values• Forces

– Constraints among variables and their values

Page 178: Software Design Patterns in Theory

178/216

Software Patterns

Schemas– Variables

– Ranges of values• Forces

– Constraints among variables and their values

What class plays this role?

Page 179: Software Design Patterns in Theory

179/216

Software Patterns

Schemas– Variables

– Ranges of values• Forces

– Constraints among variables and their values

Possible classes playing this roleplus their relations, implementation…

Page 180: Software Design Patterns in Theory

180/216

Software Patterns

Schemas– Variables

– Ranges of values• Forces

– Constraints among variables and their values

Expected relations, interactions…

Page 181: Software Design Patterns in Theory

181/216

Software Patterns

Schema theory

“The pattern is an attempt to discover some invariant features, which distinguishes good places from bad places with respect to some particular system of forces.”

—Christopher Alexander, 1979

Page 182: Software Design Patterns in Theory

182/216

Software Patterns

Knowledge and–or procedure

“The solution part of a good pattern describes both a process and a thing: the ‘thing’ is created by the ‘process’.”

—Christopher Alexander, 1979

“Furthermore, a pattern tells about a form not only what it is but also what it does.”

—Christopher Alexander, 1964

Page 183: Software Design Patterns in Theory

183/216

Software Patterns

Space and generation

“A pattern describes a coherent yet infinite design space, not a finite set of implementations in that space.”

—Frank Buschmann, Kevlin Henney, and Douglas C. Schmidt, 2007

Page 184: Software Design Patterns in Theory

184/216

Software Patterns

Use design patterns– Composite– Decorator– Observer– …

to generate the architecture of the program

Page 185: Software Design Patterns in Theory

185/216

Software Patterns

Wholeness– Quality Without a Name

• Forces

“Having an ideal concept of a thing lets one judge the beauty of it”

—Kohls and Scheiter, 2008

Page 186: Software Design Patterns in Theory

186/216

Software Patterns

Page 187: Software Design Patterns in Theory

187/216

Software Patterns

“Important assumptions– That patterns can be codified in such a way that

they can be shared between different designers– That reuse will lead to “better” designs. There is

an obvious question here of what constitutes “better”, but a key measure is maintainability”

—Zhang and Budgen, 2012 (With minor adaptations)

Page 188: Software Design Patterns in Theory

188/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 189: Software Design Patterns in Theory

189/216

Empirical Studies

“Eye movements are uniquely poised between perception and cognition. They are central to the function of the visual system, but for such scanning to be efficient, it cannot be simply a random sample of the visual world. To be useful, eye movements must be related to an organism’s memories, expectations and goals. Consequently, eye movements are driven equally by bottom-up perceptual properties of the world and top-down cognitive processes.”

—Richardson, Dale, and Spivey, 2013

Page 190: Software Design Patterns in Theory

190/216

Empirical Studies

“Eye movements are uniquely poised between perception and cognition. They are central to the function of the visual system, but for such scanning to be efficient, it cannot be simply a random sample of the visual world. To be useful, eye movements must be related to an organism’s memories, expectations and goals. Consequently, eye movements are driven equally by bottom-up perceptual properties of the world and top-down cognitive processes.”

—Richardson, Dale, and Spivey, 2013

Page 191: Software Design Patterns in Theory

191/216

Empirical Studies

“Eye movements are uniquely poised between perception and cognition. They are central to the function of the visual system, but for such scanning to be efficient, it cannot be simply a randomsample of the visual world. To be useful, eye movements must be related to an organism’s memories, expectations and goals. Consequently, eye movements are driven equally by bottom-up perceptual properties of the world and top-down cognitive processes.”

—Richardson, Dale, and Spivey, 2013

Page 192: Software Design Patterns in Theory

192/216

Empirical Studies

“Eye movements are uniquely poised between perception and cognition. They are central to the function of the visual system, but for such scanning to be efficient, it cannot be simply a randomsample of the visual world. To be useful, eye movements must be related to an organism’s memories, expectations and goals. Consequent, eye movements are driven equally by bottom-up perceptual properties of the world and top-down cognitive processes.”

—Richardson, Dale, and Spivey, 2013

Page 193: Software Design Patterns in Theory

193/216

Empirical Studies

“Eye movements are uniquely poised between perception and cognition. They are central to the function of the visual system, but for such scanning to be efficient, it cannot be simply a randomsample of the visual world. To be useful, eye movements must be related to an organism’s memories, expectations and goals. Consequent, eye movements are driven equally by bottom-upperceptual properties of the world and top-downcognitive processes.”

—Richardson, Dale, and Spivey, 2013

Page 194: Software Design Patterns in Theory

194/216

Page 195: Software Design Patterns in Theory

195/216http://web-tan.forum.impressrd.jp/e/2009/04/02/5280

Page 196: Software Design Patterns in Theory

196/216http://another-voice.jp/jp/katsu/professional_view/01/index.shtml

Page 197: Software Design Patterns in Theory

197/216http://another-voice.jp/jp/katsu/professional_view/01/index.shtml

Page 198: Software Design Patterns in Theory

198/216

Empirical Studies

Data– Fixations– Saccades– Scan path

Analyses– Centres of interests– Effort– Duration– …

Page 199: Software Design Patterns in Theory

199/216

Empirical Studies

Page 200: Software Design Patterns in Theory

200/216

Page 201: Software Design Patterns in Theory

201/216

Page 202: Software Design Patterns in Theory

202/216

Empirical Studies

SR Research Eye-link II– www.sr-research.com– Intrusive– Two infra-red cameras and one sensor– Error rate < 0.5º– Sampling rate of 500Hz– Access eye position < 3.0 ms.– 0.01º RMS resolution (tilt)

EyeLink Data Viewer

Page 203: Software Design Patterns in Theory

203/216

Page 204: Software Design Patterns in Theory

204/216

Page 205: Software Design Patterns in Theory

205/216

Empirical Studies

Tobii 1750 eye-tracker – www.tobii.se– Non-intrusive (no head mount)– Two cameras built into a 17 in flat screen– Records audio and video of a session– Error rate < 0.5º– Sampling rate of 50Hz

ClearView software

Page 206: Software Design Patterns in Theory

206/216

Page 207: Software Design Patterns in Theory

207/216

Page 208: Software Design Patterns in Theory

208/216

Empirical Studies

Seeing Machines FaceLab 5– www.seeingmachines.com– Non-intrusive– Two infra-red cameras– Error rate < 1º– Sampling rate of 60Hz– Complete head-tracking ±90º (y), ±45º (x) – Complete eye-tracking ±45º (y), ±22º (x)

GazeTracker

Page 209: Software Design Patterns in Theory

209/216

Outline

Visual systemMemory modelsMental models Schema theory Software patterns Empirical studies Conclusion

Page 210: Software Design Patterns in Theory

210/216

Conclusion

“That practices can be codified in such a way that they can be shared between different designers”

—Zhang and Budgen, 2012

What format? How memorised? How acquired?

Page 211: Software Design Patterns in Theory

211/216

Conclusion

“That practices can be codified in such a way that they can be shared between different designers”

—Zhang and Budgen, 2012

What format? Schema theory How memorised? How acquired?

Page 212: Software Design Patterns in Theory

212/216

Conclusion

“That practices can be codified in such a way that they can be shared between different designers”

—Zhang and Budgen, 2012

What format? Schema theory How memorised? Long-term memory How acquired?

Page 213: Software Design Patterns in Theory

213/216

Conclusion

“That practices can be codified in such a way that they can be shared between different designers”

—Zhang and Budgen, 2012

What format? Schema theory How memorised? Long-term memory How acquired? Gestalt theory

Page 214: Software Design Patterns in Theory

214/216

Conclusion

Software patterns– Schema theory– Knowledge and–or procedure– Space and generation– Wholeness

Page 215: Software Design Patterns in Theory

215/216

Conclusion

Empirical studies– Patterns use and usefulness

• Faults• Changes• Comprehension• …

– Many opportunities to understand program comprehension better!

Page 216: Software Design Patterns in Theory

216/216

Conclusion

Empirical studies– Patterns use and usefulness

• Faults• Changes• Comprehension• …

– Many opportunities to understand program comprehension better!