Ausarbeitung

Seminar im Bereich Informatik der Systeme
Seminar Komponentenbasierte Softwareentwicklung
Wintersemester 2005/06
Seminarausarbeitung
Wartung und Evolution
Jens Brauckmann
15.02.2006
Universität Duisburg-Essen · Fachbereich Ingenieurwissenschaften · Abteilung Informatik
Arbeitsgruppe Software Engineering – Prof. Dr. M. Heisel
betreut durch: Dipl.-Inform. Isabelle Cote

Inhaltsverzeichnis
1 Einführung 1
2 Herausforderungen der Wartung und Weiterentwicklung 2
2.1 Verwaltung von Komponenten und Konfiguration . . . . . . . . . . . . . 2
2.2 Systemüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Troubleshooting und Reparaturen . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Systemanpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Faktoren für eine erfolgreiche Wartung und Weiterentwicklung 5
3.1 Systemdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Kontrolle und Übersichtlichkeit . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Systementwicklung für erfolgreiche Wartung und Weiterentwicklung . . 6
4 Weiterentwicklung von Komponentenbasierten Systemen 8
4.1 Evolution eines komponentenbasierten Systems . . . . . . . . . . . . . . 9
5 Fazit 11
6 Literaturverzeichnis 12
i

1 Einführung
Die Anforderungen an Softwaresysteme werden immer umfassender und weitreichender.
Diese Anforderungen schlagen sich in einem erhöhten Entwicklungsaufwand und
Komplexität der Implementierungen nieder, was neue Konzepte für die Entwicklung
von Software-Systemen erforderte. Die Nutzung von Softwarekomponenten zur Entwicklung
von Softwaresystemen ist ein Konzept, das unter anderem die Entwicklungszeit
zu verkürzen sucht. Nach der Inbetriebnahme der Software beginnt jedoch erst der
zeit- und aufwandintensivste Teil im Entwicklungskreislauf der Softwareentwicklung:
die Wartung und Weiterentwicklung[Cle95]. Mit circa zwei Drittel des Gesamtbudgets
für den Bau und Betrieb eines Softwaresystems ist die Wartung der Kostenintensivste
Teil des Entwicklungskreislaufes /citeGal04. In dieser Arbeit soll nun die Wartung und
Weiterentwicklung von komponentenbasierten Systemen betrachtet werden. Es soll im
Kapitel 2 dargestellt werden, welche Anforderungen an die Wartung von komponentenbasierten
Systemen gestellt werden. In Kapitel 3 soll betrachtet werden welche
Maßnahmen im Design eines komponentenbasierten Systems die Wartung und Weiterentwicklung
vereinfachen können. Im Kapitel 4 soll betrachtet werden nach welchen
Regeln die Weiterentwicklung von Komponenten erfolgen kann, um Komponentennutzern
die Einbindung und Wartung ihrer Systeme zu erleichtern.
1

2 Herausforderungen der Wartung
und Weiterentwicklung
Die Aufgaben der Wartung und Weiterentwicklung von komponentenbasierten Systemen
erstreckt sich vom Beobachten des Systems, über die Komponentenverwaltung,
Konfiguration und Reparaturen bis hin zu Systemanpassungen für Weiterentwicklung
oder durch Komponentenveränderungen. Im Gegensatz zu herkömmlichen Systemen
findet die Wartung von komponentenbasierten Systemen nicht ausschließlich auf der
Sourcecode-Ebene statt, sondern ist auf die Zugriffsmöglichkeiten der Komponenten
angewiesen, was herkömmliche Vorgehensweisen erschweren kann.
2.1 Verwaltung von Komponenten und Konfiguration
Für die Verwaltung eines komponentenbasierten Systems und die Entscheidungsfindung
für das System ist es notwendig, dass Informationen über die historischen Entwicklung
des Systems, der verwendeten Komponenten und ihre verwendeten Funktionen,
entsprechende Lizenzvereinbarungen und Supportverträge. Kontaktadressen
und Informationen über den Supportumfang eines Komponentenherstellers gehören
ebenso zu den benötigten Verwaltungsinformationen, wie Kompatibilitätsinformationen
der Komponenten. Ein guter Überblick über alternative Komponenten und absehbare
Entwicklungsrichtungen verwendeter Komponenten sind auch nach Abschluss der
Entwicklungsphase wichtig, um eigene Weiterentwicklungen zu planen. Auf Grundlage
dieser Informationen muss entschieden werden, ob Komponenten bei Problemen
ersetzt werden sollen oder ob Komponenten bei der geplanten Weiterentwicklung des
Systems weiter Verwendung finden sollen. Zudem muss entschieden werden ob Patches
eines Komponentenherstellers eingespielt werden sollen. Es kann z.B. passieren, das ein
Hersteller keinen Support für eine Komponente anbietet, wenn die aktuellen Patches
nicht eingespielt worden sind.[Leh00] Werden Komponenten mit offenen Sourcecode
verwendet, muss Buch über Änderungen im Sourcecode geführt werden, um bei späteren
Versionen diese Änderungen zu übernehmen. Generell sollte eine Manipulation
des Sourcecodes einer Komponente aber (soweit möglich) vermieden werden.
2.2 Systemüberwachung
Die Überwachung von Systemeigenschaften und -verhalten gehört ebenfalls in den Bereich
der Systemwartung. Performanceüberwachung von Komponenten und Resourcen
- Ausnutzung kann bei Komponenten die als Black-Box in ein System integriert sind
2

schwierig sein, da man nur Herstellerangaben als Vergleichswerte heranziehen kann.
Schwierigkeiten können z.B. eine erhöhte Resourcennutzung durch falsche Einbindung
einer Komponente sein.Sicherheits-Aspekte spielen für Komponenten, die an das Internet
angeschlossen sind, eine besondere Rolle. Hier ist eine Überwachung von Internetzugriffen
der Komponenten, Zugriffen vom Internet auf die Komponente und der
Menge der gesendeten Daten sinnvoll um sicher zu stellen, das unbefugte keinen Zugriff
auf das System erhalten.
2.3 Troubleshooting und Reparaturen
Treten in einem laufenden, komponentenbasierten System Unregelmäßigkeiten auf, ist
man auf die Analysemöglichkeiten, die von den verwendeten Komponente bereitgestellt
werden, angewiesen. Die Möglichkeiten die von Komponenten bereitgestellt werden,
können dabei von einem Zugriff auf den Sourcecode bis hin zu einer Beschränkung auf
die Ein- und Ausgangsignale einer Black-Box-Komponente reichen. Bei der Analyse
eines Systems mit einer großen Anzahl verschiedener Komponenten wird man daher
flexible auf verschiedene Analysemethoden zurückgreifen müssen. Darunter fallen
die Analyse von Ein- und Ausgangssignalen oder Fehlermeldungen von Black-Box-
Komponenten, Sourcecodeanalyse durch schrittweise Testen des Codes, Test in speziellen
Testumgebungen von Komponenten, usw. . Bei diesen Tests ist man häufig auf
die Dokumentation oder die Hilfe des Komponenteherstellers (Support) angewiesen.
Kann der Fehler auf eine Komponente zurückgeführt werden, muss geprüft werden
ob der Hersteller eine Problembehebung vornehmen kann, oder ob die Komponente
ersetzt werden sollte, oder ob eine Lösung des Problem durch Systemeingriffe behoben
werden kann. Problematisch kann dabei die Kontaktnahme zum Hersteller auf Grund
von Sprach- oder Zeitzonenunterscheide sein. Zudem kann die Bereitstellung eines Patches
oder Updates des Herstellers je nach Herstellerpriorität einige Zeit in Anspruch
nehmen.
2.4 Systemanpassung
Zu den Systemanpassungen komponentenbasierter Systeme gehören sowohl Sourcecodeerweiterungen
für weiter Komponeten, Modelanpassungen, Updating von Komponenten,
als auch das Ersetzen, Einfügen und Löschen von Komponenten. Komponentebasierte
Systeme unterliegen ebenso den Weiterentwicklungsansprüchen wie andere
Softwaresysteme. Wie von[Leh00] ausführlich diskutiert müssen sich auch komponentenbasierte
System beständig den Wünschen und Anforderungen der Nutzer anpassen,
um weiterhin für den Nutzer attraktiv zu sein. Dazu gehören sowohl das Anpassen von
Funktionen, als auch Funktionserweiterungen und Interfaceverbesserungen. Für Erweiterung
des Funktionsumfanges können neue Komponentenimplementierungen notwendig
sein. Die erforderlichen Anpassungsmaßnahmen am Sourcecode und am Komponentenmodel
entsprechen denen der Systementwicklung. Veränderungen des Komponentenmodels
können sich als sehr schwierig erweisen, insbesondere wenn die Erweite-
3

ung nicht den Zielsetzungen des Models entspricht. Ein Beispiel für die Schwierigkeiten
einer Systemerweiterung kann hier [Akk02] gefunden werden. Eine Besonderheit der
Weiterentwicklung komponentenbasierter Systeme ist die Abhängigkeit der Komponenten,
die sich unabhängig von dem System entwickeln können. In Kapitel 4 wird
detaillierter auf die Weiterentwicklung von Komponenten eingegangen werden. Soll
eine neue Version einer verwendeten Komponente in das System eingespielt werden,
kann dies eine Anpassung des Komponenteninterfaces notwendig machen, entsprechend
den Vorgaben der neuen Komponentenversion. Wird eine Komponente in eine für das
System ungünstige Richtung weiterentwickelt, muss entschieden werden, ob die Komponente
auf dem alten Versionsstand weiter im System verbleiben soll, oder ob eine
neue Komponente die alte Komponente ersetzen soll. Im Falle einer Ersetzung müssen
Systemänderungen entsprechend den Vorgaben der neuen Komponente vorgenommen
werden.
4

3 Faktoren für eine erfolgreiche
Wartung und Weiterentwicklung
Bereits in der Entwicklungsphase eines Systems können Maßnahmen ergriffen werden,
die eine spätere Weiterentwicklung und Wartung des Systems stark vereinfacht und
kostengünstiger gestalten können. Der Systementwickler sollte als Wartungsverantwortliche
entsprechende Anforderungen an das System stellen und bei der Implementierung
berücksichtigen.
3.1 Systemdesign
Bei der Planung eines Systems kann bereits sichergestellt werden, das eine Vernetzung
von Komponenten untereinander vermieden wird. Je stärker Komponenten untereinander
vernetzt sind, desto umfangreiche und komplexer ist eine spätere Wartung der
Komponenten. Soll eine Komponente durch eine andere Version oder eine neue Komponente
ersetzt werden, kann dies Auswirkungen auf alle Komponenten haben, die mit
der ersetzten Komponente verknüpft sind. 3 Maßnahmen um eine leichtere Ersetzbarkeit
von Komponenten zu erreichen sollen hier kurz vorgestellt werden[HC01]:
3.1.1 Wrapper
Im Regelfall wir auf eine Komponente über ihr Interface zugegriffen und die erforderlichen
Aktionen ausgeführt. Wird eine Komponente durch eine andere Version oder eine
andere Komponente ersetzt, kann sich auch die Zugriffsart auf das Interface ändern.
Dies hat zur Folge, das alle Komponenten- und Systemzugriffe auf dieses Interface
geändert werden müssen. Um dies zu vermeiden kann ein Wrapper als Adapter für
die Komponente erstellt werden. Ein Wrapper verfügt über ein Interface, das alle
Komponente- und Systemzugriffe für die Komponente entgegen nimmt, und an das Interface
der Komponente weiter leitet. Ebenso werden alle ausgehenden Informationen
des Interfaces über den Wrapper weitergeleitet. Wird die Komponente nun durch eine
andere Komponente ersetzt, ist lediglich eine Anpassung des Wrappers nötig. Andere
Komponenten sind von der Veränderung des Komponenteninterfaces nicht betroffen.
Eine Ausnahme bilden schwerwiegende Veränderungen, durch die neue Parameter für
den Aufruf der Komponente benötigt werden. Diese Parameter müssen dem Wrapper
beim Komponentenaufruf bekannt gemacht werden. Solche schwerwiegenden Veränderungen
der Komponeten benötigen eine erheblich größere Wartungszeit für Anpassungen.
5

3.1.2 Facade
Komponenten die stark miteinander verknüpft sind erhöhen die Komplexität eines Systems
und damit die Wartungs- und Weiterentwicklungszeiten des Systems. Eine Vereinfachung
des Systems durch eine Reduktion von Vernetzungen oder zusammenfassen
von Komponenten vereinfacht die Wartung und erleichtert die Weiterentwicklung des
Systems. Werden mehrere Komponenten, die eine enge Vernetzung aufweisen, durch
ein Interface abgedeckt, bezeichnet man dies als Facade. Zugriffe auf diese Komponenten
erfolgen über die Facade, so das die Komplexität hinter der Facade dem Rest des
Systems verborgen bleibt. Bei Wartungs- oder Erweiterungsarbeiten an diesen Komponenten
wirken sich die Änderungen somit in ihrer vollen Komplexität nicht auf das
gesamte System aus, sondern nur die Änderungen die an der Facade notwendig waren
erfordern Anpassungen im System.
3.1.3 Mediator
Ein weiterer Faktor, der die Komplexität eines Systems erhöht ist ein aufrufendes
Verhalten der Komponenten untereinander. Ist die Systemstruktur so aufgebaut, das
Komponenten andere Komponenten aufrufen, muss bei einer Änderung einer Komponente
im gesamten System geprüft werden, welche Komponenten Zugriff auf diese
haben. Erfolgen alle Aufrufe durch einen zentralen Mediator, muss lediglich hier geprüft
werden, wann und wie dieser Mediator die Komponente aufruft.
3.2 Kontrolle und Übersichtlichkeit
Eine weitere erleichternde Maßnahme für die Wartung und Überwachung des Systems
ist die Implementierung eines Management-Interfaces das die Funktionen der Komponenteninterfaces
für eine Überwachung der Komponente bündelt, und dem Systemadministrator
zur Verfügung stellt. So erhält ein Systemadministrator eine Übersicht
über aktiverte Komponenten und ihre Ein- und Ausgabeereignisse. Eine solche
Funktion erleichtert die Überwachung und ermöglicht eine schnellere und Präzisere
Eingrenzung von Problemen während der Laufzeit. Es gibt verschiedene Bemühungen
einer automatischen Überwachung von komponentenbasierten Systemen, wie z.B. von
[Zul04] die jedoch noch nur bestimmte Probleme erkennen.
3.3 Systementwicklung für erfolgreiche Wartung und
Weiterentwicklung
Weiter wichtige Faktoren für die Minimierung des Wartungs- und Weiterentwicklungsaufwands
ist die Wahl der Komponenten. Ob und wie sich der Anbieter einer Komponente
für deren Weiterentwicklung oder Problembehebung entscheidet, kann nicht mit
Sicherheit vorhergesagt werden. Es gibt jedoch Kriterien die eine einfache Wartung
und Weiterentwicklung erleichtern.
Die Offenheit und Zugriffsmöglichkeiten einer Komponente sind ebenso ein Faktor für
6

die einfache Wartung, wie die Möglichkeiten die eine Komponente zur Anpassung an
das System z.B. durch Konfigurationsdatein oder Scriptinterfaces vorgibt. Ein weiterer
wichtiger Faktor ist die Wahl eines Komponentenmodell, das die Wartung durch
Übersichtfunktionen und einfache Integration von Komponenten erleichtert. Zuletzt
sollte bei der Wahl der Komponenten darauf geachtet werden, das der Support des
Komponentenherstellers für die Komponente ausreichend ist, und die Komponenten
gut Dokumentiert sind. Ein etablierter Komponentenhersteller senkt zudem das Risiko,
dass Komponenten zu einem späteren Zeitpunkt nicht länger weiterentwickelt oder
gewartet werden.
Eine häufig geforderte Möglichkeit, die Komponenteauswahl für Entwicklung und
Wartung von Komponentenbasierten Systems zu erleichtern, ist die Zertifizierung von
Komponenten. Zertifikate könnten für Integrierbarkeit, Zuverlässigkeit, Sicherheit, usw.
vergeben werden, was sich ebenfalls Positiv auf die Wartung von Komponenten auswirken
könnte.
7

4 Weiterentwicklung von
Komponentenbasierten Systemen
Wie bereits im Kapitel 2 erwähnt, spielt die Weiterentwicklung von Komponente eine
bedeutende Rolle in komponentenbasierten Systemen. Um den Systementwicklern
den Umgang mit den Komponente zu erleichtern können die Komponentenhersteller
Maßnahmen ergreifen um die Integration neuer Versionen zu erleichtern und das
System damit weiter zu entwickeln. [Lob05] haben einige allgemeingültige Regeln für
die Komponenten-Weiterentwicklung erarbeitet, die ein für den Komponentennutzer
übersichtliche Versionierung von Komponenten ermöglich. In der Studie gehen sie von
einem Komponentemodel aus, welches eine abstrakte Beschreibung und eine konkrete
Implementierung der Komponente hinter einem Interface verwendet. Die Art der
Komponentenveränderung wird in Modifizierung, Erweiterung und Reduktion der Eigenschaften
einer Komponente unterteilt. Die Einführungsauswirkungen einer solchen
Änderung können niedrig, mittel oder schwer sein, wobei eine leichte Auswirkung die
Implementierung der neuen Version ohne Anpassungen im System bedeuten, eine mittlere
Auswirkung Adaptionsänderungen im System nötig macht, und eine schwere Auswirkung
bedeutendere Anpassungen im System erfordert. Lobo u.a. haben 5 Evolutionsregeln
für die Anwendung mit den abstrakten Komponenten und 2 weitere Regeln
für die Anwendung mit konkreten Komponenten aufgestellt, mit deren Hilfe eine Einordnung
vom Grad der Veränderung der Komponente ermittelt werden können. So
sagt z.B. Regel 3: Eine Modifikation welche die Eigenschaften eines Interfaces von T1
nach T2 verändert, wird interpretiert als:
1) eine Erweiterung, wenn T1 ein Subtyp von T2 ist
2) eine Reduktion, wenn T2 Subtyp von T1 ist oder
3) eine Erweiterung und Reduktion, wenn es keine Subtyp-Relation zwischen T1 und
T2 gibt.
So kann mit Hilfe dieser Regel und einer Tabelle, an der die Eigenschaften und Relationen
mit der Art der Veränderung abgetragen sind, der Veränderungsgrad der
Komponente abgelesen werden.
So kann man z.B. in der Tabelle in Abbildung 4.1 sehen, dass eine Erweiterung der
unterstützen Interfaces nur einen geringen Änderungsgrad hat, und die Komponente
damit ohne Probleme in ein System integriert werden kann.
Die Regeln 8 und 9 beschreiben dann, wie die Versionsnummerierung in der Form
x.x.x angegeben werden soll, um die neue Versionsnummer zu ermitteln. Der Grad
einer Veränderung spiegelt sich dann in einer Versionsnummer wieder, wobei die erste
Ziffer eine schwerwiegende Veränderung mit einem großen Implementierungsaufwand
für das System angibt, die zweite Ziffer eine mittlere Veränderung die Adaptionen im
8

Abbildung 4.1: Tabelle für abstrakte Komponenten nach [?]
Abbildung 4.2: Tabelle für konkrete Komponenten nach [?]
System notwenig macht, und die dritte Ziffer leichte Veränderungen anzeigt, die ohne
Probleme in das System übernommen werden kann. Wird eine Ziffer der Versionsnummer
erhöht, werden die rechts stehenden Ziffern auf Null gesetzt, unabhängig davon
ob diese Ziffern mit der neuen Version auch angehoben werden sollten. Ausgehen von
einer Ursprungsversion 1.0.0 kann der Komponentennutzer dann bereits anhand einer
Versionsnummer eine grobe Aufwandsschätzung für die Integration der Komponente
in das System anstellen.
4.1 Evolution eines komponentenbasierten Systems
Lobo u.a. geben zudem noch einige Schritte für die Evolution eines komponentenbasierten
Systems durch die Weiterentwicklung von Komponenten an. Als Voraussetzung
soll angenommen werden, das bereits in System implementiert ist, und das eine Änderungsanforderung
vorliegt. Es werden dann 6 Schritte durchgeführt:
1. Analyse der Veränderungsanforderung
Es wir zunächst ermittelt, welche Komponenten für eine Erweiterung des Systems geändert
werden müssen. Im Anschluss wird geprüft welche Interfaces geändert werden
müssen, und ob Komponenten die auf diese Interfaces zugreifen auch angepasst werden
müssen.
2. Veränderung Planen
Es wird geplant, welche Veränderungen an welcher Komponente durchgeführt werden
müssen und die Versionsnummer wird durch das in Kapitel 4 kurz vorgestellte Verfahren
ermittelt. Bei der Planung sollte immer darauf geachtet werden, das die neue Komponentenversion
einfach im System zu implementieren ist, der Wiederverwendungswert
für andere Systems aber möglichst hoch bleibt. Auch die Systemveränderungen sollten
hier bereits geplant werden.
3. Veränderungen Implementieren und Komponententests
9

Ist die Planung der Veränderungen abgeschlossen, kann begonnen werden die Implementierung
des Komponentenänderungen vorzunehmen. Die Komponenten müssen im
Anschluss überprüft werden, ob die Änderungen wie geplant funktionieren und ob die
Funktionen der Vorgängerversion weiterhin korrekt arbeiten.
4. Integration im System und Systemtests
Erst wenn die Komponenten getestet worden sind, wird begonnen sie in das System zu
integrieren. Die dafür erforderlichen Änderungen am System werden ebenfalls in diesem
Schritt durchgeführt. Im Anschluss werden die Veränderungen entsprechen den
Anforderungen getestet, aber auch die Funktionen der Vorgängerversion müssen noch
korrekt arbeiten.
5. System einführen und Akzeptanz testen
Im nächsten Schritt wird nun das System veröffentlicht und geprüft, ob es von den
Nutzern akzeptiert wird, oder ob Praxisprobleme auftreten.
6. Neuen Komponenten veröffentlichen
Im letzten Schritt werden nun erst die neuen Versionen der Komponenten veröffentlicht,
damit diese Versionen in andere Systeme integriert werden können. Die Komponenten
sollten mit einer ausführlichen Beschreibung zu den Änderungen und dem
wahrscheinlichen Aufwand für eine Implementierung versehen werden. Eine Anleitung
oder Hilfestellung zur Integrierung der Komponenten trägt ebenfalls zu einer schnelleren
Integrierung in andere Systeme bei.
Lobo u.a gehen hier scheinbar davon aus, das Systemweiterentwicklung und Komponentenweiterentwicklung
stets in die selbe Richtung gehen. Lobo u.a. weisen zwar
darauf hin, das die Integration von "Components of the shelf"(COTS) noch keine
Berücksichtigung gefunden hat, jedoch wird nicht in Erwägung gezogen, das die Komponentenentwicklung
und damit auch die Weiterentwicklung nicht immer auf ein bestimmtes
System hin geschieht. Ebenso ist es für denen Systementwickler nicht immer
möglich, Einfluss auf die Entwicklung von Komponenten zu nehmen. Bei der Weiterentwicklung
von Systemen ist also nicht nur zu prüfen, ob Komponenten weiterentwickelt
werden müssen, sondern auch ob Komponenten ersetzt werden oder neue
Komponenten integriert werden können. Dazu kann das Vorhanden sein von neuen
Komponenteversionen durchaus als Anreiz zu einer einfach Systemweiterentwicklung
angesehen werden (z.B. wenn die Komponente nur eine Updateversion ist und ohne
Systemänderungen in das System übernommen werden kann.
10

5 Fazit
Die Wartung und Weiterentwicklung von komponentenbasierten Systemen werden
durch die Verwaltung vieler verschiedener Komponenten schwieriger und umfangreicher.
Das Eingrenzen von Problemquellen wird durch die Verwendung verschiedener
Analysemöglichkeiten unterschiedlicher Komponenten aufwendiger und man ist teilweise
auf den Support durch den Hersteller angewiesen. Der Integrationsaufwand neuer
Komponenten oder neuer Komponenteversionen kann sehr umfangreich sein und
ist häufig schwer abzuschätzen. Weiterentwicklungen des Systems sind abhängig von
Komponentenmodel und den zur Verfügung stehenden Komponenten oder der Weiterentwicklung
verwendeter Komponenten. Eine Verringerung des Wartungs- und Weiterentwicklungsaufwandes
kann aber durch Designmaßnahmen bei der Entwicklung des
Systems erreicht werden. Zertifizierungen und Standarts von Komponenten, könnten
die Auswahl von Komponenten im Bezug auf Wartung und Weiterentwicklung vereinfachen.
Ein Verfahren zur Weiterentwicklung von Systems ist vorgestellt worden, es
bestehen jedoch noch einige Problem in dem System, so das es noch nicht als allgemeingültig
angesehen werden kann.
11

6 Literaturverzeichnis
[Akk02] Attila J. / Nurminen Jukka K. Akkanen, Jyrik / Kiss. Evolution of a Software
Component - Experience with a Network Editor Component. IEEE Computer
Society, 2002. Proceedings of the Sixth European Conference on Software
Maintenance and Reengineering.
[Cle95] Paul C. Clements. From Subroutines to Subsystems: Component-Based Software
Development. American Programmer, 1995. November / Vol. 8, No.
11.
[HC01] George Heineman and William Councill. Component-Based Software Engineering
- Putting the Pieces Together. Addison-Wesley, 2001.
[Leh00] J.F. Lehmann, M.M. / Ramil. Software evolution in the age of componentbased
software engineering. IEE Proceedings Software, 2000. December / Vol.
147, No.6, Site 249-255.
[Lob05] Ana Elisa C. / ua. Lobo. A Systematic Approach for the Evolution of Reusable
Software Components. ACE 2005 homepage, 2005. Last visited: 10.02.2006.
[Voa98] Jeffrey Voas. Maintaining Component-Based Systems. IEEE Software, 1998.
July/August, Site 22-27.
[Zul04] Rudolph Zulkernine, Mohammad / Seviora. Towards automatic monitoring
of component-based software systems. The Journal of Systems and Software,
2004. Vol.74, Nr.1, Site 15-24.
12