Abstract: User experience design is an important part of software product development, and yet software product line engineering has largely ignored this topic. This paper presents a set of industry best practices for user experience design in software product lines. We conducted multiple-case case study research using two different product lines within the multinational company Siemens AG: in a healthcare software division and in an industrial automation software division. We performed a preliminary exploratory study that will serve as a baseline for future research in the design, implementation, and management of user experience design in the context of software product lines. Practitioners can use our findings and the resulting best practices to improve their user experience design, particularly within
healthcare and industrial automation software product lines.
Keywords: User experience design, UXD, user interface design, software product lines, SPL, engineering best practices, case study research, handbook method
Reference: Harutyunyan, N., & Riehle, D. (2019). User Experience Design in Software Product Lines. In Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS 2019), pp. 7503-7512.
Addison-Wesley asked the patterns community (or at least those who were there at the beginning) about their opinion on various issues. This is the second post of what should have been three (though I probably will only get to the first two).
For this very specific question, I expect everyone to say: Retire Singleton!
I beg to differ; for its time, Singleton was right. “Its time” mostly means single-threaded C++ code, as written by 3 of the 4 authors of the Design Patterns book. Today, many will argue that multi-threaded Java programs have made Singleton obsolete and even harmful. In my take at design patterns that would be wrong. Singleton should not perish, it should simply be adapted to its time. What ever thread-local information you may have, some it will be global to that thread. How is that not a thread-specific singleton? Or, take a group of application servers acting as a group: How is the group communication protocol not to provide a global id that makes the group identifiable and provide some global state attached to it? This may not be your granddaddy’s good ol’ singleton, but a singleton it may be nevertheless.
This is also where pattern descriptions will pass (or fail) the test of time: Does the original description of Singleton allow for these variations or not? If not, it may have been too narrow a description. I’d assume then that specific usage examples, tied to the programming languages and systems and technologies of its time, dominated the description and the abstracion process “out of examples, timeless patterns” did not yet conclude.
Beyond Singleton, some may want to retire Visitor, mostly because we find functional programming concepts being added to programming languages more and more, and multiple dispatch (which Visitor is about) comes for free. I say: Simply be precise about the scope. Visitor is (kind of) fine for Java but in a different context may not be needed as a design pattern because it has been cast as a language feature.
Design pattern should evolve and there is nothing wrong with it. John would approve.
Addison Wesley is going to celebrate the 20 year anniversary of the Design Patterns a.k.a. Gang-of-Four book. For this, they reached out to the community and asked for contributions. Here are the questions they asked, suggesting we ask (and answer) our own ones as well:
How has Design Patterns affected you and your career?
How has it changed how you think about software development?
Do you have specific recollections of the book’s release?
How do you use design patterns today?
Which Patterns should be retired?
Which new Patterns should be added?
I’ll provide my answers to questions 1-4 here and I’ll answer questions 5-6 in separate follow-on posts later.
The 20th Conference on Pattern Languages of Programs
October 23–26, 2013—Allerton Park, Monticello, IL, USA
The International Conference on Pattern Languages of Programs
April 1994: Members of the small, eclectic, and informal Hillside group gathered in Ben Lomond, California, for their yearly retreat and in the redwoods that Spring hatched a plan that was PLoP 1994. In response to the criticism that by putting together such an unconventional conference they would show they didn’t know what they were doing, one of them suggested, “then let’s pretend to know.”
To celebrate its 20th anniversary, PLoP in 2013 will return to its first home, Allerton Park, and the conference program will include a variety of special events alongside the usual PLoP fare.
While cleaning up, I found this copy of the OOPSLA 2004 Dating Design Patterns skit script. The skit itself was, as Brian Foote called it, occasionally humorous. I’m providing it here (before throwing out the paper copy) for the intermittent professional entertainment on my blog. We performed the skit at OOPSLA 2004. Fortunately, I don’t have any photos of this. However, I did find the following photo of the Gang-of-Four celebrating the ten year anniversary of the Design Patterns book. I think the photo is attributable to Brian Foote as well. In the back, you can see the late John Vlissides, still “in costume” from the skit.
Seit ein paar Monaten ist die neue Ausgabe des Entwurfsmusterbuchs verfügbar. Dies ist meine Übersetzung des Klassikers “Design Patterns” von Erich Gamma et al. aus dem Amerikanischen. Mit der neuen Ausgabe kommen einige Neuerungen und Änderungen. An erster Stelle zu nennen wäre der neue Umschlag:
Erster Vorschlag für den Umschlag der neuen Ausgabe
Der tatsächliche Inhalt der Sprechblase in der endgültigen veröffentlichten Fassung ist ein anderer und lautet: “We present you the book that changed software design.” Da die Viererbande (Gang-of-four) noch auf ein Nachfolgebuch mit weiteren Mustern hofft, habe ich Addison-Wesley’s ursprünglichen Vorschlag entsprechend geändert.
Abstract: Design patterns help in the creative act of designing, implementing, and documenting software systems. They have become an important part of the vocabulary of experienced software developers. This article reports about the author’s experiences and lessons learned with using and applying design patterns in industry projects. The article not only discusses how using patterns benefits the design of software systems, but also how firms can benefit further from developing a firm-specific design language and how firms can motivate and educate developers to learn and develop this shared language.
Here the slides for my OOPSLA Onward! 2009 talk on “Design Pattern Density Defined.” First the abstract:
Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric’s meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework’s design pattern density is a measure of how much easier it will become.
Abstract: Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric’s meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework’s design pattern density is a measure of how much easier it will become.
Reference: Dirk Riehle. “Design Pattern Density Defined.” In Proceedings of the 2009 Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA Onward! ’09). ACM Press, 2009. Page 469-480.