Software-Systemstrukturen - Userpage - Freie Universität Berlin

Software Engineering 

Software – Systemstrukturen (Architekturansätze) 

Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur 

erstellt. Darüber hinaus finden sich ausgewählte Beispiele zur Softwareentwicklung 

aus dem Bereich der Telekommunikation. 

28.09.2008 Prof. Dr. Andreas Schmietendorf 1

Inhaltsübersicht 

§ Grundlegende Systemstrukturen 

§ Komponentenarchitekturen 

§ Client/Service Architekturen 

§ Peer-to-Peer-Architekturen 


Grundlegende Systemstrukturen 


§ Es werden grundlegende Architekturstrukturen, die in vielen 

Systemen zum Einsatz kommen, vorgestellt. 

§ Die ineffizienteste Form einer Architektur ist ein Monolith, hier ist 

das gesamte System in einem Systembaustein zusammengefasst. 

§ Ein Monolith kann die vorgestellten Prinzipien einer SW-Architektur 

so gut wie nie umsetzen. 

Einleitung 

§ Die folgende Übersicht bietet einen Überblick über wichtige 

Vertreter für Architekturstrukturen in der heutigen Praxis. 


Zentralisierung vs. Dezentralisierung 

§ Grundlegende Frage beim Entwurf einer Architektur: 

- Alle Aspekte in einem Systembaustein bündeln (Zentralisierung) 

- oder diese auf mehrere Bausteine verteilen (Dezentralisierung). 

§ Ansätze für eine Verteilung mit Bezug auf: 

- Rechnersysteme und Prozessoren, 

- Prozesse (z.B. zum Zweck der Lastverteilung), 

- Geräte (z.B. Drucker), 

- Daten (z.B. verteiltes Dateisystem), 

- Funktionen (z.B. Namensdienst). 


Zentralisierung vs. Dezentralisierung 

§ Vorteile der Dezentralisierung: 

- niedrigere Hardwarekosten (zentraler leistungsfähiger Rechner teuer), 

- Flexibilität gegenüber Veränderungen (Lokalisierung, Ausfälle etc.), 

- einfachere aufgabenorientierte Strukturierung des Systems. 

§ Vorteile der Zentralisierung: 

- einfachere Umsetzung von Daten- und IT-Sicherheit, 

- hohe Verfügbarkeit, 

- einfachere Auslieferung neuer oder aktualisierter Systembausteine, 

- als Konsequenz niedrigere Betreuungskosten. 


Übersicht zu Architekturansätzen 

§ Komponentenarchitekturen 

§ Client/Server Architekturparadigma 

§ Peer-to-Peer Architekturen 

§ Middlewarearchitekturen 

§ Aspektorientierte Softwareentwicklung 

§ Modeldriven Architecture (MDA) 

§ Serviceorientierte Architekturen 


Komponentenarchitekturen 


§ Komponenten sind wiederverwendbare, in sich geschlossene 

Bausteine eines SW-Systems. 

§ Komponentenbegriff nach Szyperski: 

„Eine SW-Komponente ist ein wiederverwendbares Stück Software, 

das eine wohldefinierte Schnittstelle hat, in nicht vorher geplanten 

Kontexten eingesetzt werden kann und auch von Dritten komponiert 

werden kann.“ 


Quelle: Szyperski, Clemens: Component Software – Beyond Object-Orientied Programming. 

Addison-Wesley, 1998 



§ Vielseitige Verwendung des Komponentenbegriffs wie z.B.: 

- Microsofts ActiveX Controls 

- JEE Enterprise Java Beans 

hier Betrachtung von Komponentenplattformen (z.B. EJB). 

§ Trennung von fachlichen und technischen Belangen (Verteilung, 

Sicherheit, Persistenz, Transaktionen, Nebenläufigkeit und 

Ressourcenmanagement). 

§ Es wird zwischen einem Container und den dort enthaltenen 

Komponenten unterschieden. Die fachlichen Anforderungen werden 

durch die Komponenten erbracht, die technischen Anforderungen 

durch den Komponentencontainer. 


Client 


 

 

 

Component Container 

 

Session Component 

 

Service Component 

 

Entity Component 

 

Entity Component 

 

 

Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin – Fachbereich II 

 

Legacy System 

 

Database System 


Client/Server Architekturen 


Client-Server-Struktur 


Vorteile: 

Client-Server-Struktur 

§ Verwendung hoch spezialisierter Serversysteme 

§ Vereinfachung administrativer Aufgaben 

§ Zentrale Zugriffskontrolle 

§ Gute Verwendbarkeit im statischen Prozesskontext 

Nachteile: 

§ Server ggf. als „Flaschenhals“ bzw. „Single Point of Failure“ 

§ Server bietet gezielten Angriffspunkt (Bedrohung) 

§ Schwierig anpassbar an sich dynamisch verändernde Umgebungen 

§ Strikte Trennung zwischen Produzenten und Konsumenten 


Rich Clients vs. Thin Clients 

§ Zentrale Frage beim Entwurf einer Client-/Server-Architektur ist die 

Aufteilung der Funktionalität zwischen Client und Server. 

§ Das frühere Mainframe-Modell basierte auf Thin-Clients 

§ PCs und Filesharing-Konzept ebneten den Weg zu Rich-Clients: 

Berechnungen werden nur noch auf dem PC ausgeführt. 

§ Vorteil Thin-Clients: 

- Einfachere Wartung und Auslieferung von Software (nur am Server!) 

§ Vorteile Rich-Clients: 

- Weniger starke Belastung des Servers 

- Höhere Performanz beim Nutzer (Dauer des Netzzugriffs) 

- Geringere Abhängigkeit von der Funktionsfähigkeit des Netzwerk 

- Keine Einschränkungen bei Gestaltung der Nutzeroberfläche 


Schichtenarchitekturen mit 

Rich- und Thin-Clients 

Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin – Fachbereich II 


Peer to Peer Architekturen 


P2P-Anwendungsbereiche 

§ Content Sharing –Nutzung verteilter Speicherkapazitäten 

Musik- und Video-Tauschbörsen 

Bespiele: Napster, Gnutella, Flickr, Youtube 

§ Social- & Business-Networks –Interessensvereinigungen 

Kontaktbörsen, Publikationen, Veranstaltungen 

Beispiele: XING, BPM-Netzwerk, stayFriends; studivz 

§ Virtual Universities –Lern- und Lehrplattformen 

Virtuelle Klassenräume, Diskussionsforen, Podcasts 

Beispiele: BlackBoard, ILIAS, CLIX (bei etlichen Hochschulen) 


P2P-Anwendungsbereiche 

§ Distributed Computing –Nutzung verteilter Rechenkapazitäten 

Aufteilung eines rechenaufwändigen Problems 

Bespiele: SETI@home-Projekt, Cancer Research Project 

§ Collaboration and Communication –Austausch von Nachrichten 

Instant-Messaging-Programme 

Beispiele: ICQ - „I seek you“, Ad-hoc-Netzwerke – z.B. Mobiltelefone 

§ Web 2.0 Applications –Mitmach Web & Online-Anwendungen 

Anwender generierte Inhalte im Web (always beta) 

Beispiel: BLOGS, Wikis, Google Maps, Google Earth, Skype 


Hybride Struktur 


Hybride Struktur 

Mischform aus Client/Server-Ansätzen und P2P-Struktur 

(auch als Super-Peer-Netzwerk bezeichnet) 

§ Vorteile: 

- Zentraler Dienst zur Referenzierung von z.B. Daten der Peers 

- Super-Peer als Gateway zum Netzwerk 

- Super-Peers können ohne „normale“ Peers arbeiten 

- Möglichkeiten zur Bildung von Rechnerfarmen 

• Möglichkeiten zur Leistungssteigerung 

• Etablierung geschützter Bereiche z.B. zentrale Datenhaltung 

- Vereinfachtes IT-Servicemanagement 

§ Nachteile: 

- Normale Peers können nicht ohne Super-Peers arbeiten 

- P2P-Netze mit hybriden Strukturen zeigen hierarchische Ebenen 


Peer-to-Peer-Struktur 


§ Vorteile: 

Peer-to-Peer-Struktur 

- Möglichkeit der Kommerzialisierung des Internets zu entgehen 

- Vereinfachter Umgang mit dem Urheberrecht (dezentraler Ansatz) 

- Höhere Skalierbarkeit für parallelisierbare Probleme 

- Reduzierte Gefahr des Informationsverlustes 

- Unabhängigkeit von „fixed network infrastructures“ 

§ Nachteile: 

- Redundanz sorgt für inkonsistente Informationsobjekte 

- Langwierige Suche nach strukturierten Datenobjekten 

- Hohe Komplexität des IT-Managements 

- Schwierigkeit der Fehlersuche 

- Problem nachvollziehbarer fachlicher Prozessabläufe 


P2P-Datenhaltung und Suche 

§ P2P-Datenhaltung (nach [Li et al. 2002]): 

- Strukturierte Datenhaltung (Regeln zu Datenablage) 

- Teilstrukturierte Datenhaltung (Hinweise zu abgelegten Daten) 

- Unstrukturierte Datenhaltung (unbekannte Position gesuchter Daten) 

§ P2P-Suchmethoden (nach [Milojicic et al. 2002]): 

- Zentrales Verzeichnis (Suche entsprechend dem C/S-Prinzip) 

- Flooding (Suchanfrage eines Peers an alle ihm bekannten Peers) 

- Document Routing (Suche über Hash-Funktionen Position im Netz) 


P2P-Systemebenen 

Anwendung des P2P-Paradigmas auf unterschiedlichen Systemebenen 

Quelle: Dustdar, S.; Gall, H.; Hauswirth, M.; Software-Architekturen für Verteilte Systeme, 

Springer Verlag, Juli 2003 


JXTA Standard 

§ JXTA - Projekt zur Standardisierung von Peer-to-Peer- 

Anwendungen 

- Open Source Projekt ursprünglich von SUN Microsystems 

- Ziel: Spezifikation und Architektur einer P2P-Plattform 

- JXTA-Protokolle als Kern des Standards 

• Programmiersprachenunabhängig 

• Betriebssystemunabhängig 

• Übertragungsprotokollunabhängig 

- Libraries für Java, C und andere Sprachen 

§ Referenzimplementierung für J2SE bzw. JSE 


JXTA Architektur 

Quelle: Becker, R.; Liebsch, F.; Michel, Y. R.; Müller, D.: 

JXTA: Einführung und Überblick, Freie Universität Berlin, 2004 


JXTA Standard 

§ Ein Peer implementiert ein JXTA-Protokoll. Das kann 

beispielsweise ein PDA, Handy oder Server sein. Jeder Peer erhält 

eine weltweit eindeutige ID. 

§ Eine Peer Group ist eine zusammenarbeitende Menge von Peers. 

Peer Groups werden ebenfalls durch eine eindeutige ID in einem 

JXTA-Netzwerk identifiziert. 

§ Messages in JXTA werden als Objekte zwischen Peers verschickt. 

§ Eine Pipe ist ein Kommunikationskanal um Messages zu versenden 

oder empfangen zu können. 

§ Ein Advertisement ist ein XML-Dokument, das alle JXTA- 

Ressourcen benennt, beschreibt und deren Existenz bekannt gibt. 

Ressourcen sind Peers, Peer Groups, Pipes oder Services. 

§ Ein Service ist ein Dienst, der von jedem Peer oder einer Peer 

Group´bereitgestellt werden kann. 

nach juxtapose (Nebeneinanderstellung), siehe www.jxta.org

Software-Systemstrukturen - Userpage - Freie Universität Berlin

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?