Third European Conference on Pattern Languages of Programming and Computing Pattern Writing Workhop

Christophe Addinquy and Frederic Paulin:

"Transfer Pattern"

Well-designed software separates the domain model from peripheral subsystems (like GUI, persistence or communication infrastructure). However, these subsystems still have to com-municate with the domain model The domain model subsystem should not depend on peripheral subsystems that are suscepti-ble to change. The most common way of having these peripheral subsystems communicate with domain model is to write dozens of access methods for each domain class. We present a design pattern called Transfer that avoids these "bloated" interfaces by isolating the set of specific basic types used in peripheral subsystems from the domain model.

Shepherded by Kyle Brown

[zipped Postscript (64k)] [plain Postscript (522k)]

Jesus Alvarez-Gomez and Julio García-Martín:

"Parametric Synchronizer: An Object Behavioural Pattern for Concurrent Programming"

This paper describes the PARAMETRIC SYNCHRONIZER, an object behavioral pattern capable of managing synchronization and scheduling as parameters in the definition of con-current objects. Both synchronization models and scheduling policies participate in the pat-tern's structure as first-class components, and they can be defined from the outside by the programmer. Besides, the pattern allows the dynamic change of the scheduling policy without inconsistencies. Similarly to other related proposals, the PARAMETRIC SYNCHRONIZER provides the maximum amount of concurrency, decoupling method synchronization from method invocations, and method executions. As a result, the pattern can be seen as a generic framework/skeleton for the study of new synchronization models on concurrent object-oriented programming, specially focused on solving the inheritance anomaly.

Shepherded by Doug Lea

[zipped Postscript (399k)] [plain Postscript (3.69M)]

Serge Demeyer, Matthias Rieger, and Sander Tichelaar:

"Three Reverse Engineering Patterns"

Whereas a design pattern describes and discusses a solution to a design problem, a reverse engi-neering pattern describes how to understand aspects of an object-oriented design and how to identify problems in that design. In the context of a project developing a methodology for reengineering object-oriented legacy systems into frameworks, we are working on a pat-tern language for reengineering. This paper presents three samples of that pattern language, all dealing with reverse engineering.

Shepherded by Kent Beck

[zipped Postscript (224k)] [plain Postscript (853k)]

Julio García-Martín and Jorge Mederos-Martín:

"Patterns for Event Notification"

This paper describes the NOTIFIER and INTEREST PUBLISHER patterns for event notifi-cation in the context of graphical application design. The aim is to improve the known set of interaction patterns. The NOTIFIER pattern centralizes the event notification mechanics. The INTEREST PUBLISHER pattern describes the event representation and management. Both pattern can be combined to gain more flexibility.

Shepherded by Klaus Renzel

[zipped Postscript (102k)] [plain Postscript (622k)]

Marcel Rüedi and Peter Sommerlad:

"Named Object"

The Named Object design pattern is useful for managing a group of type-related components with a given configuration that are used as singletons or prototypes in your program. It pro-vides a means to transparently differentiate objects not only by their class membership, but by different configuration data. It can be seen as an extension of the Manager pattern [PLOPD3]. This pattern is part of 'Do-it-yourself Reflection', a larger collection of patterns it refers to

Shepherded by Robert Hirschfeld

[zipped Postscript (34k)] [plain Postscript (221k)]

Sherif M. Yacoub and Hany H. Ammar

"Finite State Machine Patterns"

Finite state machines (FSM) are widely used in many reactive systems to describe the dy-namic behavior of an object based on its state. The theoretical concepts of FSMs and an ob-ject's specifications, in terms of state transition diagrams, have long been used. Here, we show how to solve several recurring design problems in implementing a state machine. We present a basic design pattern for finite state machines whose design evolves from the general understanding of state machines functionality. Then we extend the basic pattern to support solutions to several design problems that are commonly thought of by system designers. These design decisions include the state-transition mechanisms, the design structure, state-instantiation techniques, and the machine type. Since finite state machines are frequently ap-plicable to areas of concurrent and real-time software, thus it is useful for the system designer to search a catalog of classified state machine patterns. The patterns cover the three-layer FSM pattern by Robert Martin and extend the set of patterns described by Paul Dyson and Bruce Anderson.

Shepherded by Andreas Rüping

Mentored by Wolfgang Keller

[zipped Postscript (125k)] [plain Postscript (1.36M)]