Startseite
Vorlesungen
Automotive SE
Softwarearchitektur
TI
IT-Projekte
Abschlussarbeiten
Publikationen
Programmkomitees
Werdegang
MAENAD
Kontakt
Impressum
Sitemap
English

Softwarearchitektur

 

Newsfeed zur Veranstaltung

Link zur Moodleseite der Veranstaltung.

Den Eintrag dieser Vorlesung im Modulhandbuch finden Sie hier.

Die wichtige Literatur zur Veranstaltung finden Sie im elektronischen Semesterapparat. Um den Semesterapparat auch von zu Hause aus nutzen zu können, ist eine Einrichtung des VPN nötig.
Eine Einleitung dazu finden Sie hier.

 

Ort und Zeitpunkt


Vorlesung: Montag 11:30-13:00, Raum W307

 

Die Übungen finden regulär im Laborraum (Q413) statt, außer in der Vorlesung oder im Newsfeed wird etwas anderes angekündigt.

Übung Gruppe 1: Montag 09:45-11:15, Raum Q305 (Seminarraum), Q413 (Laborraum)
Übung Gruppe 2: Montag 14:00-15:30, Raum Q305 (Seminarraum), Q413 (Laborraum)

 

Terminplan


19.03.2012: Einführung

26.03.2012: Prinzipien zur Bewältigung der Komplexität, Modularität

02.04.2012: Termin fällt aus

09.04.2012: Termin fällt aus (Ostern)

16.04.2012: Objektorientierung

23.04.2012: Objektorientierung

30.04.2012: Clean Code

07.05.2012: Clean Code

14.05.2012: Erweiterungen des OO Paradigmas

21.05.2012: Architekturbeschreibung

28.05.2012: Termin fällt aus (Pfingsten)

04.06.2012: Patterns Einführung, Architekturmuster, Programming Idioms

11.06.2012: Design Patterns

18.06.2012: Design Patterns

25.06.2012: Gastvortrag von Frank Buschmann (Siemens AG) zum Thema
                               Design Patterns—Rückblick, Stand und Ausblick

02.07.2012: Wiederholung

 

Vorlesungsunterlagen


Die Kapitel des Textskriptes werden über das OSO System zur Verfügung gestellt. Bitte lassen Sie sich diese Kapitel nicht als Ringbindung aushändigen, sondern als lose Blattsammlung: Dies spart (Ihr) Geld und Sie haben außerdem den Vorteil, dass Sie die einzelnen Kapitel sukzessive in einem Ordner abheften können.

Alle weiteren Materialien der Veranstaltung werden über Moodle zur Verfügung gestellt.

 

Leistungsnachweis


Klausur (90 Minuten) am Semesterende. Zugelassene Materialien: 3 Seiten (DIN A4) selbstverfasste Notizen.

Stoff: Vorlesung und Übungen, Artikel zu ausgewählten Themen (werden im Laufe der Vorlesung angekündigt)

Nach § 7 (5) der Studien- und Prüfungsordnung für den Bachelorstudiengang Informatik kann an der Prüfung nur teilnehmen, wer "den praktischen Teil des praktischen Studiensemesters absolviert hat und dies durch das Zeugnis der Ausbildungsstelle nachgewiesen hat".

 

Programmierkenntnisse


Bitte beachten Sie, dass Java die zentrale Programmiersprache dieses Kurses ist. Sie können einführende Hinweise zu Java in dem von meinem Kollegen Michael Kipp an der Hochschule Aachen verfassten Java Notbuch finden; einen sehr lesenswerten Einstig in Java bietet die Head-First Reihe; alternativ dazu können Sie auch das Buch Programmieren lernen mit Java konsultieren. Auch C++ wird in diesem Kurs eine Rolle spielen. Ein gutes Buch zu dem Thema hat Ralf Schneeweiß verfasst: Moderne C++ Programmierung: Klassen, Templates, Design Patterns. Auch JavaScript Kenntnisse benötigen Sie für den Kurs; dazu kann ich Ihnen dieses Buch empfehlen: JavaScript: The Good Parts. Auf Deutsch ist das Buch JavaScript: Einführung, Programmierung und Referenz zu empfehlen.

 

Literatur


Bitte denken Sie daran: Die wichtige Literatur zur Veranstaltung finden Sie im elektronischen Semesterapparat. Dennoch gebe ich hier einen Überblick über wichtige Veröffentlichungen zum Thema mit jeweils kurzen Bemerkungen.

 

Einführung

  • David Lorge Parnas: "Software aspects of strategic defense systems", Communications of the ACM, Volume 28, Issue 12, ACM New York, NY, USA, December 1985. pp. 1326–1335.
    • Nachdem sich Parnas aus dem US-amerikanischen Panel on Computing in Support of Battle Management zurückgezogen hat, veröffentliche ACM die acht kurzen Essays, die Parnas mit seinem Kündigungsschreiben eingereicht hatte. In diesen Essays entwirft Parnas ein pessimistisches Bild der Softwareentwicklung. Themen der Essays sind: 1. Die fundamentalen technologischen Unterschiede zwischen dem Software Engineering und anderen Ingenieurdisziplinen und warum Software unzuverlässig ist. 2. Die Eigenschaften der vorgeschlagenen strategischen Verteidigungssoftware, die der Grund dafür sind, dass sie unerschwinglich ist. 3. Warum die Techniken, die typischerweise genutzt werden, um Militärsoftware zu entwickeln, der Aufgabe nicht angemessen sind. 4. Die Natur der Software Engineering Forschung und warum deren denkbare Verbesserungen nicht ausreichen werden, um wirklich zuverlässige Verteidigungssoftware zu entwickeln. 5. Warum er nicht davon ausgeht, dass die Forschung im Bereich der Künstlichen Intelligenz helfen wird, zuverlässige Militärsoftware hervorzubringen. 6. Warum er nicht davon ausgeht, dass die Forschung im Bereich der automatischen Programmierung (Parnas meint damit im Wesentlichen die Programmierung in einer höheren Programmiersprache) die substantiellen Verbesserungen hervorbringen wird, die benötigt werden. 7. Warum uns die Programmverifikation (mathematische Beweise der Korrektheit) keine zuverlässige strategische Verteidigungssoftware geben kann. 8. Warum militärische Forschungsfinanzierung von Software und anderen Bereichen der Informatik ineffizient und ineffektiv ist.
  • Frederick P. Brooks, Jr.: "No Silver Bullet Essence and Accidents of Software Engineering", Computer, Volume 20, Issue 4, IEEE Computer Society Press Los Alamitos, CA, USA, April 1987. pp. 10–19.
    • Ein anregend geschriebenes Papier über die inhärente und zufällige Komplexität der Software. Brooks entwirft, ähnlich wie Parnas zwei Jahre zuvor, ein eher pessimistisches Bild der Softwareentwicklung, indem er argumentiert, dass die Komplexität der Softwareentwicklung inhärent ist und dass bisherige Techniken wenig Wirkung an dieser Komplexität gezeigt hätten.
  • David Harel: "Biting the Silver Bullet: Toward a Brighter Future for System Development", Computer, Volume 25, Issue 1, IEEE Computer Society Press Los Alamitos, CA, USA, January 1992. pp. 8–20.
    • Harel (der Erfinder der Statecharts) antwortet auf die beiden entmutigenden Papiere von Parnas (1985) und Brooks (1987) und äußert sich über das Potential des Software Engineering. Während er den meisten spezifischen Punkten der beiden Papiere zustimmt, beleuchtet er die hellen Seiten des Software Engineering. Dabei geht er insbesondere auf aktuelle Entwicklungen der letzten Jahre ein, die noch zu jung oder unreif waren, um Parnas oder Brooks beeinflusst zu haben. Insgesamt kommt er damit zu einem sehr viel positiveren Bild des Stands und der Zukunft des Software Engineering.

Softwarearchitektur allgemein

  • Balzert, Helmut: Lehrbuch der Software-Technik / Helmut Balzert. - Heidelberg [u.a.] : Spektrum, Akad. Verl. - (Lehrbücher der Informatik) 1. Basiskonzepte und requirements engineering. - 3. Aufl. - 2009.
    • Ein sehr gutes Buch als Einführung ins Software Engineering und als Wiederholung einiger Aspekte der UML. Wir befassen uns in dieser Veranstaltung mit Software Engineering Prinzipien, die Sie auf den Seiten 25-51 besprochen finden.
  • Bass, Len: Software architecture in practice / Len Bass, Paul Clements, Rick Kazman. - 2nd ed. - Boston: Addison-Wesley, SEI series in software engineering, 2003.
    • Dieses Buch bietet eine umfassende Einführung in die Softwarearchitektur und kann als Ergänzung und Vertiefung zu unserer Veranstaltung gelesen werden. Themen, die wir in der Veranstaltung nicht abdecken, sind die Analyse von Architekturen (ab Seite 261) und systematische Wiederverwendung durch Software-Produktlinien, falls Sie sich nicht im Wahlthema dafür entscheiden (ab Seite 351).
  • Clements, Paul: Documenting software architectures: views and beyond / Paul Clements ... [u.a.]. - 2nd ed. - Upper Saddle River, N.J. : Addison-Wesley, SEI series in software engineering, 2011.
    • Das systematischste Buch zum Thema Dokumentation von Softwarearchitekturen. Die einzelnen Kapitel können einzeln gelesen und verstanden werden; wenn Sie sich für die Fragen interessieren, warum Dokumentation von Softwarearchitektur notwendig ist, was die Dokumentation leisten kann und wie Sie die Dokumentation sinnvoll einsetzen, dann kann ich Ihnen dieses Buch empfehlen. Es kann als Vertiefung zu unserer Veranstaltung herangezogen werden. Wir decken wesentliche Teile des Buches ab. Leseempfehlungen: Seite xxi (Warum ein Vogelflügel als Cover gewählt wurde), Seite 148 (Einführung und Begriffe), Seite 5564 (Modulsicht), Seite 123153 (Komponenten und Konnektoren), Seite 431ff (UML Wiederholung), Seite 473ff (Kurzeinführung AADL), Seite 491ff (Glossar).
  • Perry, Dewayne A.: Foundations for the Study of Software Architecture / Dewayne A. Perry ; Alexander L. Wolf In: ACM SIGSOFT software engineering notes / Association for Computing Machinery / Special Interest Group on Software Engineering. - New York, NY : ACM
    Band 17, Heft 4, Okt. 1992. - S. 40–52.
    • Ein lesenswertes Papier als Einstieg in die Softwarearchitektur, da leicht
      nachvollziehbare Analogieschlüsse zu Hardwarearchitektur, Netzwerkarchitektur und
      Gebäudearchitektur gezogen werden.

Modularität

  • Baldwin, Carliss Y.: Design rules / Carliss Y. Baldwin and Kim B. Clark. - Cambridge, Mass. [u.a.] : MIT Press 1. The power of modularity. - 2000.
    • Dieses Buch widmet sich vollständig dem Thema Modularität und beleuchtet diesen Aspekt aus unterschiedlichen Blickwinkeln. Spannend für uns sind die Seiten 63–83, wo Modularität definiert und die Handhabung von Kohärenz und loser Kopplung am Beispiel der Design Structure Matrix und der Task Structure Matrix eingeführt wird. Seite 123–146 führt die modularen Operatoren ein.
  • Parnas, David Lorge: On the Criteria to be used in Decomposing Systems into Modules / D. L. Parnas
    In: Communications of the ACM / Association for Computing Machinery. - [New York, NY] : ACM
    Band 15, Heft 12, Dez. 1972. - S. 1053-1058.
    • David M. Weiss (auf Seite 143) schreibt über dieses Papier: "What makes a paper revolutionary? Is it the breadth and depth of the new ideas it presents? Is it the cogency of the arguments? [...] Most important, is it the paper's ability to change the way its readers think about the world? This paper does all of the above. [...] it sparkles with ideas that are cogent and relevant and, incidentally, that are continually being rediscovered. [...]
      Idea: A module is a work assignment. Before this paper, many programmers considered, and many still do, that a module is a set of routines that are related in some way, usually vaguely specified. [...] Dave says that a module is an assignment of responsibility and that every module is characterized by its knowledge of a design decision that it hides from all others. [...]
      Idea: At runtime, one might not be able to distinguish what criteria were used to decompose the system into modules. [...] When we make a decision becomes nearly as important as what decision we make. [...] Aspect-oriented programming, a current vogue in programming technique, appears to be a rediscovery of the use of binding time in creating modular designs. [...]"
      Dem habe ich nichts hinzuzufügen.

Objektorientierung

Aspektorientierung

Feature-oriented Programming

Architekturbeschreibung

Architekturmuster, Entwurfsmuster