swe, Software Entwurf

Framework: Grundsätlich gleiche Abläufe (Abstrakte Klassen)

Customization: Ausprägungen der einzelnen Schritte individuell. (abgeleitete Klassen)

Modellierung steht im Vordergrund

• Is-A Beziehung möglich
• Polymorphismus möglich

spätere Änderungen stehen im Vordergrund

• Dinge verändern, die anderen Kontext verwenden
• Explizite Kontrolle, wer wann was aufruft möglich

• High Cohesion
• High Coupling
• Low Representational Gap
• Information Hiding
• Viel private, wenig public
• Abstraktion
• Setter-/ Getter Methoden
• Factories verwenden

• Reduktion der Komplexität
• Spezialisierungen
• Parallelisierung
• Einbindung vorhandener Bausteine

• Wartbarkeit (Maintainability)
  • spätere Änderungen an Software sind mit erträglichem Aufwand machbar
• Übertragbarkeit (Portability)
  • Software läuft auf verschiedenen Plattformen
• Erweiterbarkeit (Extensibility)
  • Zusätzliche Funktionen können hinzugefügt werden, ohne dass bestehende Teile geändert werden müssen.

• In sich geschlossenes Bauelement
• versteckt Details hinter Schnittstelle
• enthält ein Geheimniss (z.b.: Set mit Baum oder Hastable implementiert ist)
• Module werden seperat entwickelt, getestet, ausgetauscht

Klassen:

• instanzierte Objekte
• modelliert reale Welt
• Vererbung möglich
• Modellierung:
  • kleinste Einheit
  • Daten/Funktionen

Modul:

• keine Instanzen
• Kompilations- / Installations-Einheit
• Kann mehrere kooperierende Klassen enthalten
• Modellierung:
  • Abstraktionseinheit
  • Arbeitspaket zur unabhängigen Herstellung

• nur statische Methoden, Variablen und Klassen verwenden
• keine Vererbung zulassen,. Klasse als Final deklarieren.
• innere Klassen und Interfaces, public oder private

Open Services Gateway initiative

Basis von Eclipse Plug-Ins

Modul = OSGi Bundle = .jar Datei mit Manifest

• innerhalb eines Bundles kann normale Java Sichtbarkeit verwendet werden (public, private, protected)
• im Manifest gibt es zusätzliche Einschränkungen zu normalen Java Sichtbarkeitsregeln

jedes Bundle hat eigenen ClassLoader und damit eigenen ClassPath

zyklische Abhängigkeit entsteht, wenn Modul A von B importiert wird. oder:

wenn B von einem anderen Modul importiert wird, von dem A abhängig ist.

existieren Dinge die von beiden Modulen A und B benötitgt werden. diese können nur durch zyklischen Import erreicht werden:

Die gemeinsam verwendeten Ding in ein neues Modul C auslagern. A und B imporiteren C.

• Entwurf
• Planung / Organisation
• Überwachung

Systemstrukturen und Schnittstellen definieren

• Abhängigkeiten identifizieren
• Teams auswählen
• Arbeitsreihenfolge und Termine festlegen

• Korrektheit der Implementierung überwachen
• Qualitätssicherung
  • Component Hell vermeiden
  • Unit Tests
• Entwurf anpassen
  • wenn sich Anforderungen ändern
  • wenn Planungsfehler sichtbar werden
• Architekten ermöglichen Arbeitsteilung

Oppurtunity-Driven

• Welche änderungen werden durch die zufällig vorhandenen Freiheitsgrade vereinfacht?

Gaol-Driven

• Welche Freihetisgrade müssen geplant werden, um bestimmte Änderungen zu unterstützen?

Variation Point:
Variationen, di im aktuellen System bereits benutzt werden, oder bei denen sicher ist, dass entsprechende Varianten kreiert werden.

Evoultion Point:
spekulative Variationen die vielleicht in der Zukunft benötigt werden.

• Projekt-Management
• RE
• UM
• Testing
• Entwickler

• Objektorientierter Entwurf
  • Fokus auf modellieren
  • Objekte & Klassen sinnvoll definieren
  • Lesbarkeit, Verständlichkeit, etc.
• Modularer Entwurf
  • Einheiten für unabhängiges Entwickeln, Testen, Auswechseln, Erweitern trennen
  • Wartbarkeit, Erweiterbarkeit

je ähnlicher reale Welt, Software und Entwurf, desto schneller wird vorhandenes verstanden

 Nomen = Objekte / Klassen

Verben = Aufgaben

sind Hilfsmittel zum intuitiven Entwurf im Team. Karten stellen Klassen (Class), Verantwortung (Responsibility) und Zusammenarbeit dar.

es werden bewusst KEINE Methoden deklariert.

• Pro Objekt eine Karte
• bekannte Operationen festhalten
• aufschreiben, welche anderen Objekte dafür benötigt werden
• für weitere Obejte neue Karten
• Operationen und Beziehungen auf vorhandenen Karten ergänzen
• Änderungen: Karten verwerfen, neue Karte
• Karten auf dem Tisch immer neu gruppieren

• Fokus auf Verantwortung, so denkt man weniger in Daten-und Modell Behältern.
• weniger in rein sequenziellem Kontrollfluss denken
• Grösse der Karten beschänkt Information.
• hohes Abstraktionsniveau, verliert sich nicht in Details

Datenmodellierung

Welche Einheiten gibt es, welche Beziehungen zwischen ihnen gibt es?

zu erfüllende Aufgaben

Use Cases sagen, welche Aufgaben zu erfüllen sind. Verteilun der Aufgaben an die Objekte / Klassen und Begründung.

Ablauf jedes Use Cases beschreiben

Jeden Use Case Schritt für Schritt durchgehen um herauszufinden, welche Objekte, welche anderen Objekte aufrufen müssen. Dies entspricht dem Pfeilfluss und Pfeilspitze im Sequenzdiagramm.

es muss ein zusammenhängender Kontrollfulss entstehen. Man muss Rückkehrpfeile von Aufrufen einzeichnen.
Auf spontante Aufrufe verzichten
Kontrollfluss muss Use Case wiedergeben, dazu müssen Informationen in Parametern und Rückgabewerten ausreichen

Sequenzdiagramm mit Datenmodell abgleichen

Das Sequenzdiagramm muss die gleichen Objekte oder Klassen verwenden. Diese müssen die selben Namen aufweisen. Überprüfen, ob alle Objekte, Klassen oder Beziehungen notwendig sind
Diagramme anpassen, dass sie zusammenpassen.

Alle Aufrufe auf ein Objekt definieren dessen Methoden

Welche Module gibt es, in welcher Beziehung stehen diese zueinander und wie arbeiten diese zusammen?

• Implementierungs-Geheimnisse der Anforderungen
  • Welche Entwurfsentscheidungen wollen wir trennen und welche Änderungsszenarien sehen wir für die Zukunft?
• Implementierungs-Geheimnisse der Technik
  • Wo möchten wir techn. Hilfsmittel unabhängig auswählen und wo werden bestehende Produkte genutzt (Framework)?
• Beziehungen / Abhängigkeiten
  • Welche Module benötigen welche anderen Module und gibt es Zyklen in diesen Abhängigkeiten?
• Parnas
  • Entwurfsentscheidungen isolieren (Implementierungs-Geheimnisse)
• Technology
  • Nach Einsatz von Technologien trennen
• Module gruppieren
  • Nach MVC, Schiten (nur regelkonforme Abhängigkeiten)

Ablauf jedes Use Cases beschreiben

Use Cases werden Schritt für Schritt durchgegangen, um herauszufinden, welche Module welche anderen aufrufen müssen. Pfeilfluss und Pfeilspitze.

• Sequenzdiagramm analysieren
  • Welche Objekte werden von mehr als einem Modul benötigt und in welchem Modul sollten diese implementiert werden? Welche Module müssen Objekte importieren?
• Ist der Import-Graph aller Module frei von Zyklen?
  • Falls nicht, muss man Objekte in anderem Modul implementieren? Brauch ets neue Module, die Obejte zur Verfügung stellgen müssen?

1. HTTP-Request wird von Servlet empfangen
2. Servlet agiert als Controller. Request wird an das Model weitergereicht
3. Serviet leitet Kontrolle an JSP weiter (redirect)
4. JSP produziert HTML Output mit den Model-Daten
5. JSP sendet neue Seite mittel http-Request an den Browser zurück

• alles, was das Modul nicht versteckt
• was ausserhalb des Moduls sichtbar ist
  • nicht private java-Klassen
  • exportierte packages in OSGi-Bundle
• was andere Module über das Modul annehmen dürfen
• was das Modul über andere Module annimmt