SE: Systementwurf, © Till Hänisch 2003 Systemarchitektur nach Sommerville, Software Engineering, Addison Wesley.

Präsentation zum Thema: "SE: Systementwurf, © Till Hänisch 2003 Systemarchitektur nach Sommerville, Software Engineering, Addison Wesley."—  Präsentation transkript:

1 SE: Systementwurf, © Till Hänisch 2003 Systemarchitektur nach Sommerville, Software Engineering, Addison Wesley

2 SE: Systementwurf, © Till Hänisch 2003 Literatur

3 SE: Systementwurf, © Till Hänisch 2003 Blockdiagramm Kästchen, Pfeile keine "Systematik" allgemein verständlich Struktur erkennbar? keine "allgemeine Lösung" bewährte Modelle statische Struktur Kontrollflüsse

4 SE: Systementwurf, © Till Hänisch 2003 Repository (gemeinsame) Daten in zentralem Speicher (etwa DB) gemeinsames Datenmodell, Security-Modell usw: Vorteil/Nachteil ? Integration neuer Komponenten einfach (wenn gleiches Modell) Verteilung ?

5 SE: Systementwurf, © Till Hänisch 2003 Client-Server (unabhängige) Server bieten Dienste an Funktionalitäten verteilt Kommunikation über Netzwerk (oder alles lokal, IPC) Middleware (Kommunikation, Naming services usw.)

6 SE: Systementwurf, © Till Hänisch 2003 abstract machine/Schichten Schicht bietet Dienste für nächsthöhere Schicht: abstrakte Maschine Beispiele: Betriebssysteme (IO,...), Compiler, Netzwerke inkrementelle Entwicklung möglich (und Test !!!) Erweiterbar/portabel Performance ? Daten/Aufrufe müssen durch mehrere Schichten gereicht werden Fehlerbehandlung (in jeder Schicht oder "durchreichen" ?)

7 SE: Systementwurf, © Till Hänisch 2003 call-return Hauptprogramm steuert "alles" Kontrollfluß von oben nach unten (Funktionsaufrufe) einfache, starre Kontrollflüsse (Vorteil) was passiert bei Ausnahmen ?

8 SE: Systementwurf, © Till Hänisch 2003 controller Ein Controller steuert (unabhängige) Module oft bei Real-Time Anwendungen, Steuerungen usw.

9 SE: Systementwurf, © Till Hänisch 2003 Events I Broadcast Modell: Events gehen an alle Subsysteme/Komponenten jedes Subsystem/Modul hat Handler Ziel (Name usw.) muss nicht bekannt sein (Vorteil !) keine Rückmeldung (Nachteil !) zusätzlich oft Point to Point flexibel, erweiterbar Real-Time schwierig häufig bei grafischen Oberflächen

10 SE: Systementwurf, © Till Hänisch 2003 Events II Interrupt Modell Ein Handler für jeden Interrupt-Typ Realtime

11 SE: Systementwurf, © Till Hänisch 2003 Objekte vs. Datenflüsse Kommunikation zwischen Objekten durch Pfeile dargestellt Ablauf nicht (direkt) erkennbar Datenflüsse zwischen Funktionen alte Technik, structured analysis bei komplexen Systemen manchmal übersichtlicher

12 SE: Systementwurf, © Till Hänisch 2003 Welche verwenden ? je nach Anwendung bestimmte Architekturen praktisch für bestimmte Anwendungen, z.B. Compiler, CASE-Tools, Multimedia-Archive usw allgemein: keine "reine" Architektur Mischformen, Kombinationen z.B. Blackboard bei (manchen) KI-Anwendungen

13 SE: Systementwurf, © Till Hänisch 2003 Referenzarchitekturen Beispiel: Compiler, Repository