University of Groningen Preserving and reusing architectural design decisions van der Ven, Jan

(1)

Preserving and reusing architectural design decisions van der Ven, Jan

IMPORTANT NOTE: You are advised to consult the publisher's version (publisher's PDF) if you wish to cite from it. Please check the document version below.

Document Version

Publisher's PDF, also known as Version of record

Publication date: 2019

Link to publication in University of Groningen/UMCG research database

Citation for published version (APA):

van der Ven, J. (2019). Preserving and reusing architectural design decisions. University of Groningen.

Copyright

Other than for strictly personal use, it is not permitted to download or to forward/distribute the text or part of it without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license (like Creative Commons).

Take-down policy

If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

Downloaded from the University of Groningen/UMCG research database (Pure): http://www.rug.nl/research/portal. For technical reasons the number of authors shown on this cover page is limited to 10 maximum.

(2)

Preserving and Reusing Architectural

Design Decisions

Jan Salvador van der Ven

(3)

The research presented in this thesis was carried out at the Software Engineering and Architecture group, at the Bernoulli Institute for Math, CS, AI at the University of Groningen.

This research has partially been sponsored by the Dutch Joint Academic and Com-mercial Quality Research & Development (Jacquard) program on Software En-gineering Research via contract 638.001.406 GRIFFIN: a GRId For inFormatIoN about architectural knowledge.

Cover illustration by Bloei media - bloeimedia.nl No mice were harmed in the design process.

Printed by Gildeprint - The Netherlands

ISBN (digital): 978-94-034-1534-5 ISBN (print): 978-94-034-1535-2

Copyright c 2019, Jan Salvador van der Ven

(4)

Preserving and Reusing Architectural

Design Decisions

PhD thesis

to obtain the degree of PhD at the

University of Groningen

on the authority of the

Rector Magnificus dr. E. Sterken

and in accordance with

the decision by the College of Deans.

This thesis will be defended in public on

Monday 8 April 2019 at 12:45 hours

by

Jan Salvador van der Ven

born on 14 December 1977

in Groningen, the Netherlands

(5)

Co-supervisor

Prof. P. Avgeriou

Assessment committee

Prof. U. Zdun

Prof. I. Crnkovic

Prof. D. Karastoyanova

ISBN (digital): 978-94-034-1534-5

ISBN (print): 978-94-034-1535-2

(6)

v

“Perfect is the Enemy of Done ”

(7)

(8)

vii

Acknowledgements

This project took quite some time. I have worked with many people, and I hope I remember everyone that helped me in any way. Roughly, the work on my thesis can be divided into two periods with a pause in between. In the first period, I was enrolled by the university of Groningen, and I had the opportunity to work on my research full-time. In the pause I worked in industry in several companies. With new insights from industry, I restarted my research part-time, with guidance-on-distance from Jan Bosch who resided in Gothenborg by that time. Fourteen years after starting, my work on this thesis is finished.

First of all, I want to thank Jan Bosch for the guidance of this project, and also for the endless positive and constructive attitude towards finishing this work. The business collaboration we did was challenging and fun, but you always came back with a subtle question: "how is research"?

In addition to Jan, I would like to thank three other supervisors that have been involved for shorter periods: Jos Nijhuis, Dieter Hammer and Paris Avgeriou. You all had a different perspective on research, which shaped my thoughts. Paris, thank you for the collaboration, supervision, and also for making it possible for me to teach at the university after I left. This teaching was fun and it also helped me to organize my thoughts on the research I was doing.

For this research, I have often asked others to provide me with input, either in the form of filling in a survey, or being interviewed. Thanks to all the participants, without you this research could have never been completed.

In the first period of my research, I enjoyed working with Johanneke, Marco, Sybren, Jens and Natasha. Special thanks to Anton, with whom I published my earliest works and who co-authored several of the publications that form the basis for this thesis. In the GRIFFIN project, we collaborated with researchers from the VU. Victor, Remco, Hans and Patricia, thank you for the fruitful discussions on ar-chitectural knowledge and the role of design decisions in this. Rik, I would like to thank you specifically as we were the first ’GRIFFIN-ers’. I liked the conversations we had in that period, personal as well as professional.

In the second period of my research I was not at the university, but did have contact with some researchers in Groningen: Dan, thanks for the interesting dis-cussions on research and other topics. Mircea, it was great to have a short collabo-ration with you on the Github paper.

Between the first and the second period, I worked at several companies. The people in one company shaped my thinking radically, which is also reflected in this thesis: Factlink. Tom, Remon, Gordon, Mark, Martijn and Jens, it was great to be part of the team. Special thanks to Merijn: I have learned a lot from you as you introduced me into the world of startups and showed me the joy of making products.

There is one person who was involved in the first period as well as the pause and the second period of my research. Ivor, somehow our lives keep crossing each other. Thank you for your numerous reflections on the software industry and research. Either at work, in the gym or with a small beer, we always had challenging and fun discussions. Also, thanks for giving me the opportunity to

(9)

work with you at Crop-R. I could not have finished this thesis if I didn’t have the flexible employment you made possible for me. I know we will work together some day again, and look forward to it.

While mentioning this, thanks to the Crop-R guys and girls, I loved working with you: Jeroen, Kristina, Maarten, Cees, Geoffrie, Ronald, Erik-Jan, Gert, Ma-rina, Lud en Mark. The discussions during lunch sharpened my thoughts on re-search in many occasions. Special thanks for Nico, for the deadly fights we fought at the table-tennis table that kept me in shape.

When I started writing the introduction of my thesis, Jos van Essen came in interrupting me several times. In most occasions his interruptions ended up in fruitful discussions on the state of the world and software development. Thank you for this input Jos, you helped me shape my introduction to the form it cur-rently is.

One group of friends followed my whole trajectory: the Freestylers. Jur, Axel, Martijn, Bastiaan, Hylke, Maarten, Ferdinand, Edwin, Bobby, thanks for the nu-merous discussions on everything in all kinds of places around the world (most often on camping Neus). You guys inspired me to finish my thesis not by saying I should do it but by showing how it’s done while not making it bigger than it is.

Another group of friends kept me on the ground, while they also challenged me with philosophical discussions, handball and intriguing board-games. Rik, Marijn, Sjabbe and Chris, thanks for the relaxing moments we had together in the years I worked at my research.

Finally, I would like to thank my family for the support and reflection: Irene, Corry and Marijke. Without putting pressure on me, you kept believing I could finish this. Mare en Tara, thank you for your endless enthusiasm, you energized me all the time. Last but not least, Iris thank you very much for your support and patience, especially during the restless period when I was finishing my thesis. I could not have completed this without you.

(10)

ix

Introduction

“The secret to getting ahead is getting started.”

- Mark Twain

1.1 Introduction

When I was young, I always took a city plan with me when visiting an unknown town. If I wanted to know my location, I managed with the street-signs, the index of the city plan and some orienteering-skills. When I would meet up with some-one, I used my wired phone to contact the person a few days ahead to make an appointment of where and when to meet. My sister used to send me letters when she lived in Australia. It took some weeks to communicate, but it was great to be able to hear something from her from the other side of the world. I never do any of the above-mentioned activities anymore, software radically changed them all.

Now, when I visit a town, the primary concern is that my smart-phone is charged, so the software can assist me when I need it. GPS satellites help me to show me were I am, Internet applications provide detailed maps of the world. I call my appointment when I am near to see where we meet, and send a message to my friend in the US as I walk there. It is great to see his response almost instantly from the other side of the world.

Software has an enormous impact on everyday live. It enables us to be more productive and have rich communication with each other, but also facilitate the distribution of fake-news and addicts us to our mobile devices. Software is in-cluded in traditionally physical objects like toothbrushes or thermostats. Data is produced in enormous quantities and this data is increasingly used to gain in-sights, make better decisions or sell products. Even in domains that have for a long time increased productivity by innovating the physical devices are being dis-rupted by software-driven products.

Software systems are increasingly interconnected, which creates great oppor-tunities, but also great challenges when building these systems. For example, the

BIOSCOPE project1 involved 5 companies and dozens of systems that needed to

interact. It combined the data from weather prediction, satellite images, drone im-ages and predictive algorithms on crop growth and diseases to provide automated advise to farmers. One of the products delivered potato haulm killing taskmaps

(15)

that can be used direly in (GPS-guided) tractors, based on satellite or drone images that are guaranteed to be less then ten days old.

It is challenging to build software systems like these. Many decisions have to be made to make sure all parts integrate well to meet business needs. For example, where and how should the data be stored? What data is communicated at which frequency? What is done when one of the systems fails? The answers to these topics are typical examples of decisions that form the architecture of software sys-tems. This architecture can be seen as the backbone of the system. Documenting and discussing the software architecture is extremely important for the success of a system [67]. Visualizations in the form of diagrams or models are used to

com-municate the architecture design. Figure1.1shows a diagram that was used in the

BIOSCOPE project to discuss the interaction between the system parts.

FIGURE1.1: An architectural diagram used in the BIOSCOPE project.

When systems evolve, it is hard to remember why architectural decisions were made, even if the design is visualized and documented. This effect is known as knowledge vaporization [75]. Even though the results of a decision might be doc-umented, the decision process and the reasoning behind the decision is lost, while the system evolved. This thesis investigates how architectural design decisions can be preserved, recovered or reused in order to address architectural knowledge vaporization.

(16)

1.2. A Brief History of Software Development 3

Period Application Process Architecture

Up until 1980

Small monolith programs for single purpose.

Inspired by other engineering prac-tices. Trial-and-error.

Close relationship between the design and the code.

1980 -1995

Software is available for a lager audience, and software development becomes easier. Waterfall method-ology, focus on predictability of projects. Increas-ingly more expen-sive to develop software. Emphasis on good design by doc-umenting archi-tectures. Start of reusing compo-nents. 1995 -2007

Adoption of the Internet. Software is becoming essential to companies, maintenance is increas-ingly important. Spe-cialized IT departments emerge, while compa-nies arise that solely do software products.

Increasing com-plexity as more systems interact. Agile approaches emerge. Projects are technology-focused ("can we make this work?"). Increasing com-plexity of software architecture. Exten-sive architectural documentation based on styles and patterns.

2007 un-til now

Software gets into every part of human life. For more companies, software becomes the distinctive el-ement of the business. Much easier to start a soft-ware business.

Agile matured, challenges remain in scaling and continuous deploy-ment. User focused projects ("Can we make a business out if this?").

Consolidation of styles in specific do-mains. Lightweight architectural docu-mentation, close to the source code.

TABLE1.1: Historical Change in Software Engineering and

Architec-ture

1.2 A Brief History of Software Development

Developing software is a time-consuming and tedious process. In the past decades, the ideas on how to build reliable software have evolved. Software engineering used to be an engineering practice, similar to traditional engineering practices like construction or manufacturing. As time passed, the software industry matured through trial and (sometimes very expensive) error. In order to manage the con-stantly decreasing time-to-market, the software development process changed. To show the changes, roughly four periods can be distinguished in software engineer-ing, as summarized in Table1.1.

In the first period (up until ~1980), the computer was new, and specialized com-panies and research institutes were experimenting with software. This software

(17)

of this period, there was no distinction between software and hardware, as both were sold together and software only worked for the hardware it was designed

for. The IBM System/360 2 (development started in 1965) was the first to change

this. In this family of computers, the same software could be used in different hardware versions. In the beginning of this period, there was no clear software engineering process as hardware engineering practices were adopted for software development. The designs were closely related to the implementation as there were not many layers of abstraction necessary; the design was the code. Software architecture was not existing, as Kruchten et al. [113] stated, ’until the late 1980s, the word "architecture" was used mostly in the sense of system architecture’. This changed in the next period.

In the second period (1980-1995), computers and software entered the homes of people with the introduction of the Personal Computer and operating systems like

MS-DOS3. With the greater adoption of third-level programming languages like

COBOL or C, computer programs were getting larger and more abstract. It was increasingly more difficult to create software as the cost increased (exponentially) with the size of the systems. Large, long-running projects were hard to predict and often ran over time and budget, or completely failed [33]. The interest from industry and academia in software architecture increased. Because of the high costs of failing projects, there was an increasing interest in carefully documenting the architecture in order to prevent expensive errors. Research emphasized good architectural design to manage cross-cutting concerns like non-functional require-ments. Frameworks for structured reuse of code emerged (e.g. COM components and dlls).

Around the change of the millennium (period 1995-2007), the Internet emerged and the increasing communication between software systems increased the com-plexity software development. Software was used in more domains (B2C and B2B), while companies arose that developed software as their main product. Main-tenance of software systems got increasing attention as systems were longer in use and always on. It turned out that problems from bad design decisions could be very expensive (e.g. the Millennium Bug4). In order to address the predictability of projects, experiments were conducted with agile software development

indus-try settings. The Agile Manifesto5 (2001) expressed the common agile values and

principles. With these, the emphasis on control and up-front design was slowly being replaced by an more iterative and empirical approach. Projects were tech-nology focused ("Can we make this work?"), and software architecture was respon-sible for addressing the technological challenges, while meeting nonfunctional qualities like performance or scalability. Methods for quality attribute based

ar-chitecting, like SAAM [106] and ATAM [107] were developed and used. Research

on Architecture Description Languages (ADLs) [138], documenting architectures

[42], views [67, 116], architectural styles [164] and patterns [81] was dominant in this period.

2_{https://en.wikipedia.org/wiki/IBM_System/360} 3_{https://en.wikipedia.org/wiki/MS-DOS}

4_{https://en.wikipedia.org/wiki/Year_2000_problem} 5_{http://agilemanifesto.org/}

(18)

1.3. Software Architecture 5 The last period (2007 until now) started with the introduction of the iPhone6, and therewith the start of mobile Internet. In this period, the Internet matured and stretched to mobile devices and other physical objects (the Internet of Things). As Woods describes, software systems went ’from being "always on" to being "used from anywhere for anything" ’ [199]. Standardization of many aspects of the Inter-net occurred, resulting in Software as a Service (SaaS) and Platform as a Service (PaaS) solutions. This democratized software development as it was possible for a much larger group to develop software. The focus of projects was to validate the business ideas, instead of exploring technological possibilities [156]. Agile soft-ware development proved it’s value, starting with small (startup) companies but gaining adoption across the whole software industry. The battles on the architec-tural styles and patterns were mostly settled as domains grew to a common un-derstanding for their key architectural choices, reducing the need for architectural decisions [92]. In some cases, the ecosystem made the architectural decisions for the developers (e.g. the App stores, J2EE or .NET), while in other cases successful design decisions were copied, which resulted in similarity in design. For exam-ple, all large web-frameworks use the MVC architectural style, and REST of SOAP implementations share the same design decisions. In software architecture, there is an increasing emphasis on documenting light-weight decisions, to make it pos-sible to change direction just-in-time [152]. The domain of the software architect is stretched to include automated testing, Continuous Integration and Continuous

Delivery, as well as monitoring and updating running systems [92]. As

architec-ture decision-making shifts to being more of a team activity [177], the role of

ar-chitect changes from decision maker to knowledge manager [197], responsible for

sharing knowledge.

1.3 Software Architecture

As the previous section described, software architecture changed when software engineering did. The change in perception on software architecture becomes clear when looking at the different definitions that have been used for software archi-tecture. One of the first definitions used is from Perry and Wolf [149]:

A software architecture is a set of architectural elements that have a particular form. We distinguish three different classes of architectural elements:

• processing elements; • data elements; and • connecting elements.

This definition defines different mandatory elements for the architecture, and is focused on the design itself. The definition is inspired by the architecture used in hardware and construction, by focusing on views that help to communicate the design. This is similar to the more abstract definition used by Garlan and Shaw two years later [68]:

(19)

The framework we will adopt is to treat an architecture of a specific system as a collection of computational components — or simply com-ponents — together with a description of the interactions between these components — the connectors.

The perception of an architecture as a set of components and connectors has been dominant for a long time. Many architectural styles and patterns have been defined in terms of components and connectors. However, even though architects were using views with components extensively, some aspects were missing for being able to understand the design and the system. The rationale or reasoning behind the decisions was often forgotten, and lacked a clear representation in the architecture. Forgetting the rationale of decisions caused design erosion [75], mak-ing it harder to maintain software systems. Also, as agile development practices were adopted more often, software architecture needed to be more lightweight, to be able to change with the changing business needs. Decisions needed to be de-ferred to later in the product life-cycle, without missing the rationale behind the decisions. Bosch [27] explicitly mentions the design decision as the main element of software architecture:

The key difference from traditional approaches is that we do not view a software architecture as a set of components and connectors, but rather as the composition of a set of architectural design decisions.

In this thesis, the definition of software architecture as a set of architectural design decisions is adopted. In the next section, this concept is explored in more depth.

1.4 Architectural Design Decisions

With the increasing interest in the decisions as first-class entities for architecture design, software architecture entered a new phase [27]. As the component and con-nector view was closely connected to the implementation of the design (the result), the design decision view was connected to the decision process (how we reach the result) [38]. For the domain of architectural design decisions, there are several terms that are used that need a proper introduction as they are used throughout this thesis. A Design Decision is a decision in the solution space that directly in-fluences the design of a system [96]. Architectural Design Decisions can be seen as a subset of Design Decisions, that specifically concern the software architecture of a system. An Architectural Design Decision can for example concern the adop-tion of an architectural style [68] or the inclusion of a specific component in the system [188]. There is a thin line between Design Decisions and Architectural De-sign Decisions, which follows the discussion on what architecture is and what not [65]. This thesis does not intend to provide answers in this discussion. The con-text for this thesis is software architecture, so if not mentioned otherwise, Design Decisions are considered Architectural Design Decisions.

One of the main benefits of using Design Decisions as first-class entities is that the architecture design can be split into smaller, easier to comprehend pieces, that

(20)

1.4. Architectural Design Decisions 7 together form a whole architecture. Unlike dividing the system in functional com-ponents, Design Decisions can address cross-cutting concerns like performance or maintainability, affecting multiple elements of the system. Compared to tra-ditional architectural documentation, they are easier to comprehend as they are smaller and focus on one decision topic. A Design Decision can consist of text and fragments of existing (architectural) views, as part of artifacts. Van Heesch et al. [85] state that research on Architectural Design Decisions focuses on decision templates, decision models, and annotations. Kruchten introduced a classifica-tion of Architectural Design Decisions [114], while the GRIFFIN project placed the decision process in a broader context by introducing the concept of architectural knowledge [23], which includes aspects like concerns and architectural design. To

visualize the concepts used in this thesis, Figure 1.2 shows a domain model for

Architectural Design Decisions. This domain model describes the main elements around Architectural Design Decisions and their relationships.

Alternative Decision Topic Decision Concern Artifact Rationale Ranking becomes is proposed for is made on addresses is reflected in contains is ordered by is selected based on

FIGURE1.2: Domain model for Architectural Design Decisions.

• Concern. A concern is an interest to the systems development, its operation or any other aspect that is critical or otherwise important to one or more stakeholders. The Concern can arise from different sources, like business needs, specific requirements, the development organization or previously made Decisions.

• Decision Topic. A Decision Topic is a specific question that needs to be an-swered to progress with the design. It addresses a specific Concern.

(21)

• Alternative. To address a Decision Topic, one or more potential Alternatives can be proposed. The alternatives can be reflected in one or more Artifacts, can contain Rationale for the decision, and can be ordered by several Rank-ings. When an Alternative is chosen as the solution for a Decision Topic, it becomes a Decision.

• Decision. One Alternative can be chosen to implement for a Decision Topic, this is the Decision. The selection of the right Alternative to a Decision can be based on one or more Rankings.

• Artifact. An artifact is a general term for anything used in the design or implementation of a system. This can be a file (e.g. an architecture or re-quirement description), a model (e.g. UML models) or written code.

• Rationale. The Rationale of an Alternative describes, with text or supporting views, the reasoning behind the Alternative; why would this be a good or bad choice?

• Ranking. A Ranking is a way to order Alternatives. This can be either ex-plicit (e.g. an ordered list of alternatives based on the performance) or im-plicit as part of the decision process.

Several domain models for architectural knowledge exist [22, 172], and

at-tempts show that these models can be mapped on each other [131]. The model

used in this thesis is derived from the work we did in the GRIFFIN project [190]. It contains the main elements from the ’Decision’ package we developed [61] in the context of this project. The model described in Figure 1.2 is used in the chapters of this thesis with a different focus. In Chapter 3, the decision process is ana-lyzed, connecting the Rationale and Alternatives to the Decisions (see Figure3.3).

In Chapter 4, the domain model is used as basis for the experiment with the

de-veloped tooling. This model (see Figure 4.7) adds details to the Concerns, and

connects the Decision element to documentation where the knowledge is further

detailed. In Chapter 8the domain model is used when searching for design

deci-sions in the history of source code. Here, the focus is on identifying the three main elements: the Alternatives, the Rationale, and the Decision.

Architectural Knowledge like presented in the domain model comes in three

different forms: tacit, documented and formal. Tacit knowledge [144] exists as

thoughts in human brains, and is accessible by that person only. Documented knowledge helps to communicate, as it can be read by multiple people. However, the interpretation of the documentation can be different between people. Even the person who wrote the work can have problems understanding the text later as tacit assumptions that base the text can be forgotten. Formal knowledge (e.g. meta-data or models) can help to increase the understandability and consistency, while it can also be processed by software. The research in this thesis is conducted on all types of knowledge for the software architecture domain. Architectural Knowl-edge [22] consists of the design, as well as the context, the underlying assumptions and the Architectural Decisions [119]. All this knowledge is essential for under-standing the architecture and the architecture decisions are the elements that tie all the knowledge together. In this thesis, the main focus is on architecture decisions, either tacit, documented or formal.

(22)

1.5. Research Questions 9

1.5 Research Questions

The field of software architecture clearly acknowledges the importance of architec-tural knowledge [43,60], and specifically architectural decisions [96, 178] in order

to address knowledge vaporisation [177]. Knowledge vaporisation is the problem

that knowledge about the (architecture) design is not available when needed, typi-cally during the evolution of the system. There are several reasons why knowledge vaporisation occurs. First, it is hard and time-consuming to capture knowledge in artifacts. Second, it is difficult to maintain this knowledge when the system evolves. Knowledge vaporisation affects the cost of maintenance and evolution, increases the chances on errors and slows down the development. Some solutions to address knowledge vaporisation have been proposed by academia [43, 60, 96,

178]. However, these ideas do not seem to find large-scale adoption in industry

[197]. This thesis explores industry needs on managing architectural knowledge

and shows how these needs can be supported in order to address knowledge va-porization.

First, we investigate the industrial needs for managing architectural knowl-edge, where we focus on architectural decisions. We explore user scenarios where architecture decisions are created and used, based on interviews conducted with industry partners. The first research question addresses the exploration of indus-trial needs:

Industry Needs

RQ1: What are the industry needs for managing architecture decisions?

Artifacts

RQ2: How can tacit knowledge about architectural decisions be

preserved for later use?

Process

RQ3: How does the architecture decision process

influence the decisions?

Reuse

RQ4: How can architecture decision makers reuse

decision data?

FIGURE1.3: Research Questions

RQ1: What are the industry needs for managing architecture decisions?

From the research done on this first research question, the scenarios have been divided in 27 use cases for working with architectural knowledge. These use cases involve (multiple) themes of knowledge vaporisation. The use of artifacts to pre-serve architectural knowledge was subjected in 15 use cases. Elements from the decision process came back in 9 of the use cases while reuse of decisions was pointed out in 10 of the use cases. The remaining three research questions subject these themes, as shown in Figure1.3.

(23)

The scenarios from the initial research showed that it is hard to preserve and manage architectural decisions in typically used artifacts like architectural doc-uments. There is a great availability of tools that support the documentation of architecture decisions [4]. However, the adoption in practice of tools is very low [197] and practical, adequate tools are uncommon [38]. It is often unclear what to capture and how to capture it [38]. We have investigated the research field of ratio-nale management [35,54] to see how they cope with preserving tacit knowledge in artifacts. We explored how this can be applied in software architecture research. In addition, we investigated what kind of tooling decision-makers need to preserve their tacit knowledge. Therefore, the second research question of this thesis is:

RQ2: How can tacit knowledge about architectural decisions be preserved for later use? The research results from the second research question help us to understand how tacit knowledge can be preserved in artifacts. Architecture artifacts are the result of a decision process. This is rarely a structured or standardized process. Many stakeholders of the system influence the decisions made. In this process, there is often unawareness that decisions are made [197], and there is a lack of motivation or incentive to capture them [38]. The quality of this decision process is hard to assess. However, there are many factors that influence the decision pro-cess. We investigated what the main elements are that influence the architecture decision process. Therefore, the third research question of this thesis is:

RQ3: How does the architecture decision process influence the decision results? In our work on the decision process, we saw that making decisions fast to cope with the speed of the changing market is essential for businesses. Reuse of de-cisions that are made in the past will help to increase this decision speed. The need for data to base decisions on is increasing rapidly [28]. For architectural decisions, typically reused artifacts are architectural styles and patterns. Specific design decisions, for example which component to use, are very project-specific. Reuse of these architectural decisions between projects and systems [4] is very dif-ficult. However, sharing data is becoming more common, as you can see in the open source community. As part of the research in this thesis, we searched for data on architectural decisions in open source projects. We investigate if it is pos-sible to gather data on the occurrence of specific decisions in the past, to assist decision makers in the present. Therefore, the fourth and last research question for this thesis is:

RQ4: How can architecture decision makers reuse decision data?

The four research questions are addressed this thesis. The mapping of the re-search questions to the chapters of this thesis is described in Section 1.7. A sum-mary of the results is given in the conclusions in Chapter9.

(24)

1.6. Research Methodology 11

1.6 Research Methodology

Research in software engineering is a combination of data-driven and social sci-ences research. On the one hand it is possible to prove aspects of software de-velopment (e.g. deduce the correctness or efficiency of algorithms), while on the other hand creating software is a social activity where determinism is not possible as validation. Opinions, discussions and emotions highly influence the effective-ness of a software project.

Hevner et al. [86] describe two paradigms for research in information systems. These paradigms are similarly relevant for software engineering research. First, they describe the behavioral-science perspective. Hevner et al. state this ’seeks to develop and justify theories (i.e., principles and laws) that explain or predict organiza-tional and human phenomena surrounding the analysis, design, implementation, manage-ment, and use of information systems’ [86]. Second, they describe the design-science

paradigm [52], where research is seen as a problem-solving activity. This is in

line with Shaw, [163] who describes software engineering research by defining a

specific goal:

Generally speaking, software engineering researchers seek better ways to develop and evaluate software. They are motivated by practical problems, and key objectives of the research are often quality, cost, and timeliness of software products.

With this definition, the focus is on the practical usefulness of the research (util-ity), not on the development of theories (discover truth). Hevner et al. [86] argue that these two paradigms can be seen as two sides of the same coin, both aiming to discover useful IT artifacts. Latour [124] showed that research is a social construct, where social interactions and research artifacts together construct meaningful the-ories. Hevner et al. [86] identify four types of IT artifacts that are used in software engineering research:

• constructs: vocabulary and symbols • models: abstractions and representations • methods: algorithms and practices

• instantiations: implemented and prototype systems

This thesis reports on research that developed several of these types of IT ar-tifacts. We iterated the build-and-evaluate loop often several times. When we learned from our initial results, we changed the theory and the artifacts and once again evaluated the results. This way of working is similar to the validated

learn-ing approach advocated by Eric Ries [156] for new product development. While

the IT artifact can be used as a goal for design-science research, one other aspect is important too: the evaluation of the artifact [86]. The contribution of this thesis will be addressed by describing the artifact and the evaluation of the conducted research in the conclusions in Chapter9.

(25)

1.6.1 Research Techniques

In software engineering research, many research techniques are used. In the fol-lowing list, the used research techniques in this thesis are summarized.

• Interview As software engineering is a social activity, is it important to get a solid idea of the opinions of participants. Structured interviews [161] are a way to gather data on existing problems and chosen solutions. Two chapters

in this thesis are based on interviews as research methodology: Chapter 2

and7.

• On-line Survey A more data-driven way to acquire knowledge from peo-ple that are involved in software projects is by conducting an on-line survey [154]. One of the chapters in this thesis is based on the results of a conducted survey: Chapter6. The survey was codified, and statistical analysis has been used to validate the research assumptions.

• Participant Observation In order to identify problems in software projects, we conducted research on several case studies as participant researchers [161]. In these cases, the researchers were part of a project team, and comparative multi-case analysis methodology [55] was used to generalize over the cases

to an abstract model. This methodology was used in Chapter5.

• Proof of Concept In order to validate that a proposed methodology or tool is feasible, a prototype, or proof of concept, is used [74]. With this technique, the developed prototype shows the feasibility of the approach, and demon-strates a solution that is generalizable to usage in practice. In Chapter3, an

example case is modeled in a proof of concept tool Archium [101] to show

the feasibility of the approach. In Chapter 4, an example implementation

is used in combination with a controlled experiment to show the feasibility of the approach. Last, in Chapter 8, the possibility of mining decisions and getting access to rationale is shown with an example implementation.

• Controlled Experiment With the quasi-controlled experiment [102] used in

Chapter 4, subjects were instructed to use a developed tool in order to vali-date hypotheses about expected efficiency.

• A/B Experiment As an experimental technique, the validation of work pre-sented in Chapter8was done by an A/B experiment [47]. In this experiment, the subjects were unaware they were part of the research, and two groups of subjects were used to validate additional assumptions.

1.7 Structure of this Thesis

The chapters of this thesis consist of published material. Apart from minor changes (e.g, references or small corrections), these chapters are the same as the

publica-tions. In two cases, the chapter is a combination of two publications (Chapter 2

(26)

1.8. Publications 13 Research Question Chapter Research Technique

RQ1 Chapter2 Interview

RQ2 Chapter3 Proof of Concept

Chapter4 Proof of Concept & Controlled Experiment RQ3 Chapter5 Participant Observation

Chapter6 On-line Survey Chapter7 Interview

RQ4 Chapter8 Proof of Concept & A/B Experiment

TABLE1.2: Structure of this Thesis

by the topics of the publication to increase the readability of this thesis. The chap-ters follow the order of the research questions.

Chapter 1 introduces the research questions. Chapter9 summarizes the

con-tribution of this thesis and presents future work. The concon-tribution of the other chapters to the research questions is shown in Table1.2.

1.8 Publications

The research presented in this thesis has been published in international confer-ences, as book chapters as well as in international journals. The chapters consist of these publications, sometimes with minor changes to improve the readability. The research in this thesis is performed by Jan Salvador van der Ven, which in most cases is the first author of the publication. For all the publications, at least one se-nior researcher co-authored the paper, where they helped primarily with feedback on the structure and contents.

In Chapter2, we identified the industrial needs for architectural knowledge by conducting interviews at four companies that were involved in the Griffin project. The interviews were conducted by the involved researchers (the author of this the-sis conducted the interviews at one of the partners). Together with Anton Jansen, I constructed the use case model presented in this work, based on the interview re-sults. The use case model creates the context for this thesis as it gives an overview of the needs for architectural knowledge management. I also did the validation of a set of use cases in cooperation with ASTRON, as described in the chapter. The work in Chapter2is based on the following publications:

• Jan S. van der Ven, Anton G. J. Jansen, Paris Avgeriou, and Dieter K. Ham-mer. “Using Architectural Decisions”. In: Second International Conference on the Quality of Software Architecture (QoSA 2006). Karlsruhe University Press, 2006, pp. 1–10

• Anton G. J. Jansen, Jan van der Ven, Paris Avgeriou, and Dieter K. Ham-mer. “Tool support for Architectural Decisions”. In: Proceedings of the 6th IEEE/IFIP Working Conference on Software Architecture (WICSA 2007). Mum-bai, India, Jan. 2007

(27)

In Chapter3, the relationship between software architecture and the rationale management field is explored. The concept of the explicit architectural design decision is introduced to bridge the gap between these worlds and enable better understanding of architectural decisions. This work is written in cooperation with Anton Jansen. My contribution to this work is the comparison of the processes and the validation of the ideas with the example. The work on Archium was done

by Anton. Chapter3is based on the following publication:

• Jan Salvador van der Ven, Anton Jansen, Jos Nijhuis, and Jan Bosch. “Design Decisions: The Bridge between Rationale and Architecture”. In: Rationale Management in Software Engineering. Springer, 2006, pp. 329 –348

Chapter 4 has been previously published with Anton Jansen as first author,

as he did the most of the writing of this manuscript. I started this research with the initial idea on annotating architectural decisions in documentation. I created the first version of the Word plug-in. As third and last author of this research, I contributed with the initial idea, and the structuring and writing the manuscript.

Chapter4is based on:

• Anton Jansen, Paris Avgeriou, and Jan Salvador van der Ven. “Enriching Software Architecture Documentation”. In: Journal of Systems and Software 82.8 (Aug. 2009), pp. 1232–1248

The work of Chapter5describes three dimensions that can be used to classify

the nature of architectural decisions: the architect, the artifacts and the periodicity. The dimensions are distilled by me from the industrial cases. I participated in four of the five companies as participant researcher, the data of the last company came from the coauthor Jan Bosch. The identification of the problems in the cases was done by me, while Jan Bosch assisted me with proof-reading of the work and feedback on the content. Chapter5is based on:

• Jan Salvador van der Ven and Jan Bosch. “Architecture Decisions: Who, How, and When?” In: Agile Software Architecture. Ed. by Muhammad Ali Babar, Alan W. Brown, and Ivan Mistrik. Boston: Morgan Kaufmann, 2014, pp. 113 –136

In Chapter6, we assess beliefs around software architecture, based on the re-sults of an on-line survey. I created and distributed the survey. I summarized the beliefs and conducted the coding and analyses on the results of the questionnaire.

The work from Chapter6is based on:

• Jan Salvador van der Ven and Jan Bosch. “Busting Software Architecture Beliefs: A Survey on Success Factors in Architecture Decision Making”. In: 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). Aug. 2016, pp. 42–49

Similar to Chapter3, Chapter7explores the relationship between software ar-chitecture and another field, in this case the field of lean startup. It describes how the concept of design decisions and pivots show similarities. The work is based on

(28)

1.8. Publications 15 interviews with founders and experienced architects at five different companies. I conducted these interviews, created the conceptual model and conducted the anal-ysis of the pivots. Also, I create the comparison of the concepts and developed the

guidelines. The work in Chapter7is based on:

• Jan Salvador van der Ven and Jan Bosch. “Pivots and Architectural Deci-sions: Two Sides of the Same Medal? What Architecture Research and Lean Startup can learn from Each Other”. In: Proceedings of International Conference on Software Engineering Advances (ICSEA 2013). 2013, pp. 310–317

Chapter8describes how architectural design decisions can be mined from the

version management of open source projects. The idea came from me, and I cre-ated the software that was used to do the mining, visualization, and validation with the email experiment. I developed the criteria for the programming lan-guages and the assessment of them. I conducted the analysis of the early results with subject matter experts as well as the email experiment. The chapter is based on the extended version of this research, which is currently under review,

supple-mented with a part from the previously published version. The work in Chapter8

is based on the following manuscripts:

• Jan Salvador van der Ven and Jan Bosch. “Making the Right Decision: Sup-porting Architects with Design Decision Data”. In: Proceedings of the 7th Eu-ropean Conference on Software Architecture (ECSA 2013). Ed. by Khalil Drira. Vol. 7957. Lecture Notes in Computer Science. Springer, 2013, pp. 176–183 • Jan Salvador van der Ven and Jan Bosch, "Towards Reusing Decisions my

Mining Open Source Repositories". Submitted to an international Software En-gineering Journal., 2018

Additional publications done by the author of this thesis, which are not in-cluded as chapters in this thesis, are:

• Marco Sinnema, Jan Salvador van der Ven, and Sybren Deelstra. “Using Vari-ability Modeling Principles to Capture Architectural Knowledge”. In: SIG-SOFT Softw. Eng. Notes 31.5 (Sept. 2006)

• Remco de Boer, Rik Farenhorst, Viktor Clerc, Jan Salvador van der Ven, Patri-cia Lago, and Hans van Vliet. “Structuring Architecture Project Memories”. In: Proceedings 8th International Workshop on Learning Software Organizations (LSO 2006). 2006, pp. 39–47

• Hylke Faber, Menno Wierdsma, Richard Doornbos, Jan Salvador van der Ven, and Kevin de Vette. “Teaching Computational Thinking to Primary School Students via Unplugged Programming Lessons”. In: Journal of the European Teacher Education Network 12.0 (2017), pp. 13–24

• Hylke H. Faber, Jan Salvador van der Ven, and Menno D.M. Wierdsma. “Teaching Computational Thinking to 8-Year-Olds Through ScratchJr”. In: Proceedings of the 2017 ACM Conference on Innovation and Technology in Com-puter Science Education. ITiCSE ’17. Bologna, Italy: ACM, 2017, pp. 359–359

(29)

(30)

17

Chapter 2

Exploring Use Cases for Architectural

Decisions

“In theory there is no difference between theory and practice. In practice there is.”

- Yogi Berra This section is based on:

• Jan S. van der Ven, Anton G. J. Jansen, Paris Avgeriou, and Dieter K. Ham-mer. “Using Architectural Decisions”. In: Second International Conference on the Quality of Software Architecture (QoSA 2006). Karlsruhe University Press, 2006, pp. 1–10

• Anton G. J. Jansen, Jan van der Ven, Paris Avgeriou, and Dieter K. Ham-mer. “Tool support for Architectural Decisions”. In: Proceedings of the 6th IEEE/IFIP Working Conference on Software Architecture (WICSA 2007). Mum-bai, India, Jan. 2007

The problem introduction sections were used from the latter, while the descrip-tion of the use case model is based on the work presented in QoSA 2006.

Abstract

There are increasing demands for the explicit representation and subsequent sharing and usage of architectural decisions in the software architecting process. However, there is lit-tle known on how to use these architectural decisions, or what type of stakeholders need to use them. This chapter presents a use case model that arose from industrial needs, and is meant to explore how these needs can be satisfied through the effective usage of architec-tural decisions by the relevant stakeholders. The use cases are currently being validated in practice through industrial case studies. As a result of this validation, we argue that the usage of architectural decisions by the corresponding stakeholders can enhance the quality of software architecture.

2.1 Introduction

Current research trends in software architecture focus on the treatment of architec-tural decisions [112,114,180] as first-class entities and their explicit representation

(31)

in the architectural documentation. From this point of view, a software system’s architecture is no longer perceived as interacting components and connectors, but rather as a set of architectural decisions [100]. This paradigm shift has been initi-ated in order to alleviate a major shortcoming in the field of software architecture: Architectural Knowledge Vaporization [27,189]. Architectural decisions are one of the most significant forms of architectural knowledge [189]. Consequently, archi-tectural knowledge vaporizes because most of the archiarchi-tectural decisions are not documented in the architectural document and cannot be explicitly derived from the architectural models. They merely exist in the form of tacit knowledge in the heads of architects or other stakeholders, and inevitably dissipate. Note, that this knowledge vaporization is accelerated if no architectural documentation is created or maintained in the first place. Architectural knowledge vaporization due to the loss of architectural decisions is most critical, as it leads to a number of problems that the software industry is struggling with:

• Expensive system evolution. As the systems need to change in order to deal with new requirements, new architectural decisions need to be taken. However, the documentation of existing architectural decisions that reflect the original intent of the architects is lacking. This in turn causes the adding, removing, or changing of decisions to be highly problematic. Architects may violate, override, or neglect to remove existing decisions, as they are unaware of them. This issue, which is also known as architectural erosion [149], results in high evolution costs.

• Lack of stakeholder communication. The stakeholders come from differ-ent backgrounds and have differdiffer-ent concerns that the architecture documdiffer-ent must address. If the architectural decisions are not documented and shared among the stakeholders, it is difficult to perform trade-offs, resolve conflicts, and set common goals, as the reasons behind the architecture are not clear to everyone.

• Limited reusability. Architectural reuse cannot be effectively performed when the architectural decisions are implicitly hidden in the architecture. To reuse architectural artifacts, we need to know the alternatives, and the ratio-nale behind each of them, as to avoid making the same mistakes. Otherwise the architects need to ‘re-invent the wheel’.

The complex nature and role of architectural decisions requires a systematic and partially automated approach that can explicitly document and subsequently incorporate them in the architecting process. We have worked with industrial part-ners to understand the exact problems they face with respect to loss of architectural decisions. We demonstrate how the system stakeholders exactly can use architec-tural decisions with the help of a use-case model.

The rest of this chapter is structured as follows: first, the notion of architectural decisions is introduced, continued by the vision of how to share and use these

de-cisions by relevant stakeholders as the Knowledge Grid. In Section2.3we give an

overview of how our industrial partners defined the needs for using and sharing architectural decisions. Section 2.4presents the use case model, including the ac-tors and system boundary. The ongoing validation of the use cases is conducted

(32)

2.2. Architectural Decisions 19 in Section2.5. Section2.6discusses related work in this field and Section2.7sums up with conclusions and future work.

2.2 Architectural Decisions

To solve the problem of knowledge vaporization and attack the associated prob-lems of expensive system evolution, lack of stakeholder communication, and lim-ited reused we need to effectively upgrade the status of architectural decisions to first-class entities. However, first we need to understand their nature and their role in software architecture. Based on our earlier work [27, 100, 189], we have come to the following conclusions on architectural decisions so far:

• They are cross-cutting to a great part or the whole of the design. Each deci-sion usually involves a number of architectural components and connectors and influence a number of quality attributes.

• They are interlaced in the context of a system’s architecture and they may have complex dependencies with each other. These dependencies are usually not easily understood which further hinders modeling them and analyzing them (e.g. for consistency).

• They are taken to realize requirements (or stakeholders’ concerns), and con-versely requirements must result in architectural decisions. This two-way traceability between requirements and decisions is essential for understand-ing why the architectural decisions were taken.

• They must result in architectural models, and conversely architectural mod-els must be rationalized by architectural decisions. This two-way traceability between decisions and models is essential for understanding how the archi-tectural decisions affect the system.

• They are derived in a rich context: they result from choosing one out of sev-eral alternatives, they usually represent a trade-off, they are accompanied by a rationale, and they have positive and negative consequences on the overall quality of the system architecture.

The exact properties and relationships of the architectural decisions [27, 119] are still the topic of ongoing research. Some properties [100,142,180] and relation-ships [112] have been identified. In this chapter, the definition from [189] is used for architectural decisions:

A description of the choice and considered alternatives that (partially) realize one or more requirements. Alternatives consist of a set of ar-chitectural additions, subtractions and modifications to the software architecture, the rationale, and the design rules, design constraints and additional requirements.

(33)

A description of an architectural decision can therefore be divided in two parts: a description of the choice and the associated alternatives. The description of the choice consists of elements like: problem, motivation, cause, context, choice (i.e. the decision), and the resulting architectural modification. The description of an alternative include: design rules and constraints, consequences, pros and cons of the alternative [189]. For a more in-depth description how architectural decisions can be described see [180,189].

2.3 From industrial needs to Use Cases

In order to support and semi-automate the introduction and management of ar-chitectural decisions in the architecting process an appropriate tool is required. In specific, this tool should be a Knowledge Grid [200]: “an intelligent and sustain-able interconnection environment that ensustain-ables people and machines to effectively capture, publish, share and manage knowledge resources”.

Before pinpointing the specific requirements for a knowledge grid in the next sections, it is useful to consider the more generic requirements by combining the areas of knowledge grids and architectural decisions. First, this system should support the effective collaboration of teams, problem solving, and decision mak-ing. It should also use ontologies to represent the complex nature of architectural decisions, as well as their dense inter-dependencies. Furthermore, it must effec-tively visualize architectural decisions and their relations from a number of dif-ferent viewpoints, depending on the stakeholders’ concerns. Finally, it must be integrated with the tools used by architects, as it must connect the architectural decisions to documents written in the various tools or design environments, and thus provide traceability between them.

We are currently participating in the Griffin project that is working on tools, techniques and methods that will perform the various tasks needed for building this knowledge grid. Until now, the project has produced two main results: a use case model, and a domain model. The domain model describes the basic concepts for storing, sharing, and using architectural decisions and the relationships

be-tween those concepts [61]. The use case model describes the required usages of

the envisioned knowledge grid. The use cases are expressed in terms of the do-main model, in order to acquire a direct link between what should be described (the domain model), and how it should be used (use cases). The focus in this chapter is on the use case model.

Four different industrial partners participate in the Griffin project. They are all facing challenges associated to architectural knowledge vaporization. Although the companies are of different nature, they all are involved in constructing large software-intensive systems. They consider software architecture of paramount importance to their projects, and they all use highly sophisticated techniques for maintaining, sharing and assessing software architectures. Still, some challenges remain.

We conducted qualitative interviews with 14 employees of these industrial partners. Our goal was to analyze the problems they faced concerning sharing architectural knowledge, and to identify possible solutions to these problems. Peo-ple with different roles were interviewed: architects (SA), project managers (PM),

(34)

2.4. The Use Case Model 21 architecture reviewers (AR), and software engineers (SE). To guide the interviews a questionnaire was used (see appendix). The questionnaire was not directly shown to the employees, but used us starting points and checklist for the interviewers.

The results from the interviews were wrapped up in interview reports that de-scribed the current challenges and envisioned solutions by these companies. The interview reports contained some needs from the interviewees, which included:

1. Find relevant information in large architectural descriptions (SA, PM, AR). 2. Add architectural decisions, relate them to other architectural knowledge

like architectural documentation, or requirement documentation (SA, PM). 3. Search architectural decisions and the underlying reasons, construct

(multi-ple) views where the decisions are represented (SA, PM, AR).

4. Identify what knowledge should minimally be made available to let devel-opers work effectively (SA).

5. Identify the changes in architectural documentation (PM).

6. Identify what architectural decisions have been made in the past, to avoid re-doing the decision process. This include identifying what alternatives were evaluated and the issues that played some critical role at that time (SA, PM, AR, SE).

7. Reuse architectural decisions (SA, PM, SE).

8. Keep architecture up-to-date during development and evolution (SA, PM). 9. Get an overview of the architecture (SA, PM, AR).

The next section describes how these interviews were used to construct use cases for managing and sharing architectural knowledge.

2.4 The Use Case Model

This section elaborates on a set of use cases that roughly define the requirements for a potential knowledge grid. The starting point for the use cases were the inter-view reports and the requirements stated in these reports. First, we describe the ac-tors of the knowledge grid, starting from the roles of our interviewees. After this, the primary actor and the scope are discussed. To understand the dependencies between the use cases a use case model consisting of 27 use cases, including the relations, is presented in Figure 2.1. Besides presenting the dependencies among the use cases, the figure also relates the use case to the identified needs described in the previous section.

(35)

Knowledge Grid 17 Project Manager Architecture Reviewer Architect Maintainer All

Summary User-Goal Subfunction

2 16 4 5 26 14 24 25 1 6 9 11 15 21 23 10 12 18 19 22 20 13 8 3 7 27 Legend X

Use case X Actor Includes

relationship

Use Case Titles

1. Check implementation against architectural decisions (need 8)

2. Identify the subversive stakeholder (need 3) 3. Identify key architectural decisions for a specific stakeholder (need 1,9)

4. Perform a review for a specific concern (need 3) 5. Check correctness (need 8, 9)

6. Identify affected stakeholders on change (need 3)

7. Identify unresolved concerns for a specific stakeholder (need 9)

8. Keep up-to-date (need 5)

9. Inform affected stakeholders (need 5) 10. Retrieve an architectural decision (need 6) 11. View the change of the architectural decisions over time (need 5)

12. Add an architectural decision (need 2) 13. Remove consequences of a cancelled architectural decision (need 8) 14. Reuse architectural decisions (need 14) 15. Recover architectural decisions (need 6, 7) 16. Perform incremental architectural review (need 1, 9)

17. Assess design maturity (need 1)

18. Evaluate impact of an architectural decision 19. Evaluate consistency (need 1)

20. Identify incompleteness (need 1) 21. Conduct a risk analysis

22. Detect patterns of architectural decision dependencies

23. Check for superfluous architectural decisions 24. Cleanup the architecture

25. Conduct a trade-off analysis (need 3) 26. Identify important architectural drivers (need 3) 27. Get consequences of an architectural decision (need 3, 6)

(36)

2.4. The Use Case Model 23

2.4.1 Actors

We identified the following actors being relevant for the use cases, based on the roles of the interviewees.

• Architect. Architects should be able to create and manage an architecture, and get an overview of the status of the architecture. This results in demands for views that show the coverage of requirements or describe the consistency of the design. Also, the architect is responsible for providing stakeholders with sufficient information, to ensure that their concerns are met in the architec-ture design.

• Architecture Reviewer. Architecture reviewers are often interested in a specific view on the architecture. They can be colleagues, experts from a certain field, or reviewers from an external organization. They want to understand the architecture quickly and want to identify potential pitfalls in the architecture, like poorly founded architectural decisions, architectural incompleteness, or architectural inconsistency.

• Project Manager. The concerns of the project manager are usually driven by the planning; what is the status of the architecture, are there potential upcom-ing problems or risks, and how can we address them? The project manager also addresses people-related issues, e.g. which stakeholder is the biggest risk for the architecture?

• Developer. The primary concern of the developer is that the architecture should provide sufficient information for implementing the system. The de-scriptions must be unambiguous. Also, the developer must know where to look for the necessary knowledge; this can be in the architectural documen-tation, or by knowing which person to contact.

• Maintainer. The maintainer is often ignored as a stakeholder of an architec-ture. However, the maintainer is one of the most important actors when the architecture has to evolve. The maintainer has interest in the evolution of the architecture (up-to date information), and the consequences of changes in the architecture.

We encountered that the different companies used different terms for the roles they have in the software development process. The list of actors presented above is an abstraction of those different roles.

2.4.2 Describing the use cases

We present the use cases, as mandated in [44], using the following elements: • Scope. All the use cases are defined as an interaction on a knowledge grid

type of system (see Section 2.3). From the use case model perspective, this system is considered a black-box system.

(37)

• Goal level. The descriptions from the interviews were very diverse in detail. As a consequence, some use cases describe a single interaction on the sys-tem (e.g. add an architectural decision), while others are very high-level de-mands of the system (e.g. perform an incremental architectural review). We

adopted three goal levels from [44] of a decreasing abstraction: Summary,

User-goal and Subfunction, for describing this difference. A Summary goal use case can involve multiple User-goals use cases, and often have a longer time span (hours, days). A User-goal use case involves a primary actor using the system (in Business Process Management often called elementary busi-ness process), often in one session of using the system. Subfunction use cases are required to carry out User-goal use cases. They typically represent an ele-mentary action on the system, which is used by multiple User-goal use cases. • Primary actor. The list of actors described in Section 2.4.1are used to deter-mine the primary actor for a specific use case. Sometimes, a use case can be performed by all actors (e.g. identify key architectural decisions). In these cases, the term All is used as a substitute for the primary actor. In other cases, when the type of actor affects the use case, the most suitable actor was selected as primary actor, and the others were left out.

• Main success scenario and steps. First, a short description of the use case was constructed. From this, a set of steps was defined, describing the main suc-cess scenario. Due to space constraints, this is not shown for all the use cases. In the next section, four use cases are described in detail.

• Includes relationships. The “include” relationships between the use cases are based on the steps defined for these use cases. This relationship expresses that a use case contains behavior defined in another use case, as defined in

UML 2.01. When a use case includes another use case with a different

pri-mary actor, this typically means that the first actor will ask the second actor to perform the specified use case. For example, in use case 2 (Identify the sub-versive stakeholder), the project manager will ask the architect to conduct a risk analysis (use case 21). Off course one person can also have multiple roles, and thus perform as the primary actor in both use cases.

Figure2.1 presents the characteristics (Primary actor, goal level, and name) of the use case model, which consists of 27 use cases. Note that to enhance the read-ability, the uses relationship (between the actor and the use case) is not visualized with arrows, but by horizontal alignment. For example, the architecture reviewer acts as a primary actor for use cases 16, 4, 26, and 5. The use cases are vertically di-vided in the three goal levels: Summary, User-goal and Subfunction. For example, use case 16 is a Summary use-case and use case 4 an User-goal.

2.5 Use Case Validation

An use case model like the one presented in Section 2.4 can not be formally

vali-dated. Instead, the use cases need to be applied in practice and their effect on the 1_{http://www.uml.org/}

University of Groningen Preserving and reusing architectural design decisions van der Ven, Jan

Preserving and Reusing Architectural

Design Decisions

Jan Salvador van der Ven

Preserving and Reusing Architectural

Design Decisions

PhD thesis

to obtain the degree of PhD at the

University of Groningen

on the authority of the

Rector Magnificus dr. E. Sterken

and in accordance with

the decision by the College of Deans.

This thesis will be defended in public on

Monday 8 April 2019 at 12:45 hours

by

Jan Salvador van der Ven

born on 14 December 1977

in Groningen, the Netherlands

Co-supervisor

Prof. P. Avgeriou

Assessment committee

Prof. U. Zdun

Prof. I. Crnkovic

Prof. D. Karastoyanova

ISBN (digital): 978-94-034-1534-5

ISBN (print): 978-94-034-1535-2

Acknowledgements

Contents

Chapter 1

Introduction

1.1

Introduction

1.2

A Brief History of Software Development

1.3

Software Architecture

1.4

Architectural Design Decisions

1.5

Research Questions

1.6

Research Methodology

1.6.1

Research Techniques

1.7

Structure of this Thesis

1.8

Publications

Chapter 2

Exploring Use Cases for Architectural

Decisions

Abstract

2.1

Introduction

2.2

Architectural Decisions

2.3

From industrial needs to Use Cases

2.4

The Use Case Model

2.4.1

Actors

2.4.2

Describing the use cases

2.5

Use Case Validation