Evaluierung von Softwarearchitekturen

Junius, Andreas

Evaluierung von Softwarearchitekturen

Am Beispiel einer Schach-Community

von Andreas Junius (Autor:in)

Informatik - Software

Zusammenfassung

Inhaltsangabe:Einleitung:
Diese Diplomarbeit entstand im Zusammenhang mit meiner Tätigkeit als freier Programmierer für ein reales Kundenprojekt. Mein Ein-Personen-Betrieb ist auf die Erstellung von Flash-Anwendungen spezialisiert, womit eine grundlegende Architekturentscheidung bereits vom Kunden noch vor der eigentlichen Anfrage getroffen wurde.
Unabhängig von dieser Entscheidung, die ja immer noch revidiert werden könnte, da es zu Flash ja auch Alternativen gibt (Director, Java-Applets usw.), die der Kunde vielleicht nicht kennt, stellen sich jedoch die allgemeinen Probleme der Softwareentwicklung, die gelöst werden müssen.
Problemstellung:
Die Arbeit zeigt am Beispiel einer Schach-Community, wie große Sotwareprojekte geplant und umgesetzt werden können. Dabei werden die verschiedenen Aspekte guter Softwarearchitektur beleuchtet und am praktischen Beispiel ausprobiert, bzw. umgesetzt.
Der Zusammenhang zwischen Softwarearchitektur und Vorgehensmodell wird entsprechend dargestellt. Das Projekt verwendet hauptsächlich objektorientierte Techniken und Methoden.
Verwendete Technologien sind Flash, der Flash Media Server, Java, Servlets, Tomcat und eine PostgreSQL-Datenbank. Die gewählte Modellierungssprache ist UML 2.0. Eine guten Überblick, auch als Einführung in das Thema, bieten die Folien und der Text für das Kolloquium, die als Flash-Dateien verfügbar sind.

Inhaltsverzeichnis:Inhaltsverzeichnis:
VorwortII
Probleme der Softwareentwicklung.II
KomplexitätII
Warenzeichen.III
VerzeichnisIV
InhaltIV
AbbildungenVII
TabellenVIII
CodebeispieleIX
AbkürzungenX
1.Einführung1
1.1Architekturbegriff1
1.2Problemstellung1
1.3Anforderungsbasierte Architektur2
1.4Der Softwarearchitekt2
1.5Leitfaden3
2.Grundlagen und erste Ansätze4
2.1Software als System4
2.2Die Phasenmodelle4
2.2.1Wasserfallmodell4
2.2.2Spiralmodell5
2.2.3V-Modell5
2.2.4Diamant-Modell5
2.2.5Projekt-Modell6
2.3Architekturstrukturen6
2.3.1Client-Server-Modell6
2.3.2n-Tier-Architektur7
2.3.3Rich-Client / Thin-Client-Architektur8
2.3.4Middleware-Architektur9
2.3.5Service-Orientierte Architektur10
2.4Entwurfsmuster12
2.4.1Adapter-Muster13
2.4.2Observer-Muster14
2.4.3Strategy-Muster15
2.4.4Composite-Muster17
2.4.5MVC-Paradigma18
2.5Persistenz21
2.5.1Strukturbruch21
2.5.2Persistenzunabhängigkeit21
2.5.3Persistenzschicht22
2.5.4Modelltransformation22
2.5.5Persistenzframework22
2.6Flash Media […]

Leseprobe

Inhaltsverzeichnis

Andreas Junius

Evaluierung von Softwarearchitekturen

Am Beispiel einer Schach-Community

ISBN-10: 3-8324-9969-5

ISBN-13: 978-3-8324-9969-3

Druck Diplomica® GmbH, Hamburg, 2006

Zugl. Private FernFachhochschule Darmstadt, Darmstadt, Deutschland,

Diplomarbeit, 2006

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

http://www.diplom.de, Hamburg 2006

Printed in Germany

Chess-Freak der Schachserver

Vorwort

Diese Diplomarbeit entstand im Zusammenhang mit meiner Tätigkeit als freier

Programmierer für ein reales Kundenprojekt. Mein Ein-Personen-Betrieb ist auf die

Erstellung von Flash-Anwendungen spezialisiert, womit eine grundlegende

Architekturentscheidung bereits vom Kunden noch vor der eigentlichen Anfrage

getroffen wurde. Unabhängig von dieser Entscheidung, die ja immer noch revidiert

werden könnte, da es zu Flash ja auch Alternativen gibt (Director, Java-Applets

usw.), die der Kunde vielleicht nicht kennt, stellen sich jedoch die allgemeinen

Probleme der Softwareentwicklung, die gelöst werden müssen.

Probleme der Softwareentwicklung

Im allgemeinen arbeiten Computer (bzw. die darauf laufenden Programme) nach

dem sogenannten EVA-Prinzip (Eingabe-Verarbeitung-Ausgabe). D. h. im

Mittelpunkt steht ein Algorithmus, der die Verarbeitung der Eingabedaten abhängig

von deren Wert nach einer bestimmten Vorschrift vornimmt. Ist der verwendete

Algorithmus sehr einfach oder allgemein gut bekannt, so kann dieser oft direkt

implementiert werden. Dies trifft aber äußerst selten zu und so wurde ein Werkzeug

geschaffen, Algorithmen strukturiert zu planen (Struktogramme nach DIN 66261 -

siehe auch die Projektarbeit unter

www.amphitrite.info

). Struktogramme

beschreiben damit lediglich einen bestimmten Algorithmus. Moderne Systeme

bestehen jedoch aus einer Fülle von Algorithmen (Komponenten, Modulen, usw.),

die miteinander auf unterschiedliche Weise interagieren. Struktogramme als sehr

frühes Planungswerkzeug stellen heutzutage nur noch ein ergänzendes Element im

Werkzeugkasten der Softwarearchitektur dar.

Komplexität

Meine bisherigen Softwareentwicklungsprojekte zeichneten sich dadurch aus, daß

mit zunehmenden technischen Möglichkeiten auch die Wünsche der Kunden, bzw.

Anwender stiegen. Die Projekte wurden damit zunehmend komplexer und schwerer

zu handhaben. Künftige Erweiterungswünsche mußten zumindest erahnt und

passende Anschlußmöglichkeiten, bzw. Schnittstellen geschaffen werden. Dazu kam

der Wunsch, zumindest Teile der Software so zu gestalten, daß sie

wiederverwendbar wurden ein Problem, das auch heute noch nicht

zufriedenstellend gelöst ist, obwohl es natürlich eine Menge guter Ansätze in diese

Richtung gibt.

III

Chess-Freak der Schachserver

Kurz: komplexe Softwareprojekte bedürfen umfassender Planung und straffen

Projektmanagements. Softwarearchitektur ist dabei in jedem komplexen System

immer vorhanden, bewußt oder unbewußt, gut geplant oder eben ignoriert ohne

geht es nicht. Eine gute Softwarearchitektur ist demzufolge Voraussetzung für gute

Softwaresysteme.

Mein Wunsch, qualitativ hochwertige, erweiterbare und gut wartbare Software

kostengünstig herzustellen ist ursächlich für die Themenwahl dieser Diplomarbeit.

Warenzeichen

In dieser Arbeit werden eingetragene Warenzeichen, Handelsnamen und

Gebrauchsnamen verwendet. Auch wenn diese nicht als solche gekennzeichnet

sind, gelten die entsprechenden Schutzbestimmungen.

Chess-Freak der Schachserver

Verzeichnis

Inhalt

Vorwort... II

Probleme der Softwareentwicklung ... II

Komplexität ... II

Warenzeichen ...III

Verzeichnis ... IV

Inhalt... IV

Abbildungen... VII

Tabellen ... VIII

Codebeispiele... IX

Abkürzungen... X

Einführung ...1

1.1

Architekturbegriff ...1

1.2

Problemstellung ...1

1.3

Anforderungsbasierte Architektur ...2

1.4

Der Softwarearchitekt...2

1.5

Leitfaden...3

Grundlagen und erste Ansätze...4

2.1

Software als System...4

2.2

Die Phasenmodelle ...4

2.2.1

Wasserfallmodell ...4

2.2.2

Spiralmodell...5

2.2.3

V-Modell ...5

2.2.4

Diamant-Modell ...5

2.2.5

Projekt-Modell ...6

2.3

Architekturstrukturen ...6

2.3.1

Client-Server-Modell ...6

2.3.2

n-Tier-Architektur ...7

2.3.3

Rich-Client / Thin-Client-Architektur...8

2.3.4

Middleware-Architektur...9

2.3.5

Service-Orientierte Architektur ...10

2.4

Entwurfsmuster ...12

2.4.1

Adapter-Muster ...13

2.4.2

Observer-Muster...14

2.4.3

Strategy-Muster ...15

Chess-Freak der Schachserver

2.4.4

Composite-Muster...17

2.4.5

MVC-Paradigma...18

2.5

Persistenz ...21

2.5.1

Strukturbruch...21

2.5.2

Persistenzunabhängigkeit ...21

2.5.3

Persistenzschicht ...22

2.5.4

Modelltransformation ...22

2.5.5

Persistenzframework ...22

2.6

Flash Media Server...25

2.6.1

Funktionsweise...25

2.6.2

Entwicklung ...26

Realisierung und Anwendung...28

3.1

Problematik der Planungstiefe...28

3.2

Projektbeschreibung ...28

3.3

Erste Gedanken ...29

3.4

Modellierung der Anwendungsfälle ...31

3.5

Benutzeroberfläche ...34

3.6

Architekturstruktur...36

3.7

Modellierung der Abläufe...37

3.8

Wahl des Phasenmodells ...39

3.9

Klassenentwurf ...39

3.9.1

Abbildung der Datenobjekte ...40

3.9.2

Anwendungsschicht...43

3.9.3

Benutzeroberfläche ...45

3.9.4

Persistenzmechanismus...46

3.10

Detaillösungen...47

3.10.1

Einbindung einer Zugkontrolle...47

3.10.2

Anbindung von Oberflächenelementen ...52

3.10.3

Übertragung der Datenobjekte vom Client zum Server ...53

3.10.4

Einsatz des Flash Media Server ...56

Resumee und Ausblick...60

4.1

Resumee...60

4.2

Ausblick ...60

Literaturverzeichnis ...62

Bücher ...62

Software...63

Weiterführende Links ...64

Projekt ...64

Chess-Freak der Schachserver

Erklärung ...65

Anhang ...a

Screen-Entwürfe...a

Modellierung ...e

Daten-, bzw. Dateiformate...g

Datenmodellierung ... j

Berechnung des ELO ...v

VII

Chess-Freak der Schachserver

Abbildungen

Abbildung 1 - Der Softwarearchitekt im Spannungsfeld ...2

Abbildung 2 - Client-Server-Modell ...7

Abbildung 3 - Drei-Schicht-Architektur ...7

Abbildung 4 - Schema einer Middleware-Architektur ...9

Abbildung 5 Klassenadapter, UML-Klassendiagramm ...13

Abbildung 6 Objektadapter, UML-Klassendiagramm ...14

Abbildung 7 Observer, UML-Klassendiagramm...15

Abbildung 8 Strategy, UML-Klassendiagramm ...16

Abbildung 9 Composite-Muster, UML-Klassendiagramm ...17

Abbildung 10 MVC-Paradigma im Überblick ...18

Abbildung 11 Persistenzframework, Interface Persistent ...23

Abbildung 12 Persistenzframework, Cache und Slot ...23

Abbildung 13 - Persistenzframework, BrokerFactory ...24

Abbildung 14 - Persistenzframework, Brokerarchitektur...24

Abbildung 15 Persistenzframework, Transaction und ConnectionManager...24

Abbildung 16 Persistenzframework, Beziehungen...25

Abbildung 17 Flash Media Server, Übersicht ...26

Abbildung 18 UML Use-Case Diagramm ...31

Abbildung 19 UML Use-Case Diagramm, Erweiterungen ...33

Abbildung 20 Auswahlmenü mit verschiedenen Elementen ...34

Abbildung 21 Gesamtsicht der Architekturstruktur ...37

Abbildung 22 UML-Aktivitätsdiagramm Nutzerneuregistrierung ...38

Abbildung 23 Brett- und Figurendefinition...41

Abbildung 24 - UML-Klassendiagramm Datenklassen ...43

Abbildung 25 UML-Klassendiagramm Geschäftsprozeß...44

Abbildung 26 UML-Klassendiagramm MVC, Teil 1...45

Abbildung 27 UML-Klassendiagramm MVC, Teil 2...46

Abbildung 28 - Datenbankstruktur ...47

Abbildung 29 UML Klassendiagramm Zugerkennung...49

Abbildung 30 Spielbrettanbindung nach dem MVC-Paradigma...52

Abbildung 31 Datenübertragung Gateway-Architektur ...54

Abbildung 32 Aktivitätsdiagramm Beendigung einer Partie ...57

Abbildung 33 Verteilungsdiagramm Remis-Anfrage ...58

VIII

Chess-Freak der Schachserver

Tabellen

Tabelle 1 - Vergleichskriterien Thin-Client/Rich-Client ...8

Tabelle 2 Variablen Cast ...55

Chess-Freak der Schachserver

Codebeispiele

Codefragment 1 Clientseitiger Aufbau einer netConnection ...27

Codefragment 2 Serverseitiges Gerüst für eine FMS-Applikation ...27

Codefragment 3 - Interface ChessController, Actionscript 2.0...50

Codefragment 4 Zugerkennung SimpleController, Auszug ...52

Codefragment 5 Interface IBoard (Schnittstelle eines View) ...53

Codefragment 6 HTTP Anfragestring (Body) ...55

Codefragment 7 HTTP Serverantwort (Body) ...55

Codefragment 8 Remis-Anfrage FMS, serverseitig, Server-Side Actionscript ...59

Codefragment 9 Remis-Anfrage FMS, serverseitig, Actionscript 2.0 ...59

Chess-Freak der Schachserver

Abkürzungen

AJAX

Asynchron Javascript und XML

AMF

Action Message Format

API

Application Programming Interface

CGI

Common Gateway Interface

CORBA

Common Object Request Broker Architecture

DBMS

Database Management System

DCOM

Distributed Component Object Model

DDL

Data Description Language

ELO-Zahl

Keine Abkürzung, sondern nach dem Erfinder (Arpad Emrick Elo)

benannter Leistungskennwert für Schachspieler

ERD

Entity Relationship Diagram

FCS

Flash Communication Server

FIDE

Fédération Internationale des Échecs, Weltschachbund

FMS

Flash Media Server

GoF

Gang-Of-Four (Erich Gamma und Kollegen, Design Patterns)

HTML

Hypertext Mark-up Language

HTTP

Hypertext Transfer Protocol

IDE

Integrated Development Environment

JDK

Java Developer Kit

J2EE

Java 2 Platform, Enterprise Edition

J2SE

Java 2 Platform, Standard Edition

JRE

Java Runtime Environment

MVC

Model-View-Controller

.NET

Laufzeitumgebung von Microsoft, ähnlich Java

OID

Object Identifier

OO-DBMS

Object Oriented Database Management System

O/R-Mapping Object-Relational Mapping

OO-RPC

Object Oriented Remote Procedure Call

PDA

Personal Digital Assistant

PGN

Portable Game Notation

R-DBMS

Relational Database Management System

RMI

Remote Method Invocation

RPC

Remote Procedure Call

RTMP

Real-Time Messaging Protocol

RTMPS

Real-Time Messaging Protocol, Tunnelling Using SSL

RTMPT

Real-Time Messaging Protocol, Tunnelling

SQL

Structured Query Language

Chess-Freak der Schachserver

SOA

Service Oriented Architecture

UML

Unified Modelling Language

UTF8

8-bit Unicode Transformation Format

XML

Extensible Mark-up Language

Chess-Freak der Schachserver

Einführung

1.1

Architekturbegriff

Laut deutschem Duden ist Architektur der kunstgerechte Aufbau und die

künstlerische Gestaltung von Bauwerken. Im Oxford Advanced Learner's Dictionary

findet sich folgende Definition:

the art and study of designing buildings

the design or style of a building or buildings

the design and structure of a computer system

Die klassische Architektur in dieser Definition eignet sich also nicht unmittelbar, um

Softwarearchitektur daraus abzuleiten. Erweitert man jedoch die Definition um die

zur Erstellung von Bauten notwendige Werkplanung (Tragwerk, Installation,

Gestaltung, usw.), so werden die Parallelen offensichtlich, denn nun ist auch die

Struktur eines Bauwerks enthalten. Softwarearchitektur umfaßt nach obiger

Definition Design und Struktur eines Computer (Software-) Systems.

Softwarearchitektur ist umfassend und verfolgt einen holistischen Ansatz beim

Entwurf. Eine gute Definition lautet ,,Die Systemarchitektur eines Systems

beschreibt dessen Struktur respektive Strukturen, dessen Bausteine (Software- und

Hardware-Bausteine), sowie deren sichtbaren Eigenschaften und Beziehungen

zueinander."

(Vogel, 2005, S. 48). Ausdrücklich nicht enthalten ist hier die innere

Sicht der jeweiligen Bausteine ein wichtiges Mittel der Komplexitätsreduzierung.

1.2

Problemstellung

Während Phasenkonzepte den Entwicklungszyklus einer Anwendung strukturieren,

um eine effiziente und ökonomische Softwareentwicklung zu ermöglichen, befaßt

sich Softwarearchitektur mit der Strukturierung des Systems an sich. Die

Architektur basiert dabei auf unterschiedlichen Sichten, um dem jeweiligen

Einsatzzweck gerecht zu werden. Beispiele sind hier die Sicht auf das

Gesamtsystem (Architektur-Struktur), die Außensicht auf das System

(Anwenderschnittstelle) oder die Innensicht des Systems (Komponenten,

Schnittstellen, usw.). Je nach Sicht sollen entsprechende Ziele erreicht werden, als

da wären:

Vogel, Oliver; Arnold, Ingo; Chugtai, Arif; Ihler, Edmund; Mehlig, Uwe; Neumann, Thomas;

Völter, Markus; Zdun, Uwe: Software-Architektur, Grundlagen Konzepte Praxis, Spektrum

Akademischer Verlag (Hg.), ISBN 3-8274-1534-9, 1.Auflage, München, 2005.

Chess-Freak der Schachserver

Optimale Zusammenstellung des Systems den Anforderungen entsprechend.

Bewältigung der inhärenten Komplexität eines Systems.

Sicherstellung der geforderten Qualität in bezug auf Verfügbarkeit,

Leistungsverhalten, Bedienbarkeit und Sicherheit.

Unterstützung von Wiederverwendbarkeit.

Reduzierung des Wartungsaufwands für ein System.

Sicherstellen von weitgehender Plattformunabhängigkeit (Portierbarkeit).

Parallelisierung der Implementierungsarbeit.

1.3

Anforderungsbasierte Architektur

Die Architektur wird aus den Anforderungen entwickelt, die zu Beginn definiert

werden oder die sich im Laufe der Zeit ergeben. Die Anforderungen ergeben sich

aus den Fähigkeiten, die das System aufweisen soll. Selbstverständlich gilt für die

Anforderungen, daß sie korrekt, machbar, eindeutig und überprüfbar sind, um die

Qualität der resultierenden Architektur meßbar zu machen.

1.4

Der Softwarearchitekt

Der Softwarearchitekt spielt eine zentrale Rolle im Spannungsfeld Auftraggeber

Anwender Designer Entwickler. Dementsprechend spielt er eine Reihe von

Rollen mit unterschiedlichen Anforderungen, z.B. Systemgestalter, Problemlöser,

Entscheider, Visionär, usw..

Abbildung 1 - Der Softwarearchitekt im Spannungsfeld

Chess-Freak der Schachserver

Um diese Rollen adäquat ausfüllen zu können, ist viel Wissen (Sozialkompetenz,

Geschäftswissen, Architekturwissen, allgemeines und technisches IT-Wissen,

rechtliche Grundkenntnisse) und eine Menge Erfahrung nötig.

Elementare Architektur-Fähigkeiten sind:

Erstellen eines Business-, bzw. Anwendungs-Falls

Verstehen der Anforderungen

Entwerfen der Architektur

Kommunizieren der Architektur

Umsetzen der Architektur

1.5

Leitfaden

Diese Diplomarbeit beinhaltet im ersten Teil die allgemeinen theoretischen

Grundlagen der Softwareentwicklung und zeigt anschließend im zweiten Teil die

Anwendung der erarbeiteten Grundlagen auf. Das Kapitel Grundlagen und erste

Ansätze führt in die Problematik der Softwareentwicklung ein. Software als System

zeigt kurz, was unter dem Begriff System in diesem Zusammenhang zu verstehen

ist und welche Probleme dabei bearbeitet werden. Die Phasenmodelle strukturieren

den Ablauf der Softwareentwicklung. Einige dieser Modelle werden hier kurz

vorgestellt mit dem Ziel einen Vergleich anstellen und eine Entscheidung fällen zu

können. Architektur-Strukturen führt in die verschiedenen Modelle aus der Sicht der

Gesamtarchitektur ein. Entwurfsmuster befassen sich mit erfolgreichen, gut

dokumentierten Lösungen für bestimmte Problemstellungen. Persistenz bedeutet

die Speicherung von Daten aller Art auf dauerhaften Datenträgern, auch bei

Nutzung von Datenbanken.

Im Kapitel Realisierung und Anwendung wird das Projekt Chess-Freak geplant und

implementiert. Dabei lege ich den Fokus auf einige ausgewählte Problemstellungen,

zum einen die Projektplanung und den Architekturentwurf betreffend, zum anderen

ausgewählte technische Probleme betreffend. Das Resultat dieser Bemühungen wird

im Resümee bewertet. Einzelheiten der Implementierung und weitergehende

Informationen finden Sie im Anhang.

Chess-Freak der Schachserver

Grundlagen und erste Ansätze

2.1

Software als System

Ganz allgemein ist ein System ein aus mehreren Teilen zusammengesetztes und

gegliedertes Ganzes. Ein Softwaresystem besteht dabei aus Elementen, die

ebenfalls aus Software bestehen. Ein solches System kann außerdem aus kleineren

(Sub-) Systemen hierarchisch zusammengesetzt werden. Jedes System hat eine

Grenze, die es von seiner Umwelt separiert. Ein System dient immer der Erreichung

eines bestimmten Ziels, dabei interagiert es mit seiner Umwelt über entsprechende

Schnittstellen. Die innere Komplexität eines Systems oder Subsystems bleibt dem

Nutzer hinter der Schnittstelle verborgen nicht die Implementierung, sondern nur

die Eigenschaften, bzw. das Verhalten werden dadurch bekannt.

Der Sinn eines Systems ist es, Eigenschaften und Verhalten bereitzustellen, die die

Summe der Einzelteile nicht haben, die sogenannte Emergenz (von lateinisch

emergere: auftauchen, hervorkommen, sich zeigen) von Systemen (,,Das Ganze ist

mehr als die Summe seiner Teile"). Architektonisches Denken ist Denken in

Systemen. Dabei werden die Systembausteine sowie deren Zusammenspiel im

System betrachtet und Aussagen darüber getroffen, wie die Architektur die

Anforderungen an das System unterstützt.

2.2

Die Phasenmodelle

Phasenmodelle sollen den Entwicklungszyklus einer Anwendung strukturieren und

die systematische Planung unterstützen. Ziel ist eine möglichst ökonomische

Softwareentwicklung. Viele Phasenmodelle enthalten außerdem Iterationen und

Parallelisierungen, durch die bestimmte Fortschrittsstufen wiederholt verbessert

und einzelne Arbeitspakete auf ein Team verteilt werden können.

Architekturstruktur und Phasenmodell hängen voneinander ab. Die erforderliche

Architekturstruktur zeichnet sich normalerweise in der sehr frühen Phase der ersten

Systemanalyse ab. Das gewählte Phasenmodell soll die erforderliche

Architekturstruktur bestmöglich unterstützen. Architektur und Anforderungen einer

Multimediaanwendung legen daher z.B. die Nutzung des Diamantmodells als

geeignetes Phasenmodell nahe, da dieses Modell zusätzlich die Verwaltung knapper

technischer Ressourcen beinhaltet.

2.2.1

Wasserfallmodell

Das klassische Wasserfallmodell ist ein lineares Phasenmodell, d.h. die einzelnen

Phasen werden streng sequentiell abgearbeitet, wobei Rückkopplungen

unerwünscht sind. Der Vorteil dieses Modells ist seine Einfachheit und leichte

Chess-Freak der Schachserver

Planbarkeit. Die Nachteile sind aber leider sehr schwerwiegend: bedingt durch den

linearen Verlauf werden Fehler erst sehr spät entdeckt und der Anwender bekommt

das Produkt ebenfalls erst zu einem sehr späten Zeitpunkt zu sehen. Kommen dann

auch noch Änderungs- oder Ergänzungswünsche auf, entstehen die unerwünschten

Rückkopplungen, unter Umständen bis hin zur Spezifikationsphase.

2.2.2

Spiralmodell

Das Spiralmodell teilt die Phasen in kleinere Teilphasen auf. Dadurch können alle

Phasen mehrfach durchlaufen werden und es werden zu einem sehr frühen

Zeitpunkt Teile des Systems verfügbar. Die Anwender, bzw. der Kunde haben so

die Möglichkeit die Entwicklung des Systems mitzuverfolgen und können bei

Fehlentwicklungen rechtzeitig gegensteuern. Nachteilig ist bei diesem Modell die

schlechte zeitliche Planbarkeit vor allem der Kunde kann durch massive

Änderungs- bzw. Erweiterungswünsche den Entwicklungsaufwand ins Unermeßliche

steigern und damit den Budgetrahmen sprengen. Ein Problem ergibt sich auch aus

der Tatsache, daß einige Kunden oft ein fehlerhaftes System nicht von einem

unfertigen, bzw. teilimplementierten System unterscheiden können. Bei einer

negativen Sichtweise des Kunden oder der Anwender kann dies zum Scheitern

eines Softwareentwicklungsprojektes führen.

2.2.3

V-Modell

Das V-Modell (Vorgehensmodell) ist ein lineares System aus sieben Phasen, deren

Gliederung man sich v-förmig vorstellen kann. Es handelt sich um das Modell des

Bundes und wird daher vor allem in Verwaltungen und Behörden eingesetzt. Vor-

und Nachteile sind analog zum Wasserfallmodell zu sehen, bedingt durch den

gleichen linearen Ablauf.

2.2.4

Diamant-Modell

Für die Erstellung von Multimedia-Anwendungen eignet sich das Diamantmodell,

dessen Planungs- und Entwicklungsphasen an den drei Achsen ,,Zeit", ,,Personal"

und ,,technische Ressourcen" ausgerichtet sind. Dabei werden die Produktion der

einzelnen Komponenten (Sounddesign, Animationen, Video, Bilder, Layout,

Programmierung) auf entsprechend spezialisierte Teams übertragen und das

,,Gesamtsystem" wird vom (kleinen) Kernteam zusammengesetzt. Begrenzte

technische Ressourcen werden dabei auf der entsprechenden Dimension des

Diamantmodells ebenso berücksichtigt. Vorteil dieses Modells ist die starke

Parallelisierung der Projektschritte vor allem in der Implementierungsphase.

Chess-Freak der Schachserver

2.2.5

Projekt-Modell

Das Projekt-Modell der Firma sd&m ist ein speziell für Großprojekte entworfenes

Modell, das neben den Phasen noch Stufen, Iterationen und Verzahnungen enthält.

Die Grundstruktur besteht dabei aus den Phasen Studie, Systemspezifikation,

Systemkonstruktion, Implementierung, Integration und Einführung, sowie Wartung.

Das System wird dabei noch in Stufen (sogenannte Releases) unterteilt, die die

Kernphasen Spezifikation bis Integration und Einführung beinhalten. Das Ergebnis

ist jeweils ein funktionierendes (Teil-) System.

Iteration in diesem Zusammenhang meint das methodische Wiederholen der

Projektphasen innerhalb einer Stufe in kurzen Abständen. Ziele sind die

evolutionäre Entwicklung und die beschleunigte Projektdurchführung durch parallel

arbeitende Teams pro Iterationsschritt.

Der Begriff Verzahnung bezeichnet die parallele Bearbeitung aufeinanderfolgender

Phasen. So ist es z.B. möglich mit der technischen Konstruktion zu beginnen,

obwohl die Spezifikation noch nicht vollständig fertiggestellt ist.

2.3

Architekturstrukturen

System-Architektur verfolgt einen holistischen Ansatz, d.h. das Gesamtsystem wird

den Anforderungen entsprechend geplant, wobei die innere Architektursicht der

Komponenten und Bauteile nicht berücksichtigt wird (so kann die Architektur der

Komponenten unabhängig entworfen werden, wodurch die dem System inhärente

Komplexität reduziert wird). Dabei kommen Prinzipien, grundlegende Konzepte,

Muster und Referenz-Architekturen als Architektur-Mittel zum Einsatz.

Prinzipien beschreiben grundlegende Voraussetzungen für gute Software-

Architektur, etwa das ,Separation-Of-Concerns'-Prinzip, welches besagt, daß die

Verantwortlichkeiten von Softwarebausteinen klar getrennt werden sollen. Muster

hingegen beschreiben bewährte Architekturlösungen für ganz bestimmte

Problemstellungen. Architektur-Strukturen setzen die o.g. Architektur-Mittel in

einem größeren Kontext ein und helfen so, schneller zu einer der Aufgabenstellung

angemessenen Lösung zu kommen. Einige bekannte Architektur-Strukturen werden

nachfolgend vorgestellt.

2.3.1

Client-Server-Modell

Das Client-Server-Modell basiert auf einem einfachen Anfrage-/Antwort-Schema.

Dabei setzt der Client eine Anfrage an den Server ab und erhält von diesem

anschließend eine Antwort. Die Ressourcen werden dabei vom Server zentral

verwaltet, aufgeteilt und zur Verfügung gestellt. Dieses Modell funktioniert sowohl

in kleineren als auch in größeren Kontexten, d.h. von entsprechenden, einfachen

Chess-Freak der Schachserver

Prozessen bis hin zu ganzen Netzwerken, die als Client eines Rechenzentrums

wirken können.

Abbildung 2 - Client-Server-Modell

Beim Client-Server-Modell handelt es sich um eine 2-Schicht-Architektur. Ein

Beispiel dafür wäre eine Benutzerschnittstelle auf einem Clientrechner und ein

Datenbankmanagementsystem (DBMS) auf einem Server. Eine solche Anwendung

gerät bei steigenden Nutzerzahlen (bzw. vielen konkurrierenden Clientzugriffen)

jedoch schnell an ihre Grenzen. Außerdem sind solche Systeme noch stark

aneinander gebunden. Dadurch erfordert ein Wechsel des Datenbank-

Management-Systems unter Umständen aufwendige Anpassungsarbeiten an der

Clientsoftware.

2.3.2

n-Tier-Architektur

Das genannte Problem läßt sich mit einer 3-Schicht-Architektur lösen. Dabei wird

eine Zwischenschicht eingeführt, die zentrale Teile der Applikationslogik enthalten

kann und auch Queuing oder Priorisierung übernimmt.

Abbildung 3 - Drei-Schicht-Architektur

Chess-Freak der Schachserver

Vorteil ist eine Steigerung der Performance bei hohen Zugriffszahlen und eine

Erhöhung der Flexibilität.

2-Schicht-Architektur und 3-Schicht-Architektur sind häufige Spezialfälle von n-

Schicht-Architekturen. Höherschichtige Architekturen ergeben sich durch Einfügen

weiterer Schichten, beispielsweise einer Autorisierungsschicht oder Schichten zur

Lastverteilung, sowie durch hintereinanderschalten mehrerer mehrschichtiger

Anwendungen.

2.3.3

Rich-Client / Thin-Client-Architektur

Eine zentrale Frage beim Entwurf von Client-Server-Architekturen ist die Frage, wie

die Funktionalität zwischen Client und Server aufgeteilt werden soll. Mit den

Begriffen Rich-Client und Thin-Client werden, in Reinform angewendet, zwei

Extreme beschrieben:

Ein Thin-Client ist ein Programm ohne eigene Funktionalität. Die

Funktionalität liegt allein am Server, wodurch der Thin-Client vom Server

vollkommen abhängig ist, d.h. er ist ohne Server nicht funktionsfähig. Ein

Beispiel hierfür wäre ein einfacher Terminal oder eine File-Sharing-

Anwendung.

Ein Rich-Client ist eine vollwertige Anwendung, die Daten am Server bei

Bedarf abruft und autark verarbeitet. Die Abhängigkeit vom Server ist hier

wesentlich geringer, als beim Thin-Client. Oft werden Rich-Clients so

entworfen, daß sie ihre Daten lokal speichern und nur bei bestehender

Netzverbindung synchronisieren.

In der Praxis sind diese Reinformen eher selten anzutreffen, meist kommt es zu

Kompromissen zwischen diesen Extremen. Dabei wird man versuchen, eine Balance

zwischen den Anforderungen an Performance, Netzbelastung, Serverauslastung,

usw. zu finden. Wichtige Kriterien dafür sind:

Thin-Client

Rich-Client

Serverbelastung

hoch

niedrig

Netzbelastung

hoch

niedrig

Performance

Abhängig von der zu übertragenden Datenmenge

Netzwerkabhängigkeit

hoch

niedrig

Wartungsaufwand

niedrig

hoch

Tabelle 1 - Vergleichskriterien Thin-Client/Rich-Client

Chess-Freak der Schachserver

Bekannte Thin-Clients sind etwa der Web-Browser als Thin-Client für einen

Applikationsserver oder die Remote-Konsole von Windows zur Steuerung entfernter

Computer. Ein bekannter Rich-Client hingegen ist Eclipse3

(Eclipse Platform, 20.

April 2006, der automatische Updates und eine Plug-In-Verwaltung beinhaltet,

sonst aber alle Eigenschaften einer klassischen Desktop-Anwendung aufweist.

2.3.4

Middleware-Architektur

Middleware, zu deutsch Verbindungssoftware, soll bei der Lösung des Problems, die

unterschiedlichen Bausteine verteilter Systeme zu verbinden, helfen. Verteilte

Systeme stellen andere Anforderungen an die Entwickler, als nicht verteilte

Systeme. Kommunikations-Middleware soll dem Entwickler dabei helfen, die

Anforderungen zu erfüllen ohne dabei bis auf die Ebene der Betriebssystem-API

vordringen zu müssen.

Es handelt sich dabei um eine zusätzliche Softwareschicht, über die Client und

Server verbunden werden können und die die darunterliegenden Schichten von

Netzwerk und Betriebssystem verdeckt.

Abbildung 4 - Schema einer Middleware-Architektur

Middleware soll dabei die typischen Anforderungen an verteilte Software, die sich

aus der unsicheren Datenübertragung und schlecht vorhersagbaren Zuständen

ergeben, erfüllen helfen. Hier wären zu nennen:

Eclipse Platform,

http://www.eclipse.org/

, 20. April 2006

Chess-Freak der Schachserver

Latenz des Netzwerks: längere Antwort-, bzw. Reaktionszeiten aus verteilten

Aufrufen.

Vorhersagbarkeit: Aufrufzeiten lassen sich nicht vorhersagen, da Latenz und

mögliche Ausfälle dies nicht ermöglichen.

Nebenläufigkeit: in verteilten Systemen ist echte Nebenläufigkeit (anders als

in Ein-Prozessor-Systemen) möglich, was bereits in der Architektur

berücksichtigt werden muß.

Skalierbarkeit: die Anzahl der Clientzugriffe pro Zeiteinheit, bzw. deren

Verteilung ist schwer vorherzusagen. Die Architektur sollte dafür sorgen, daß

das Gesamtsystem skaliert, bzw. entsprechende Möglichkeiten dafür

vorhanden sind.

Teilweiser Systemausfall: in einem verteilten System können einzelne Teile

ausfallen, während andere Teile weiterhin einwandfrei funktionieren. Das

Gesamtsystem sollte mit solchen Ausfällen umgehen können.

Heutzutage gibt es eine Reihe von Verteilungsstilen, auf denen die meisten

Middleware-Systeme basieren:

Remote Procedure Call-Systeme (RCP), auch in objektorientierten Varianten

(OO-RCP). Als bekannte Systeme sind hier zu nennen: CORBA, RMI, DCOM.

Messaging-Systeme, die Anfragen und Antworten in

Nachrichtenwarteschlangen zwischenspeichern.

Shared-Repository, gemeinsamer Speicher, auf den die Clients lesend und

schreibend zugreifen können.

Streaming-Systeme, die den kontinuierlichen Datenaustausch in Form von

Datenströmen ermöglichen.

2.3.5

Service-Orientierte Architektur

Serviceorientierte Architektur (SOA) soll Middleware so nutzen, daß lose

gekoppelte, verteilte Services möglich werden. Dabei steht die Geschäftlogik im

Vordergrund, während die Kommunikation technologieneutral und standardisiert

abläuft. Bei diesem Konzept werden fachliche Dienste und Funktionalitäten in Form

von Services bereitgehalten. Der Service kann (teilweise auch anonym) über eine

standardisierte Schnittstelle in Anspruch genommen werden.

Beispiele für den Einsatz von Services wären die Verbindung der IT-Infrastrukturen

zweier Unternehmen (etwa bei Fusionen) oder die Verbindung unterschiedlicher

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2006
ISBN (eBook): 9783832499693
ISBN (Paperback): 9783838699691
DOI: 10.3239/9783832499693
Dateigröße: 2.4 MB
Sprache: Deutsch
Institution / Hochschule: Private FernFachhochschule Darmstadt; Standort Pfungstadt – Informatik
Erscheinungsdatum: 2006 (November)
Note: 1,3
Schlagworte: softwaretechnik architekturmuster softwaredesign flash media phasenmodell

Autor

Andreas Junius (Autor:in)