03 Architekturentwurf

Fakultt fr Informatik
Technische Universitt Mnchen
Einfhrung in die Softwaretechnik

3. Architekturentwurf
Prof. M. Broy (I4), Prof. B. Brgge, (I1), Prof. F. Matthes (I19), Prof. A. Pretschner (I22)
Architekturentwurf
3.1 Motivation
3.2 Konzepte des Architekturentwurfs
Komponente, Schnittstelle, Vertrag, Substituierbarkeit, ...
3.3 Architekturdokumentation mit der UML und DSM
3.4 Zur Rolle des Softwarearchitekten
3.5 Architekturmuster
3.6 Beispiel eines Architekturentwurfs
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm
Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 2

Aufgabe des Architekturentwurfs (1)
Aus den gegebenen Anforderungen an ein Software-Produkt eine softwaretechnische
Lsung (ohne Implementierung) entwickeln
Softwarearchitektur entwickeln und dokumentieren
Komponenten bzw. Module identifizieren
Ausgangspunkt
Funktionale und nicht-funktionale Anforderungen aus der Analysephase, z.B.
Pflichtenheft
Ergebnis
Softwarearchitektur (Systemarchitektur)
Spezifikationen der Systemkomponenten

Aufgabe des Entwurfs (2)
Analyse Entwurf
WAS? WIE?
Paketdiagramme,
Komponentendiagramme,
Anwendungsfalldiagramme, Entwurfs-Klassendiagramme,
konzeptuelle Klassendiagramme, Verteilungsdiagramme,
Aktivittsdiagramme ...

Architektur im allgemeinen Sprachgebrauch
Art and technique of designing and
building, as distinguished from the skills
associated with construction.
[EB07]
[Za87]
Jedes Softwaresystem hat eine Architektur
Die Architektur eines Softwaresystems umfasst
die Struktur,
das Verhalten und
die Verteilung
des Systems, jedoch auf einem hohen Abstraktionslevel.
Beschrieben werden im Besonderen

die Komponenten sowie
deren Beziehungen zueinander.
Die Auswahl der Architektur bestimmt das Verhalten des zu entwickelnden Systems
mageblich.
[ReHa06]

Definitionen fr Softwarearchitektur
Es gibt eine Vielzahl von Definitionen fr Softwarearchitektur, eine bersicht findet sich
unter http://www.sei.cmu.edu/architecture/definitions.html.
The fundamental organization of a system embodied in its components, their relationships

to each other, and to the environment, and the principles guiding its design and evolution.
[IEE00]
The software architecture of a program or computing system is the structure or structures

of the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.
[BCK03]
The structure of the components of a program/system, their interrelationships, and

principles and guidelines governing their design and evolution over time.
[GP95]

Meine Definition
Software Architecture is a set of functional decompositions of a software system
according to non-functional requirements.

Zentrale Begriffe
(De-)
Composition
Interface:
abstract Architecture
functionality
Architektur aggregiert ggf. rekursiv Komponenten
9
und ihre Beziehungen I
(De-)
Composition
Interface:
functionality
10
und ihre Beziehungen II
connects
(De-)
Composition
Interface: has
functionality
11
Funktionale Anforderungen I
connects
(De-)
Composition
Interface: has
functionality drive
describes Functional
requirements
has
System
12
Funktionale Anforderungen II
connects
(De-)
Composition
Interface: has
functionality drive
captures requirements
has
System
13
Nichtfunktionale Anforderungen I
connects
(De-)
Composition
Interface: has
functionality drive
has
System
Non-functional
requirements drive
14
Nichtfunktionale Anforderungen II
connects
(De-)
Composition
Interface: has determines
satisfaction drive
functionality
has
System
Non-functional
requirements drive
15
Software Architecture is a set of functional
decompositions of a software system according to
non-functional requirements.
connects
(De-)
Composition
Interface: has determines drive
satisfaction drive
functionality
Functional
describes requirements
has
System
Non-functional
requirements
16
Bedeutung von Softwarearchitektur
Die Softwarearchitektur hat starken Einfluss auf den Erfolg eines Softwareprojekts.
Software architecture is the set of design decisions which, if made incorrectly, may
cause your project to be cancelled. Eoin Woods
Die Bedeutung der Architektur steigt, je grer (und komplexer) das Projekt ist.
Die Softwarearchitektur beeinflusst hauptschlich das Projektmanagement.
Wichtig: Eine Architekturbeschreibung muss unterschiedliche Interessen verschiedener

Interessenten adressieren. Dies kann sie oft nur unter Verwendung unterschiedlicher
Betrachtungswinkel (engl. Viewpoints) erreichen.

Wesentliche Ziele einer Softwarearchitektur
Untersttzung der effizienten Entwicklung
berblick ber die Systemgre
Verteilung von Aufgaben auf Teams
Minimierung von Projektrisiken
Explizieren der bercksichtigten Anforderungen
Transparenz hinsichtlich mglicher Risiken
Schaffung eines gemeinsamen Verstndnisses
Gemeinsame Terminologe aller IT Beteiligten
Dokumentation von Kernwissen
Domnenspezifisches Wissen wird konzentriert dokumentiert
Ermglicht bertragung auf hnliche Aufgabenstellungen
Verteilung von Systemteilen in verteilen Hardwarearchitekturen (z.B. Client/Server)
Weiterentwicklung des Systems durch Anpassung/Austausch von Komponenten
[PBG07]

Anforderungen sind die Leitplanken des
Architekturentwurfs
Die Anforderungen aus den Dokumenten der Analysephase werden zu Einflussfaktoren
auf die zu erstellende Architektur.
Spezielle Bedeutung kommt dabei Anforderungen zu, welche die Gestaltung der
Architektur beschrnken, z.B. durch Vorgabe von:
Programmiersprachen
Fachlichen (Industrie-)Standards
Anzubindenden Altsystemen

Innerhalb dieser Leitplanken werden Architekturentscheidungen getroffen.

Tipps fr den Architekturentwurf:
Team von Experten
Eher kleines Team

Eine gute Architektur erfllt bestimmte Eigenschaften
Die Architektur besteht aus wohldefinierten, klar abgegrenzten Bausteinen.
Jeder Architekturbaustein ist in sich geschlossen und bietet eine nach auen klar
definierte Menge von Funktionalitten.
Die Architekturbausteine nutzen die von anderen Bausteinen angebotenen
Funktionalitten.
Die von einem Baustein angebotenen Funktionalitten sind unabhngig von ihrer
Erbringung im Inneren des Bausteins.
Die Architektur sowie der Zuschnitt ihrer Bausteine ist einheitlich und einfach.
[Bo94]
Zwei Kernbegriffe:
Komponente (Baustein)
Schnittstelle (nach auen klar definierte Menge von Funktionalitten)

Architekturentwurf: Top-Down-Entwicklung
Aufteilung der Komponenten in Teilkomponenten, die wieder in Teilkomponenten aufgeteilt
werden
Entwicklung in mehreren Verfeinerungsschritten
von abstrakten Architekturen zu Implementierung/Programmcode.
Komplexittsreduktion
Organisation, Aufgabenteilung (Teilsystem Entwicklergruppen)
Architekturentwurf
Entwurf Entwurf
Schnittstelle Schnittstelle
12 2
Entwurf Teilsystem 1 Entwurf Teilsystem 2 Entwurf Teilsystem
Entwurf Entwurf
Komponente 1.1 Komponente 2.1

Ziele der Dekomposition in Bausteine
Geringe Kopplung Kopplung beschreibt, zu welchem Grad zwei Bausteine ber
Schnittstellen miteinander verbunden sind. Geringe Kopplung, d.h. eine geringe Zahl
derartiger Schnittstellen ist dabei im Sinne der Komplexittsreduktion vorzuziehen.
Hohe Kohsion Kohsion beschreibt den Grad der Bindung der Elemente innerhalb
eines Bausteins. Hohe Kohsion, d.h. die enge Bindung verwandter Elemente in einen
Baustein ist dabei im Sinne der klaren Trennung von Verantwortlichkeiten im System
vorzuziehen.
Zulnglichkeit Zulnglichkeit beschreibt den Grad der Eignung eines Bausteines fr die
im zugewiesenen Aufgaben. (Ist der Baustein hinreichend, um die Aufgaben zu erfllen?)
Vollstndigkeit Vollstndigkeit beschreibt, zu welchem Grad ein Baustein mit seinen

Schnittstellen seinen Verantwortungsbereich abdeckt.
Einfachheit Einfachheit gibt einen Anhaltspunkt, wieweit ein Baustein die Komplexitt
seines Aufgabenbereichs reflektiert.
[Bo94]

Kopplung und Kohrenz von Komponenten
Ziel: Reduktion der Systemkomplexitt bei gleichzeitiger Erhaltung der Flexibilitt
Kohrenz zwischen Klassen (Kohrenz ist eine Form der Kohsion):

Hoch: Klassen, die mit hnlichen Aufgaben betraut sind, sind durch Assoziationen
verbunden
Niedrig: Viele Hilfsklassen ohne Assoziationen existieren
Kopplung zwischen Komponente:

Hoch: Vernderungen einer Komponente zieht eine Vielzahl von nderungen an
anderen Komponenten nach sich
Gering: Vernderung einer Komponente hat wenig Einfluss auf die anderen
Komponenten

Wie erreicht man hohe Kohrenz?
Hohe Kohrenz lsst sich erzielen, indem ein Groteil der Interaktion innerhalb einer
Komponente geschieht, nicht jedoch ber Komponentengrenzen hinweg.
Interessante Fragestellungen:
Hat der Aufruf eines Dienstes einer Komponente stets einen Unteraufruf an eine
weitere Komponente zur Folge?
Ja Vielleicht sollten die Komponenten zusammengefhrt werden
Welche Komponenten rufen einander bei der Diensterbringung auf?
Knnen Aufrufe durch Umstrukturierung oder nderung der Schnittstellen
vermieden werden?
Lassen sich die Komponenten hierarchisch, d.h. in Schichten organisieren?

Wie lsst sich geringe Kopplung erzielen?
Geringe Kopplung lsst sich stets erzielen, wenn Details ber die aufgerufene Klasse
vor der aufrufenden Klasse verborgen werden knnen (Information hiding - Parnas).
Interessante Fragestellungen:
Muss die aufrufende Klasse die Attribute der aufgerufenen Klasse kennen?
Ist es mglich, dass die aufrufende Klasse sich auf Methoden der aufzurufenden
Klasse beschrnkt?
David Parnas

Wie breche ich eine groe Anwendung in Bausteine
herunter?
Funktionale Dekomposition Objekt-orientierte Dekomposition
Abbildung des Gesamtsystems auf Zusammenfassung von Klassen zu
Funktionen und Unterfunktionen, beginnend Subsystemen/Komponenten
beim Anwendungsfall.
Schichtung von
Subsystemen/Komponenten
Abstraktion: Konzentration auf das
Wesentliche, Verdrngen des
Unwesentlichen
Lokalitt: Zusammenfassung von
Zusammengehrigem (Daten und
Algorithmen)
Verdecken: Beschrnkung der Sichtbarkeit
von Details auf diejenigen Teile eines
Systems, die sie auch bentigen
schrittweise Verfeinerung la Pascal, C oder Objektorientierte Verfeinerung la Simula, Java

COBOL oder C#

3.2 Konzept des Architekturentwurfs
3.1 Motivation
3.3. Architekturdokumentation mit der UML und DSM
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm

Mgliche Eigenschaften von Komponenten
Eine Komponente
hat eine (oder mehrere) definierte Schnittstelle(n)
hat einen Zustand
kann aus Komponenten zusammengesetzt sein
kann nebenlufig aufgerufen werden
hat einen eigenen Adressraum
hat eine eindeutige Identitt
kann dynamisch angelegt werden (hat einen Lebenszyklus)
hat einen persistenten Zustand
kann konfiguriert werden
ist selbstbeschreibend
...
Verschiedene Sprachen, Systeme und Modelle verwenden unterschiedliche

Komponentenbegriffe Das Konzept der Komponente, wie hier diskutiert, ist nicht 1-zu-1
durch heutige Sprachen und Systeme implementiert.

Komponenten und Schnittstellen
Eine Schnittstelle (engl. Interface)
definiert die
Grenze zwischen zwei Komponenten
beschreibt den Informationsfluss ber
die Grenze
In der Praxis wird in der Regel die
Schnittstelle nur syntaktisch festgelegt, d.h.
ihre Signatur wird definiert.
Semantisch: Jede Methode wird durch

einen Vertrag (Vor- und Nachbedingung)
beschrieben.
Es wird zwischen Export- und Import-

Schnittstellen unterschieden.

Export/Import-Schnittstelle (Interface)
Exportschnittstelle: Welche Methoden werden ber die Schnittstelle zur Verfgung
gestellt?
Importschnittstelle: Welche Methoden werden ber die Schnittstelle aufgerufen?
Achtung:
In den Kontrakten wird Bezug auf den Zustand des Systems gegeben, in dem die
Methode genutzt wird.
Sichtbarer Teil einer Architektur: die APIs

Beispiele fr die Signatur einer Schnittstelle
Als CORBA IDL Interface:
module StockObjects {
struct Quote { string symbol; long at_time; double price; long volume; };
exception IllegalQuoteException{};
interface Stock {
// Returns the current stock quote.
Quote get_quote();
// Sets the current stock quote.
void set_quote(in Quote stock_quote) raises(IllegalQuoteException);
};
};
Als Java Interface:

public interface StockObjects {
//Returns the current stock quote
public Quote getQuote();
//Sets the current stock quote
public void setQuote(Quote stockQuote) throws IllegalQuoteException;
}
+ Definitionen von Quote und IllegalQuoteException.

Kapselung, Schnittstellen- und Datenabstraktion
Eine Komponente umfasst einen Zustandsraum.
Die Schnittstelle beschreibt, wie auf die Zustnde zugegriffen wird.
Damit kapselt eine Komponente Zustnde ber eine Schnittstelle.
Prinzip der Schnittstellen- und Datenabstraktion, Information hiding:

In einem konsequent auf Kapselung ausgerichteten objektorientierten Ansatz wird auf
den Zustand einer Komponente ausschlielich ber die Schnittstelle zugegriffen.
Dann kann die konkrete Darstellung des Zustands der Komponente gendert werden,
ohne dass sich das Verhalten der Komponente ndert.
Die konkrete Wahl und Darstellung (Implementierungsdetails) wird dann fr die
Nutzer der Komponente unerheblich und ist vom Nutzer verborgen.

Design by Contract -
Trennung von Nutzung und Implementierung
Das Prinzip der Schnittstellen- und Datenabstraktion:
Die Schnittstellenspezifikation einer Komponente enthlt alle Informationen, die fr die
Nutzung und als Anforderung fr die Implementierung erforderlich sind (die
Spezifikation wird auch als Vertrag, als Kontrakt, zwischen Nutzer und Implementierer
bezeichnet daher der Name Design by Contract).
Dann kann die Komponente unabhngig von der Nutzung implementiert werden (und
nach Bedarf eine Implementierung durch eine andere ersetzt werden), solange nur der
Kontrakt eingehalten wird.
Dann knnen Systeme entwickelt werden, die ber eine Importschnittstelle eine
Komponente nutzen, unabhngig davon, welche Implementierung gewhlt wird (und
die Entwicklung kann parallel zur Implementierung stattfinden).

Komponentenschnittstellen vs. API
Komponentenschnittstelle: Menge von Methoden
legt die Interaktion und die Informationsflsse ber die Komponentengrenzen fest
detailliert einen Dienst (wohldefiniert und berschaubar)
wird whrend des Architekturentwurfs festgelegt
Application programmers interface (API)

ist die Realisierung einer Komponentenschnittstelle in einer spezifischen
Programmiersprache
wird whrend der Implementierung entwickelt
Die beiden Begriffe werden hufig miteinander verwechselt, lassen sich aber klar
verschiedenen Phasen im Softwareentwicklungsprozess zuordnen.

Schnittstellenklasse fr eine Komponente
Die Schnittstellenklasse fr eine Komponente beschreibt alle Dienste, welche die
Komponente nach auen anbietet:
durch eine Menge von ffentlichen Methoden
kann durch das Entwurfsmuster Fassade realisiert werden

Komposition von Komponenten ber Export- und
Importschnittstelle
Miteinander verbundene Export- und Importschnittstellen mssen syntaktisch kompatibel
sein, d.h.
die Menge der importierten Methoden ist eine Teilmenge der exportierten
die Typen der importierten Methoden sind kompatibel zu den Typen der exportierten
Methoden
StorageCell
Admin

Beispiele fr syntaktische Kompatibilitt & Vertrge
Gegeben folgende Subtyphierarchie:
Betrachten wir nun die folgenden Schnittstellen:

?


StudentFinder subtype PersonFinder

StudentFinder subtype PersonFinder
PersonProcessor subtype StudentProcessor
Subtyp-Beziehung zwischen Schnittstellen abhngig von syntaktischer Kompatibilitt der

Methoden

Syntaktische Kompatibilitt von Methoden
Eine Methode mit Typ
T = [Rtype (Ptype p, ...)]
Ist syntaktisch kompatibel zu einer Methode mit Typ
T = [Rtype (Ptype p, ...)] ,
wenn
T und T gleiche Zahl und Identifikatoren von Parametern in gleicher Reihenfolge
enthalten,
der Typ jedes Parameters in T ein Subtyp des Typs der Parameter in T ist
Ptype subtype Ptype
falls T ein Resultat besitzt auch T ein Resultat besitzt und der Resultattyp von T ein
Subtyp von T ist
Rtype subtype Rtype
Konsequenz: Jeder Aufruf einer Methode vom Typ T ist ein syntaktisch korrekter Aufruf
einer Methode vom Typ T,kurz T subtype T
Hintergrund: Vererbung. Wo T (allgemein) erwartet wird, kann auch T (speziell) stehen.

Kovarianz und Kontravarianz
Verwandtes Problem: Typisierung von Methoden in Unterklassen, Substitutionsprinzip
Spezialisierung entlang der Vererbungsbeziehung: Kovarianz

Spezialisierung entgegen der Vererbungsbeziehung: Kontravarianz
Im Szenario vorher:
Kovarianter Rckgabetyp, kontravariante Argumenttypen
Garantiert statische Typsicherheit
T required: allgemeinerer Rckgabetyp, speziellere Argumenttypen
T provided : speziellerer Rckgabetyp, allgemeinere Argumenttypen
Intuitiv:
Wenn eine Komponente Methode T bentigt, ist ein angebotenes T in Ordnung (kompatibel)
T lsst allgemeinere Argumente zu (die weniger knnen mssen)
T lsst spezielleren Rckgabetyp zu (der mehr knnen darf)
Abhngigkeit von Programmiersprache!

Der Zuschnitt einer Schnittstelle bestimmt die
syntaktische Kompatibilitt
Wie stehen diese beiden Schnittstellen zueinander in Beziehung?

StudentManager.find(String) subtype PersonManager.find(String)

PersonManager.process(Person) subtype StudentManager.process(Person)

StudentManager.find(String) subtype PersonManager.find(String)

PersonManager.process(Person) subtype StudentManager.process(Person)
StudentManager subtype PersonManager und

PersonManager subtype StudentManager

Vertrge
Ein Vertrag definiert auch semantisch zulssige Generalisierungen einer Schnittstelle.
Eine Sub-Schnittstelle darf keinen der Vertrge brechen, die fr ihre Super-Schnittstelle
gelten.
Die Methoden der Sub-Schnittstelle knnen andere Vor- und Nachbedingungen besitzen,
solange diese zu den Vor- und Nachbedingungen der entsprechenden Methoden in der
Super-Schnittstelle kompatibel sind.
Implementierungen der Sub-Schnittstelle knnen berall dort eingesetzt werden, wo

Implementierungen der Super-Schnittstelle erwartet werden.

Semantische Kompatibilitt von Methoden
Definition: Eine Methode
Rtype m (Ptype p, ...)
pre [R ]
post [Q ]
ist semantisch kompatibel zu einer Methode
Rtype m (Ptype p, ...)
pre [R ]
post [Q ]
wenn
die Typen T=[Rtype (Ptype p,...)] und T=[Rtype (Ptype p,...)]
syntaktisch kompatibel sind (T subtype T)
die Vorbedingung R von m die Vorbedingung R von m impliziert
R R
die Nachbedingung Q von m die Nachbedingung Q von m impliziert
Q Q
Konsequenz
Jeder Aufruf der Methode m kann korrekt durch einen Aufruf von m ersetzt werden.

Beispiele fr semantische Kompatibilitt & Vertrge
Die Klasse BetterMath class Math {
erfllt den Vertrag ihrer float sqrt(float x)
Superklasse Math: /** @pre x>0 **/
Die Vorbedingung /** @post abs(sqrt(x)*sqrt(x)-x)<10e-2 */
(@pre) ist weniger strikt.
}
Die Nachbedingung
(@post) ist strikter.
class BetterMath {
float sqrt(float x)
Math.sqrt() ist also
semantisch kompatibel zu /** @pre x>=0 **/
BetterMath.sqrt(). /** @post abs(sqrt(x)*sqrt(x)-x)<10e-5 */
}

Sichten auf Komponenten
Black-Box-Sicht: Nur die Schnittstelle der Komponente nach auen wird angegeben
White-Box-Sicht: Die Realisierung / der interne Aufbau der Komponente wird
betrachtet
User
DataProcessing
User interaction
importData()
Interface Black-Box exportData()
User Interface White-Box public void importData() {

data = file.getData();
Editor User }
Window interaction public void exportData() {
Controller file.storeData(data);
}
Model
Browser

Komposition von Komponenten ber Export- und
Importschnittstelle
Admin
StorageCell

Hierarchische Komponente
User
Admin
StorageCell
DataBase

Methodische Ratschlge fr den Architekturentwurf
Konsequent Kapselung benutzen: Zustnde mglichst abstrakt beschreiben (keine
Implementierungsinformation vorwegnehmen), konsequentes Information Hiding
Beispiel: Bei (einer spteren) Implementierung einer Liste durch eine zweifach
verkettete Liste sollte in der Architektur nur auf die abstrakten Listenoperationen
Bezug genommen werden.
Nur die Methoden und Zustandsinformationen modellieren, die fr die Interaktion von
Bedeutung sind.
Groe Systeme durch Hierarchiebildung beherrschbar machen.
In sich geschlossene, in ihrer Aufgabe in der Architektur anschaulich beschreibbare
Komponenten formen.
Technische und fachliche Informationen trennen und in separaten Komponenten
kapseln.

Architekturentwurf unter Bercksichtigung bereits
vorhandener Komponenten ist eine Herausforderung
Komponenten-basierte Softwareentwicklung
1. Identifikation der fehlenden Komponenten
2. Entscheidung make-or-buy fr die fehlende Komponente
Spezialfall: COTS Commercial-off-the-Shelf

Hier wird in Schritt 2 stets fr eine Kaufkomponente entschieden
Entwurf basiert ausschlielich auf Standardkomponenten

3.1 Motivation
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm

UML als Sprache fr die Architekturdokumentation (1)
2012 spielt UML als Notation eine wichtige Rolle.
Beispiele fr Diagrammtypen, die Architektursichten untersttzen:
Komponentendiagramm (fr logische Struktur) beschreibt

Komponenten
Schnittstellen
Kommunikationsbeziehungen
Interaktionsdiagramm, speziell Sequenzdiagramm (fr logisches Verhalten)
beschreibt
Nachrichten
Kontrollfluss
Verteilungsdiagramm (fr physische Struktur) beschreibt
phys. Gerte und Ausfhrungsumgebungen
Artefakte (welche logische Komponenten manifestieren)

Waren-
wirtschaftssystem
Point Of Sales
Terminal
Fakturierungs-
system

sd Waren verbuchen
W1: Warenwirt F1: Fakturierungs

:Terminal
schaftssystem system
b1:Kassierer
wareRegistrieren ()
getPreis()
getPreis:Preis
warenAusgang()
fakturieren()

<<device>> <<device>>
server :Host pos1 :Host
<<execution Environment>> <<execution Environment>>

:JEE Server :JSE Runtime
<<artifact>> <<artifact>>
jdbc.jar jdbc.jar
<<deploy>> <<deploy>>
<<artifact>> <<artifact>>
WaWi.ear POS.java
<<manifest>> <<manifest>>
Waren Point-of-Sales
wirtschaftssystem Terminal

Grenzen von UML-Diagrammen
Quelle: www.lattix.com
Darstellung einer Architektur durch eine DSM
www.lattix.com
Quelle: www.lattix.com

3.1 Motivation
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm

Der Softwarearchitekt als Plattform-Spezialist
Plattformen (z.B. J2EE und .Net) sind ziemlich komplex
Plattformen bieten Standardlsungen fr wiederkehrende Probleme, unterliegen
jedoch Restriktionen hinsichtlich der Strukturen von Lsung und Problem.
Die Kenntnis dieser Strukturrestriktionen ist lebenswichtig fr den sinnvollen und
erfolgreichen Einsatz von Plattformen Spezialistenwissen tut Not.
Jedoch kann die Konzentration auf eine Plattform die Sicht auf das Problem verndern
(vgl. Maslow):
If the only tool you have is a hammer, you tend to see every problem as a nail.
[ReHa06]

Der Softwarearchitekt als Entwurfsspezialist
Objektorientierter Entwurf stellt eine groe Herausforderung dar: nicht alle Entwickler
sind dazu gleichermaen im Stande
Objektorientierter Entwurf beeinflusst die Eigenschaften eines Systems stark
Spezialisten fr den objektorientierten Entwurf werden als Softwarearchitekten
angesehen
Der Schwerpunkt beim Entwurf liegt auf Methoden und Paradigmen, nicht auf
Technologien und Plattformen.
Die Architekten leisten einen Beitrag auf einem hohen Abstraktionsniveau.
Der Entwurf auf niedrigeren Ebenen wird delegiert.
Softwarearchitekten brauchen ein hohes Ma an Erfahrung im Entwurf, jedoch reicht

diese Erfahrung allein nicht aus, um ein guter Architekt zu werden.
[ReHa06]

Der Softwarearchitekt als Kommunikator (1)
Der Entwurf von Software stellt eine gemeinschaftliche Aktivitt dar.
In greren Entwicklungsteams besteht Arbeitsteilung:
Programm-Level: Programmierer, Entwickler, Datenbankadministratoren
(DBAs), Tester
Gemeinsames Architekturverstndnis
Aufgaben mssen sich berlappen
Realisierung und Anpassung von Komponenten

Technische Fhigkeiten
Softwarearchitektur-Level: Softwarearchitekt, Systemarchitekt

Komponenten- und Schnittstellenspezifikation
Abstraktions- und
Kommunikationsfhigk.
Projektmanagement-Level: Projektmanager / Gruppen- / Abteilungsleiter

Anforderungserhebung: funktional und nicht-funktional
Kostenschtzung, Ressourcenplanung
Projektplanung und -controlling Geschftskenntnis und
soziale Kompetenz
Gruppenkommunikation und -fhrung

Der Softwarearchitekt als Kommunikator (2)
Verschiedene Interessenten beeinflussen den Softwarearchitekten
Management Marketing
Endbenutzer Kunde
Wartungstrupp
Geringe Kosten,
gute Personal- Viele Funktionen,
auslastung! schnelle Entwick- nderbarkeit!
lung, geringe Verhalten,
Kosten, Performanz,
Konkurrenz- Sicherheit,
Niedrige
fhigkeit! Verfgbarkeit,
Kosten,
Benutzbarkeit!
Fertigstellung
gem
Zeitplan!
Softwarearchitekt
[BCK03]
Der Softwarearchitekt als Domnenexperte
Eine zentrale Aufgabe des Softwarearchitekten ist es, den Kunden bei der
Formulierung nicht-funktionaler Anforderungen an das System zu untersttzen.
Der Softwarearchitekt muss ein Domnenexperte sein, um eine Architektur zur Lsung
eines Problems aus der Anwendungsdomne entwerfen zu knnen.
Hufig haben Softwarearchitekten spezialisiertes Wissen ber einzelne
Anwendungsdomnen, welches sie im Laufe frherer Projekte gesammelt haben.
Unglcklicherweise versuchen Projektleiter hufig, nicht-technische Probleme vom

Softwarearchitekten fernzuhalten.

3.1 Motivation
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm

Architekturmuster
Muster
beschreiben erprobte Lsungsideen fr hufig auftretende Entwurfsprobleme.
bestehen aus drei wesentlichen Teilen:
Kontext: Situation, in der ein Problem auftritt
Problem: Das zu lsende Problem
Lsung: Die erprobte Lsung des Problems
Architekturmuster sind verwandt mit Entwurfsmustern:
Architekturmuster zielen auf Architekturentwurf im Grobentwurf und frhen
Feinentwurf (z.B. Client/Server, Model-View-Controller)
Entwurfsmuster zielen auf implementierungsnhere Fragestellungen im
Feinentwurf und Implementierung (z.B. Observer, Singleton, Visitor)
Anwendbar sowohl im Grob- als auch im Feinentwurf (im letzten Fall bergehend in
Entwurfsmuster)

Architekturmuster: Bestandteile
Beispiel: Repository-Muster
Problem:
Mehrere Benutzer mssen auf eine gemeinsame Datenbasis zugreifen und ber
nderungen durch andere Benutzer informiert werden.
Kontext:
Mehrere Benutzer und Schreibzugriff (sonst wre keine Koordinierung notwendig)
Lsung:
Zugriffssteuerung mit Protokollierung und Benachrichtigung
User 1 User 2 User 3
Access and Versioning Control
Repository

Wichtige Architekturmuster
Model-View-Controller (MVC)
Aufteilung einer Anwendung in die Schichten zur Datenhaltung (Model),
Darstellung (View) und Steuerung (Controller)
Schichten-Architektur
Aufteilung einer Anwendung in mehrere Schichten, wobei jede Schicht nur auf
benachbarte Schichten (darber und darunter) zugreifen darf.
Client/Server
2-Schichtenarchitektur, auch Front-End und Back-End fr Client bzw. Server
Strukturelle Entwurfsmuster
Fassade: Einheitliche Schnittstelle fr ein Teilsystem aus mehreren Komponenten
Kompositum: Komponenten, die Instanzen von sich (und abgeleiteten Klassen)
enthalten knnen, z.B. GUI-Fenster

Client/Server-Architektur
Zweischichtenarchitektur
Client
Benutzungsschnittstelle
Zugriff auf Serverdienste
Entkoppelt von Datenhaltung und konkreter Netztechnologie
Server
Datenhaltung
Geschftslogik
Client 1
Server
Client 2

Schichten und Partitionen
Eine Schicht ist ein Systembestandteil, der Dienste fr eine andere Schicht anbietet
und dabei den folgenden Restriktionen unterliegt:
Eine Schicht ist nur von den Diensten von weiter unten liegenden Schichten
abhngig.
Eine Schicht hat keine Kenntnis von hher liegenden Schichten.
Alternativer Begriff: virtuelle Maschine
Eine Schicht kann horizontal in unabhngige Komponenten (Partitionen genannt)

zerlegt werden
Partitionen bieten sich wechselseitig Dienste an
Partitionen sind in der Regel nur schwach gekoppelt

Aufbau eines Systems aus Schichten / virtuellen
Maschinen
Ein System lsst sich als eine bereinanderschichtung von virtuellen Maschinen
betrachten, bei der eine Maschine die primitiven Funktionen der darunter liegenden
Maschinen nutzt.
C1ass1 C1ass2 C1ass3
attr attr attr Virtual Machine 4
op op op
C1assE C1assF
attr attr Virtual Machine 3
op op
C1assC C1assD
op op
Class A C1ass B
op op
Operating System, Libraries Existing System

Strenge vs. offene Schichtenarchitektur
Strenge Schichtenarchitektur Offene Schichtenarchitektur
Jede Schicht (virtuelle Maschine) kann nur Jede Schicht (virtuelle Maschine) kann auf
auf Operationen der unmittelbar darunter Operationen aller darunter liegenden
liegenden zugreifen. zugreifen.
Erhhte Wartbarkeit und Flexibilitt Erhhte Performanz
C1ass1 C1ass2 C1ass3 C1 C1 C1

attr attr attr VM4 attr attr attr VM4
op op op op op op
C1assE C1assF C1 C1
attr attr VM3 attr attr VM3
op op op op
C1assC C1assD C1 C1
op op op op
Class A C1ass B C1 C1
op op op op

3-Schichtenarchitektur
Darstellungsschicht
Benutzungsschnittstelle greift nur ber die Anwendungsschicht auf Daten zu
Benutzungsschnittstelle kann ausgetauscht werden, ohne die Anwendungslogik zu
verndern
Anwendungsschicht
Anwendungslogik, Fachlicher Kern
Datenzugriffsschicht
Kapselt den Zugriff auf die Datenhaltung
Presentation Layer
Application/Business Layer
Data Access Layer

3-Schichtenarchitektur: Beispiel CQ.edit
Darstellungsschicht in UI (UserInterface)
Anwendungslogik (vorwiegend) im Paket edu.tum.cs.cqedit.ui.model
Datenzugriff in Core
Die Schichtentrennung ist in der realen Implementierung von CQ.edit nicht strikt.
Presentation Layer User Interface

Eclipse
UI.model
Application/Business Layer
Data Access Layer Core ConQAT
Data
Storage

Model-View-Controller (MVC)
View
Darstellung von Daten
Entgegennahme von Benutzerbefehlen und Weiterleitung an registrierte Controller
Controller
Verarbeitung von Benutzerbefehlen
Zugriff auf das Modell, Weiterleitung von Daten an Views
Model
Datenhaltung
View 1 View 2 View 3
Controller 1 Controller 2
Model

Model-View-Controller (MVC): Beispiel CQ.edit
Views
Darstellung (Blockdiagramm) edu.tum.cs.cqedit.ui.editor.graphical
Darstellung (Baum) edu.tum.cs.cqedit.ui.editor.outline
Controller
Verteilt ber mehrere Pakete:
Listener-Klassen in
edu.tum.cs.cqedit.ui.model
edu.tum.cs.cqedit.ui.editor
Model edu.tum.cs.cqedit.ui.model
View: Graphical
View: Outline

3.1 Motivation
Architekturentwurf
Prozess
Software-
Rolle architekt
Architektur-
beschreibung
Komponenten-
Artefakte diagramm
Deployment-
diagramm

Softwarearchitekturentwurf: SyCaTool
Das System Cartography Tool (SyCaTool) im berblick:
Werkzeug zur konsistenten Visualisierung von konzeptuellen Systemmodellen
Eclipse-basiert nutzt Technologien des Eclipse Modeling Framework (EMF) und des
Graphical Editor Framework (GEF)
Entwickelt am Lehrstuhl von Prof. Matthes in Kooperation mit der Siemens AG (2005-
2008)
Auszug aus der Anwendungsfallbeschreibung des SyCaTools (nach [Sc06]):

Lade gespeichertes Systemmodell aus Datei
Erzeuge Visualisierung aus einem Systemmodell
Lade gespeicherte Visualisierung aus Datei
Blende Kartenschicht ein / aus

Softwarearchitektur: Mittel und Entwicklungsphasen
Analyse und Grobentwurf:
Erste abstrakte Entwrfe des Datenflusses und
der Zusammenarbeit zwischen Komponenten
Datenflussdiagramme
Grobentwurf:
Festlegung der Systemarchitektur, (grerer) Komponenten und
der Schnittstellen zwischen Komponenten
Blockdiagramme (UML: Komponentendiagramme)
Feinentwurf:
Verfeinerung der Teilsysteme zu programmiersprachlich
darstellbaren Komponenten (z.B. Module, Klassen)
Klassendiagramme (UML), programmiersprachliche
Definitionen

Abstrakte Beschreibung der Datenflsse im SyCaTool
Auensicht Innensicht Core
Darstellung als Bild

Benutzer-
schnittstelle Darstellung mit
Renderer
Positionsinformation
Fordere Liefere Darstel-
Darstellung an lung als Bild
Core
Layouter
Fordere/liefere Fordere/liefer
Schema Daten
Darstellung ohne
Transformer
Positionsinformation
Datenhaltung
Schema Daten

Grobentwurf
Strukturierung des Systems:
Aufteilung in (grere) Teilsysteme / Komponenten
Bercksichtigung externer Komponenten (hier: Teilsystem des Eclipse Frameworks)
Spezifikation der Teilsysteme (Blockdiagramm)

Benutzerschnittstelle: Benutzerinteraktion zur Benutzer- Eclipse
Erstellung von Darstellungen. schnittstelle JFACE
Core: Datenverarbeitung zur Erstellung von
Darstellungen, Generierung und Layout der Eclipse
Darstellungen. Core
GEF
Datenhaltung: Import/Export von Daten in
XML-Dateien.
Daten- Eclipse
haltung EMF

Grobentwurf:
Kriterien fr eine gute Strukturierung des Systems
Hohe Kohsion (Zusammenhalt, Geschlossenheit)
Das System soll in Teile gegliedert werden, die inhaltlich (eng) zusammenpassen.
Beispiel: Die Darstellung und die Geschftslogik sollten in verschiedenen
Komponenten modelliert werden, da voneinander inhaltlich weitgehend
unabhngig.
Niedrige Kopplung (Abhngigkeit):
Einzelne Teilsysteme sollten mglichst unabhngig voneinander sein.
Beispiel: Die Geschftslogik sollte zur Benutzerinteraktion mithilfe mglichst
weniger Methoden auf die Darstellungskomponente zugreifen mssen.
Weitere Eigenschaften:
Korrektheit, Verstndlichkeit, Wiederverwendung, Anpassbarkeit

Feinentwurf
Verfeinerung des Grobentwurfs
Ausgangspunkt: Grobentwurf, Aufteilung in Teilsysteme
Ergebnis: Systemarchitektur auf Ebene der Module/Klassen
Vorgehen:
Schrittweise Modularisierung des Systems in kleinere Komponenten bis zur
Strukturierung in Module/Klassen.
Mgliche Zwischenschritte der Modularisierung:
Pakete (Packages), die mehrere inhaltlich zusammengehrige Klassen enthalten.
Pakete knnen hierarchisch in Teilpakete aufgeteilt werden.
Implementierungsnhere Beschreibungsform
Vervollstndigung/Ergnzung der Aufgaben und Schnittstellen

03 Architekturentwurf

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03 Architekturentwurf

Hochgeladen von

Copyright:

Verfügbare Formate

Fakultt fr Informatik

Technische Universitt Mnchen

Einfhrung in die Softwaretechnik

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 2

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 3

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 4

Beschrieben werden im Besonderen

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 6

The fundamental organization of a system embodied in its components, their relationships

The software architecture of a program or computing system is the structure or structures

The structure of the components of a program/system, their interrelationships, and

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 7

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 8

Architektur aggregiert ggf. rekursiv Komponenten

Wichtig: Eine Architekturbeschreibung muss unterschiedliche Interessen verschiedener

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 17

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 18

Innerhalb dieser Leitplanken werden Architekturentscheidungen getroffen.

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 19

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 20

Entwurf Teilsystem 1 Entwurf Teilsystem 2 Entwurf Teilsystem

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 21

Vollstndigkeit Vollstndigkeit beschreibt, zu welchem Grad ein Baustein mit seinen

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 22

Kohrenz zwischen Klassen (Kohrenz ist eine Form der Kohsion):

Kopplung zwischen Komponente:

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 23

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 24

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 25

schrittweise Verfeinerung la Pascal, C oder Objektorientierte Verfeinerung la Simula, Java

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 26

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 27

Verschiedene Sprachen, Systeme und Modelle verwenden unterschiedliche

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 28

Semantisch: Jede Methode wird durch

Es wird zwischen Export- und Import-

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 29

Sichtbarer Teil einer Architektur: die APIs

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 30

Als Java Interface:

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 31

Prinzip der Schnittstellen- und Datenabstraktion, Information hiding:

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 32

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 33

Application programmers interface (API)

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 34

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 35

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 36

Betrachten wir nun die folgenden Schnittstellen:

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 37

Betrachten wir nun die folgenden Schnittstellen:

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 38

Betrachten wir nun die folgenden Schnittstellen:

StudentFinder subtype PersonFinder

PersonProcessor subtype StudentProcessor

Subtyp-Beziehung zwischen Schnittstellen abhngig von syntaktischer Kompatibilitt der

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 39

Hintergrund: Vererbung. Wo T (allgemein) erwartet wird, kann auch T (speziell) stehen.

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 40

Spezialisierung entlang der Vererbungsbeziehung: Kovarianz

Abhngigkeit von Programmiersprache!

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 41

Pretschner SoSe 2014 - EIST 3 - Architekturentwurf TUM 42