Thema. Strukturierung von Software Studienarbeit Fakultät ...

Thema. Strukturierung von Software
Studienarbeit
Fakultät Informatik
Hochschule Reutlingen
Reutlingen University
Studiengänge Wirtschaftsinformatik
Alteburgstraße 150
72762 Reutlingen
Bearbeiter
Markus Riegger
Angelstraße 13
72406 Bisingen
Betreuer
Prof. Dr. Laux
07.11.2012

1
Einführung
In diesem Dokument möchte ich über das Thema “Strukturierung von Software”
schreiben. Dabei werde ich mich an den Vortrag von Barbara Liskov von der
Massachusetts Institute of Technology (MIT) zum Thema „Programming the Turning
Machine“ beziehen. In den einzelnen Kapiteln wird es um Komplexität von Software, die
Geschichte von Softwarearchitekturen, die Modularisierung und Objektorientierung in
Softwareprojekten gehen. Dabei werde ich auch auf die von Frau Liskov entwickelter
Programmierusprache CLU eingehen.
2

2
Die Geschichte der Softwarearchitektur
Frau Liskov spricht in dem Vortrag ihre Projekte aus den 70er Jahren an. Die
Geschichte der Softwarearchitektur begann jedoch schon früher. Der Beginn der
Strukturierung von Software war die Softwarekrise Mitte der 60er Jahre. Auslöser der
Krise war, dass die Kosten für Software zum ersten Mal die Kosten der Hardware
überschritten haben. Die Techniken konnten mit der Komplexität der Software nicht
mehr mithalten. Dies brachte große Softwareprojekte zum scheitern. 1 Zum ersten Mal
wurde der Begriff „Softwarearchitektur“ in einem Tagungsband einer von der NASA
finanzierter Konferenz erwähnt. Dies war im Jahr 1969. David Parns schrieb im Jahre
1972 einen Artikel über Kritereien für Modulkomposition von Softwaresystemen. Dabei
legte er die ersten Konzepte und Ideen für Softwarearchitekturen fest. Dewayne Perry
und Alexander Wolf veröffentlichen im Jahre 1992 einen Artikel in dem sie die Formel
"Elemente + Form + Rational = Softwarearchitektur" einführten. 1996 wurden die ersten
Entwurfsmuster für die Softwarearchitektur festgelegt. 1999 fand dann die erste
Konferenz speziell zum Thema „Softwarearchitektur“ statt.
Im Jahr 2000 wurde dann eine IEEE Norm zur Beschreibung von Softwarearchitektur. In
der Version 2.0 (veröffentlicht im Jahr 2003) eignet sich UML nun zur Modellierung von
Softwarearchitekturen. 2004 entstand bei der GI ein Arbeitskreis, welcher im Jahre 2006
das Buch „Handbuch der Software-Architektur“ veröffentlicht. In der Praxis sind die
Themen Cloud Computing, Mehrkernprozessoren, mobile Endgeräte und
Serviceorientierte Architekturen aktuell. Aktuelle Forschungsthemen sind
Wissensmanagement für Softwarearchitekturen, modellbasierte Analyseverfahren und
Softwareproduktlinien. 2
1 http://de.wikipedia.org/wiki/Softwarekrise Zugegriffen am 07.11.2012 14:20
2 http://de.wikipedia.org/wiki/Softwarearchitektur Zugegriffen am 07.11.2012 13:00
3

3
Komplexität von Software
In ihrem Vortrag geht Frau Liskov auf die Komplexität von Programmen ein. Heutige
Programme erreichen eine beachtliche Größe und die Komplexität richtet sich oft nach
genau dieser Größe. Durch jeden Technologiefortschritt erhöht sich diese stetig. Dabei
stellt sich die Frage wie man diese Komplexität des Quellcodes ermitteln kann.
Die Größe eines Programmes kann als Metrik zur Ermittlung der Komplexität eines
Programmes herangezogen werden. Nach Gary McGraw kann die Komplexität eines
Programmes wie folgt abgebildet werden. 3
Anzahl der Zeilen²
Bei diesem Maß gilt es zu beachten, dass ein Programm eine gewissen Länge
erreichen kann ohne eine große Komplexität zu enthalten. Stellen Sie sich vor sie
müssten in die Ausgabezeile die Zahlen 1-100 ausgeben. Dies kann entweder „hart“
codiert sein oder in einer Schleife ablaufen. Die Komplexität der ersten Methode wäre
100² = 10000. Die Komplexität bei einer Schleife wäre 3² = 9. Dies Zeigt obwohl die
Schleife für einen Programmierer schwerer zu verstehen ist erreicht sie einen deutlich
niederen Wert. 4
McGabe versucht mit der zyklomatischen Komplexität die Ermittlung zu verfeinern.
Hierbei werden die Verzweigungen zusätzlich berücksichtigt und in die Metrik
übernommen. Jedoch ist auch diese Methode ungenau.
Eine Eindeutige Bestimmung der Komplexität von Software ist nicht möglich. Die
Komplexität wird näherungsweise bestimmt. Jedoch kann die Anzahl der technischen
Fehler als weiterer Anhaltspunkt der Komplexität hinzugezogen werden. 5
Wodurch wird nun eine Erhöhung der Komplexität in Software ausgelöst?
Bereits Fred Brooks hat festgestellt, dass die Komplexität nur bis zu einem bestimmten
Bereich reduziert werden kann. Jedoch ist es für die Softwarequalität und die
Wartbarkeit von Softwaresystemen relevant diese möglichen Reduktionen
durchzuführen. Um eine anhaltende Wirkung zu erzielen muss die Verbesserung
durchgehend geschehen, weil sich die Softwarewelt dauernd ändert. Eine geringe
Komplexität vereinfacht hierbei die Softwaretest und Wartung des Systems. 6
Modularisierung bietet hier zum Beispiel eine Möglichkeit der Reduktion von der
Komplexität.
3 http://softwaresanierung.wordpress.com/2010/08/25/komplexitat-von-software/ Zugegriffen
am 07.11.2012 10:10
4 http://softwaresanierung.wordpress.com/2010/08/25/komplexitat-von-software/ Zugegriffen
am 07.11.2012 10:10
5 http://softwaresanierung.wordpress.com/2010/08/25/komplexitat-von-software/ Zugegriffen
am 07.11.2012 10:10
6 http://www.verifysoft.com/de_cmtpp_mscoder.pdf Zugegriffen am 07.11.2012 11:30
4

4
Modularisierung
In ihrem Vortrag spricht Frau Liskov über die Modualisierung von Software. Die
Modularisierung von Software ist aus heutiger Sicht nicht mehr wegzudenken. Der
Einsatz der Modularisierung bei Software dient dazu Software wiederverwertbar und
erweiterbar zu machen. Durch die Modularisierung ermöglicht eine kostengünstiger und
schnelle Entwicklung eines neuen Programms. 7 Mit Modularisierung wird das Aufteilen
einer Aufgabe in unterschiedliche Teilaufgaben bezeichnet. Diese Teilaufgaben sind
von einander unabhängig und können ohne Zugriff auf andere Module durchgeführt
werden. Als Module werden also autonome und rekonfigurierbare Systembausteine
benannt. 8
4.1
Moduleigenschaften
Um eine Modulübergreifende Kommunikation der Modul zu realisieren müssen
Schnittstellen zwischen beiden Modulen existieren. Der Output eines Moduls muss an
ein weiteres Modul weitergeleitet werden und dort als Import verarbeitet werden. Die
Versorgung eines Modul erfolgt mit Hilfe von Material-, Medien-, und
Informationsflüssen über standardisierte Schnittstellen. 9
4.2
Was gilt es bei Modularisierung zu beachten?
Ein wichtiger Punkt ist die Modulgeschlossenheit. Dabei ist ein Modul für eine in sich
geschlossene Aufgabe zuständig. Das bedeutet, wenn ein Modul zum Beispiel eine
Kennzahl berechnen soll ist die Berechnung mit Ende des Moduls abgeschlossen. Eine
Kennzahlenformel wird nicht auf mehrere Module verteilt.
Es muss auf eine Modulbindung geachtet werden. Modulbindung meint dabei die
Summe an Beziehungen die zwischen untergeordneten Modulen besteht. Dabei sollte
es keine Module ohne Modulbindung geben. Also keine Module die keinen
Zusammenhang mit einem anderen Modul.
Mit der Modulkopplung wird die stärke der Verbindung zwischen verschiedenen
Modulen. Die Größe der Modulkopplung gibt an wie viele Schnittstellen es gibt. Diese
müssen bei Weiterentwicklungen beachtet werden. Je mehr Modulkopplungen
existieren desto Fehleranfällig ist ein System. Es sollte also auf eine Minimalität von
Schnittstellen geachtet werden. Dabei gilt desto kleiner die Schnittstelle eines Moduls
7 http://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/auto/thesisKuhlemann.pdf Seite 7
Zugegriffen am 07.11.2012 15:14
8 http://www.fml.mw.tum.de/fml/index.php?Set_ID=320&letter=M&b_id=3444427B-4630-
3633-342D-424346442D34 Zugegriffen am 07.11.2012 15:30
9 http://www.fml.mw.tum.de/fml/index.php?Set_ID=320&letter=M&b_id=3444427B-4630-
3633-342D-424346442D34 Zugegriffen am 07.11.2012 15:30
5

ist, desto besser. Durch die kleineren Schnittstellen wird die Höhe der Modulkopplung
reduziert.
Die optimale Modulgröße ermittelt sich aus der Summe von Modulkopplungs- und der
Modulbindungskurve. Dabei ist die ideale Modulgröße eines Systems an dem Punkt an
dem die Komplexität am geringsten ist. Die Modulkopplung nimmt mit steigender Anzahl
von Modulen zu. Dagegen nimmt die Modulbindung bei steigender Modulanzahl ab.
Dies gilt solange das Systemfunktionen gleich bleiben. 10
4.3
Gestaltungsregeln
Abbildung 1: Optimale Anzahl der Module 11
Bei der Modularisierung muss auf die Wartbarkeit des Systems geachtet werden. Bei
der Modularisierung werden die Methoden Hierarchisierung, Abstraktion, und
Kapselung verwendet. Die Zusammenfassung oder Zerlegung (in Submodule) von
Modulen erzeugt eine hierarchische Strukturierung. Die Strukturhierarchie legt den
Aufbau des Systems dar. Die Hierarchisierung erhöht die Transparenz des Systems
und verringert die Komplexität der Struktur.
Abstraktion, also das Weglassen unwichtiger Details und Ermittlung der
Gemeinsamkeiten, ist eine Technik um die Komplexität zu beherrschen. Dabei wird auf
die Unterschiede der Module geachtet. Als Ergänzung der Abstraktion gilt die
Kapselung. In der Kapselung wird der innere Aufbau eines Moduls dargestellt. Sie stellt
eine klare Trennung zwischen der Bedienschnittstelle und dem inneren Aufbau des
Moduls sicher. Die Verwendung eines Moduls muss ohne genaue Kenntnis des
technischen Aufbau des Moduls möglich sein. 12
Eine hohe Modulkoppelung wirkt sich negativ auf die Testbarkeit aus. Eine gute
Testbarkeit ist dann gegeben, wenn ein Modul ohne Kenntnis des Gesamtsystems
getestet werden kann.
Module müssen durch andere Module ersetzt werden können. Dabei sollten keine
unerwünschten Effekte auf andere oder auf dieses Modul auftreten. Dies nennt man
Interferenzfreiheit. Interferenzfreiheit ist nicht gegeben, wenn Aufgaben auf mehrere
Module verteilt sind oder Module mehrere Aufgaben erledigen.
10 http://www.fml.mw.tum.de/fml/index.php?Set_ID=320&letter=M&b_id=3444427B-4630-
3633-342D-424346442D34 Zugegriffen am 07.11.2012 15:30
11 Abbildung übernommen von http://www.fml.mw.tum.de/fml/index.php?
Set_ID=320&letter=M&b_id=3444427B-4630-3633-342D-424346442D34 Zugegriffen am
07.11.2012 15:30
12 http://www.fml.mw.tum.de/fml/index.php?Set_ID=320&letter=M&b_id=3444427B-4630-
3633-342D-424346442D34 Zugegriffen am 07.11.2012 15:30
6

Die Wiederverwendbarkeit eines Moduls gibt die Verwendungszahl eines Moduls an.
Ein gutes Modul kann in unterschiedlichen oder dem Selben Projekt mehrfach
verwendet werden.
7

5
Objektorientierung
In ihrem Vortrag ging Frau Liskov auf ihre Programmiersprache CLU und
objektorientierte Programmierung ein. Dabei hat sie auch die Elemente wie
Datenkapselung, Polymorphie und Vererbung eingegangen.
5.1
CLU
Die Programmiersprache CLU wurde von Barbara Liskov und ihren Studenten zwischen
1974 und 1975 entwickelt. Diese Sprache gilt als erste Programmiersprache, welche
eine Datenbankabstraktion bot. Dies war grundlegend für die Entwicklung von
objektorientierten Programmiersprachen. CLU wurde als Programmiersprache für
Großprojekte entwickelt und ermöglicht die Bearbeitung eines Projektes durch mehrere
Bearbeiter.
CLU beinhaltet die Sprachelemente Cluster, Ausnahmebehandlungen, Iteratoren und
Mehrfachzuweisung von Variablen. CLU war für fortgeschrittene Programmierer
gedacht. 13
5.2 LSP
Unter der Abkürzung LSP versteht man das liskovsche Subtitutionsprinzip. LSP ist auch
unter dem Begriff Ersetzbarkeitsprinzip bekannt und ist ein Kriterium in der
objektorientierten Programmierung. LSP wurde 1993 von Barbara Liskov und Jeannette
Wing entwickelt. Bei der Modellierung eines Datentyps gibt LSP die Bedingungen für
den Untertyp an. 14
5.3
Objektorientierte Programmierung
Objektorientierung ist eine Methode zur Komplexitätsreduzierung in Softwaresystemen.
Objektorientierte Programmiersprachen sind eng mit der Entwicklung der Konzept der
Objektorientierung verbunden. 15
Die Objektorientierung hat sich erst spät, also Anfang der 90er Jahre, durchgesetzt.
Objektorientierte Softwareentwicklung bietet dabei Techniken an, welche einen
Entwickler bei der Entwicklung einfacher wartbarer, erweiterbarer und besser testbarer
Systeme hilft.
Die Objektorientierung kann jedoch nicht alle Probleme oder diese nur teilweise lösen.
13 http://de.wikipedia.org/wiki/CLU_(Programmiersprache) Zugegriffen am 07.11.2012 18:15
14 http://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip Zugegriffen am 07.11.2012
18:30
15 Bernhard Lahres, Gregor Rayman Objektorientierte Programmierung, Galileo Computing
8

5.3.1
Kapselung
In der Objektorientierung gehören Daten direkt zu einem Objekt. Direkte Aufrufe der
Datenstruktur, wie sie in der strukturierten Programmierung, ist nicht möglich. Daten
können also nur von dem Objekt gelesen oder verändert werden. Ein anderes Objekt
kann die Daten nur über eine Schnittstelle anfordern.
Das Objekt kann also selbst für die Konsistenz der Daten sorgen. Zum Beispiel können
Abhängigkeiten definiert werden. So können von einander abhängige Daten nur
gemeinsam geändert werden. Änderungen an der Datenstruktur wirken sich nur auf das
betroffene Objekt aus. Dies reduziert die Anzahl der Betroffenen in einem System und
den Aufwand für die Anpassung. Die Kapselung macht es also einfacher die Korrektheit
von Programmen zu gewährleisten und reduziert den Änderungsaufwand. 16
5.3.2
Polymorphie
Polymorphie bedeutet auf Deutsch „Vielgestaltigkeit“. In der Objektorientierung bedeutet
dies einen möglichen Aufruf der selben Operation von verschiedenen Objekten
unterschiedliches Verhalten zur Folge haben kann.
Dynamische Polymorphie erlaubt es dabei einer Variablen eines Objekts Werte
unterschiedlicher Typen zuzuweisen. Dies ist möglich, da der Typ der Variablen
lediglich eine Schnittstelle ist. Werden einer Variablen während der Programmlaufzeit
Werte unterschiedlicher Typen zugeordnet geschieht dies über unterschiedliche
Methoden.
Die Polymorphie ist die Voraussetzung um Konzepte wie die Vererbung oder der
Ersetzbarkeit zu realisieren. 17
5.3.3
Vererbung
Die Vererbung wurde erstmals in der Programmiersprache Simula (1967) eingesetzt.
Dabei ist die Vererbung ein Grundlegendes Konzept der Objektorientierung. Diese hat
daher eine große Bedeutung in der Softwareentwicklung. Anhand bereits vorhandenen
Klassen werden neue Klassen geschaffen. Die Klassen sind dabei für immer mit
einander verbunden. Eine Klasse, welche von einer anderen erbt, kann eine
Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein. Die Vererbung
kann zusätzlich zur Dokumentation von Ähnlichkeiten zweier Klassen verwendet
werden. Klassenhierarchien stellen strukturelle Ähnlichkeiten von Klassen dar.
Basisklassen (auch Superklasse genannt) ist die Bezeichnung für die vererbende
Klasse. Subklassen sind die erbenden Klassen. Generalisierung beschreibt die Umkehr
der Vererbung. Ableitung oder Spezialisierung beschreibt das Erben selbst. Subklassen
16 Bernhard Lahres, Gregor Rayman Objektorientierte Programmierung, Galileo Computing
17 Bernhard Lahres, Gregor Rayman Objektorientierte Programmierung, Galileo Computing
9

und Superkassen stehen in einer „is-a“ Beziehung. In einer Klasse werden Datentypen
und Funktionalitäten definiert, welche an andere Klassen vererbt werden können.
Mehrfachvererbung tritt auf, wenn eine Subklasse von mehreren Superklassen erbt.
Diese Art der Vererbung steht nicht in allen Sprachen zur Verfügung. 18
5.3.4 Iterator
Iteratoren sind eine Art von Zeigern. Er besitzt zwei Funktionen. Eine Funktion ist die
Erstellung einer Referenz auf ein bestimmtes Objekt und eine andere ist die
Selbstmodifizierung um auf das Nächste Element zu zeigen. Ein Iterator dient dazu auf
ein Element zuzugreifen und diesen von der Menge der Datenstruktur zu trennen. 19
18 http://de.wikipedia.org/wiki/Vererbung_(Programmierung) Zugegriffen am 07.11.2012 19:00
19 http://de.wikipedia.org/wiki/Iterator Zugegriffen am 07.11.2012 20:40
10