Returning to EuroPLoP — Topics: API Refactoring and Pattern Visualization

EuroPLoP is one of the go-to conferences on all things patterns; our “Patterns for API Design” benefitted a lot from EuroPLoP writers’ workshops 2017 to 2020. All five co-authors of the book attended this year’s conference with follow-up work. For instance, Mirko and Olaf brought eight API refactorings with them, and a focus group aimed at exchanging experience with pattern education.

Focus Group “Pattern Visualization in Teaching and Consulting”

We value design patterns as a unique and effective way to capture and share practical expertise and research results.¹ But patterns can not only be used to design software and systems; important use cases also include teaching and consulting.

I feature Patterns of Enterprise Application Architecture, Domain-Driven Design (DDD), and Enterprise Integration Patterns in my lectures (and more).² Several submissions contained decision models for pattern selection. Hence, I proposed a focus group to discuss:

How to present entire patterns from context to problem and forces to solution, examples, consequences and known uses to classroom audiences and workshop participants?

The focus group took place on July 7 from 15:45 to 16:45; 18 EuroPLoPers attended. Its objectives were:

• Clarify the desired qualities (aka forces) for adequate pattern teaching and consulting.
• Collect and compare lessons learned (good and bad) and identify “best” practices for pattern presentation in learning environments.
• Identify suited notations and diagram types en route to a common toolbox for pattern display (not just solution sketches but entire patterns from context to solution and consequences, as well as relationships between patterns).

The workshop agenda was:

1. Introduction, goals and agenda. We formed a big circle and had a quick look at the pre-workshop version of this blog post.
2. Topic and input collection. I moderated and asked for volunteers to report how they teach bachelor and master students (or other audiences).
3. Deep dive on selected themes/topics/toolbox elements. We decided for criteria and notation as our deep dive topics.
4. Wrap up and closing questions and answers. Participants got a final chance to comment in this open round.

After the introduction, we started collecting input from the participants on how they taught (or were taught) patterns. In this input collection, participants shared examples and experiences guided by the following questions:

• Which types of patterns and pattern languages do you teach?
• Who is the target audience (in academia and industry)? How long is each session, how many students attend?
• Which didactic concepts and notations do you use?

Problem-based learning is applied frequently. One participant explained that he teaches software design/architecture as well as people roles and practices (e.g., those in Scrum), both to practitioners and in university settings. Pattern maps and examples are helpful when teaching process patterns; UML is more suited for software design/architecture audiences. The patterns are usually taught for 0.5-4 days in the industry and spread out over several classes in a university setting.

We had several participants from the Human-Computer Interaction (HCI) field. Pattern maps are common in user interface patterns; these patterns are typically very visual, so images of examples are often used. A challenge is that patterns are only a tiny part of the curriculum, so they must be condensed. Websites for pattern libraries are used, such as User Interface Design patterns, and the students are shown how to navigate them. But sometimes, these websites vanish. One approach is to call out the names of the patterns when navigating through sample websites. Patterns are often grouped into pattern sections/categories depending on certain criteria, which help navigate/find the patterns. Storyboards can be used as well.

Patterns for human behavior (collaboration) often are taught to classes of 80-100 students. Dialog workshops using patterns are conducted, where patterns are explained and then applied. Another interesting example was teaching drama patterns (capturing recurring scenes in dramas played in theaters, that is) to children from the age of 5, typically 8-9 years old. The focus is on applying patterns to learn reading and writing. Instead of explicitly explaining the patterns, the emphasis is on getting into the action. Children recognize situations and intuitively apply the patterns.

In bachelor curricula, design patterns are taught at the code and architecture level (e.g., the POSA patterns). Student groups can be as large as 150 students (and more), and classes/lectures are typically 90-100 minutes long. The teaching approach involves discussing forces and then presenting corresponding solutions. Alternatively, an example may be presented with diagrams or code, followed by a generalization into an abstract solution sketch. One participant teaching at the master level employs a flipped classroom approach in teaching domain-driven design, architecture, software design, and distributed systems. The class size can reach up to 150-200 students. Concrete examples are presented at the beginning, followed by discussions on forces, solutions and so on. The presentations include UML diagrams, code snippets and architecture diagrams. Short videos are assigned as pre-class material to introduce the content, and in-class time is dedicated to applying the concepts.

In another software architecture class, a large project is broken down into microservices as a scenario. Before writing any code, students have to identify applicable patterns. UML is then used to model the patterns, which are applied to the project next. Yet another approach giving students projects and a pattern catalog. They are expected to document their existing designs using patterns and explain the reasoning behind their decisions. At OST, bachelor students form small reader groups that get assigned pattern books or papers, for example, from (Euro-)PLoP or the POSA books. Students summarize their patterns and explain and discuss them in their groups. They also learn about the shepherding process.

In the middle of the workshop, we looked at criteria for good pattern teaching (good as in effective and efficient). We discovered the following ones:

• Applicability. Patterns should be embedded in the learners’ work and appropriately adapted or transferable to their specific contexts.
• Tangibility. Visual elements like examples (shown before and after pattern application) are easier to remember and understand than large amounts of plain text.
• Interaction between learners. It matters to make the acquired knowledge stick. Games are one way of achieving interactivity; for instance, the “Fearless Journey” game featuring change management patterns was played at EuroPLoP 23.
• Selectivity. One shoud resist the urge to teach students all patterns in a language or domain. Instead, key patterns relevant to the learning objectives should be focussed on.
• Simplicity. Using concise patterns (e.g., patlets) focusing on a single force or concept makes it easier for learners to follow.

A T-shaped approach often makes sense, providing examples of patterns and teaching how to apply them. Another part of such approach is to teach how to decide whether any other patterns are eligible in a given context, and how to study those patterns independently after the class. The goal is to teach learners abstraction and enable them to apply patterns in multiple technologies and frameworks. Four increasing pattern competency levels were proposed (aka “4A staircase”):

• Awareness. Learners are introduced to the pattern so that they know it exists and can explain it.
• Appropriateness. Learners develop the ability to make trade-offs and determine when a pattern is suitable for a particular situation.
• Abstraction. Learners acquire the skill to (re-)use patterns in different contexts.
• Authoring. Learners become capable of writing up their own patterns.

We also discussed notations and representation, starting with this draft sketch (Q = question or quality, C = concern or criterion, DD = decision driver, O = Option, P = pattern):

We captured the following comments:

• Bipartite graphs and Questions, Options, and Criteria (QOC) diagrams: When covering multiple patterns (e.g., 5-8 or more), using arrows to represent relationships between patterns can become overwhelming. Tables with forces and patterns as rows and columns are a suited alternative.
• For process-oriented patterns, for instance, those capturing agile practices or change management knowledge, sequences of patterns can be presented as little stories, creating a learning path or journey with a time dimension. Workflow diagrams have their place too.
• Decision-oriented learning paths start with an interesting design problem (or question), present several solution options as patterns, and move from decision to decision.
  • The pattern options in each decision all solve the same problem, but differently; they share most, if not all, their forces (which become decision criteria).
  • A pattern selection leads to the next decision, for instance, via the related patterns section.
  • This approach produces different sequences, which eventually may form a graph-like structure (examples can be found in this paper).
  • The decision-making (or learning) order is suggestive, not normative.
  • There are different ways to get started with the decision identification, for instance, asking “how to we adresss/realize…” questions about (non-)functional requirements, domain model elements, and architectural style descriptions.
• Icons can aid memorization, especially when they align with metaphors related to the patterns. However, metaphors have to be chosen widely to avoid misunderstandings (a topic for another post).
• Any notation should be chosen and/or designed with a clear purpose and target audience in sight. This might come across as obvious, but cannot be repeated often enough.

We ended with a final round of questions and answers, which directed us at an early approach to representing patterns and their relationships in a machine-readable way, the Pattern Language Markup Language (PLML). PLML comes as an XML document-type definition.³

Several more focus group sessions took place at the conference this year, including a “CheriSharing” workshop (a friendly, collaborative conference retrospective) and one on “Dramatizing Software Patterns” (recurring elements in a role play mapped to patterns such as Observer).

Writer’s Workshop A

Unlike other conferences, EuroPLoP focuses on improving papers instead of only presenting them. Shepherding and writers’ workshops are the two primary ways of doing so (so is PC member/peer review feedback, which is more common). Shepherding⁴ happened before the conference (for about 3 months); the writers’ workshops form the heart of the conference. Authors read each other’s papers before the conference and then discuss them on-site, following a very specific protocol.

Mirko and I got the paper “API Refactoring to Patterns” workshopped.⁵ It contains the first eight entries from our Interface Refactoring Catalog that has been emerging since 2020. The following caption from the website lists the refactorings that we collected on the left and also calls out the various smells they remove (we gave “Add Wish List” top priority in the workshop):

The paper draft was well received, and we got a lot of helpful and constructive feedback to improve it further. The overall impression was that it is well-written, that the figures aided understandability and that the examples were chosen and explained well. One aspect that we will certainly improve is to clarify the target audience of the refactorings, explain patterns icon usage in figures even more, and highlight which refactorings can be applied in a fully backward-compatible way (and which ones require additional effort to keep existing clients working).⁶

The other draft papers in the workshop were:

• “Design Patterns for Approval Processes”
• “Tool Support for Learning Architectural Guidance Models and Pattern Mining from Architectural Design Decision Models”
• “Deployment Tracking and Exception Tracking Patterns: More monitoring design patterns for cloud-native applications”
• “API Rate Limit Pattern”

There were six more workshops running in parallel, covering a diverse range of topics, including pattern writing with and for ChatGPT, microservices patterns and their effect on extensibility, patterns for contextual organizational change, community-driven learning, flexible learning spaces for hybrid education, anti-patterns related to mismanagement of NFRs.

Many of the workshopped papers will eventually become available online in the ACM Digital Library; see, for instance, “Interface Responsibility Patterns: Processing Resources and Operation Responsibilities”. The authors copy of that paper (PDF) is publicly available for download.

What’s Next?

Links to previous editions and other patterns conferences can be found here.

Please consider a submission to EuroPLoP 2024 (due in January/February, so there is time)… coaching and tools for beginners are available. For instance, have a look at the “Pattern Writing” section on this page.

– Olaf, with Mirko taking focus group session notes and capturing writer’s workshop impressions

This post is also available on Medium: Part 1 (Focus Group) and Part 2 (Writers’ Workshop)