The following are abstracts of the final papers in the PLoP'99 proceedings.
Many projects today use a component-based approach to developing software. Component-Based Development (CBD) stresses language and platform interoperability, and separation of interface from implementation. Existing and newly constructed components are being deployed to clients and servers to build flexible, reusable solutions. However, assembling a system consisting of custom and pre-built components can be difficult because of hidden dependencies, complex interactions, and obscure design. This pattern language has ABSTRACT INTERACTIONS, COMPONENT BUS, COMPONENT GLUE, THIRD-PARTY BINDING, and CONSUMER-PRODUCER as five patterns that make it easier to assemble components that communicate, collaborate, and coordinate to get a job done..
Many projects today use a component-based approach to developing software. Component-Based Development (CBD) stresses language and platform interoperability, and separation of interface from implementation. Existing and newly constructed components are being deployed to clients and servers to build flexible, reusable solutions. Throughout the history of computing machinery, hardware and software engineers have endeavored to make it easier to utilize computers to solve problems. Many times, this has been done through raising the level of abstraction. And a consistent, exponential increase in the performance and storing ability of these computers has facilitated it. Components and component frameworks are being used today to build solutions at a higher level of abstraction. However, successful integration and deployment can be a complicated task. This paper presents LAYERED COMPONENT FRAMEWORK as a pattern that helps framework builders build more cohesive and flexible component frameworks.
The User Information Feedback pattern language gives patterns for event (error and information) reporting and management. This pattern language describes the importance of separating error signaling, context memorization, event production and event publication on any media. On one hand, this pattern language is an extension of Neil Harrison's "Patterns for logging diagnostic messages" [Harrison98]. It suggest some ways for message identification, and their dispatching and filtering on different media. On the other hand, this pattern language links to Ward Cunningam's "Checks Pattern Language" [Cunningham95].
Based on experiences on many application development projects, it was attempted to try and capture the commonalities between these domains in a (meta-) domain pattern. It was hoped that this domain pattern (Service Provider) would help in generating a generic, non-domain specific framework, which could then be customized in several domain contexts.
In other words, in trying to generalize commonalities among different applications in several domains (telecom, healthcare, higher education, billing, packaging), we have tried to generalize common notions into a "domain pattern". As "patterns generate architectures", so domain patterns generate application domain architectures. While patterns are micro-architectures finding solutions to problems in a context that cuts across particular designs, domain patterns are a generalization of analysis patterns that help create generic frameworks (non-domain specific frameworks).
Service Provider tries to capture the structure and fundamental collaborations between a Composite Party who offers Composite (packaged deals) Services or Products for some form of purchase (rent, lease, membership, purchase, subscription, registration, etc.) by a ServiceUserParty according to some specific Terms of Agreement (constraints, contracts, agreements, etc.)
Domain patterns cover not only patterns at an application layer level, but also with other generic application system levels of user-interface, database and business rules. We discuss a few patterns of each category that are pertinent to the Service Provider domain pattern.
This framework is implemented in Java (Java Business Frameworks (JBF)), and has been used in the implementation of the following applications : course registration, order-entry, sales leads, rule repository, sales and billing.
When a model is implemented in an object-oriented language, associations are implemented as attributes. All associations could be modeled from the start as attributes, but all attributes could be modeled as associations equally well. The modeler therefore cannot choose to use an association or an attribute only by reference to the reality underlying the model. Instead, the modeler chooses one or the other for its expressive power. In some contexts, these modeling decisions are independent of whether the modeler is engaged in analysis or design. The first pattern, Deferred Attributes, deals with these situations. Since analysis and design serve different expressive needs, however, the decisions are likely to differ in other contexts. The other two patterns, Associations for Analysis and Attributes for Design, deal with those situations.
What do well-known techniques such as gather/scatter for input/output, code downloading for system extension, message batching, mobile agents, and deferred calls for disconnected operation have in common? Despite being rather different techniques, all of them share a common piece of design (and, possibly, implementation) as their cornerstone: the CompositeCalls design pattern. All techniques mentioned above are designed for multiple-domain applications. In all of them, multiple operations are bundled together and then sent to a different domain, where they are executed. In some cases, the objective is to reduce the number of domain-crossings. In other cases, it is to allow for dynamic server extension. In this paper, we describe the CompositeCalls pattern and identify eight classes of existing techniques that instantiate it. We, then, discuss the circumstances in which the pattern should and should not be used. Finally, we present some work done with a priori knowledge of the pattern.
This pattern language is targeted at the embedded system level. The implementation target is for the micro-controller in a cost sensitive environment where real time executives are more than can be supported or more complex than necessary. This language describes and details the continual loop or "Carousel" model for control.
A pattern language to deal with Business Resource Management is presented. It covers a great number of applications in business systems, including patterns for resource rental, trading and maintenance, and was designed based on practical experience in information systems development. Existing recurring patterns were applied to form patterns in our language, which were instantiated to this specific domain. The idea has been to make the language as complete as possible in order to be useful for the analysis of a wide variety of applications in this domain. Fifteen patterns are presented together with a diagram showing the precedence for checking the convenience of their utilization. Object models using UML notation are used both to present each pattern structure and a sample instantiation. The pattern language application to practical cases has shown that analysis is easily conducted, as it is a guideline for the work to be done.
This is a pattern language about building distributed component systems. It is made up of three parts, architectural considerations that underlie distributed components, issues in the design and use of distributed component frameworks, and design issues in building distributed components. It is derived from work originally done in the Component Design Patterns patterns from the wiki web.
Software systems, as abstract, non-tangible entities, should be able to be constructed faster and more efficiently compared to tangible objects. However, software systems are actually more difficult to assemble. Tangible objects have discrete components and are usually independent of their environment. Components contributing to the build of a software system are not limited to source code; moreover, they are not always obvious. Software that has been built often cannot be reconstructed later. The software configuration management patterns described here examine and resolve some of the forces regarding the reconstruction of software systems.
When designing the architecture of an interactive system, the challenge is to keep the data model and the functional core that manipulates the data independent of the user interface. However, we usually categorize the rendering function, which translates the data into the form suitable for visual purposes, as the output part of the user interface. In other words, the rendering process of the data and the way to output the rendering result are tightly coupled. This limitation results in the need to render the data once for each user interface whenever the data changes, even in the case that multiple user interfaces share the same rendering result. In this paper, we describe the Document-View-Presentation (DVP) pattern for interactive software systems. This pattern builds on the Document-View pattern and strongly decouples the rendering function from the output of the rendering result. This separation makes it possible to render the data once and output the result in different methods repeatedly. This architecture is especially suitable to those interactive systems with computationally expensive rendering algorithms, such as graphics or image processing systems. Moreover, the DVP pattern also introduces the 3-tier concept into the design of an interactive system to have thin clients, i.e. user interfaces. Such a thin user interface could be distributed to another process or even another machine without a major impact on the system. This capability possibly allows an interactive system to become a Web-based application without much effort.
As systems grow too complex to completely know at the level of individual objects, we need new techniques for manipulating and comprehending large models. The goal of the most ambition enterprise systems is tight integration spanning the entire business. Yet the entire business model for almost any such organization is too large and complex to manage or even understand as a single unit. This paper presents four patterns that enable the modeling process to scale up to very complicated domains.
A domain model architecture must provide a guide to design decisions for the business model that reduce interdependence of parts without reducing their interoperability or synergy and that improve the model's clarity and ease of understanding and analysis as a whole. It must also capture the conceptual core of the system, the "vision".
These goals are addressed through four patterns: "modularity", "unification context", "distillation", and "large-scale structure". These principles, useful separately but particularly powerful taken together, help us to produce good designs even when systems get too big to keep all details in mind.
Design of the business domain layer of object software presents special challenges. Often,the practical problems of design and implementation lead developers to compromise the object model. This weakens the iterative cycle, since the model cannot provide the foundation for the next iteration. This paper is meant to bridge the gap from analysis modeling to design and implementation of the domain, using a set of patterns of successful practices to produce designs that retain a conceptual foundation. Most of these are published in some form, but have not been organized systematically to address this basic problem. These include patterns for constructing objects that express the conceptual model, patterns for creating and accessing the expressive objects, patterns for isolating the domain from other layers, patterns for refining conceptual models so they are more amenable to design, and some auxiliaries that help prevent corruption the model when special situations arise.
The paper also discusses the relationship of the analysis model and design. This distinction insidiously leads many into waterfall development, yet the proper unification of the two is a key to the power of objects in the domain. The goal is to create software designs that powerfully express conceptual domain models and that perform well in the deployment environment.
This analysis pattern describes how to make a reservation for a reusable entity and its subsequent use. Its requirements are expressed by Use Cases and its description uses class models, state diagrams, and sequence diagrams. The pattern corresponds to a minimal semantic unit.
Development of efficient client-server applications involves good knowledge of multithreading and network communication, domains often closely related to the operating system. Therefore, the reusability of components could be limited by some system specific techniques or limitations used in the design. To enhance the reusability and ease of use, it is then very important to decouple communication establishment and initialization from service use in a client-server application. In this way, upgrades are simplified and one can improve, for instance, the message format without knowing the way services work. On the other hand a developer in charge of maintaining or creating a new kind of service does not need to know how the connections are concretely established. The composition of the Reactor pattern and the Acceptor-Connector pattern provides a powerful pattern to handle concurrent requests delivered to a server with the benefit of the separation of concerns between connection establishment and service use. We tried to enhance the portability of this solution by considering a Java implementation of this composition. But the Java language presents significant differences with C++, which lead us to modify the original patterns designed by D. C. Schmidt and to introduce a new pattern based on the Reactor pattern to solve the encountered problems.
A server system acting as a repository of objects available to a variety of unrelated distributed clients is likely to require a means to restrict access based on the identity of the requesting client. Identification and authentication protocols are often missing from currently available distributed object systems. The Authenticator pattern describes a general mechanism for providing identification and authentication to a server from a client. It has the added feature of allowing protocol negotiation to take place using the same procedures. The pattern operates by offering an authentication negotiation object which then provides the protected object only after authentication is successful.
Given the potentially enormous amount and variety of data available in the Internet and other systems, it becomes necessary to filter out part of it for institutional or legislative reasons. We present a filtering architecture that can apply different filtering policies.
This is a design pattern for the client-side implementation of a pipelined request/response protocol. The pattern is an elaboration of the Remote Proxy design pattern presented in the GOF and POSA books. Its intent is to hide the fact that a service is remote and make a remote service convenient to use.
Mobile agents and mobile computing have grown in importance recently. The Supervisor-Worker pattern is an architectural pattern that helps architects solving the problem of protecting the mobile agent from leakage and tampering. The fundamental Master-Slave Pattern is widespread and heavily used in traditional applications. The Supervisor-Worker pattern inherits many of the Master-Slave patterns benefits. It also solves several of the security issues of mobile agents.
The present document addresses problem domains that can be solved using a state exploration system. The goal of a state exploration strategy is to identify a series of operations in order to reach a certain "goal state" from a defined "initial state". State exploration strategies are tightly coupled with the problem domain, however, some common elements could be reused. This pattern provides a solution to common problems encountered in the elaboration of state exploration systems. This pattern does not provide a solution to the time complexity of such problems and is not intended to provide solutions to problems having large state spaces.
The Jini Community is a diverse group of individuals, universities and companies that have a common interest in creating a new marketplace of digital services based on Jini technology. This is a new way of doing business and there are no existing organizations that can be used as a model. This document presents a pattern language to be used to create the initial Jini Community and to evolve it over time.
In software developments, the simple succession of operations can easily be hard-coded. However, to control event driven systems, applications must conform to a well-defined sequence of operations, even simultaneous ones, that depends on a variable environment, on time constraints and on synchronization constraints between several sequences. In that kind of applications, too complex intertwined conditional statements must be avoided as well as blocking wait operations. Conditional statements quickly become complex and thus incomprehensible, particularly when several actions must be done simultaneously, whereas wait statements force all the application in a blocked state. Tasks can provide a solution for these kinds of problems. However, difficulties appear when no tasks support is provided by the chosen programming languages, when the number of parallel working tasks is limited, or when describing and implementing synchronization mechanisms are too complex. Moreover, the global behavior of the application is difficult to understand and deadlock situations can occur. Thus, specifying and reusing a flexible, reliable and on-line modifiable construction that defines sequences of different kinds of parallel actions is an easy, generic approach to this problem. The Grafcet pattern specifies such a construction. Its description in a pattern form not only provides an architectural solution but also a documentation about its use, the reasons for this particular solution, the benefits and drawbacks related to that pattern, the applicability context, etc.
Because of the increasing gap between modern high-level programming languages and existing hardware, it has often become necessary to introduce intermediate languages and to build abstract machines on top of the primitive hardware. This paper describes the ABSTRACT-MACHINE, a structural pattern that captures the essential features addressing the definition of abstract machines. The pattern describes both the static and dynamic features of abstract machines as separate components, as well as it considers the instruction set and the semantics for these instructions as other first-order components of the pattern.
This paper contains a small pattern language for the architecture of programs that process transactions with consistent and not unexpected results.
An examination of the successful techniques that have allowed earlier networks and network elements to be successful must be done to understand how to evolve networks. The patterns presented here describe techniques implemented in many Lucent Technologies switching systems to deal with traffic congestion issues. Handling congestion is one of the key roles of a network management system. Congestion is the term used by telecommunications system designers to describe the situation when the call load exceeds the available resources of the system. These patterns discuss ways that these systems deal with congestion. The approaches can be generally classified as protective or expansive controls. Protective controls reduce the amount of work by restricting access to resources. This protects the system from too much work. Expansive controls allow the system to use additional resources not available to call processing under normal conditions. This expands the possible actions that the system may take.
Shepherding is a important part of the process of preparing patterns to be workshopped at a PLoP conference. Shepherding is a powerful tool that can go beyond grammar and style to the very heart of a pattern. But the quality of shepherding varies widely; some people receive detailed help, while others get only cursory remarks. These twelve patterns form a small language for improving patterns through shepherding. While the patterns approach pattern improvement through the process of shepherding, they are grounded in the basic elements of quality in patterns. Therefore, they can be useful not only for the shepherd, but for the pattern writer as well.
The World Wide Web (WWW) has dramatically changed the look and feel of GUI interfaces, sometimes for the better, sometimes to the user's detriment. There are solutions to the usability problems introduced by the web. This paper presents an initial collection of these patterns. These pattern and others like them endeavor to establish helpful guidelines for developers to use and eliminate the mystery for them and for the end user. These patterns document the human factors implications of frequently used interface elements for applications deployed over the web. Web applications require a much broader range of user input than web sites. Web application development often involves the collaboration of skilled information technology professionals with widely varying backgrounds and terminology. Usability is a critical success factor for successful web applications. We believe that patterns can provide a language for communicating usability concerns among these diverse participants in the development process without hindering the creative elements of web development. The patterns included in this paper are: "Required Fields", "Carrot on a Stick", "What they see is all they get", "Policy Statement", and "Plan B"
Creational patterns, such as Singleton and Factory Method [1], address object construction and initialization, but do not con-sider object destruction. In some applications, however, object destruction is as important as object construction. The Object Lifecycle Manager pattern addresses issues associated with object destruction. Object Lifecycle Manager is also an ex-ample of a complementary pattern, which completes or ex-tends other patterns. In particular, the Object Lifecycle Man-ager pattern completes creational patterns by considering the entire lifecycle of objects.
Alternator is an object behavioral pattern that has two primary purposes: 1) provide a place holder for a group of alternate objects where one alternate is currently engaged in processing and the others are disengaged, and 2) provide a mechanism for switching between alternates, automatically disengaging the old alternate and engaging the new alternate.
The Mayfly pattern describes an implementation approach to constructing interfaces for efficient data structures. In Nature, the mayfly is a creature well known for its short life span. Similarly, for our purposes, a Mayfly is a temporary object that resides on the stack or only in registers (never in the heap). All of its member functions are typically inlined and it is always passed by value. These characteristics make Mayfly objects ideal for providing lightweight interfaces to efficient array-based data structures such as compressed matrices, graphs, heaps, and trees. The Mayfly pattern cuts across several other patterns. For instance, many of the iterators in the Standard Template Library (STL [1, 19]) are Mayflies. Among the Mayflies described in this paper will be some Adapter [3] 1 and Aggregate [3, 14] objects.
There are compelling reasons to produce software for international audiences. The needs of users from diverse cultures must be taken into account if the software is to be usable and useful. Due to differences in language and user psychology, it is necessary to produce multiple versions of the same application. This leads to a large number of technical and non-technical issues. The Planet pattern language addresses addresses the high-level issues which developers encounter in specifying requirements for international software. It helps developers document and access information about target cultures and shows them how these resources can help them to customise functionality and user-interface design.
Interest in using and creating patterns has been growing throughout the software development community since the "gang of four" first proposed the concept in 1994. However, much of this interest exists only among individuals. Unfortunately, very few organizations have embraced patterns. This is most likely due, at least in part, to the fact that patterns are viewed by many organizations as a proactive effort whose value cannot be easily quantified and observed.
The spark for patterns in an organization often begins with one person or a small group who has observed and/or heard about the benefits. They may have used a pattern or two, explored the web, read books or journals, or have attended one of the many conferences where patterns are a topic of conversation. However, despite all of the web pages, literature, and discussion, there is little information to help individuals lead an effort towards evolving a patterns culture.
This topic was first considered by Linda Rising and David DeLano of AG Communication Systems during their Introducing Patterns into an Organization workshop at OOPSLA'96. Since this event, AGCS found that introducing patterns is an instance of introducing a new technology so they have updated the collection to Introducing Technology into the Workplace. While these patterns form a strong and extremely useful foundation, the emphasis is on the introduction of a technology, with only a few patterns considering how one can sustain (Keep It Going) the momentum begun during the Grass Roots introduction. Keeping the momentum going is vital if an organization is to achieve a patterns culture.
Therefore, the patterns presented here expand on the "introducing patterns" work with the addition of patterns to facilitate introduction and to help one or more individuals move an organization towards evolving a patterns culture.
A modern software application seldom exists in isolation but instead within a set of related applications, such as a product line or corporate information system, with a shared context. Addressing such applications one at a time as the traditional application-oriented approach does, treats many of the common aspects of the context independently and repeatedly with each application. This approach results in higher costs for duplicated work, but more importantly it inevitably produces redundancy multiply defined data and logic and hinders the effective management of complexity and variation, all of which impair quality and reduce value. The Composable System Pattern Language addresses how to reduce such problems by recognizing sets of overlapping products and components as being a single system and optimizing the system as a whole. This pattern language currently documents nine patterns, but suggests more than a dozen others that may be pertinent.
We are involved in an ongoing effort to design a pattern language for parallel application programs. The pattern language consists of a set of patterns that guide the programmer through the entire process of developing a parallel program, including patterns that help find the concurrency in the problem, patterns that help find the appropriate algorithm structure to exploit the concurrency in parallel execution, and patterns describing lower-level implementation issues. The current version of the pattern language can be seen at http://www.cise.ufl.edu/research/~ParallelPatterns. In the current note, we present three selected patterns from our pattern language, selected from the set of patterns that are used after the problem has been analyzed to identify the exploitable concurrency. The EmbarrassinglyParallel pattern is used when the problem can be decomposed into a set of independent tasks. The SeparableDependencies pattern can be used when dependencies between tasks can be pulled outside the concurrent execution by replicating data prior to the concurrent execution and then combining the replicated data afterwards. The GeometricDecomposition pattern is used when the problem space can be decomposed into discrete subspaces and the problem solved by first exchanging information among subspaces and then concurrently computing solutions for the subspaces.
Matcher-Handler is a behavioral pattern that defines a generalized mechanism for delivering spontaneously generated data to one or more data handlers throughout an application in a loosely coupled way. This pattern explicitly separates the responsibilities of data identification (matching) from data handling. The pattern borrows structure and behavior from the Observer and Strategy patterns defined in "Design Patterns: Elements of Reusable Object- Oriented Software." A barcode reader attached to a cash register is used for an example of a data source for spontaneous input data. The text identifies the strengths and weaknesses of the pattern and describes several variations of the pattern that have shown to be useful in actual projects.
The need often arises to write simple, possibly one-shot behaviors that do not seem to belong in the interface of any class. The behavior can be assigned a name and encapsulated in a method in a speci c class, but the given name would convey little information beyond what can be inferred by directly looking at the code. In such cases it is better to express the behavior as Functions, unnamed behaviors expressed as blocks in Smalltalk and inner classes in Java.
The following collection of patterns and one anti-pattern target developers and their managers who are involved in creating and demonstrating concept prototypes and using the ubiquitous GUI-development tools to make them (such as Visual Basic, Delphi, and Web-based development tools, like Sapphire Web). With an increasing emphasis on quick product turn-around and fast to-market pressures, these concept prototypes feed the illusion that development cycles can be drastically shortened because, "the GUI is already done!". These patterns addresses how prototypes can be used as a tool to inform the developers, managers and clients, and even venture capitalists, rather than an arbitrary baseline to which all further development must conform.
Envoy is a pattern language for simulating an object-oriented programming style in a statically-scoped functional programming language such as Scheme. Object-oriented programming and functional programming are alternative ways to address the difficulties of writing and maintaining large programs. Both styles help to solve the problems that result from global data: functional programming by prohibiting global state, and OOP by encapsulating global state into more manageably-sized units.
In the functional style, a program never changes the value of a variable. Indeed, there is no sense of "variable", since symbols are really names for values, not slots that hold values. But this style is uncomfortable when dealing with problems more naturally seen as operating on data than as computing values. Rather than forcing the solution to such problems to fit the style, functional programmers often step outside the style to program with state. This pattern language describes structures that a functional programmer using Scheme or a similar language might use to write programs that maintain state.
The ACEE Architecture Pattern aims to aid in constructing the software architecture of Computer-supported Automation and Control Systems (CsACS). It consists of four components: Acquisition, Computing, Execution and Expression. The Acquisition component is responsible for acquiring signals from the external objects. In terms of assigned control rules and acquired signals, the Computing component makes the control decisions. The Execution component is in charge of fulfilling the control decisions. The Expression component expresses the status of relevant external objects and the system control decisions in diverse forms. The Broadcaster/Listeners mechanism (also known as Observer design pattern)is applied to accommodate the communications between them.