Vorlesung W

intersem

ester 2008 / 2009

Technische U

niversität München

Institut für Inform

atik

Lehrstuhl von Prof. D

r. Manfred B

roy

Dr. K

laus Bergner, Prof. D

r. Manfred B

roy, Dr. M

arc Sihling

Softwarearchitektur

(Arch

itektur: αρχή

= Anfan

g, Urspru

ng +

tectum= Hau

s, Dach

)

1. Einleitung und Ü

berblick

Inhalt

�Ein

leitung

�Motivation

�Organisatorisches zur V

orlesung

�Softw

arearchitektu

r als Design

ergebnis

�Die R

olle der Softwarearchitektur für das System

�Beispiel

�Begriffsdefinition

�Softw

arearchitektu

r als Tätigkeit im

Projekt�

Die R

olle des Softwarearchitekten im

Projekt

�Architekturanalyse und –entw

urf

�Architekturm

odelle

1.2

Softw

arearch

itektu

r –1. E

inleitung

Problemstellung

�Beobach

tungen:

�Der A

lltag ist immer stärker durchdrungen von Softw

are

�Softw

are bestimmt im

mer m

ehr den Geschäftserfolg

�Die G

röße von Systemen w

ächst kontinuierlich (siehe beispielsw

eise Toll-C

ollect, FISCUS, etc.)

�Unsere Fähigkeit, Softw

aresysteme zu entw

ickelnwächst langsam

er als der Bedarf (sog. „Softw

are-Krise“)

�Nur etw

a 25% aller E

ntwicklungsprojekte verlaufen

erfolgreich (hinsichtlich Zeit, Qualität, K

osten)

�Bis zu ca. 80%

der Gesam

tkosten eines Softwaresystem

sfallen nach Fertigstellung an

1.3

Softw

arearch

itektu

r –1. E

inleitung

Ansatz: Softw

are-Engineering

�Softw

areentwicklung w

ird aufgefasst als Ingenieursdisziplin, mit

Methoden, T

echniken und Werkzeugen, die teilw

eise von traditionellen D

isziplinen (z.B. M

aschinenbau oder Architektur)

„abgeschaut“werden.

�Kom

plexität wird begegnet m

it dem Handw

erkszeug des Ingenieurs�

Teile u

nd H

errsche: ein

Problem w

ird in klein

ere Häppch

en zerlegt, die

versteh-un

d handh

abbar sind (->

Modu

l, Kom

ponen

te)

�Abstraktion

: die für die aktu

elle Zielsetzung irrelevan

ten Details w

erden

ausgeblen

det (-> Schn

ittstelle)

�Wiederverw

endu

ng: die Situ

ation w

ird mit verstan

denen

Problemen

korreliert, fü

r die Lösungen

bekannt sin

d

�Softw

arearchitektur ist eine Teildisziplin des Softw

are-Engineerings,

für die sich überraschend viele Analogien zur klassischen

Architektur finden lassen

1.4

Softw

arearch

itektu

r –1. E

inleitung

Architektur-B

eispiel: das Münchner O

lympiagelände

�Gew

inner des dam

aligen

Arch

itekturw

ettbewerbs:

G. B

ehnisch

�Gebau

t in den

Jahren 1966-1972

�Charakteristisch

es Zeltdach, gestü

tzt von 58 Pylon

en

�Kon

zipiert als „offenes

Amph

itheater“

�Unter D

enkm

alschutz

seit 1977

1.5

Softw

arearch

itektu

r –1. E

inleitung

Wichtigste A

nforderungen

�Lan

glebigkeit �

Vielfältige E

insatzmöglichkeiten (7.400 V

eranstaltungen seit ´72)

�Dauerhaftigkeit der Strukturen

�Geringe W

artungskosten (vgl. andere Städte!!!)

�Ästh

etik�

Imagetransport, auch über O

lympia hinaus

�Unterstützung der Funktion

�Berü

cksichtigun

g lokaler Gegebenh

eiten�

Brachgelände m

it angrenzendem Schuttberg

�Balan

ce zwisch

en Q

ualität, Zeit u

nd Kosten

�Begrenztes B

udget

�Hoher Zeitdruck

�Und viele m

ehr…

.1.6

Softw

arearch

itektu

r –1. E

inleitung

Leistung der Architekten

�Spektaku

läre Ingenieursleistu

ng

�Dachkonstruktion nicht „berechenbar“

�Einfache Sim

ulationsmodelle

�Elegan

z, Tran

sparenz, Leich

tigkeit�

Organische E

inbettung der Sportanlagen in die Umgebung

�„Blick ü

ber den Tellerran

d“�

Konzeption eines dauerhaften N

aherholungsgebiets

�Vielfältige E

insatzmöglichkeiten (Studentenstadt, K

onzerte und Fußballspiele im

Stadion, etc.)

1.7

Softw

arearch

itektu

r –1. E

inleitung

Die D

isziplin „Architektur“

»Arch

itektur ist die Kom

bination von utilitas, firm

itas und venustas.«

frei nach Vitru

vius (Röm

ischer Architekt 90-20 v. C

hr.)

�utilita

s: das G

ebäude erfüllt seine Funktion

�firm

itas: das G

ebäude ist stabil

�venusta

s: das G

ebäude ist ästhetisch gestaltet

1.8

Softw

arearch

itektu

r –1. E

inleitung

Die D

isziplin „Architektur“

»Arch

itektur ist die Kom

bination von utilitas, firm

itas und venustas.«

frei nach Vitru

vius (Röm

ischer Architekt 90-20 v. C

hr.)

�utilita

s: das G

ebäude erfüllt seine Funktion

(das Softwaresystem

erfüllt seine Anforderungen)

�firm

itas: das G

ebäude ist stabil (das Softw

aresystem ist langlebig und

„stabil“gegenüber Ä

nderungen)

�venusta

s: das G

ebäude ist ästhetisch gestaltet

(das Softwaresystem

weist klare, logische Stru

kturenauf, die das V

erständnis vereinfachen)

1.9

Softw

arearch

itektu

r –1. E

inleitung

Organisatorisches zur V

orlesung „Softwarearchitektur“

�Ort: M

I HS2

�Zeit: M

ontags von

14:00 –16:00 U

hr

�Website: h

ttp://www4.in

.tum.de/leh

re/vorlesungen/sw

_arch/WS0809/

�Mailverteiler: savorles@

in.tum.de

�Büro: FM

I 01.11.044 (Sekretariat Broy)

1.10

Softw

arearch

itektu

r –1. E

inleitung

Überblick über die V

orlesung

�20.10.08: E

inleitung und Überblick

�27.10.08: G

rundlagen der Softwarearchitektur

�03.11.08: B

eschreibungstechniken (1)�

10.11.08: Beschreibungstechniken (2)

�17.11.08: Sichten (1)

�24.11.08: Sichten (2)

�01.12.08: A

usprägungen (1)�

08.12.08: Ausprägungen (2)

�15.12.08: B

etriebliche Informationssystem

e (1)�

12.01.08: Betriebliche Inform

ationssysteme (2)

�19.01.08: E

ingebettete Systeme (1)

�26.01.08: E

ingebettete Systeme (2)

�02.02.08: E

ingeladener Industrievortrag

�06.02.09: A

nmeldeterm

in zur Prüfung�

09.02.09: Prüfung1.11

Softw

arearch

itektu

r –1. E

inleitung

Zielgruppe der Vorlesung

�Vorau

ssetzung:

�Grundstudium

Informatik

�Vorlesung Softw

aretechnik oder Softwareengineering

�Nützlich

:�

Erfahrungen bei der Program

mierung größerer System

e (nicht nur m

it der Technik –

auch mit dem

sozialen Gefüge eines

Team

s)

�Kenntnisse der U

ML

1.12

Softw

arearch

itektu

r –1. E

inleitung

Inhalt

�Ein

leitung

�Motivation

�Organisatorisches zur V

orlesung

�Softw

arearchitektu

r als Design

ergebnis

�Die R

olle der Softwarearchitektur für das System

�Beispiel

�Begriffsdefinition

�Softw

arearchitektu

r als Tätigkeit im

Projekt�

Die R

olle des Softwarearchitekten im

Projekt

�Architekturanalyse und –entw

urf

�Architekturm

odelle

1.13

Softw

arearch

itektu

r –1. E

inleitung

Bedeutung der Softw

arearchitektur

�Die A

rchitektu

r�

ist Grundlage für das V

erständnis über das System

im Projektteam

�definiert die E

ntwicklungsprozesse

im Team

und beeinflusst somit die

Effizient im

Projekt

�Die Q

ualität der A

rchitektu

r�

entscheidet über den Projekterfolg

�entscheidet über die Q

ualität des Produkts

�entscheidet über die W

artbarkeit und E

rweiterbarkeit des System

s

1.14

Softw

arearch

itektu

r –1. E

inleitung

Beispiel: A

rchitektur eines Übersetzers

1.15

Softw

arearch

itektu

r –1. E

inleitung

Lexical Analyzer

Lexical Analyzer

ParserParser

Generator

Generator

foo.cfoo.ou

tabstract syn

tax treetoken

s

Wer heutzutage einen Ü

bersetzer programmiert, profitiert von einem

etablierten V

erständnis der einzelnen Bestandteile und ihrer jew

eiligen Aufgaben, V

erantwortlichkeiten sow

ie Abhängigkeiten untereinander.

Das realisierte System

wird daher w

ohl ganz ähnlich zur obigen Abbildung aussehen…

Kernpunkte der Ü

bersetzerarchitektur

�Einfach und verständlich�

ein „D

atenstrom

“du

rchläu

ft verschieden

e „Stationen

“mit klar

definierten

Eingabe-

und A

usgabeformaten

�Fu

nktionsprin

zip kann schn

ell verstanden

und kommuniziert w

erden

�Effizient realisierbar�

Zerlegung erlau

bt die parallele Entw

icklung in

meh

reren Team

s

�Betriebssystem

e wie U

nix verein

fachen

die Implem

entieru

ng

�Langlebig�

Das System

kann seh

r einfach u

m neu

e Funktion

alität erweitert

werden

, beispielsw

eise um ein

e Station, die den

abstrakten

Syntaxbau

m optim

iert

�Skalierbar�

Im Rah

men

einer verteilten Umgebu

ng kan

n die Anwen

dung leicht

parallelisiert und m

ehrere Station

en redu

ndan

t ausgelegt werden

1.16

Softw

arearch

itektu

r –1. E

inleitung

Wege der W

iederverwendung der A

rchitektur

�Als „R

eferenz-Architektur“

für den Bau von Ü

bersetzern: Festlegung der einzelnen System

teile, ihrer Verantw

ortung und des gem

einsamen Zusam

menspiels. E

rweiterungsm

öglichkeiten werden

aufgezeigt.

�Als „A

rchitektur-Stil“: allgemeines Strukturprinzip, bekannt als

„pipes-and-filter“-Architektur. D

atenströme w

erden über „pipes“von einem

„filter“zum

nächsten transportiert und dort weiterverarbeitet. D

as funktioniert nur bei Anw

endungen mit

�sequ

entialisierbaren

Bearb

eitungssch

ritten

�Abh

ängigkeiten

nur zw

ischen

benach

barten Bearb

eitungssch

ritten

�Als „Fram

ework“: für die R

ealisierung eines Übersetzers m

uss diese „halbfertige Im

plementierung“

nur noch an wenigen Stellen

angepasst werden.

1.17

Softw

arearch

itektu

r –1. E

inleitung

(Noch) offene Fragen…

�Erfüllt die A

rchitektur die Anforderungen an das System

?

�Existieren bessere A

rchitekturen für den Übersetzerbau?

�Wie ist der Zusam

menhang zw

ischen bestimmten M

erkmalen einer

Architektur u

nd bestimmten A

nforderungen?

�Auf w

elche Weise w

ird die Architektur am

besten dokumentiert und

kommuniziert (m

it Kästchen und Pfeilen?)

�Wie können besonders gute E

igenschaften der Übersetzerarchitektur auf andere System

e übertragen w

erden?

�Welche B

estandteile des Übersetzers kann m

an wiederverw

enden für die R

ealisierung weiterer System

e? (Tatsächlich findet sich diese

Architektur in

vielen Übersetzern w

ieder.)

1.18

Softw

arearch

itektu

r –1. E

inleitung

Softwarearch

itektur als Prozess u

nd Ergebn

is

�Eine Softw

arearchitektur

�unterteilt das A

nwendungssystem

in Bestandteile m

it definierten Verantw

ortlichkeiten und einem festgelegten Zusam

menspiel

�erm

öglicht die Beurteilung der Q

ualität des Gesam

tsystems

anhand der Qualitäten der E

inzelteile

�definiert Schnittstellen für zukünftige E

rweiterungen

�Eine S

oftw

are

arch

itektu

r besteht aus einer Menge von

Kom

ponenten und ihren Beziehungen untereinander.

�Die Softw

arearchitektur beeinflusst maßgeblich E

ntwicklungs-

und Weiterentw

icklungsprozesse.

�Die D

isziplin

Softw

are

arch

itektu

rwird als T

eil des Software-

Engineerings verstanden und definiert M

ethoden, Techniken und

Werkzeuge zur effizienten E

ntwicklung qualitativ hochw

ertiger Softw

arearchitekturen.

1.19

Softw

arearch

itektu

r –1. E

inleitung

Was ist eine K

omponente?

�Eine K

om

ponente

�ist ein

Bau

stein des Systems

�kapselt ih

r Inneres u

nd kom

muniziert m

it anderen

Kom

ponen

ten über

präzise definierte Sch

nittstellen

�kan

n, m

uss aber n

icht tatsäch

lichen

Modu

len der Im

plemen

tierung

entsprech

en. In

sbesondere kan

n m

an auch

Kom

ponen

ten definieren

, oh

ne in

der Implem

entieru

ng ein

entsprech

endes K

onzept hierfü

r zu

haben

.

�Beispiele für K

ompon

enten�

Enterprise Java-B

ean

�Term

inal m

it Tou

chscreen und T

reibersoftware

�Alternative D

efinition�

A softw

are compon

ent is a un

it of composition

with

contractu

allyspecified in

terfaces and explicit con

text dependen

cies only.

A softw

are compon

ent can be deployed in

depen

dently an

d is subject to

composition

by third parties

1.20

Weitere D

efinitionen

Es existieren über 90 D

efinitionen des Begriffs „Softw

arearchitektur“(siehe http://w

ww.sei.cm

u.edu). Zwei prom

inente Beispiele:

�„Architecture is defined [...] as the fu

ndam

enta

l org

aniza

tionof a system

, embodied in its co

mponents, their

relatio

nsh

ipsto each other and to the environm

ent, and the prin

ciples g

overn

ing its d

esig

n and evolu

tion.“

(IEEE Std. N

o. 1471-2000)

�„The stru

cture

of the com

ponents

of a program/system

their in

terre

latio

nsh

ips, and principles and g

uid

elin

es g

overn

ing

their d

esig

n and evolu

tionover tim

e.“(G

arlan und Perry, 1995)

1.21

Softw

arearch

itektu

r –1. E

inleitung

Ein B

eispiel:wie kom

mt m

an zur Softw

arearchitektur?

�Ein gängiger W

eg, um die K

omponenten einer A

rchitektur zu erm

itteln,besteht in der B

etrachtung von Abhängigkeiten

2.22

Softw

arearch

itektu

r–1. E

inleitung

Ein B

eispiel:wie kom

mt m

an zur Softw

arearchitektur?

�Ein gängiger W

eg, um die K

omponenten einer A

rchitektur zu erm

itteln,besteht in der B

etrachtung von Abhängigkeiten

�Kom

ponenten „gruppieren“Elem

ente mit starker A

bhängigkeit

2.23

ABC

Softw

arearch

itektu

r–1. E

inleitung

Ein B

eispiel:wie kom

mt m

an zur Softw

arearchitektur?

�Ein gängiger W

eg, um die K

omponenten einer A

rchitektur zu erm

itteln,besteht in der B

etrachtung von Abhängigkeiten

�Kom

ponenten „gruppieren“Elem

ente mit starker A

bhängigkeit

�Abhängigkeiten zw

ischen Elem

enten werden zu Schnittstellen

�Ist die A

rchitektur einmal festgelegt, gibt sie R

ichtlinien vor für die Einführung neuer A

bhängigkeiten (hier: keine Verbindung zw

ischen den K

omponenten A

und C)

2.24

ABC

ABC

Softw

arearch

itektu

r–1. E

inleitung

Inhalt

�Ein

leitung

�Motivation

�Organisatorisches zur V

orlesung

�Softw

arearchitektu

r als Design

ergebnis

�Die R

olle der Softwarearchitektur für das System

�Beispiel

�Begriffsdefinition

�Softw

arearchitektu

r als Tätigkeit im

Projekt�

Die R

olle des Softwarearchitekten im

Projekt

�Architekturanalyse und –entw

urf

�Architekturm

odelle

1.25

Softw

arearch

itektu

r –1. E

inleitung

Die R

olle des Softwarearchitekten (nach V

-Modell X

T)

�Aufgaben

und B

efugn

isse�

Entw

urf der System-bzw

. Softwarearchitektur

�Umsetzung der A

nforderungen an die Kom

ponen

ten�

Verantw

ortlichkeit für Implem

entierungs-, Integrations-und Prüfkonzept

�Fäh

igkeitsprofil�

Kennt A

nwendung, R

ahmenbedingungen und E

insatzgebiete des System

s�

Kennt die Schnittstellen des System

s�

Kennt A

rchitekturprinzipien und verschiedene SW

-Architekturen

�Kennt Standard-Softw

are, COTS, M

OTS, etc.

�Kennt M

ethoden und W

erkzeuge �

Hat Fähigkeit, Schw

achstellen und Risiken zu erkennen

�Hat Fähigkeit, Problem

e unter adäquater B

erücksichtigung der SW/H

W zu

analysieren und entsprechende Lösungsvorschläg

e auszuarbeiten�

Hat Fähigkeit, zu

abstrahieren und zu vereinfachen�

Hat Fähigkeit, A

bhängigkeiten zu erkennen�

Hat K

ommunikationsfähig

keit mit A

nwendern und T

eam

1.26

Softw

arearch

itektu

r –1. E

inleitung

Spannungsfeld Architekturentw

urf

1.27

Softwarearchitekt

Endbenutze

rKunde

Management

Methodike

rEntwickle

r

Administra

tor

Marke

tingmehr F

unktio

nalitä

t als d

ie Konkur-

renz, ku

rze Entwicklu

ngsdauer,...

hohe Effe

ktivität,

Ausla

stung, W

achstu

m,...

einfacher B

etrie

b,

einfache W

artu

ng,...

Funktio

nalitä

t, Perfo

rmanz,

Stabilitä

t, Sich

erheit,...

geringe Koste

n, hohe

Qualitä

t, Term

intre

ue,...

Implementierungs-

richtlin

ien, D

esig

n,...

Einhaltung vo

n Standards fü

r Dokumentation, V

orgehen,...

Organisa

tion

Einhaltung vo

n Betrie

bs-

vereinbarungen, R

ichtlin

ien,...

Softw

arearch

itektu

r –1. E

inleitung

Ziel des Architekturentw

urfs

�Eine Softw

arearchitektur besteht aus einer Menge von

Kom

ponenten und deren Beziehungen untereinander.

�Ziel des A

rchitekturentwurfs ist:

�Den

Bau

plan des System

s zu erstellen

, nach

dem sich dan

n Erstellung,

Wartu

ng, Pfleg

e und W

eiterentw

icklung au

srichten

�Ein

e vollständige u

nd prägn

ante A

rchitektu

rbeschreibu

ng erstellen

�Dabei d

ie geforderten fu

nktionalen

und n

icht fu

nktion

alen

Anforderu

ngen gew

ährleisten

�Die A

rchitekturbeschreibung dient als

�Kom

munikation

s-und D

iskussion

splattform

�Design

-und Im

plemen

tierungsplan

1.28

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

Architekturbeschreibung:

Kom

munikations-

und Diskussionsplattform

�Abstrakte B

eschreibu

ng des System

s

�Beh

errschbarkeit der K

omplexität

�Zuordn

en, Priorisieren und R

eflektieren von fu

nktion

alen und n

icht fu

nktion

alen Anforderun

gen

�Integration von

existierenden Lösu

ngen und System

en

�Abgleich

mit den

Anforderun

gen an

Systemarch

itektur

und H

ardware

�Erarbeiten

, Evaluieren un

d Bew

erten von altern

ativen Lösu

ngsansätzen

1.29

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

Softw

arearchitekt

Endbenutze

rKunde

Management

Marke

ting

Organisa

tion

Softw

arearchitekt

Endbenutze

rEndbenutze

rKunde

Kunde

Management

Management

Marke

ting

Marke

ting

Organisa

tion

Organisa

tion

Architekturbeschreibung:

Design-

und Implem

entierungsplan

�Festlegu

ng der Kom

ponen

ten des System

s sow

ie deren Sch

nittstellen

und

Interaktionsm

uster

�Integration von

neu

en Tech

nologien

und in

novativen Lösungsan

sätzen

�Erarbeitun

g, Einführung, Sch

ulung u

nd Überprüfun

g von

Programmierrich

tlinien

�Erstellu

ng von Prototypen

und exem

plarischen

Teillösun

gen

�Wiederverw

endu

ng von existierenden

Implem

entierungen

und Teilim

plemen

tierungen

�Rah

men für die Projektorgan

isation und -plan

ung

1.30

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

Softw

arearchitekt

Methodiker

Entwick

ler

Administra

tor

Softw

arearchitekt

Methodiker

Methodiker

Entwick

ler

Entwick

ler

Administra

tor

Administra

tor

Architekturm

odellierung

.31

File

- FileN

ame : S

tring

P

- X : int

- Y : int F

o

- Nam

e : String

- Style : int

- Size : int

Di

- Heig

ht : int- W

idth : intLine

+$ S

TRAIGHT : LineS

tyle+$ S

NAPPED : LineS

tyle+$ S

LANTED : LineS

tyle+$ LO

OP : LineS

tyle

<<Enum

>>

Autom

a

+$ IM

PLE

MENTATION : A

utomatonK

ind+$ C

LASSSPEC : A

utomatonK

ind+$ T

YPESPEC : A

utomatonK

ind

<<Enum

>>

Dire

+$ IN

: Direction

+$ O

UT : D

irection

<<Enum

>>

Tran

- Nam

e : String

- Input : String

- Output : S

tring- P

reCondition : S

tring- P

ostCondition : S

tring- A

ction : String

- IsOuter : boolean

- ControlP

ointOne : P

oint- C

ontrolPointT

wo : P

oint

Par

- Nam

e : String

Rep

S

Inte

- Nam

e : String

- Condition : S

tring- D

irection : int- Location : P

oint

* 1

+OutS

egment*

+SourceP

oint 1

* 1+InS

egment

* +DestinationP

oint1

Com

- Nam

e : String

- OEFStream

: String

- OEFAnnotation : S

tring

* 1* 1

Re

- Nam

e : String

11

11

Proj

Chan

- Nam

e : String

- Type : S

tring- D

isplayFont : F

ont- D

rawType : int

- TextB

oxSize : D

imension

- TextB

oxLocation : Point

Stat

- Nam

e : String

- Predicate : S

tring- E

ntryAction : S

tring- E

xitAction : S

tring- IsH

istory : boolean- IsInitial : boolean- Location : P

oint- S

ize : Dimension

- Border : int

0..1*

0..1*

1* 1*

Proj

- Nam

e : String

- OEFStream

: String

* 1* 1 1* 1*

0..1

*

+SuperP

roject

0..1

+SubP

roject

*

11

11

S

Attr

- Nam

e : String

- Type : S

tring

Port

- Nam

e : String

- Direction : D

irection = -1

- Type : S

tring- Location : P

oint# D

isplayFont : F

ont- S

howNam

e : boolean

0..1 1

+OutC

hannel

0..1

+SourceP

ort

1

0..1

1

+InC

hannel

0..1

+DestinationP

ort

1

Co

- Nam

e : String

1

*

1

*

Auto

- Nam

e : String

- Kind : int

- ClassN

ame : S

tring

0..1* 0..1*

1

*

1

*

Com

- Nam

e : String

- Location : Point

- Size : D

imension

- Border : int

- DisplayF

ont : Font

- TextB

oxLocation : Point

- TextB

oxSize : D

imension

0..1*

0..1*

1*

+SuperC

omponent

1

+SubC

omponent *

1

*

1

*

1* 1*

0..1

1

0..1

1

0..1

0..1

0..1

0..1

Te

- Line : String

11..*11..*

top-downbottom-up

fachlich

technisch

Arch

itektu

rmodell

Wiederve

rwendung

Applika

tionsse

rver,

Datenbanken,

Transaktio

nsm

onitore

existie

rende

Komponenten &

Syste

me

fachlich

eAnforderungen

Syste

march

itektu

r, Hardware

Arch

itektu

ranalyse

Softw

arearch

itektu

r –1. E

inleitung

Eingangsprodukte des E

ntwurfs: A

nforderungen

�Anforderungskategorien

�Funktionale A

nforderungen: Verw

altung von Kunden,

Verw

altung von Verträgen, etc.

�Nicht funktionale A

nforderungen-

Qualitätsan

forderungen

(IEEE 1061): Ben

utzbarkeit, Stabilität,

Wartbarkeit, Erw

eiterbarkeit, Performan

z, etc.

-Ran

dbedingu

ngen-

System / Produ

kt: Vorgaben zur V

erteilung, physikalische Anforderungen, U

mweltanforderu

ngen, Materialanforderungen, etc.

-Technologie: V

orgaben zur Hardw

are, Vorgaben zur Softw

are, Vorgaben zu Standardtechnologie, etc.

-Prozess: V

orgaben zum Vorgehen

smodell, A

nforderungen bzgl. Einführung und M

igration, etc.

-Organisation / M

anagement: V

orgaben bzgl. Zeit und B

udget, Vorgaben bzgl. Personal, V

orgaben bzgl. Ressourcen

1.32

Softw

arearch

itektu

r –1. E

inleitung

Ergebnisprodukte der A

rchitekturanalyse

�Besch

reibung der A

rchitektu

ranforderungen

�Identifizieren, E

inordnen und Beschreiben der A

nforderungen

�Charakterisierung der A

nforderungen bzgl. Flexibilität und Änderbarkeit

�Ausw

irkungsanalyse von Anforderungsänderungen

�Besch

reibung der A

rchitektu

rtreiber �

Identifizieren der zentralen Architekturtreiber und Zuordnen der

Anforderungen

�Entw

icklung von (alternativen) (Teil-) Lösungen und Strategien

bzw. Strategiebausteinen

�Identifizieren von Strategien und Lösungen, die in B

eziehung stehen

1.33

Softw

arearch

itektu

r –1. E

inleitung

Beschreibung der A

nforderungen

<Name der Anforderung>

Kategorie:

<Kategorie der A

nforderung: fu

nktio

nale Anforderung, nich

t funktio

nale Anforderung (Q

ualitä

tsanforderung), R

ahmen-

bedingung Syste

m/Produkt, u

sw.; G

egenebenenfalls V

erweis

auf das A

nforderungsanalyse

-bzw

. Domänenanalyse

-dokument>

Beschreibung:

<Kurze

Besch

reibung der A

nforderung>

Prioritä

t:<muss | so

ll | kann>

Flexibilitä

t und

Änderbarkeit:

<Besch

reibung der F

lexib

ilität der A

nforderung, d

.h. in

wie weit

akze

ptiert d

er A

nforderungsträ

ger, d

ass d

iese Anforderung

verändert w

erden.

Besch

reibung der Ä

nderbarke

it der A

nforderung, d

.h. in

wie

weit sin

d Änderungen dieser A

nforderung durch

den

Anforderungsträ

ger a

bzusehen.>

Auswirkungen:

<Ausw

irkungen auf andere Anforderungen und auf die

Arch

itektu

r bzw

. auf T

eile der A

rchitektu

r bei Ä

nderungen

dieser A

nforderung>

1.34

Softw

arearch

itektu

r –1. E

inleitung

Beschreibung der A

rchitekturtreiber

<Name des Architekturtre

ibers>

Beschreibung:

<Kurze

Besch

reibung des A

rchitektu

rtreibers>

Anforderungen:

<Liste

der A

nforderungen, d

ie der A

rchitektu

rtreiber

adressie

rt.>

1. Testszenario:

<Besch

reibung eines A

nwendungssze

narios u

m eine ko

rrekte

Realisie

rung des A

rchitektu

rtreibers zu

überprüfen.>

N. Testszenario:

<dito>

Lösung:

<Kurze

Lösungsbesch

reibung>

1. Strategiebaustein:

<Besch

reibung eines S

trategiebauste

ins. M

ehrere

Stra

tegiebauste

ine kö

nnen so

wohl alternativ a

ls auch

kombiniert ve

rwendet w

erden.>

N. Strategiebaustein:

<dito>

Verwandte Strategien:

<Liste

anderer A

rchitektu

rtreiber b

zw. S

trategiebauste

inen, d

ie

in Bezug zu

diesem Arch

itektu

rtreiber ste

hen>

1.35

Softw

arearch

itektu

r –1. E

inleitung

Anw

endungsbeispiel: eVersicherung 2000

�Neu

es Inform

ationssystem

„eVersich

erung 2000“

der „Versich

erungs A

G“

�Produ

kte der Versich

erungs A

G�

Lebensversicherungen

�Rentenversicherungen

�Unfallversicherungen

�Fu

nktion

alität der eVersich

erung 2000

�Versicherungsangebote verw

alten

�Versicherungsverträge verw

alten

�Versicherungspolicen verw

alten

�Anwen

der des Systems sin

d Endkunden, M

akler und

Mitarbeiter der V

ersicheru

ngs AG

1.36

Softw

arearch

itektu

r –1. E

inleitung

Beispiel einer A

rchitekturanforderungsbeschreibung

A1: Verwaltung von Kundendaten

Kategorie:

funktio

nale Anforderung

Beschreibung:

Das S

ystem erm

öglich

t Benutze

rn Kunden zu

erze

ugen, deren

Daten (N

ame, A

dresse

, etc.) zu

bearbeiten, zu

suchen und zu

lösch

en.

Prioritä

t:muss

Flexibilitä

t und

Änderbarkeit:

Exte

rne Kundendatenbanken müsse

n in zu

künftig

en

Versio

nen des S

ystems e

ingebunden werden kö

nnen.

Auswirkungen:

Die nachträ

glich

e Integration exte

rner K

undendatenbanken

kann große Ausw

irkungen auf d

ie Arch

itektu

r und so

mit a

uch

auf das S

ystem so

wie die damit ve

rbundenen

Entwicklu

ngssa

ufwände haben.

1.37

A2: Verwaltung von Vertra

gsdaten

Kategorie:

funktio

nale Anforderung

.....

Softw

arearch

itektu

r –1. E

inleitung

Beispiel einer A

rchitekturanforderungsbeschreibung

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

1.38

A3: Gleichzeitiges Arbeiten mehrer Benutzer

Kategorie:

Qualitä

tsanforderung

A4: Internet-basiertes System mit grafischer Oberfläche

Kategorie:

Qualitä

tsanforderung

A5: Benutzer haben Zugriff a

uf aktuelle Daten

Kategorie:

Qualitä

tsanforderung

A6: Time-to-market ist zw

ei Jahre

Kategorie:

Rahmenbedingung Syste

m/Produkt

A7: Anforderungen sind priorisiert

Kategorie:

Rahmenbedingung Prozess

A8: Release-Zyklus wichtiger als Funktionalität

Kategorie:

Rahmenbedingung Management

.....

Beispiel einer A

rchitekturtreiberbeschreibung

Aktuelle, konsistente, mehrbenutzerfähige Datenbearbeitung

Beschreibung:

Mehrere Benutze

r müsse

n gleich

zeitig

mit d

em Syste

m die

Daten bearbeiten und auf a

ktuelle und ko

nsiste

nte Daten

zugreifen kö

nnen. A

uf D

atenänderungen anderer B

enutze

r muss e

in möglich

st zeitnaher Z

ugriff m

öglich

sein.

Anforderungen:

A1, A

2, A

3, A

4, A

5, A

6, A

8,

1. Testszenario:

Das S

ystem ste

llt dem Benutze

r eine Kundenliste

zur

Verfü

gung. D

er B

enutze

r wählt e

inen Kunden zu

r Bearbeitung

aus u

nd ändert d

en Namen des K

unden. M

it der B

estä

tigung

der N

amensänderung, ä

ndert sich

auch der N

ame in der

dargeste

llten Kundenliste

.

2. Testszenario:

Benutze

r A bearbeitet die Daten eines K

unden. E

in anderer

Benutze

r B erm

ittelt g

leich

zeitig

ein Liste

mit K

unden deren

Versich

erungsvo

lumen ein bestim

mtes L

imit ü

bertrifft. In

dieser

Kundenliste

taucht auch der ve

ränderte

Name des K

unden auf,

der g

erade vo

n Benutze

r A bearbeitet w

urde.

Lösung:

????

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

1.39

Beispiel einer A

rchitekturtreiberbeschreibung

Lösung:

Kombination vo

n Model/V

iew/Contro

ller M

uste

r und

Transaktio

nsm

echanism

us. Z

uerst e

ine Kombination aus d

em

1. und dem 6. S

trategiebauste

in. D

ann vo

n dem 1. zu

m 2. und

später zu

m 3. S

trategiebauste

in erweitern, entsp

rechend dem

Arch

itektu

rtreiber „K

urze

Entwicklu

ngszykle

n“.

1. Strategiebaustein:

Benutze

r kann die Aktu

alisie

rung der D

aten auf K

nopfdruck

aktivie

ren.

2. Strategiebaustein:

In bestim

mten Zeitin

terva

llen werden die angezeigten Daten

aktu

alisie

rt.

3. Strategiebaustein:

Nach einer D

atenänderung werden die Daten anderer

Benutze

r automatisch

aktu

alisie

rt.

4. Strategiebaustein:

Eine Transaktio

n pro Benutze

r

5. Strategiebaustein:

Eine Transaktio

n pro Dialog / F

enste

r

6. Strategiebaustein:

Eine Transaktio

n pro Anwendungsfa

ll

Verwandte

Strategien:

Arch

itektu

rtreiber: K

urze

Entwicklu

ngszykle

n; 1. S

trategie:

Einfaches, in

krementelles H

inzufügen vo

n Funktio

nalitä

t

1.40

Softw

arearch

itektu

r –1. E

inleitung

Ergebnistyp der A

rchitekturmodellierung:

Architekturbeschreibung bzw

. Architekturspezifikation

�Ein

e Arch

itekturbesch

reibung bzw

. Arch

itektur-

spezifikation besch

reibt ein Arch

itekturm

odell (meist in

Form

eines Softw

arearchitektu

rdokumentes)

�Ein

Softwarearch

itekturdokumen

t sollte enthalten:

�En

twurfsziele, R

ichtlin

ien und M

uster der A

rchitektur

�Abstrakte, grafisch

e Besch

reibungen

mit versch

iedenen

Sichten�

Zusätzlich

er, erklärender T

ext�

Entw

urfsen

tscheidungen

und A

lternativlösu

ngen�

Funktion

ale und nich

t funktion

ale Testfälle

�Erw

eiterungsm

öglichkeiten

�Ein

Softwarearch

itekturdokumen

t sollte so einfach

wie

möglich

sein, aber so u

mfan

greich w

ie notwen

dig.�

“You

know you

've achieved perfection in design, not

when

you have noth

ing m

ore to add, but w

hen

you

have noth

ing m

ore to take away.”

[nach Antoine de Saint-Exupery]

1.41

Softw

arearch

itektu

r –1. E

inleitung

Techniken für den A

rchitekturentwurf

�Ziel des A

rchitektu

rentwurfs

�Kom

ponenten identifizieren

�Schnittstellen der K

omponenten beschreiben

�Kom

position der Kom

ponenten beschreiben

�Tech

niken

�Anw

endung von Heuristiken zur K

omponentenidentifikation

-Hau

ptwörter in

Anforderun

gen w

erden zu

Entitäten

und Verben

werden

zu Aktivitäten

-Bündelu

ng von A

ktivitäten und En

titäten in

Kom

ponenten

�Von Szenarien zu vollständigen M

odellen-

Von

UML-Sequen

zdiagrammen

zu UML K

lassendiagram

men

-Class R

esponsibilities C

ollaborations W

orkshop, C

RC-Karten

�Wiederverw

endung von bewährten A

rchitekturen (Architekturstile, Fram

eworks, etc.)

1.42

Softw

arearch

itektu

r –1. E

inleitung

Erfolgsfaktoren des A

rchitekturentwurfs

�In m

inim

alen Sch

nittstellen

und K

ompon

enten den

ken

�Syn

tax und V

erhalten

von Schnittstellen

und

Kom

ponenten

beschreiben

�Kom

position der K

ompon

enten

zu ein

er Arch

itektur

getrennt besch

reiben

�Modu

larität

�Lose K

opplung

�Abh

ängigkeiten

sichtbar m

achen

�Zu

erst fachlich

e Sichten

, dann tech

nisch

e

�Geeign

ete Kom

bination

von bottom-up u

nd top-down

1.43

Softw

arearch

itektu

r –1. E

inleitung

1-44

Architekturdokum

ente nach V-M

odell XT

�Die zen

tralen Produ

kte der Systemerstellu

ng, der H

W-und SW

-Entw

icklung

haben

eine einh

eitliche T

hem

enstru

ktur.

�…

legen rich

tungsw

eisende A

rchitektu

rprinzipien

fest

�…

untersu

chen m

ögliche En

twurfsaltern

ativen

�…

beschreiben

die Zerlegung in

Kom

ponen

ten

�…

identifizieren

Schnittstellen

und B

eziehungen

zwisch

en Kom

ponen

ten und

zur U

mgebun

g des Systems

�(U

nte

rstützu

ngs-) S

yste

m-/ H

W-/ S

W-A

rchite

ktu

r�

Arch

itektu

rprin

zipien u

nd E

ntw

urfsa

ltern

ativ

en

�Dekom

positio

n d

es (U

nte

rstützu

ngs-) S

yste

ms /

der H

W-/ S

W-E

inheit

�Quersch

nittlich

e S

yste

meig

ensch

afte

n (nur bei (U

nterstützun

gs-) System

)

�Sch

nittste

llenübersich

t

�(Ü

berg

reife

nder) D

ate

nkata

log

�Desig

nabsich

eru

ng

�Zu sp

ezifizie

rende S

yste

m-/ H

W-/ S

W-E

lem

ente

Designabsicherung

�Ziel: Zeigen

, dass die Arch

itektur die A

nforderungen

erfü

llt. Eventuell darüber h

inau

s Altern

ativen bew

erten�

Modellgetrieben

e Validierun

g und Verifikation

�exem

plarische „Ausführung“

der Modelle

�Modelchecking

�Bew

eisen bestimmter E

igenschaften (Theorem

beweiser)

�Prototyping�

experimentelle Prototypen

�explorative Prototypen

�evolutionäre Prototypen

�Tests�

funktionale Tests

�Lasttests

�Perform

ance-Tests

�Messu

ngen m

it Metriken

(siehe [G

il02])1.45

Softw

arearch

itektu

r –1. E

inleitung

Der A

rchitekt als Programmierer

�Evalu

ierung von En

twurfsaltern

ativen m

it Hilfe von

experim

entellen

Prototypen

�Ein

führung un

d Verbreitu

ng der Softwarearch

itektur im

En

twicklerteam

durch

evolutionären

Prototypen

�Evalu

ierung u

nd Einführun

g von neu

en innovativen

Tech

nologien

und Konzepten

�Mitarbeit im

Entw

icklerteam als Program

mierer u

. Tester

�Train

er und B

erater des Entw

icklungsteam

s

�Koordin

ation und M

oderation der Schnittstellen

-festlegun

g wäh

rend Fein

design un

d Implem

entierun

g

�Initiieru

ng und Etablieru

ng des Dialogs zw

ischen

den En

twicklern

im Team

2.46

Softw

arearch

itektu

r –2. Z

iele und Ergebnisse

des A

rchitektu

rentwurfs

Der A

rchitekt als Analyst

�Maßgeblich

e inhaltliche G

estaltung der System

vision: Festlegu

ng der übergreifen

den Ziele, A

nforderu

ngen und

Rah

menbedingungen

des Systems u

nd Arch

itektur

�Abstim

mung der System

anforderu

ngen durch

explorative Prototypen

�Wirku

ngsanalyse, A

bstimmung un

d Review

von Anforderungen

an das System

�Integration von

technisch

en und konzeptionellen

Innovationen

in die gem

einsam

e Systemvision

�Verbreitu

ng und A

kzeptanz der Systemvision

unter allen

Beteiligten

: Endbenu

tzer, Kunde, En

twicklu

ngsteam

, etc.1.47

Der A

rchitekt als technischer Projektleiter (1)

�En

tscheidun

gskompeten

z für alle w

esentlich

en En

twurfs-

entsch

eidungen u

nd Verän

derungen

: Entscheidun

gen so

spät wie m

öglich und so frü

h wie nötig treffen

!�

Ausw

ahl u

nd Beu

rteilung der techn

ischen

Fähigkeiten

von B

ewerbern un

d Mitarbeitern

�Ausw

ahl u

nd Festlegung von Sch

ulungen, W

erkzeugen

und T

echnologie

�Sch

ulung un

d Einführu

ng der Softwarearch

itektur im

En

twicklerteam

�Motivation

, Begeisterun

g und Integration des

Entw

icklerteams bzgl. des A

rchitektu

rentwurfs

�Organisation

des Entw

icklerteams en

tsprechend dem

Arch

itekturen

twurf u

nd dem Projektplan

1.48

Der A

rchitekt als technischer Projektleiter (2)

�Zuordn

en der konkreten

Implem

entieru

ngsaufgaben zu

den Entw

icklern

�Delegieren von „lokalen

“En

twurfsen

tscheidu

ngen an

Spezialisten und an

das Entw

icklungsteam

�Verfolgu

ng und Ü

berprüfung der im

plementieru

ngs-spezifisch

en Projektm

eilenstein

e

�Verfolgu

ng und Ü

berprüfung der Q

ualität des

Feindesigns der Im

plemen

tierung

�Überprü

fung der In

tegrität und korrekten

Realisierun

g der Softw

arearchitektu

r

�Organisation

von Wartu

ng und W

eiterentw

icklung der

zentralen

Schnittstellen

des Systems

1.49

Der A

rchitekt als „Hüter“

der Softwarearchitektur

�Überprü

fung u

nd Sicherung der Ein

haltu

ng der Arch

itekturvorgaben im

konkreten

Entw

icklungsprojekt

�Softw

arearchitektu

r und die R

olle des Software-

architekten als B

estandteil der Untern

ehmen

skultu

r etablieren

�Iden

tifikation, Koordination

und Erarbeitung von

projektübergreifenden A

rchitektu

rthem

en aus der eigen

en Projektlandschaft, In

dustrie und Forsch

ung

�Defin

ition und Integration des A

rchitektu

rentwurfs in

die firm

enübergreifende Projektman

agemen

t-un

d Qualitätssich

erungsstan

dards

1.50

Zusammenfassung „D

isziplin Softwarearchitektur“

�Ziel des A

rchitektu

rentwurfs ist es ein

e vollständige u

nd prägn

ante A

rchitektu

rbeschreibun

g zu erstellen

, um die

geforderten fun

ktionalen

und n

icht fun

ktionalen

Anforderungen

zu gewäh

rleisten�

Der Softw

arearchitekt ist D

IE Brücke zw

ischen

allen Anforderungsträgern un

d der Softwaretech

nik

�Der En

twurfsprozess steh

t im Zentru

m des gesam

ten

Entw

icklungsprozesses; Er h

at Schnittstellen zu

Anfor-

derungsanalyse, System

architektu

r und Im

plementierung

�Der En

twurfsprozess ist ein Zyklu

s aus A

nalyse,

Modellieru

ng und V

alidierung der Softw

arearchitektur

�Die qu

erschnittlich

en Aufgaben

des Arch

itekten geh

en von der Program

mierun

g bis zur Firm

enstrategiegestaltu

ng2.51

Softw

arearch

itektu

r –1. E

inleitung

Literaturhinweise

�[BRS97] K

laus Bergner, A

ndreas Rausch, M

arc Sihling: U

sing UML for M

odeling a Distribu

ted Java Application, T

echnischer B

ericht der U

niversität München, T

UM-

I9735, http://wwwbib.in

formatik.tu-m

uenchen.de/infberich

te/1997/TUM-

I9735.ps.gz,1997

�[AF98] Paul A

llen, Stuart Forst: C

omponent-Based D

evelopment for Enterprise

Systems: A

pplying The SELECT Perspective , C

ambridge U

niversity Press, 1998�

[BCK+98] Len B

ass, Paul Clem

ents, R

ick Kazm

an, Ken B

ass: Software A

rchitecture in Practice (Sei Series in Softw

are Engineering) , Addison

-Wesley Pub

lishing, 1998�

[DW98] D

esmon

d Francis D'Sou

za, Alan C

ameron W

ills. Objects, C

omponents, and

Framew

orks With U

ML: The C

atalysis Approach

, Addison W

esley Publishing Com

pany, 1998�

[HNS99] C

hristine Hofm

eister, Robert N

ord, Dilip S

oni: Applied Softw

are Architecture , A

ddison W

esley –Object T

echnology Series, 1999�

[HS99] Peter H

erzum, O

liver Sims. B

usiness Com

ponent Factory: A

Com

prehensive Overview

of Com

ponent-Based Developm

ent for the Enterprise , John W

iley & Sons,

1999�

[JRL+

00] Mehdi Jazayeri, A

lexander R

an, Frank Van D

er Linden, Philip V

an Der

Linden: Software A

rchitecture for Product Families: Principles and Practice, A

ddison-

Wesley Publishin

g, 2000�

[Gil02] T

om Gilb: C

ompetitive E

ngineering, www.gilb.com

, 2002

1.52

Softw

arearch

itektu

r –1. E

inleitung