Modellierung und Dokumentation von Softwarearchitekturen


Seminararbeit, 2005

40 Seiten, Note: 1,3


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Grundlagen von Softwarearchitekturen
2.1 Begriffsdefinitionen
2.2 Motivation für Softwarearchitekturen
2.2.1 Qualität von Softwarearchitekturen
2.2.2 Einflussfaktoren von Softwarearchitekturen

3 Modellierung von Softwarearchitekturen
3.1 Ziele
3.2 Konzepte und Methoden
3.2.1 Sichtenkonzept
3.2.2 Architekturstrukturen
3.2.3 Architekturstile
3.2.4 Referenzmodelle und Referenzarchitekturen
3.2.5 Aktivitäten zur Modellierung
3.2.6 Unified Modeling Language (UML)
3.2.6.1 Motivation
3.2.6.2 Entwicklung
3.2.6.3 Ziele
3.2.6.4 Aufbau & Konzepte

4 Dokumentation von Softwarearchitekturen
4.1 Ziele
4.2 Konzepte und Methoden
4.2.1 Grundregeln
4.2.2 Sichtenkonzept

5 Fazit und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1 – Die Softwarearchitektur im Kontext

Abbildung 2.2 – Einfluss der Stakeholder auf die Architektur

Abbildung 3.1 – Modellierung und Dokumentation im Kontext

Abbildung 3.2 – Konzepte und Methoden der Modellierung

Abbildung 3.3 – Das 4+1 Sichten Modell

Abbildung 3.4 – Beziehungen zwischen Architekturkonzepten

Abbildung 3.5 – Die Diagramme der UML gegliedert nach Sichten

Abbildung 3.6 – Die Diagramme der UML gegliedert nach Kategorien

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die Architektur zählt zu den wichtigsten Elementen eines Softwaresystems. Aus diesem Grund, gehören sowohl die Modellierung als auch die Dokumentation einer Softwarearchitektur, zu den wesentlichen Aktivitäten im Rahmen der Entwicklung von Software.

Die vorliegende Arbeit beschäftigt sich mit der Modellierung und Dokumentation von Softwarearchitekturen. Sie gliedert sich in drei Hauptteile. Jeder dieser Teile beginnt mit der Definition und Abgrenzung der zentralen Begriffe und setzt sich mit der jeweils zugrunde liegenden Motivation auseinander. Mit dem Teil „Grundlagen von Softwarearchitekturen“ soll die grundlegende Bedeutung von Softwarearchitekturen herausgestellt werden. Hierbei stehen im besonderen die Frage, welche Faktoren Einfluss auf die Architektur haben sowie der Aspekt der Qualität im Mittelpunkt. Im Teil „Modellierung von Softwarearchitekturen“ geht es schwerpunktmäßig um eine Reihe zentraler Konzepte und Methoden, welche für die Modellierung verwendet werden können. Ein besonderer Fokus liegt hierbei auf der Modellierungssprache UML, da diese einen praktischen Ansatz zur Modellierung darstellt und die darüber hinaus sehr weit verbreitet ist. Der Teil „Dokumentation von Softwarearchitekturen“ befasst sich schließlich damit, warum die Dokumentation einer Softwarearchitektur notwendig ist, welche Ziele mit der Dokumentation verfolgt werden sowie welche Ansätze es gibt, um diese Ziele zu erreichen.

2 Grundlagen von Softwarearchitekturen

Um ein Verständnis für die Bedeutung der Modellierung und Dokumentation von Softwarearchitekturen zu erlangen, ist es zunächst wichtig deutlich zu machen, welche Rolle die Softwarearchitektur bei der Entwicklung eines Softwaresystems spielt. In diesem Abschnitt wird es daher, als Basis für die nachfolgenden Punkte, vor allem um grundsätzliche Aspekte in Bezug auf Softwarearchitekturen gehen.

2.1 Begriffsdefinitionen

Eine Softwarearchitektur kann definiert werden als die Struktur der Strukturen einer Software bzw. eines Softwaresystems (vgl. [BaCK2003, S.3]).

Unter einer Struktur sind dabei Software Elemente und die Beziehungen zwischen diesen Elementen zu verstehen. Die Elemente enthalten ihrerseits öffentliche und private Bereiche und werden durch unterschiedliche Personen bzw. Gruppen von Personen bearbeitet. Von den Details der Elemente wird bei einer Architektur abstrahiert (vgl. [BaCK2003, S.21f]). Im folgenden werden die Begriffe Softwarearchitektur und Architektur, sofern nicht anders angegeben, synonym verwendet. Gleiches gilt für die Begriffe Software, Softwaresystem und System.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1 – Die Softwarearchitektur im Kontext

Legt man die oben genannte Definition zugrunde, so verfügt prinzipiell jedes Softwaresystem über eine Architektur. Im einfachsten Fall, wenn das System nur aus einem einzigen Element besteht [BaCK2003, S.22].

Allerdings existiert bis heute keine anerkannte, allgemeingültige Definition des Begriffs Softwarearchitektur. Die vorliegende Definition stellt somit eine unter zahlreichen Definitionen dar[1]. Jedoch besteht zwischen vielen der gängigen Definitionen eine starke inhaltliche Redundanz (vgl. [BaCK2003, S.23]).

Weiterhin ist im Bereich der Softwareentwicklung der Begriff des Stakeholders von Relevanz. Als Stakeholder werden in diesem Fall alle Personen und Gruppen von Personen bezeichnet, die an dem Prozess der Systementwicklung beteiligt sind (vgl. [HaNe2001, S.248]) bzw. die ein Interesse an diesem Prozess haben (vgl. [BaCK2003, S.6]).

2.2 Motivation für Softwarearchitekturen

Der Architektur kommt in einem Softwaresystem eine Rolle zu, die vergleichbar ist mit der Rolle von Architekturen in anderen Kontexten, etwa beim Bau von Gebäuden. Die Architektur eines Softwaresystems stellt dessen Grundstruktur dar, so wie die Architektur eines Gebäudes dessen Grundstruktur beschreibt. Dementsprechend zählt die Modellierung der Architektur zu den wichtigsten Phasen im Softwareentwicklungsprozess.

Die Bedeutung der Softwarearchitektur basiert dabei im wesentlichen auf drei Faktoren [BaCK2003, S.26ff]:

- Grundstruktur

Die Softwarearchitektur beschreibt die frühesten Entscheidungen, bezüglich des Designs und damit die Grundstruktur eines Systems. Das heißt auch, dass es sich bei den Entscheidungen, die sich in der Architektur ausdrücken, um die schwierigsten und die mit den weitest reichenden Konsequenzen verbundenen Entscheidungen handelt. Damit hat die Architektur auch maßgeblichen Einfluss darauf, wie die Implementierung des Systems erfolgt und wie die Struktur des Entwicklungsprozesses bzw. des Entwicklungsprojektes aussieht.

Darüber hinaus wirkt sich die Architektur darauf aus, inwieweit bestimmte Qualitätsaspekte vom System erfüllt werden können, auch wenn die Qualität eines Softwaresystems selbst, nicht von der Architektur determiniert wird.

- Kommunikation

Die Architektur dient als Mittel der Kommunikation zwischen den Stakeholdern. Die Stakeholder haben unterschiedliche, oftmals divergierende Interessen. Außerdem kommen sie zum Teil aus unterschiedlichen Bereichen (z.B. Kunden, Projektmanager, Programmierer), weswegen es zu Problemen bei der Kommunikation oder Missverständnissen zwischen ihnen kommen kann. Daher ist es wichtig die Architektur eines Systems als gemeinsame, allen verständliche Sprache für die Stakeholder zu verstehen und zu verwenden.

- Abstraktion

Der Aspekt der Abstraktion ist im Hinblick auf Softwarearchitekturen von besonderer Bedeutung. Die Softwarearchitektur stellt ein Modell der Struktur eines Systems dar, bei dem die Details des Systems nicht betrachtet bzw. abgebildet werden. Es erfolgt demnach eine Abstraktion und damit eine Reduktion auf das wesentliche.

Dies hat zur Folge, dass sich eine Architektur auch auf Systeme mit vergleichbaren Anforderungen, in funktionaler und qualitativer Hinsicht, übertragen und so wiederverwenden lässt.

2.2.1 Qualität von Softwarearchitekturen

Aufgrund der Bedeutung die der Architektur eines Softwaresystems zukommt, hat die Qualität einer solchen Architektur entscheidenden Einfluss auf die Qualität der Software insgesamt. Der Aspekt der Qualität spielt demzufolge für die Modellierung einer Softwarearchitektur ebenfalls eine entscheidende Rolle, da im Rahmen der Modellierung Entscheidungen zu treffen sind, die großen Einfluss auf die spätere Erfüllung bestimmter Qualitätsmerkmale durch die Software haben.

Eine Software muss über die reine Funktionalität hinaus gehende, so genannte nicht-funktionale Qualitätsanforderungen erfüllen. Dies sind nach [BaCK2003, S.74] die folgenden sechs Attribute, die eine Software in unterschiedlich starker Ausprägung realisiert:

- Verfügbarkeit

Gibt Auskunft darüber, in welchem Umfang die Software zur Bearbeitung einer gegebenen Aufgabe genutzt werden kann. Die Verfügbarkeit kann eingeschränkt werden sowohl durch Belastungen des Systems als auch durch Fehler (vgl. [MeLe2003, S.702]).

- Modifizierbarkeit

Gibt an inwieweit die Software an veränderte Anforderungen angepasst werden kann (vgl. [MeLe2003, S.604]).

- Performanz

Bezeichnet die Geschwindigkeit, mit der die Software eine Aufgabe bzw. eine Menge von Aufgaben verarbeitet (vgl. [MeLe2003, S.364]).

- Sicherheit

Beschreibt in welchem Maß die Software Sicherheitsaspekte wie Korrektheit, Datenschutz oder Schutzmechanismen in Bezug auf unberechtigten Zugriff erfüllt (vgl. [MeLe2003, S.98]).

- Testbarkeit

Gibt an wie gut sich das Eingabeverhalten und das Ausgabeverhalten der Software, anhand von Experimenten und Programmdurchläufen testen und beurteilen lässt (vgl. [MeLe2003, S.662]).

- Verwendbarkeit

Gibt an inwiefern sich das System gemäß seiner Bestimmung verwenden lässt und wie leicht bzw. verständlich die Handhabung ist (vgl. [MeLe2003, S.604]).

Die Frage was eine Architektur zu einer guten oder schlechten Architektur macht, kann in diesem Zusammenhang nicht eindeutig beantwortet werden, da es keine allgemeingültige Definition oder Kriterien gibt, um schlechte von guten Architekturen abzugrenzen. Softwarearchitekturen sind vielmehr im Kontext einer gegebenen Problemstellung zu sehen. Das heißt, sie sind lediglich mehr oder weniger geeignet um ein bestimmtes Problem zu lösen. Aus diesem Grund sollte die Evaluation einer Architektur auch immer im Bezug auf die jeweiligen Ziele und Anforderungen der zu entwickelnden Software stattfinden [BaCK2003, S.15].

2.2.2 Einflussfaktoren von Softwarearchitekturen

Eine Softwarearchitektur steht immer in einem Kontext. Die Beziehungen der Architektur zu ihrer Umwelt, in der sie konstruiert und verwendet wird, sind von großer Bedeutung, da die Architektur ein Ergebnis technischer, geschäftlicher und sozialer Einflüsse darstellt [BaCK2003, S.8]. Zwischen diesen Einflussfaktoren und der Softwarearchitektur existiert eine kontinuierliche Wechselwirkung. Auf der einen Seite wird die Architektur beeinflusst von der technischen, geschäftlichen und sozialen Umwelt, diese werden aber auf der anderen Seite wiederum selbst von der Architektur beeinflusst. Diese Wechselwirkung kann als Architecture Business Cycle (ABC) bezeichnet werden [BaCK2003, S.5].

Als Einflussfaktoren für eine Softwarearchitektur, sind nach [BaCK2003, S.6ff] die folgenden zu nennen:

- Die Entwickelnde Organisation

Sowohl die Struktur der Organisation die eine Software entwickelt als auch die zur Verfügung stehenden Ressourcen und dabei vor allem das vorhandene Personal und dessen Qualifikation, haben Einfluss auf die Architektur.

- Die Architekten

Die Architekten und ihre Erfahrung sind ein signifikanter Einflussfaktor. So können beispielsweise negative oder positive Erfahrungen der Architekten im Bezug auf bestimmte Architekturkonzepte oder Entwicklungsmethoden, Einfluss darauf haben, wie diese Architekten zukünftig bei der Entwicklung vorgehen und welche Konzepte und Methoden sie verwenden werden.

- Das technische Umfeld

Das technische Umfeld macht einen Einflussfaktor aus, da vom technischen Umfeld die Möglichkeiten abhängen, die dem Architekten, zum Beispiel in Form von Softwareentwicklungskonzepten oder Entwicklungstechniken, zur Verfügung stehen.

- Die Stakeholder

Bei den Stakeholdern einer Architektur kann es sich zum Beispiel um Kunden, Endbenutzer, Entwickler oder Projektmanager handeln. Sie alle haben unterschiedliche Vorstellungen, Erwartungen und Ziele bezogen auf das Softwaresystem und beeinflussen daher auch maßgeblich dessen Architektur. Für den Architekten ist es wichtig, möglichst viele ihrer Interessen zu berücksichtigen. Allerdings stehen die Interessen und Ziele der verschiedenen Stakeholder häufig in konfliktären Beziehungen zueinander. Zum Beispiel möchte ein Entwickler nach Möglichkeit über ausreichende Ressourcen in personeller, zeitlicher und finanzieller Hinsicht verfügen können, während für das Management der entwickelnden Organisation, geringe Kosten und eine geringe Entwicklungszeit im Vordergrund stehen. Aufgrund derartiger konfliktärer Zielbeziehungen ist es erforderlich, über gemeinsame Ziele zu diskutieren. Diese können in Form von so genannten Anforderungsdokumenten (engl.: Requirement Documents) festgehalten werden (vgl. [BaCK2003, S.7]).

[...]


[1] Weitere Definitionen: http://www.sei.cmu.edu/architecture/definitions.html

Ende der Leseprobe aus 40 Seiten

Details

Titel
Modellierung und Dokumentation von Softwarearchitekturen
Hochschule
Universität Duisburg-Essen
Note
1,3
Autor
Jahr
2005
Seiten
40
Katalognummer
V75307
ISBN (eBook)
9783638798167
ISBN (Buch)
9783638807166
Dateigröße
586 KB
Sprache
Deutsch
Schlagworte
Modellierung, Dokumentation, Softwarearchitekturen
Arbeit zitieren
Christian Kahl (Autor:in), 2005, Modellierung und Dokumentation von Softwarearchitekturen, München, GRIN Verlag, https://www.grin.com/document/75307

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Modellierung und Dokumentation von Softwarearchitekturen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden