326 Objektorientiert entwerfen und implementieren

  • 10 Dez. 2018
  • 15:55

    Entwurfsmuster Das Kompositum & Factory-Pattern und und und ...

    Das Kompositum (englisch composite oder whole-part) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung, das zur Kategorie der Strukturmuster (englisch structural patterns) gehört.
    Mehr lesen...

    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

  • 10 Dez. 2018
  • 14:25

    Java Threads und Socket

    Was ist Socket ?
       Mehr lesen...

    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

  • 10 Dez. 2018
  • 12:25

    Entwurfsmuster Queue

    In der Informatik bezeichnet eine Warteschlange (englisch queue [kju]) eine häufig eingesetzte Datenstruktur. Sie dient zur Zwischenspeicherung von Objekten in einer Reihenfolge, bevor diese weiterverarbeitet werden.
    Mehr lesen...

    Java Queue Tutorial

  • 10 Dez. 2018
  • 11:15

    Entwurfsmuster Abhängigkeits-Umkehr-Prinzip

    Das Dependency Inversion Principle (DIP) besagt, dass in der objektorientierten Programmierung die Basis eines Entwurfs nicht die speziellen Eigenschaften von Modulen sind, sondern deren gemeinsame Merkmale sollen in einer gemeinsamen Schnittstelle abstrahiert werden. Durch die Abstraktion werden die nicht mehr relevanten Details eines Moduls ausgeblendet. Mit Modul werden abgegrenzte und eigenständige Teile einer Software bezeichnet - dabei kann es sich um Objekte oder Klassen handeln. Die Umkehr der Abhängigkeiten ist nicht zu verwechseln mit dem in objektorientierten Programmierung gleichermaßen bekannten Prinzip von der Umkehr des Kontrollflusses, der Inversion of Control (IoC).
    Mehr lesen...

    OOP Design Principles: Dependency Inversion Principle

  • 10 Dez. 2018
  • 11:05

    Entwurfsmuster Adapter

    Das Entwurfsmuster "Adapter", dient, wie der Name bereits andeutet, dazu, eine Schnittstelle einer anderen, inkompatiblen Schnittstelle anzupassen. Damit können Klassen zusammenarbeiten, die sonst aufgrund ihrer Schnittstellen nicht dazu in der Lage wären.
    Mehr lesen...

    Passt schon: Adapter [Entwurfsmuster]

  • 10 Dez. 2018
  • 10:05

    Entwerfen Single Responsibility Principle

    In der objektorientierten Programmierung sagt das SRP aus, dass jede Klasse nur eine fest definierte Aufgabe zu erfüllen hat. In einer Klasse sollten lediglich Funktionen vorhanden sein, die direkt zur Erfüllung dieser Aufgabe beitragen.
    Mehr lesen...

    Understanding the Single Responsibility Principle

  • 08 Sep. 2018
  • 20:05

    Grobarchitektur Entwerfen

    Was bedeutet der Begriff Architektur in der Softwareentwicklung?

    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
  • 14 Aug. 2018
  • 20:05

    Einfürung Use-Case-Diagramme & Fachklassen

    Use-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. Wie Sie nun gesehen haben, können im Use-Case-Diagramm wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen.
    Mehr lesen...

    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...