home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Architektur

Zur Architektur und zum Grobentwurf zählen Aspekte wie

     

  • Persistenz von Daten
  • Berechtigungskonzepte
  • Identifikation, Verteilung und Zusammenspiel von Subsytemen und Komponenten
  • Skalierung

Wichtige Hilfsmittel in dieser Phase sind UML Komponentendiagramme oder Verteilungsdiagramme.

Mehrschichtige Anwendungen

Die mehrschichtigen Anwendungen werden auch als "n-tier Applikationen" bezeichnet. Ihnen ist gemein, dass die Gesamtanwendung in verschiedene Schichten zerlegt wird. Diese Zerlegung kann vor allem dann sinnvoll sein, wenn eine Anwendung gut skalieren muss, d.h. dass bei hoher Last (z.B. hohe Anzahl gleichzeitiger Benutzer) das gleiche Antwortverhalten wie bei niedriger Last besteht.

Eine übliche Aufteilung der Schichten ist:

     

  • Dialogschicht (z.B. HTML Browser)
  • Präsentationsschicht (z.B. Webserver)
  • Geschäftschicht (mit Geschäftslogik und Geschäftsobjekten)
  • "Mittelschicht" bei verteilten Anwendungen
  • Persistenzschicht (z.B. Datenbank)

Komponentenentwurf

Die Aufteilung einer Anwendung kann - wie eben gezeigt - in Schichten erfolgen. Genauso ist eine Aufteilung innerhalb der Schichten möglich. Der Begriff der Komponente ist davon unabhängig:

Eine Softwarekomponente ist eine Einheit, die gekapselte Funktionalität implementiert und über wohl definierte Schnittstellen zur Verfügung stellt.

Man strebt eine komponentenorientierte Architektur an, um einzelne Komponenten besser wieder verwenden, besser zu testen und austauschen zu können. Während der Entwicklungszeit ergibt sich auch eine höhere Unabhängigkeit von Teams, die an verschiedenen Komponenten arbeiten.

Ein komponentenorientierter Entwurf zeichnet sich aus durch

     

  • Abgeschlossenheit der Komponenten: Die Implementierung der Komponente ist nach außen nicht sichtbar
  • Die Komponenten sind untereinander nur lose gekoppelt (loose coupling)
  • Starke Bindung und ein starker Zusammenhang der Elemente innerhalb eines Moduls (strong cohesion)

Zerstören der Unabhängigkeit von Komponenten

Die Kopplung von Komponenten entsteht (wobei gleichzeitig die Wiederverwendbarkeit, Testbarkeit und Austauschbarkeit erschwert wird) durch

     

  • Import von Klassen einer anderen Komponente
  • Vererbung von Klassen einer anderen Komponente
  • Implementierung von Klassen einer anderen Komponente
  • Zugriff auf Methoden und Attribute von Klassen einer anderen Komponente

Tipps für unabhängige Komponenten

Umgekehrt kann Kopplung vermieden werden durch

     

  • Methoden, deren Gültigkeitsbereich auf "private" oder zumindest "protected" gesetzt wird
  • Bevorzugung von Interfaces anstatt von Vererbung über Komponenten hinweg (so sich das nicht ganz vermeiden lässt)
  • Kurze Liste an Übergabeparametern
  • Bei Übergabeparametern Interfaces bevorzugen (z.B. Map statt Hashtable)
  • Gegenseitigen zyklische Abhängigkeiten vermeiden
  • Möglichst wenige Fehler (Exceptions) über Komponentengrenzen werfen

Größe der Komponenten

Komponenten sollten sich nicht nur an technischen Rahmenbedingungen, wie den Schichten eine Anwendung, sondern vor allem auch an fachlichen Überlegungen orientieren. Werden die Komponenten zu granular gewählt steigt der Integrationsaufwand, werden sie zu grobkörnig definiert steigen die Kosten und die Komplexität für die Erstellung eines einzelnen Moduls.

Kommunikation

Davon abhängig wie die Komponenten entworfen werden, findet ihre gegenseitige Kommunikation zwischen oder innerhalb der Schichten statt.

 

     

  • RMI im Java Umfeld
  • Corba, das unabhängig von einer konkrete Programmiersprache definiert ist und in verschiedenen Sprachen implementiert ist
  • XML über HTTP (z.B. XML, RPC, SOAP) gewinnt besonders mit Webservices und serviceorientierten Architekturen (SOA) an Bedeutung
  • DCOM im Microsoft Umfeld