Pattern Languages of Programs'98
Abstracts of all PLoP'98 papers
Define an object that encapsulates the interaction of two or three obects.
Courier promotes loose coupling by keeping objects from referring to each
other explicitly, and it lets you vary their interaction independently.
Interaction Patterns for Communicating Processes
Interaction dynamics describe the way entities relate and communicate with
one another. Just as people interact in a variety of ways, communicating
processes, such as software components, can also interact in many and highly
complex ways. The software world is filled with examples of systems utilizing
processes, objects, components, device drivers and entities by other names
-- interconnected in different ways and with different purposes. But in
the seeming chaos there is order. Interactions between communicating
entities have many basic properties which can be isolated, described
and used across many application domains and in many situations. This paper
identifies some fundamental patterns that apply to communicating processes
in general and software components in particular. The patterns can be used
alone or in combinations, allowing more complex patterns to be built out
of simpler ones. The success of components as a software technology is
predicated on reuse and ease of reuse. In software component terms, ease
of reuse is determined by how easily components can be interconnected,
which depends solely on their interfaces and the interactions supported
by those interfaces. By recognizing the existence of standard interaction
patterns, and applying them to interfaces, components should be easier
to interconnect, and therefore reuse.
Many systems need to deal with time. Time can be just an additional type,
such as for the date of birth, or it can be an additional dimension, e.g.
when a history of data is needed. This paper summarizes some of the patterns
that help to design these systems.
Identify the Champion
Abstract: An Organisational Pattern for Programme Committees.
Intent: Make the paper review and selection process for a scientific
conference more efficient by focusing programme committee members' attention
on whether or not they will "champion" a submitted paper during the programme
Solution: Organize the review forms, the ranking and sorting of
reviews, detection of conflicts, and the review meeting itself around the
identification of champions. Use rating schemes with explicit operational
meaning, such as "I will champion this paper", rather than implicit, subjective
meaning, such as "strong accept", or "better than average", or "5". Group
papers around presence or absence of champions and detractors rather than
ranking them by weighted scores. Drive all discussions and decisions by
Many patterns depended on one important distinction: the distinction between
an object's class and its type. For example, many patterns rely on
interface inheritance, although, on examining their structures, most are
described using implementation inheritance. The making of this implicit
distinction gives evidence that there are patterns, fundamental to many,
that live within other patterns and are at the foundation of good object-oriented
principles. I give these patterns the name foundation patterns. I discuss
two such foundation patterns: delegation and substitution, separating the
two into their rightful positions, making clear what each patterns' role
is in object-oriented design.
Objects do not just represent objects that exist in the real world; they
often represent the memories of objects that once existed but have since
disappeared or projections of how they are expected to exist in the future.
This presents a particular modeling challenge because something which
appears straightforward at a point in time becomes far more complicated
when the model must consider how objects change over time.
This paper presents 3 patterns which show how this problem can be addressed
by elaborating the object model and how the resulting model can support
clients which are not concerned with the temporal aspects.
Many classes, particularly persistent ones, require that a certain subset
of their attributes be valid before a given instance can be considered
valid. How can this be guaranteed in component based or distributed environments
where the client which creates the instances is outside our design control?
Traditional solutions involve long lists of parameters to be supplied
by the client at creation time or allowing an invalid object to be created
and using a separate validation step. This paper examines situations in
which these solutions are not desirable or acceptable and presents an alternative
solution which can be more generally applied.
Customer Interaction Patterns
With the increasing emphasis on business awareness, individual team members
are asked to play a more active role in interfacing with customers. This
new role poses a challenge for those who may need guidance to improve their
effectiveness in customer interaction.
These patterns target developers and service providers in their direct
interaction with customers. This collection has been developing for over
a year and has acquired a structure that could produce a pattern language.
In the following diagram, patterns at each "level" help form the context
for patterns at the next lower "level." Connections between patterns
indicate that the lower level pattern was part of the solution for the
higher level pattern.
Feature Extraction - A Pattern for Information Retrieval
Digital libraries handle large amounts of information. They offer access
to collections of documents repre-sented in electronic format. According
to Bruce Schatz [Sch97]:
A digital library enables users to interact effectively with information
distributed across a net-work. These network information systems support
search and display of items from organized collections.
An increasing number of users discovers online information retrieval
and interactive searches. Once com-fortable with the new tools, they demand
new materials to be available in digital libraries. This requires obtaining
digital representations of documents. Since the process is getting cheaper
and faster, extending a digital library is not difficult.
Obviously, this increase in the amount of information has a strong impact
on the supporting software. Consider for example the case of searching—text
retrieval. This is a simple but basic operation for any digital library.
Several different algorithms are available for traditional text retrieval
[FO95]. However, they are not always applicable in the context of digital
libraries. For example, full text scanning, regular expression searching
and signature files have bad response times for large amounts of information.
Inversion is scalable but has a large storage overhead (up to 300%), and
index updates are expensive.
Large volumes of data are not the only challenging characteristic typical
to digital libraries. Unlike conven-tional database systems, digital library
users usually perform similarity searches (i.e., approximate) instead of
exact searches. A typical query for a database user may be “what is the
title of the book with the ISBN 0201633612.” In contrast, in a digital
library system, a user can ask “list in decreasing order of similarity
all books that are on the same subject as the one with ISBN 0201633612.”
(Database systems can also answer such queries provided that an appropriate
index structure has been created in advance.) This corresponds to a query
by example. Conventional database systems can handle some approximate searches,
but they were not designed for this purpose.
The emergence of multimedia content within electronic publications raises
another issue. One can provide as a query a digital image and ask for all
electronic documents that contain similar pictures. In this case, the challenge
is “understanding” the contents of the image. Digital images (and any other
data for that matter) correspond to complex information. Although computers
are good at representing and manipulating digital representations of this
type of information, decoding their contents is still a research issue.
One workaround for this problem is to have a person annotate each image
with a set of keywords. However, due to its inherent limitations,
this is only a temporary Band-Aid.
User Interface Software
This pattern language digs step by step into the design of a user interface
architecture. I do not mean the layout of a user interface. This is a matter
of ergonomics and bears enough potential to form a complete set of pattern
languages on its own. If you are interested in these issues, refer to books
such as [Tog92], [Coo95], or [Col95].
Instead, this paper is about the software that drives the user interface.
The figure below shows the overall landscape of the pattern language. It
starts with the most fundamental pattern, the User Interface Layer. Two
patterns describe the architecture of this layer: Separate Transformation
explains how to deal with complex interactions while Widget Model helps
to structure presentation. Though both patterns seem to describe different
philosophies, they are often combined to form the basic architecture of
the User Interface Layer.
Still you need to deal with more issues. At first you have to provide
Context Support between different interactions of the user. Depending on
the requirements and architecture of your system you can apply several
patterns for this. For the sake of brevity this document contains only
thumbnails of them. Another area of interest concerns Domain Layer Access,
which again lays the foundation of several other patterns. While some of
them are well-known design patterns, others are special to user interfaces.
A Confederation of Patterns for Resource Management
A confederation of patterns that covers a great number of applications
in business systems is proposed. Resource Management is the term used to
d efine these a pplications. It i ncludes patterns for Resource Location,
Resource Trading and Resource Maintenance. They are applied to examples
as medical attendance, video rental, real estate rental, library service,
show box office, fertilizer retail store and car repair shop. The proposal
is based on professional practice, and results from the combination of
recurring patterns, already covered in other PLoPs. The practice used mostly
procedural languages, but through object oriented reverse engineering of
real systems it was possible to explicit the proposed object oriented patterns.
Correct and timely rendering of graphics to a physical display is complex.
Obvious solutions tend to be monolithic. Display Maintenance describes
eight common design patterns for designing display architec-ture. Display
List, Request Update and Painter's Algorithm, the kernel of the language,
decompose the problem providing a modular architecture with correct behavior.
The other patterns address the issue of speed.
Composite as Metamodel: a Design Pattern for Implementing
SIGOBT-style Object Wrappers for HL7 Messages
We describe a Design Pattern applicable to the design and implementation
of SIGOBT-style object wrappers for HL7 messages. The Pattern described
is a special case of the Composite Pattern and is found in ProtoGen, the
MS-HUG SIGOBT implementation and in our own implementation of the SIGOBT
recommendations at the Centre for Medical Informatics.
In enterprise information systems based on a two-tier distribution architecture,
there are several clients working with shared resources. When designing
such a system one must ensure that each client that accesses such shared
resources does not interfere with other clients accessing and modifying
the same resources. If the resource in question does not have a thread
safe interface and/or it does not provide concurrency control mechanisms,
a Lock Server attached to that shared source can help provide controlled
concurrent access which allows each client to work with a consistent view
of the resource. This paper discusses the architecture of such a shared
By placing defaults and constants into a class interface, certain method
signatures become more general but also longer with the use of more parameters.
With Convenience Methods however, you will get a more flexible class interface
as well as a more readable client code.
In enterprise information systems based on a two-tier distribution architecture,
there are several clients working with shared resources. When designing
the system you have to ensure that each client has a consistent view on
the current state of the shared resource. If the resource in question is
passive, i.e. the resource is not able to notify interested clients about
changes of its (internal) state, attaching a Notification Server to that
passive resource helps achieve a consistent view for each client.
The Object Recursion Pattern
Distribute processing of a request over a structure by delegating polymorphically.
Object Recursion transparently enables a request to be repeatedly broken
into smaller parts that are easier to handle.
A Pattern Language of Statecharts
Finite state machines and their extension to statecharts are widely used
in reactive systems. David Harel [Harel87] has introduced statecharts as
an extension of finite state machines to describe the complex behavior
of an entity. The formalized concepts of statecharts and their specifications
have been used in many applications. Here, we show how to solve recurring
design problems in implementing statechart specification of an entity in
an object-oriented application. The statecharts' patterns represent solutions
to frequent design problems that are commonly thought of by system designers,
which include how to deploy hierarchy, orthogonality, and broadcasting
in a statechart's object oriented design. Since statecharts are frequently
applicable to software applications, thus it is helpful for the system
designer to directly exercise the statechart pattern language in his application
design. In the next section, a quick background of statechart is
presented, then a pattern map summarizes the statechart patterns and their
relation to finite state machine patterns. The rest of the sections describe
the patterns themselves.
The purpose of this paper is to present an architectural pattern named
shared repository pattern. This pattern defines a model of communication
for software components based on the use of a shared repository. It is
a very popular pattern in industrial settings that has been used in numerous
and various domains.
The work presented in this paper is part of a project which purpose
is to elaborate a system of architectural patterns in order to guide the
design of software systems. This project is conducted through the analysis
of existing systems in the Thomson-CSF business units.
Tropyc: A Pattern Language for Cryptographic Software
This work describes Tropyc, a pattern language for cryptographic software.
Nine patters are described: Information Secrecy, Message Authentication,
Message Integrity, Sender Authentication, Secrecy with Authentication,
Secrecy with Signature, Secrecy with Integrity, Signature with Appendix,
and Secrecy with Signature with Appendix. These patterns are classified
according to four fundamental objectives of cryptography and compose a
closed set of patterns for that domain. These patterns have the same
dynamic behavior and structure. We abstracted these aspects in a
generic object-oriented Cryptographic Metapattern.
Some Patterns for Insurance Systems
Building flexible insurance systems that allow short product release cycles
is a challenge for many insurance firms. Despite the huge market and the
many projects that do near identical things these projects are still a
little bit like black magic. There’s virtually no literature around on
the topic. This paper provides a collection of patterns that help explain
the basic forces and solutions for the design of product driven insurance
Encourage Piecemeal Growth
This pattern language’s initial growth and development was borne out of
two forces. The first was that I had completed a challenging development
effort in Java which had some promising ideas for a pattern language. The
second was that during the project, I had the great good fortune to read
Christopher Alexander’s The Timeless Way of Building and later, A Pattern
An Alternative Solution for the Observation Pattern Problem
We have used Fowler's Observation pattern (published in [Fowler 97a]) in
a project involving the maintenance of medical records of patients.
The pattern has been modified to suit the project particular requirements.
We end up with a substantially modified model which could be regarded as
an alternative solution. In this paper, we present that alternative model
and the underlying rationale.
We also suggest, as a separate issue, how the study of analysis can
be improved by using a suitable 'minimal' application, an application just
big enough to cover the pattern in question.
The fifty patterns contained in this language address the general problem
of how to design a complex and interactive artifact. The language’s goal
is to support high-quality interaction between that artifact and its users.
The patterns range from large-scale “genre” patterns, such as Form and
Composed Command, to smaller special-purpose patterns like Reality Check
and Short Description. The language should be of particular interest to
software designers, although the patterns seek to capture design patterns
across many different media, including print and industrial design. The
language does not address implementation.
Telecommunications Input and Output Pattern Language
A specialized set of patterns for defining the human-machine interface
has come into use within the world of telecommunications switching products.
The patterns presented here provide for the essential interaction between
a system and its human masters. Several of the patterns discuss concepts
specific to a telecommunications system, but most are general enough to
provide insight for anyone designing the Input/Output (“I/O”) interface
for a large system.
This paper begins by discussing the environment within which these
patterns are applicable. Two different methods of visualizing the
overall structure of this language are then presented, one graphical and
the other in the form of pattern groupings by related topics. The
patterns are then introduced. Supplemental material includes thumbnail
sketches of several patterns referenced frequently.
Using Design Patterns to Develop a Hyper-controllable
Medical Image Application
The basic idea of hyper-control is to use a multimedia document to control
other application systems[Chen 96]. In the original Command Processor pattern,
the fixed execution sequence of computation codes and dialog codes hinders
an application from supporting the hyper-control mechanism. Based on an
extension of this pattern and other related patterns, we have developed
a medical image system Discover, which can support the hyper-control mechanism.
In this paper, the system architecture of Discover will be described. We
will also give a practical example to explain the available ways for a
hyper-control document to "hyper-control" an application, and describe
our experience in using patterns.
A Structured Matcher is useful when making choices from a small, discrete
set of alternatives. It decomposes a complex decision into simpler decisions
about relevant factors and then uses decisions about these factors to make
Microthread - An Object Behavioral Pattern for Managing
There are times when the execution of an object needs to be suspended and
later resumed either due to the object responding to external events or
processing requirements internal to the object. The Microthread pattern
simplifies the management of an object’s execution when the object needs
to start, stop, and resume its execution. This pattern has shown itself
to be useful in both stand alone and distributed applications. An example
usage is shown along with the bene-fits and liabilities of using the pattern.
An implementation outline is also provided along with some sample code.
Finally, patterns related to the Microthread pattern are listed.
Triggered Placeholder - An Object Behavioral Pattern
for Delaying Object Creation
There are times when delaying an object’s creation is desirable to avoid
untimely side effects or the use of resources before they are actually
needed. It is non-trivial to receive a request to create an object and
delay that object’s creation until a later time. The Triggered Placeholder
pattern decouples a request for an object’s creation from its actual creation.
An example usage is shown along with the benefits and liabilities of using
the pattern. An implementation outline is also provided along with some
sample code. Finally, patterns related to the Triggered Place-holder pattern
A Componentware Development Methodology based on Process
We present a new approach to a componentware development methodology based
on a system of process patterns. We argue that organizing the development
process by means of a pattern system results in higher flexibility compared
to traditional ways of defining development processes. This is especially
important in the context of componentware. Finally, we propose a
pattern catalog with a selection of suitable process patterns.
Streamed Lines: Branching Patterns for Parallel Software
Most software version control systems provide mechanisms for branching
into multiple lines of development and merging source code from one development
line into another. However, the techniques, policies and guidelines for
using these mechanisms are often misapplied or not fully understood. This
is unfortunate, since the use or misuse of branching and merging can make
or break a parallel software development project. Streamed Lines is a pattern
language for organizing related lines of development into appropriately
diverging and converging streams of source code changes.
Composing Multimedia Artifacts for Reuse
This paper describes a pattern language that is used to define a multimedia
authoring environment capable of producing and utilising multimedia components.
We believe that the effective construction of multimedia material should
refrain from the common practice of building new documents and presentations
entirely from scratch. Hence, the proposed pattern language emphasises
the process of making new multimedia artefacts by reusing the existing
components to suit the requirements of new applications. Each of the presented
patterns describes one well-known approach to multimedia authoring, e.g.
joining and breaking artefact groups, defining and filling in templates,
arranging and re-arranging artefact collections, creating and holding presentations,
synchronising multiple multimedia channels, etc. The paper also provides
some insight as to the direction of the pattern language development, i.e.
it lists six dimensions of multimedia authoring and reuse and shows what
areas of functionality the final form of the pattern language must ultimately
Pattern: Hierarchical Star Schema
The HiStar pattern applies in the following situation:
the application data model is characterized by hierarchical relationships
along several dimensions
a distinguished entity is the focal point of the data model
the data model is represented using relational tables
the hierarchy must be traversed flexibly and efficiently.
The Cascading Bridge Design Pattern
Separate implementation dimensions into independent classes so they can
be varied and evolved independently. The benefits of this approach apply
in designing within sub-systems as well as architecting across sub-systems.
There are some particularly unique benefits for the latter.
The Reflective State Pattern
This paper presents the Reflective State pattern that is a refinement of
the State design pattern [GHJV95] based on the Reflection architectural
pattern [BMRS+96]. This pattern proposes a solution for some design decisions
that have to be taken in order to implement the State pattern, such as
the creation and the control of State objects and also the execution of
state transitions. When the object has a complex dynamic behavior, its
implementation can also become very complex. The Reflective State pattern
implements the control aspects in the meta level, separating them from
the functional aspects that are implemented by the Context object and the
State objects, located at the base level. This pattern provides a solution
that is easier to understand, extend and reuse than the State pattern.
Patterns for Interactive Applications
Many applications that we think of as "killer applications" on personal
computers, such as word processors or spreadsheets, developed before graphical
user interfaces were common. While graphical interfaces have brought several
benefits to these programs (better usability, scrolling, fancy fonts, and
crisper graphics), the core models of these programs haven't changed: word
processors still deal with text, and spreadsheets with matrices of formulas.
The pattern language described below attempts to generalize from applications
such as Emacs [1, 2], WordStar , dBASE III , and VisiCalc , and
to capture their essence. These patterns apply fairly early in the design,
after task analysis and object-oriented analysis have identified key tasks,
objects, and relationships.
The patterns apply to interactive programs, be they terminal-based or
graphical. By "interactive," we're trying to get at the difference between
the ed and vi editors. The line editor ed works nicely on a roll of paper
on a hard-copy terminal - you work one line at a time, and the file is
printed only at your request. The vi editor works on a screen - it continuously
shows the current document. You can enter text and see it in context as
In the Portland Pattern Repository , Kent Beck has articulated two
related patterns: in Story, he notes that while stories are presented in
time, the interface must be designed in space. In One Window Per Task,
he provides guidance on how to associate windows with tasks. The patterns
below are intended to weave into that same design space, and assume Beck's
patterns as a given.
This pattern language addresses three aspects of application design:
appearance, behavior, and extensibility.
For a discussion of how to design screens, see Structuring Metaphor.
For a discussion of important characteristics of application behavior,
see Computer Magic.
For a discussion of how to make an application extensible, see Two-Layer
Override Current Processing
Sometimes applications that execute commands with unpredictable response
times need to process those commands asynchronously so the user can continue
to perform functions in other parts of the application. In a multi-threaded
system, worker threads or asynchronous calls can be used to mitigate delays
in response times to commands operating over the network, printing, faxing,
or other types.
However, if done improperly, this can introduce race conditions, deadlocks,
data corruption, floods, hurricanes, or misuse of finite resources. Under
systems without threading, long commands are sometimes executed in a manner
such that a small fraction of processing is performed, followed by the
retrieval and dispatching of all queued messages, before processing the
Also, when these commands are executing and their completion is pending,
the user may request the invocation of additional commands that are intended
to interrupt the processing of the current command in favor of executing
the new command, in effect overriding the execution of a currently processing
Override Current Processing is a design pattern that can be used to
delegate the implementation of asynchronous execution of commands under
a LIFE (Last In, First Execute) idiom in languages such as Java and C++.
Fundamental Elements of an Extendible Java Framework
Their are many views of what a framework is. Those who have studied them
closely and have written about them in an academic sense seem to center
around the concept of abstract classes (see Jo hnson). Many who market
them to the industry tend to focus on functionality and APIs. The Java
language offers a series of underpinnings that make one reconsider
the wording of the earlier definitions. When those underpinnings are exploited
in the development
of a framework, one can get a level of extendability and understandability
in a framework which is a step above what one might get in the more established
object-oriented programming languages (such as C++ and Smalltalk).
We will discuss the patterns we have used in developing frameworks in
Java that encourage extendible and understandable frameworks. While doing
this we do not
intend to take part in the battles over how much more productive or
powerful an environment Smalltalk is, how much more efficient a language
like C++ is, etc. We
are merely attempting to illustrate how one should approach building
a framework in Java to meet these two goals of extendibility and understandability.
Refining the Observer Pattern: The Middle Observer Pattern
The refinement presented in this paper incorporates the possibility of
decoupling the common behavior from the observers avoiding data redundancy
in such a way we can maintain consistency among them without the object
that is being observed knows that feature.
SCRUM: An extension pattern language for hyperproductive
The patterns of the SCRUM development method are presented as an extension
pattern language to the existing organizational pattern languages.
In the last few years, the SCRUM development method has rapidly gained
recognition as an effective tool to hyper-productive software development.
However, when SCRUM patterns are combined with other existing organizational
patterns, they lead to highly adaptive, yet well-structured software development
organizations. Also, decomposing SCRUM into patterns can guide adoption
of only those parts of SCRUM that are applicable to a specific situation.
Connecting Business Objects to Relational Databases
These patterns describe how to implement business objects so that they
can be mapped to non object-oriented databases. There is an impedance
mismatch between these technologies since objects consist of both data
and behavior while a relational database consists of tables and relations
between them. Although it is impossible to completely eliminate this
impedance mismatch, you can minimize it by following the proper patterns.
The proper patterns hide persistence from the developer so that effort
can be spent on understanding the domain rather than in making objects
Application Scenario - A Pattern Language For Business
Application Scenario is a pattern language for those systems in which the
processes, rules, and interactions between business objects are the most
complex part of the system. It describes a collection of patterns which
make business processes explicit, and which model and implement these processes
in a traceable way from requirements and analysis through design, and into
first class objects in the implementation.
Telephony Data Handling Pattern Language
This paper is the beginning of a pattern language within a pattern language.
It is intended to be used in the context of a more encompassing telecommunications
pattern language. On its own, it is a pattern language of data handling
patterns. These patterns may not be unique to the data handling needs of
telephony systems, but are not validated outside this context.
Patterns for Productivity
The greatest asset of a software development organisation is the productive,
cohesive team. Quality software, architectures and systems can only
be developed when productive, cohesive teams operate. This pattern
language addresses team capability and productivity—the ways a capability
to produce and evolve software can be created and maintained in a healthy
These patterns are primarily about people, process, and understanding,
rather than products, production and artefact. Their solutions resolve
forces to create more productive software development environments by drawing
on products, production and artefacts.
The “growing alternative” metaphor (Brooks 95) strongly underlies these
patterns; software is grown by a group of people who share a culture of
understanding of the problem space, the domain, the system requirements,
the implementation technology, and a shared perception of the potential
futures of the system. A productive development team therefore represents
a development capability which should be regarded as of greater value to
the business than architectures or other software artefacts, which can
be evolved while team activity is maintained.
About these Patterns
The following eleven patterns describe the establishment and maintenance
of a team. Two patterns, BOOTSTRAPPING and COHESIVE TEAM address
establishing a productive team. Four patterns, ROUND PEGS FOR ROUND
HOLES, PROJECT PULSE, DELIVERABLES TO GO, and PRODUCTION POTENTIAL address
the managing and scheduling of an established team. The remaining
patterns, SHOW AND TELL, PRODUCTIVITY GAMES, TEAM SPACE, EFFECTIVE HANDOVER
and ARRANGING THE FURNITURE address maintaining a healthy level of productivity
as the project delivers.
A number of excellent organisational pattern languages have been written
(for example, (Coplien 95)). If any distinction can be made, it is that
the following patterns take a ‘capability based’ view of a development
team, and address ongoing management of the capability in a business context.
In Eric Raymond’s terms (Raymond 98), they pragmatically recognise the
reality of cathedral style development of medium and large business applications
and systems, and address some of the inherent inflexibilities and shortcomings.
Several patterns introduce ‘bazaar’ qualities in small doses.
These patterns are by no means complete; rather, they describe elements
of the author’s experience and observation. Alexander writes “good patterns
are good because to some extent each one of them reaches the quality without
a name itself”. Patterns themselves, like the systems in which they
are embedded and repair, must be allowed to evolve in a piecemeal fashion.
These patterns are offered primarily for their face value, but also as
an incremental contribution to the piecemeal growth of organisational pattern
Patterns for Dynamic Websites
In this paper we present two hypermedia patterns for websites to explore
solutions that have been adopted to face common problems about the information
available on the user and the website sides. One aspect of this problem
is analyzed on the News pattern to handle the problem of what do the users
know about the changes on a website. Another aspect is analyzed in the
Dynamic Configuration pattern from the website perspective, regarding the
activities that are carried out by users and how these activities can be
The Emissary Design Pattern
Define an object responsible of handling the events that occur during the
execution of an operation. This object decouples the objects implementing
the operation from the one requesting it. This object (the Emissary) thus
represents the client at the server objects, and acts as an intermediary
in the communication between the servers and the client.
This paper examines a set of three patterns that examine the issues that
arise when data are to be shared among several applications in one or more
different formats. When an ENGLISH ONLY/STANDARD REPRESENTATION can be
used, conversion and translation are moot issues. However, this simplicity
is not without its cost. When freely CONVERTIBLE CURRENCIES are available,
data are not isolated and trapped by incompatible representations. However,
as the number of formats increases, conversion becomes a complicated problem.
A LINGUA FRANCA addresses the problem posed when representations proliferate.
If a standard secondary tongue is adopted, a much smaller number of translators
or converters is required to ensure universal translation.
Metadata and Active Object-Models
A number of forces shape the way in which software evolves. One is
a desire to make programs as general as possible. Another is to push
configuration decisions out into the data. Yet another is to push
them out onto the users. Data themselves become more universal
and reusable when they are accompanied by descriptions of themselves that
let other programs make sense of them. They can become even more
independent when they are accompanied in their travels by code.
There are many ways to look at patterns. An especially useful way to think
of patterns is as a tool for teaching. We don't use patterns blindly; we
learn them. Patterns are all about learning successful techniques, understanding
when and how to use them. At ChiliPLoP'98, a small group of computer science
educators gathered to think about and write patterns appropriate for novices
learning to program in the first two years of undergraduate instruction.
(For more information or to become involved in this ongoing project, visit
the elementary patterns web page.)
The patterns contained here were first discussed and written as a part
of the ChiliPLoP workshop. They are, we hope, the beginnings of what will
be a pattern language for helping novice programmers construct loops. Writing
loops is the basis for many of the problems students attempt to solve when
programs in Algol-like languages. (In functional languages such as
Scheme, recursion is typically used for repetition instead of loops. See,
for example, Roundabout, a pattern language for recursive programming that
was workshopped at PLoP'97.)
We focused our initial efforts on identifying specific problems that
students encounter when learning to write loops. This lead us to several
specific patterns. At this point, they are only rather loosely related,
but we hope that they serve as a useful starting point for a more extensive
A Collection of History Patterns
Over time, events bring about changes of state in a domain. These
events may originate external to the domain, or be generated by the domain
itself. It is frequently necessary to either provide an audit trail
as to how a domain object reached a particular state, or to enable operations
on a domain object in the state it was at a previous point in time.
This paper presents a collection of patterns that document techniques for
recording the history of domain objects, by using an Edition to associate
the changed state with the event that caused it. The sequence of
the patterns reflects an increasing scope in the change of state: from
the changing of a simple value of a variable (ChangeLog) through to the
capturing of an entire composite structure at a point in time (HistoryOnTree).
Your are building a multi-user system or application that will provide
service to many users concurrently, or you are converting a single-user
system to support multiple users. The system may be either a multi-client
server or a thin-client system such as a terminal server or mainframe.
Additionally, you may be retrofitting security onto an existing multi-user
Multi-user systems add a host of problems beyond those faced by single-user
systems. These include
Many of these activities require information about the user on who’s behalf
processing is taking place to ensure that their activities are kept separate.
the need to restrict the activities of users to those they have permission
to carry out,
the need to prevent accidental interactions or “race conditions” between
the activities of the various concurrent users
Return to PLoP'98
Last update: August 6, 1998