Pattern Myths1 Ten Design Pattern Myths Jim Fawcett condensed from Pattern Hatching, John Vlissides, Addison-Wesley, 1998.

Slides:



Advertisements
Similar presentations
Critical Thinking Course Introduction and Lesson 1
Advertisements

IS6112 Application Modelling and Design Introduction.
Design and Programming Patterns Associated with Java Networking by Margaret Toews cs843, Spring 2003.
Getting Started: Research and Literature Reviews An Introduction.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
Design Patterns Daniel McClain. Background What are they?  Way of recording solutions to recurring design problems History  “A Pattern Language: Towns,
Introduction to Design Patterns (1). “ In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software.
Ralph Johnson - University of Illinois1 Patterns: What They Are, and How to Write Them Ralph Johnson University of Illinois at Urbana-Champaign
OOHDM Hypermedia Research Work Designing Web-based applications with Object Oriented Hypermedia Design Method OOHDM.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Design Patterns.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
1 PH Chapter 1 (pp. 1-10) GoF Composite Pattern (pp ) PH Ch 2 through Fundamentals (pp ) Presentation by Julie Betlach 5/28/2009.
Educator’s Guide Using Instructables With Your Students.
Design Patterns Discussion of pages: xi-11 Sections: Preface, Forward, Chapter
Application of Pedagogic Patterns to the Design of Distance Learning Materials Steve Wade University of Huddersfield.
“Enhancing Reuse with Information Hiding” ITT Proceedings of the Workshop on Reusability in Programming, 1983 Reprinted in Software Reusability, Volume.
Describing Methodologies PART II Rapid Application Development* Systems Analysis and Design II.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
AELDP ACADEMIC READING. Questions Do you have any questions about academic reading?
Business Analysis and Essential Competencies
T. Dawson, TASC 9/11/13 Use of a Technical Reference in NASA IV&V.
Introduction to Design Patterns (1). Definition: “ In software engineering, a design pattern is a general reusable solution to a commonly occurring problem.
Introductory Software Engineering with a Focus on Dependency Management Christine Hofmeister.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Advanced topics in software engineering CSC532 Term Paper Design Patterns Harpreet Singh Submitted By:-
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
3rd Country Training, K.Subieta: System Engineering and Databases. Lecture 3, Slide 1 February 20, 2004 Lecture 3: Introduction to Software Analysis and.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 27. Review UML dynamic view – State Diagrams.
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
Planning and Integrating Curriculum: Unit 4, Key Topic 1http://facultyinitiative.wested.org/1.
Patterns and Reuse. Patterns Reuse of Analysis and Design.
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
1 Introduction to Software Engineering Lecture 1.
GRASP: Designing Objects with Responsibilities
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
DESIGN PATTERNS CSC532 Adv. Topics in Software Engineering Shirin A. Lakhani.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design.
Metadata with MMI Opening the Door to Collaboration John Graybeal, Luis Bermudez, Philip Bogden, Steven Miller, Stephanie Watson.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
Christoph F. Eick University of Houston Organization 1. What are Ontologies? 2. What are they good for? 3. Ontologies and.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
© 2010 Health Information Management: Concepts, Principles, and Practice Chapter 5: Data and Information Management.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
WEB 2.0 PATTERNS Carolina Marin. Content  Introduction  The Participation-Collaboration Pattern  The Collaborative Tagging Pattern.
Composite Pattern ( ) Pattern Hatching Chpt 1-2 Presentation by Joe Barzilai 1/30/2006.
Daphne Ogle, Fluid Design Lead, University of California, Berkeley Content Management Research.
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Design Pattern Catalog - Page L3-1 PS95&96-MEF-L10-1 Dr. M.E. Fayad Creationa.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Patterns in cs education Matthias Felleisen & Daniel Jackson NDIST · December 5, 2001.
1 Introduction to Design. 2 Outline Basics of design Design approaches.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
SAIP 19 - Software Architecture in the Future. The book says … ABC Revisited Architecture and Legacy Systems Achieving an Architecture From Architecture.
Software Design Derived from Dr. Fawcett’s slides CSE784 – Software Studio Fall 2009.
1 Architectural Blueprints—The “4+1” View Model of Software Architecture (
Sakai UI Design Patterns Design Patterns WG 12-Jun-2007, 14:05 Marc Brierley.
Modes of Meaning. First, some terms…  Text: in this class, we will use the term “text” to mean any object we study and analyze. While a text can be a.
1 Good Object-Oriented Design Dr. Radu Marinescu Lecture 4 Introduction to Design Patterns.
+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission.
Abstract  An abstract is a concise summary of a larger project (a thesis, research report, performance, service project, etc.) that concisely describes.
Design Patterns CSCE 315 – Programming Studio Spring 2013.
The Systems Engineering Context
Design Patterns.
Presentation transcript:

Pattern Myths1 Ten Design Pattern Myths Jim Fawcett condensed from Pattern Hatching, John Vlissides, Addison-Wesley, 1998

Pattern Myths2 Myth 1 - A Pattern is a Solution to a Problem in Some Context Yes, three essential parts of a pattern are Problem, Solution, and Context, but three other things are also required: Relevant Recurrence: This solution is relevant in other situations. Vehicle for Teaching: The solution conveys some principle or observation worth passing on to others. It is not immediately obvious, nor is it so complex that there is little value in passing on. It must have a Name:

Pattern Myths3 Myth 2 - Patterns are just rules, tricks, and data structures Patterns introduce few new terms A good pattern is inherently accessible to its audience. Patterns are not rules you can apply mindlessly nor are they limited to programming tricks Each pattern captures a useful principle or method that can be used “as-is” or bent and modified to suit your current design needs. Most, but not all, patterns focus on issues that are independent of a specific programming language. Structure may capture the essence of a pattern but: structure usually relates to module and/or class relationships the value of many patterns lies in their description of dynamic, not static, relationships. That is, collaborations are more important than structure.

Pattern Myths4 Myth 3 - Seen one, Seen them all Patterns come in a variety of application domains, content, scope, and styles. Patterns are used to capture: Design paradigms Object-Oriented Design techniques Programming strategies Domain specific techniques database, distributed processing, … Specific technology issues security, component models, … Architectures for user interfaces Management strategies

Pattern Myths5 Myth 4 - Patterns need tool or Methodology Support to be Effective The benefit from patterns comes mostly from applying them as they are - with no support of any kind. Patterns provide a way to pass on expertise from the seasoned expert to the entry level developer. Patterns also provide a means to save, catalog, review, and reason about technical issues and really bright ideas. The benefits of patterns are: they capture expertise and make it accessible their names form a vocabulary that makes communication precise they help people understand a system more quickly when it is documented with the patterns it uses they help to restructure a system by helping us to focus on the main issues

Pattern Myths6 Myth 5 - Patterns Guarantee Reusable Software, Higher Productivity Patterns don’t guarantee anything. They don’t even make benefit likely. Patterns do nothing to remove the human from the creative process. Patterns bring the hope of empowerment to the uninitiated but otherwise capable and creative person. Patterns are just another weapon in the developer’s arsenal.

Pattern Myths7 Myth 6 - Patterns Generate Whole Architectures Patterns themselves don’t generate anything. People do - and they do it well only if they and the patterns they use are effective. Patterns are often catalysts that set the path to a complete architecture. Use of patterns can establish a strong foundation on which to build. Patterns are unlikely to cover every aspect of an architecture. Any non-trivial design has lots of aspects that no pattern addresses. It’s up to you to fill in the spaces with your own creativity. The intent and especially motivation sections should deal with the “forces” at work in a design problem and the “resolutions” of those forces that the pattern provides. A clear view of the motivation behind a pattern helps you to bend it to the needs of your current application.

Pattern Myths8 Myth 7 - Patterns are only for Object-Oriented Design/Implementation “Patterns are nothing if they don’t capture expertise. The nature of that expertise is left open to the pattern writer.” Patterns are useful in: analysis Design functional, structured, declarative, object-oriented, … implementation and maintenance testing documentation organization and management

Pattern Myths9 Myth 8 - There’s no Evidence that Patterns Help Anybody “People are reporting benefits from patterns in journals [Software - Practice and Experience] and conferences [OOPSLA].” Pattern Languages of Program Design conference proceedings are filled with scores of papers describing benefits of applying and modifying existing patterns as well as reporting new pattern discoveries.

Pattern Myths10 Myth 9 - The Pattern Community is a Clique of Elites The four authors of the Design Patterns book are from university faculty, research lab, and industry. Most of the contributors to the PLOP conferences are working software developers in industry.

Pattern Myths11 Myth 10 - The Pattern Community is Self- Serving, even Conspiratorial “…, I can confirm that we [authors of Design Patterns] were as surprised as anyone by the reaction to Design Patterns … even the publisher was caught off-guard by the demand.” “… if you read the works of leading pattern authors carefully, you’ll sense a common and overarching desire: to take hard-earned expertise, best practices, even competitive advantage -- the fruits of years of hands-on experience -- and not just disclose it but impart it to all comers.”