Kapitel

Software-Eigenschaften

„Java-Programme werden in Bytecode übersetzt und dann in einer speziellen Umgebung aus- geführt, die als Java-Laufzeitumgebung oder Java-Plattform bezeichnet wird. Deren wichtigster Bestandteil ist die Java Virtual Machine (Java-VM), die die Programme ausführt, indem sie den Bytecode interpretiert.

Java-Programme laufen in aller Regel ohne weitere Anpassungen auf verschiedenen Computern und Betriebssystemen, für die eine Java-VM existiert. Sun selbst bietet Java-VMs für die Betriebssysteme Linux, Solaris und Windows an.“

Java ist eine Programmiersprache mit der man erwünschte Software-Eigenschaften generieren kann.

Portierbarkeit: Die Java Virtual Machine existiert für die am meisten verbreiteten Betriebssysteme und schafft dabei weitgehend konstante Rahmenbedingungen, sodass Java-Programme ohne oder mit nur geringen Veränderungen auf all diesen Betriebssystemen funktionieren. Ein Beispiel für ein solches Programm ist OpenOffice.org, das es für u.a. für Windows, Linux und Macintosh gibt.

Wiederverwendbarkeit: Hat ein Entwickler in Java eine Klassenbibliothek geschrieben, die z.B. sicherstellt, dass ein eigegebenes Passwort ein gewisses Format hat, kann er es auch dann für ein Linuxprogramm nutzen, wenn es ursprünglich für ein Windowsprogramm entworfen wurde. Eine Neuimplementierung entfällt also zugunsten der Wiederverwendbarkeit.

Wartbarkeit

Adaptive Wartung

Schließlich ändern sich die Rahmenbedingungen des Kunden (= neue mobile Endgeräte

müssen unterstützt werden), die zur Anpassung der Software führen.

Die Software muss an veränderte gesetzliche Rahmenbedingungen angepasst werden, die durch den Umstieg auf eine neue Bilanzierung zurückzuführen sind.

Korrektive Wartung: Es wird eine Funktionalität des Programms nachträglich angepasst, weil deren ursprüngliche Implementierung den Kundenwünschen nicht gerecht wurde.

Enhansive Wartung: Die Software wird um eine vorher nicht vorhandene Funktionalität erweitert, die eine Prozessbeschleunigung im Unternehmen bewirkt, weil redundante Operationen wegfallen.

Bei der Überprüfung der Produkteigenschaften wird mangelnde Qualität aufgedeckt. Diese wird dann durch Nachbesserung beseitigt.

Beispiel: Eine Software soll auf einem anderen HW-System eingesetzt werden. Es werden komplexe

Anpassungen nötig sein, damit die SW einwandfrei läuft.

Ursache für schlechte Qualität wird analysiert. Danach werden Prozesse verbessert und somit das Problem an seiner Wurzel entfernt.

Beispiel: Mit dem Hintergrundwissen, das zukünftig die SW auf anderen spezifischen HW-Systemen

eingesetzt werden soll, entschließt man sich für ein Redesign in einer anderen Programmiersprache. Diese ermöglicht es, nahezu plattformunabhängige SW zu entwickeln. So können zeitaufwendige Anpassungen für spezielle HW-Systeme eingespart werden.

Software-Prinzipien

Zwischen den Prinzipien des Software Engineerings und den Eigenschaften von Software bestehen unterschiedliche Abhängigkeiten. Wir verdeutlichen das am Prinzip Inkrementalität:

Die Inkrementalität impliziert, dass eine Software schrittweise entwickelt wird und nach jedem solchen Schritt eine Rückkopplung stattfindet. Eine Rückkopplung bedeutet auch, dass der Kunde/Nutzer eingeladen wird, um ihn die aktuellste Version der Software zu präsentieren. So kann er frühzeitig Änderungen veranlassen, die für ihn die Software intuitiver gestalten und somit die Benutzerfreundlichkeit erhöhen.

Dialoge können schrittweise und in Abstimmung aneinander entwickelt werden, wodurch die Gesamtsoftware einheitlicher und ebenfalls benutzerfreundlicher wird.

Schrittweises Vorgehen verursacht Fehler und Wartezeiten bei den Übergabezeitpunkten. Wenn SW auf inkrementelle Weiterentwicklung ausgelegt wird, können ineffiziente Betriebsprozesse technisch untermauert werden. Inkrementalität verschiebt die Schwierigkeit bei der SW-Entwicklung auf die Integration der Module. Unternehmensweite Integration der Software ist schwer zu realisieren. Für die Wartung wird viel Know-How gebraucht, dass aber in den Köpfen der Entwickler steckt. SW-Firma wird abhängig von SE'lern. Inkrementalität verursacht eine Dokumentationsflut, weil die Iterationsschritte dokumentiert werden sollten. Ausserdem ist es sehr schwierig eine komplexe SW iterativ zu entwickeln, weil während des Entwicklungsprozesses neue Erkenntnisse hinzukommen. Die neuen Erkenntnisse können die schrittweise Planung umwerfen.

Unified Process ist Use Case getrieben, dadurch kann der Kunde und der Endnutzer in die Anforderungserhebung eingebunden werden.

Die Architekturzentrierung nimmt künftige Weiterentwicklungsmöglichkeiten vorweg. Frühzeitige Integration der Bauteile/Module ermöglicht es früh, Fehler in der Software-Entwicklung zu machen. Je frühzeitiger Fehler gemacht werden, desto kostengünstiger wird das SW-Projekt, weil spätere Nachsteuerung zu teuerer sind.

Prototyping eignet sich für echte Neuentwicklung von SW, für die es noch keine „Blaupausen“ gibt.

Frühes Fehlermachen in den Anfangsstadien der SW-Entwicklung wird ermöglicht, um rasch Design und Modellierungsprobleme aus der Welt zu schaffen. Der Prototyp kann dem Kunde präsentiert werden und den Kunden helfen, seine Vorstellungen besser zu artikulieren.

Bei Lebenszyklusmodellen taucht das Prinzip Inkrementalität ebenfalls auf.

Bei dem Lebenszyklusmodell „Prototyping“ ist die Inkrementalität wichtig. Schließlich entstehen dabei, unabhängig davon ob man Throw-away-Prototypen oder inkrementelle Prototypen einsetzt, viele Versionen, die zumindest im Normalfall im Verlauf der Zeit der gewünschten Software immer ähnlicher werden. Diese Prototypen erlauben eine Rückkopplung, da ständig sichergestellt und geprüft wird, dass die Anforderungen an die Software erfüllt werden.

Auch das Spiralmodell berücksichtigt die Inkrementalität. Schließlich ist auch dabei die Softwareentwicklung in Phasen unterteilt. Zum Anschluss einer solchen Phase wird die nächste Phase geplant, sodass auch Erkenntnisse und nachträglich aufgekommene Kundenwünsche aus der letzten Phase aufgegriffen werden können. So wird die Software schrittweise an die Kundenwünsche angepasst.

Das Prinzip „Allgemeinheit“ kann die Eigenschaft „Benutzungsfreundlichkeit“ negativ beeinflussen. Ist ein Programm allgemein aufgebaut, muss dessen graphische Oberfläche allen Anwendungsszenarien gerecht werden. Das bedeutet, dass dem Nutzer diverse Konfigurationsmöglichkeiten für die einzelnen Szenarien geboten werden müssen. Selbst die intuitivste Anordnung dieser Einstellungsmöglichkeiten kann nur wenig an der Tatsache ändern, dass man sich lange in eine Software einarbeiten muss. Dieses Problem wird deutlich, wenn man den Einstellungsdialog von Ahead Nero 6 öffnet (Siehe Bild 1). Auch die Tatsache, dass man einen mehrmonatigen Kurs benötigt, um sich in SAP einzuarbeiten, verdeutlicht diesen Konflikt zwischen der „Allgemeinheit“ und der „Benutzungsfreundlichkeit“. Meist ist eine nicht allgemeine Software die benutzungsfreundlichste.

Kohasion & Kopplung:

Die Kohäsion beschreibt, wie hoch die „Verstrickung“ innerhalb eines Moduls ist. Dieser Terminus darf nicht im Zusammenhang mit der Verflechtung zwischen den Modulen benutzt werden. Die Kopplung sollte möglichst gering sein, da man sonst dem Prinzip der „Modularität“ der Software keine Rechnung trägt.

Kohasion (innerhalb der Kästen): ist hoch wenn > 2
Kopplung (Verbund zwischen Kästen): ist hoch wenn > 2

Lehman’s Law (Zusatzaufgabe):

Lehman's Law of Uncertainty and Lehman's Law of Increasing Software Entropy bedeuten, dass Änderungen während und nach der Entwicklung unvermeidlich sind.

Law of Uncertainty:

Software ändert sich während ihres ganzen Lebenszyklus. Genauere Angaben zum Gegenstand der Änderungen sind nicht vorhersehbar.

Law of Increasing Software Entropy:

Änderungen einer Software machen ihre Struktur in der Regel unverständlicher. Die innere Struktur einer Software geht mit fortschreitender Software-Lebenszeit verloren.

Kapitel

Begriffswiederholung:

Prinzip: Grundsatz, der Handeln zu Grunde legt $\Longrightarrow$ allgemeingültig, daher abstrakt
Technik: Vorschrift zur Durchführung einer Tätigkeit
Methode: Bündelung von Techniken zur Erreichung von Zielen
Werkzeuge: Rechnerunterstützung für Techniken und Methoden

Lebenszyklusmodell:

im Vergleich zum SW-Prozessmodell wird vor allem auf die Vermittlung der prinzipiellen Vorgehensweise als auf formale Definitionen der Fokus gesetzt. Aus einem Lebenszyklusmodell lassen sich beliebig Software-Prozessmodelle ableiten. Phasen sind definiert. WAS wird implementiert?

Software-Prozessmodell:

Ist im Vergleich zum Lebenszyklusmodell konkreter (bzw. das LZ-Modell ist abstrakter). Es definiert Aktivitäten und deren Reihenfolge bei der Durchführung (z.B. Systemtest dann Abnahmetest), Werkzeuge & Methoden (C++, Visual Studio) sowie alle zu verarbeitenden oder erzeugten Objekttypen. Aus einem SW-Prozessmodell lassen sich beliebig Software-Prozesse ableiten. WIE wird implementiert?

Software-Prozesse:

Ist im Vergleich zum Software-Prozessmodell konkreter, ein Prozess beschreibt eine konkrete Ausprägung eines bestimmten Softwareprozessmodells. Er verhält sich wie ein Objekt zu seinem Objekttyp (Objekt / Klasse in der OOP). Ein Prozess beschreibt z.B. wann und zu welchem Zeitpunkt eine bestimmte Aktivität von einer bestimmten Person durchgeführt wird. Des Weiteren kann er Auskunft über die zu verarbeitenden oder erzeugten Objekte (Objekt ist ungleich Objekttypen in Prozessmodell !) geben. WER, WANN, WIE?

Einführung in die Software Methodologie

Software-Lebenszyklusmodell

Dabei handelt es sich um eine prinzipielle Vorgehensweise bei der Softwareentwicklung, die auf einem sehr hohen Abstraktionsniveau angesiedelt ist, wobei die wesentlichen Entwicklungsaktivitäten inklusive deren Abhängigkeiten festgehalten werden. Dabei stellt man sich die Frage: „Was ist die Problemstellung und wie kann man sie informationstechnisch lösen?“. Die dabei relevanten Problematiken haben sich in den letzten Jahrzehnten nur unwesentlich verändert. Abhängig vom vorliegenden Projekt werden unterschiedliche Lebenszyklusmodelle benötigt, manchmal sind auch nachträgliche Anpassungen nötig. Diese Anpassungen verursachen meistens sehr hohe Kosten und sollten gut überlegt sein, weil damit verbunden sein kann, dass ein Teil der geleisteten Arbeit überflüssig wird und auch das Prozessmodell angepasst werden muss. Weil der gewählte Lebenszyklus einen sehr großen Einfluss auf die Rahmenbedingungen des Projektes hat, gibt es oft einen speziellen Lebenszyklusmodellierer, der in einer sehr frühen Projektphase ein möglichst optimales Modell auswählen muss. Weiterhin behält er das stattfindende Projekt auf einer abstrakten Ebene im Blick und kann den Einfluss sich ändernder Rahmenbedingungen abschätzen. Zu jedem Lebenszyklusmodell gibt es mehrere passende Prozessmodelle.

Software-Prozessmodell Hierbei wird festgelegt, welche Aktivitäten in welcher Reihenfolge durchzuführen sind. Dabei wird auch eine Auswahl der Werkzeuge und Methoden getroffen, die zur Durchführung dieser Aktivitäten notwendig sind. Hierbei spielt es eine bedeutende Rolle, welche Technologie genutzt wird. Es ist also nicht gleichgültig, ob man eine hohe objektorientierte Programmiersprache oder Assembler nutzt. Weiterhin werden hier auch die Typen der Objekte festgelegt, die im Zusammenhang mit den Aktivitäten erzeugt und verarbeitet werden. Auch wird hier die Frage gestellt, wie die Durchführung der Aktivitäten diese Objekte beeinflusst und verändert. Zu jedem Prozessmodell gibt es mehrere Software-Prozesse.

Allgemein gilt: Jeder Schritt und insbesondere jede Abweichung von einem Lebenszyklus- oder Prozessmodell muss gut dokumentiert werden, damit sie im Nachhinein nachvollzogen werden kann.

Beispiele:

Bauwesen: Während im Bauwesen fundamentale Möglichkeiten zur Beschreibung eines Gebäudes existieren (Berufsbild Bauzeichner, CAD etc…), gibt es im Software Engineering keinen einheitlichen „Bauplan“ für Software.

Maschinenbau: Das Endprodukt ist materiell, es entstehen neben den Personalkosten weitere Kosten, wie z.B. Materialkosten. Das Material kann im Unterschied zum Software Engineering hierbei auch wesentlich zum Erfolg des Produktes beitragen.

Code and Fix Modell:

Programmcode schreiben (Code)
Fehler beheben (Fix)

Vorteile:

einfaches Modell

Nachteile:

keine Struktur
keine Teamarbeit
keine Änderungen möglich
Unzuverlässigkeit, Unvorhersehbarkeit und Ineffizienz des Produktes

Wasserfallmodell:

Großes Projekt: ( geeignet für SP, V-Modell, RUP)

für den Start einer Phase das Ergebnis / Output der Vorgängerphase (i.d.R. die Dokumentation) als Input vorliegen muss.

- verhindert z.B. eine parallele Bearbeitung verschiedener Phasen, es kann nur sequentiell programmiert werden, die Phase muss vollständig abgeschlossen sein.
- Dementsprechend verzögert sich die Entwicklungszeit und erhöht die Kosten.
- Im Vergleich zum Spiralmodell fehlt ein Risikomanagement, welches bei ungünstiger Entwicklung des Projektes durch frühzeitigen Abbruch ebenfall Geld und Zeit einsparen kann.
- Änderungen können schlecht vorgenommen, da der Kunde das Endprodukt erst spät sieht

Präzise Anforderungen: /
- liegen exakte und auch bis zum Projektende unveränderte Anforderungen vor, so ist das Wasserfallmodell als Referenzmodell geeignet,
- problematisch wird es jedoch bei sich ständig ändernden Anforderungen zwischen den Phasen (siehe instabile Anforderung)

Instabile Anforderungen: ( geeignet für SP, V-Modell, RUP, vor allem Prototyping)
- Durch die starre Phaseneinteilung lassen sich die bei einem komplexen Projekt üblichen Änderungswünsche der Anforderungen eher schlecht vornehmen.
- Zwar ist eine iterative Vorgehensweise nicht ausgeschlossen, jedoch kann der „Rücksprung“ zu Phasen über die Vorgängerphase hinaus den Zeit&Kostenrahmen enorm gefährden.
wichtig, direkt von Anfang die Anforderungen so präzise wie möglich zu stellen um so auf spätere Änderungen verzichten zu können.

Hoher Zeitdruck: ( geeignet für SP, V-Modell, RUP, Code and Fix)
die lineare Entwicklung von Software ist praxisfern und zeitaufwendig, i.d.R. findet eine Überlappung der Phasen statt.
Eine Phase kann erst nach Abschluss der Vorgängerphase begonnen werden, das diese als Ergebnis den Input des Nachfolgers stellt. (dokumentenzentriert)
Hinzu kommen Zeiteinbußen durch aufwendige Reviews (Qualitätssicherung?).

Kurzfassungen von Literaturhinweisen

[Royce, 1970] "Managing the Development of Large Software Systems"
[Benington, 1956] "Production of Large Computer Programs"
[Boehm, 1981] "Software Engineering Economics"

Spiralmodell

Bei dem Spiralmodell wird auf die Risikoeinschätzung und die Minimierung des Risikos Wert gelegt. Dies ist darauf zurückzuführen, dass insbesondere bei großen Softwareprojekten weit mehr als die Hälfte aller Projekte verspätet oder gar nicht fertiggestellt werden. Das Risiko einer solchen Verspätung oder eines solchen Abbruchs möchte man möglichst gering halten.

Vergleicht man die Softwareentwicklung mit dem Spiralmodell mit der prototypischen Entwicklung stellt man fest, dass es sowohl Gemeinsamkeiten als auch Unterschiede gibt. Die Gemeinsamkeiten sind vor allen Dingen in der Zielsetzung der beiden Vorgehensweisen anzusiedeln: Es wird nämlich versucht, das Risiko des Scheiterns oder der Verspätung dadurch abzuwenden, indem man versucht Missverständnisse möglichst früh zu erkennen.

Der Unterschied ist, dass das Spiralmodell ein allgemeineres Modell ist als das Prototyping. Das Spiralmodell ist nämlich eigentlich ein Metamodell, während das Prototyping ein klassisches Lebenszyklus-Modell darstellt. Das Spiralmodell geht über das Prototyping hinaus indem es nicht nur die Erstellung von Prototypen vorsieht, sondern auch andere Ansätze bietet: Man behält z.B. auch ständig andere Lösungsalternativen im Blick

Ein Grund für die Flexibilität des Spiralmodells ist die Tatsache, dass die aktuell folgende Projektphase ausgehend von der vorherigen Phase geplant wird. Ein solcher Ansatz bietet den Vorteil, dass die Erfahrungen aus der letzten Phase mitberücksichtigt werden und auch dass beispielsweise im Gegensatz zum Wasserfallmodell nicht vor Projektbeginn quasi der gesamte Projektablauf feststeht.

Weiterhin ist das Spiralmodell auch insofern flexibel, als dass es an unterschiedliche Aufgabenstellungen (z.B. Webanwendung, Desktopanwendung, mobile Anwendung…) anpassbar ist. Man würde also abhängig von der Anwendungsart beispielsweise die Risikoanalyse unterschiedlich gestalten. Auch würde man die Methoden und Werkzeuge je nach Anwendungsart anders wählen. Mehr noch: Es ist sogar möglich, innerhalb dieses Modells andere Modelle wie das Prototyping oder auch abgewandelte Formen des Wasserfallmodells zu integrieren.

Allgemein kann man auch sagen, dass ausgehend aus der Tatsache, dass das Spiralmodell ein Metamodell ist, es insgesamt auf einem noch höheren Abstraktionsniveau anzusiedeln ist, als z.B. das Wasserfallmodell, sodass es wesentlich mehr Gestaltungsspielräume bietet.

Prototyping-Modelle

Vor- und Nachteile von Prototyping

Vorteile

Reduzierung des Entwicklungsrisikos
Prototypen können durch heutige Werkzeuge schnell erstellt werden
Kreativität für Lösungsalternativen
Starke Rückkopplung mit Endbenutzer

Nachteile

Gefahr: aus Zeitgründen wird Wegwerf – Prototyp Teil des Endprodukts
Prototypen werden oft als Ersatz für fehlende Dokumentation angesehen

Das V – Modell

Vorteile des V-Modells

Integration von SE, KM, QS, PM
Identifikation und Definition von Rollen und Verantwortungen
Umfassende Abdeckung verschiedener Aspekte
Durchgängige Betrachtung der Qualitätssicherung

The users of The V-Model participate in the development and maintenance of The V-Model. A change control board publicly maintains the V-Model. The change control board meets once a year and processes all received change requests on The V-Model.
At each project start, the V-Model can be tailored into a specific project V-Model, this being possible because the V-Model is organization and project independent.
The V-Model provides concrete assistance on how to implement an activity and its work steps, defining explicitly the events needed to complete a work step: each activity schema contains instructions, recommendations and detailed explanations of the activity.

Nachteile des V-Modells

zu detailliert für Lebenszyklusmodell
zu unkonkret für Softwareprozess – Modell
Anwendung unklar $\rightarrow$ Gefahr der nicht Anwendung
Lange Trainingszeit

Diese Aspekte werden im V-Modell nicht berücksichtigt:

Es gibt keine Dientleistungsverträge
Die Organisation und Durchführung der Operationen Pflege, Reparatur und disposal des Systems werden nicht durch das V-Model abgedeckt. Jedenfalls sind Planung und Vorbereitung dieser Aufgaben im Modell enthalten.
Das V-Model weist die Software-Entwicklung einem Projekt zu nicht einer Organisation.

Das V-Modell XT wird in drei Schichten erklärt. In allgemeiner Form , danach jeweils den dokumentenzentrierten und den modellbasierten Entwicklungsansatz. Am Ende erläutern wir, wie man die Vorteile beider Ansätze kombinieren kann.

Die Bundesrepublik Deutschland hat im im Verteidigungs- und Verwaltungsbereich das V-Modell zum verbindlichen Standard erklärt. Den Grund dafür werden wir sofort verstehen, wenn wir uns an das Bermuda-Dreieck erinnern.

Unified Process

Literaturhinweise zu Unified Process

Kroll, Per; Kruchten, Philippe (2003). The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. ISBN 0-321-16609-4 .
Kruchten, Philippe (2004). The Rational Unified Process: An Introduction (3rd Ed.). ISBN 0-321-19770-4 .
Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. ISBN 0-13-111155-8
Scott, Kendall (2002). The Unified Process Explained. ISBN 0-201-74204-7
Bergstrom, Stefan; Raberg, Lotta (2004). Adopting the Rational Unified Process: Success with the RUP. ISBN 0-321-20294-5

Kapitel: Rollenmodell

„Eine Rolle beschreibt eine Menge von zusammengehörigen Aufgaben und Befugnissen (oft auch notwendige Qualifikationen) z.B. Projektleiter…“

Eine Rolle hat folgende Eigenschaften:

sie wird von Personen wahrgenommen
eine Person kann mehrere Rollen übernehmen (Herr B. ist Projektleiter und Mitglied der Tester-Gruppe)
eine Rolle kann von mehreren Personen wahrgenommen werden (Herr B. und Herr A. sind beide Tester)
nicht in jeder Softwareentwicklung treten alle Rollen auf (kein Projektleiter in 2 – Mann –Teams …)
Ziel: Kooperation zw. den beteiligten Personen, Interessenausgleich

Vorteile:

klare Aufgabenabgrenzung unter den Beteiligten
Fähigkeiten werden berücksichtigt
Interessenausgleich zw. den Rollen mindert die Zielkonflikte
Kooperation zw. den Rollen mindern Zielkonflikte und tragen zum Erfolg bei / Kommunikation gefördert

Kapitel Konfigurationsmanagement

Vorwärts- und Rückwärts Delta-Technik

Berechnungsaufwand ist nötig, um das Delta von zwei Dateien zu ermitteln. Da bei beiden Techniken (Vorwärts und Rückwärts) für jede neue Version das Delta zur Vorgängerversion ermittelt werden muss (oder eben genau andersherum), ist der Berechnungsaufwand gleich. Wie das Delta aussieht, ist allerdings unterschiedlich. Es bleibt aber für jede neue Version das Delta von zwei Dateien zu bestimmen => gleicher Aufwand.

Rekonstruktionsaufwand wird benötigt, um eine Version der Datei zu erstellen. Bei Vorwärtsdelta ist der Rekonstruktionsaufwand für die Basisversion = 0, bei Rückwärtsdelta ist er für die aktuellste Version = 0. Alle anderen Versionen müssen auf Basis der vollständig gespeicherten Version und den Deltas ermittelt werden. Da immer das Delta zwischen zwei aufeinanderfolgenden Versinen berechnet wird, kann es sein, dass mehrere Deltas bei der Rekonstruktion berücksichtigt werden müssen.

Da ich in der Regel seltener auf alte Versionen zugreifen will, sonder meine akutelle Version weiterentwickeln will, ist der R-Aufwand bei der Rückwärtsdeltatechnik in der Regel geringer.

Allgemein

Man unterscheidet zwischen der optimistischen und der pessimistischen Zugriffskontrolle. Bei den beiden Varianten gibt es ein sogenanntes Repository, in dem sämtliche projektrelevanten Dateien zentral und versioniert gespeichert sind. Diese Dateien können Quellcode, Dokumentationen, Schulungsmaterial u.v.m. sein. Will man als berechtigter Mitarbeiter bestimmte Dateien einsehen oder verändern, werden die betroffenen Dateien von der Konfigurationsmanagementsoftware aus dem Repository in den Workspace des Mitarbeiters kopiert (Check Out). In seinem Workspace kann der Mitarbeiter die Datei dann betrachten und manipulieren. Braucht der Mitarbeiter die Datei nicht mehr, werden eventuelle Änderungen im Repository festgehalten und die Versionsnummer angepasst (Check In).

Allerdings besteht auch die Notwendigkeit, konkurrierenden/gleichzeitigen Zugriff auf ein und dieselbe Datei abzuwickeln. Zwei Strategien greifen dieses Problem an.

Pessimistische Zugriffskontrolle

Bei der pessimistischen Zugriffskontrolle gibt es keinen gleichzeitigen Zugriff auf eine und dieselbe Datei. Hat Mitarbeiter A Datei Z „ausgecheckt“, kann Mitarbeiter B die Datei Z solange nicht ebenfalls auschecken, bis A sie wieder eincheckt. Dies gilt unabhängig davon, ob A die Datei Z nur zu lesen oder bearbeiten beabsichtigt.

Oft wird die pessimistische Zugriffskontrolle dahingehend verändert, dass man zwischen dem Auschecken zum Lesen und Auschecken zum Bearbeiten unterscheiden. Bei der ersten Variante dürfen mehrere Nutzer Datei Z zumindest gemeinsam betrachten. Die hierbei relevanten Verfahren sind z.B. RCS und SCCS.

Optimistische Zugriffskontrolle

Die optimistische Zugriffskontrolle (z.B. bei CVS) würde beliebig vielen Nutzern erlauben Datei Z gemeinsam in ihren Workspaces zu nutzen. Dies umfasst sowohl lesende als auch schreibende Zugriffe. Nach dem Check In erfolgt ein Merge. Dabei versucht das System, die Änderungen der unterschiedlichen Nutzer zusammenzufügen. Ist dies nicht möglich, weil beispielsweise dieselbe Zeile von den Mitarbeitern A und B unterschiedlich angepasst wurde, meldet das System diese Komplikation und verlangt ein manuelles Eingreifen.

Diskussion: Vor- und Nachteile

Die beiden Zugriffskontrollen haben Vor- und Nachteile.

Diskussion: Pessimistische Zugriffskontrolle

Die pessimistische Zugriffskontrolle ist sicherlich sehr sicher, weil widersprüchliche Änderungen unmöglich sind: Nutzer A kann nicht den Typ einer globalen Variable ändern, wobei Nutzer B an einer anderen Codestelle von dem ursprünglichen Variablentyp ausgeht und mit dieser Variable arbeitet. Auch ist die Implementierung solcher Systeme einfacher, weil Algorithmen zum Zusammenfügen der Datei nicht zum Einsatz kommen.

Allerding verhindert das pessimistische Verfahren das gleichzeitige Arbeiten an einem Dokument. Ist das trotzdem nötig, weil beispielsweise unterschiedliches Know-how zum Anfertigen einer Spezifikation nötig ist (z.B. Soft- und Hardwareebene), muss vorher eine Absprache getätigt werden, wer wann welche Datei nutzen darf. Weiterhin kommt es häufig vor, dass ein Nutzer eine Datei „vorsichtshalber“ für den Schreibzugriff auscheckt, diese aber eigentlich nur zum Lesen benötigt und im Anschluss beispielsweise in die Pause geht, ohne die Datei wieder einzuchecken. Der Arbeitsfluss im Projekt erliegt, weil andere auf den Dateizugriff warten müssen.

Diskussion: Optimistische Zugriffskontrolle

Bei der optimistischen Zugriffskontrolle ist gleichzeitiges Arbeiten an einer Datei möglich und Nutzer.

A kann in einer Spezifikation die Softwareebene erläutern während B die Hardwareanforderungen notiert. Wie oben aber bereits geschildert, kann es besonders bei dem mergen von Quellcode zu Widersprüchen kommen, die das System aber nicht als solche erkennt. Dadurch kann die Programmlogik gefährdet werden. Auch sind die zum zusammenfügen der Dateien nötigen Algorithmen komplizierter und es lassen sich nicht alle Dateien zusammenfügen (Bilder, Videos…). Nutzt man die trotzdem die optimistische Variante, sollte ein Angestellter das zusammengefügte Resultat auf Konsistenz überprüfen.

Fazit

Als Fazit kann man sagen, dass bei dem pessimistischen Verfahren der Schwerpunkt auf Sicherheit gelegt wird, während bei der optimistischen Zugriffskontrolle das gemeinsame Arbeiten trotz potenzieller Inkonsistenzen im Vordergrund steht.

Beispiel: Subversion

Wie unterstützt Subversion das Konfigurationsmanagement ?

Subversion speichert Client-seitig beim Erstellen einer lokalen Kopie (checkout), beim Aktualisieren (update) und Übertragen (commit) in einem gesonderten Verzeichnis (.svn) eine zweite Kopie jeder Datei. Dadurch verdoppelt sich der Speicherbedarf einer Arbeitskopie, allerdings bietet dies bei entfernten Projektarchiven auch einige Vorteile. So können einige Aktionen, wie Anzeige der lokalen Änderungen, ganz ohne Netzwerkzugriff erfolgen, und Subversion muss beim Übertragen nur die geänderten Teile einer Datei übertragen, während CVS die Änderungen Server-seitig berechnet und somit jeweils die gesamte Datei übertragen muss. Auch ist es möglich, jederzeit die Änderungen einer Datei gegenüber ihrer Basisversion zu ermitteln oder zurückzunehmen, ohne das Projektarchiv zu konsultieren. Die Übertragung der lokalen Änderungen (commits) geschieht dabei in Subversion atomar, das heißt, eine Änderung – auch mehrerer Dateien – wird entweder ganz oder gar nicht ins Repository gespeichert. Verbindungsabbrüche und mehrere gleichzeitige Zugriffe können somit nicht zu inkonsistenten Zuständen führen.

Was ist die grundlegende Funktionsweise ?

Die Versionierung erfolgt in einem zentralen Projektarchiv (engl. repository) in Form einer einfachen Revisionszählung. Wenn Änderungen an Inhalten verteilt auf den Computern der Bearbeiter ausgeführt werden, werden zwischen dem Projektarchiv und einem Arbeitsplatz jeweils nur die Unterschiede zu bereits vorhandenen Ständen übertragen; anfangs das gesamte Projekt, später nur Änderungen.

Mit Subversion ist es aber – im Gegensatz zu CVS – z. B. möglich, Dateien oder Verzeichnisse zu verschieben oder umzubenennen, ohne die Versionsgeschichte zu verlieren. Das Versionsschema von Subversion bezieht sich nicht mehr auf einzelne Dateien, sondern jeweils auf das ganze Projektarchiv, mit jeder Änderung bekommt es eine neue „Revisionsnummer“ zugeordnet. Somit kann man einfacher – und im Gegensatz zu CVS konsistent – eine exakte Version beschreiben (z. B. „Revision 2841“ statt „Version vom 23. März 2004 20:56:31 UTC“). Die Revisionsnummer einer Datei entspricht dabei der Revisionsnummer des Projektarchivs, als sie das letzte Mal geändert wurde, die Revisionsnummer eines Verzeichnisses entspricht der höchsten Revisionsnummer der enthaltenen Dateien und Verzeichnisse. Die Abfolge der Revisionsnummern einer einzelnen Datei kann also durchaus lückenhaft sein, wenn die Datei nicht bei jeder Änderung (Commit) am Repository geändert wurde.

Diskussion: Sinn der Konfigurationsmanagement/Versionierung

Erst durch Konfigurationsmanagement lassen sich Veränderungen auch dem Kunden artikulieren. Die Versionierung einer Software und der Teilkomponenten ist sorgfältig zu machen. Der Kunde erhält dadurch den Durchblick bei seinem Auftrag.

Software-Hersteller führen oft ein Register, indem sie festhalten, welcher Kunde welche Version seiner Software nutzt. Dies erleichtert das nachträgliche Anpassen der Software und die Fehleridentifikation.

Probleme sind lösbar, wenn sie verstanden werden. Getätigte Änderungen sind zu protokollieren. Dies sichert die Nachvollziehbarkeit von Problemen.

Systembegleitende Dokumente wie Bsp. Spezifikationen verändern sich ständig. Das ist eine Binsenwahrheit. Ohne Versionierung stellen sich schnell Probleme ein.

Für jede Version sollten verbindliche Ziele da sein: Mindestanforderungen sind zu definieren. Das Release von Firefox 3.5 kam spät, und es wurde das dritte Servicepack für Windows XP nachträglich für eine kurze Zeit von den Downloadservern entfernt, weil sicherheitskritische Probleme erkannt wurden. Trotz Verspätung bekam der Endverbraucher ein hochqualitatives Produkt.

Lieferumfang

Spezifikation: Der Kunde kann sich ein genaues Bild über sämtliche Eckpunkte der Software verschaffen.

Schulungsmaterial: Der Kunde kann seine Angestellten besser einarbeiten und den

Supportaufwand reduzieren

Installationsanleitungen: Der Kunde kann die Software eigenständig einrichten und konfigurieren.
Support-Channels: Der Kunde kann sich bei Problemen mit den Hersteller in Verbindung setzen
Release-Notes: Der Kunde kann die Unterschiede zwischen den Versionen leichter nachvollziehen.

Tichy-Algorithmus

Die vier Ansätze

LGS-Algorithmus von Hunt
Iterativer LGS-Algorithmus
Iterativer Algorithmus für längsten gemeinsamen Substring
Heckel-Algorithmus

finden alle nicht das minimale Coverage Set.

Geg.:

Gegen seien zwei Textdateien Text_1 [1,...,m] und Text_2 [1,...,n]. Aus diesen zwei Textdateien kennt man die Startzeilen start_1 und start_2. Wichtig für den Tychy-Algorithmus ist der Block Move: er hat eine Länge - die Variable nennen wir laenge.

Text_1 [0,…,m] ; Text_2 [0,…,n]: 2 Textdateien
start 1 : Startzeile von Text 1
start_2: Startzeile von Text_2
laenge: Länge des Block Moves

Beispielsweise bezeichne Text_1 das Codefragment:

public void helloWorld()
{
for (int i=1; i<=3; i++)
{
System.out.println(„Hello World“);
}
//Diese Methode schreibt 3mal Hello World 
//mit for-Schleife
//ganz leicht
}
//Ende

Und Text_2 bezeichne das Codefragment:

public void helloWorld()
{
//Diese Methode schreibt 3mal Hello World
//mit for-Schleife
for (int i=0; i<3; i++)
{
//Ausgabe
System.out.println(„Hello World“);
}
//ganz leicht
}
//Ende

Zur Beschreibung von Datei 2 auf Basis von Datei 1 sind folgende Befehle nötig:

Move (0,2)
Move (6,2)
Add (for (int i=0; i<3; i++))
Move (1,1)
Add (//Ausgabe)
Move (4,2)
Move (8,3)

Der Tychy-Algorithmus arbeitet mit einer äußeren while-Schleife und einer inneren Schleife. Die äußere Schleife wird solange durchlaufen bis der start_2 die Indexgrenze n überschritten hat.

Das vorkommende Label F bezeichnet einen Teilalgorithmus, den wir später erläutern. Der Teilalgorithmus F findet iterativ start_1 und laenge zu dem aktuellen Index start_2, dass den Blockmove maximiert.

while start_2 ≤ n do

begin

F: find start_1 and laenge such that (start_1, start_2, laenge)

is a maximal block move for start_2

if laenge > 0 then print (start_1 , start_2, laenge)

start_2 := start_2 + Max (1, laenge)

end

Verständnisfrage:

Was geschieht wenn eine Zeile in Text_2 nicht in Text_1 enthalten ist ?

In der äußeren Schleife wird der Teilalgorithmus F aufgerufen: das Ergebnis sind aktualisierte start_1 und laenge. Eine nichtverschwindene Variable laenge wird ausgegeben mit den aktualisierten start_1 und den aktuellen start_2. Dan wird start_2 um das Inkrement Max(1, laenge) erhöht.

Definition: Ein Block Move ist ein 3- Tupel (start_1, start_2, laenge), mit

start_1 : Startzeile von Text_1 start_2: Startzeile von Text_2 laenge: Länge des Block Moves

so dass gilt:

Die Textzeilen von Text_1 und Text_2 sind zwischen den Indizes start_i und start_i+laenge-1 (i=1,2) identisch.

Text_1[start_1, ..., start_1+laenge-1] = Text_2[start_2, ..., start_2+laenge-1]

(0 ≤ start_1 ≤ m-laenge+1 ; 0 ≤ start_2 ≤ n-laenge+1)

Anmerkung:

Jede Zeile Text_2i, die auch in Text_1 vorkommt, ist in genau einem Block Move enthalten.
Zeilen von Text_1 können in mehreren Block Moves enthalten sein.
Ein minimales Coverage Set ist das Coverage Set mit den wenigsten Block Moves

illustratives Beispiel für den äußeren Schleifendurchlauf:

Schreiben Sie sich die 3-Tupel des Blockmove auf ! Die vom Blockmove betroffenen Zeilen sind gelb angedeutet.

Text_1 = { x y a a a b c q s t u }
Text_2 = { x f a a b c q s h }

Verständnisfrage: Was ist das minimale coverrage set ?

Der Tichy-Algorithmus findet das minimale Coverage Set. Der Beweis erfolgt über Induktion

Teilalgorithmus F: Die inneren Schleifen beim Tichy-Algorithmus

1. innere Schleife: Gewährleistet die vollständige Durchsuchung von Text_1 für gegebene Position start_2

2. innere Schleife: Ermittelt die Länge des aktuellen Block Moves für die Positionen start_2 und start_1_aktuell

laenge := 0; start_1 := 0; start_1_aktuell := 0;

while start_1_aktuell + laenge ≤ m and { nicht größer als Länge von Text_1}

start_2 + laenge ≤ n do { nicht größer als Länge von Text 2}

begin {Ermittlung der Länge zwischen Text_1[start_1_aktuell,…] and Text_2[start_2,…]}

laenge_aktuell := 0

while (start1_aktuell ++ laenge_aktuell

\leq

m)

and {nicht Ende von Text_1 erreicht}

(start_2 + laenge_aktuell

\leq

n) and {nicht Ende von Text_2 erreicht}

(Text_1 [start_1_aktuell + laenge_aktuell] = Text_2 [start_2 + laenge_aktuell]) {Zeile in Text_1 = Zeile in Text_2}

do laenge_aktuell := laenge_aktuell + 1 {erhöhte aktuelle Block Move-Länge um 1}

if laenge_aktuell > laenge then

begin { längerer Block Move gefunden }

laenge := laenge_aktuell

start_1 := start_1_aktuell

end

start_1_aktuell := start_1_aktuell + 1

end

Erläuterndes Beispiel:

Welcher Block wird ausgewählt ? Notieren Sie die 3-Tupel des Block Moves !

Text_1 = { x y a a a b c q s t u }
Text_2 = {x f a a b c q s h }

Text_1 = { x y a a a b c q s t u }
Text 2 = {x f a a a b c q s h }

Text 1 = { x y a a a b c q s t u }
Text_2 = {x f a b c q s h }

start_1_aktuell: 5
laenge: 6 m: 10
danach: Abbruchbedingung erfüllt (5 + 6 ≤ 10)

E-Learning-Tool für den Tichy Algorithmus

Im Rahmen eines Projektseminars an der Universität Duisburg-Essen wurde ein Anwendungsprogramm entwickelt, um den Tichy Algorithmus zu üben. Die Anwendung unterstützt verschiedene Schwierigkeitsgrade, ein variables Zeitlimit und die Möglichkeit, eigene bzw. zufallsgenerierte Zeichensequenzen zu erstellen. Nach Eingabe der Variablen kann eine Musterlösung eingeblendet werden. Fehlerhafte Eingaben werden farblich hervorgehoben.

Dieses E-Learning-Tool ist erreichbar unter der folgenden Adresse: http://code.google.com/p/pseminar/

Die aktuelle Versionsnummer lautet 1.4.

Kapitel Testen