is this a pattern by tiffany winn paul calder flinders university of south australia
DESCRIPTION
Software Design Patterns Identifying pattern Developers must recognize reoccurring problems Developers then create a solutions for those problemsTRANSCRIPT
Is This a Pattern
byTiffany WinnPaul Calder
Flinders University of South Australia
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.
Software Design Patterns Identifying pattern
Developers must recognize reoccurring problems
Developers then create a solutions for those problems
Buzz Word Recently the word “pattern” has
become a buzz word
The implicit definition of the pattern concept has become less precise
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
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
1. A pattern implies an artifact Big picture level: How the software
works
Design level: The relationships the software attempts to capture
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
Questions ???