Strukturierte Methode für Softwaretechnik-Übung

Hier wird die Methode der Modellierung und objekt-orientierten Analyse beschrieben, die in den Übungsblättern zu der VorlesungSoftwaretechnik2004 benutzt wird an dem Beispiel der Prüfungsverwaltung. Sie stützt sich auf das sukzessive Erweitern von Diagrammen (auf UML-Basis), ausgehend von einer verbalen Beschreibung der Anforderungen. Aus verschiedenen Perspektiven werden dabei immer mehr der Anforderungen formalisiert, bis am Ende die Implementation nicht mehr weit ist. Die Methode strukturiert den großen Schritt von der Anforderungsermittlung zu der Kodierung.

  1. Projektbeschreibung: Basis der Entwicklung ist eine kurze Beschreibung der Wünsche an das zu erstellende System. Dort sollten die wichtigsten Anforderungen stehen, funktional wie nicht-funktional. Die hier stehenden Anforderungen sollten sich nicht mehr ändern, es können aber nachfolgend neue hinzukommen.
  2. Technische Risiken: Welche der genannten Anforderungen sind zentral für das Gelingen des Systems? Welche technischen Anforderungen und Umstände können das Projekt wahrscheinlich scheitern lassen? Extrahieren Sie dazu insbesondere die nicht-funktionalen Anforderungen. Modellieren Sie zunächst den Systemteil mit dem größten Risiko.
  3. Akteure: Finden Sie Akteure, d.h. alles, was mit dem System interagiert und etwas mit dem System tut, also von ihm benutzt wird, aber nicht Teil des Systems ist. Das System hat keinen Einfluss auf die Akteure. Akteure decken auch keine der Anforderungen ab.
  4. Anwendungsfälle definieren: Identifizieren Sie für jeden Akteur, was er/sie/es mit dem System tun will. Dies sind meist Verben in der sprachlichen Beschreibung. Jede genannte funktionale Anforderung muss danach abgedeckt sein. Ergänzen Sie eventuell weitere Fälle, die implizit als ebenfalls zu realisieren angenommen werden. Gruppieren Sie die Fälle zu größeren Einheiten, wenn es im ersten Schritt zu viele Fälle werden.
  5. Szenarien:
    • Normalfall: Schreiben Sie für jeden Anwendungsfall ein Szenario bestehend aus Vorbedingung, nummerierte Abfolge der Tätigkeiten (ohne Schleifen und Bedingungen) und Nachbedingung. Betrachten Sie den normalen, gut laufenden Fall und werden Sie nicht zu detailliert. Formulieren Sie das Szenario aus Sicht des Akteurs mit aktiven Verben. Sprechen Sie von dem "System", mit dem der Akteur interagiert.
    • Ausnahmefall: Pro Normalszenario geben Sie die Ausnahmefälle oder andere alternative Abläufe des Szenarios verbal an. Bedenken Sie hier auch erweiterte Anforderungen, die bislang noch nicht genannt wurden. Eventuell entstehen hier neue Risiken. Nehmen Sie sich diesen bevorzugt an.
  6. Benutzungsoberflächen: Wenn angebracht, skizzieren Sie aus den Szenarien erste Benutzungsoberflächen. Dies kann schon die erste Rückmeldung an den Kunden sein.
  7. Architektur: Zeichnen Sie ein Komponentendiagramm mit der ersten Vermutung der Architektur des Systems. Achten Sie auf eine gute Modularisierung. Wenden Sie ein Architekturmuster an, wenn möglich. Fügen Sie die Anwendungsfälle soweit möglich den einzelnen Paketen hinzu. Definieren Sie Schnittstellen zwischen den Paketen.
  8. Objekte und Operationen: Entwerfen Sie für jeden Normalfall ein Sequenzdiagramm. Detaillieren Sie, was Sie vorher noch "System" genannt haben. Auf diese Weise gehen dabei die (Prozess-)Objekte hervor, d.h. Teile des Systems.
  9. Klassen 1: Definieren Sie aus den ermittelten Objekten Klassen und bringen Sie sie in eine Hierarchie, falls möglich. Achten Sie dabei erneut auf die Substantive in verbalen Beschreibungen. Auch Akteure können Klassen sein. Modellieren Sie auch Assoziationen (einige Verben und Hilfsverben) zwischen Klassen.
  10. Klassen 2: Ergänzen Sie die Operationen aus den Sequenzmodellen und fügen Sie notwendige Attribute hinzu. Werden Sie im ersten Schritt nicht zu detailliert. Fügen Sie die Klassen den Komponenten aus der Architektur hinzu und passen Sie diese eventuell an.
  11. Lebenszyklen: Entwerfen Sie für Klassen, bei denen es einen Lebenszyklus gibt, ein Zustandsdiagramm, wenn es nicht zu trivial ist.
  12. Klassen 3: Verfeinern Sie die Klassenmodelle im zweiten Schritt um Kardinalitäten, Kompositionen und Aggregationen, Rollen und Restriktionen. Spezifizieren Sie die Attribute und Operationen genauer. Versuchen Sie, Entwurfsmuster zu entdecken, dokumentieren Sie dies und passen Sie das Modell evtl. daran an.
  13. Implementation: Implementieren Sie zunächst die Objektschnittstellen anhand dar Klassendiagramme, dann den Lebenszyklus von Objekten anhand der Zustandsdiagramme, danach die Interaktion der Objekte aufgrund der Sequenzdiagramme. Sie werden hier viele Details hinzu fügen müssen. Modularisieren Sie dies anhand des Komponentendiagramms.

Die hier angegebene Reihenfolge der Tätigkeiten ist zum Lesen geeignet, wird in der Praxis aber häufig durchbrochen werden müssen:
  • Man wechselt beliebig zu vorhergehenden Schritten, um die dort entstandenen Modelle zu verbessern.
  • Man fügt risikogesteuert oder aufgrund spät eintreffenden Informationen iterativ neue Anforderungen hinzu, mit denen man die vorher erstellten Modelle ergänzt, indem man oben wieder anfängt. Genauso können Modellierungen nachträglich wieder verworfen werden.
  • Man lässt gegebenenfalls einzelne überflüssige oder triviale Schritte weg.
  • Man ändert die Reihenfolge (z.B. könnte man die Architektur auch direkt nach der Ermittlung der Anwendungsfälle angehen).
  • Man muss abwägen, ob man jeden Anwendungsfall zunächst komplett bis zu Ende modelliert oder ob man alle Anwendungsfälle gleichzeitig feiner modelliert.

In der Regel wird zwischen objekt-orientierter Analyse (OOA), objekt-orientiertem Entwurf (OOD) und objekt-orientierter Programmierung (OOP) unterschieden. OOA beschäftigt sich mit den realen Konzepten (bis etwa zum Schritt Klassen 1), OOD fügt diesen technische Details und Verallgemeinerungen hinzu (bis zum Schritt Klassen 3) und OOP bildet dies auf eine gewählte Programmiersprache ab. Es wird oft so sein, dass gute Analysemodelle schlechte Implementierungsmodelle sind, deshalb machen die Diagramme oft Umwandlungen mit. Sie sollten die ursprünglichen Modelle nicht wegwerfen. Genauso sollten Sie nicht zu früh an Implementierungsdetails denken.

Eine ähnliche, aber deutlich ausführlicher beschriebene Methode findet sich in Helmut Balzert: Lehrbuch der Software-Technik, 2000 ab Abschnitt 2.18.3. Dort sind insbesondere die Checklisten hilfreich.

Bedenken Sie, dass es viele solcher Methoden geben kann. Diese ist objekt-orientiert. Man kann auch z.B. datenfluss-orientiert vorgehen. Genauso ist die hier beschriebene Methode besonders für interaktive Software gedacht. Bei Echtzeitanforderungen wird man z.B. nicht so Anwendungsfall-orientiert vorgehen wollen.

(Comments)

If you have comments or additions but do not want to include them in the main body above, put add them here and sign as indicated below the text window.
Topic revision: r3 - 29 Nov 2004, jekutschPCPOOL.MI.FU-BERLIN.DE
 
  • Printable version of this topic (p) Printable version of this topic (p)