Proceedings of
Pattern Languages of Program Design 4
PLoPD4

 

Abstracts of all PLoPD4 papers

Notes:
Some of these files require a Postscript viewer.
Others require Acrobat Reader.
Still others require MS Word or Word Viewer for 95, 98, NT (32 bit), or 3.x (16 bit).

Identify the Champion (pdf, html)

The peer review process for technical contributions to conferences in computing sciences is very thorough, and can be as stringent as the review process for journal publications in other domains.  The programme committee for such a conference will typically convene at a meeting, where submitted papers are discussed, and accepted or rejected for presentation at the conference.  Experience shows that discussions are more focussed, and the entire process runs more smoothly if most of the time is devoted to those papers that are actually "championed" by some committee member.  In order to make this work effectively, however, the notion of "championing" must be introduced early in the review process.  This paper presents a set of process patterns that help to achieve this goal.

Essence Pattern (rtf)

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.

Temporal Patterns (rtf)

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.

Patterns for Conducting Process Improvement (pdf)

Process improvement shares many characteristics with product development.  Recognizing these similarities is important, but so is recognizing some of the crucial differences. It is vital to the success of improvement efforts to realize that process change entails cultural change.  Numerous social and technical barriers must be overcome to effect lasting improvement. Ten patterns of successful software process improvement are described which illustrate some important similarities and differences between process improvement and product development.

A Family of Patterns for Business Resource Management (pdf)

A family of patterns that covers a great number of applications in business systems is presented. Business Resource Management is the term used to define these applications. It includes patterns for Resource Rental, Resource Trade and Resource Maintenance. They are applied to examples as medical attendance, video rental, real estate rental, library service, show box office, fertilizer retail store, car repair shop and electronic appliance repair shop. The work 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 presented object oriented patterns.

Multiparadigm Iteration Patterns (Word)

Since its inception, the field of software design patterns has had an object-oriented perspective. Yet object-oriented programming is just one of many programming paradigms. When we expand our view of programming to include other paradigms, we are presented with a much wider range of possible design choices. We illustrate this by showing that even a concept as simple as iteration can be approached from a number of different perspectives.

The Cascading Bridge Design Pattern (pdf)
Separate implementation dimensions into independent components so they can be independently interchangeable, evolvable, and testable. The GoF Bridge is expanded and generalized to exploit key additional benefits at multiple levels of system design.

Capturing and Structuring Goals:  Analysis Patterns (Word)
Too often, analysis concentrates on how a system or business functions, through scenario descriptions and interaction models.   In these four related patterns, analysis centers on objectives, with emphasis on what a business or system is trying to achieve.  The purpose of each activity is captured and explicitly stated, hierarchical and other relationships between objectives are identified, and a goal hierarchy diagram is formed.   This becomes the foundation for all requirements analysis.   Due to the nature of goals, it is less variable than a structure based on tasks and activities.

Architectural Patterns for Parallel Programming (Word)
This paper introduces an approach to describing and selecting architectural patterns for parallel programming. The approach uses the requirements of the order of data and the computations of the problem, along with the nature of their processing components, to make selections between different architectural patterns.

Finite State Machine Patterns (Word)

Finite state machines (FSM) are widely used in many reactive systems to describe the dynamic behavior of an entity based on its state. The theoretical concepts of FSMs and an entity's specification, in terms of state transition diagrams, have long been used.  This paper presents a FSM pattern language that addresses
several recurring design problems in implementing a state machine in an object oriented design. A basic design pattern for finite state machines is presented, its design evolves from the general understanding of state machines functionality. Then the basic pattern is extended to support solutions to several design problems that commonly challenge system designers.  These design decisions include state-transition mechanisms, design structure, state-instantiation techniques, and the machine type. Since finite state machines are frequently applicable to areas of concurrent and real-time software, thus it is useful for the system designer to
consult a catalog of classified state machine patterns.  The pattern language, presented in here, covers the three-layer FSM pattern by Robert Martin [Martin95] and extend the set of patterns described by Paul Dyson and Bruce Anderson [Dyson+98]. However, discussion on nested and concurrent states (i.e. statecharts) will not be included [Yacoub+98].

A Pattern Language of Statecharts (Word)

Finite state machines and their extension to statecharts are widely used in reactive systems. Statecharts have been introduced to model the behavior of complex systems. Their formalized concepts and specifications have been used in many applications. This paper presents a design pattern language to solve recurring design problems in implementing a statechart specification in an object-oriented design. The pattern language represents solutions to frequent design problems that commonly confront a system designer.  These problems include how to implement specifications containing hierarchy, orthogonality, and broadcasting in object oriented design.  The pattern language maps the specification into object oriented design and hence code would be easily generated for the specification.
Since statecharts are frequently applicable to software applications, it is helpful for the system designer to directly exercise the statechart pattern language in his application design.  In the next section, a brief background on statecharts is presented, then a pattern map summarizes the new statechart patterns, their
relationships, and how they relate to finite state machine patterns.  The rest of the sections describe five new statechart patterns namely, Basic Statechart, Hierarchical Statechart, Orthogonal Statechart, Broadcasting, and History State. Appendix (A) summarizes the patterns as problem/solution pairs, and appendix (B) gives a summary of statecharts principles.

Customer Interaction Patterns (Word)
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 acquired a structure that could produce a pattern language.

Composing Multimedia Artifacts for Reuse (Word)
This paper describes a pattern language that is used to define a multimedia authoring environment capable of producing and utilizing 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 emphasizes the process of making new multimedia artifacts by reusing 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 artifact groups, defining and filling in templates, arranging and re-arranging artifact collections, creating and holding presentations, synchronizing 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.

Abstract Session, An Object Structural Pattern (pdf)
Object-oriented frameworks are structured in terms of client/server relationships between objects; an object's services are invoked by client objects through the operations of its interface.  A common design requirement is for a server object to maintain state for each client that it is serving.  Typically this is implemented by returning handles or untyped pointers to the client that are used to identify the per-client data structure holding its state. The lack of strong typing can lead to
obscure errors that complicate debugging and maintenance.

The Abstract Session pattern allows objects to maintain per-client state with full type safety and no loss of efficiency.

The Agent Pattern: A Perspective from the Mobile Agent System Point of View (rtf)
This paper presents the Agent pattern, a design pattern useful to develop dynamic and distributed applications. 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 (a specialization of the Agent class), with some user identification and a specific security policy, providing distribution, security and persistence transparency.  Furthermore, this paper presents a detailed application of this pattern in the AgentSpace framework, as well as a brief application to the Telescript and Aglets Workbench.

Incremental Role Play (Word)
The complexity of object-oriented architectures is hard to understand with abstract explanations; therefore ask the students to behave as objects of the design and develop the design in several iterations.

Managing Change to Reusable Software (html)
Change is one of the few constants of software engineering. While managing this change is a challenge for all software-intensive projects, managing change becomes more difficult when companies build product-lines.  While reuse helps manage change across the product-line, managing change for specific components becomes more difficult. This paper describes six organizational patterns that support software reuse and address these concerns.

Display Maintenance (Word)
Correct and timely rendering of graphics to a physical display is complex. Obvious solutions tend to be monolithic. Display Maintenance describes nine common design patterns for designing display architecture. Display List, Request Update or Global 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.

Patterns for Improving the Capacity of Layered Systems with Multi-Threaded Servers (pdf, ps)
The paper describes a set of patterns that extend the pattern language proposed in [Meszaros96] for improving the capacity of reactive systems.  The intent of these patterns is to identify some specific causes which limit the efficiency of a distributed layered client-server system with multi-threaded servers, and to find appropriate corrective measures.  The type of systems considered here is a subclass of the larger category of reactive systems, and the new patterns are dealing with their specific performance characteristics. The patterns are illustrated with performance measurements conducted on a layered client-server system.

User Interface Software (Word)
This pattern language describes how to build the software that runs a user interface. It starts with the User Interface Layer as the basic pattern and drills down to fundamental design patterns. The patterns can be found in most popular architectures, such as MVC, PAC, and Application Document View. While the major patterns are discussed in depth, the paper only gives references as it comes to well-known design patterns described in other books.

Branch Removal (html)
This paper presents an extreme optimization technique that can be used when code must be fast, albeit at the expense of clarity and maintainability.  The technique takes advantage of pipelined hardware.

The Structure and Layout of Technical Documents (ps)
A technical document has one author or a small number of authors.  However, a technical document is usually read or browsed through many times and, furthermore, is typically used by a number of readers. Therefore, effort placed on the quality of technical documents generally pays off well. Authors who place effort on the quality of their documents are amply repaid by many readers' ease.  This paper presents a collection of patterns that help authors set up, develop, and improve technical documents. The focus of this paper is on the structure and layout of technical documents, and not on their contents. Guidelines concerning the contents of technical documents are to a large extent domain-specific and are beyond the scope of this paper.

Writing and Reviewing Technical Documents ps)
This paper presents a collection of patterns that can help both authors and reviewers make efficient use of the time they spend on technical documents. They address organisational issues as well as social or communication issues. They are meant to improve the process of writing and to make the review of technical documents a positive experience both for the author and for the reviewers. This includes all forms of reviews, such as meeting reviews or distribution reviews
or combinations. This paper builds upon a number of existing patterns and pattern languages that deal with related issues, such as review culture, communication issues, or teamwork.

A Presentation Pattern Language (pdf, ps)
Giving a good presentation is not easy. It takes a lot of discipline and creativity to prepare and give a presentation that, on the one hand, is received positively by its audience and, on the other hand, has the effects desired by the presenter. This paper gives a handful of recommendations that aid in creating a good presentation. These recommendations are put in pattern form and combined into a presentation pattern language.

The Role Object Pattern (pdf)
Adapt an object to different clients needs through transparently attached role objects, each one representing a role the object has to play in that clients context. Each context may be its own application, which therefore gets decoupled from the other applications.
 
METAWRAPPERS: Implementing Object Models of Nested Data Formats (pdf)
Sometimes, we may want to modify, or just read (in a computer program) specific parts of a message received (as a stream of bytes) from a communications port or of data read (also as a stream of bytes) from a flat file. What would be convenient for this is a kind of API to locate any component of a message in order to modify or read it. Such an API could also be used to construct an entire message. If the format of the message is a nested one (such as those defined using the ASN.1 or BNF notations nor those defined by the HL7 Standard), one possible style of such an API is to treat the components of a message (including the message itself) as objects and the constituent components of these components as objects nested within objects. In other words, direct programming with message component types (each message component type appears as a type in the computer program). This pattern deals with how to implement these types when their number is great or when new types are introduced and existing ones modified with great frequency.

Type-Check Elimination: Two Reengineering Patterns (pdf)
Whereas a design pattern describes and discusses a solution to a design problem, a reengineering pattern describes how to go from an existing legacy solution to a better refactored 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.
 
Patterns of Input Processing Software (pdf)
Programs that accept and interpret user input must must be able to interpret the input, as well as handle erroneous input.  In order to support such processing, and do it in a way that creates maintainable and extensible code, separation of concerns is critical. The five patterns presented here show how to achieve such separation of concerns in lexical analysis and parsing of input.

Design Patterns in Garbage Collection (ps, pdf)
This paper describes several design patterns found in garbage collectors.  The patterns we present are divided into two groups. The first group are two
new design patterns: Rootset and TriColour that have been  used in the garbage collection domain for up to 20 years. The second group of patterns are reported in the GoF book, such as Adapter, Facade, Iterator and Proxy, but we examine their use in the garbage collection domain. These patterns can be used by language implementors to provide a less efficient, but simpler and more flexible way of implementing and reusing garbage collectors in programming languages than current low-level and nonportable methods.

Foundation Patterns (Word)
Although not often mentioned, many patterns depend on one important distinction. This is the distinction between an object's class and its type. Stated another way, patterns rely on interface inheritance rather than on implementation inheritance.  Nevertheless, on examining their structures, patterns usually describe
implementation inheritance. By making this implicit distinction in their patterns, pattern writers give evidence that there are other patterns, fundamental to many,
that live within other patterns and that 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.

Tropyc: A Pattern Language for Cryptographic Software (pdf)
This work describes Tropyc, a pattern language for cryptographic software based on a generic object-oriented cryptographic architecture. Nine patterns
are described: Information Secrecy, Sender Authentication, Message Integrity, Signature, Signature with Appendix, Secrecy with Integrity, Secrecy with
Sender Authentication, Secrecy with Signature, and Secrecy with Signature with Appendix. They are classified according to four fundamental objectives
of cryptography (secrecy, integrity, authentication and non-repudiation) and compose a closed set of patterns for this domain. These patterns have the same dynamic behavior and structure. We abstracted these aspects into a Generic Object-Oriented Cryptographic Architecture.

The Reliable Hybrid Pattern A Generalized Software Fault Tolerant Design Pattern (Word, pdf)
In order to make software applications more reliable, it may be necessary to incorporate into them a strategy for tolerating software faults.  In the case of critical applications, this is essential.  In this paper we describe a general pattern, which we call the Reliable Hybrid pattern, that can be used to design fault tolerant software applications.  The pattern supports development of applications based on classical fault tolerant strategies such as N-Version Programming and Recovery Block, as well as those based on advanced hybrid techniques such as Consensus Recovery Block, Acceptance Voting, and N-Self Checking Programming.  The Reliable Hybrid pattern structure reflects the fact that these advanced strategies can be constructed through recursive combination of N-Version Programming, Recovery Block, and hybrid components.  Our pattern explicitly indicates how different advanced software voting techniques fit
into the design structure.  We use Consensus Recovery Block to illustrate the behavior of the designs that can be constructed using the Reliable Hybrid pattern, and we discuss some general issues related to the use of fault-tolerant software.

The Reflective State Pattern (ps, rtf)
This paper presents the Reflective State pattern that is a refinement of the State design pattern based on the Reflection architectural pattern.  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 the execution of state transitions. 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 object located at the base level. This pattern provides a solution that is easier to understand, extend and reuse than the State pattern.

A Collection of History Patterns (Word)
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 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) to the capturing of an entire composite structure at a  point in time (HistoryOnTree).

A Pattern Language for Writers' Workshops (Word)
Peer review is a crucial element of the quality improvement process for any document and more broadly for any intellectual work.  Most intellectual disciplines rely on a peer review culture for the advancement of knowledge, and those disciplines often focus more on content than on expression. The pattern community is less interested in the advancement of knowledge than in the broad dissemination of sound practice, and is equally concerned with content and expression.  Writers' Workshops, which come from the creative literature community, provide an alternative to pervailing peer review practice that is well-suited to the needs of the pattern community.  These patterns describe the normative behaviors of such writers' workshops.

C++ Idioms (Word, Word6)
This paper attempts to do three things.  The first is to re-cast the well-known idioms of "Advanced C++ Programming Styles and Idioms" in pattern form.  The second is to organize these idioms, which until now have survived as independent and largely unrelated patterns, into a true pattern language.  That means that the patterns for a graph and that they should be applied in an order dictated by the structure of the graph.  The third goal is to show that the patterns together, as a pattern language, attack what is metaphorically, conceptually, or actually a structural problem.

Capable, Productive and Satisfied - Some Organisational Patterns for Protecting Productive People (Word)
This paper documents 9 patterns which address the generation of a productive culture in a software development team.  The patterns address specific aspects of team behaviour, including the formation of an accurate recognition of a team's capacity, bootstrapping a new team, focussing on the problem space, being aware of the team's work rate, making sure that deliverables are used, learning to make appropriate assignments to individuals, and handling personnel changes.

Garden of Applications (Word)
This pattern language describes a set of constructs which provide a framework for interactive applications systems developed in a piecemeal fashion. It does this by proscribing the use of a set of constructs which encourage both the framework and application developers to start with a simple first order approximation of the system to be delivered. Because the applications and framework are largely decoupled from one another, iteratively changing these components will less of an impact. These patterns also depend upon a language which supports late binding, such as Java.

The Abstract Class Pattern (Word)
The pattern describes the technique for creating a superclass that defines its subclasses interface and their common implementation.

The Object Recursion Pattern (Word)
The pattern describes the technique for implementing recursion in an object-oriented fashion. The recursive message is progressively delegated through several handlers, called recursors because they implement the message to delegate to the next handler; eventually, the message reaches a handler, a terminator, that does not delegate further. The polymorphic nature of the message hides its recursive implementation, and the two different implementations of the message make it object recursion.

A Design Pattern for Distributed Object Communication (ps)
This paper presents the Distributed Proxy pattern, a design pattern for distributed object communication. The Distributed Proxy pattern decouples distributed object communication from object specific functionalities. It further decouples logical communication from physical communication. The Distributed Proxy pattern enforces an incremental development process, encapsulates the underlying distribution mechanisms, and offers location transparency.

The Validated Observation Pattern (ps)
The paper documents the Validated Observation pattern. This pattern provides an object model to record observations.  Observations are of various types and each type has its own structure and constraints. An important aim of the pattern is to allow the observations to be validated against their types.

Patterns for Software Packaging, Installation and Activation (Word)
Software packaging, installation and activation requires care during development. In return, careful packaging can help reducing development effort by reuse of standards and applications. The patterns presented here help to build packages for late installation, that cover multiple software layers (Minestrone), to define what functionality can be added and installed late (Plug-In and Specific Plug-In), and to shift costs between installation and activation (Advent).

Shared repository pattern (Word)
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 conducted at the Thomson-CSF research laboratory 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.

An Approach to Algorithm Design by Patterns (Word)
The paper proposes two behavioral patterns called DIVIDE-&-CONQUER and BACKTRACKING to facilitate the development of algorithms based upon
algorithm design techniques. The common informal seudocode that specifies the solving strategy for a general algorithm design technique is enhanced to provide a helpful guide to develop particular algorithms by following the divide and conquer and  the backtracking design techniques.

SCRUM: An extension pattern language for hyperproductive software development (pdf)
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.

EALAN:  A pattern language to build agile organizations (pdf)
BPR (Business Process Reengineering), is the leading functional strategy followed by most Global 2000 organizations.  Its premises are revolutionary:  it calls for a new order of organization that relies on the infiltration of software applications and other technologies as an enablers of the core business processes, that has proven to enhance productivity by factors of up to 1000%.

This has translated in increasingly high correlations of new software being developed by MIS shops to reengineering efforts.  Simultaneously, an increasing percentage of these new projects are being developed with object oriented technology.

This paper describes the relationships of the resulting "enterprise architectures" and their congruent temporal evolutions in terms of a pattern language.

Smalltalk Scaffolding Patterns (Word)
Smalltalk is an ideal language for rapid prototyping due to its economy of expression and interpreted execution, which allows a rapid code/test cycle, along with its extensive available class libraries which assist with rapid creation of both design essence and scaffolding. This paper presents a small set of patterns that have proven to be useful in the rapid development of prototypes using Smalltalk. The primary goal of these patterns is simple expedience.

Patterns for Building an Unusually Adaptable Java Framework (html)
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 [Johnson]). 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 extendibility and understandability (and therefore adaptability) 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, a.k.a. unusually adaptable, 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 the goals of unusual adaptability.

Effective Leadership in Software Development (html)
There is an abundance of literature available offering advice on how to organize your software development team and your development process. Many
organizational patterns [Cope] have been written that hint at a philosophy behind them that is not explicitly identified. Here we document patterns we have used to develop approaches to various software projects. We also believe these patterns lay the foundation for many organizational and other patterns while explaining some of the things we do to build effective teams and processes. Since these are philosophical patterns they are (at least intended to be) about mindsets, not concrete how-tos. The how-tos are the organizational patterns and such.

This collection of patterns is intended for people who desire to be a change agent for more effective software development. The basic premise is that without a solid foundation on which to frame the use of organizational patterns, it is easy to choose the wrong patterns, emphasize the wrong forces, or miss the forest for the trees. Unlike most papers written and read by people from a purely technical perspective, we are going to discuss religious/metaphysical issues of faith and their interaction/importance for software development. Although this is unorthodox, from a software industry perspective, we believe that the avoidance of these issues is fundamentally responsible for the general lack of effective leadership on many software development projects.

Object Synchronizer: A Design Pattern for Object Synchronization (ps)
This paper describes the Object Synchronizer pattern which decouples object synchronization from object functionality. This pattern supports several synchronization policies and their customization.  This pattern is used when invocations to an object need to be controlled in order to preserve its consistency. The solution described by this pattern provides encapsulation, modularity, extensibility and reuse of synchronization policies.

Big Ball of Mud (html)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom
discussed. This paper examines the most frequently deployed architecture:  the BIG BALL OF MUD.  A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.  These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture.  In order to become so popular, it must be doing something right. If more high-minded
architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.  A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?

Basic Relationship Patterns (ps)
Relationships between objects are almost as important to designs as objects themselves. Most programming languages do not support relationships well, so programmers must implement relationships in terms of more primitive constructs.  This paper presents five basic patterns which describe how objects can be used to model relationships within programs.  By using these patterns, programs and designs can be made smaller, more flexible, and easier to understand and
maintain.

High-Level and Process Patterns from the Memory Preservation Society (Word)
Minimising a program's memory use is one of oldest skills of the programmer's craft.  Although memory has become much cheaper over the years, there are very few systems that can afford to ignore memory usage entirely, and the recent development of palmtop computers and intelligent mobile phones has produced an entire new type of system where memory is limited.  In this chapter we describe some of the patterns we've encountered in memory-challenged systems. We've been surprised at the large number of patterns we found when we started to study the subject, so in this chapter we present only the High-level
and Process Patterns.

The Object System Pattern (ps)
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, but these objects will require more memory space and execution time than the more rigid objects supported by programming languages.

GOF patterns for GUI Design (ps)
The Design Patterns book introduced twenty-three patterns for object oriented software design.  These patterns are used widely, but only in their intended domain of software design.  We describe how seven of these patterns can be used for the conceptual design of graphical user interfaces.  By using these patterns, designers can produce interfaces which are more consistent, make good use of screen space, and are easier to use.

Being Careful With Your Inheritance:  Building Robust Frameworks With Less Inheritance (Word, ps)
Object oriented languages allow one to model solutions in a variety of ways, from packaging  state and algorithm together in pure objects to treating state and algorithm them as separate objects and everything in-between. As Cockburn puts it,  „object technology  is fundamentally a program-packaging technology that permits a continuum of function-only and function-plus-data packages" [Cockburn98]. What is "right" in a particular case depends on the prevailing context, constraints and user preference.

Inheritance is often used in solutions because object oriented languages directly support it. However experience has shown that inheritance may have been oversold and that such solutions suffer from a variety of ailments. Other solutions, based on composition are more complex to assemble and maintain and must use home grown mechanisms for survival but they are often more responsive to change.  Intransigent monolithic inheritance structures are broken down and
re-glued in a less stringent way. Function and data are separated and dynamically loosely re-coupled to provide extra flexibility and robustness (usability over time).

The framework presented highlights some of the issues involved.  Instead of inheritance, recursive algorithmic decomposition and indirection are substituted to gain flexibility, to influence runtime behaviour and to achieve robustness in the face of change. These mechanisms which are resolved at runtime provide great freedoms and can be seen as a move away from the strait-jacket compiled, static inheritance based languages often impose. But they are appropriate only in given situations, suffering their own kinds of problems: they are not a universal panacea. Surprisingly enough these mechanisms have their heritage in pre-Object solutions. Booch observes that these traditional techniques have their place in "bringing order to chaos" [Booch94].

Feature Extraction--A Pattern for Information Retrieval (ps, pdf)
The volume of information we can access is constantly increasing.  This growth is determined by the technology available for information processing. With the ubiquity of computers, most of the current information is produced and processed only in electronic format.

The volume of information alone is only one of the prerequisites of an information-driven society. Equally important is the ability to find pieces of information relevant to a particular problem. Traditional searching algorithms are not viable for problems typical to the information retrieval domain. They are based on assumptions about technology and goals that seemed reasonable before the widespread use of computers. However, these assumptions no longer hold in the context of information retrieval systems.

Feature extraction is an elegant and efficient alternative. The feature extraction pattern presented in this paper: (i) provides scalable solutions for systems that deal with large amounts of information, (ii) offers a natural, low-overhead solution for similarity searching, and (iii) enables software to process complex information without understanding its contents. Although the pattern originated in the information retrieval domain, it has expanded into other fields like office automation, genome databases, fingerprint identification, medical imaging, data mining, multimedia, etc. Since the pattern works with any kind of data, it has a wide range of applications.

An Input and Output Pattern Language:  Lessons From Telecommunications (Word)
This language contains the patterns that define how the human interface of a large real-time fault-tolerant system should be designed. It is based upon the experiences over many years from several telephone switching systems.  These patterns discuss key aspects such as dealing with overall system size, large specialized work forces and fault tolerance.

Archictectural Patterns for Enabling Application Security (Word)
Making an application secure is much harder than just adding a password protected login screen.  This paper contains a collection of patterns to be used when dealing with application security.  Secure Access Layer provides an interface for applications to use the security of the systems on which they are built.  Single Access Point limits entry into the application through one single point.  Check Point gives the developer a way to handle an unknown or changing security policy.  Groups of users have different Roles that define what they can and cannot do.  The global information about the user is distributed throughout the application with a Session.  Finally, users are presented with either a Limited View of legal options or are given a Full View With Errors.  These seven
patterns work together to provide a security framework for building applications.

Roundabout: A Pattern Language for Recursive Programming (html)
Roundabout presents a set of patterns for writing recursive programs.  Recursion is especially useful in contexts involving inductively-defined data structures.  By following the data's structure, recursion directly supports inductive reasoning about the program's behavior and correctness.  Perhaps more importantly, it often provides the simplest or clearest way to express a computation.  Thus, recursion can lead to code that is straightforward to write, modify, and read.  Roundabout helps programmers develop recursive code that follows the structure of the data that it processes.

Reports (Word)
This paper contains a collection of patterns for database reporting applications. While there are many different aspects of reporting, this paper focuses on the
ability to create new reports at runtime. It does not discuss user interface issues or good database design. This pattern language consists of patterns that pull data from the database and those that manipulate data after it has been extracted from the database.  This is accomplished by converting both queries and formulas into objects. These objects are then assembled into reports through the high-level Report Objects pattern.

The Cache Pattern: A Design Pattern for Locality of Reference and Caching (Word)
The technique of caching has been used in computer science for over twenty years.  It is a powerful technique with which data-intensive applications can increase speed and efficiency.  The efficacy of caching relies on the principle of locality of reference.  This pattern describes locality of reference and the components, interactions and policies required to implement caching.

InterruptibleCommand (pdf)
Sometimes applications executing 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 long-running commands.
 
As commands execute pending completion, an actor may invoke additional commands that are intended to interrupt the processing of the current command in favor of executing the new command.  Systems that are not multi-threaded execute 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.  On multi-threaded systems, interruption can introduce race conditions, deadlocks, data corruption, and over-consumption of resources.

Interruptible Command is a design pattern that can be used to safely delegate and interrupt the execution of commands.

Patterns for GIS Applications Design (Word)
Geographical Information Systems (GIS) are used to collect, analyze, and present information describing the physical and logical properties of the geographic world. The problem of reusing design in GIS applications has become also a need because nowadays times, more and more users are building GIS applications based on legacy systems instead of using a particular GIS product.  Recurrent problems are solved but those solutions are hardly communicated between
developers making impossible to get an unified basement architecture, which is the more important effort of the GIS community [OGIS96]. Patterns presented in this paper are part of our current work in this area, we hope that developers of geographical applications could use it but also document their own experience in this powerful way.

Pattern Systems for Hypermedia (Word)
Hypermedia technology is being used increasingly, mostly due to the new generation of open systems, i.e., those that allow the connection among applications in the same or different machines (intranets) or those that publish the interface of an application in a WWW's browser. However, current applications in this domain are not taking profit of all benefits that characterize this technology, and maintenance is very difficult to achieve. Building large hypermedia applications is a hard task, and although there exist many hypermedia design methodologies [Schwabe96, Izakowitz95], we also need design patterns that convey the expertise in the domain. We present in this paper three pattern systems intended to provide guidance for different aspects of hypermedia applications; the
first one concerns with the development of software support for hypermedia in the context of object-oriented applications; the second one deals with
organizing the navigational structures in a clear and meaningful way for intended readers and the third one comprises patterns for building effective graphical interfaces.

The Contract Pattern (ps)
This paper describes the Contract pattern, a programming pattern (idiom) that lets you apply assertions to guarantee pre-conditions and post-conditions of methods and invariants on the state of objects.  The Design by Contract methodology' introduced by Meyer is available in the Eiffel context, but unfortunately not for all the other object-oriented languages interested to profit from Meyer's contribution. This paper shows how to implement this idiom in Java. By using this idiom, developers can improve the reliability of their classes by precising what constraints must be satisfied by the client to guarantee correct functioning.

The Nanokernel Construction Pattern (ps)
The Nanokernel Construction Pattern is a set of design patterns which captures the design decisions for building microkernels in a systematic and incremental fashion. It divides the construction into three major patterns: Object Manager, Timer and Scheduler.  This pattern simplifies the development of microkernels to different hardware platforms and provides a portable structure for their machine-dependent components.

A Componentware Development Methodology based on Process Patterns (pdf)
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.

Proactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events (ps)
Modern operating systems provide multiple mechanisms for developing concurrent applications.  Synchronous multi-threading is a popular mechanism for developing applications that perform multiple operations simultaneously.  However, threads often have high performance overhead and require deep knowledge of synchronization patterns and principles.  Therefore, an increasing number of operating systems support asynchronous mechanisms that provide the benefits of concurrency while alleviating much of the overhead and complexity of multi-threading.

The Proactor pattern presented in this paper describes how to structure applications and systems that effectively utilize asynchronous mechanisms supported by operating systems.  When an application invokes an asynchronous operation, the OS performs the operation on behalf of the application.  This allows the application to have multiple operations running simultaneously without requiring the application to have a corresponding number of threads.  Therefore, the Proactor pattern simplifies concurrent programming and improves performance by requiring fewer threads and leveraging OS support for asynchronous operations.
 
Convenience Methods (pdf, rtf)
By placing defaults and constants into method signatures of 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 (pdf, rtf)
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 of 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.

Lock Server (pdf, rtf)
In information systems based on a two-tier distribution architecture, there are usually several clients working with shared resources. When designing such a system you 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.

Three Domain Specific Design Patterns (Word)
Patterns can be found and applied in any part of the software development process.  There has been a lot of development and research in patterns, and we can
see how there are patterns that focus on the analysis of a specific domain [Coad95], others that focus on the design of software systems [GHJV95], and some that focus on the technical issues in the implementation on a specific language [Coplien94].  This paper presents three domain specific patterns, where two of them together can be the basic architecture of a business administration software system.  These patterns deal with abstractions from the real world that are likely to appear in many O.O. software systems, and give a solution to some typical problems usually found in a wide range of business applications.

Patterns for Designing Navigable Information Spaces (pdf)
This paper presents several design patterns for the hypermedia domain: Navigational Context, Active Reference, Landmark, News and Shopping Basket. They are part of a pattern language for hypermedia applications and address the design of healthy navigational structures.  They can be applied in stand-alone applications or in dynamic Web sites or Information Systems.



Return to PLoPD4 homepage.



 
 Please send corrections, updates or suggestions to Matthew Hurlbut ([email protected]).
Last update: November  9, 1998