S o ftw a re a rc h ite kt u r

(1)

Vorlesung Wintersemester 2008 / 2009

Technische Universität MünchenInstitut für InformatikLehrstuhl von Prof. Dr. Manfred Broy

Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling

S o ftw a re a rc h ite kt u r

(Architektur:αρχή= Anfang, Ursprung +tectum= Haus, Dach)

1. Einleitung und Überblick

In h a lt

E in le itu n g

Motivation

Organisatorisches zur Vorlesung

S o ftw a re a rc h ite kt u r a ls D e sig n e rg e b n is

Die Rolle der Softwarearchitektur für das System

Beispiel

Begriffsdefinition

S o ftw a re a rc h ite kt u r a ls T ä tig ke it im P ro je kt

Die Rolle des Softwarearchitekten im Projekt

Architekturanalyse und –entwurf

Architekturmodelle

1.2Softwarearchitektur –1. Einleitung

(2)

P ro b le m st e llu n g

B e o b a ch tu n g e n :

Der Alltag ist immer stärker durchdrungen von Software

Software bestimmt immer mehr den Geschäftserfolg

Die Größe von Systemen wächst kontinuierlich(siehe beispielsweise Toll-Collect, FISCUS, etc.)

Unsere Fähigkeit, Softwaresysteme zu entwickelnwächst langsamer als der Bedarf (sog. „Software-Krise“)

Nur etwa 25% aller Entwicklungsprojekte verlaufenerfolgreich (hinsichtlich Zeit, Qualität, Kosten)

Bis zu ca. 80% der Gesamtkosten eines Softwaresystemsfallen nach Fertigstellung an

A n sa tz : S o ftw a re -E n g in e e rin g

Softwareentwicklung wird aufgefasst als Ingenieursdisziplin, mitMethoden, Techniken und Werkzeugen, die teilweise vontraditionellen 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, dieversteh-und handhabbar sind (-> Modul, Komponente)

Abstraktion: die für die aktuelle Zielsetzung irrelevanten Details werdenausgeblendet (-> Schnittstelle)

Wiederverwendung: die Situation wird mit verstandenen Problemenkorreliert, für die Lösungen bekannt sind

Softwarearchitektur ist eine Teildisziplin des Software-Engineerings,für die sich überraschend viele Analogien zur klassischenArchitektur finden lassen

(3)

A rc h ite kt u r- B e is p ie l: d a s M ü n ch n e r O ly m p ia g e lä n d e

G e w in n e r d e s d a m a lig e n Ar ch ite kt u rw e ttb e w e rb s: G . B e h n is ch

G e b a u t i n d e n J a h re n 1 9 6 6 -1 9 7 2

C h a ra kt e ris tis ch e s Z e ltd a ch , g e st ü tzt v o n 5 8 P ylo n e n

K o n zip ie rt a ls „ o ffe n e s Am p h ith e a te r“

U n te r D e n km a ls ch u tz se it 1 9 7 7

W ic h tig st e A n fo rd e ru n g e n

La n g le b ig ke it

Vielfältige Einsatzmöglichkeiten (7.400 Veranstaltungen seit ´72)

Dauerhaftigkeit der Strukturen

Geringe Wartungskosten (vgl. andere Städte!!!)

Ä st h e tik

Imagetransport, auch über Olympia hinaus

Unterstützung der Funktion

B e rü ck sic h tig u n g lo ka le r G e g e b e n h e ite n

Brachgelände mit angrenzendem Schuttberg

B a la n ce zw is ch e n Q u a lit ä t, Z e it u n d K o st e n

Begrenztes Budget

Hoher Zeitdruck

U n d v ie le m e h r… .

(4)

Le is tu n g d e r A rc h ite kt e n

S p e kt a ku lä re I n g e n ie u rs le is tu n g

Dachkonstruktion nicht „berechenbar“

Einfache Simulationsmodelle

E le g a n z, T ra n sp a re n z, L e ic h tig ke it

Organische Einbettung der Sportanlagen in die Umgebung

„B lic k ü b e r d e n T e lle rr a n d “

Konzeption eines dauerhaften Naherholungsgebiets

Vielfältige Einsatzmöglichkeiten (Studentenstadt, Konzerte undFußballspiele im Stadion, etc.)

D ie D is zip lin „ A rc h ite kt u r“

» Ar ch ite kt u r i st d ie K o m b in a tio n v o n u tili ta s , fir m ita s u n d ve n u st as .«

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

(5)

D ie D is zip lin „ A rc h ite kt u r“

» Ar ch ite kt u r i st d ie K o m b in a tio n v o n u tili ta s , fir m ita s u n d ve n u st as .«

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 (das Softwaresystem ist langlebig und„stabil“gegenüber Änderungen)

venustas: das Gebäude ist ästhetisch gestaltet(das Softwaresystem weist klare, logische Strukturenauf, die das Verständnis vereinfachen)

O rg a n is a to ris ch e s zu r V o rle su n g „ S o ftw a re a rc h ite kt u r“

O rt : M I H S 2

Z e it: M o n ta g s vo n 1 4 :0 0 – 1 6 :0 0 U h r

W e b sit e :

http://www4.in.tum.de/lehre/vorlesungen/sw_arch/WS0809/

M a ilv e rt e ile r:

savorles@in.tum.de

B ü ro : F M I 0 1 .1 1 .0 4 4 ( S e kr e ta ria t B ro y)

(6)

Ü b e rb lic k ü b e r d ie V o rle su n g

20.10.08: Einleitung und Überblick

27.10.08: Grundlagen der Softwarearchitektur

03.11.08: Beschreibungstechniken (1)

10.11.08: Beschreibungstechniken (2)

17.11.08: Sichten (1)

24.11.08: Sichten (2)

01.12.08: Ausprägungen (1)

08.12.08: Ausprägungen (2)

15.12.08: Betriebliche Informationssysteme (1)

12.01.08: Betriebliche Informationssysteme (2)

19.01.08: Eingebettete Systeme (1)

26.01.08: Eingebettete Systeme (2)

02.02.08: Eingeladener Industrievortrag

06.02.09: Anmeldetermin zur Prüfung

09.02.09: Prüfung

Z ie lg ru p p e d e r V o rle su n g

V o ra u ss e tzu n g :

Grundstudium Informatik

Vorlesung Softwaretechnik oder Softwareengineering

N ü tzl ic h :

Erfahrungen bei der Programmierung größerer Systeme (nicht nur mit der Technik –auch mit dem sozialen Gefüge eines Teams)

Kenntnisse der UML

(7)

In h a lt

E in le itu n g

Motivation

S o ftw a re a rc h ite kt u r a ls D e sig n e rg e b n is

Beispiel

Begriffsdefinition

S o ftw a re a rc h ite kt u r a ls T ä tig ke it im P ro je kt

Architekturmodelle

B e d e u tu n g d e r S o ftw a re a rc h ite kt u r

D ie Ar ch ite kt u r

ist Grundlage für das Verständnisüber das System im Projektteam

definiert die Entwicklungsprozesseim Team und beeinflusst somit dieEffizient im Projekt

D ie Q u a lit ä t d e r Ar ch ite kt u r

entscheidet über den Projekterfolg

entscheidet über die Qualität des Produkts

entscheidet über die Wartbarkeit und Erweiterbarkeit des Systems

(8)

B e is p ie l: A rc h ite kt u r e in e s Ü b e rs e tz e rs

1.15Softwarearchitektur –1. Einleitung Lexical Analyzer Lexical Analyzer Parser ParserGenerator Generator

foo.cfoo.outabstract syntax treetokens

Wer heutzutage einen Übersetzer programmiert, profitiert von einemetablierten Verständnis der einzelnen Bestandteile und ihrer jeweiligenAufgaben, Verantwortlichkeiten sowie Abhängigkeiten untereinander. Das realisierte System wird daher wohl ganz ähnlich zur obigenAbbildung aussehen…

K e rn p u n kt e d e r Ü b e rs e tz e ra rc h ite kt u r

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 erweitertwerden, beispielsweise um eine Station, die den abstraktenSyntaxbaum optimiert

Skalierbar

Im Rahmen einer verteilten Umgebung kann die Anwendung leicht parallelisiert und mehrere Stationen redundant ausgelegt werden

(9)

W e g e d e r W ie d e rv e rw e n d u n g d e r A rc h ite kt u r

Als „Referenz-Architektur“für den Bau von Übersetzern: Festlegungder einzelnen Systemteile, ihrer Verantwortung und des gemeinsamen Zusammenspiels. Erweiterungsmöglichkeiten werdenaufgezeigt.

Als „Architektur-Stil“: allgemeines Strukturprinzip, bekannt als„pipes-and-filter“-Architektur. Datenströme werden über „pipes“von einem „filter“zum nächsten transportiert und dortweiterverarbeitet. 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 Stellenangepasst werden.

(N o ch ) o ffe n e F ra g e n …

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 die Architektur am besten dokumentiert undkommuniziert (mit Kästchen und Pfeilen?)

Wie können besonders gute Eigenschaften der Übersetzerarchitektur auf andere Systeme übertragen werden?

Welche Bestandteile des Übersetzers kann man wiederverwendenfür die Realisierung weiterer Systeme? (Tatsächlich findet sich dieseArchitektur in vielen Übersetzern wieder.)

(10)

S o ftw a re a rc h ite kt u r a ls P ro ze ss u n d E rg e b n is

Eine Softwarearchitektur

unterteilt das Anwendungssystem in Bestandteile mit definiertenVerantwortlichkeiten 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

EineSoftwarearchitektur besteht aus einer Menge vonKomponenten und ihren Beziehungen untereinander.

Die Softwarearchitektur beeinflusst maßgeblich Entwicklungs-undWeiterentwicklungsprozesse.

DieDisziplin Softwarearchitekturwird als Teil des Software-Engineerings verstanden und definiert Methoden, Techniken undWerkzeuge zur effizienten Entwicklung qualitativ hochwertiger Softwarearchitekturen.

W a s is t e in e K o m p o n e n te ?

EineKomponente

ist ein Baustein des Systems

kapselt ihr Inneres und kommuniziert mit anderen Komponenten über präzise definierte Schnittstellen

kann, muss aber nicht tatsächlichen Modulen der Implementierungentsprechen. Insbesondere kann man auch Komponenten definieren, ohne in der Implementierung ein entsprechendes Konzept hierfür zuhaben.

Beispiele für Komponenten

Enterprise Java-Bean

Terminal mit Touchscreen und Treibersoftware

Alternative Definition

A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject tocomposition by third parties

1.20

(11)

W e ite re D e fin iti o n e n

Es existieren über 90 Definitionen des Begriffs „Softwarearchitektur“(siehehttp://www.sei.cmu.edu). Zwei prominente Beispiele:

„Architecture is defined [...] as thefundamental organizationof a system, embodied in its components, their relationshipsto each other and to the environment, and theprinciples governing its design and evolution.“(IEEE Std. No. 1471-2000)

„Thestructureof thecomponentsof a program/system their interrelationships, and principles andguidelines governingtheir design and evolutionover time.“(Garlan und Perry, 1995)

Ein Beispiel:wie kommt man zur Softwarearchitektur?

Ein gängiger Weg, um die Komponenten einer Architektur zuermitteln,besteht in der Betrachtung von Abhängigkeiten

2.22Softwarearchitektur–1. Einleitung

(12)

Komponenten „gruppieren“Elemente mit starker Abhängigkeit

2.23 ABC

Softwarearchitektur–1. Einleitung

Komponenten „gruppieren“Elemente mit starker Abhängigkeit

Abhängigkeiten zwischen Elementen werden zu Schnittstellen

Ist die Architektur einmal festgelegt, gibt sie Richtlinien vor für dieEinführung neuer Abhängigkeiten (hier: keine Verbindung zwischenden Komponenten A und C)

2.24 ABC ABC

Softwarearchitektur–1. Einleitung

(13)

In h a lt

E in le itu n g

Motivation

S o ftw a re a rc h ite kt u r a ls D e sig n e rg e b n is

Beispiel

Begriffsdefinition

S o ftw a re a rc h ite kt u r a ls T ä tig ke it im P ro je kt

Architekturmodelle

D ie R o lle d e s S o ftw a re a rc h ite kt e n ( n a ch V -M o d e ll X T )

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 zuanalysieren 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

(14)

S p a n n u n g sf e ld A rc h ite kt u re n tw u rf

1.27 Softwarearchitekt EndbenutzerKunde

Management

MethodikerEntwickler Administrator Marketing

mehr Funktionalität als die Konkur-renz, kurze Entwicklungsdauer,... hohe Effektivität, Auslastung, Wachstum,... einfacher Betrieb, einfache Wartung,... Funktionalität, Performanz,Stabilität, Sicherheit,... geringe Kosten, hoheQualität, Termintreue,...

Implementierungs-richtlinien, Design,... Einhaltung von Standards für Dokumentation, Vorgehen,...Organisation Einhaltung von Betriebs-vereinbarungen, Richtlinien,...

Softwarearchitektur –1. Einleitung

Z ie l d e s A rc h ite kt u re n tw u rfs

Eine Softwarearchitektur besteht aus einer Menge vonKomponenten und deren Beziehungen untereinander.

Ziel des Architekturentwurfs ist:

Den Bauplan des Systems zu erstellen, nach dem sich dann Erstellung, Wartung, Pflege und Weiterentwicklung ausrichten

Eine vollständige und prägnante Architekturbeschreibung erstellen

Dabei die geforderten funktionalen und nicht funktionalenAnforderungen gewährleisten

Die Architekturbeschreibung dient als

Kommunikations-und Diskussionsplattform

Design-und Implementierungsplan

1.28Softwarearchitektur –2. Ziele und Ergebnisse des Architekturentwurfs

(15)

A rc h ite kt u rb e sc h re ib u n g : K o m m u n ik a tio n s- u n d D is ku ss io n sp la ttf o rm

Ab st ra kt e B e sc h re ib u n g d e s S ys te m s

B e h e rr sc h b a rk e it d e r K o m p le xit ä t

Z u o rd n e n , P rio ris ie re n u n d R e fle kt ie re n v o n fu n kt io n a le n u n d n ic h t f u n kt io n a le n An fo rd e ru n g e n

In te g ra tio n v o n e xis tie re n d e n L ö su n g e n u n d S ys te m e n

Ab g le ic h m it d e n A n fo rd e ru n g e n a n S ys te m a rc h ite kt u r u n d H a rd w a re

E ra rb e ite n , E va lu ie re n u n d B e w e rt e n v o n a lte rn a tiv e n Lö su n g sa n sä tze n

1.29Softwarearchitektur –2. Ziele und Ergebnisse des Architekturentwurfs Softwarearchitekt EndbenutzerKunde

ManagementMarketing

Organisation Softwarearchitekt EndbenutzerEndbenutzerKundeKunde

ManagementManagementMarketingMarketing

OrganisationOrganisation

A rc h ite kt u rb e sc h re ib u n g : D e sig n - u n d I m p le m e n tie ru n g sp la n

F e st le g u n g d e r K o m p o n e n te n d e s S ys te m s so w ie d e re n S ch n itt st e lle n u n d In te ra kt io n sm u st e r

In te g ra tio n v o n n e u e n T e ch n o lo g ie n u n d in n o va tiv e n L ö su n g sa n sä tze n

E ra rb e itu n g , E in fü h ru n g , S ch u lu n g u n d Ü b e rp rü fu n g v o n P ro g ra m m ie rr ic h tli n ie n

E rs te llu n g v o n P ro to ty p e n u n d e xe m p la ris ch e n T e illö su n g e n

W ie d e rv e rw e n d u n g v o n e xis tie re n d e n Im p le m e n tie ru n g e n u n d T e ilim p le m e n tie ru n g e n

R a h m e n fü r d ie P ro je kt o rg a n is a tio n u n d - p la n u n g

1.30Softwarearchitektur –2. Ziele und Ergebnisse des Architekturentwurfs Softwarearchitekt

MethodikerEntwickler Administrator Softwarearchitekt MethodikerMethodikerEntwicklerEntwickler AdministratorAdministrator