Combining Architectural Design Decisions and Legacy System Evolution

Gerdes, Sebastian; Lehnert, Steffen; Riebisch, Matthias

doi:10.1007/978-3-319-09970-5_5

Cited by 8 publications

(3 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…During this step the architect is taking the architectural design decisions, analogous to the decision making approaches widely described in the literature [18,24,6]. The activity requires two main inputs: the design issues ADIssue and a set of design alternatives ADAlternative.…”

Section: Architecturally Significant Metrics (Asm)mentioning

confidence: 99%

“…Usually, the architect now selects the top-ranked recommendations as the most suitable solutions candidates, which will be added to another tab. The selected candidates are considered as design alternatives (ADAlternative) to be align with the common ADD-making approaches [18,24,6]. Finally, for each alternative needs to be decided whether to approve it as solution (ADOutcome) or to reject it, as shown in Figure 6.…”

Section: Tool-supported Decision Makingmentioning

confidence: 99%

See 1 more Smart Citation

Decision Buddy

Gerdes

Soliman

Riebisch

2015

Proceedings of the 1st International Workshop on Future of Software Architecture Design Assistants

Self Cite

View full text Add to dashboard Cite

Designing a software architecture is a highly complex task and associated with a high degree of uncertainty. There are a variety of reusable and established solutions, but they differ in their impact on the system's functionality and quality. The architect has to consider different aspects like stakeholders' requirements as well as numerous constraints coming, among others, from the technical environment and organization. The context of software evolution sheds a different light on constraints. The existing system with its structure based on previous decisions is a limiting factor constraining the ongoing development. However, current approaches do not sufficiently consider constraints induced by an existing system until now. To assist the architect in taking the right design decisions efficiently, tool support for the recommendation of solutions and structured documentation of the design decisions are indispensable. In our paper, we propose a decision process focusing on the consideration of constraints in evolving systems. Furthermore, we introduce our tool Decision Buddy and show how it contributes to the application of our constraint-based decision process.

show abstract

Section: Architecturally Significant Metrics (Asm)mentioning

confidence: 99%

Section: Tool-supported Decision Makingmentioning

confidence: 99%

Decision Buddy

Gerdes

Soliman

Riebisch

2015

Proceedings of the 1st International Workshop on Future of Software Architecture Design Assistants

Self Cite

View full text Add to dashboard Cite

show abstract

“…-Requirements and constraints (REQ) could be quality attribute requirements, such as performance, maintainability, security [1], user functional requirements, such as use cases and user stories, or contextual constraints such as external systems or constraints from managers [1]. -Architecture of existing system (EXA) may constrain new ADDs [8].…”

Section: Background -Architectural Knowledge Conceptsmentioning

confidence: 99%

An Exploratory Study on Architectural Knowledge in Issue Tracking Systems

Soliman¹,

Galster²,

Avgeriou³

2021

Preprint

View full text Add to dashboard Cite

Software developers use issue trackers (e.g. Jira) to manage defects, bugs, tasks, change requests, etc. In this paper we explore (a) how architectural knowledge concepts (e.g. architectural component behavior, contextual constraints) are textually represented in issues (e.g. as adjectives), (b) which architectural knowledge concepts commonly occur in issues, and (c) which architectural knowledge concepts appear together. We analyzed issues in the Jira issue trackers of three large Apache projects. To identify "architecturally relevant" issues, we linked issues to architecturally relevant source code changes in the studied systems. We then developed a code book by manually labeling a subset of issues. After reaching conceptual saturation, we coded remaining issues. Our findings support empirically-grounded search tools to identify architectural knowledge concepts in issues for future reuse.

show abstract