Conference Organization

Conference Chair: Till Schümmer

Program Chair: Lise Hvatum

Program Committee: Paris Avgeriou, Arno Haase, Neil Harrison, Lise Hvatum, Allan Kelly, Michael Kircher, Andy Longshaw, Klaus Marquardt, Till Schümmer, Didi Schütz, Markus Völter, Uwe Zdun

Writers’ Workshop groups in EuroPLoP 2007

Writers’ Workshop A  –  Allen

Workshop Leader: Allan Kelly

Papers:

• A1: Andreas Fießer: A Pattern Language for Film Production
• A2: Allan Kelly: More patterns for Technology Companies Product Development
• A3: Ralf Laue, Volker Gruhn : Good and Bad Excuses for Unstructured Business Process Models
• A4: Osorio Lopes Abath Neto, Jacques Philippe Sauvé, Ayla Dantas: A Pattern Language for Acceptance Test-Driven Development
• A5: Jürgen Salecker: Patterns for Configuration Management
• A6: Michael Weiss: In Bed with the Enemy

Writers’ Workshop B  –  Brooks

Workshop Leader: Till Schümmer

Papers:

• B1: Marina Haase, Marco Miedl: Patterns for Leading Effective and Efficient Meetings – Part Two
• B2: Stephan Lukosch, Till Schümmer, Thomas Jarmer : There’s more than just a LOGIN — Six patterns that make connecting to a collaborative system more convenient
• B3: Amir Raveh, Ofra Homsky: Pattern Language for Online Communities
• B4: Nicole Schadewitz: Interaction Design Patterns for Cross-Cultural Computer Supported Design Learning
• B5: Axel Schmolitzky: Patterns for Teaching Software in Classroom
• B6: Till Schümmer, Peter Tandler: Patterns for Technology Enhanced Meetings

Writers’ Workshop C  –  Cerf

Workshop Leader: Dietmar Schütz

Papers:

• C1: Jorge L. Ortega Arjona: Design Patterns for Communication Components of Parallel Programs
• C2: Sachin Bammi: A generic real time data acquisition pattern language for embedded applications involving interrupt driven I/O
• C3: Michael Pont, Susan Kurian, Huiyan Wang: Selecting an appropriate scheduler for use with time-triggered embedded systems
• C4: Dietmar Schütz: Patterns for Implementing Variability
• C5: Huiyan Wang, Michael Pont: Patterns which help to avoid conflicts over shared resources in time-triggered embedded systems which employ a pre-emptive scheduler
• C6: Ed Fernandez, Michael VanHilst: Patterns for WiMax security
• C7: Juan C. Pelaez, Ed Fernandez: Patterns for VoIP Signaling Protocol Architectures

Writers’ Workshop D  –  Dahl

Workshop Leader: Tim Wellhausen 

Papers:

• D1: Birte Böhm, Norbert Gewald, Gerold Herold, Dieter Wißmann: Indirection Pattern for data modeling
• D2: Lotte De Rore, Monique Snoeck: A pattern language for reconciliation
• D3: Isabelle Cote, Denis Hatebur, Maritta Heisel, Holger Schmidt, Ina Wentzlaff: A Systematic Account of Problem Frames
• D4: Hans Wegener, Robert Marti: Slowly Changing Dimensions: a Pattern Language for Coping with Change in Analytical Information Processing
• D5: Leon Welicki: Patterns for Factoring Responsibilities when Working with Objects and Relational Databases
• D6: Tim Wellhausen: Object Prefetch Filter – A Pattern for Improving the Performance of Object Retrieval Using Object-Relational Mapping Tools

Writers’ Workshop F  –  Feigenbaum

Workshop Leader: Andreas Rüping

Papers:

• F1: Diethelm Bienhaus: Patterns for Unique Product Identification
• F2: Stefan Holtel: A Pattern Language for a Semantics-Driven Software Architecture
• F3: Marty Kauhanen, Chris Eaket, Robert Biddle: Patterns for Story Authoring Tools
• F4: Christian Kohls, Tobiam Windbrake: Moving objects – More patterns for a pattern language of interactive information graphics
• F5: Fernando Lyardet, Dirk Schnelle: Consumer Voice Interface Patterns
• F6: Andreas Rüping: Software Architectures for Web Content Management — The Big Picture

Writers’ Workshop G  –  Gray

Workshop Leader: Klaus Marquardt

Papers:

• G1: Arno Haase: A Pattern Language for Designing Pattern Languages
• G2: Klaus Marquardt: Overthreading 
• G3: James Noble, Arno Schmiedmeier, David J. Pearce, Andrew P. Black: Patterns of Aspect-Oriented Design
• G4: Arno Schmidmeier: Aspect Team and other patterns for adoption of AOP
• G5: James Siddle: Creating Software Architecture using Pattern Sequences
• G6: Carsten Hentrich, Uwe Zdun: Service Integration Patterns for Invoking Services from Business Processes

Writing Group

Writing Group Leader: Uwe Zdun

Papers:

• WG1: Mayank Chaturvedi: Team where People Matter  A Project Management Pattern; [Associated with workshop A] 
• >WG3: Klaus Meffert, Ilka Philippow: Configuration Provider: A Pattern for Application Configuration  [Associated with workshop F]
• WG5:  Birgit Zimmermann, Christoph Rensing, Ralf Steinmetz: New Patterns for Tailoring E-Learning Materials to Make them Suited for Charged Requirements  [Associated with workshop B]
• WG6: Marc Bartsch, Rachel Harrison: Design Patterns with Aspects: A case study  [Associated with workshop G]

EuroPLoP 2007 Focus Groups

Patterns for Versioning, Releases, and Distribution

Organized by Klaus Marquardt and Kevlin Henney

Beyond software development, there is more to the software lifecycle than maintenance. From a developer’s perspective, the focus on development can be considered only natural.

However, it is very much an inward looking perspective. The software needs to be brought to the end user, and the end user and various customer stakeholders will care about the software beyond its initial release.

To the extent that they influence the development and architecture, the logistics of software deployment are the topic of this focus group. This includes

• Definition of a package for release 
• Deployment and installation 
• Check for compatibility with other software components 
• Identify the software for future reference 

Process and Results

Some work is available as a would-be pattern language. This focus group shall add to the pattern collection by including a broader experience, and explore sequences to shape the pattern language.

For the focus group, we will use an abbreviated pattern format that helps to focus on sequences. The existing patterns will be brought to the workshop in that format. Participants are asked to prepare in advance, but unprepared guests are welcome as well.

Complexity Management

Organized by Klaus Marquardt, Lise Hvatum, and Dietmar Schütz

Just like stranded whales suffocate from their own weight, projects can suffocate from their own complexity. To successfully run and finish a project, its complexity must be known and managed.

This focus group shall explore the current state of complexity metrics, the related heuristics, and collect the management practices in a pattern form.

Process and Results

The group will start out to identify where complexity is within some project, how it is introduced into the project, and how to get rid of it (where possible) or circumvent it.

Pattern Repositories

Organized by Michael Weiss, Aliaksandr Birukou, and Paolo Giorgini

How do you find a pattern? Do you A. Flip through the patterns books on your shelf, B. Google, C. Not bother and stick with what you know, or do you D. Search a pattern repository. We will explore the issues in making a repository work well. Some of questions for which we hope to get answers are how do you organize and search pattern repositories, how do you integrate them with your development process, and how do you create a community of users around a repository.

More details can be found in this PDF file.

News: The focus group has created a wiki for off-site interaction: http://www.patternforge.net/wiki.

Ajax — The big new thing or the big new bubble?

Organized by Andreas Rüping

With Web 2.0 becoming more and more popular, Ajax (Asynchronous JavaScript and XML) turns out to be the new technical buzzword in the area of Internet-based systems. People’s opinions concerning Ajax seem to differ a lot though. Some say it’s just trendy, relevant only for web sites such as MySpace and YouTube that seem to be in vogue right now. Others point out that Ajax represents a new quality for web applications that cannot be ignored. So the big question is: is this just a hype, or is there some substantial new technology?

In discussions you often hear the following pros and cons: 

+ Ajax-based web applications are much more interactive than anything we’ve known before. Only Ajax makes a vast user participation possible. 

+ Ajax-based web applications are much faster than traditional web applications. Fewer pages are loaded, and some of the page loading can be done in the background asynchonously. 

– Ajax blurs the concept of a web page. The back button can no longer be used, bookmarkability is ruined, and web pages cannot be found by search engines. 

– Ajax-based applications rely on a lot of JavaScript code. JavaScript is notoriously difficult to test and maintain. Develop with JavaScript, and you’re sure to end up in spaghetti. 

– Ajax introduces lots of browser dependencies. Users must have JavaScript switched on, and not everybody has. But even if, what users get to see depends on the browser they’re using.

These pros and cons read a bit like a system of conflicting forces, so why not try to resolve these forces and figure out what techniques really work, and how?

The perspective of this focus group is to:

• bring together people interested in advanced web technologies
• exchange experiences made with Ajax in real-world projects
• describe scenarios where Ajax makes sense and others where it doesn’t
• identify best practices for using, but not overdosing Ajax

“That Works for Me!” – The role of context in the successful application of software development practices

Organized by Andy Longshaw and Kevlin Henney

There are many methodologies and collections of software development practices that are used in different organizations and by software development teams within those organizations. Some of these organizations successfully produce software-intensive systems while others simply produce high levels of stress. In some cases, successful and unsuccessful organizations use, or purport to use, the same software development methodology, so why do they not get the same results? If an approach fails, it is likely that reluctant adopters and cynical stakeholders will blame the methodology and that the methodologists and enthusiastic adopters will blame the organization and the application of the method. This observation applies as much to individuals and their practices as it does to teams and whole organizations: whether it is naming conventions, programmer testing, class hierarchy design or pairing, “that works for me” does not always translate to “that should work for you”.

It is well knows that certain software products and frameworks have a “sweet spot”: a target environment or projected mode of operation under which the product will perform optimally. When you move outside that sweet spot, not only may the operation of the product become sub-optimal but it may actually start to become detrimental to the operation of the system as a whole. By and large, methodologies and software development practices do not come with an explicit sweet spot (or in their case an expected organizational context and matching individual aptitudes) and, being concerned with people rather than software, they are not as clearly bounded as frameworks. Furthermore, for a variety of reasons, methodologies have a tendency to generalize over time.

However, our hypothesis would be that methodologies and practices also have such a sweet spot in which they operate best and – just as with a software product – straying too far outside this sweet spot can cause the practices to become counter-productive. In both success and failure stories, there is a great deal of implicit detail that contributes to the eventual outcome. By making more of this explicit, could we expect more effective adoption of practices?

This focus group looks to explore which practices work (and which ones don’t) in different types of organization and software development environments and with different kinds of people. Questions we will look to answer include:

• What examples do we have of successful methodologies or software development practices? 
• What are the additional details and particular aspects of the context in which they were applied that seemed to make them work? 
• Can we actually be that scientific about the relationship between context and practices or was a particular success using a practice just lucky? 
• What context do we think that the originators of the methodology had in mind when they proposed them (or what type of context did they grow out of)? 
• What makes a methodology work or not work, apart from having the originator of it stood over your shoulder all the time? 
• Can we start to define a set of key environmental factors that will lead to the successful application of a particular methodology or development practice? 
• Can we identify any environmental factors that will lead to a particular methodology or development practice becoming a development anti-pattern or smell? And to what extent is it the practice as opposed to misapplication of the practice? 
• Based on this, do we find that there are “groupings of practices” that share the same context or not?

Patterns for Finding your way into new Projects – quickly…

Organized by Marina Haase

We all know the situation: We are new in an IT-Project – there is very little documentation, and very few people to help us get into the project. I’m implying that most of us don’t just arrive in a project – and “hey, presto!” by magic understand the project, are integrated in the team and start being productive.

I’m sure over the years many of you have collected best practices that you repeat when arriving in new project contexts… and I have started analysing what I do – what doesn’t work and what does… and probably will work next time too! The goal of this focus group is to collect proven best practices for getting into projects and start being productive quickly.

We will spend the first few minutes introducing our best practices. Then we will spend a few moments thinking and brainstorming about the problems that occur when starting out in projects. We will then try and associate the problems to the collected best practices or other ideas of best practices. After this we will divide into groups and brainstorm about forces and consequences of first pattern ideas. Ideally at the end of the focus group we will have generated a collection of pattern beginnings that might be documented in detail at a future Europlop.