Archiv für den Monat: Mai 2013

Scrum-Rechner Teil 5: Die logische Sicht als Teil des Konzepts

In diesem Beitrag wird die logische Sicht des Scrum-Rechners auf einer sehr abstrakten Ebene entwickelt. Die Anforderungen bestehen in den UseCases, von denen im Moment einer in Details untersucht wurde.
Die Frage, die mit der logischen Sicht beantwortet werden soll, ist: „Wie ist die Software konzeptuell organisiert?“. „Konzeptuell“ in diesem Zusammenhang bedeutet, dass nicht die Organisation in deploybaren Artefakten, sondern die logische Struktur untersucht wird. Detailfagen, die gestellt werden müssen, sind: „Welches sind die wichtigsten Schichten, Subsysteme, Packages, Frameworks, Interfaces und Klassen?“.

Traditionell ist eine Entkopplung der Darstellungsschicht von dem Rest des Systems gewünscht, um den „Impact of change“ bei neuen Anforderungen an die GUI (Designänderungen oder neue Technologien) gering zu halten. Während der traditionelle objektorientierte Weg besagt, dass jedes Objekt sich selbst darstellt (siehe GRASP: Information Expert), wird dieses Prinzip den nicht-funktionalen Anforderungen (hier: der Wartbarkeit) geopfert, und in View-Klassen ausgelagert (GRASP: Pure Fabrication). Microsoft bezeichnet die Trennung der View von dem Rest des Systems als „Document-View Architecture“.

Der UseCase beschreibt schon einige „Spielregeln“, nämlich die Abfolge Operand->Operator->Operand->…. Diese Regeln sollen von der Geschäftslogik (Durchführung der Berechnung) getrennt werden, sie werden also in einen Controller ausgelagert. Ergebnis wäre das Model-View-Controller-Pattern.

Wird für die bekannten Anwendungsfälle wirklich Model-View-Controller benötigt? Der UseCase „Daten eingeben“ erfordert zumindest keine Verbindung zwischen Modell und View. Im Zweifel gilt hier erst einmal: YAGNI. Statt MVC folgt der Entwurf in der logischen Sicht dem Model-View-Presenter Pattern.

logische Sicht des Scrum-Rechners

logische Sicht des Scrum-Rechners