Conference Organization
Conference Chair: Uwe Zdun
Program Chair: Andy Longshaw
Program Committee: Alan O’Callaghan, Andy Longshaw, Arno Haase, Kevlin Henney, Neil Harrison, Lise Hvatum, Allan Kelly, Michael Kircher, Klaus Marquardt, Till Schümmer, Didi Schütz, Markus Völter, Uwe Zdun
Writers’ Workshop groups in EuroPLoP 2005
A1 – Share and enjoy – Patterns for Successful Knowledge Sharing in Large Online Communities
Workshop Leaders: Elizabeth Whitworth , Robert Biddle
Many online community sites have been created in recent years to better harness the information sharing power of the Internet. Unfortunately, relatively few have prospered in the nebulous web environment. Some communities lacked momentum and could not draw in enough members. Perhaps more tragically, however, many found they could not hold themselves together once initial success brought flocks of new members from all corners of the web. This paper provides a small collection of patterns on how to implement community design that better supports optimal collaboration, cohesiveness, and enjoyment in large, collaborative online communities.
A2 – More Patterns for Web Applications
Workshop Leader: Michael Weiss
Small to medium sized web applications are often built using a standard open-source platform such as LAMP, rather than a comprehensive, but also more complex framework like J2EE. Our goal is to document a pattern language for this domain. The paper continues our previously reported work on a conceptual model of web applications, and web application frameworks. In this paper, we focus on patterns for the interaction with external data sources, basic access control, and managing complex application logic.
A3 – Patterns for Negotiating Actors
Workshop Leaders: Michael Weiss , Babak Esfandiari
Negotiation is the process through which two or more autonomous actors arrive at a mutually agreeable course of action. In this paper we present three patterns for organizing the negotiation process: trusted facilitator, total disclosure, and incremental disclosure. Organization refers to how the actors reveal their preferences, and whether they interact directly or indirectly. The patterns are demonstrated by applying them to the problem of aligning the behavior of the component services of a composite web service.
A4 – Patterns for Virtual Places
Workshop Leaders: Till Schuemmer , Alejandro Fernandez , Mika Myller
Interaction in virtual communities needs a place to take place. This paper combines Findings from virtual community systems with ideas initially presented by Alexander in A Pattern Language. Patterns for virtual spaces are presented and linked to their real world counterpart.
A5 – Patterns for Session Management in Groupware Systems
Workshop Leaders: Stephan Lukosch , Till Schuemmer
Synchronous groupware brings together users who want to collaborate on a common task. One possibility to make collaboration possible and to structure computer supported collaborative work is to organize collaboration comparable to a real world meeting as a session. In this paper, we discuss patterns that focus on session management for groupware systems. These patterns describe how to model a session, how to get a session running, and what to do when a session ends.
A6 – Software Architectures On Top Of Content Management – Best Practices For Enterprises And E-Government
Workshop Leader: Andreas Rueping
Content management comprises techniques and processes around the creation, maintenance, distribution and delivery of web content. When you design a large web site you’ll probably use a content management system, but you still have to set up a software architecture on top of that. Seriously, you can expect such an endeavour to be a fully-fledged software engineering project. A few guidelines how to this can’t be bad. The paper presents a collection of patterns that capture experiences from a number of projects, ranging from the design of e-government web sites offering public community services on the one hand to enterprise portals for customer relationships management on the other. The topics addressed include content organisation, rendering, support for different output channels, session state management, search functionality, personalisation, caching, workflow and deployment.
B1 – Obligation-Fulfillment: A Pattern Language for Some Financial Information Systems
Workshop Leader: Lubor Sesera
The paper addresses the issue of analysis patterns for some financial information systems. They deal with information systems based on recording obligations of various kinds and their fulfillments. This spans a large number of domains: from commercial companies to public and government institutions. Together, eight patterns and their variants are described forming a simple pattern language.
B2 – Slowly Changing Dimensions – a Pattern Language for Coping With Business Change in an Enterprise
Workshop Leaders: Hans Wegener , Robert Marti
This pattern language focuses on dealing with changes to context attributes in data stores in large corporations that are considered “slow” with respect to the rate at which business transactions are recorded, but “fast” with respect to the evolution of the underlying data model. It defines and delineates elements of an architectural language to describe where changes in the business environment materialize in and how they are propagated through the technical world. It demarcates the line between business and technical world in order to assign responsibility as to where design decisions have to be taken. It outlines techniques for capturing, managing, and propagating the structural properties of changes. It identifies different types of business change and describes how these changes can be handled at the business level and be reflected in the technical world.
B3 – A Pattern Language of Software Licensing
Workshop Leaders: Mark Perry, Halina Kaminski
Software licensing and attendant technologies are integral to the protection of software from unauthorized use, first by defining what is authorized for that particular license. This ensures the management of the resource, and where appropriate, the revenue stream for exploitation of the product. Although a software license is simply an agreement forming a legal relationship between the user of the software and the vendor, it is a vital part of software evolution from idea to market. Software developers are constantly seeking new ways to improve the licensing mechanisms that are currently used on the market. Furthermore, diversity of business models brings the need for a variety of different types of software licenses. In this paper we present a a pattern language for software licensing: a set of patterns that can be used by novice or senior programmers to design and integrate an appropriate license type into their software products. Each pattern provides a solution to a well-known problem.
B4 – User Interfaces for Searching – A Pattern Language
Workshop Leader: Tim Wellhausen
The ability to perform search requests in business data is an important aspect of a modern information system. To be accepted by the users, a successful information system needs a user interface that leverages the features and complexity of the back-end. This paper proposes a pattern language that focuses on the design of such user interfaces.
B5 – Audio Navigation Patterns
Workshop Leaders: Dirk Schnelle , Fernando Lyardet , Tao Wei
Nowadays, the design of effective speech interfaces is considered to be more an art than an engineering science. Several guidelines exist, but are more or less a hint about what should be avoided. We introduce a rst set of patterns integrating many guidelines and solution approaches developed during the past 15 years. Our goal is to document and share this knowledge with novel designers as well as providing a language to talk about Voice User Interface (VUI) designs
B6 – A few more business patterns
Workshop Leader: Allan Kelly
Author expands on earlier patterns of business strategy to investigate how patterns may cover the whole business domain. Having shown earlier how patterns may be used to characterise corporate strategy the author is now seeking to drill down into implementation, from large-scale patterns down to smaller ones. Several common business practices are presented in pattern form: Self-Service, No Frills, Personal Attention, One Size Fits All, and Cosmetic Differences.
C1 – Patterns and Advice for Managing Distributed Product Development Teams
Lise B. Hvatum , Adrian Cretoiu , Thierry Simien , Denis Heliot
These patterns are based on several years of experience within an oilfield services company running development teams that are geographically distributed. They need to deal with a substantial time difference and fundamental cultural diversity. Experience from managing these teams has been collected in a written form from various managers, and from memos with recommendations. The information collected was not in a form where it was easily accessible for new teams. Our aim is to generate a collection of standalone documentation to support distributed project teams on the journey to a successful product delivery.
C2 – Patterns for Leading Effective Meetings
Marina Haase
Statistics reveal that out of professionals attending meetings on a regular basis – 91 % admit to daydreaming during meetings – 73 % say they have brought other work to meetings – 39 % say they have dozed during meetings Many of us spend a high percentage of our work time in meetings. Often these meetings are frustrating as they seem endless, ineffective and a waste of time. But meetings are essential to business life. They are necessary for planning, reaching decisions, building teams, finding solutions… As we all know and countless books on leading meetings state, meetings can actually be made effective, energetic and fun… This paper has collected four patterns on leading meetings effectively. They are obviously not a pattern language but maybe a tentative start of a pattern collection…
C3 – XP Expanded: Patterns for Distributed eXtreme Programming
Keith Braithwaite , Tim Joyce
The ever–increasing globalisation of businesses that consume development effort leads to the desire to create development organisations that span the world. At the same time, XP and other Agile approaches to development emphasise the importance of close communication and collaboration. While these two forces on development teams seem to be in flat contradiction, in fact a body of techniques for successful distributed Agile development is beginning to emerge. These few patterns record those facets of one successful distributed XP team’s practice that seem to be widely shared amongst distributed development efforts with an Agile bent.
C4 – Patterns for Extreme Programming Practice
Joe Bergin
This set of patterns is intended to complement the standard wisdom that can be gleaned from the Extreme Programming literature such as Kent Beck’s Extreme Programming Explained. It is directed primarily at those who are starting out with Extreme Programming and might miss some subtle ideas. Once a team gains experience these patterns will become obvious, but initially some of them are counter intuitive.
C5 – Have it Your Way
Mark Prince, Andy Schneider
Everyone involved in the software development process makes decisions. Having appropriate decision support is one part of the process, but sometimes the greater challenge comes after making the decision: actually having the decision adopted and carried through. For Project Managers and Technical Leads, being able to get your decisions acted on gracefully and managing their outcome (good or bad) is one of the set of skills that belong in any manager or leads toolbox. This paper presents four patterns that capture the common practices necessary to have decisions adopted.
C6 – Technical Vendor Selection Patterns
Andy Schneider
The vendor selection process is a key part of a commercial off the shelf software based development project. Vendor selection involves a broad community including business representatives, technical teams, functional experts, contract negotiations
C7 – amethodology
James Noble, Charles Weir
You’re sitting there, contemplating the start of a new project. You have (perhaps) a potential team of programmers, project managers, office cleaners, specification gurus, architects, testers, telephone sanitizers, configuration management specialists etc. How are you going to coordinate them? How are they going to coordinate themselves? Even imagining the strictly personnel management side has been taken care of (or not) according to the whims and working of your company; the technical management is more difficult. You’ll need an agreed way of working, of agreeing in advance what we’re going to do, of cementing technical contracts between developers – in other words, you need a methodology. There are many Audi-driving ‘consultants’ who will gather around to help you help them meet their sales quotas. But how do you make the right decision?
D1 – Context Encapsulation – Three Stories, a Language, and Some Sequences
Kevlin Henney
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.
D2 – Indecisive Generality
Klaus Marquardt
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.
D3 – Architectural Patterns Revisited – A Pattern Language
Paris Avgeriou , Uwe Zdun
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’.
D4 – A Pattern for Formal Verification of Properties of Large Systems
Wolfgang Herzner , Georg Weissenbacher
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.
D5 – A Pattern Language for the Network of Things
Diethelm Bienhaus
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.
D6 – More Patterns for the Generation, Handling and Management of Errors
Andy Longshaw , Eoin Woods
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
D7 – Maintainability Patterns
Ofra Homsky , Amir Raveh
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.
E1 – Models and Aspects
Markus Voelter
Aspect Oriented Software Development (AOSD, see [AOSD]) as well as Model-Driven Software Development (MSDD, see [MDSD]) are both becoming more and more important in modern software engineering. Both approaches attack important problems of traditional software development. AOSD addresses the modularization (and thus, reuse) of cross-cutting concerns (CCC). MDSD allows developers to express structures and algorithms in a more problem-domain oriented language, and automates many of the tedious aspects of software development. But how do the two approaches relate? And how, if at all, can they be used together? This paper looks at both of these questions. The first one – how AOSD and MDSD relate – is briefly discussed in the following paragraphs. How AOSD and MDSD can be used together is the subject of the main discussion, where the paper presents six patterns of how MDSD and AOSD can be used in conjunction.
E2 – Cooperating Aspects
Arno Schmidmeier , Stefan Hanenberg
Most AOP examples and AOP patterns describe scenarios, where aspects work on a set of objects. This is not the only use case of aspects. In programs of advanced AOP developers aspects do often cooperate with objects and other aspects. This paper describes two pattern of interacting and cooperating aspects. NOTE: Please can readers concentrate on pages 4-14.
E3 – The Interaction Aspect Pattern
Alessandro Garcia , Christina Chavez , Uira Kulesza , Carlos Lucena
Software agents have the ability to interact with its surrounding environment. As the agents’ complexity increases, object-oriented abstractions cannot modularize their interactive behavior that usually tends to spread across several classes and methods of each agent design. The Interaction Aspect pattern supports the separate definition of the interaction-related concerns through the use of aspects. It decouples the agent’s interactive behavior from the implementation of its basic functionality and other agent-specific concerns, which in turn improves the system reusability and maintainability.
E4 – The Role Aspect Pattern
Alessandro Garcia , Christina Chavez , Uira Kulesza , Carlos Lucena
Software agents have to play multiple roles during their collaborations in a multi-agent system. As the agents’ complexity increases, object-oriented abstractions cannot modularize the agent roles, which tend to spread across several classes and methods of the system design. The Role Aspect pattern supports the separate definition of agent roles through the use of aspects. It decouples the role-specific behavior from the agent’s basic functionality and other system concerns, which in turn improves the system reusability and maintainability.
E5 – Execution Chain
Didi Schuetz
The “Execution Chain” design patterns focuses on systems where input signals are processed in a cascading style with different components working on the output of previous ones. Similar to the structure in the Observer pattern, the dependencies between the components are expressed explicitly within the code. But instead of building dynamic dependency structures, the information is used to derive an appropriate execution sequence upfront, and stepping through this schedule at runtime. This mechanism supports centralised control on the execution, and provides valuable support to monitor or enforce existing hard and soft real-time requirements. During many architectural reviews in the past years, we often encountered situations where project teams emphasized on using patterns, usually mentioning Observer in the first place. Further investigation revealed that these applications didn’t gain much (or any) benefit out of the dynamic dependency management that comes with observer, but paid a high price for that unused feature. The pattern described here trades this flexibility for much better predictability and additional support functions for systems with real-time requirements.
E6 – The Pipes and Filters Pattern. A Functional Parallelism Architectural Pattern for Parallel Programming
Jorge L. Ortega-Arjona
The Pipes and Filters pattern is an architectural pattern for parallel programming used when a design problem can be understood in terms of functional parallelism. This pattern proposes a solution in which different operations are performed simultaneously on different ordered pieces of data, that “flow” through the operations. Operations carried out by each component depend on results of preceeding operations by former components.
E7 – Design Patterns for Graceful Degradation
Titos Saridakis
The term graceful degradation describes the smooth change to a lower state of some system aspect as a response to the occurrence of an event that prohibits the manifestation of the fully fledged system behavior. Graceful degradation has appeared in a variety of domains, from image processing and telecommunications to shared memory multiprocessors and multi-modular memory systems. In each domain, graceful degradation has targeted a different system aspect, e.g. image quality, voice quality, computational capacity, memory access throughput, etc. However, irrespectively of the system aspect that has been gracefully degraded, the basic concepts behind the corresponding mechanisms have been similar in all the domains where graceful degradation has been used. This paper presents four design patterns that capture design principles of graceful degradation. The first of the presented patterns captures the general idea behind lowering the state of a system aspect in the occurrence of an unsolicited event that affects the quality of that aspect. The rest of the patterns elaborate on three alternative methods for graceful degradation, each with a different set of properties.
Writing Group
WG1 – Hybrid Parser
Juergen Salecker
The Hybrid Parser architectural pattern applies to software systems which need to parse documents but are constrained by memory resources available. The pattern combines the processing advantages (mainly execution speed) of event driven parsers with the programming comfort of tree based parsers. An event driven parser together with a set of expressions is used to select interesting sections (recursive) within the document to be parsed, then the parser events are forwarded to a tree builder which produces a tree of objects out of the forwarded parser events. Finally a tree based parser is used to provide the mapping from the produced object tree to the programming language.
WG2 – An analysis pattern: ‘Three-party pattern’
Lotte De Rore , Monique Snoeck
Reuse of domain models is often limited to the reuse of the structural aspects of the domain. In this paper we present a pattern in such a way that it is possible to reuse both structural and behavioral aspects. The analysis pattern ‘Three-way partnership’ describes a situation with three independent concepts that at some point need to be related with each other in various ways. The pattern can be reused in domains where you have a ‘registration’ of ‘task assignments’.
WG3 – Colour and Image Issues in Web Development
Tanya Linden , Jacob L. Cybulski
This paper describes a small set of patterns that are produced in a process of domain-wide pattern mining. We provide a brief description of the experience mining process across web development domain and explain how the resulting pattern languages were discovered. A subset of the mined patterns was selected for this paper because of their pertinence to most web development projects, i.e. colour scheme and readability issues and images download issue.
WG4 – A Pattern Language for Online Share Trading
Jayadev Gyani , Dr.P.R.K.Murthi
Online share trading systems are gaining popularity because they support share trading from any corner of the world. They provide convenient trading facility to the buyers and sellers of stocks. They provide excellent means of transparency to the sellers and buyers of shares. This paper presents a pattern language for online share trading system. The pattern language contains eight analysis patterns which provide the basic functionality of online share trading namely Select the Company, Search, Sector, Gainers Losers, Trade, Company Profile, Verify and Confirmation. These patterns are mined by observing several online share trading sites. This language helps the developer during analysis of such systems. Basically patterns are reusable designs which can be used in other similar applications. Keywords: pattern language, design patterns, online share trading.
EuroPLoP 2005 Focus Groups
Focus groups are usually free-format discussion groups which bring together people who are interested in a challenging topic related to patterns. They bring up issues such as using patterns, organising patterns, experiences with patterns, or designing pattern languages in a design fest etc. Interdisciplinary topics are particularly welcome since they help us learn from other domains. These domains range from less obvious areas of computing, such as artificial intelligence, to other areas of science, such as building architecture, mechanical engineering, music, or film making.
There are 3 long focus groups and 4 short focus groups, with 4 resp. 2 sessions over the conference. You can choose one long focus group and one short focus group. Remember that these events typically require some kind of preparation, so please check with the session description when you decide which session you’d like to attend.
In EuroPLoP 2005 there are the following LONG Focus Groups:
- Visualizing and Connecting Pattern Languages: This focus group will look for ways of combining different pattern languages and supporting orientation in pattern languages by means of graphical representations. We will discuss conceptual models and practical concerns related with the visualization of languages. There will also be the space for reviewing existing pattern collections and finding out what’s so go about them.
- Patterns for Embedded Systems: Since embedded systems are getting more and more complex and forced to fulfil more and more demanding requirements, such as openness and flexibility, which are well known in the development of desktop systems. When developing such a high level embedded systems, neither an excellent embedded skill set nor advanced desktop experience is sufficient to be successful. While embedded developers stumble into pitfalls that arise from the complexity, the desktop developers miss requirements like resource effectiveness, deployment strategies, start-up times etc. Goal of this workshop is to explore the primary knowledge on embedded systems that are necessary to “ground” an experienced desktop developer. This knowledge will then be organized in a collection of patterns, thereby defining a probably huge list of patterns that are not written yet but would be very helpful as soon as they are out. Participants to this focus group are asked to prepare a list of pattern candidates that are essential for “desktop” software engineers to be successful in development of embedded systems. Contact: dietmar.schuetz@siemens.com
- Conway’s Law: In their recently published book Organizational Patterns for Agile Software Development Coplien & Harrison include a pattern named Conway’s Law where the solution calls on organizations to: Make sure the organization is compatible with the product architecture.This focus group will look at Conway’s Law in more depth.
In EuroPLoP 2005 there are the following SHORT Focus Groups:
- Architectural Patterns in Practice: Architectural patterns were one of the very few points, where consensus was achieved in the field of software architecture: their significance is well-established and they are essential to architectural description. The goal of this focus group is to examine how practitioners, researchers, developers, etc. make use of the rich but heterogeneous and diverse collection of architectural patterns, found in the literature. The participants will reflect and discuss on some of the key issues of putting architectural patterns to practice, focusing on their hands-on experience. The focus group is intended to initiate what is expected to be a long discussion among interested researchers and practitioners in putting architectural patterns to work.
- Can Pattern Mining Be Improved?: I am proposing a domain wide pattern crafting process whereby practitioners who normally would not participate in pattern mining would be given a chance to share their experience via interviews with the ghost writer (see Figure 1). In my empirical work it was mainly unstructured and semi-structured interviews where practitioners were asked to talk about projects reflecting on their problem-solving experience. The goals of these interviews were to identify areas of concern to practitioners and ultimately to outline the potential pattern languages. All interviews were audio and video recorded (in particular, video recording of the computer screen helps understand the narration).Goal of this focus group: Seek the opinions on the proposed process.
- A Pattern Language for Peer-to-Peer Networks: Peer-to-peer networks are very different in their technical architecture and their implementation. But the success of various peer-to-peer networks in certain domains shows, that these implementations are best practice examples for distributed applications. The resulting architectures and implementations of those networks can be understood as strategies and differ according to their problem domains. Despite their varying implementations, all peer-to-peer networks must cope with communication, large amount of data, and security issues. Moreover, there are similar activities among peers, such as joining and leaving the network, querying for data items, or routing through the network. Those activities depend on the network strategy, but solve recurring problems in peer-to-peer networks. Some of these topics were discussed on the EuroPLoP 2002 (ref. Peer to Peer Patterns), but not documented as patterns. The intention of this paper is to create a structure for a peer-to-peer pattern language and to document some patterns within the language. For this goal, the pattern language shall include different abstraction levels, which address different software development phases (e.g. analysis, design).
- Patterns for Leading Effective Meetings : Meetings are part of every day life. They are necessary for planning, discussing and deciding issues in projects. But most of us have — at least at one point — sat in a meeting that could have been a lot more effective and wondered how much more time we will need to waste … Many of us have even spent seemingly endless hours in meetings that seem dull, ineffective or even counterproductive.
