326 Objektorientiert entwerfen und implementieren

Das Composite-Pattern

Das Factory-Pattern

Factory-Design-Pattern sind die am häufigsten verwendeten Muster in einer Objekt-orientierten Umgebung. Da die Objekterstellung manchmal sehr komplex ist, kommt man bei der Implementierung häufig nicht an einer Abstraktion vorbei.
Mehr lesen...

Factory Method Pattern - Kurzerklärung der Struktur (German / Deutsch)

Design-Pattern [German] - Singleton

Socket Programming in Java

Threads in Java

Ein Thread in Java kann aus verschiedenen Sichten charakterisiert werden. Inhaltlich sind einzelne Threads eine in sich sequenzielle Abfolge von Anweisungen, als Ganzes gesehen laufen sie jedoch parallel zu anderen Threads.
Mehr lesen...

Java Queue Tutorial

Java Queue Tutorial

OOP Design Principles: Dependency Inversion Principle

Passt schon: Adapter [Entwurfsmuster]

Understanding the Single Responsibility Principle

Grobarchitektur

Bei grösseren Systemen wird die Architektur hierarchisch beschrieben. Auf den oberen Ebenen werden als Bausteine Pakete, Komponenten und Schnittstellen (Interfaces), verwendet. Dies entspricht der Grobarchitektur. Ganz grosse Systeme werden zuerst in Subsysteme aufgeteilt. Für jedes Subsystem existiert dann wieder eine eigene Architektur.

Detailarchitektur

Die Detailarchitektur befasst sich mit den einzlnen Teilkomponenten eines Systems. Hier kommen Klassen als Bausteine hinzu. Der Übergang zum Software-Entwurf ist fliessend.

Physische Architektur

UML-Deploymentdiagramm

Die physische Architektur eines Systems kann mit dem UML-Deploymentdiagramm beschrieben werden. Darin wird die Hardware als Knoten und die Verbindungen zwischen der Hardware als Kommunikationspfade (Assoziationen) dargestellt. Das nachfolgende Diagramm zeigt eine Client-Server-Architektur.

Verteilte Systeme: Peer-to-Peer

Bei Peer-to-Peer-Systemen haben alle beteiligten Rechner die gleiche Rolle.Auf jedem Rechner läuft die gleiche Applikation, welche alle Aufgaben von der Benutzerschnittstelle über die Applikationslogik bis zur Datenhaltung wahrnimmt. Alle Rechner des Systems sind (mindestens logisch) untereinander vernetzt. Dies entspricht im Extremfall einer vollvermaschten Topologie. Peer-To-Peer-Systeme können sehr robust sein, da der Ausfall eines einzelnen Rechners vom Gesamtsystem kompensiert werden kann (im Gegensatz zu einem Serverausfall, welcher das ganze System lahmlegen kann). Allerdings bringen Peer-to-Peer-Systeme einen hohen Aufwand für die Synchronisation untereinander. Dieser wächst mit zunehmender Anzahl Peers sogar im Quadrat.
Mehr Lesen ...

Verteilte Systeme: Client-Server

Client-Server-Systeme haben eine Sterntopologie. Die gesamte Kommunikation läuft immer über den Server. Ganz grob gilt: Der Server ist für die Applikationslogik und die Datenhaltung verantwortlich. Die Clients enthalten die Benutzerschnittstelle. Ein solcher Client wird dann als Thin-Client bezeichnet. Wenn die Clients auch die Applikationslogik enthalten spricht man von einem Fat-Client. Allerdings ist die Welt nicht nur schwarz/weiss und so gibt es auch hier Nuancen.
Mehr Lesen ...

Thin-Client

Ein Thin-Client kann auf einer limitierten Hardware betrieben werden. Für die Realisierung der Benutzerschnittstelle reicht ein Browser. Entsprechend ist die Systemarchitektur hier durch die verschiedenen Technologien der Web-Applikationen geprägt.
Mehr Lesen ...

Fat-Client

Ein Fat-Client benötigt einen vollwertigen Rechner, da er auch die Applikationslogik ausführt, oder wenigstens Teile davon. Der Server ist dann im Extremfall nur noch für die Datenhaltung zuständig. Für die Kommunikation zum Server können verschiedene Protokolle zur Anwendung kommen.
Mehr Lesen ...

Logische Architektur

Kriterien für guten Entwurf

Hohe Kohäsion

Kohäsion bedeutet "innerer Zusammenhalt". Mit hoher Kohäsion ist gemeint, dass alle Bestandteile eines Blocks (aber auch einer Komponente, eines Paketes, eines Moduls, einer Klasse) einen engen Bezug zueinander haben.
Gutes Beispiel: Der Block Sitzplatzverwaltung enthält die Liste aller Sitzplätze, sowie die nötigen Funktionen zur Suche von freien Sitzplätzen, zur Reservation und zur Freigabe von reservierten Sitzplätzen.
Schlechtes Beispiel: Der Block Sitzplatzverwaltung enthält auch die Kundendaten der Abonnementskunden (Kunden, welche einen festen Sitzplatz abonniert haben).

Schwache Kopplung

Kopplung entsteht dann, wenn ein Block von einem anderen abhängt. Abhängigkeiten entstehen, wenn ein Block
die Schnittstelle eines anderen Blockes braucht
Daten aus einem anderen Block braucht oder
Strukturelemente (z.B. Klassen) aus einem anderen Block braucht.
Die Kopplung zwischen den Blöcken soll so gering wie möglich sein (allerdings wird sie nie null sein). Dadurch steigt die Wartbarkeit und die Stabilität eines Systems. Wenn an einem Block etwas geändert wird, sollen die Auswirkungen auf das Gesamtsystem so klein wie möglich sein. Wichtig ist vor allem, dass gegenseitige Abhängigkeiten zwischen Blöcken möglichst vermieden werden.

Elemente für die Beschreibung der logischen Architektur

Block

Die allgemeinste Form eines Elementes. Blöcke eignen sich für eine erste Skizze der Architektur. Siehe auch "Logische Architektur". Werden Blöcke verschachtelt, so spricht man oft auch von Subsystemen. Der äusserste Block bildet dann das Gesamtsystem. Blöcke können später durch Komponenten und Klassen ersetzt werden.

Modul

Das Modul wurde mit der modularen Programmierung eingeführt. Es ist ein Kapsel für Daten und bietet nach aussen eine definierte Schnittstelle an. Diese besteht aus Prozeduren und Funktionen, welche auf den gekapselten Daten arbeiten. Heute werden Module in Form von Komponenten oder Klassen realisiert.

Komponente

Im engeren Sinn ist eine Komponente eine für sich ausführbare Einheit. Gleich wie beim Modul, kaspelt eine Komponente Daten und bietet eine Schnittstelle nach aussen an. Komponenten können von anderen Komponenten abhängen und sie können veschachtelt werden. Komponenten sind ersetzbar, d.h. eine Komponente kann durch eine beliebige andere Komponente ersetzt werden , welche die gleiche Schittstelle hat. Der Begriff wird oft in einem weiteren Sinn als Synonym für Modul oder gar Block verwendet.

Interface

Der Begriff Interface hat mehrer Bedeutungen. Hier steht er für eine Sammlung von Methodendeklarationen (deshalb wird der englische Begriff verwendet). Interfaces können eingesetzt werden, um die Schnittstelle von Komponenten zu definieren.

Klasse

Die Klasse ist das unterste Element der logischen Architektur.

Paket

Pakete dienen dazu Elemente zu gruppieren und um einen eigenen Namensraum für diese Elemente zu definieren. Pakete können verwendet werden, um die Zerlegeung eines Gesamtsystems in kleinere Einheiten darzustellen. So gesehen eignen sich Pakete als Ersatz für Blöcke.

Diagramme

Blockdiagramm

Das Blockdiagramm ist ein freies Diagramm und gehört nicht zur UML. Es zeigt Blöcke und Schnittstellen.

UML-Paketdiagramm

Zeigt die Aufteilung eines Systems in Pakete. Zwischen den Paketen können <>-Abhängigkeiten eingezeichnet werden. Pakete können beliebig verschachtelt werden. Sie können auch Komponenten, Interfaces und Klassen enthalten.

UML-Komponentendiagramm

Zeigt die Komponenten eines Systems und wie diese über Schnittstellen miteinander kommunizieren. Dabei können Kombinationen von benötigten und angebotenen Interfaces oder einfach Konnektoren (Assozoationen zwischen Ports) zur Anwendung kommen.

UML-Kompositionsstrukturdiagramm

Das Kompositionsstruktur-Diagramm zeigt typischerweise den inneren Aufbau einer Komponente. Es bietet sehr viele Möglichkeiten und kann relativ komplex werden. Im Modul 326 wird es nicht weiter eingesetzt.

Architekturmsuter

Schichten

Das Schichten-Muster (Englisch layer oder tier) ist allgegenwärtig in der Informatik. Sie kennen es zum Beispiel bereits aus der Netzwerktechnik. Die Idee ist, ein System vertikal in verschiedene Schichten zu gliedern. Jede Schicht übernimmt ein bestimmte Aufgabe. Sie bietet der Darüberliegenden Schicht ihre Dienste über eine Schnittstelle an und versteckt gleichzeitig die Komplexität der Aufgabe vor der darüberliegenden Schicht. Die Schicht nimmt ihrerseits die Dienste der darunterligenden Schicht in Anspruch. Wichtig ist, dass die Abhängigkeiten zwischen den Schichten streng von oben nach unten gerichtet sind.
Das Beispiel zeigt eine sogenannte Three-Tier-Architektur, wie sie zum Beispiel bei Web-Applikationen zur Anwendung kommt als UML-Paketdiagramm

Use Cases.mp4

Fachklassen.mp4

Fachklassen haben einen Wert für ein vertieftes Verständnis der fachlichen Domäne. Sie sind eine nützliche Ergänzung zum Glossar mit dem Ziel, Fachbegriffe gut und genau zu erklären. Es ist sehr wichtig, dass die Namen der Fachklassen für die Bezeichner von Klassen, Methoden oder Attribute im Code verwendet werden. Dadurch erhalten wir lesbaren Code. Fachklassen lassen sich nicht mehr direkt für die Implementierung verwenden. Eine Generierung von Code ist faktisch ausgeschlossen bzw. ist nicht sinnvoll. Aufgrund der Reduktion auf das für das Verständnis Notwendige sind die Fachklassen auch robust bei Änderungen am Code. Denn Entwickler ändern gerne und oft an den Details, aber wichtige Begriffe ändern auch Entwicklern nicht ohne triftigen Grund.
Mehr lesen...