Is This a Pattern

1
Is This a Pattern

• by
• Tiffany Winn
• Paul Calder
• Flinders University of South Australia

2
The Authors

• Tiffany Winn is a PhD student in computer science
  at Flinders University, where she received her
  BSc (Hons.) in computer science. Her research
  interests are in design patterns and programming
  paradigms.
• Paul Calder is a senior lecturer in the School of
  Informatics Engineering at Flinders University.
  His research interests include object-oriented
  software design, component-based software reuse,
  graphical interfaces, and data visualization. He
  is a member of the IEEE Computer Society, ACM
  SIGCHI, and ACM SIGPLAN. He earned his PhD in
  electrical engineering from Stanford University,
  where he was one of the developers of the
  InterViews user interface toolkit.

3
Software Design Patterns

• Identifying pattern
• Developers must recognize reoccurring problems
• Developers then create a solutions for those
  problems

4
Buzz Word

• Recently the word pattern has become a buzz
  word
• The implicit definition of the pattern concept
  has become less precise

5
Developer Skills

• Developers must increase
• Their understanding of patterns at a theoretical
  and practical level
• Their ability to distinguish patterns from
  similar seeming non-patterns

6
Essential Characteristics of Patterns

• These characteristics cannot provide a definite
  test for pattern-ness
• If an entity does not contain one of the
  characteristics then it is not a pattern

7
1. A pattern implies an artifact

• Big picture level How the software works
• Design level The relationships the software
  attempts to capture

8
Drawing the artifact

• The design pattern captures the overall structure
  in a physical or spatial sense
• If the software pattern cannot be drawn, it does
  not embody a physical understanding of a
  softwares artifact and therefore is not a pattern

9
2. A pattern bridges many levels of abstraction

• A pattern is not just a concrete designed
  artifact or abstract description
• A pattern facilitates the progression from a
  vague idea to the actual software
• Therefore a pattern bridges different abstraction
  levels

10
Linking abstraction levels

• Linking helps designers make connections between
  different levels
• Book Analogy
• Story paragraph sentence word
• Book ? Program
• Story Level ? General problem overview
• Paragraph Level ? Flowchart (control flow)
• Sentence Level ? Algorithms
• Word Level ? Sample Code
• Flowchart and Algorithms help link the general
  overview with the sample code

11
Linking abstraction levels

• Design aids, such as patterns, should bridge
  different design levels
• Designers understanding evolves as the solution
  develops
• It is important to develop aids that move from
  gradual initial understanding to a more in depth
  one
• The ability to link different levels of thinking
  about a design is critical to knowledge reuse

12
Knowledge Reuse

• Knowledge reuse is a key to good design
• The challenge in reusability is to express the
  fragmentary and abstract components out of which
  complete programs are built.
• Designers reuse knowledge by learning from their
  own and others experiences
• Recognize and abstract from useful similarities
  at any abstraction level from their own or
  others context
• C. Rich and R.C. Waters, The Programmers
  Apprentice. Addison-Wesley, Reading, Mass., 1990

13
3. A pattern is both functional and nonfunctional

• Functional issues deal with possibility
• Determine what decisions could be or were made in
  a particular context
• Nonfunctional issues deal with feasibility
• They address the reasons the decision was made
  and its desirability in a particular context

14
Balancing Act

• Design often involves balancing conflicting
  forces
• Sacrificing software readability for efficiency
• Good design requires more that understanding just
  the forces involved
• It also requires understanding the relationships
  between those forces

15
Design Complexity

• Software design is complex and subject to
  frequent change
• Complex design a developer will be unable to
  grasp the interplay between forces
• Designers must develop skills, methods, and tools
  that help clarify interplay

16
Functional and Nonfunctional

• A design pattern is functional because it
  documents a solution to a problem
• Provide fragment samples of code and diagrams of
  software structure
• A design patterns is nonfunctional because it
  discusses the feasibility of the solution
  documents
• Discussion of its applicability

17
4. A pattern is manifest in a solution

• The pattern will be present and recognizable in
  the solution
• Whether used consciously or unconsciously
• A pattern is not a simple tool it leaves a mark
  on the finished product
• Focuses both on design process and design
  structure

18
Design Approaches

• All design approaches strive for the creation of
  well-designed software
• Approaches that focus solely on design process or
  methodology do no leave any identifiable imprint
• Approaches, such as design patterns that focus on
  both design process and structure directly
  influence the visible structure of the product

19
5. A pattern captures system hot spots

• Software system must remain stable in a highly
  dynamic environment
• Building a stable system is not about foreseeing
  every modification
• Building a stable system is about understanding
  the domain well enough to build a system that can
  evolve appropriately

20
Invariant and Hot Spots

• Central to any pattern is an invariant that
  solves a reoccurring problem
• Patterns facilitate good design by capturing hot
  spots those parts of a solution likely to
  change as a development system evolves

21
Invariant and Hot Spots

• The pattern captures the invariant and hot spots
  and provides a structure to manage the
  interaction between these stable and changing
  system elements
• In the software domain, patterns isolate expected
  invariant system elements from the effects of
  change to system hot spots

22
6. A pattern is part of a language

• Every pattern is connected to and shaped by other
  patterns
• Patterns are part of a network of interrelated
  patterns a pattern language
• When patterns are combined they form a language
  for describing design solutions

23
Pattern quotes

• No pattern is an isolated entity. Each pattern
  can exist in the world, only to the extent that
  it is supported by other patterns the larger
  patterns in which it is embedded, the patterns of
  the same size that surround it, and the smaller
  patterns which are embedded in it.
• This is a fundamental view of the world. It says
  that when you build a thing you cannot merely
  build that thing in isolation, but must also
  repair the world around it, and within it, so
  that the larger world at that one place becomes
  more coherent, and more whole.
• C. Alexander, S. Ishikawa, and M. Silverstein,
  A Pattern Language, Oxford Univ. Press, New York,
  1977.

24
Pattern Languages

• Pattern languages are critical because they
  capture the emergent behavior of complex systems
• A pattern language is therefore a collective of
  solutions to reoccurring problems
• A good pattern language guides a designer towards
  a good system architecture
• The whole is more than that sum of the parts a
  pattern language is more than the sum of its
  patterns

25
7. A pattern is validated by use

• Patterns are usually discovered through concrete
  experience rather than abstract argument
• A pattern cannot be verified or validated from a
  purely theoretical framework

26
A pattern is validated by use

• In spoken language new words are devised and old
  words acquire new meanings through repeated use
• Words can also be theoretically devise, although
  not validated until it achieves widespread use
• Likewise, a patterns repeated presence in
  existing artifacts confirms it usefulness
• Programming theory is important but to be
  meaningful it must be evaluated in a concrete
  environment

27
A pattern is validated by use

• Patterns are validated by experience rather than
  by testing
• Validating pattern existence by experience is
  difficult because it is hard to know when a
  patterns is complete and correct

28
8. A pattern is grounded in a domain

• A pattern is not an isolated entity
• Patterns are defined in the context of other
  patterns and with respect to a particular field
  to which it applies

29
A pattern is grounded in a domain

• Discussion of a pattern only makes sense as part
  of a pattern language
• A discussion of patterns must clarify what domain
  the patterns serve and it must ensure that all
  the patterns share a common domain

30
9. A pattern captures a big idea

• Design patterns are not solutions to trivial
  problems
• Not every design problem warrants a pattern
• Patterns focus on difficult problems in a
  particular area
• Problems designers face in a certain area time
  and time again

31
A pattern captures a big idea

• Therefore, a pattern language captures a domain.
  
• The patterns in the language identify the
  domains key concepts and their interplay
• A pattern must strike a balance between a
  solution to a specific problem and if that
  problem is significant enough to warrant a pattern

32
Conclusion

• Developing a definition that completely captures
  the pattern concept is neither worthwhile nor
  possible
• What is possible and worthwhile is to document
  essential characteristics
• Clarifies and develops our understanding of
  patterns
• Therefore increasing our ability to identify them

33
Questions ???