Problems Potential Solutions Problems Potential Solutions Documenting patterns

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

Problems & Potential Solutions Problems Potential Solutions We need to simultaneously understand existing patterns, while also To address key requirements of DRE system, we need to extend the corpus • Not becoming wedded to existing patterns of existing patterns literature, which is • Decoupling specific design/implementation largely focused on structure & details from the generalizable pattern structure & behavior, but not on Qo. S dynamics 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 Traditional DRE systems research community not accustomed to reasoning about design and traditional patterns community not familiar with DRE/Qo. S issues 2 Form working groups and get involved with both communities software, NEP • Important to combine domainexperts with OO design & DRE experts

Problems & Potential Solutions Problems 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? 3 Potential Solutions

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”) • Go. F taxonomy • Creational patterns • Structural patterns • Behavioal patterns • POSA taxonomy Idioms Communication Initialization Service Access & Configuration Event Handling Synchronization Concurrency 4 Design patterns Architectural patterns