Papers

The following papers were discussed at the writers workshops of EuroPLoP 2003.

Workshop A (Alvar Aalto)

Pippin Barr
	Interface Ontology: Creating a Physical World for Computer Interfaces Interaction patterns are often used to present existing knowledge about user-interfaces in a generalised, but well-defined manner. Such patterns provide insight into the practices and assumptions of the design community. This paper presents a small number of patterns based on the concept of physical ontology. That is, the paper puts forward patterns in which computing concepts in a program are explained to the user through basic physical metaphors. The end result is an initial foray into uncovering the physical basis of the user-interface.
Charles Weir, James Noble
	A Window in your Pocket: Some Small Patterns for User Interfaces Pocket computers (palmtops, sub-sub-notebooks, PDAs, organisers, communicators, tricorders) are becoming more common, and real alternatives to PCs for many purposes. Unfortunately, because they are physically smaller, user interfaces for pocket computers are much harder to design than those for larger machines. This paper presents some patterns for designing user interfaces for pocket computers. Programmers and designers can use these patterns to design interfaces that will better suit small computers, resulting in applications that are more usable.
Charles Weir, James Noble
	The Hitchhikers' Guide To Google The web is big. Really big. This is good because the Web now encompasses the entire history, culture, science, and achievements of the human race, not to mention JPEGs of every romantically eligible member of that race under the age of 35. This is bad because it is now too big to find anything. The Hitch-Hikers Guide to Google is a collection of patterns that will be your guide through the Internet. By reading these patterns, you can, make friends, improve your lifestyle and experience excitement, adventure, and really wild things. When one reader didn't read these patterns, he dropped his computer in a puddle and couldn't search the web any more. Share and Enjoy.
Till Schümmer
	GAMA - A Pattern Language for Computer Supported Dynamic Collaboration The GAMA pattern language provides patterns for supporting dynamic teams with computer technology. In this document, a small subset of the GAMA language is presented that deals with spontaneous group formation based on common interests. Note to Writers Workshop: This paper presents the first patterns of the GAMA pattern language. I am aware of the fact that the language is already quite long. My primary interest for discussion would be in the coherence of the patterns. I would like to ask you to focus on the problems, the solutions, and the .gures (just to get a better idea of the solutions). You may skip the patterns "Elephant’s Brain" and – if necessary – "Gaze Over the Shoulder". Any additional feedback is appreciated, but might go beyond the workshop’s possibilities.
Paris Avgeriou, Andreas Papasalouros, Symeon Retalis
	Patterns For Designing Learning Management Systems Learning Management Systems are sophisticated web-based applications that are being engineered today in increasing numbers by numerous institutions and companies that want to get involved in e-learning either for providing services to third parties, or for educating and training their own people. Even though the construction of such systems has been taking place for many years, they are still designed and developed from scratch. The reason is that experience from previous Learning Management Systems, is not codified or documented, resulting in forcing the development teams to "re-invent the wheel". This paper presents an approach of recording design experience in the form of design patterns for Learning Management Systems and aims at developing a pattern language for these systems.
Joe Bergin
	Two Pedagogical Patterns This paper contains two patterns that are unrelated except that they are both pedagogical patterns. The first, Student Tasks First, is a candidate for inclusion in the Patterns for Active Learning and the second, Differential Grading, is a candidate for inclusion in Feedback Patterns. Both involve course design, however. Student Tasks First tells how to begin the course design process and Differential Grading gives advice about how to design the grading/assessment structure. This advice is consistent with the Bloom Taxonomy.
Diethelm Bienhaus
	Some Pedagogical Patterns from a System-centered Approach This collection presents patterns comprising fundamental problem / solution pairs captured from a system-centered respectively cybernetic approach. Specific solutions for the field of learning and teaching are derived from the general solutions. The quest for general principles and concepts applicable to different systems - biological, ecological, economical, social or technical - is key motivation in cybernetics. Cybernetics as the science of relationships, control, and organization in all types of objects. Patterns of this collection focus on identifying problem / solution pairs in systems from different domains: biology, medicine, cognitive science and engineering. The identified solutions are transferred to the problem area of learning and teaching. This pattern collection extends the patterns approach: problem solution pairs different domains are presented under a system-centred and pedagogical focus. Hint for Writers Workshop: The paper is too long to be workshoped in depth. The author would particularly appreciate feedback concerning: The chosen approach itself: it is helpful trying to transfer solutions from other domains to teaching topics? What can readers learn from it? Do the patterns just describe common observations or are they helpful for learners and teachers? Is this just a collection or a language, or should it be seen as a starting point to build a language?
Jutta Eckstein, Mary Lynn Manns, Helen Sharp, Marianna Sipos
	Patterns for Teaching Effectively This pattern language in progress proposes some successful techniques to assist with teaching and learning. The patterns were revised and rewritten in Alexandrian form in order to support the integration into a pattern language. Further patterns will be submitted to future conferences of the PLoP series. Whereas the pattern languages developed so far are all focusing on learning, this collection focuses instead on teaching effectively.

Workshop B (Filippo Brunelleschi)

Frank Buschmann, Kevlin Henney
	A Distributed Computing Pattern Language In this paper, we introduce to a possible pattern language for distributed computing and present selected patterns of its component partitioning and resource management patterns. We distilled this language from our own experiences in realizing distributed systems as well as from the distribution patterns that skillful software architects, designers, and developers contributed to the software community. The language has been used to develop many real-world distributed object computing middleware and applications. You can use it with your colleagues and project team-mates to guide the design of new distributed systems and also to improve and refactor existing ones.
Wolfgang Herzner
	Message Queues Three Patterns for Asynchronous Information Exchange Information interchange between concurrent processing elements like threads or tasks is one of the fundamental issues in information processing systems. In many cases, the information transfer needs to occur asynchronously, i.e. the consumer must be enabled to receive the information at some later point in time than the producer provides it. (Of course, this may apply to data transfer within a sequential processing element as well.) Messages and their intermediate storage in queues are one of the most common solutions to this problem. This paper describes three patterns, addressing different combination of forces: the simple FIFO-Queue, the Selectable Message Queue, and the Smart Queue.
Michael Kircher, Prashant Jain
	Resource Lifecycle Manager Building distributed systems is challenging. Making distributed systems robust and scalable is even more challenging. The most important aspect of making distributed systems robust and scalable is how resources are managed. This pattern describes how the management of the lifecycle of resources can be decoupled from their use. Using the Resource Lifecycle Manager pattern frees the resource users from the responsibility of managing the lifecycle of the resources that they use. The Resource Lifecycle Manager therefore allows greater control over the lifecycle of the resources thus yielding better managed and more robust systems.
Michael Kircher, Prashant Jain
	Caching The Caching pattern describes how to avoid expensive re-acquisition of resources by not releasing the resources immediately after their use. The resources are kept in memory and are re-used to avoid having to reacquire them. The Caching pattern is different from the Pooling pattern since Caching maintains the identity of a resource in memory; Pooling relies on a resource becoming anonymous and possibly gaining a different idenity later.
Markus Völter, Michael Kircher, Uwe Zdun, Michael Englbrecht
	Patterns for Asynchronous Invocations in Distributed Object Frameworks OO-RPC middleware typically provides synchronous remote method invocations from clients to server objects. In some scenarios, asynchronous behaviour is necessary, though. This collection of patterns introduces the four most commonly used techniques in this context. fire and forget describes best-effort delivery semantics for asynchronous operations that have void return types. sync with server looks the same from the client’s point of view, however it is able to notify the client (by throwing an exception) in case the delivery of the invocation to the server application fails. poll objects provide clients with means to query the distributed object framework whether an asynchronous reply for the request has arrived yet, and if so, to obtain the return value. Last but not least, result callback will actively notify the requesting client of the returning result..
Markus Völter
	A Collection of Patterns for Program Generation Generation of source code is becoming a more and more important tool for software engineering, especially in the context of model driven development and MDA. While it is possible in theory to "generate code" just using printf, this approach is insufficient in all but the most trivial cases. However, there are several alternatives. This paper introduces a set of patterns that describe the most commonly used source code generation techniques. That can be used for model transformations, model-to-source generation or source code transformation. It also contains large amount of examples that show how different tools realize the patterns.
Louis-Pierre Gagnaux
	Complex Interface Pattern This pattern describes how to design an application in layers, using an abstract interface layer of classes with common behaviour and common implementation. It addresses the following issues: - how to implement a family of classes with a common interface and a common implementation - how to implement a layer, which is completely independent of the client using it, so that the client can decide at run-time which layer it wants to use. This paper also gives an real example, where I used this pattern to implement a wrapper layer, to wrap all the cumbersome SNMP (simple network management protocol) semantics in a library, in order that applications can use a simple interface to notify its alarms to a standard SNMP Manager without having to deal with SNMP.
Kristian Elof Sørensen
	Window to the World You are building a system that interacts with a remote system. You intent to test this interaction. <Data Manipulator> deals with the problem of testing your systems handling of interactions that strays away from the well behaved documented way of behaving and into the land of the faulty communications. <Interaction Pretender> allows you to test your systems interaction with other systems that are still on the drawing board when you perform your tests, or are unavailable for test for a number of other reasons. It is an extension of <Data Manipulator>. <Window To The World> solves a couple of problems that comes up as a liability in both of the preceding patterns, namely how to switch in between interacting with the real remote system and various <Data Manipulator> and <Interaction Pretender> implementations, and how to increase the likelihood that results of tests made with implementations of the latter two, are valid for interactions with the real system as well. <Life Threatening Test> uses <Interaction Pretender> and therefore also <Data Manipulator> and <Window To The World> to solve the problem of testing a system where bugs can lead to destructions in the physical world up to and including killing humans.
Klaus Marquardt
	Performitis Large software systems and projects develop a high degree of internal complexity by their sheer size, and are bound to trouble. Experienced software architects have learned to detect problems before they have become critical, and apply a variety of different measures in different situations. This knowledge of early symptom recognition and selection of a reaction can be collected in the form of diagnoses and therapies. Performitis is a kind of architectural approach that arises from an overly narrow focus on performance during development. While it appears a technical issue at first, the examination discovers that its foundations are located in people and process issues. Accordingly, Performitis should be treated by technical as well as team and process therapies, where a combination of both is typically most successful.

Workshop C (Le Corbusier)

Ben Elsinga, Aaldert Hofman
	Security Taxonomy Pattern Language The intent of this pattern is to give you guidance and support in establishing a consistent and coherent set of security aspects that have to be addressed in enterprise security. In day-to-day life we experience that people address information security only in a limited way. That might be because they do not oversee the broadness of the information security field or because they just focus on products or techniques. This paper introduces a few patterns that contribute in solving this problem by providing a consistent framework of terminology along a few distinct dimensions: Goal of security, Nature of safeguards and Effect of safeguards.
Ben Elsinga, Aaldert Hofman
	Security Paradigm Pattern Language This pattern language describes a number of so called security paradigm patterns. A security paradigm in this context is defined as a high-level model to express the way the organisation thinks about security. Organisations often lack a clear vision on how to approach the security challenge at the corporate and enterprise level, based on business drivers and the actual context. The real problem is that the language to express the security on strategy level is missing. This paper provides this language. This paper defines a number of security paradigms grouped in a framework of mindset, execution and architecture paradigms, including their interrelationships. Hint for Writers Workshop: In case this paper is to long for a full review, please focus the chapters 1, 2 and 3 (12 pages). The rest is background information for people who are interested and who want to know more about a specific paradigm.
Eduardo B. Fernandez, John Sinibaldi
	More patterns for operating systems access control We present architectural patterns for access control in operating systems. These complement the patterns that we introduced in a previous paper. The patterns control access to resources represented as objects and include patterns for authentication, process creation, object creation, and object access.
Haralambos Mouratidis, Paolo Giorgini, Markus Schumacher
	Security Patterns for Agent Systems Security is an important issue in the development of agent-based systems. However, a careful analysis shows that the common approach towards the inclusion of security within a system is to identify security requirements after the definition of a system. This approach has provoked the emergence of computer systems afflicted with security vulnerabilities. The use of patterns can provide a valuable solution in the development of secure agent based systems. In this paper we present a pattern language for secure agent systems that, currently, consists of four patterns.
Markus Schumacher
	Firewall Patterns In this paper we provide three firewall patterns. The firewall pattern describes how access to internal networks can be restricted in general. It shows the basic problems and indicates a general solution. The other two patterns are more specific variants which are usually used in order to implement access control at the network border. This patterns are part of an initiative to integrate security-related patterns into an overall security pattern system.
Peter Sommerlad
	Reverse Proxy Patterns Implementing an application-level server-side proxy can result in a large number of positive consequences. However, the aspects of network security, single sign on and integration imply different forces upon such a reverse proxy. Attaching the surrounding infrastructure can show additional roadblocks for a successful deployment. These patterns try to structure the many forces, regarding the different aspects into several patterns, that can be successfully studied to understand reverse proxy solutions and hopefully applied to design reverse proxy applications.
Paul Dyson, Andy Longshaw
	Patterns for Highly-Controllable Internet Systems Many large-scale internet-based systems have similar architectures. Such similarity provides an environment rich for pattern mining. This paper describes two small pattern languages that, between them, consider the common structures introduced to improve the overall control (manageability and security) of large-scale internet-technology systems. This paper is a companion to "Patterns for High-Availability Internet Systems" submitted to EuroPLoP 2002 and forms part of the same higher-level pattern language.
Titos Saridakis
	Design Patterns for Fault Containment Fault containment is an importance constituent of fault tolerance. Means for fault containment allow a system to limit the impact of manifested faults to some predefined system boundaries. This document presents some of the best known techniques for fault containment formatted as design patterns. These patterns are elicited from the areas of self-stabilization, specification closure and fault tolerant OS kernels. The presented fault containment patterns are: the Input Guard pattern which confines an error outside the guarded system boundaries; the Output Guard which confines an error inside the guarded system boundaries; and the Container pattern which is the fault tolerant counterpart of the well-known Wrapper pattern and which combines the properties of the Input and Output Guard patterns.
Ewald A. Kaluscha, Sonja Grabner-Kräuter
	Towards a Pattern Language for Consumer Trust in Electronic Commerce Since the mid-1990s the concept of trust has received increasing attention in the field of e-commerce and was recognized by scholars as one of the main reasons why a high number of consumers are still reluctant from buying on the Internet. Against this background the purpose of this paper is to adopt the idea of patterns for the enhancement of trust in e-commerce. Based on managerial implications derived from a recent review of eleven empirical studies on online trust we present a set of sample patterns for the design of trustworthy Internet storefronts, a first step towards a new pattern language.

Workshop D (Francis Duffy)

Aaldert Hofman
	Reducing complexity in Boolean expressions The intent of this pattern is to enable business analysts, designers and programmers to reduce complexity in Boolean expressions in design and program, thus improving quality of programs. In complex expressions humans tend to lose comprehension and oversight of the expression. The smart use of binary algebra allows us to reduce complexity. A complex statement is reduced to a set of single statements that will not be nested. The result of each single statement is given a certain value. The answer to the overall complex expression will be based on the sum of all these values.
Allan Kelly
	Encapsulated Execution Context Where several pieces of common data are needed by diverse parts of a system forces may arise which lead to global data or long parameter lists on function calls. Both results detract from encapsulation, maintainability and impede the use of other patterns, e.g. Command, Chain of Responsibility. The solution is to encapsulate this data in a context object which specifies the execution context for the system. State data is factored into this object so that other objects may be stateless, or contain only data relevant to their role. Systems which have been designed on polymorphic principles - either run-time or compile-time polymorphic - can benefit from this encapsulation which becomes their connection to rest of the system. More traditional systems benefit because ripple effects produced by over long parameter lists (which break encapsulation) on function calls are reduced.
Gustavo Patow, Fernando Lyardet
	Open Arguments How do you allow individual functions to augment or change their state (arguments) at runtime? What should be done when a procedural interface is needed with a generic purpose parameter-passing mechanism? This is especially true when creating plug-ins that need an undetermined number of parameters with undetermined types. A runtime mechanism for accessing, altering, adding and removing arguments or parameters at runtime must be provided. The best way to go through is to define a class ParamBlock which is a simple dictionary of pairs, which is the only real parameter of the implemented procedures.
Uwe Zdun
	Patterns of Tracing Software Structures and Dependencies Tracing the structures and dependencies in existing, formal source documents, such as code or design specifications, is required for many different reengineering tools, programming languages and language extensions, self documentation, visualizations, and other software engineering tasks. There are many recurring techniques used in these fields to gather the relevant trace information. This paper presents a pattern language covering basic techniques in this area, as well as technology projections and known uses. Hint forWriters Workshop: As you may have noticed, my Paper at EuroPLoP (Patterns of Tracing Software Structures and Dependencies) is a bit longer than 10 pages. So in order to focus your review activities, may I please ask you to mainly provide feedback on the patterns themselves. If you want to focus on specific patterns, I would like to ask you to review Parse Tree Interpreter, Trace Callback, Hook Injector, Invocation Context, Metadata Tags and Partial Parser more deeply. (Of course I'll be happy about feedback on everything else, too :-) )
Stefan Hanenberg, Arno Schmidmeier
	Idioms in Aspect Oriented Programs For concrete usage scenarios there are different options of how to use AspectJ's features, and these options deeply impact the opportunities for further evolution of both base classes and aspects. Aspects can use aspect oriented as well as object oriented features. The combination of these mechanisms provides new powerful mechanisms. Idioms are required to guide the AspectJ adopters through this frontier of programming.
Rilla Khaled
	Software Visualisation for Java Programs in InspectJ Visualisation is a powerful tool for explaining how programs work, however it is often overlooked as a tool for aiding understanding. This paper presents a pattern language for making program-specific visualisations of Java programs using the InspectJ framework. InspectJ is a visualisation framework that uses AspectJ to monitor programs at run-time. These patterns step through the process of building a visualisation from start to finish, featuring a running example of the development of a visualisation for a simulation program. After reading these patterns, you should be able to use InspectJ to create visualisations for your own Java programs.	D6_KhaledR.doc (395KB)
Simon Key, Michael Pont
	An Assembly-Language Scheduler Pattern This pattern describes a new version of one of our previous patterns (CO-OPERATIVE SCHEDULER, from Pont, M.J., 2001, "Patterns for Time-Triggered Embedded Systems"). This new pattern - ASSEMBLY-LANGUAGE SCHEDULER - is designed for use in high-reliability embedded systems with very limited memory resources.
Michael J. Pont, Andrew J. Norman, Chisanga Mwelwa, Tim Edwards
	Towards a pattern-based design methodology for embedded systems In this paper, we present four new patterns which, together, are intended to form the core of a simple design methodology for embedded systems. The new patterns are DESKTOP-SERIAL PROTOTYPE, ENVIRONMENT MODEL, SINGLE-PROCESSOR PROTOTYPE and HEARTBEAT LED. Note to writers workshop: If you can't handle the whole paper, please focus your feedback on the first pattern "DOS Scheduler".
Hans Werner Pohl, Jens Gerlach
	Using the Bridge Design Pattern for OSGi Service Update In the OSGi framework, components cooperate by sharing service objects. The suggested way to replace a service by a newer version consists of updating its containing components which requires a temporary shutdown of the component. Special care must be taken to avoid dangling references to old service instances. As this appears to be an overly expensive strategy, we describe the use of the well-known Bridge design pattern to decouple service replacement from component updates. Instead of registering services only references to instances of automatically generated bridge classes are registered. This solves not only the problem of dangling references but also avoids stopping and starting dependent bundles.

Workshop E (Gustave Eiffel)

Mark Prince, Andy Schneider
	Excerpts from Post Modern Technical Leadership Patterns This paper presents four patterns; InformationIsKing, CoreSampling, CodeSurfing, and TakeCareOfTheSmallChange. CodeSurfing describes a mechanism for parsing changes in a code base to ensure expectations are met. CoreSampling describes a mechanism for detailed information analysis of a developers work. The paper also covers a management aspect of Technical Leadership -TakeCareOfTheSmallChange. This mixture was deliberately chosen to reflect the mix of activities a technical lead undertakes.
Alberto Rodrigues Silva
	Towards the Organizational Engineering Pattern Language Part 1: Contact, Person and Organizational Patterns In this paper we discuss the motivation for a organizational engineering pattern language. We also propose a set of organizational patterns, maintaining a tighter connection with the real world. In the real world there are many pattern behaviours and good solutions, that if transported to organizational paradigm will increase not only its capabilities and potential, as well as, possessing more expressiveness since they translate familiar concepts, make this emerging approach more easily accepted by the involved community. In particular, we propose the following organizational patterns: CONTACT, PERSON, ORGANIZATION, BUSINESS PROCESS, INFORMATION SYSTEM, and VISION, MISSION AND GOAL. However, this is the first of a two paper series, in which we focus on the CONTACT, PERSON and ORGANIZATION patterns.
Amir Raveh, Ofra Homsky
	Technical Support Patterns Introduction The enclosed patterns are trying to focus on a phase of software development that is usually the least discussed - the maintenance phase. They provide a set of tools for resolving problems found in software systems, and build on complementary design practices. Motivation Once software begins its useful life, it also meets the operating environment and the users. This is where problems start manifesting, starting from installers and users who fail to understand what those software engineers want them to do, through environmental problems such as resource shortages, all the way through to errors in the software. The purpose of this pattern language is to close the loop: in many cases the software development process is described as one beginning with initial concept and design and ending as people start using it. The technical support of software systems calls for many skills, both in the technical domain and in the human interaction domain. Closing the loop also means that software should be designed to make problem resolution easier. This is where the design for maintainability patterns merge with this language. Contents The patterns tackle the resource problem from developing awareness of software developers to maintenance, building software to facilitate troubleshooting, all the way to preventing, resolving and isolating problems. Hint for Writers Workshop: We are aware of the fact that the language contains fourteen patterns. We believe that including fewer patterns would have left the language full of holes, and lacking. Since we value your feedback, we would like you to focus it on these issues: 1. The coherence and completeness of the language as whole. Reading the Introduction section would be the easy way to gain this perspective. 2. Feedback on the patterns included in the paper. We appreciate any comments and feedback you have on all of them, but since this might go beyond the possibilities of the workshop, we ask you to focus on the last seven patterns (Fresh Perspective to Review Checklist). 3. Known uses Finding documentation of the technical support of software was quite a challenge for us. You can see we came with examples from web sites created by frustrated users and customer support people, as well as literary sources (such as James Harriot). If you have seen any of these patterns applied, or know of quotable cases where a pattern was applied, please let us know...
Neil Harrison
	Advanced Writing It has been nearly ten years since software people started writing patterns. In that time, we have grown a lot, and have become somewhat better at expressing our ideas as patterns. Over the years, we have devoted much time and energy to improving our writing -- we have paid special attention to readability, form, and flow. In fact, we have raised the standard of readability for all software publications. But content and substance are not where they should be. People have justly accused many of our patterns of being rather superficial. For patterns to move to the next level, we need to work on substance. This workshop will focus on improving the substance in your patterns. It will help you know what to look for in both your own, as well as others' patterns.
Armin Scherz, Wolfgang Zuser
	A Pattern Language for Software Quality Assurance in Small and Medium Enterprises Small and medium IT enterprise are forced to compete against large companies in many cases. It is an unequal competition. While SMEs are usually characterized by restrictions concerning budget and personnel, large companies have many possibilities concerning personnel selection or recruiting and monetary flexibility. A working software quality assurance is one of the key success factors for SMEs in this situation. The existing restrictions in SMEs do not allow an QA-department on its own but usually they have excellent software engineers. They are concerned about the necessity of QA and they are able to do good QA within projects. This pattern language presents a set of patterns, which can be applied to IT projects in SMEs without specialized QA personnel. The patterns are divided into foundations patterns, which form a basis for action patterns, and action patterns, which are directly applicable to IT projects. The patterns can supply a minimal set of QA activities. Together with excellent software engineers they are sufficient to produce high quality software.
Haitham Hamza, Mohamed E. Fayad
	The Negotiation Analysis Pattern Negotiation is a general concept that has many applications in various contexts. This paper introduces the Negotiation analysis pattern. This pattern aims to provide a model that analyzes the core concept of the negotiation notation independent of any application.In order to achieve this goal, Negotiation pattern is built based on the concepts of Stable Analysis Patterns we have introduced before in [2, and 8]. The core idea behind stable analysis patterns is to build the model of the pattern based on the software stability concepts introduced in [5, 6, and 7]. That is to construct the pattern in terms of its Enduring Business Themes (EBTs), Business Objects (BOs), and Industrial Objects (IOs). By applying this approach to the negotiation problem, the resultant pattern will poses the stability feature, and, therefore, it can be used to model the negotiation problem in any application. The paper provides detailed documentation of the proposed Negotiation pattern.
Andreas Rüping
	A Culture for Small Frameworks Object-oriented frameworks hit the world of software engineering a couple of years ago in an attempt to reuse not only code, but also concepts and designs. Owing to the wide-spread use of object-oriented technology, frameworks play an important role in many IT projects these days. Ideally, a framework evolves from experiences made while building several similar applications. A team that can rely on year-long experiences in an application domain stands the best chance for finding the right level of abstraction for a framework. Sometimes, however, the need for a framework arises on a much shorter timescale. Think of a development project that, in its initial stage, identifies certain functions that will be used in several places within the application. The idea of building a framework springs to mind, so that these functions can be reused wherever they are needed. This, however, means that the framework and the application must be built simultanously. Is this even possible? Is there a chance that the framework can live up to its promise? This paper presents a collection of patterns that deal with these questions. The patterns summarise the experiences made in several projects in which application development was the major goal, and in which a framework was built to facilitate application development. These experiences were both positive and negative: yes, you can build a framework in such a context, but only if you take care to limit the framework's complexity, and if the teams involved collaborate closely.
Gertrud Bjørnvig
	Patterns for the Role of Use Cases These patterns are about the role of use cases in the software development process. Five of the seven patterns have been workshopped at VikingPLoP 2002 (Know-HowKickoff, NarrativeAndGeneric, DeviationsDefineScope, GoalsDefineNumber, and UseCaseAsCenter). I would like the focus for this paper to be partly on the two new patterns: ReadinessReflectionList and SizeTheIterations, and partly on the relation to other patterns. The patterns are related to some of Jim Coplien and Neil Harrison's "Organizational Patterns", and to some of Steve Adolph and Paul Bramble's "Patterns for Effective Use Cases".
Xiaohong Yuan, Eduardo B. Fernandez
	An Analysis Pattern for Student Registration We discuss an analysis pattern for student registration into courses. The pattern describes events such as student registering in course sections, student adding and dropping course sections, grade management, etc. The pattern corresponds to a minimal semantic unit.

Writing Group

Ofra Homsky
	More Patterns for Group Leadership The target users of these patterns are group leaders: teachers, guides, managers, instructors, and coaches. They are the ones who have an overview of the group: its goals, assignments, tasks, abilities, and composition. Consequently, the group leaders can influence and streamline the group conduct and disposition. A group, being comprised of individual people, takes on an additional identity, a collective identity – that of the group: a software team, a task force, a tour group, a class. There are many factors that influence the general mood in the group – external factors and internal factors. The following patterns refer to some of the changes that come from within the group itself, created by the social relationships among group members These patterns join those I presented in last year's EuroPLoP and are part of what I hope to build into a full Pattern Language. These patterns should combine with other patterns and pattern languages referring to group work, in the sense that together with the preparations of and for the program, group leaders should bring into consideration these "mood change" factors and integrate these suggested patterns into their program.
Mads Ingstrup
	Interaction Widgets The Interaction Widget pattern describes how to enable mediation between an application and its environment, in a way satisfactory to both users and developers. The problem solved by this pattern is how to bridge the gap between the users and the developers perspective on the application, in the creation of a user interface. It further describes examples of the diverse contexts that the pattern can be applied to.
Gustavo Patow, Fernando Lyardet
	Parsing Constructor Suppose you are writing an object oriented application with persistent objects. Suppose that the file format chosen is a simple text file. When loading that file to retrieve the original classes/instances, you will need, at some time, to parse each string and make an instance of the corresponding classes. Thus, the question that arises is where to put the decision about the right objects to be created and how. One of the best alternatives be to gather all the creation cases organized in an unique, well-defined place: a class method newInstance().
Sasha Romanosky
	Operational Security Patterns To continue the practice of security patterns, we develop three security patterns previously introduced. We can describe these patterns as operational security patterns to differentiate them from architectural or enterprise security patterns. Operational security patterns can be used to further enhance the security position of any organization by providing guidance and recommendations to networked environments after they have been put into production. In this paper we present the following security patterns: - Low Hanging Fruit: Enhancing security through some quick fixes - Whitehat, Hack Thyself: Testing the response of systems by applying real-world attacks. - Fail Securely: Preparing applications and systems to respond appropriately when failure occurs.