BibTeX Eintrag

@inproceedings{busch2015b,
	Author = {Axel Busch},
	Booktitle = {Software Engineering 2015 --- Workshopband},
	Note = {Doctoral Symposium},
	Series = {GI Lecture Notes in Informatics},
	Tags = {workshop},
	Title = {Automated Decision Support for Recurring Design Decisions Considering Non-Functional Requirements},
	Year = {2015}}

Abstract

Planning high quality software means more than regarding functionality. Considering non-functional requirements, implementing them and understanding their effects on the software architecture remain often an open question. Therefore, in this paper, we present an approach that provides decision support in a software develop- ment process for recurring design decisions in the field of non-functional requirements. The approach defines a design decision model that allows to encapsulate the reasoning of design decisions, make them reusable and use them to enable automated feedback in a decision making process. At the end, this approach increases the developer’s pro- ductivity by reusing design decisions and therefore allows to implement requirements with lower overhead and to improve the architecture quality by a tool assisted decision support process.

Eigene Zusammenfassung

Die steigende Größe und Komplexität von Softwareprojekten erfordern explizite Trennung der Qualitätsattribute, ansonsten werden die Vorstellungen der Stakeholder, gerade in den nicht-funktionalen Anforderungen wie Security, Usability und Reliabilty nicht erfüllt.
Bisher ist es nicht klar, wie der Einfluss einer bestimmten Entscheidung auf andere Qualitätsattribute ist, d.h. wenn eine Entscheidung für ein bestimmtes Attribut (Beispiel Sicherheit) getroffen wurde, kann bisher nicht vorhergesagt werden, wie groß der Einfluss sein wird, zum Beispiel, wie die Performance sich verändern wird.
In diesem Ansatz wird der Gedankenganz einer wiederkehrenden Designentscheidung in einer Entität gekapselt und somit wiederverwendbar gemacht. Es können dadurch auch die Effekte auf die Qualitätsattribute modelliert werden. Somit sind automatisierte Kompromissentscheidungen möglich.
Jede Designentscheidung kann unterschiedlich implementiert werden, indem unterschiedliche Deploymentkonfigurationen oder alternative Komponenten verwendet werden. Jede Konfiguration kann ihre eigenen Qualitätsattribute haben, zum Beispiel verschiedene Level der Sicherheit.
Dieser Ansatz liefert ein Designentscheidungsrepository, in dem diese Entitäten für wiederkehrende Entscheidungen hinterlegt sind. Durch ein automatisiertes Designentscheidungssystem wird der Entwickler unterstützt, um das bestmögliche Design unter Berücksichtigung der Qualitätsattribute bzw. nicht funktionalen Anforderungen zu erhalten.

Beschreibung des Ansatzes

Anforderungen sind in der Regel unpräzise und nicht nach Wichtigkeit geordnet (1). Somit wird zu aller erst diese Liste der Anforderungen analysiert (2.1) und klassifiziert (2.2) in verschiedene Kategorien, wie zum Beispiel Sicherheit oder die Usability. Daraufhin wird zu jeder Anforderung ein potentielles Designentscheidungsmodell aus dem Repository ausgewählt oder eine neue Entity hinzugefügt/implementiert. Jedes Modell enthält einen Teil, in dem die Architekturabhängigkeiten beschrieben sind. Diese müssen vom Softwarearchitekten mit der bereits bestehenden Architektur zusammengebracht werden (4). Aus den letztendlich gewählten Modelle werden die pareto-optimalen Kandidaten berechnet (5) unter Berücksichtigung der Qualitätsanforderungen. Das System gibt dem Softwarearchitekten daraufhin die Rückmeldung über gefundenen pareto-optimalen Lösungen unter Berücksichtigung der Qualitätsattribute. An dieser Stelle gibt es folglich zwei mögliche Schritte: Der Architekt kann die gefundenen Lösungen in die Softwarearchitektur übernehmen (7.1) oder, falls die erforderliche Qualität nicht erreicht wurde, die Anforderungen erneut überarbeiten/klassifizieren/priorisieren. Am Ende steht somit die bestmögliche Lösung der Architektur für die betrachteten Qualitätsattribute.

Notizen

Verweise