Back to EuroPLoP Writers Workshop page.
Eydun Eli Jacobsen, Palle Nowak
We present a pattern language for building virtual machines using a domain specific framework. The patterns are organised so that the first patterns deal with concepts in the domain of virtual machines and later patterns are more concerned with implementation details. Even though the patterns document the use of a particular framework, they are formulated general enough to serve as general guidelines (principles and abstractions) when developing simple virtual machines. A framework prototype implemented in BETA is available.
Andreas Rueping
An object-oriented framework is a collection of abstract classes that
represent the architecture of a generic application. A framework often
comes with a library that offers numerous implementations for the
abstract classes. The fact that there are many concrete components
to choose from is what makes a framework so flexible.
However, not all concrete components may go together well with all
other concrete components. Maybe there are constraints between some
of the components from the framework's library. To this end, a conflict
between flexibility and consistency occurs. We want our framework to
allow for asmany variations as possible, yet we also have to ensure
that only valid application programs can be instantiated.
We present a pattern language for framework design that addresses this
issue. We present four patterns that share the common goal of achieving
as much flexibility as possible while preserving consistency at the
same time.
Leonor Barroca, Pedro R. Henriques
This paper presents the definition of a generic framework for representing the behaviour of reactive systems and reasoning about timing properties. We defend the need of a dual approach that uses a notation for the specification of behaviour (preferably a graphical one), and a temporal logic to express formally, and reason about, this behaviour. This combination of notations forms the basis of a generic framework that can be instantiated for different choices of notations. Two instantiations of the framework, illustrating its use, are discussed. We use Design Patterns to describe in detail one of the instantiations (ArchSM method).
James Noble
To design a program, first find your objects. Unfortunately, the right objects are not easy to find, and as a result most programs are not as well designed as they could be. The patterns in this language describe how objects can found within existing programs. By using these patterns, programs and designs can be made more simple, more general, and more easy to change.
Charles Weir
Design and architecture are usually represented as a solo activity. Yet software development is almost invariably a team process. This paper describes patterns which leverage the individual strengths of several development team members to get a better result than one single designer could achieve alone.
Lorraine L. Boyd
There are two main types of persistent objects in large scale business systems: static and association objects. Static objects are tangible items which contain inherent identifying characteristics over their lifetime. Examples of static objects are product, customer and employee. Association objects represent something which happens at a point in time, associating two other objects. The objects being associated may be either static objects or other association objects. Association objects have attributes inherent in the relationship such as date, time or cost, which change when a new association is formed. Examples of association objects are order, customer contact, room assignment, and work assignment. This paper discusses three patterns for association objects and approaches for applying them to large scale business systems during the requirements definition or analysis phase. This paper then presents a pattern language consisting of three association patterns and which can aid in finding and defining business needs during these early stages of system development.
Paul Dyson and Bruce Anderson
As our understanding of how we build software grows, we document recurrent design decisions in the form of patterns. As our understanding of each pattern grows, we extend and refine these patterns so that the advice they give is more concrete and comprehensive. We present seven patterns that refine and extend the State pattern found in the GOF book. The refinements are concrete advice for some of the decisions mentioned, but not dealt with, in the original pattern; the extensions are decisions not mentioned in the original. The splitting of the one large pattern into a pattern-language makes it more accessible and easier to understand.