Writer's Workhop B
|Stephane Ducasse, Rob Nebbe & Tamar Richner||Type-Check Elimination: Two Reengineering Patterns|
|Wolfgang Keller||Object/Relational Access Layers|
|Manfred Lange||Time Patterns|
|Klaus Marquardt||Physical Patterns|
|James Noble||The Object System Pattern|
|James Noble & Charles Weir||Proceedings of the Memory Preservation Society|
|Jorge L. Ortega Arjona & Graham Roberts||Architectural Patterns for Parallel Programming|
|Alberto Silva & Jose Delgado||The Agent Pattern|
Whereas a design pattern describes and discusses a solution to a designproblem, a reengineering pattern describes how to go from an existing solution to a better solution. In the context of a project developing a methodology for reengineering object-oriented legacy systems to frameworks, we are working on a pattern language for reengineering. In this paper we highlight the structure of a reengineering pattern and present two simple, related patterns.
Shepherded by Don Roberts
[zipped Postscript (51k)] [plain Postscript (189k)]
Numerous patterns have been written about the design of object/relational database access layers. Looking at the body of pattern literature you will find that some patterns are still to be mined, while there's no generative "one stop" pattern language for the problem domain. This paper provides a systematic roadmap of the patterns in the field. It fills some pot holes on the road towards a full pattern language for object/relational database access layers by providing some missing patterns and links. It focuses on the missing patterns, as writing them all would require integrating some 35+ patterns into a single paper. That's too much for a PLoP paper.
Shepherded by James Noble
[zipped Postscript (272k)] [plain Postscript (1.39M)]
The paper describes several patterns, which are useful when time comes into play while designing an application. Order by increasing complexity, the six patterns present techniques addressing different issues in that area. Although time in general adds an additional level of complexity to the application, the patterns here start from very simple, such as "Time as Type", and also cover the question on how to store the history of the states of an object (including referenced objects!)
Shepherded by Massimo Arnoldi
[zipped Postscript (69k)] [plain Postscript (584k)]
Patterns have emerged as an efficient way to communicate solution proposals. Most software patterns up to now focus on logical design issues. This article presents physical design patterns, that partly employ existing logical patterns. The presented patterns deal with limited physical resources, and framework development. "Advent", combined with the logical "Light'n'Heavy", facilitates online installation of software components. "Plug-In" describes how large logical components are physically integrated. "Suppengemuese" describes components satisfying a variety of technical interfaces at the same time. For writing these patterns, a notation is introduced that serves the documentation of logical and physical patterns alike, but differs from notations known in literature.
Shepherded by Neil Harrison
[zipped Postscript (87k)] [plain Postscript (722k)]
Classical object oriented systems require every object to be an instance of a class, and all classes to be written before the program is deployed. Some programs need flexible, configurable, dynamically extensible representations of objects, which cannot be determined in advance. The Object System pattern describes how you can build your own object system from scratch. Using the Object System pattern, you can build precisely the kind of objects you need for your application.
Shepherded by Peter Sommerlad
[zipped Postscript (401k)] [plain Postscript (1.24M)]
In this paper we describe some of the most common patterns used in memory-limited systems. The patterns deal only with limitations on RAM memory. Of course a typical system may have many other constraints. Some of the patterns, such as the optimisation ones, may apply as much to other constraints as to RAM; other patterns will not be so suitable. Where appropriate, we've indicated in the individual patterns how they interact with other resource limitations.
Shepherded by John Vlissides
[zipped Postscript (156k)] [plain Postscript (1.37M)]
This paper introduces an approach for describing and selecting architectural patterns for parallel programming, according to the characteristics of order of data and computations of the problem, the patterns of process distribution among components, and the organization of these components, using pattern descriptions.
Shepherded by Frank Buschmann
[zipped Postscript (164k)] [plain Postscript (1.58M)]
This paper presents the Agent pattern, a design pattern for dynamic and distributed applications development. The Agent pattern provides a clean and easy way to develop agent-based applications, mainly in open and large-scale distributed environments such as the Internet and application areas such as Electronic Commerce. The Agent pattern encapsulates a business specific class (the Agent class), with some user identification and a specific security policy, providing distribution, security and persistence transparency. Furthermore, this paper presents a real application of this pattern in the AgentSpace framework.
Shepherded by Doug Lea
[zipped Postscript (121k)] [plain Postscript (926k)]
|[EuroPLoP 98 Homepage]||
Last change: June 25th 1998