Proceedings of
Pattern Languages of Programs'98

 

Abstracts of all PLoP'98 papers

Courier Patterns

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.

Time Patterns

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 committee meeting.

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 identifying
the champion.

Foundation Patterns

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.

Temporal Patterns

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.

Essence Pattern

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 multimedia
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.

Display Maintenance

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.

Lock Server

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 Lock Server.

Convenience Methods

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.

Notification Server

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.

Shared Repository

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 systems.

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 Language.

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.

Interaction Patterns

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.

Structured Matcher

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 the decision.

Microthread - An Object Behavioral Pattern for Managing Object Execution

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 are listed.

A Componentware Development Methodology based on Process Patterns

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 Development

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 address.

Pattern: Hierarchical Star Schema

The HiStar pattern applies in the following situation:

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 [3], dBASE III [4], and VisiCalc [5], 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 you type.

In the Portland Pattern Repository [6], 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.
 

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 next fraction.

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 command.

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 their definition
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 programming
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 software development

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 persistent.

Application Scenario - A Pattern Language For Business Process Control

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

About 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 state.

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 literature.

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 validated.

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.

Lingua Franca

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.

Loop Patterns

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 writing
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 documenting effort.

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).

Virtual Singleton

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 system.
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.


Return to PLoP'98 homepage.


 
 Please send corrections, updates or suggestions to Weerasak Witthawaskul (witthawa@ncsa.uiuc.edu).
Last update: August 6, 1998