Assisting software architects in architectural decision-making using Quark
Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies...
Main Authors: | , |
---|---|
Format: | Article |
Language: | English |
Published: |
Centro Latinoamericano de Estudios en Informática
2014-12-01
|
Series: | CLEI Electronic Journal |
Online Access: | http://www.clei.org/cleiej/index.php/cleiej/article/view/71 |
id |
doaj-970ac4b0d6cb41359f999854c17dd333 |
---|---|
record_format |
Article |
spelling |
doaj-970ac4b0d6cb41359f999854c17dd3332020-11-25T01:04:42ZengCentro Latinoamericano de Estudios en InformáticaCLEI Electronic Journal0717-50002014-12-0117310.19153/cleiej.17.3.1Assisting software architects in architectural decision-making using QuarkDavid Ameller0Xavier Franch1Universitat Polit`ecnica de CatalunyaUniversitat Polit`ecnica de Catalunya Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool. http://www.clei.org/cleiej/index.php/cleiej/article/view/71 |
collection |
DOAJ |
language |
English |
format |
Article |
sources |
DOAJ |
author |
David Ameller Xavier Franch |
spellingShingle |
David Ameller Xavier Franch Assisting software architects in architectural decision-making using Quark CLEI Electronic Journal |
author_facet |
David Ameller Xavier Franch |
author_sort |
David Ameller |
title |
Assisting software architects in architectural decision-making using Quark |
title_short |
Assisting software architects in architectural decision-making using Quark |
title_full |
Assisting software architects in architectural decision-making using Quark |
title_fullStr |
Assisting software architects in architectural decision-making using Quark |
title_full_unstemmed |
Assisting software architects in architectural decision-making using Quark |
title_sort |
assisting software architects in architectural decision-making using quark |
publisher |
Centro Latinoamericano de Estudios en Informática |
series |
CLEI Electronic Journal |
issn |
0717-5000 |
publishDate |
2014-12-01 |
description |
Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool.
|
url |
http://www.clei.org/cleiej/index.php/cleiej/article/view/71 |
work_keys_str_mv |
AT davidameller assistingsoftwarearchitectsinarchitecturaldecisionmakingusingquark AT xavierfranch assistingsoftwarearchitectsinarchitecturaldecisionmakingusingquark |
_version_ |
1725196513739538432 |