Design decisions are made throughout the design process of a new software system or the evolution of an existing system. The context in which a system is developed influences these decisions themselves and the way they are made. There are only a few empirical studies regarding architectural decision-making or concerning how the decision-making process is executed. In this paper, we report an analysis of expert interviews regarding architectural decision-making to gain insight into how decision-making is organized in different organizational contexts. We base our analysis on interviews conducted in a previous study, where we talked to 25 software architects, team leads, and senior developers from 22 different companies in ten different countries about architectural decision-making and documentation. In this paper, we specifically analyze the interview transcripts with regard to the decision-making process. We identified eight different categories of main factors influencing how, when, and by whom decisions are made. We also present decision-making scenarios and relate them to the discovered influence factors. Results show that, apart from organizational factors, individual factors and cultural factors seem to have about the same influence as business and project factors. Company size and domain do not influence the decision-making process as much as one might expect.
{"title":"A Study on Architectural Decision-Making in Context","authors":"Iris Groher, R. Weinreich","doi":"10.1109/WICSA.2015.27","DOIUrl":"https://doi.org/10.1109/WICSA.2015.27","url":null,"abstract":"Design decisions are made throughout the design process of a new software system or the evolution of an existing system. The context in which a system is developed influences these decisions themselves and the way they are made. There are only a few empirical studies regarding architectural decision-making or concerning how the decision-making process is executed. In this paper, we report an analysis of expert interviews regarding architectural decision-making to gain insight into how decision-making is organized in different organizational contexts. We base our analysis on interviews conducted in a previous study, where we talked to 25 software architects, team leads, and senior developers from 22 different companies in ten different countries about architectural decision-making and documentation. In this paper, we specifically analyze the interview transcripts with regard to the decision-making process. We identified eight different categories of main factors influencing how, when, and by whom decisions are made. We also present decision-making scenarios and relate them to the discovered influence factors. Results show that, apart from organizational factors, individual factors and cultural factors seem to have about the same influence as business and project factors. Company size and domain do not influence the decision-making process as much as one might expect.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"24 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117143932","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Architectural technical debt (ATD) is incurred by design decisions that intentionally or unintentionally compromise system-wide quality attributes, particularly maintainability and evolvability. ATD is harmful to the system's long-term health, thus it needs to be identified for further management. However, existing ATD identification approaches are mainly based on source code analysis and thus suffer from certain shortcomings: they can only identify issues at the system implementation, they can only be employed after the systems is implemented in code, they lack a mechanism to confirm whether the potential ATD identified is real ATD or not. To address these issues, we proposed an ATD identification approach based on architecture decisions and change scenarios. To evaluate the effectiveness and usability of this approach, we conducted a case study with an information system in a large telecommunications company. The results show that the proposed approach is useful and easy to use, and it supports release planning and ATD interest measurement.
{"title":"Architectural Technical Debt Identification Based on Architecture Decisions and Change Scenarios","authors":"Zengyang Li, Peng Liang, P. Avgeriou","doi":"10.1109/WICSA.2015.19","DOIUrl":"https://doi.org/10.1109/WICSA.2015.19","url":null,"abstract":"Architectural technical debt (ATD) is incurred by design decisions that intentionally or unintentionally compromise system-wide quality attributes, particularly maintainability and evolvability. ATD is harmful to the system's long-term health, thus it needs to be identified for further management. However, existing ATD identification approaches are mainly based on source code analysis and thus suffer from certain shortcomings: they can only identify issues at the system implementation, they can only be employed after the systems is implemented in code, they lack a mechanism to confirm whether the potential ATD identified is real ATD or not. To address these issues, we proposed an ATD identification approach based on architecture decisions and change scenarios. To evaluate the effectiveness and usability of this approach, we conducted a case study with an information system in a large telecommunications company. The results show that the proposed approach is useful and easy to use, and it supports release planning and ATD interest measurement.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"52 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124912078","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In this paper, we propose and empirically validate a suite of hotspot patterns: recurring architecture problems that occur in most complex systems and incur high maintenance costs. In particular, we introduce two novel hotspot patterns, Unstable Interface and Implicit Cross-module Dependency. These patterns are defined based on Baldwin and Clark's design rule theory, and detected by the combination of history and architecture information. Through our tool-supported evaluations, we show that these patterns not only identify the most error-prone and change-prone files, they also pinpoint specific architecture problems that may be the root causes of bug-proneness and change-proneness. Significantly, we show that 1) these structure-history integrated patterns contribute more to error- and change-proneness than other hotspot patterns, and 2) the more hotspot patterns a file is involved in, the more error- and change-prone it is. Finally, we report on an industrial case study to demonstrate the practicality of these hotspot patterns. The architect and developers confirmed that our hotspot detector discovered the majority of the architecture problems causing maintenance pain, and they have started to improve the system's maintainability by refactoring and fixing the identified architecture issues.
{"title":"Hotspot Patterns: The Formal Definition and Automatic Detection of Architecture Smells","authors":"Ran Mo, Yuanfang Cai, R. Kazman, Lu Xiao","doi":"10.1109/WICSA.2015.12","DOIUrl":"https://doi.org/10.1109/WICSA.2015.12","url":null,"abstract":"In this paper, we propose and empirically validate a suite of hotspot patterns: recurring architecture problems that occur in most complex systems and incur high maintenance costs. In particular, we introduce two novel hotspot patterns, Unstable Interface and Implicit Cross-module Dependency. These patterns are defined based on Baldwin and Clark's design rule theory, and detected by the combination of history and architecture information. Through our tool-supported evaluations, we show that these patterns not only identify the most error-prone and change-prone files, they also pinpoint specific architecture problems that may be the root causes of bug-proneness and change-proneness. Significantly, we show that 1) these structure-history integrated patterns contribute more to error- and change-proneness than other hotspot patterns, and 2) the more hotspot patterns a file is involved in, the more error- and change-prone it is. Finally, we report on an industrial case study to demonstrate the practicality of these hotspot patterns. The architect and developers confirmed that our hotspot detector discovered the majority of the architecture problems causing maintenance pain, and they have started to improve the system's maintainability by refactoring and fixing the identified architecture issues.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116349604","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Dynamic software architectures are those that describe how components and connectors can be created, interconnected, and/or removed during system execution. Most existing architecture description languages (ADLs) provide a limited support to expressively describe these architectures and entail architectural mismatches and inconsistencies between architecture and implementation due to their decoupling from implementation. In this paper, we introduce the dynamic reconfiguration support provided by π-ADL, a formal, well-founded theoretically language for describing dynamic software architectures under structural and behavioral viewpoints. π-ADL provides architectural-level primitives for specifying programmed dynamic reconfigurations, i.e., Foreseen changes described at design time and triggered at runtime. In addition, π-ADL allows enacting dynamic reconfiguration by means of: (i) an exogenous approach, in which it is possible to control all elements of the software architectures and to apply the changes on the whole structure, and (ii) an endogenous approach, in which the architectural elements can manage dynamic reconfiguration actions. Furthermore, π-ADL is integrated with the Go programming language, thus enabling to automatically generate implementation code from architectural descriptions, thus tackling the existing gap between them. We hereby use a real-world flood monitoring system as an illustrative example of how to describe dynamic software architectures in π-ADL and automatically generate source code in Go.
{"title":"Supporting Dynamic Software Architectures: From Architectural Description to Implementation","authors":"Everton Cavalcante, T. Batista, F. Oquendo","doi":"10.1109/WICSA.2015.21","DOIUrl":"https://doi.org/10.1109/WICSA.2015.21","url":null,"abstract":"Dynamic software architectures are those that describe how components and connectors can be created, interconnected, and/or removed during system execution. Most existing architecture description languages (ADLs) provide a limited support to expressively describe these architectures and entail architectural mismatches and inconsistencies between architecture and implementation due to their decoupling from implementation. In this paper, we introduce the dynamic reconfiguration support provided by π-ADL, a formal, well-founded theoretically language for describing dynamic software architectures under structural and behavioral viewpoints. π-ADL provides architectural-level primitives for specifying programmed dynamic reconfigurations, i.e., Foreseen changes described at design time and triggered at runtime. In addition, π-ADL allows enacting dynamic reconfiguration by means of: (i) an exogenous approach, in which it is possible to control all elements of the software architectures and to apply the changes on the whole structure, and (ii) an endogenous approach, in which the architectural elements can manage dynamic reconfiguration actions. Furthermore, π-ADL is integrated with the Go programming language, thus enabling to automatically generate implementation code from architectural descriptions, thus tackling the existing gap between them. We hereby use a real-world flood monitoring system as an illustrative example of how to describe dynamic software architectures in π-ADL and automatically generate source code in Go.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114840880","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Social and technical debt both represent the state of software development organizations as a result of accumulated decisions. In the case of social debt, decisions (and connected debt) weigh on people and their socio-technical interactions/characteristics. Digging deeper into social debt with an industrial case-study, we found that software architecture, the prince of development artefacts, plays a major role in causing social debt. This paper discusses a key circumstance wherefore social debt is connected to software architectures and what can be done and measured in response, as observed in our case-study. Also, we introduce DAHLIA, that is "Debt-Aimed Architecture-Level Incommunicability Analysis" - a framework to elicit some of the causes behind social debt for further analysis.
{"title":"When Software Architecture Leads to Social Debt","authors":"D. Tamburri, E. D. Nitto","doi":"10.1109/WICSA.2015.16","DOIUrl":"https://doi.org/10.1109/WICSA.2015.16","url":null,"abstract":"Social and technical debt both represent the state of software development organizations as a result of accumulated decisions. In the case of social debt, decisions (and connected debt) weigh on people and their socio-technical interactions/characteristics. Digging deeper into social debt with an industrial case-study, we found that software architecture, the prince of development artefacts, plays a major role in causing social debt. This paper discusses a key circumstance wherefore social debt is connected to software architectures and what can be done and measured in response, as observed in our case-study. Also, we introduce DAHLIA, that is \"Debt-Aimed Architecture-Level Incommunicability Analysis\" - a framework to elicit some of the causes behind social debt for further analysis.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130546672","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
O. Zimmermann, Lukas Wegmann, H. Koziolek, Thomas Goldschmidt
Architectural Knowledge Management (AKM) has been a major topic in software architecture research since 2004. Open AKM problems include an effective, seamless transition from reusable knowledge found in patterns books and technology blogs to project-specific decision guidance and an efficient, practical approach to knowledge application and maintenance. We extended our previous work with concepts for problem space modeling, focusing on reusable knowledge, as well as solution space management, focusing on project-level decisions. We implemented these concepts in ADMentor, an extension of Sparx Enterprise Architect. AD Mentor features rapid problem space modeling, UML model linkage, question-option-criteria diagram support, meta-information for model tailoring, as well as decision backlog management. We validated ADMentor by modeling and applying 85 cloud application design decisions and 75 workflow management decisions, creating one problem and three sample solution spaces covering control system architectures, and obtaining user feedback on tool and model content.
{"title":"Architectural Decision Guidance Across Projects - Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge","authors":"O. Zimmermann, Lukas Wegmann, H. Koziolek, Thomas Goldschmidt","doi":"10.1109/WICSA.2015.29","DOIUrl":"https://doi.org/10.1109/WICSA.2015.29","url":null,"abstract":"Architectural Knowledge Management (AKM) has been a major topic in software architecture research since 2004. Open AKM problems include an effective, seamless transition from reusable knowledge found in patterns books and technology blogs to project-specific decision guidance and an efficient, practical approach to knowledge application and maintenance. We extended our previous work with concepts for problem space modeling, focusing on reusable knowledge, as well as solution space management, focusing on project-level decisions. We implemented these concepts in ADMentor, an extension of Sparx Enterprise Architect. AD Mentor features rapid problem space modeling, UML model linkage, question-option-criteria diagram support, meta-information for model tailoring, as well as decision backlog management. We validated ADMentor by modeling and applying 85 cloud application design decisions and 75 workflow management decisions, creating one problem and three sample solution spaces covering control system architectures, and obtaining user feedback on tool and model content.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"344 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122324919","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Designing massively scalable, highly available big data systems is an immense challenge for software architects. Big data applications require distributed systems design principles to create scalable solutions, and the selection and adoption of open source and commercial technologies that can provide the required quality attributes. In big data systems, the data management layer presents unique engineering problems, arising from the proliferation of new data models and distributed technologies for building scalable, available data stores. Architects must consequently compare candidate database technology features and select platforms that can satisfy application quality and cost requirements. In practice, the inevitable absence of up-to-date, reliable technology evaluation sources makes this comparison exercise a highly exploratory, unstructured task. To address these problems, we have created a detailed feature taxonomy that enables rigorous comparison and evaluation of distributed database platforms. The taxonomy captures the major architectural characteristics of distributed databases, including data model and query capabilities. In this paper we present the major elements of the feature taxonomy, and demonstrate its utility by populating the taxonomy for nine different database technologies. We also briefly describe QuABaseBD, a knowledge base that we have built to support the population and querying of database features by software architects. QuABaseBD links the taxonomy to general quality attribute scenarios and design tactics for big data systems. This creates a unique, dynamic knowledge resource for architects building big data systems.
{"title":"Architecture Knowledge for Evaluating Scalable Databases","authors":"I. Gorton, John Klein, A. Nurgaliev","doi":"10.1109/WICSA.2015.26","DOIUrl":"https://doi.org/10.1109/WICSA.2015.26","url":null,"abstract":"Designing massively scalable, highly available big data systems is an immense challenge for software architects. Big data applications require distributed systems design principles to create scalable solutions, and the selection and adoption of open source and commercial technologies that can provide the required quality attributes. In big data systems, the data management layer presents unique engineering problems, arising from the proliferation of new data models and distributed technologies for building scalable, available data stores. Architects must consequently compare candidate database technology features and select platforms that can satisfy application quality and cost requirements. In practice, the inevitable absence of up-to-date, reliable technology evaluation sources makes this comparison exercise a highly exploratory, unstructured task. To address these problems, we have created a detailed feature taxonomy that enables rigorous comparison and evaluation of distributed database platforms. The taxonomy captures the major architectural characteristics of distributed databases, including data model and query capabilities. In this paper we present the major elements of the feature taxonomy, and demonstrate its utility by populating the taxonomy for nine different database technologies. We also briefly describe QuABaseBD, a knowledge base that we have built to support the population and querying of database features by software architects. QuABaseBD links the taxonomy to general quality attribute scenarios and design tactics for big data systems. This creates a unique, dynamic knowledge resource for architects building big data systems.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133352462","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Architecture description can be modeled as a set of alternative choices and decisions, where the rationale and tradeoffs for each decision are documented and understood as needed to inform subsequent decisions. Each decision, based on ISO/IEC/IEEE 42010, pertains to one or more stakeholder concerns. These concerns combined with the system environment and scenarios provide architecture design context that clarifies the motivation for decisions. Subsequent authors have introduced the notion of an influencing decision force, using a many-to-many relationship with concern, to provide further context for decisions. For both concerns and forces it is left to the architect to identify the nature of this context. This paper proposes a systematic process for identifying and documenting design context in support of architectural decisions. For our work decision force is used as a central unifying aspect of the architecture framework metamodel. We extend the decision Forces Viewpoint to capture detailed design context descriptions, and add features for tagging the architecture description elements to facilitate identification of commonality, classification, and specialization. Initial feedback from industry stakeholders indicates this approach should be explored further.
{"title":"Exploring Software Architecture Context","authors":"K. Harper, Jiang Zheng","doi":"10.1109/WICSA.2015.22","DOIUrl":"https://doi.org/10.1109/WICSA.2015.22","url":null,"abstract":"Architecture description can be modeled as a set of alternative choices and decisions, where the rationale and tradeoffs for each decision are documented and understood as needed to inform subsequent decisions. Each decision, based on ISO/IEC/IEEE 42010, pertains to one or more stakeholder concerns. These concerns combined with the system environment and scenarios provide architecture design context that clarifies the motivation for decisions. Subsequent authors have introduced the notion of an influencing decision force, using a many-to-many relationship with concern, to provide further context for decisions. For both concerns and forces it is left to the architect to identify the nature of this context. This paper proposes a systematic process for identifying and documenting design context in support of architectural decisions. For our work decision force is used as a central unifying aspect of the architecture framework metamodel. We extend the decision Forces Viewpoint to capture detailed design context descriptions, and add features for tagging the architecture description elements to facilitate identification of commonality, classification, and specialization. Initial feedback from industry stakeholders indicates this approach should be explored further.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"38 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116662690","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
To investigate the new requirements and challenges of architecting often safety critical software in the automotive domain, we have performed two case studies on Volvo Car Group and Volvo Group Truck Technology. Our findings suggest that automotive software architects produce two different architectures (or views) of the same system. The first one is a high-level descriptive architecture, mainly documenting system design decisions and describing principles and guidelines that should govern the overall system. The second architecture is the working architecture, defining the actual blueprint for the implementation teams and being used in their daily work. The working architecture is characterized by high complexity and considerably lower readability than the high-level architecture. Unfortunately, the team responsible for the high-level architecture tends to get isolated from the rest of the development organization, with few communications except regarding the working architecture. This creates tensions within the organizations, sub-optimal design of the communication matrix and limited usage of the high-level architecture in the development teams. To adapt to the current pace of software development and rapidly growing software systems new ways of working are required, both on technical and on an organizational level.
{"title":"Architecting in the Automotive Domain: Descriptive vs Prescriptive Architecture","authors":"Ulf Eliasson, Rogardt Heldal, Patrizio Pelliccione, Jonn Lantz","doi":"10.1109/WICSA.2015.18","DOIUrl":"https://doi.org/10.1109/WICSA.2015.18","url":null,"abstract":"To investigate the new requirements and challenges of architecting often safety critical software in the automotive domain, we have performed two case studies on Volvo Car Group and Volvo Group Truck Technology. Our findings suggest that automotive software architects produce two different architectures (or views) of the same system. The first one is a high-level descriptive architecture, mainly documenting system design decisions and describing principles and guidelines that should govern the overall system. The second architecture is the working architecture, defining the actual blueprint for the implementation teams and being used in their daily work. The working architecture is characterized by high complexity and considerably lower readability than the high-level architecture. Unfortunately, the team responsible for the high-level architecture tends to get isolated from the rest of the development organization, with few communications except regarding the working architecture. This creates tensions within the organizations, sub-optimal design of the communication matrix and limited usage of the high-level architecture in the development teams. To adapt to the current pace of software development and rapidly growing software systems new ways of working are required, both on technical and on an organizational level.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125133104","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Decision-making is at the core of software architecture design. However, in order for the architect to take the right design decisions, assistance is required for exploring the architectural knowledge, which encompasses the various architectural solutions, their relationships and distinctions. In the past decades, the number of available technology options has increased significantly, while existing architecture knowledge approaches support technology decisions by representing relations between the different technology solutions, as well as design problems. However, they do not differentiate the candidate technologies according to their offered qualities and drawbacks. Our main goal in this exploratory study is to understand how technology solutions are being considered by the architects during the design process, and how can we enhance existing architecture knowledge concepts to support technology decision making. Our contribution in this paper is differentiating the different technology solutions' features based on a set of architecturally significant aspects, to facilitate considering technologies during the architecture design decisions. In addition, we proposed an extension for existing architecture knowledge models, which characterise the technology design decisions, and their reasoning. We evaluated our results through real examples from practitioners. Moreover, we conducted interviews with experts to validate our proposed concepts.
{"title":"Enriching Architecture Knowledge with Technology Design Decisions","authors":"Mohamed Soliman, Matthias Riebisch, Uwe Zdun","doi":"10.1109/WICSA.2015.14","DOIUrl":"https://doi.org/10.1109/WICSA.2015.14","url":null,"abstract":"Decision-making is at the core of software architecture design. However, in order for the architect to take the right design decisions, assistance is required for exploring the architectural knowledge, which encompasses the various architectural solutions, their relationships and distinctions. In the past decades, the number of available technology options has increased significantly, while existing architecture knowledge approaches support technology decisions by representing relations between the different technology solutions, as well as design problems. However, they do not differentiate the candidate technologies according to their offered qualities and drawbacks. Our main goal in this exploratory study is to understand how technology solutions are being considered by the architects during the design process, and how can we enhance existing architecture knowledge concepts to support technology decision making. Our contribution in this paper is differentiating the different technology solutions' features based on a set of architecturally significant aspects, to facilitate considering technologies during the architecture design decisions. In addition, we proposed an extension for existing architecture knowledge models, which characterise the technology design decisions, and their reasoning. We evaluated our results through real examples from practitioners. Moreover, we conducted interviews with experts to validate our proposed concepts.","PeriodicalId":414931,"journal":{"name":"2015 12th Working IEEE/IFIP Conference on Software Architecture","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134400426","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：