We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJavier Cubberley
Modified about 1 year ago
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 1 S E 2 Patterns Frank Buschmann Siemens AG, Corporate Technology Dept. Software & Engineering Frank.Buschmann@mchp.siemens.de
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 2 S E 2 Software Architecture Many Concepts Support Software Architecture Processes, such as the Unified Software Development Process; Notations, such as UML; Technologies, such as frameworks and distributed object computing; Enabling Techniques like separation of concerns; and Programming paradigms, such as object technology. Each approach addresses a specific aspect in the process of constructing high-quality software architectures.
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 3 S E 2 Technologies and Systems However...... all these concepts do not tell you how to solve a very specific problem that arises during the construction of a particular software system. For example, how to keep two cooperating components consistent to each other, or how to organize the event handling in a distributed system? Solving such problems is still left to your own intuition and experience in software construction.
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 4 S E 2 Experts Know Solutions That Work Experts Do Not Construct Solutions When experts work on a particular problem it is unusual for them to tackle it by inventing a new solution that is completely distinct from existing ones. Experts know, from their own and others experience, a large body of proven solutions to many design problems. Confronted with a ‘new’ problem they often remember a similar one they once solved successfully and adapt the ‘old’ solution to the new context. Experts think in Problem/Solution pairs! Proxy DBMS ProxyBroker Bridge Proxy * ** 0..1 ViewController Client Communication Infrastructure User Interface Functional Core Model Persistence 1 11 1 11 Gotcha!
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 5 S E 2 Let’s take a look at a well-known pattern
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 6 S E 2 Observer (1) Observer (GoF) Problem Changing the internal state of a component may cause inconsistencies to the state of other components. How can we restore consistency effectively in a way that: the information provider must not depend on information consumers; and the information consumers that depend on the information provider must not be known a priori. House1 Door_A; Window_1a Window_1b... is presented as depends on
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 7 S E 2 Observer (2) Solution-Structure Implement a change propagation mechanism between the information provider, the subject, and the information consumers, the observers. The Subject maintains a registry of observers and notifies all registered observers about changes to its state. An Observer declares an update function to be called by the subject’s change propagation mechanism. Concrete Observers implement the update function in an observer-specific manner. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); *
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 8 S E 2 Observer (3) Solution-Dynamics The Observers register with the subject’s change propagation mechanism. A Client modifies the subject’s data. The Subject starts its change propagation mechanism. The Subject calls the update function of every registered observer. The Observers retrieve the changed data from the subject and update themselves. SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 9 S E 2 Observer (4) Benefits Defined handling of dependencies between otherwise strongly coupled components Support for dynamic configuration of a subject with observers Adding new observers does not affect the subject or the change propagation mechanism Liabilities Indirection Unnecessary updates Update cascades
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 10 S E 2 Let’s Reflect
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 11 S E 2 Properties A Pattern presents a concrete solution schema for recurring design problems; documents proven design experience; specifies concepts above the level of individual classes and objects; describes structure and behavior of cooperating objects; provides a common vocabulary and concept understanding; and addresses specific quality properties of the problem’s solution. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); * SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData Observer House1 Door_A; Window_1a Window_1b... is presented as depends on Problem Solution
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 12 S E 2 Process and Thing Pattern are both: A Process and A Thing every pattern tells you what to do, in terms of the structure to create and the behavior that performs in this structure; and it tells you how to do it, by providing a process that helps creating the structure. Subject attach detach notify setData getData s->getData() Observer update ConcreteObserver update doSomething state = X; notify(); state observerList for all observers in observerList do notify(); * SubjectObserver 1Observer 2 attach(this) setData notify update getData update getData Observer The Process The “Thing” 1. Identify the Subject 2. Identify the Observers 3. Add registration functionality to the Subject 4. Add Observer repository to the Subject 5. Add update functionality to the Observers 6. Implement the Subject’s Change Propagation Mechanism
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 13 S E 2 Forces Forces: The Heart of Every Pattern complete the general problem; describe requirements, constraints, and desired properties to the solution; influence the concrete solution; tell you why the problem is a hard problem; tell you why the solution is as is and not something different. Observer Force 1: The information provider must not depend on information consumers. Solution: All Observers share the update() interface. Force 2: The information consumers that depend on the information provider must not be known a priori. Solution: Subject provides registration and unregistration functionality; Change propagation mechanism only calls the “anonymous” update() function.
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 14 S E 2 Object-Technology Patterns are NOT Necessarily Object-Oriented Object technology simplifies the implementation of a pattern, but is not essential. Instead of using inheritance you may use C function pointers, for example, to implement the change propagation mechanism of Observer. Many other patterns, such as Layers, do not build on object technology at all. Subject attach detach notify setData getData Observer update doSomething state observerList *
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 15 S E 2 Genericity Patterns are Generic No two implementations of a pattern are likely to be the same. A pattern provides a generic solution schema. It is not carved in stone. A pattern is a mental design aid. You should be able to reuse the solution schema a million times over, each implementation being different, but all of them sharing the essential core. A pattern introduces roles, NOT classes! Subject attach detach notify setData getData Observer update ConcreteObserver update doSomething state observerList 2 Observer Design Options Subject notify setData getData Observer update ConcreteObserver update doSomething state Event Channel attach detach notify * observerList * 11
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 16 S E 2 Scale and Abstraction Pattern Categories Architectural patterns express fundamental structural organizations of systems into subsystems. Design patterns help with refining subsystems and components of a software system, or the relationships between them. Idioms are low-level patterns specific to a programming language. Analysis patterns describe how work is organized in a specific domain. Organizational patterns describe how software development should be organized. Leaky Bucket Counter (by James Coplien et al.) Problem: Distinction between transient and hard errors that may occur on a unit. Solution: Provide the unit to be observed with an error-counter, initialized with 0. Whenever an error occurs, increase the counter by 1. If the counter reaches a unit- specific threshold, issue an alarm. If no error occurs for a unit-specific period of time, decrease the counter by 1. threshold leak error Use in Siemens: Engine Control Switches: Fault Management
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 17 S E 2 Relationships Pattern Relationships Refinement. For example, Observer can be used to refine the relationship between the model and its views. Combination. For example, Proxy can be combined with Forwarder-Receiver on the same level of abstraction to provide the stub concept. Variation. For example, Event Channel is a variation of Observer. * Observer update Model (Subject) attachObs detachObs notify getData service observers coreData Controller init handleEvent update myModel myView View init makeController activate display update myModel myController 11
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 18 S E 2 Experiences
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 19 S E 2 Projects Project Experience @ Siemens Hot Rolling Mill Process Automation Medical Imaging Network Management Passenger Information Car Dealing Warehouse Management Object Request Brokers many more
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 20 S E 2 Observation (1) Using Patterns may lead to Frameworks For most projects the primary goals were extensibility and adaptability. Through careful ‘design for evolution and change’ we received software architectures that are stable in their core, yet being extensible with new structures, modifiable with respect to existing structures, and adaptable to customer- specific requirements. In other words, we ended with frameworks. DoorBin Composite Storage * Equipment Abstract Iterator Abstract Visitor * Abstract Strategy LoadInLayersLeafsOnlyOccupation SOC 1 1 Storage Manager * Telegram Office 1 Abstract Storage DBMS Storage Original Telegram Factory
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 21 S E 2 Observation (2) One Size Does Not Fit All Patterns alone are NOT sufficient enough for building systems that meet today’s tough requirements. DOC provides the communication infrastructure. Frameworks support building architectures for system families. Patterns help designing the frameworks. Components help configuring the frameworks to a customer-specific application. DoorBin Composite Storage * Equipment Abstract Iterator Abstract Visitor * Abstract Strategy LoadInLayersLeafsOnlyOccupation SOC 1 1 Storage Manager * Telegram Office 1 Abstract Storage DBMS Storage Original Telegram Factory
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 22 S E 2 Benefits Solutions to design problems are based on well-proven standard concepts. Consideration of alternatives are possible. Explicit consideration of non-functional aspects. Improved communication. Improved documentation. Knowledge is available to the whole organization.
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 23 S E 2 Problems Hype. Finding the right patterns is not always easy. Implementing a pattern correctly needs some experience. Using patterns does not necessarily result in a high-quality design. People often see patterns as blueprints.
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 24 S E 2 Lessons Learned Patterns help, but are no silver bullet. Patterns complement but do not replace existing technology and methods. Education is crucial for success. Don’t force developers in using the patterns. Apply patterns carefully. JUST DO IT!
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 25 S E 2 The End
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 26 S E 2 References (1) References C. Alexander: The Timeless Way of Building, Oxford University Press, 1979 M. Fowler: UML Distilled, Addison-Wesley, 1997 R.P. Gabriel: Patterns of Software, Oxford University Press, 1996 E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns – Elements of Reusable Object-Oriented Software, Addison- Wesley, 1995 Various Eds. : Pattern Languages of Program Design, Vol. 1- 3, Addison-Wesley, 1995, 1996, 1997 F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture—A System of Patterns, John Wiley and Sons, 1996
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 27 S E 2 References (2) References M. Fowler: Analysis Patterns, Addison-Wesley, 1997 K. Beck: Smalltalk Best Practice Patterns, Prentice Hall, 1997 J.O. Coplien: Advanced C++ Styles and Idioms Addison-Wesley, 1992 D. Lea: Concurrent Programming in Java, Design Principles and Patterns, Addison- Wesley, 1997 J. Vlissides: Pattern Hatching, Addison-Wesley, coming soon The Patterns Home Page http://www.hillside.net/patterns/
S © Siemens AG, 1998 Frank Buschmann ZT SE 2 Page 28 S E 2 Questions?
Csci 490 / Engr 596 Special Topics / Special Projects Software Design and Scala Programming Spring Semester 2010 Lecture Notes.
Engr 691 Special Topics in Engineering Science Software Architecture Spring Semester 2004 Lecture Notes.
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
PRESENTED BY SANGEETA MEHTA EECS810 UNIVERSITY OF KANSAS OCTOBER 2008 Design Patterns.
Design Patterns Trends and Case Study John Hurst June 2005.
Software Design Refinement Using Design Patterns Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
D ESIGN P ATTERNS Weslei A. de T. Marinho. T ALK O UTLINE Pattern Definition GRASP Patterns GoF Patterns GoF Patterns Classification Creational Patterns.
Design Principle & Patterns by A.Surasit Samaisut Copyrights : All Rights Reserved.
ECE 355 Design Patterns Tutorial Part 2 (based on slides by Ali Razavi) Presented by Igor Ivković
1 Good Object-Oriented Design Dr. Radu Marinescu Lecture 4 Introduction to Design Patterns.
Software Engineering I Object-Oriented Design Software Design Refinement Using Design Patterns Instructor: Dr. Hany H. Ammar Dept. of Computer Science.
Software Architecture and Patterns 1. Outline Introduction Software Architecture and Architectural Design Architectural Styles System Structuring Modular.
Ralph Johnson - University of Illinois1 Patterns: What They Are, and How to Write Them Ralph Johnson University of Illinois at Urbana-Champaign
CSC 480 Software Engineering Design With Patterns.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
Software Design Patterns (1) Introduction. patterns do … & do not … Patterns do... provide common vocabulary provide “shorthand” for effectively communicating.
ECE450S – Software Engineering II Lecture 7 OOD & Introduction to Design Patterns.
CS 5150 Software Engineering Lecture 16 Program Design 3.
Spring 2010CS 2251 Design Patterns. Spring 2010CS 2252 What is a Design Pattern? "a general reusable solution to a commonly occurring problem in software.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
© Siemens AG, CT SE, Prashant Jain, October 15, 2001 C O R P O R A T E T E C H N O L O G Y OOPSLA 2001 Workshop Software & Engineering Architecture 1 A.
Pertemuan 09 Architectural Patterns Mata kuliah: T0144 – Advanced Topics in Software Engineering Tahun: 2010.
CS590L - Lecture 6 1 CS590L Distributed Component Architecture References: - E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of.
Patterns Roberto Damiani Mendes. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP.
Copyright © Active Frameworks Inc. - All Rights Reserved - V2.0Design Pattern Catalog - Page L3-1 PS95&96-MEF-L10-1 Dr. M.E. Fayad Creationa.
Observer Pattern Fall 2005 OOPD John Anthony. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment,
Design Patterns Introduction What is a Design Pattern? Why were they developed? Why should we use them? How important are they?
Design Patterns Introduction. What is a Design Pattern? A technique to repeat designer success. Borrowed from Civil and Electrical Engineering domains.
Ch:8 Design Concepts S.W Design should have following quality attribute: –Functionality –Usability –Reliability –Performance –Supportability (extensibility,
101 User Interface Patterns and its applications Tonya Groover Department of Computer Science.
Creational Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
Design Patterns CSIS 3701: Advanced Object Oriented Programming.
Patterns in programming 1. What are patterns? “A design pattern is a general, reusable solution to a commonly occurring problem in software. A design.
Y2 eProjects Session 4 – Advanced Topics. Objectives Dynamic Models Design Patterns (Optional) Software testing (for S4) ACCP i7.1\Sem3_4\eProject\T4.
D ESIGN P ATTERNS Breno Batista Machado Weslei A. de T. Marinho.
Design Patterns 1. Design patterns are solutions to problems that arise when developing software within a particular context Patterns capture the structure.
Page 1 Building Reliable Component-based Systems Chapter 1 - Basic Concepts in Component-Based Software Engineering Chapter 1 Basic Concepts in Component-Based.
Patterns and AntiPatterns Ku-Yaw Chang Assistant Professor, Department of Computer Science and Information Engineering Da-Yeh University.
SS ZG653Second Semester Topic Architectural Patterns – Review of Patterns.
Chapter5 Pattern Systems Feng Zhiyong Tianjin University Apr 16, 2004.
Design Patterns CS is not simply about programming it is also about good design some designs are better than others – more efficient in space or time required.
1 CS590L Distributed Component Architecture Yugi Lee STB #555 (816) * This presentation is prepared based.
Powerpoint Templates Page 1 Powerpoint Templates What is Design Patterns ? by Indriati Teknik Informatika – UB.
DESIGN PATTERNS CSC532 Adv. Topics in Software Engineering Shirin A. Lakhani.
Understanding and using patterns in software development EEL 6883 Software Engineering Vol. 1 Chapter 4 pp Presenter: Sorosh Olamaei.
January 12, Introduction to Design Patterns Tim Burke References: –Gamma, Erich, et. al. (AKA, The Gang of Four). Design Patterns: Elements of Reusable.
Welcome to. Who am I? A better way to code Design Patterns ??? What are design patterns? How many are there? How do I use them? When do I use.
05 - Patterns Intro.CSC4071 Design Patterns Designing good and reusable OO software is hard. –Mix of specific + general –Impossible to get it right the.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 6: Using Design Patterns.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
© 2017 SlidePlayer.com Inc. All rights reserved.