Softwarearchitektur - Software and Systems Engineering

Transcrição

Softwarearchitektur - Software and Systems Engineering
Softwarearchitektur
(Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach)
1. Einleitung und Überblick
Vorlesung Wintersemester 2005 / 2006
Technische Universität München
Institut für Informatik
Lehrstuhl von Prof. Dr. Manfred Broy
Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.2
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.3
Problemstellung
ƒ Beobachtungen:
ƒ Der Alltag ist immer stärker durchdrungen von Software
ƒ Software bestimmt immer mehr den Erfolg (von Produkten, oä.)
ƒ Die Größe von Systemen wächst kontinuierlich
(siehe beispielsweise Toll-Collect, FISCUS, etc.)
ƒ Unsere Fähigkeit, Softwaresysteme zu entwickeln
wächst langsamer als der Bedarf (sog. „Software-Krise“)
ƒ Nur etwa 25% aller Entwicklungsprojekte verlaufen
erfolgreich (hinsichtlich Zeit, Qualität, Kosten)
ƒ Bis zu ca. 75% der Gesamtkosten eines Softwaresystems
fallen nach Fertigstellung an
Softwarearchitektur – 1. Einleitung
1.4
Ansatz: Software-Engineering
ƒ Softwareentwicklung wird aufgefasst als Ingenieursdisziplin, mit
Methoden, Techniken und Werkzeugen, die teilweise von
traditionellen Disziplinen (z.B. Maschinenbau oder Architektur)
„abgeschaut“ werden.
ƒ Komplexität wird begegnet mit dem Handwerkszeug des Ingenieurs
ƒ Teile und Herrsche: ein Problem wird in kleinere Häppchen zerlegt, die
versteh- und handhabbar sind (-> Modul, Komponente)
ƒ Abstraktion: die für die aktuelle Zielsetzung irrelevanten Details werden
ausgeblendet (-> Schnittstelle)
ƒ Wiederverwendung: die Situation wird mit verstandenen Problemen
korreliert, für die Lösungen bekannt sind
ƒ Softwarearchitektur ist eine Teildisziplin des Software-Engineerings,
für die sich überraschend viele Analogien zur klassischen
Architektur finden lassen
Softwarearchitektur – 1. Einleitung
1.5
Beispiel: das Münchner Olympiagelände
ƒ Gewinner des damaligen
Architekturwettbewerbs:
G. Behnisch
ƒ Gebaut in den Jahren
1966-1972
ƒ Charakteristisches
Zeltdach, gestützt von
58 Pylonen
ƒ Konzipiert als „offenes
Amphitheater“
ƒ Unter Denkmalschutz seit
1977
Softwarearchitektur – 1. Einleitung
1.6
Wichtigste Anforderungen
ƒ Langlebigkeit
ƒ Vielfältige Einsatzmöglichkeiten (7.400 Veranstaltungen seit ´72)
ƒ Dauerhaftigkeit der Strukturen
ƒ Geringe Wartungskosten (vgl. andere Städte!!!)
ƒ Ästhetik
ƒ Imagetransport, auch über Olympia hinaus
ƒ Unterstützung der Funktion
ƒ Berücksichtigung lokaler Gegebenheiten
ƒ Brachgelände mit angrenzendem Schuttberg
ƒ Balance zwischen Qualität, Zeit und Kosten
ƒ Begrenztes Budget
ƒ Hoher Zeitdruck
ƒ Und viele mehr….
Softwarearchitektur – 1. Einleitung
1.7
Leistung der Architekten
ƒ Spektakuläre Ingenieursleistung
ƒ Dachkonstruktion nicht „berechenbar“
ƒ Einfache Simulationsmodelle
ƒ Eleganz, Transparenz, Leichtigkeit
ƒ Organische Einbettung der Sportanlagen in die Umgebung
ƒ „Blick über den Tellerrand“
ƒ Konzeption eines dauerhaften Naherholungsgebiets
ƒ Vielfältige Einsatzmöglichkeiten (Studentenstadt, Konzerte und
Fußballspiele im Stadion, etc.)
Softwarearchitektur – 1. Einleitung
1.8
Konkretes Beispiel: Bungalows im Olydorf
ƒ 800 Bungalows
ƒ Fertigstellung 1.5.1971
ƒ Geplant und gebaut von
Werner Wirsing (Preis für
vorbildliches Bauen vom
Bund deutscher
Architekten)
ƒ Grundstück: ehemaliger
Flughafen
Oberwiesenfeld
ƒ Auftraggeber: Deutsches
Studentenwerk
Softwarearchitektur – 1. Einleitung
1.9
Sich ändernde Anforderungen der Bungalows
ƒ Anforderung: Sportlerheim
ƒ Trennzaun zwischen Männerund Frauenbereich
ƒ Aktivitäts- (Schwimmbad) und
Erholungsbereiche
ƒ „Sportlermensa“
ƒ Leichte Erreichbarkeit der
Sportstätten
ƒ Anforderung: Studentendorf
ƒ Gemeinschaftszentrum mit
Disco, Tee- und Bierstube,
Kino
ƒ Günstige Unterkunft
ƒ Hohe Fluktuation
ƒ Einfaches Navigationskonzept von Otl Aicher über Farben an den
Eingangstüren und im Außenbereich („Media-Linien“)
ƒ Moderne Infrastruktur (Parkplätze, U-Bahn-Anschluß, etc.)
ƒ Ansprechende Gestaltung
Softwarearchitektur – 1. Einleitung
1.10
Die zentrale Rolle des Architekten
ƒ Aufsammeln, Bewerten und Priorisieren der
teils mannigfaltigen Anforderungen
ƒ Konzeption und Umsetzung einer qualitativ
hochwertigen Architektur…
ƒ … unter Berücksichtigung von Zeit und
Kosten!
Softwarearchitektur – 1. Einleitung
1.11
Die Disziplin „Architektur“
»Architektur ist die Kombination von utilitas, firmitas
und venustas.« frei nach Vitruvius (Römischer Architekt 90-20 v. Chr.)
ƒ
utilitas : das Gebäude erfüllt seine Funktion
ƒ
firmitas : das Gebäude ist stabil
ƒ
venustas : das Gebäude ist ästhetisch gestaltet
Softwarearchitektur – 1. Einleitung
1.12
Die Disziplin „Architektur“
»Architektur ist die Kombination von utilitas, firmitas
und venustas.« frei nach Vitruvius (Römischer Architekt 90-20 v. Chr.)
ƒ
utilitas : das Gebäude erfüllt seine Funktion
(das Softwaresystem erfüllt seine Anforderungen)
ƒ
firmitas : das Gebäude ist stabil
ƒ
venustas : das Gebäude ist ästhetisch gestaltet
(das Softwaresystem weist klare, logische Strukturen
auf, die das Verständnis vereinfachen)
(das Softwaresystem ist langlebig und
„stabil“ gegenüber Änderungen)
Softwarearchitektur – 1. Einleitung
1.13
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.14
Softwarearchitektur als Teil der Lösung
ƒ
Softwarearchitektur
ƒ unterteilt das Anwendungssystem in Bestandteile mit definierten
Verantwortlichkeiten und einem festgelegten Zusammenspiel
ƒ ermöglicht die Beurteilung der Qualität des Gesamtsystems anhand der
Qualitäten der Einzelteile
ƒ definiert Schnittstellen für zukünftige Erweiterungen
ƒ
Begriffsdefinition: „Eine Softwarearchitektur besteht aus einer Menge
von Komponenten und ihren Beziehungen untereinander.“
ƒ
Die Softwarearchitektur beeinflusst maßgeblich Entwicklungs- und
Weiterentwicklungsprozesse
ƒ
Die „Disziplin Softwarearchitektur“ wird als Teil des Software-Engineerings
verstanden und definiert Methoden, Techniken und Werkzeuge zur
effizienten Entwicklung qualitativ hochwertiger Softwarearchitekturen.
Softwarearchitektur – 1. Einleitung
1.15
Weitere Definitionen (1)
Es existieren über 90 Definitionen des Begriffs „Softwarearchitektur“
(siehe http://www.sei.cmu.edu)
ƒ
„Architecture is defined [...] as the fundamental
organization of a system, embodied in its components, their
relationships to each other and to the environment, and the
principles governing its design and evolution.“
(IEEE Std. No. 1471-2000)
ƒ „The structure of the components of a program/system their
interrelationships, and principles and guidelines governing
their design and evolution over time.
(Garlan und Perry, 1995)
Softwarearchitektur – 1. Einleitung
1.16
Weitere Definitionen (2)
ƒ „…the highest level concept of a system in ist environment. The
architecture of a software system is its organization or structure of
significant components interacting through interfaces, those
components being composed of successively smaller components and
interfaces.“
(Rational Unified Process)
ƒ „In most successful software projects, the expert developers working
on that projects have a shared understanding of the system
design. This shared understanding is called „architecture“. This
understanding includes how the system is divided into components
and how the components interact through interfaces…“
(Ralph Jonson, 2003)
ƒ „ Architecture is a framework for change“
(Tom De Marco)
Softwarearchitektur – 1. Einleitung
1.17
Ebenso wichtig: die Rolle des Softwarearchitekten
ƒ
Aufgaben und Befugnisse
ƒ Entwurf der System- bzw. Softwarearchitektur
ƒ Umsetzung der Anforderungen an die Komponenten
ƒ Verantwortlichkeit für Implementierungs-, Integrations- und Prüfkonzept
ƒ
Fähigkeitsprofil
Kennt Anwendung, Rahmenbedingungen und Einsatzgebiete des Systems
Kennt die Schnittstellen des Systems
Kennt Architekturprinzipien und verschiedene SW-Architekturen
Kennt Standard-Software, COTS, MOTS, etc.
Kennt Methoden und Werkzeuge
Hat Fähigkeit, Schwachstellen und Risiken zu erkennen
Hat Fähigkeit, Probleme unter adäquater Berücksichtigung der SW/HW zu
analysieren und entsprechende Lösungsvorschläge auszuarbeiten
ƒ Hat Fähigkeit, zu abstrahieren und zu vereinfachen
ƒ Hat Fähigkeit, Abhängigkeiten zu erkennen
ƒ Hat Kommunikationsfähigkeit mit Anwendern und Team
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Softwarearchitektur – 1. Einleitung
1.18
Geschichte des Begriffs „Softwarearchitektur“
Wann
Wannwird
wirddie
dieDisziplin
Disziplin„Software„Softwarearchitektur“
vergleichbar
architektur“ vergleichbarmit
mitder
der
klassischen
Architektur
sein?
klassischen Architektur sein?
2010
?
2000
Hype
1990
theoretische Vorarbeiten
1980
1970
1960
Softwarearchitektur – 1. Einleitung
Erste Erwähnung
Garmisch-Konferenz
•„Software Engineering“
•Wiederverwendung
•Komponenten
1.19
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.20
Was macht eine gute Architektur aus?
Softwarearchitektur – 1. Einleitung
1.21
Negativbeispiel
ƒ „Ich habe vielleicht schon mal eine schlechte
Softwarearchitektur gesehen, da sie …“
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
kaum zu verstehen bzw. zu kommunizieren war
die Wiederverwendung von Bestandteilen nicht zuließ
zu einer schlechten Performanz des Systems führte
bei Änderungen der Anforderungen Anpassungen an ganz
unterschiedlichen Stellen erforderlich machte
nicht erweiterbar war
nicht wartbar war
sehr umfangreiche Schnittstellen definierte
etc....
Softwarearchitektur – 1. Einleitung
1.22
Positivbeispiel: Architektur eines Übersetzers
Lexical
Lexical
Analyzer
Analyzer
foo.c
Parser
Parser
tokens
Generator
Generator
abstract syntax tree
foo.out
Wer heutzutage einen Übersetzer programmiert, profitiert von einem
etablierten Verständnis der einzelnen Bestandteile und ihrer jeweiligen
Aufgaben, Verantwortlichkeiten sowie Abhängigkeiten untereinander.
Das realisierte System wird daher wohl ganz ähnlich zur obigen
Abbildung aussehen…
Softwarearchitektur – 1. Einleitung
1.23
Kernpunkte der Übersetzerarchitektur
ƒ Einfach und verständlich
ƒ ein „Datenstrom“ durchläuft verschiedene „Stationen“ mit klar
definierten Eingabe- und Ausgabeformaten
ƒ Funktionsprinzip kann schnell verstanden und kommuniziert werden
ƒ Effizient realisierbar
ƒ Zerlegung erlaubt die parallele Entwicklung in mehreren Teams
ƒ Betriebssysteme wie Unix vereinfachen die Implementierung
ƒ Langlebig
ƒ Das System kann sehr einfach um neue Funktionalität erweitert
werden, beispielsweise um eine Station, die den abstrakten
Syntaxbaum optimiert
ƒ Skalierbar
ƒ Im Rahmen einer verteilten Umgebung kann die Anwendung leicht
parallelisiert und mehrere Stationen redundant ausgelegt werden
Softwarearchitektur – 1. Einleitung
1.24
(Noch) offene Fragen…
ƒ Auf welche Weise erfüllt die Architektur die Anforderungen an das
System?
ƒ Existieren bessere Architekturen für den Übersetzerbau?
ƒ Wie ist der Zusammenhang zwischen bestimmten Merkmalen einer
Architektur und bestimmten Anforderungen?
ƒ Auf welche Weise wird eine Architektur am besten dokumentiert
und kommuniziert (mit Kästchen und Pfeilen?)
ƒ Wie können besonders gute Eigenschaften der
Übersetzerarchitektur auf andere Systeme übertragen werden?
ƒ Welche Bestandteile des Übersetzers kann man wiederverwenden
für die Realisierung weiterer Systeme? (Tatsächlich findet sich diese
Architektur in vielen Übersetzern wieder.)
Softwarearchitektur – 1. Einleitung
1.25
Wege der Wiederverwendung der Architektur
ƒ Als „Referenz-Architektur“ für den Bau von Übersetzern: Festlegung
der einzelnen Systemteile, ihrer Verantwortung und des
gemeinsamen Zusammenspiels. Erweiterungsmöglichkeiten werden
aufgezeigt.
ƒ Als „Architektur-Stil“: allgemeines Strukturprinzip, bekannt als
„pipes-and-filter“-Architektur. Datenströme werden über „pipes“
von einem „filter“ zum nächsten transportiert und dort
weiterverarbeitet. Das funktioniert nur bei Anwendungen mit
ƒ sequentialisierbaren Bearbeitungsschritten
ƒ Abhängigkeiten nur zwischen benachbarten Bearbeitungsschritten
ƒ Als „Framework“: für die Realisierung eines Übersetzers muss diese
„halbfertige Implementierung“ nur noch an wenigen Stellen
angepasst werden.
Softwarearchitektur – 1. Einleitung
1.26
Welche Qualitätseigenschaften werden durch die
Softwarearchitektur beeinflusst?
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
scalability
availability / reliability
security
safety
usability
portability
performance
interoperability
evolvability
extensability
Softwarearchitektur – 1. Einleitung
ƒ Verfahren, um die Qualität
einer Architektur beurteilen zu
können oder auch um
Architekturen vergleichbar zu
machen, sind Inhalt aktueller
Forschungen…
1.27
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.28
Überblick über die Vorlesung
„
„
„
„
„
„
„
„
„
„
„
„
„
„
17.10.:
24.10.:
07.11.:
14.11.:
21.11.:
28.11.:
05.12.:
12.12.:
19.12.:
09.01.:
16.01.:
23.01.:
30.01.:
06.02.:
Einleitung und Überblick
Ziele und Ergebnisse des Architekturentwurfs
Grundlagen der Softwarearchitektur
Beschreibungstechniken
Sichten
Model Driven Architecture (MDA)
Ausprägungen (1)
Ausprägungen (2)
Betriebliche Informationssysteme (1)
Betriebliche Informationssysteme (2)
Betriebliche Informationssysteme (3)
Eingebettete Systeme (1)
Eingebettete Systeme (2)
Telekommunikation
Softwarearchitektur – 1. Einleitung
1.29
Übersicht Kapitel 2: Ziele und Ergebnisse des
Architekturentwurfs
ƒ Das Ziel, ein Softwaresystem mit einer geeigneten
Architektur zu unterlegen, beeinflusst nachhaltig
Organisation und Entwicklungsprozess
ƒ Definition und systematische Adressierung bestimmter
Qualitätskriterien (z.B. funktionale und technische
Anforderungen)
ƒ „Softwarearchitektur“ als zentraler Dreh- und Angelpunkt des
Entwicklungsprozesses (Analyse, Design, Bewertung, etc.) mit
vielen Querbezügen in begleitende Tätigkeiten (Projektplanung,
Projektmanagement, Auslieferung, Wartung, etc.)
ƒ Softwarearchitekt als zentraler Vermittler und Koordinator
(oft auch „technischer Projektleiter“)
Softwarearchitektur – 1. Einleitung
1.30
Übersicht Kapitel 3: Grundlagen der
Softwarearchitektur
ƒ Teilweise sehr unterschiedliche Vorstellungen prägen die
heutige Begriffswelt im Bereich Softwarearchitektur
ƒ Wir definieren ein einfaches Architekturmodell
ƒ als kleinsten Nenner existierender, bewährter Technologien
ƒ in formaler Form für die präzise, eindeutige Festlegung von
Konzepten
ƒ als gemeinsames Verständnis der zugrunde liegenden Ideen und
damit für eine verbesserte Kommunikation
ƒ für die Beschreibung von Bedeutungen (z.B. von graphischen
Beschreibungstechniken, Programmsyntax, etc.)
Softwarearchitektur – 1. Einleitung
1.31
Übersicht Kapitel 4: Beschreibungstechniken
ƒ Um in der Lage zu sein, über Softwarearchitekturen zu
kommunizieren, zu diskutieren, diese zu bewerten und
zu vergleichen benötigt man Möglichkeiten,
Softwarearchitekturen in geeigneter Form zu
repräsentieren
ƒ Ältere „Architekturbeschreibungssprachen“ sind oftmals
sehr formal und daher umständlich
ƒ Neue Ansätze sind geeigneter:
ƒ IEEE 1471 standard on architecture representation
ƒ Unified Modeling Language
ƒ Wir verwenden in der Vorlesung die UML 2.0
Softwarearchitektur – 1. Einleitung
1.32
Übersicht Kapitel 5: Sichten
ƒ Eine Softwarearchitektur kann sich je nach Rolle des
Betrachters, Zeitpunkt im Entwicklungsprozess und
gewünschtem Fokus unterschiedlich darstellen
ƒ Diese „Sichten“ können beispielsweise wie folgt
klassifiziert werden:
ƒ
ƒ
ƒ
ƒ
Code View
Module View
Execution View
Conceptual View
ƒ Vgl. [HNS99]
aus [AC98]
Softwarearchitektur – 1. Einleitung
1.33
Übersicht Kapitel 6-Ende: Ausprägungen und
Wiederverwendung
ƒ Auf welche Weise lassen sich erfolgreiche
Softwarearchitekturen in neuen Projekten
wiederverwenden?
ƒ Sammlung, Katalogisierung und geeignete Präsentation
von Fragmenten oder vollständigen
Softwarearchitekturen, die sich in der Praxis bewährt
haben
ƒ
ƒ
ƒ
ƒ
Frameworks
Komponenten
Architekturmuster
Standards und Mechanismen
Softwarearchitektur – 1. Einleitung
1.34
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.35
Ziele der Vorlesung
ƒ Wer die Vorlesung (kontinuierlich) besucht
ƒ weiß, was Softwarearchitektur bedeutet
ƒ kennt die Kernprobleme sowie geeignete theoretische und
praktische Lösungsansätze
ƒ kann Softwarearchitekturen graphisch aber auch formal darstellen
ƒ kennt nicht nur wichtige Technologien sondern auch Prozesse
insbesondere innerhalb des Entwicklungsteams
ƒ kann anhand vorgestellter Beispiele und diskutierter Formen der
Wiederverwendung selbst Softwarearchitekturen entwickeln und
umsetzen
ƒ kennt das Handwerkzeug des Softwarearchitekten
ƒ steigert seinen/ihren „Marktwert“
Softwarearchitektur – 1. Einleitung
1.36
Zielgruppe der Vorlesung
ƒ Voraussetzung:
ƒ Grundstudium Informatik
ƒ Vorlesung Softwaretechnik oder Softwareengineering
ƒ Nützlich:
ƒ Erfahrungen bei der Programmierung größerer Systeme (nicht
nur mit der Technik – auch mit dem sozialen Gefüge eines
Teams)
ƒ Kenntnisse der UML
Softwarearchitektur – 1. Einleitung
1.37
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.38
Organisatorisches
ƒ Die Vorlesung ist prüfbar! (ECTS: 3)
ƒ Ort: MI 00.13.009A
ƒ Zeit: Montags von 14:00 – 16:00 Uhr
ƒ Website:
http://www4.in.tum.de/lehre/vorlesungen/sw_arch/WS0506/index.shtml
ƒ Mailverteiler: [email protected]
ƒ Büro: FMI 01.11.044 (Sekretariat Broy)
Softwarearchitektur – 1. Einleitung
1.39
Inhalt
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Motivation und Analogie zur Architektur
Der Begriff der Softwarearchitektur
Softwarearchitektur am Beispiel
Inhalte der Vorlesung
Zielgruppen
Organisatorisches
Zusammenfassung und Ausblick
Softwarearchitektur – 1. Einleitung
1.40
Zusammenfassung
ƒ Architektur und Softwarearchitektur zeigen viele
Parallelen: die richtige Kombination aus Ästhetik und
Funktionalität führt zum Erfolg
ƒ Die „Disziplin Softwarearchitektur“ trägt entscheidend zum
Gelingen eines Softwareprojekts bei
ƒ die Softwarearchitektur beschreibt, auf welche Weise die diversen
Anforderungen erfüllt werden und kann anhand wünschenswerter
Qualitätskriterien beurteilt werden
ƒ der Softwarearchitekt nimmt im Entwicklungsprozess eine zentrale
Rolle ein. Er behält den Überblick, vermittelt zwischen den
Beteiligten und gibt den Rahmen für die Implementierung vor.
ƒ Die Vorlesung behandelt sowohl Grundlagen als auch
weiterführende Konzepte
Softwarearchitektur – 1. Einleitung
1.41
Literaturhinweise
ƒ
ƒ
ƒ
ƒ
Martín Abadi, Luca Cardelli: A Theory of Objects –
Monographs in Computer Science, Springer Verlag 1998
[HNS99]
Christine Hofmeister, Robert Nord, Dilip Soni: Applied
Software Architecture, Addison Wesley – Object Technology Series, 1999
[Hus94]
Norbert Huse: Le Corbusier, Rowohlt Taschenbuch Verlag,
Sechste Auflage, 1994
[SG96]
Mary Shaw, David Garlan: Software Architecture.
Perspectives on an Emerging Discipline, Prentice Hall, 1996
[AC98]
Softwarearchitektur – 1. Einleitung
1.42