1

Problems & Potential SolutionsProblems Potential 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

Problems & Potential SolutionsProblems Potential 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

Problems & Potential SolutionsProblems Potential 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

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 taxonomyIdioms Design patterns Architectural patterns

Communication

Initialization

Service Access & Configuration

Event Handling

Synchronization

Concurrency