Softwaretechnik Uberblick I Software-Architektur · ! unterstutzt Wiederverwendung im groˇen Stil...

Softwaretechnik

Prof. Dr. Rainer Koschke

Fachbereich Mathematik und InformatikArbeitsgruppe Softwaretechnik

Universitat Bremen

Wintersemester 2011/12

Uberblick I

Software-Architektur

Software-Architektur:

Software-Architektur

Software-ArchitekturWas ist Software-Architektur?Zusammenfassung aus dem Software-Projekt:Hofmeister-Methode und -BlickwinkelQualitat von Software-ArchitekturenTaktikenEvaluation von Software-ArchitekturWiederholungsfragen

3 / 82

Software-Architektur:

Lernziele

Verstehen, was Software-Architektur ist

Qualitaten einer Architektur kennen

Taktiken des Software-Architekturentwurfs kennen

Software-Architektur beschreiben konnen

Software-Architektur bewerten konnen

4 / 82

Software-Architektur: Was ist Software-Architektur?

Was ist Architektur?

Architecture is the human organization of empty spaceusing raw material.

Richard Hooker, 1996.

DefinitionSoftware-Architektur ist die grundlegende Organisation einesSystems, verkorpert (IEEE P1471 2002)

in seinen Komponenten,

deren Beziehungen untereinander und zur Umgebung

und die Prinzipien, die den Entwurf und die Evolution leiten.

Weitere uber 100 Definitionen unter www.sei.cmu.edu/architecture/community_definitions.html.

6 / 82


Bedeutung von Software-Architektur

Kommunikation zwischen allen Interessenten

hoher Abstraktionsgrad, der von vielen verstanden werden kann

Fruhe Entwurfsentscheidungen

→ nachhaltige Auswirkungen→ fruhzeitige Analyse

Transferierbare Abstraktion des Systems

→ Beherrschung der Komplexitat→ Aufgabenverteilung→ eigenstandig wiederverwendbar→ unterstutzt Wiederverwendung im großen Stil

(Software-Produktlinien)

7 / 82

www.sei.cmu.edu/architecture/community_definitions.html

www.sei.cmu.edu/architecture/community_definitions.html

• SA reprasentiert hohe Abstraktion eines Systems, die von denmeisten Interessenten verstanden werden kann und damit eineGrundlage zum gegenseitigen Verstandnis, zur Konsensbildung undzur Kommunikation darstellt.

• SA ist die Manifestation fruher Entwurfsentscheidungen; diese fruheFixierung kann nachhaltige Auswirkungen haben auf dienachfolgende Entwicklung, Auslieferung sowie Wartung undEvolution. SA ist auch die fruheste Systembeschreibung, dieanalysiert werden kann.

• SA konstituiert ein relativ kleines intellektuell fassbares Modelldaruber, wie das System strukturiert ist und wie seine Komponentenzusammenwirken; dieses Modell ist eigenstandig nutzbar und kannuber das spezifische System hinaus transferiert werden; insbesonderekann es fur Systeme mit ahnlichen Eigenschaften undAnforderungen wiederverwendet werden, um so Wiederverwendungim großen Stil zu unterstutzen (Stichwort: Software-Produktlinien).


Architektursichten und -blickwinkel (IEEE P1471 2002)

DefinitionArchitektursicht (View):

Reprasentation eines

ganzen Systems aus der

Perspektive einer

koharenten Menge von

Anliegen.

DefinitionArchitekturblickwinkel (Viewpoint):Spezifikation der Regeln undKonventionen, um eine Architektursicht zukonstruieren und zu benutzen.Ein Blickwinkel ist ein Muster oder eineVorlage, von der aus individuelle Sichtenentwickelt werden konnen, durchFestlegung von

Zweck,

adressierte Betrachter,

und Techniken fur Erstellung,Gebrauch und Analyse.

function

calls

8 / 82

Unterschiedliche Sichten helfen der Strukturierung: Separation ofConcerns.

Architecture design and reconstruction create architectural views forexisting systems. But what is a view at all?

One of the achievements of the IEEE P1471 is the definition of views andviewpoints.

A view is a representation of a whole system from the perspective of arelated set of concerns. Here, for instance, you see a part of the callgraph of jikes, the IBM compiler for Java.

Such views are formalized through viewpoints. A viewpoint specifies thekind of information that can be put in a view. A call graph viewpoint canbe modeled by this UML diagram, for instance.


Siemens-Blickwinkel (Hofmeister u. a. 2000)

Konzeptioneller Blickwinkel: beschreibt logische Strukturdes Systems; abstrahiert weitgehend von technologischenDetails

Modulblickwinkel: beschreibt die statische logische Strukturdes Systems

Ausfuhrungsblickwinkel: beschreibt die dynamische logischeStruktur des Systems

Code-Blickwinkel: beschreibt die ”‘anfassbaren”’ Elementedes Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateienetc.)

9 / 82


Verbreitete Blickwinkel

ZachmanPerry and Wolfe

4+1Siemens

Clements et al.. . .

10 / 82

Viewpoints are very popular in forward engineering. Zachman was one ofthe first authors on viewpoints (Zachman 1987; Sowa und Zachman1992; Zachman 1999). He proposed 6× 6 different viewpoints. Perry undWolf (1992) proposed a simplified version of these views, distinguishingonly three viewpoints. Then you have the 4+1 viewpoints by PhilippeKruchten (1995), you have the four Siemens viewpoints, et cetera.

The number of viewpoints is confusing, in particular, because many ofthem are very similar.

Recently, the book by Clements and colleagues brought some order tothis sea of viewpoints.


Blickwinkelkategorisierung (Clements u. a. 2002)

M: module

decompositionusegeneralizationlayers

CC: component & connectors

pipe and filtershared datapublish and subscribeclient serverpeer-to-peercommunicating processes

A: allocation

deploymentimplementationwork assignment

11 / 82

Here, you see their categories of viewpoints.

Module viewpoints show static structure and describe the decomposition,layering, and generalization of modules and their use dependencies. Amodule is a code unit that implements a set of responsibilities.

Component-and-connector viewpoints express runtime behavior describedin terms of components and connectors. A component is one of theprincipal processing units of the executing system; a connector is aninteraction mechanism for the components.

Allocation viewpoints describe mappings of software units to elements ofthe environment (the hardware, the file systems, or the developmentteam).


Architekturbegriffe im Kontext (IEEE P1471 2002)

System

Stakeholder Rationale

Mission

View

ModelLibrary

Viewpoint

Concern

Environment

Viewpoint

ArchitecturalDescription

Architecture

establishesmethods for

fulfills

has an

identifies

used to cover

aggregates

conforms to

organized by

identifies

1..*

1..*

1..*

1..*

1..*

1..* 1..*

1..*

1..* 1..*

0..1

1..*

1..*

1..*

influences

inhabits

1

provides

has

is addressed to

has

is important to

described by

participates in

consists of

participates in

has source

selects

12 / 82

Software-Architektur: Zusammenfassung aus dem Software-Projekt: Hofmeister-Methode und -Blickwinkel

Methode von Hofmeister u. a. (2000)

1 Einflussfaktoren identifizieren

Produktfunktionen und -attributetechnologische Faktorenorganisatorische Faktoren

2 konkurrierende Faktoren feststellen

3 Kompromisse fur Faktorenkonflikte durch Strategien finden

4 iterativer Entwurf der verschiedenen Sichten

13 / 82

Software-Architektur: Zusammenfassung aus dem Software-Projekt: Hofmeister-Methode und -Blickwinkel

Modul−

beschränkungen

ModuleSubsysteme

Schichten

neue

Modula−

risierung

Änderungen

elementen

an Laufzeit−

KonnektorenKonfiguration

Komponenten

KomponentenKonnektorenKonfiguration

Laufzeit−

beschränk−

ungen

neue

Modula−

risierung

Laufzeit−

elemente

Modulblickwinkel

Code−Blickwinkel

Aus

führ

ungs

blic

kwin

kel

Konzeptioneller Blickwinkel

Software−Architektur

Einfluss

Rückkopplung

Module

Quell−Code

Har

dwar

e−A

rchi

tekt

ur

14 / 82

Software-Architektur: Qualitat von Software-Architekturen

Funktionalitat versus Qualitat

DefinitionFunktionalitat: Umsetzung der funktionalen Anforderungen; dieFahigkeit eines Software-Systems, auf eine Eingabe die erwarteteAusgabe zu produzieren.

Funktionalitat kann durch beliebige Strukturen umgesetzt werden;ist damit weitgehend unabhangig von Struktur.

Software-Architektur schrankt mogliche Strukturen ein aufgrundanderer Qualitatsattribute.

DefinitionQualitat ist der Grad, in dem ein Satz inharenter MerkmaleAnforderungen erfullt.

EN ISO 9000:2005

17 / 82


Beispiele fur Software-Qualitatsaspekte

Anderbarkeit

Testbarkeit

Sicherheit

Robustheit

Gebrauchstauglichkeit (Usability)

Performanz

Verfugbarkeit

Skalierbarkeit

Portierbarkeit

. . .

18 / 82


Software-Architektur und Qualitatsattribute

Architektur ist kritisch fur die Realisierung vieler Qualitaten

→ Qualitaten mussen durch Konstruktion eingebaut werden→ Qualitaten konnen und sollen auf Architekturebene evaluiert

werden

Architektur alleine genugt nicht zur Erreichung der Qualitaten

→ Architektur bildet nur die Grundlage→ Implementierungsdetails sind maßgebend

Qualitatsattribute konnen im Konflikt zueinander stehen;Architektur ist ein Kompromiss

Qualitatsattribute mussen objektiv und operationalbeschrieben sein → konkrete messbare Szenarien

19 / 82


DefinitionQualitatsattributsszenario ist eine operationale Anforderunghinsichtlich eines Qualitatsattributs (Bass u. a. 2003):

wenn ein bestimmtes Ereignis eintritt (Stimulus)

in einer bestimmten Situation (Umgebung),

das von einem bestimmten Ausloser kommt (Stimulusquelle)

und auf einen bestimmten Gegenstand einwirkt (Artefakt),

dann soll eine geforderte Reaktion

in einer messbaren Art eintreten (Reaktionsmessung).

unerwartete

Nachricht

Operator

informiert;

Betrieb fort-

gesetztNormaler

Betrieb

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

Prozess

Keine Downtimesystemextern

20 / 82

Beispiel fur Verfugbarkeit: Erkennung von Fehlern mitAusnahmebehandlung fur volle Fehlertoleranz.


Kategorien von Software-Architektur-Qualitaten

Systemqualitaten (Verfugbarkeit, Anderbarkeit, Performanz,Sicherheit, Testbarkeit, Gebrauchstauglichkeit etc.)

Geschaftsqualitaten, z.B. Time-To-Market

Qualitaten der Architektur selbst, z.B. konzeptionelleIntegritat, die indirekt die anderen Qualitaten beeinflussen

21 / 82


PerformanzAllgemeine Szenarien:

Quelle intern/externStimulus periodische, sporadisch, stochastische EreignisseArtefakt SystemUmgebung Normalbetrieb, ausgelastet

Reaktion Bearbeitung von Stimuli, Anderung von Service-Levels

Maß Latenz, Deadline, Durchsatz, Versatz, Versaumnis-rate, Datenverlust

Spezielles Szenario:

initiierte

Transaktion

Transaktion

ist

bearbeitet

Normaler

Betrieb

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

System

Latenz von 2[sek]Benutzer22 / 82

Latenz: Reaktionszeit gemessen ab Eintreffen der Nachricht(Latency)

Deadline: fester Zeitpunkt, zu dem Reaktion erfolgt sein muss

Versatz: Variation der Reaktionszeit (Jitter)

Durchsatz: Anzahl der Ereignisse, die einem bestimmten Zeitintervallbearbeitet werden konnen

Versaumnisrate: Anzahl der Ereignisse, die einem bestimmtenZeitintervall nicht bearbeitet werden konnten

Datenverlust: Umfang der Daten, die verloren gingen


Anderbarkeit

Allgemeine Szenarien:

Quelle Endbenutzer, Entwickler, SystemadministratorStimulus Wunsch, Funktionalitat hinzuzufugen, zu entfernen,

abzuandern, zu variieren bzw. Qualitatsaspekt zuverandern

Artefakt System (Benutzeroberflache, Plattform, Umgebung,kooperierendes System)

Umgebung Laufzeit, Ladezeit, Ubersetzungszeit, Entwurfszeit

Reaktion Lokalisierung, Anderung, Test, Auslieferung der Ar-chitekturkomponenten

Maß Kosten in Form von Anzahl der betroffenen Kompo-nenten, Aufwand, Geld; Ausmaß des Einflusses aufandere Qualitatsattribute

23 / 82


Anderbarkeit


Wunsch, GUI

zu andern

Anderung

ohne Seiten-

effekte

gemachtEntwurfs-

zeit

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

Code

in 3 StundenEntwickler

24 / 82


Testbarkeit

DefinitionTestbarkeit: Grad der Einfachheit, Fehler in der Softwareaufzuzeigen; Wahrscheinlichkeit – unter der Voraussetzung, dassdie Software mindestens einen Fehler hat – dass der nachste Testpositiv ausfallt.

25 / 82


Testbarkeit

Allgemeine Szenarien:

Quelle Unit-Entwickler, Integrator, Systemverifizierer, Ak-zeptanztester, Endbenutzer

Stimulus Prufling (Analyse, Architektur, Entwurf, Klasse,Subsystem) erstellt; System ausgeliefert

Artefakt Teil des Enwurfs oder Codes; ganze Applikation

Umgebung Entwurfs-, Entwicklungs-, Ubersetzungs-, Einsatz-zeit

Reaktion gewahrt Einblick in Zustandswerte und berechneteWerte, bereitet Testumgebung vor

Maß Abdeckungsgrad, Wahrscheinlichkeit eines Storfalls,wenn ein Fehler existiert; Aufwand fur Test, Dauer,Vorbereitung der Testumgebung

26 / 82


Testbarkeit


fuhrt Unit-

test durch

Unit hat

Schnittstelle,

Verhalten zu

steuern und zubeobachten

Unit

implementiert

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

Unit

85% PfadabdeckungUnit-Tester

in 3 Stunden

27 / 82


Geschaftsqualitaten

Time-To-Market

Kosten/Nutzen

anvisierte Lebensdauer

Zielmarkt

Auslieferungsplan

Integration mit Legacy-Systemen

. . .

29 / 82

• Time-To-Market: kurze Time-To-Markt zwingt zu COTS undinkrementeller Entwicklung

• Kosten/Nutzen: hat z.B. auch Einfluss auf Technologien, dieverwendet werden konnen (Anschaffungskosten, Einarbeitungszeit)

• anvisierte Lebensdauer: hohe Lebensdauer verstarkt Bedeutung vonAnderbarkeit, Skalierbarkeit, Portabilitat

• Zielmarkt: bei Massenmarkt ist Portabilitat und allgemeineFunktionalitat von hoher Bedeutung

• Auslieferungsplan: bei inkrementeller Auslieferung muss das Systemleicht erweiterbar sein

• Integration mit Legacy-Systemen: zwingt zuIntegrationsmechanismen


Qualitaten der Architektur selbst

Einfachheit

konzeptionelle Integritat: Gleiches wird gleich gelost (FredBrooks)

Kopplung minimieren, Kohasion maximieren

Isomporphie zur Realitat (Michael Jackson)

. . .

31 / 82

Software-Architektur: Taktiken

Taktiken und Strategien

DefinitionTaktik bezeichnet das geschickte Nutzen einer gegebenen Lage(Wikipedia).

Strategisches Handeln ist langfristig, taktisches Handelnmittelfristig und operatives Handeln kurzfristig angelegt(Wikipedia).

”Tactics are the specifics of strategies”.

33 / 82


Taktik im Architekturkontext

DefinitionTaktik: Entwurfsentscheidung, die die Reaktion auf einen Stimulusbestimmt und damit ein Qualitatsattribut beeinflusst.

Wunsch, GUI

zu andern

Anderung

ohne Seiten-

effekte

gemachtEntwurfs-

zeit

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

Code

in 3 StundenEntwickler

35 / 82


Taktiken fur Anderbarkeit

Eingrenzungvon Anderungen

semantischeKoharenzantizipierteAnderungenverallgemeinerteModuleBegrenzungmoglicherOptionenabstraktegemeinsameDienste

Vermeidung desWelleneffekts

GeheimnisprinzipErhalt existierenderSchnittstellenRestriktion vonKommunikations-pfadenVerwendung einesMittelsmanns

Aufschieben derBindezeit

Laufzeit-registrierungKonfigurations-dateienPolymorphismusAustausch vonKomponentenEinhaltung vonProtokollen

Anderbarkeit

37 / 82

Eingrenzung von Anderungen

semantische Koharenz: alle Bestandteile eines Moduls tragen zu einemgemeinsamen Zweck bei; bei Anderung des Zwecksmussen nur die Elemente des Moduls angepasst werden

antizipierte Anderungen: zukunftige Anderungen sind bereitseingeplant/eingebaut

verallgemeinerte Module: Modul ist allgemeiner als es sein musste undparametrisiert (durch einfache Parameter bis hin zurAuspragung des Moduls als Interpreter)

Begrenzung moglicher Optionen: die moglichen Optionen werdeneingeschrankt; damit werden beliebige Anderungenausgeschlossen; z.B. kann man bei Anderungen desProzessors einschranken, dass er sich nur innerhalb einerProzessorfamilie andern darf

abstrakte gemeinsame Dienste: ahnliche Funktionalitat in verschiedenenModulen wird herausfaktorisiert und nur einmalimplementiert als dienstleistendes Modul


Vermeidung des Welleneffekts

Geheimnisprinzip: Dinge, die sich wahrscheinlich andern, werdenhinter einer abstrakten Schnittstelle verborgen.

Erhalt existierender Schnittstellen: Alternativen:– mehrere Schnittstellen: neu und alt– Adapter– Stumpf (wenn Dienst wegfallt)

Restriktion von Kommunikationspfaden: Anzahl der Module, mitdenen Daten geteilt werden, wird reduziert

38 / 82


Verwendung eines Mittelsmanns I

Verwender (V) und Dienstleister (D)

Syntax von . . .

Daten: Format von Daten zwischen V und D→ Verwendung eines Repositories, das Daten konvertiert

Diensten: Signaturen mussen ubereinstimmen→ Muster: Facade, Mediator, Strategy, Proxy, Factory

Semantik von . . .

Daten: konsistente Annahmen uber Semantik der DatenDiensten: konsistente Annahmen uber Semantik der Dienste

→ semantischer Konverter

Reihenfolge von. . .

Daten: konsistente Annahme uber ReihenfolgeKontrolle: D muss vor V ausgefuhrt sein (in bestimmter Zeit)

→ Puffer mit Veranderung der Reihenfolge

39 / 82


Verwendung eines Mittelsmanns II

Identitat der Schnittstelle von D (falls es mehrere gibt)

→ Broker-Muster

Ort von D (zur Laufzeit); z.B. gleicher Prozessor

→ Name-Server

Quality-of-Service/-Data von D

→ schwer zu uberbrucken

Existenz von D

→ Factory-Muster

Ressourcenverhalten von D

→ Ressourcen-Manager als Mittelsmann

40 / 82

Beispiele:

• Syntax von . . .

– Daten: die Sequenz von Bytes (Big vs. Little Endian)– Diensten: Anzahl und Typ der Parameter

• Semantik von . . .

– Daten: die Einheit der Werte ist die gleiche; Meilen versusKilometer (alles schon ’mal dagewesen)

– Diensten: top wirft Exception, wenn der Stack leer ist statteinen undefinierten Wert zuruckzugeben

• Reihenfolge von . . .

– Daten: Netzwerkpakete kommen in der Reihenfolge ihresAbschickens an

– Kontrolle: D muss 5 Millisekunden vor V ausgefuhrt wordensein

• Identitat der Schnittstelle von D: D hat verschiedene Versionenseiner Schnittstelle uber die Zeit

• Ort von D (zur Laufzeit); V und D laufen auf gleichem Prozessormit gemeinsamem Speicher

• Quality-of-Service/-Data von D: die Daten des Sensors D sind ineinem Toleranzbereich der Genauigkeit

• Existenz von D: damit V einen Dienst von D aufrufen kann, muss Dexistieren oder V muss die Moglichkeit haben, D zu erschaffen

• Ressourcenverhalten von D: D gibt alle seine Resourcen wieder frei,nachdem der Dienst erbracht wurde


Aufschieben der Bindezeit

Laufzeitregistrierung: Plug-and-Play zur Laufzeit oder Ladezeit

Konfigurationsdateien: Parameterwerte wahrend desSystemstarts

Polymorphismus: spates Binden von Methoden

Austausch von Komponenten: wahrend der Ladezeit

Einhaltung von Protokollen: Laufzeit-Bindung unabhangigerProzesse

41 / 82


Taktiken fur Testbarkeit

InteresMonitoring

Behandlung vonEingabe-/Ausgabe

Aufnahme/WiedergabeTrennung vonSchnittstelleund Imple-mentierungSpezialisierungvon Schnitt-stellen

EingebauterMonitor

Testbarkeit

42 / 82


Behandlung von Eingabe und Ausgabe

Aufnahme/Wiedergabe

Information, die Schnittstelle passiert, wird vermerkt

kann spater fur Regressionstest benutzt werden

Trennung von Schnittstelle und Implementierung

ermoglicht Substitution der Implementierung furs Testen

Teststumpfe konnen vorausgesetzte Komponenten simulieren

Testtreiber simulieren Verwender

Spezialisierung von Zugriffspfaden/Schnittstellen

Spezialisierte Schnittstelle erlaubt Aufzeichnung undManipulation von Attributen einer Komponente durch einenTestrahmen

43 / 82


Internes Monitoring

Eingebauter Monitor

Zustand und andere Attribute (Performanz, Belastung (Load),Sicherheit etc.) werden durch Schnittstelle zur Verfugunggestellt

wird uber Schnittstelle vom Monitor zur Laufzeit beobachtet

Permanente Schnittstelle: Teil der normalen Schnittstelle

Temporare Schnittstelle: nur beim Monitoring prasent(Ausgabeanweisungen im Code furs Tracing,Code-Instrumentierung, Makros, aspektorientiertesProgrammieren etc.)

44 / 82

Software-Architektur: Evaluation von Software-Architektur

Kosten von Evaluationen

Erfahrungen bei AT&T:

ca. 300 Architekur-Reviews durchgefuhrt

fur Projekte mit mindestens 700 PT Aufwand

→ durchschnittlich 70 PT fur Evaluation

Erfahrungen des SEIs:

36 PT fur ATAM-Evaluation (nur Evaluations-Team; dazunoch: andere Projektteilnehmer und Entscheider)

46 / 82


Vorteile einer fruhen Evaluation

fruhe Erkennung von Fehlern (je fruher ein Fehler entdecktwird, desto billiger ist seine Beseitigung)

→ 10% Kosteneinsparung bei AT&T

Zwang zur Dokumentation der Architektur

Zwang zum Festhalten der Begrundungen vonEntwurfsentscheidungen

weitere Uberprufung der Anforderungen

Verbesserung von Architekturen durch Erfahrungen, die manin den Evaluationen sammelt

47 / 82


Techniken zur Evaluation von Software-Architektur

Fragetechniken

Fragebogen und ChecklistenArchitecture Tradeoff Analysis Method (ATAM)Cost Benefit Analysis Method (CBAM)

Messtechniken

Architekturmetriken (Kopplung, Kohasion etc.)Simulatoren (Performanz, Verfugbarkeit)

48 / 82

→ Fragetechniken sind jederzeit anwendbar, aber weniger objektiv

→ Messtechniken setzen operationale Architektur voraus, liefern abergenaue Antworten


Anforderungen/Kontext

Architekturanalysen sind schwierig:

große Systeme haben umfangreiche Architektur

Evaluation muss Verbindung zu Geschaftszielen herstellen

verschiedene Stakeholders haben unterschiedliche Interessen

49 / 82


Architecture Tradeoff Analysis Method (ATAM)

Vorbedingungen:

klar artikulierte Ziele und Anforderungen an die Architektur

klar abgesteckter Rahmen (ca. funf Ziele mit hoher Prioritat)

erwarteter Nutzen ubersteigt erwartete Kosten (meist furSysteme ab mittlerer Große erfullt)

Schlusselrollen verfugbar (z.B. Architekt)

kompetentes Evaluations-Team (Querschnittsbereich mitEntscheidungskompetenzen)

realistische und offene Erwartungen

51 / 82


Teilnehmer bei ATAM (Bass u. a. 2003)

Evaluations-Team (extern)

Entscheider

Projekt-ManagerArchitekteventuell Vertreter des Kunden

Architektur-Stakeholders

Entwickler, Tester, Integrierer, Wartungsprogrammierer,Performanztuner, Benutzer, Build-Prozess-Verantwortliche

52 / 82


Rollen im ATAM-Evaluations-Team

GruppenleiterAufgaben:

bereitet Evaluation vor

halt Kontakt zum Kunden

formiert Evaluations-Team

stellt sicher, dass Endbericht ausgeliefertwird

Eigenschaften:

Organisationsgabe

Managementfahigkeiten

gute Interaktion mit Kunden

zuverlassig in Zeitplanen

53 / 82



EvaluationsleiterinAufgaben:

leitet Evaluation

unterstutzt Auswahl der Szenarien

organisiert Szenarioauswahl und-priorisierung

unterstutzt Evaluation

Eigenschaften:

erfahren in Architektur

kann prasentieren

kann moderieren

54 / 82



Szenario-SchreiberAufgaben:

halt Szenarien fest wahrend der Auswahl(Flipchart o.A.)

halt Terminologie fest

besteht auf klarer Formulierung

Eigenschaften:

besteht darauf, die Dinge auf den Punktzu bringen

kann die Essenz einer Diskussionaufnehmen und sie pragnantzusammenfassen

55 / 82



ProtokollantAufgaben:

protokolliert initiale Szenarien sowieMotivation und Entschluss fur Szenarien

verschickt Szenarien an alle Beteiligten

Eigenschaften:

kann sich schriftlich gut ausdrucken

kann Information gut abrufen

hat gutes Verstandnis vonArchitekturfragen

kann technische Aspekte gut aufnehmen

ist bereit, Diskussion zu unterbrechen, umsein eigenes Verstandnis eines Szenarioszu prufen

56 / 82



ZeitnehmerinAufgaben:

unterstutzt Evaluationsleiter, die Zeiteinzuhalten

unterstutzt, die Zeit fur jedes Szenario inder Evaluationsphase festzuhalten und zusteuern

Eigenschaften:

bereit, Diskussion mit Hinweis auf Zeit zuunterbrechen

57 / 82



ProzessbeobachterinAufgaben:

entdeckt Verbesserungen desEvaluationsprozesses

eher stille Beobachtung wahrend derEvaluation, kann aber Prozessvorschlagemachen

berichtet Erfahrungen und schlagtVerbesserung nach der Evaluation vor

berichtet an unternehmensweiteArchitekturgruppe

Eigenschaften:

guter Beobachter

erfahrener Anwender der Methode

58 / 82



Prozessexperte (Process Enforcer)Aufgaben:

unterstutzt Evaluationsleiter, dieProzessschritte richtig auszufuhren

Eigenschaften:

erfahrener Anwender der Methode

diskreter Ratgeber

59 / 82



FragestellerAufgaben:

wirft Aspekte auf, an die die Stakeholdersnicht gedacht haben

Eigenschaften:

hat fundiertes Architekturwissen

hat Einsicht in die Belange derStakeholders

hat Erfahrung mit Systemen in ahnlichenDomanen

ohne Angst, auch umstrittene Belangeaufzuwerfen

60 / 82


Resultate von ATAM

Primare Resultate:

prazise Beschreibung der Architektur

Artikulation der Geschaftsziele

Qualitatsanforderungen in Form von Szenarien

Verbindung von Entwurfsentscheidungen undQualitatsanforderungen

Liste von Einflussen (Sensitivity Points) und Kompromissen(Tradeoff Points)

Liste von Risiken (Risks) und Nichtrisiken (Nonrisks)

61 / 82


Einflusse/Kompromisse

DefinitionSensitivity Point: Entwurfsentscheidung mit merklichem Einflussauf ein Qualitatsattribut

Bsp.: Backup-Datenbank soll verwendet werden→ (positiver) Einfluss auf Zuverlassigkeit

DefinitionTradeoff Point: Sensitivity Point mit merklichem Einfluss aufmehrere Qualitatsattribute

Bsp.: Backup-Datenbank soll verwendet werden→ (negativer) Einfluss auch auf Performanz, wegen zusatzlichenRessourcenbedarfs

62 / 82


Risiken/Nichtrisiken

DefinitionRisiko: Entwurfsentscheidung mit potentiell unerwunschtenKonsequenzen fur die Qualitatsattribute.Nichtrisiko: Entwurfsentscheidung, die nach Analyse keineunerwunschten Konsequenzen fur die Qualitatsattribute hat.

Bsp.: Backup-Datenbank soll verwendet werden→ (positiver) Einfluss auf Zuverlassigkeit→ (negativer) Einfluss auch auf Performanz

Wird zum Risiko, erst wenn Performanz von großer Bedeutung ist.

63 / 82


Resultate von ATAM (Forts.)

Erwunschte Nebeneffekte:

bessere Architekturbeschreibung

Gemeinschaftsgefuhl der Beteiligten

bessere und offenere Kommunikation der Beteiligten

besseres Verstandnis der jeweiligen Anliegen

64 / 82


Prozessphasen

Aktivitat Teilnehmer Dauer

Vorbereitung Leiter desEvaluationsteams,Schlusselentscheider

informell uberein paarWochen

Evaluation Teil I Evaluationsteam,Architekt und Entscheider

1 Tag gefolgtvon einer Pausevon 2-3Wochen

Evaluation Teil II Evaluationsteam,Architekt, Entscheider,Stakeholders

2 Tage

Wiedervorlage Evaluationsteam undBetroffene

1 Woche

65 / 82

Prozessphase Vorbereitung

• Einfuhrung ins Projekt

• Erorterung der Logistik

• initiale Liste der Stakeholders

• Zeitplan

• Ubergabe verfugbarer Architekturdokumentation


ATAM-Evaluationsphase

Prasentationvon ATAM

Prasentation derArchitektur

Brainstorming undPriorisierung derSzenarien

Erstellung des Nutzensder Qualitatsattributeals Baum, Priorisierung

Prasentation derResultate

Prasentation dertreibendenGeschaftsziele

Identifikation derArchitekturansatze

Analyse derArchitekturansatze

Analyse derArchitekturansatze

Pha

se1

Pha

se2

66 / 82

1. Evaluationsleiter stellt ATAM, Kontext, Erwartungen vor

2. Projektentscheider stellt Geschaftsziele vor

– die wichtigsten Funktionen des Systems– relevante technische, organisatorische, okonomische oder

politische Randbedingungen– Geschaftsziele und Kontext– wesentliche Stakeholders– Hauptqualitatsziele der Architektur

3. Architekt stellt Architektur vor

– technische Randbedingungen (Betriebssystem, Hardware,Middleware, andere verbundene Systeme etc.)

– Architekturansatze (Stile und Muster)– Struktur der Prasentation:

Darstellung der verschiedenen Sichten (z.B. Siemens-Sichten)prinzipielle Entwurfsentscheidungen, Muster, TaktikenIntegration von COTS-KomponentenVerfolgung von 1-3 der wichtigsten AnwendungsfalleVerfolgung von 1-3 der wichtigsten AnderungsszenarienRisiken

4. Architekturansatze werden identifiziert

– Muster und Taktiken werden vom Team identifiziert– und vom Protokollanten fur alle sichtbar festgehalten;– erlauben spatere Analyse (bekannte Vor- und Nachteile), z.B.:

Schichtenarchitektur positiv fur Portierbarkeit, negativ furPerformanzDaten-Repository ermoglicht Skalierbarkeit, Abhangigkeitenschwerer zu durchschauen

5. Nutzlichkeitsbaum fur Qualtitatsattribute wird erstellt; Szenarienwerden priorisiert


Nutzlichkeitsbaum (Utility Tree)

TestbarkeitPerformanzAnderbarkeit

Nutzlichkeit

. . .Sicherheit

Transaktions-durchsatz

Datenlatenz

Speicherlatenz furKundendatenbankunter 20ms

20 Video-Framespro Sekundein Echtzeit

Stimulusquelle

Stimulus Reaktion

Umgebung

Artefakt

Reaktionsmessung

Prozess

68 / 82


Priorisierung der Szenarien

E

B

C

D

A

F

Priorität

Entscheider

hochPriorität Architekt

hoch

niedrig

eher nicht sehr wahrscheinlich

wahrscheinlich nicht wahrscheinlich

niedrig

69 / 82

• Priorisierung der Szenarien durch Entscheider

• Priorisierung der Szenarien durch Architekt bezuglich derSchwierigkeit, mit der die Architektur das Szenario erfullen kann

• Auswahl der Szenarien fur Evaluation


Beispielanalyse eines Architekturansatzes

Architekturdiagramm:

Primar CPU(OS1)

BackupCPU withWatchdog(OS2)

Switch CPU(OS1)

heartbeat(1 sec.)

A12 Wiederaufsetzen bei HW-Ausfall eines Switches

Attribut Verfugbarkeit

Umgebung Normaler Betrieb

Stimulus Eine der CPUs fallt aus

Reaktion 0.999999 Verfugbarkeit des Switches

71 / 82


Primar CPU(OS1)

BackupCPU withWatchdog(OS2)

Switch CPU(OS1)

heartbeat(1 sec.)

Watchdog ist einfach und zuverlassig

Fehlererkennung in maximal 2 Sekunden(Heartbeat/Watchdog)

Umschaltung in maximal 4 Sekunden

gleiche Hardware und gleiches Betriebssystem → gleicheFehler

Verfugbarkeit gefahrdet, weil redundanter Datenkanal fehlt

72 / 82


Resultat

Architekturentscheidungen Einfluss Kompromiss Risiko Nichtrisiko

Watchdog E4 N12

Heartbeat E5 N13

Datenumleitung E6 N14

Backup-CPU(s) E2 R8

Keinen Backup-Datenkanal E3 K3 R9

73 / 82


Prozessphase Wiedervorlage

Resultat wird vorgestellt/ubergeben

Diskussion uber den Verlauf der Evaluation

Prozessbeobachter berichtet

Aufwand wird festgehalten

Nach einigen Monaten:

Langzeiteffekte der Evaluation (sowohl fur Architektur alsauch weitere Evaluationen) werden bestimmt

Kosten/Nutzen-Abwagung

78 / 82

Software-Architektur: Wiederholungsfragen

Wiederholungs- und Vertiefungsfragen I

Was ist Software-Architektur?

Welche Bedeutung kommt ihr zu?

Was ist eine Architektursicht bzw. -blickwinkel?

Erlautern Sie die Kategorien von Blickwinkeln von Clements etal.

Erlautern Sie die Siemens-Blickwinkel. Wozu die Trennung inverschiedene Blickwinkel? Wer hat Interesse an den jeweiligenBlickwinkeln?

Erlautern Sie den Begriff Qualitat in Bezug aufSoftware-Architektur.

Was ist ein Qualitatsattributsszenario und was bezweckt mandamit?

Was ist eine Taktik im Zusammenhang mitSoftware-Architektur?

Nennen Sie Taktiken fur Anderbarkeit und Testbarkeit.79 / 82


Wiederholungs- und Vertiefungsfragen II

Geben Sie ein Szenario an fur das Qualitatsattribut. . . (Performanz, Anderbarkeit, Testbarkeit, aber auch andere).

Welche grundsatzlichen Techniken gibt es, umSoftware-Architekturen zu evaluieren?

Erlautern Sie die Architecture Tradeoff Analysis Method(ATAM).

Welche Rollen sind bei ATAM vorgesehen?

Erlautern Sie die Begriffe Sensitivity und Tradeoff Point.Wozu wird der Unterschied gemacht?

Wann betrachtet man eine Entwurfsentscheidung als Risiko?

80 / 82


1 Bass u. a. 2003 Bass, Len ; Clements, Paul ; Kazman,Rick: Software Architecture in Practice. 2nd ed. AddisonWesley, 2003

2 Clements u. a. 2002 Clements, Paul ; Bachmann, Felix ;Bass, Len ; Garlan, David ; Ivers, James ; Little, Reed ;Nord, Robert ; Stafford, Judith: Documenting SoftwareArchitecture. Boston : Addison-Wesley, 2002

3 Hofmeister u. a. 2000 Hofmeister, Christine ; Nord,Robert ; Soni, Dilip: Applied Software Architecture. AddisonWesley, 2000 (Object Technology Series)

4 IEEE P1471 2002 : IEEE Recommended Practice forArchitectural Description of Software-intensive Systems—Std.1471-2000. ISBN 0-7381-2518-0, IEEE, New York, NY, USA.2002

5 Kruchten 1995 Kruchten, Phillipe: The 4+1 View Model ofArchitecture. In: IEEE Software 12 (1995), November, Nr. 6,S. 42–50

81 / 82


6 Perry und Wolf 1992 Perry, Dewayne E. ; Wolf,Alexander L.: Foundations for the Study of Software. In: ACMSIGSOFT 17 (1992), Oktober, Nr. 4, S. 40–52

7 Sowa und Zachman 1992 Sowa, J. F. ; Zachman, J. A.:Extending and formalising the framework for informationsystems architecture. In: IBM Systems Journal (1992)

8 Zachman 1987 Zachman, J. A.: A framework for informationsystems architecture. In: IBM Systems Journal 26 (1987), Nr. 3

9 Zachman 1999 Zachman, J. A.: A framework for informationsystems architecture. In: IBM Systems Journal 38 (1999),Nr. 2&3, S. 454—470

82 / 82

Softwaretechnik Uberblick I Software-Architektur · ! unterstutzt Wiederverwendung im groˇen Stil...

Documents

Transcript of Softwaretechnik Uberblick I Software-Architektur · ! unterstutzt Wiederverwendung im groˇen Stil...