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 software’s 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. 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 Linking abstraction levels

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 it’s 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 pattern’s 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 domain’s 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 ???