LE 6 | OOD - Objektorientiertes Design - IW [Überarbeitet: 20150630 /IW, 20150702 / ME] Flashcards
Was bedeutet Design in der SWT?
- beschreibt den Prozess zwischen Analyse und Implementierung
- Definition grundlegender Architekturen
- Spezifikation von Komponenten
- Interaktionen transparent machen
Wie wird die Designphase noch genannt und warum wird diese so genannt?
- Architekturphase
- Gestaltung (Design) der Komponeten soll eine Architektur ergeben
Welche Phase folgt im Wasserfallmodell nach der Analysephase?
- Designphase
Welche Dokument sind nach IEEE Std 1016 im Designprozess zu erstellen?
- Einleitung
- Designübersicht
- System Architektur
- Detailbeschreibung der Komponenten
- Benutzerschnittstelle (UI)
- Zusätzliches Material (Appendix)
Nenne 2 Frameworks für den Designprozess!
- Spring
- EJB/JEE
Welche Kriterien muss eine gute Softwarearchitektur/Design erfüllen?
- Änderbar
- Testbar
- Verständlich/ Lesbar
- Wiederverwendbarkeit von Komponenten/Klassen
Bei der Definition der Anwendungsarchitektur gilt es zunächst ein grobes Bild der Komponenten zu definieren, welches dann immer weiter verfeinert wird.
Wie geht man dabei vor?
-
Deployment-Diagramm (Verteilungsdiagramm)
- gobes Bild definieren
- Verteilungsdiagramm
- Versuchen alle Interaktionswege zu berücksichtigen
- die ersten groben Komponenten werden sichbar
-
Schichten und Komponenten (Komponentenmodell)
- Komponentendiagramm
- Identifkation möglichst vieler Komponenten zur Abrenzung und Verteilung
- Gruppenbildung um Schichten sichtbar zu machen (GUI, Anwendungslogik, Datenhaltung)
- Vertikale Schichten (Gruppen) und fachliche horizontale Schichten
- Wer soll und darf wen benutzen?
Welche Fachlichen Komponenten gibt es beim Designprozess?
-
Definition von Fachklassen
- Jede bisherige Komponente auf Klassenebene runterbrechen
-
Externe Komponenten
- Externe Schnittstellen wie GUI, Webservices, DB, etc. erfassen
-
Workflows
- Klassen die für den Ablauf zuständig sind (Controller, Workflow-Komponenten) erfassen
- Häufig Zusammenhang mit den Use-Cases
-
Gruppen bilden
- Komponenten in Gruppen einteilen und Beziehungen überlegen
- Zusammenhängende Fachklassen können meist durch die gleiche Workflow-Komponente behandelt werden
- Sonstige Logik und Hilfskomponenten erfassen
- Erste Beziehungen erfassen
Im komponentenspezifischen Klassenmodell werden die einzelnen Entitäten genau ausgearbeitet, d. h. spezifiziert. Dazu geht man in einzelnen Schritten vor:
Welche Schritte gibt es dabei ?
Komponentenspezifisches Klassenmodell
1. Identifikation aller endgültigen Fachklassen
- Einzelnen Entitäten/Klassen werden genau ausgearbeitet
- Alle Klassen definieren (Fachklassen und auch umliegende und weitergehende)
2. Assoziationen zwischen Klassen definieren
- Was repräsentieren die Klassen?
- Welche Zustände können die Klassen annehmen?
3. Exakte Komponentenspezifikation
- Textuell oder per UML alle Attribute und Methoden aufschreiben
- Wenn alles definiert ist, kann der Entwickler mit der Implementierung beginnen
Welche Mittel gibt es um ein gelungenes Design zu erzeugen? (Designprinzipien)
-
Berücksichtigung des Umfelds
- Aufgabe, Team, Mittel, Rahmenbedingungen, Standards, etc.
-
Einteilung in Pakete
- Paketstruktur erzeugen
- Technische, fachliche oder andere Einteilungen nutzen z. B. durch Namensräume darstellen
-
Einteilung in Klassen
- Welche Klasse in welchem Paket?
- Klassen in sich wohl strukturiert?
- Erledigt die Klasse nur ihre eigene Aufgabe?
-
Interaktion der Pakete
- Wie kommunizieren die Pakete miteinander?
- Wer mit wem?
- Proxy, etc?
-
Interaktion der Klassen
- Design Patterns?
- Dependency-Injection Framework?
- Design der Klasse selbst
Was versteht man unter dem DRY-Prinzip?
DRY - Dont Repeat Yourself
- Gleicher oder ähnlichen Code zusammenfassen
- Copy Paste vermeiden
- Wartbarer / weniger Fehler
Was versteht man unter dem SRP-Prinzip?
SRP - Single Responsibility Design
- Klassen sollen nur eine Aufgabe übernehmen
- Lose Kopplung
- Vermindert Änderungsempfindlichkeit
- Separation of Concerns
Was ist unter Information Hiding (Tell, don’t ask) zu verstehen?
- Details einer Implementierung bleiben nach außen hin verborgen
- dadurch kann die innere Implementierung eines Moduls modifiziert werden, ohne das andere Module davon betroffen sind
- hat die Verminderung der Abhängigkeiten zwischen Modulen zur Folge und unterstützt damit eine diesbezüglich bessere Wartung und Pflege von Modulen
Warum eigenen sich Dynamische Modelle zum Entwerfen und Modellieren besonders?
Veranschaulichung von Abläufen für die Teammitglied
- Dynamische Diagramme veranschaulichen Sachverhalte und Zusammenspiel von Komponenten
- Bsp. Zusammenarbeitsmodelle, Sequenz- und Kollaborationsdiagramme
Einfachere Überprüfung der Vollständigkeit
- Durch das runterbrechen von Aktionen (Top-Down) werden Abläufe und Aktionen in Einzelteile und Unterabläufe aufgeteilt
- Dadurch ist es leichter möglich, fehlende Komponenten zu identifizieren
Kriterien bei Komponentenschnittstellen ?
-
Geheimnisprinzip
- Der Nutzer muss nur das Interface kennen und kann sich darauf verlassen das dieses erfüllt wird
- Schnittstellenmethoden ändern sich i.d.R. nicht sehr häufig
-
Zuständigkeit
- Klare Zuständigkeitsteilung
- Nutzer verlässt sich auf Korrektheit, Vollständigkeit und das „nicht ändern” der Schnittstelle
- Anbieter kümmert sich nur um die Erfüllung der Schnittstelle
-
Testbarkeit
- Schnittstellen können getestet werden
- Der Nutzer kann sich dadurch darauf verlassen das die Schnittstelle erfüllt wird
- TDD: Schnittstellen werden von außen nach innen definiert
- Möglichst immer gegen ein Interface programmieren
- Nie die Klasse instanziieren, sondern immer die Klasse aus dem Interface herstellen
