1. 1 Problems & Potential Solutions ProblemsPotential Solutions Documenting patterns & pattern languages for DRE systems is hard because We’re not accustomed to reasoning about our designs Knowledge of how to develop successful DRE systems is fragmented amongst researchers & practitioners Start with the basics & get involved with the patterns community We know how to explain our system architectures & how our systems work, but often don’t motivate & justify our design choices effectively, which makes it hard to Compare/contrast different technologies Distinguish the fundamental/generic aspects of our solutions from the details of a specific implementation Document & present systems from a problem- oriented focus rather than a solution-oriented focus Writing effective patterns & pattern languages is hard Articulation of forces often missing, which makes it hard to know the scope/context where the pattern applies Need to demonstrate generality of solution, rather than simply document a specific design/model or algorithm/protocol Show relationships to existing patterns & existing systems, i.e., what is the “pedigree” of the pattern? Pick a pattern template & follow it! (e.g., Alexandrian, GoF, POSA, etc.)

2. 2 Problems & Potential Solutions ProblemsPotential Solutions We need to simultaneously understand existing patterns, while also Not becoming wedded to existing patterns Decoupling specific design/implementation details from the generalizable pattern structure & dynamics To address key requirements of DRE system, we need to extend the corpus of existing patterns literature, which is largely focused on structure & behavior, but not on QoS Should we start by documenting “basic building block” patterns or start by creating pattern language template? Pincer’s movement The best patterns & pattern languages come from working on real-world problems; where do we find such problems? OEPs, research papers, open-source software, NEP Important to combine domain- experts with OO design & DRE experts Traditional DRE systems research community not accustomed to reasoning about design and traditional patterns community not familiar with DRE/QoS issues Form working groups and get involved with both communities

3. 3 Problems & Potential Solutions ProblemsPotential Solutions Determine the appropriate methods & notations for capturing dimensions of different DRE problem spaces Should we concern ourselves with documenting non-DRE patterns in our DRE pattern language?

4. 4 Pattern Taxonomies Gerard’s taxonomy Interface patterns (“Chunks of Lego”) Implementation patterns (“How do you build the Lego chunks?”) Usage patterns, e.g., codifying “best practices” (“How to combine chunks of Lego to create higher-level structures”) GoF taxonomy Creational patterns Structural patterns Behavioal patterns POSA taxonomy IdiomsDesign patternsArchitectural patterns Communication Initialization Service Access & Configuration Event Handling Synchronization Concurrency