Writers Workshop D - Dvorjak/Duran Duran

Context Encapsulation - Three Stories, a Language, and Some Sequences

This paper presents a small pattern language, CONTEXT ENCAPSULATION, based on dividing up the ENCAPSULATE CONTEXT pattern by Allan Kelly. Four patterns for encapsulating execution context in statically typed languages are described, allowing a component to be sufficiently decoupled from the code and assumptions in the environment in which it was written. It connects these patterns into the kernel of a pattern language, linking them to one another as well as to patterns outside the language. It presents pattern stories that illustrate the language by example and offers pattern sequences that highlight more generally how the pattern language can be animated. The historical background and motivation for the themes in the paper are also introduced. This paper concludes with a section of notes that readers should consider appendices, and should be read only if the subject matter appeals: some reflections on the wider pattern relationships the pattern language can draw on; a simple record of how the pattern language was written; and a brief and formal reflection on pattern sequences, pattern languages, and the nature of design.

Indecisive Generality

When a project fails to clarify important issues, to complete the analysis, or to make clear statements where the system is meant to be extensible and where it needs to be stable, architects tend to answer the indecisiveness in a technical way: general and complex solutions. This diagnosis pattern shows why unmanaged complexity is a major risk to the project's success, how it creeps into a project and how to detect it. Furthermore it gives techniques how to enforce decisions and limit the generality.

Architectural Patterns Revisited - A Pattern Language

Architectural patterns are a fundamental stone in the field of software architecture: they offer well-established solutions to architectural problems, help to document the architectural design decisions, facilitate communication between stakeholders through a common vocabulary and assist in analyzing the quality attributes of a software system. Regrettably, finding, and applying the appropriate architectural patterns in practice still remains largely ad-hoc and un-disciplined. This is due to the difference of opinion with respect to the 'philosophy' and granularity of architectural patterns, as well as the lack of a comprehensive catalogue. In this paper we attempt to establish common ground in the architectural patterns community by proposing a pattern language that acts as a superset of the existing architectural patterns collections and categorizations. This language is particularly focused on establishing the relationships between the patterns and performs a categorization based on the concept of 'architectural views'.

A Pattern for Formal Verification of Properties of Large Systems

Formal verification (e.g., model checking or theorem proving) constitutes a far more thorough examination than conventional system testing, but tends to become overly costly (or even infeasible) with increased complexity of the system under test. A common strategy to handle large systems is to consider a simplified model, which reflects only those aspects of the original system that are relevant with respect to the property that should be verified. The CEDAR pattern describes a way to obtain an appropriate simplified model by iterative, counterexample-driven refinement of an initial, extremely coarse abstraction.

A Pattern Language for the Network of Things

Nowadays production and distribution processes are controlled to a large extend by information processes. Interconnecting the flow of material and of information promises increasing efficiency and quality of business activities. Inproduction and distribution processes an identification of "material things" is necessary. Several solutions for automated identification have evolved like Barcode. Radio Frequency Identification RFID is going to replace or augment traditional automated identification techniques. Data can be read from and written to RFID tags. Thus ''things'' can carry information about them like their ID and product description. Widespread application of this RFID tags will reveal approaching challenges like coping with an enormous amount of data distributed on single ''things''. This pattern language is a starting point dealing with problems information technology is going to face.

More Patterns for the Generation, Handling and Management of Errors

As systems become more complex it is increasingly difficult to anticipate and handle error conditions in a system. The developers of the system must ensure that errors do not cause problems for the users of the system. In a previous paper, a collection of patterns for such distributed error handling was explored. As this collection was refined, two new patterns emerged: Hide Technical Details from Users and Unique Error Identifier. This paper retains the same context and but is focused on obtaining feedback specifically on these new additions

Maintainability Patterns

Maintainability of products lies in two areas - the technical and the human. To maintain a product and provide assistance to the customers using it one needs to have indicators that will help glean some insight to the way the system works, and to be able to work as efficiently with the customers since they can also provide valuable information that can help in solving problems that may arise during the time the system is used. One of the biggest challenges in providing good support to a product is the relationship with the customers. We referred to some of the issues in previous patterns, such as What IS the Problem?, Re-State the "obvious" and What Did You Do Before That? (EuroPLoP2003). Face to Face Meeting First presented hers continues on the issue of creating good communication with the customer. On the technical side of maintainability we present 3 patterns: Gene Roddenberry refers to the looking forward phase of the ongoing development of a product. The other two patterns, Total Events Counter Alarm and Protected Counters suggest ways to prevent or indicate problems on their "brewing" stages, before they become critical.