Methoden und Architekturen der Softwaretechnik

Frontmatter

Kapitel 1. Problembereich und Lösungsbereich

Zusammenfassung

Zuerst werden in Kapitel 1.1 die Begriffe “Problembereich” und “Lösungsbereich” erläutert und die grundlegenden Schritte der Software-Entwicklung in diesen beiden Bereichen vorgestellt. Danach werden in Kapitel 1.2 das funktionsorientierte Paradigma, sowie das objektorientierte, datenorientierte und aspektorientierte Paradigma umrissen. Ein Paradigma ist hierbei ein Denkkonzept.

Joachim Goll

Kapitel 2. Die vier Ebenen des Software Engineerings

Zusammenfassung

Die Softwareentwicklung ist dasjenige Gebiet der Informatik, das sich mit der Erstellung von Programmsystemen befasst. Wissenschaftliche Methoden begleiten die industrielle Praxis [Pom96].

Joachim Goll

Kapitel 3. Ausprägungen von Vorgehensmodellen

Zusammenfassung

Da die verschiedenen Tätigkeitsschritte der Entwicklung sich heutzutage überlappen, muss in aktuellen Konzepten zwischen sequenziellen Projektphasen und Tätigkeitsschritten der Entwicklung unterschieden werden. Die Projektphasen braucht man nach wie vor, schon um Meilensteine im Projekt definieren zu können. Meilensteine charakterisieren Fertigstellungstermine bestimmter Erzeugnisse. Diese können nicht verschmiert werden. Tätigkeitsschritte, die vor einem Meilenstein geplant sind, finden wegen der erforderlichen Änderungen an der Software auch nach Meilensteinen statt. Streng gesehen wird man nie fertig, da sich alles stets ändert. Ein Ende einer Projektphase muss nach bestimmten Kriterien definiert werden.

Joachim Goll

Kapitel 4. Qualität von Softwaresystemen

Zusammenfassung

Eine Software ist nur brauchbar, wenn sie die versprochenen Funktionen erfüllt, eine stabile Konstruktion darstellt und zuverlässig ist, vernünftige Antwortzeiten hat und leicht bedienbar ist. Hierzu werden Requirements an die Qualität aufgestellt, die Teil der Forderungen an das zu realisierende System sind. Für die Einhaltung der Qualitätsforderungen muss die Qualitätssicherung in Zusammenarbeit mit den Entwicklern sorgen. Jede Qualitätsforderung muss durch eine entsprechende Maßnahme sichergestellt und überprüft werden können.

Joachim Goll

Kapitel 5. Requirements

Zusammenfassung

Requirements sind Anforderungen. Ziel des Requirement Engineerings ist es, in systematischer, ingenieursmäßiger Vorgehensweise eine Requirement-Spezifikation zu erstellen, die die tatsächlichen Anforderungen an ein Produkt best möglich beschreibt, so dass das Produkt den Wünschen des Kunden entspricht. Wenn dieses Ziel nicht erreicht wird, sei es z. B. infolge von Unvollständigkeit, Widersprüchlichkeiten oder Mehrdeutigkeiten, so wird der Kunde mit dem Produkt nicht zufrieden sein. Der Prozess der Entwicklung eines Produkts kann nur dann zum Erfolg führen, wenn der Kunde seine Wünsche erfüllt sieht. Requirements werden in einer Requirement-Spezifikation erfasst. Ein Requirement an ein System ist eine Anforderung des Kunden an die Funktionalität eines Systems bzw. an die Systemeigenschaften oder eine Einschränkung an den Entwurf.

Joachim Goll

Kapitel 6. Funktionsorientierte Modellierung mit der Strukturierten Analyse

Zusammenfassung

Die Strukturierte Analyse (SA) hat sich seit ihren Anfängen in der Mitte der siebziger Jahre zu einer wichtigen Standardmethode der Systemanalyse entwickelt. Die Art der grafischen Darstellung der Vernetzung von parallelen Funktionen bzw. Prozessen in Datenflussdiagrammen, die den Kern der Strukturierten Analyse darstellen, wurde bereits vor fast 90 Jahren von Forschern auf dem Gebiet des Operation Research [You92] verwendet. Diese Forscher befassten sich mit Arbeitsflussmodellen für Betriebe. Der Zusammenhang liegt natürlich auf der Hand: sowohl bei den Datenflüssen der Datenverarbeitung als auch bei den Arbeitsflussmodellen der Geschäftsprozesse gibt es Prozesse, die definierte Ergebnisse produzieren, wobei das Vorliegen dieser Ergebnisse wiederum Voraussetzung dafür ist, dass andere Prozesse arbeiten können.

Joachim Goll

Kapitel 7. Funktionsorientierte Modellierung mit der Strukturierten Analyse/Echtzeit

Zusammenfassung

Strukturierte Analyse/Echtzeit (engl. structured analysis/real time, SA/RT)) ist die Realzeiterweiterung der Strukturierten Analyse. Sie dient zur Modellierung der Reaktion eines Systems auf bestimmte Ereignisse, z. B. dass eine Steuerung bei Vorliegen einer bestimmten Bedingung ein Steuersignal für ein Fremdsystem generiert. Während die Strukturierte Analyse auf dem Konzept der Datenflüsse beruht, unterscheidet die Strukturierte Analyse/Echtzeit Steuerflüsse von Datenflüssen.

Joachim Goll

Kapitel 8. Datenorientierte Modellierung mit dem Entity-Relationship-Modell

Zusammenfassung

Das Entity-Relationship-Modell (ERM) stellt das älteste und allgemeinste Modell zur strukturierten Modellierung von Daten dar. Es wurde 1970-76 von Chen [Che76] definiert und später vielfach weiterentwickelt. Wegen ihrer Bedeutung für die Modellierung von Daten wurde die Entity-Relationship-Modellierung nachträglich in die Strukturierte Analyse (siehe Kapitel 6) aufgenommen.

Joachim Goll

Kapitel 9. Objektorientierte Grundlagen

Zusammenfassung

Nach dem Vergleich des objektorientierten Ansatzes mit funktionsorientierten Techniken in Kapitel 9.1 folgen in Kapitel 9.2 die grundlegenden Eigenschaften von Objekten. Kapitel 9.3 behandelt die Vererbung, Kapitel 9.4 die Komposition und Aggregation, Kapitel 9.5 den Vergleich von Mehrfachvererbung zu Komposition und Aggregation, Kapitel 9.6 Polymorphie und Kapitel 9.7 Verträge.

Joachim Goll

Kapitel 10. Objektorientierte Notation mit UML – eine Einführung

Zusammenfassung

Die Unified Modeling Language (UML) ist eine standardisierte Notationssprache zur Beschreibung der objektorientierten Modellierung von Systemen. Sie wurde von der ISO standardisiert (ISO/IEC 19501). Das objektorientierte Konzept und die objektorientierte Methodik selbst beruhen nicht auf UML, sondern können mit Hilfe von UML notiert werden. UML hat eine große Bedeutung in der Praxis erlangt.

Joachim Goll

Kapitel 11. Einführung in standardisierte Diagrammtypen nach UML

Zusammenfassung

Diese Diagramme sind festgelegte Sichten auf ein Modell. Die Diagrammtypen nach UML sind gekoppelt und können nicht als orthogonal zueinander betrachtet werden. Oft lassen sich für einen bestimmten Zweck verschiedene Diagramme einsetzen.

Joachim Goll

Kapitel 12. Objektorientierte Systemanalyse

Zusammenfassung

Zunächst werden in diesem Hauptkapitel die grundsätzlichen Objektarten Entity-, Kontroll- und Interface-Objekte besprochen. Dann wird ein erprobter Satz von Schritten zur Durchführung der Objektorientierten Systemanalyse aufgestellt. Beispiele hierzu runden dieses Kapitel ab.

Joachim Goll

Kapitel 13. Entwurfsprinzipien

Zusammenfassung

Im Folgenden werden Entwurfsprinzipien, die aus Sicht des Autors in der Praxis zu einem erfolgreichen Entwurf beitragen können, vorgestellt. Weitere in der Literatur genannte Prinzipien, die nicht auf der Erfahrung des Autors beruhen, werden nicht aufgeführt.

Joachim Goll

Kapitel 14. Funktionsorientierter Systementwurf

Zusammenfassung

Der funktionsorientierte Systementwurf hat zum Ziel, die im Rahmen der funktionsorientierten Systemanalyse eingeführten Funktionen und Daten auf Programme abzubilden, die dann im Rahmen der Implementierung zu programmieren sind. Hierbei sind insbesondere die Fähigkeiten eines Betriebssystems bzw. das Fehlen eines Betriebssystems zu berücksichtigen. Mit anderen Worten, der Systementwurf dient zur Abbildung der Essenz des Systems auf das jeweilige Betriebssystem oder auf einen Rechner ohne Betriebssystem.

Joachim Goll

Kapitel 15. Datenorientierter Systementwurf

Zusammenfassung

Die Verwaltung von Informationen spielt heutzutage eine immer wichtigere Rolle. Es gibt kaum ein Informationssystem, das in der Lage ist, seine Informationen ohne eine Datenbank zu verwalten. Datenbankverwaltungssysteme oder Datenbankmanagementsysteme (kurz DBMS) und die darin verwalteten Datenbanken sind aus den heutigen Projektlandschaften nicht mehr wegzudenken.

Joachim Goll

Kapitel 16. Objektorientierter Systementwurf

Zusammenfassung

Beim Entwurf wird das Programm in seiner Struktur entworfen. Das Programm muss dabei eine solche Programmstruktur erhalten, dass es in der Lage ist, die Dynamik der gewünschten Anwendungsfälle durchzuführen und seinen Nutzern als Leistung des Systems fehlerfrei anzubieten. Bei der Formulierung der Struktur und der Dynamik des Programms können bewährte Muster wie Architekturmuster (siehe Kapitel 18) oder Entwurfsmuster (siehe Kapitel 17) eine Hilfe darstellen. Als Beispiel sei hier das Architekturmuster Layers (siehe Kapitel 18.1) genannt. Dieses Muster gliedert die Struktur eines Systems in ein Schichtenmodell aus gekoppelten Teilsystemen mit Service-Aufrufen von einer oberen Schicht zu einer direkt darunter liegenden Schicht. Beim Entwurf müssen alle Arten von Funktionen berücksichtigt werden, die für die Lauffähigkeit des Programms entscheidend sind. Dies wird im Folgenden erläutert.

Joachim Goll

Kapitel 17. Objektorientierte Entwurfsmuster

Zusammenfassung

Objektorientierte Entwurfsmuster (engl. design patterns) sind bewährte Muster, die beim Entwurf von Systemen zur Kenntnis genommen werden sollten, da sie Lösungsvorschläge für bestimmte Problemstellungen sind, die sich bereits in mehreren Systemen bewährt haben.

Joachim Goll

Kapitel 18. Architekturmuster

Zusammenfassung

Das Besondere an den Architekturmustern ist, dass damit sehr schnell komplexe Sachverhalte auf einfache Weise dargestellt werden können. Entwurfsmuster stellen feinkörnige Muster dar, während Architekturmuster grobkörnig sind. Architekturmuster lösen nicht ein Teilproblem, sondern beeinflussen die Grundzüge der Architektur eines Systems.

Joachim Goll

Kapitel 19. Systementwurf bei aspektorientierter Programmierung

Zusammenfassung

Die Aspektorientierte Programmierung (AOP) ist eine Erweiterung des Konzepts der Objektorientierung. Eine wichtige Zielsetzung der Objektorientierung ist die Wiederverwendbarkeit von Klassen, jedoch ist es in der Praxis eher selten, dass eine Klasse ohne Änderung übernommen werden kann. Es gibt auch viele Programmteile, die sich quer durch die Geschäftslogik ziehen wie zum Beispiel das Logging.

Joachim Goll

Kapitel 20. Test und Integration

Zusammenfassung

In den vorangehenden Kapiteln wurden im Wesentlichen die Schritte zur Erstellung der Software vorgestellt. Jedes relevante Dokument und jedes Programm sollte jedoch getestet und abgenommen sein, ehe es in den Einsatz übergeht.

Joachim Goll

Backmatter