Design Pattern and Software Architecture: VIII. Conclusion AG Softwaretechnik Raum E 3.165 Tele. 60-3321 hg@upb.de VIII. Conclusion VIII.1 Classifications VIII.2 Common Misconceptions VIII.3 Open Questions & Outlook VIII.4 Bibliography VIII-2
VIII.1 Classifications Different classifications: [Gamma+1994]: creational pattern (C), behavioural pattern (B), structural pattern (S) [Buschmann+1996]: architectural pattern, design pattern, idioms [Douglass+1999]: architectural pattern, mechanistic pattern Synthesised classification for all patterns <Name> (<Section>[/C /B /S ) (POSA1) In the lecture [Gamma+1994] [Buschmann+1996] VIII-3 Classification (1/3) Coordination & Structuring Interactive Systems Distributed Systems & Communication Adoption Architectural Patterns Hierarchical Layers (V.2) Pipe & Filters (V.2) Blackboard (V.2) ADT & OO (V.2) Event Systems (V.2) Process-Control (V.2) Interpreter (V.2/B) MVC (V.3) PAC (V.3) Broker (V.4) Real-Time Broker (VI.2.3) Micorkernel (V.5) Reflection (V.5) Design Patterns Interpreter (V.2/B) Observer (II.2/B) View Handler (POSA1) Observer (II.2/B) Observer (II.2/B) Real-Time Observer (VI.3.1) Transaction (VI.3.1) Remote Proxy (VI.2.3/S) Real-Time Proxy (VI.2.3) Adapter (IV.4/S) Idioms VIII-4
Classification (2/3) Architectural Patterns Design Patterns Idioms Resource Handling & Synchronization Static Allocation (VI.2.2) Fixed Size Allocation (VI.2.2) Priority Ceiling (VI.2.2) Flyweight (IV.4/S) Rendezvous (VI.3.2) Smart Pointer (VI.3.1) Failures & Safety Homogenous Redundancy (VI.2.1) Heterogeneous Redundancy (VI.2.1) Sanity Check (VI.2.1) Monitor-Actuator (VI.2.1) Watchdog (VI.2.1) Safety Executive (VI.2.1) Exceptions (III.2) Debugging (III.3) Creation Structural Decomposition Abstract Factory (IV.3/C) Prototype (IV.3/C) Dynamic Cast (IV.3/C) Builder (C) Composite (IV.4/S) Whole-Part (POSA1) Singleton (III.3/C) Factory Method (IV.3/C) VIII-5 Classification (3/3) Architectural Patterns Design Patterns Idioms Service Access Control Service Variation Service Extension Organization of Work Management Proxy (VI.2.3/S) Façade (IV.4/S) Iterator (IV.4 /B) Bridge (IV.4/S) Strategy (IV.5/B) State (VI.3.3/B) State Table (VI.3.3) Policy (VI.3.2) Decorator (IV.4/S) Visitor (IV.5/B) Hooks (IV.5) Command (IV.5 /B) Chain of Responsibility (B) Mediator (B) Memento (IV.5/B) Command Processor (POSA1) Template Method (IV.5/B) VIII-6
VIII.2 Common Misconceptions (1/3) Pattern are only effective when tools or the software process support their application! Patterns are simply a jargon, rules, programming tricks, data structures,...! No, because: Pattern make valuable rather general experience available Pattern provides a basis to communicate about design decisions and therefore support understanding and not coding Restructuring becomes easier with pattern-based design Pattern are more, because: Specific problems are addressed and solved A pattern describes its specific structure and behaviour Pattern catalogues Pattern languages VIII-7 Common Misconceptions (2/3) Pattern guarantee reusable software, high productivity, peace on earth, etc. Design pattern application results in a complete appropriate architecture. NO! Pattern guarantee nothing Pattern Languages guarantee only a little bit Pattern are just another tool for designer to do their job Therefore, incompetent designers will still result in bad designs NO! Architectural styles provide only vocabulary Architectural pattern provide only skeleton Design pattern handle only partial problems Part of a system are often better solved without patterns VIII-8
Common Misconceptions (3/3) Pattern can only be employed during the object-oriented design and implementation. Counter examples: Patterns for non OO languages Analysis pattern Software process patterns Anti patterns Reverse Engineering with pattern detection to measure the software quality Most pattern are looking similar to me and it still remains to be proven that pattern are successfully employed! No, because Patterns may have similar structure, but always differ substantial in behaviour My personal experience! Numerous publications on SWE, OO and pattern conferences (PloP) VIII-9 VIII.3 Open Questions & Outlook Problem of pattern composition (cf. II.3): Order of pattern application counts! Pattern languages that ensure correct composition? Pattern and encapsulation/components (cf. II.4): Pattern describe partial behaviour and structure and therefore cross traditional module boundaries! For Black-box abstraction suitable means for the formalization of patterns are required! Pattern for specific domains (cf. VI): Additional domain specific aspects such as dependability, real-time, synchronization, VIII-10
Doing Research? Graduate School of Dynamic Intelligent Systems SFB for Self-Optimising Concepts and Structures in Mechanical Engineering (hopefully starting july this year) Research in our group: SFB project B1: design techniques for self-optimising multi-agentsystems with mechatronic components SFB project B2: design methods: design processes, methods and tools for the design of self-optimising systems PhD in Graduate School: dynamic intelligent systems ISILEIT: Integrative Specification of Distributed Control Systems for the Flexible Automated Manufacturing FINITE: Fuzzy logic based interactive recognition of design pattern implementations Available: SHK positions Task force on B1 + B2 (next winter semester) bachelor thesis diploma thesis PhD positions (regular) PhD positions (Graduate School) VIII-11 VIII.4 Bibliography (1/1) [Buschmann+1996] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern Oriented Software Architecture. John Wiley & Sons, Inc., 1996. [Douglass1999] Bruce Powel Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns. Addison- Wesley, May 1999. [Gamma+1994] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. VIII-12