3 Konfigurationsmöglichkeiten von Software

3.4 Ergebnisse der Analyse von Konfigurationskonzepten



3.4.1 Zusammenfassung der Ergebnisse

Vorgestellt wurden Konzepte zur Entwicklung von Systemfamilien, die für den flexiblen Einsatz von wiederverwendbaren Komponenten für die Ableitung von Systemfamilien verwendet werden können. Dazu gehörten Paradigmen, Konzepte, Tools und Architekturen, deren Vorgehensweise und Anwendbarkeit im Laufe des Softwareentwicklungsprozesses erläutert wurden. Hier wurden Vor- und Nachteile aus der Literatur zusammengefasst. Dazu kamen standardmäßig verwendete Konzepte des Konfigurationsmanagements von Windows und Linux.
Für das FORE-Modell kann aus den Analyseergebnissen abgeleitet werden, dass von Anfang an eine konsistente Modellierung der Anforderungen für grundlegende Architekturentscheidungen in den ersten Phasen des Entwicklungsprozesses wichtig ist, da komponentenbasierte Systemfamilien nicht aus traditionellen Softwareprojekten abgeleitet werden können.
Die Verwendung von Komponenten spart dabei Zeit und Geld und kanalisiert Wissen vorhergehender Programmentwicklungen. Sauber gestaltete Systeme lassen sich auch später besser warten, erweitern und modifizieren. Generatoren, die z.B. auf GenVoca basieren, fokussieren dabei die vollständige Ableitung von Familienmitgliedern und benötigen dafür ein konsistente regelbasierte Grammatik.
Deswegen sollten von Anfang an bei Abschluss der Anforderungserhebung verschiedene Sichtweisen und Zusammenfassungen nicht nur aus herkömmlicher funktionaler Sicht erfolgen, sondern auch andere Gesichtspunkte wie Aspekte, Funktionsgruppen, Schichten oder Architekturgrundgerüste modelliert werden, um so die sich anschließende Entscheidung für die Grobarchitektur und die zu verwendenden Technologien zu erleichtern und für die Implementierung bereits einen Grundstein für die Vorgehensweise des Programmentwurfs zu schaffen. Die Entscheidung für die Entwicklung von Systemfamilien sollte bereits in der Planungsphase feststehen.
Des Weiteren hat dieses Kapitel aufgezeigt, welche Konzepte für die Hinterlegung von Software in den beiden meist verbreiteten Betriebssystemen zur Laufzeit verwendet werden. Generell kann man davon ausgehen, dass jedes Problem hier seiner spezifischen Lösung bedarf. Ein einfaches Anwendungsprogramm, welches keinerlei Kommunikation mit anderen Programmen benötigt, ist mit der einfachen und übersichtlichen Struktur einer Textdatei gut beraten. Dagegen bedarf die Mächtigkeit eines Betriebssystems eines leistungsstarken, wie auch komplexen Aufbaus einer Datenbank. Auch vom Sicherheitsaspekt her ist es sinnvoller, systemweite Einstellungen versteckt und verschlüsselt zu hinterlegen. Die Verschlüsselung kann bei linuxbasierenden Softwareprojekten jedoch nicht angewendet werden, da diverse Lizenzen auch bei weiterentwickelter Software dies verbieten.
Sinnvoll im Zusammenhang mit der Erstellung von Systemfamilien wäre die Entwicklung eines Kataloges ähnlich der Bestrebungen der FH Mannheim, in dem über bestimmte Kriterien in einem Modell die richtigen Hilfsmittel ausgewählt werden können. Hierzu müsste das entsprechende Wissen gesammelt und aufbereitet werden. Dies könnte z.B. mit Hilfe von erweiterten und bewerteten Merkmalsmodellen für die Katalogisierung der Softwareanforderungen und Systemeigenschaften geschehen159.
Die hier vorgestellten Konzepte seien im Folgenden zusammengefasst:


Dabei wurden die Kriterien in Anlehnung an die DIN ISO 9126 verwendet. Dies umfasst160:
  • Funktionalität als Sammelbegriff für den Umfang der angebotenen Funktionen, der Richtigkeit der Ergebnisse und die Verträglichkeit mit anderen Systemen oder Komponenten und der Eignung für die Praxis.
  • Zuverlässigkeit als Merkmal der korrekten Arbeitsweise bei normalen und erschwerten Bedingungen, dem Aufwand bei Wiederaufnahme der Lauffähigkeit und Reaktion bei Verfälschung oder Datenverlust.
  • Benutzbarkeit als Kriterium für die Verständlichkeit, Handhabbarkeit und Erlernbarkeit des Konzeptes.
  • Effizienz als Zeitdauer und Ressourcenbedarf wie Speicherplatz und Prozessorleistung bis zum Ergebnis.
  • Änderbarkeit als Maß für die Wartbarkeit, Durchführbarkeit, Verständnisdauer des Programms, Stabilität und Überprüfbarkeit des Konzeptes.
  • Übertragbarkeit als Kennzeichen für den Aufwand der Implementierung, für die Anpassbarkeit an andere Umgebung und für die Schnittstellenverträglichkeit.
Aus den Ergebnissen dieser Tabelle geht hervor, dass alle Konzepte und Methoden mehr oder weniger zu der Softwarequalität beitragen. Oft werden aufgrund der Komplexität des Konzeptes Abstriche gemacht. Trotzdem kann nicht allgemeingültig gesagt werden, dass sich gewisse Konzepte schlechter eignen, sondern einfach für andere Projekte geeignet sind.
So reduziert die Mächtigkeit und Fehlerintoleranz einer Windows Registry die Benutzbarkeit, erhöht aber die Funktionalität umso mehr. Die Generative Programmierung dagegen bietet unter Einbußen der Benutzbarkeit und Änderbarkeit einen hohen Funktionsumfang und lässt sich einfach übertragen.
Komponenten- und Pluginarchitekturen unterstützen überdurchschnittlich viele Kriterien, und werden auch immer häufiger aufgrund ihrer flexiblen Struktur eingesetzt.

3.4.2 Ergebnisse für die Konfiguration der VDR-Software

Für die Konfiguration der Live-CD wird anhand der Analyseergebnisse und den bereits vorhandenen Plugins die Weiterführung des Pluginmodells verfolgt.
Die Konfigurationsdaten selbst werden dabei in einzelnen unverschlüsselten Textdateien vorgenommen, die mit dem XML-Format ausgedrückt werden, da das Projekt einen relativ geringen Umfang hat.
Bei größeren Projekten würden die positiven Aspekte einer datenbankorientierten Konfiguration überwiegen. Das XML-Format wird auch deshalb gewählt, da die Anforderungen und Eigenschaften des DVP-Projekts bereits in XML vorliegen. Zudem bietet XML eine Unterstützung dynamischer Inhalte, bessere Lesbarkeit und große Unterstützung auf internationaler Ebene, da XML das Datenaustauschformat der Zukunft ist.161


  • 159: Vgl. [Arno 2005] Folie 56 ff
  • 160: Vgl. [Balz 2001] S. 1113 und [Phil 2005] S. 46 ff
  • 161: Vgl. [Micr 2005-2]

 


Top| Home| << Zurück | Nächste >>
" TARGET="_blank"> >> Home Page <<