Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005. Design Richtlinien

Transkript

1 Babeș-Bolyai Universität Cluj Napoca Fakultät für Mathematik und Informatik Grundlagen der Programmierung MLG5005 Design Richtlinien

2 UML GRASP

3 Drei-Schichten-Architektur Entwurfsziel: die Trennung von Fachkonzept, Benutzungsoberfläche und Datenhaltung

4 Evolution von UML 1995 Zusammenschluss der Methoden Booch (Booch), OMT (Rumbaugh) und OOSE (Jacobson) 1995 Entwicklung von UML UML 0.9 Jan 1997 UML 1.0 durch OMG Sept 1997 UML UML UML UML 2.0

5 UML Entwicklungsziele verschiedenen existierenden objektorienten Modellierungsmethoden zu vereinheitlichen Ermöglichung der Modellierung großer Systeme Schaffung einer Modellierungssprache, die sowohl von Menschen als auch Maschinen verstanden wird

6 Was kann UML? Spezifikation Visualisierung Entwurf der Architektur Erstellung Simulation und Test Dokumentation

7 Was ist UML nicht? kein Vorgehensmodell kein Modellierungswerkzeug keine Modellierungsrichtlinien keine Programmiersprache

8 UML-Bausteine UML besteht aus 3 Hauptelementen: 1. Grundbestandteile Dinge Beziehungen Diagramme 2. Regeln, nach denen diese Bestandteile zusammengesetzt werden können. Modell muss semantisch in sich konsistent sein

9 UML-Bausteine UML besteht aus 3 Hauptelementen: 3. Mechanismen, die in der UML gelten. Spezifikationen Details Durchgängige Unterscheidungen Erweiterungsmechanismen

10 UML-Bausteine Dinge Strukturelemente(Klassen, Schnittstellen, Komponenten etc.) Beziehungen Abhängigkeit Assoziation Generalisierung Realisierung Diagramme Klassendiagramme, Diagramme etc,

11 Darstellung in Diagrammen 6 Strukturdiagramme -> statische Systemstruktur Klassendiagramm Paketdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Objektdiagramm Verteilungsdiagramm

12 Darstellung in Diagrammen 7 Verhaltensdiagramme -> dynamisches Laufzeitverhalten Use-Case-Diagramm Aktivitätsdiagramm Zustandsautomat Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm

13 Klassendiagramm zeigt Klassen und ihre Beziehungen untereinander Visualisierung und Modellierung der statischen Struktur eines Systems

14 Klassendiagramm der Name der Klasse steht am oberen Rand dem Namen folgen die Attribute der Klasse und darunter die Methoden

15 Klassendiagramm Zusammenstellung deklarativ-statischer Modellelemente (d.h. Klassen, Typen, ihre Inhalte und Beziehungen) Definition der Sprachbasiskonzepte (Zur Erinnerung: Metamodell der UML ist als Klassendiagramm formuliert) Details über Daten- und Verhaltensstruktur des Systems

16 Klassendiagramm

17 Assoziation Die kennt-beziehung Zwischen den Objekten von Klassen können konkrete Beziehungen bestehen In der UML werden Assoziationen als Strecken zwischen den Klassen dargestellt

18 Die Multiplizität 0..3 gibt an, dass ein Kunde 0 bis 3 Konten besitzen kann, die Multiplizität 1 gibt an, dass ein Konto genau einem Kunden gehört. Assoziation Die kennt-beziehung Die Kardinalität einer Assoziation gibt an, mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert sein kann; 1 steht für ein Objekt, * für viele.

19 Implementierung einer gerichteten Assoziation Die gerichtete Assoziation Schüler fährt Auto wird so implementiert, dass die Klasse Schüler um ein Attribut dasauto ergänzt wird. class Schueler: def init (self, auto): self._das_auto = auto #Auto Class-Instanz def get_auto (self): return self._das_auto def set_auto (self, auto): self._das_auto = auto

20 Aggregation Die hat-beziehung Ein Spezialfall der Assoziation ist die Aggregation, bei der die beteiligten Klassen in einer Ganzes-Teile-Beziehung (hat-beziehung) stehen Eine Aggregation bildet also die Zusammensetzung eines Objekts aus einer Menge gleichartiger Einzelteile ab

21 Aggregation Die hat-beziehung Die Teil-Klasse kann selbst wieder eine Aggregatklasse sein Zur Implementierung einer Aggregation muss die Aggregatklasse um ein Attribut ergänzt werden, in dem mehrere Objekte gespeichert werden können

22 Komposition Eine spezielle Art der Aggregation ist die Komposition, bei der die Teile vom Ganzen existenzabhängig sind Ein Teil kann also nur zu einem einzigen Ganzen angehören und die Lebensdauer dieses Teils wird durch die des Ganzen bestimmt

23 Komposition Es ist nicht immer einfach zu entscheiden, ob eine Aggregation oder Komposition vorliegt Eine Datei ist existenzabhängig vom Ordner, in dem diese Datei gespeichert ist. Wird der Ordner gelöscht, so werden auch alle darin befindlichen Dateien gelöscht

24 Generalisierung Vererbung Die Ist-Beziehung beschreibt eine Beziehung zwischen einer allgemeinen Klasse (Basisklasse) und einer speziellen Klasse die spezialisierte Klasse ist vollständig konsistent mit der Basisklasse, enthält aber zusätzliche Informationen (Attribute, Methoden, Assoziationen) ein Objekt der spezialisierten Klasse kann überall dort verwendet werden, wo ein Objekt der Basisklasse erlaubt ist

25 Generalisierung Vererbung Die Ist-Beziehung In der Biologie wird in Form von Taxonomien mit Generalisierungsstrukturen gearbeitet beispielsweise gliedert sich das Reich der Tiere in die beiden Unterreiche der Einzeller und Vielzeller

26 Implementierung der Vererbung

27 Objektdiagramm zeigt die Objekte und ihre Beziehungen zu einem bestimmten Zeitpunkt instanzen von Klassen zu modellieren

28 Paketdiagramm Darstellung der logischen Organisation von Modellelementen und deren Abhängigkeiten Übersichtliche logische Aufbaustruktur des Systems

29 Ziel: Design Richtlinien Single-Responsibility-Prinzip Separation of Concerns Kopplung minimieren Kohäsion maximieren

30 Design Richtlinien Problemstellung Schreibe ein Programm, das alle Daten von Studenten verwaltet. (CRUD-Operationen) Feature F1. Studenten einfügen F2. Studenten lesen F3. Studenten finden F4. Studenten löschen

31 Schichtenarchitektur ein häufig angewandtes Strukturierungsprinzip für die Architektur von Softwaresystemen die Trennung von Fachkonzept, Benutzungsoberfläche und Datenhaltung Benutzerschnittstelle Applikation (GRASP Controller) Domäne (Business Layer) Infrastruktur (Datenhaltung, I/O, etc...)

32 Grasp patterns GRASP = General Responsibility Assignment Software Patterns Geringe Kopplung Hohe Kohäsion Information Expert Creator Controller Pure Fabrication Polymorphismus

33 viele Teile -> schwer zu verstehen! Kohäsion wie gut eine Programmeinheit (eine Funktion/ein Modul) eine logische Aufgabe oder Einheit abbildet. starke Kohäsion: alle Teile eines Moduls sollten mit anderen Teilen des Moduls zusammenhängen und voneinander abhängig sein. schwache Kohäsion: Teile eines Moduls haben keinen Bezug zu anderen Teilen

34 Kopplung ein Maß, das die Stärke die Verknüpfung von verschiedenen Systemen, Anwendungen, oder Softwaremodulen beschreibt Formen von Kopplung. Am Beispiel von der Klasse X zur Klasse Y: X ist direkte oder indirekte Unterklasse von Y X implementiert das Interface von Y X hat Attribut bzw. Referenz von Typ Y (Aggregation/Assoziation) X hat Methode, die Y referenziert (Abhängigkeit)

35 Information Expert das Objekt alle Methoden besitzen, die Aktionen definieren, die mit ihm gemacht werden können gib dem Informations-Experten die Verantwortlichkeit, d. h. der Klasse, welche die notwendigen Informationen besitzt, um die Verantwortung wahrzunehmen. auch bekannt als Do it Myself Strategie (Peter Coad) information Expert ist das grundlegende Prinzip von Objektorientiertem Design und kann auch als Kapselung von Daten bezeichnet werden. die konsequente Verwendung führt zu geringer Kopplung (low coupling) und hoher Kohäsion (high cohesion).

36 Information Expert Information Expert Sale

37 Creator Das Erzeuger-Prinzip legt fest, wer eine Instanz einer Klasse (Objekt) erzeugen sollte. Neue Objekte der Klasse A sollten von B erzeugt werden, wenn: B eine Aggregation von A ist B A-Objekte enthält B A-Objekte erfasst B A-Objekte mit starker Kopplung verwendet B die Initialisierungsdaten für A hat (d. h. B ist Experte bezüglich Erzeugung von A)

38 Creator Tasks T1. Student erstellen T2. Student überprüfen T3. Student speichern T4....

39 Protected Variations Interfaces sollen immer verschiedene konkrete Implementierung verstecken. Wie sollen Objekte, Subsysteme und Systeme entworfen werden, dass Veränderungen oder Instabilitäten in diesen Elementen keinen unerwünschten Einfluss auf andere Elemente haben? Identifiziere Punkte, an denen Veränderungen oder Instabilitäten zu erwarten sind Weise Verantwortlichkeiten so zu, dass diese Punkte durch ein stabiles Interface eingekapselt werden

40 Protected Variations Student überprüfen

41 Pure Fabrication Weise eine Menge stark zusammenhängender Zuständigkeiten einer künstliche Klasse zu, die nichts Reales in der Anwendungsdomäne repräsentiert Etwas, das nur dazu dient, hohen Zusammenhalt, schwache Kopplung und gute Wiederverwendbarkeit zu unterstützen Erfindung der Imagination. Design ist üblicherweise sehr sauber daher pur

42 Pure Fabrication Angenommen wir benötigen Unterstützung, um eine Verkaufs-Instanz in eine relationale Datenbank zu schreiben Nach dem Expert Pattern ist das Sache von Verkauf selbst

43 Pure Fabrication Um das Schreiben in die Datenbank zu realisieren, bedarf es einer Anzahl von datenbankspezifischen Operationen, die nichts mit dem eigentlichen Verkauf zu tun haben Dadurch erhielte die Klasse Verkauf schlechten Zusammenhalt. Die Verkaufs-Klasse wäre zusätzlich an die Schnittstelle zu der relationalen Datenbank (zugekaufte Software) gekoppelt Keine Kopplung zu einer anderen Domänen-Klasse sondern zu einer Schnittstelle zu einer Datenbank

44 Pure Fabrication Zusätzliche Klasse, deren einzige Zuständigkeit es ist, irgendwelche Objekte auf irgendeinem persistenten Medium zu speichern

45 Pure Fabrication Verkauf behält den sauberen Entwurf. Die Klasse PersistenStorageBroker ist relativ gut zusammenhängend. Einzige Verantwortlichkeit: Speichern von Objekten Die Klasse PersistenStorageBroker ist eine sehr generische und wiederverwendbare Klasse

46 Pure Fabrication Pure Fabrication Klassen orientieren sich an zusammenhängenden Funktionalitäten und sind daher eher funktions-zentrierte Klassen Viele existierenden Design Patterns sind Pure Fabrication Klassen: Adapter, Observer, Visitor, usw. Probleme: Der Geist der Objektorientierung kann durch diese funktionsorientierte Argumentation verletzt werden Wird Pure Fabrication missbraucht, dann führt es zu funktions- oder prozessorientiertem Design, das lediglich mit Hilfe eine objektorientierten Sprache implementiert wird

47 Pure Fabrication - Repository Student speichern (RAM, Datei) expert: Student