LE 6 | OOD - Objektorientiertes Design - IW [Überarbeitet: 20150630 /IW, 20150702 / ME]

Question 1

Was bedeutet Design in der SWT?

Answer 1

• beschreibt den Prozess zwischen Analyse und Implementierung
• Definition grundlegender Architekturen
• Spezifikation von Komponenten
• Interaktionen transparent machen

Question 2

Wie wird die Designphase noch genannt und warum wird diese so genannt?

Answer 2

• Architekturphase
• Gestaltung (Design) der Komponeten soll eine Architektur ergeben

Question 3

Welche Phase folgt im Wasserfallmodell nach der Analysephase?

Answer 3

• Designphase

Question 4

Welche Dokument sind nach IEEE Std 1016 im Designprozess zu erstellen?

Answer 4

• Einleitung
  
  • Designübersicht
• System Architektur
• Detailbeschreibung der Komponenten
• Benutzerschnittstelle (UI)
• Zusätzliches Material (Appendix)

Question 5

Nenne 2 Frameworks für den Designprozess!

Answer 5

• Spring
• EJB/JEE

Question 6

Welche Kriterien muss eine gute Softwarearchitektur/Design erfüllen?

Answer 6

• Änderbar
• Testbar
• Verständlich/ Lesbar
• Wiederverwendbarkeit von Komponenten/Klassen

Question 7

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?

Answer 7

• 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?

Question 8

Welche Fachlichen Komponenten gibt es beim Designprozess?

Answer 8

• 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

Question 9

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 ?

Answer 9

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​

1. Was repräsentieren die Klassen?
2. 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

Question 10

Welche Mittel gibt es um ein gelungenes Design zu erzeugen? (Designprinzipien)

Answer 10

• 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

Question 11

Was versteht man unter dem DRY-Prinzip?

Answer 11

DRY - Dont Repeat Yourself

• Gleicher oder ähnlichen Code zusammenfassen
• Copy Paste vermeiden
• Wartbarer / weniger Fehler

Question 12

Was versteht man unter dem SRP-Prinzip?

Answer 12

SRP - Single Responsibility Design

• Klassen sollen nur eine Aufgabe übernehmen
• Lose Kopplung
• Vermindert Änderungsempfindlichkeit
• Separation of Concerns

Question 13

Was ist unter Information Hiding (Tell, don’t ask) zu verstehen?

Answer 13

• 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

Question 14

Warum eigenen sich Dynamische Modelle zum Entwerfen und Modellieren besonders?

Answer 14

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

Question 15

Kriterien bei Komponentenschnittstellen ?

Answer 15

• 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

Question 16

Schnittstellen der Komponentengruppen

Answer 16

Schnittstellen der Komponentengruppen

• Gute Architektur vermindert insgesamt die Abhängigkeiten
• Komponenten in Gruppen (Packages) zusammenfassen und versuchen die Zugriffe zwischen den Packages zu minimieren
  
  • kann erreicht werden durch das Einführen von Proxies für Packages
  • Proxy stellt eine Möglichkeit da den „inhalt“ des Packages zu kapseln und über den Stellvertreter darauf zuzugreifen
• „losere” Kopplung (Inhalt des Packages kann geändert werden, solange der Zugriff auf den Proxy bestehen bleibt)

Question 17

Externe Schnittstellen

Answer 17

Externe Schnittstellen

• Große Systeme interagieren meist irgendwie mit ihrer Umwelt
• GUI, XML aus anderen Quellen, Dokumente, etc.
• Schnittstellen möglichst von Anfang im Blick haben

Question 18

Welche Testdefinitionen müssen entwickelt werden?

Answer 18

• Tests für Anwendungsfälle
  
  • Welche Eingaben, Operationen und Ausgaben gibt es?
  • Ergebnisse ganzer Komponentenabläufe testen
• Klassentests
  
  • Test der Methoden innerhalb der Klassen (UnitTests)
  • Randbedingungen in den Testplan mit aufnehmen (Alter > 0)
• Tests externer Schnittstellen
  
  • Werden meist unterschätzt
  • Kleine Prototypen die früh Schwachstellen aufzeigen
  • Verhindert spätere Fehler in der Implementierung etc.
• Klasseninterne Tests
  
  • Vorbedingungen
  • Rückgabewerte
  • Nachbedingungen
• Testautomatisierung vorbereiten
  
  • Tests sollten soweit wie möglich automatisiert werden
  • lm einfachsten Fall durch Buildsprachen wie Ant, Maven
  • lm besten Fall durch Continous Integration

Question 19

Was muss bei der Definition der Attribute berücksichtigt werden?

Answer 19

• Am Ende der Designphase werden die Attribute der Komponenten/Klassen definiert
• Folgendes ist zu berücksichtigen:
  
  • Sind alle Attribute erfasst?
  • Ist das Attribut ein Grundtyp oder doch besser ein Objekt einer anderen Klasse
  • Ist es eine Collection? Wenn ja, welche ist am besten geeignet
  • Stimmen die Zuständigkeiten? Sollte das Attribut ggf. in eine andere Klasse?
  • Gibt es Zusicherungen für jedes Attribut?

Question 20

Was ist wichtig beim GUI Design ?

Answer 20

GUI Design

• Umfassende Anwendungen haben mindestens drei Eingabemöglichkeiten
  
  • Rich-Client auf dem Desktop
  • Thin-Client z. B. Webanwendung
  • Mobiler Client
  • Abbruchmöglichkeiten bieten
  • Wo bin ich wann in der Anwendung (Breadcrumb)
  • sind alle Use-Cases abgebildet?
  • Kurze Wege, Konsistenz, etc.
  • Default- und Grenzwerte für Felder

Question 21

Wie viel Design ist nötig?

Answer 21

Wie viel Design ist nötig?

• Kein Design, lieber iterativ das Designentwickeln (direkt am Code)
  
  • Vorteile
    
    • Kein initialer Aufwand
    • Besser auf Situationen reagieren die erst während der Entwicklung auftreten
  • Nachteile
    
    • Zeitverschwendung mit ausprobieren, obwohl es bereits Best Practices gibt
    • Bestehende bewährte Architekturen werden ignoriert
• Viel Design, keine Versuchsentwicklung
  
  • Vorteile
    
    • Schneller einen definierten Stand erreichen
    • Keine Zeit mit Live-Erfahrungen „verschwenden“
  • Nachteile
    
    • Viel initiale Papierarbeit
    • Ggf. wird eine nicht optimale Lösung erzeugt, da das Design fest steht
• Von der Aufgabenstellung abhängig
• Vom Team, Auftraggeber, Finanzen abhängig
• Referenzimplementierungen sollten genutzt werden
• Gibt es keine sollte ein Mix aus beiden Vorgehen meist das Beste sein
• „Good Enough Design” (Nicht alles bis aufs letzte Detail ausgearbeitet, so „das es reicht”)