Danke erstmal für Deine Geduld. Wenn mich was interessiert, muss ich einfach die Lösung wissen, sonst träum ich nachts davon
Also, ich probiers mal.
In die Anwendung werden die Wareneingänge des letzten Tages eingelesen, das Verfallsdatum der Waren wird geprüft und es wird geschaut, wie lang die Reichweite des jeweiligen Produkts noch ist. Sollte die Reichweite über das Verfallsdatum minus 6 Monate hinausgehen, wird der Artikel in eine eigene Tabelle geladen und kann dann mit der zu testenden Anwendung bearbeitet werden. Außerdem können die zugehörigen Lieferanten bearbeitet werden (z.B. ob man mit ihnen in Verbindung tritt zwecks Retoure usw.)
Die Anwendung ist nicht besonders groß, besteht aus 4 Dialogen und gliedert sich in etwa 17 Use Cases.
Das soweit. Etwas schwieriger ist allerdings der Aufbau in Module, da es sich um eine eigene Architektur handelt, die etwas schwer so kurz zu beschreiben ist. Der Grundgedanke (wie bei vielen anderen Architekturen) ist der, dass es die Ebenen DB-Zugriff, Business-Logik und GUI gibt. Alles weitere wird dann etwas komplizierter. Ich kann nur sagen: Es gibt zunächst zwei größere Module, eins dass erstmal die Überprüfung vornimmt, ob der Artikel überhaupt in der Anwendung zu kontrollieren ist (siehe Einleitung oben) und das zweite, das dann für die Ansicht und Bearbeitung der Artikel zuständig ist. Die Anwendung wird aber sicherlich noch in mehr kleine Module unterteilt werden, ich persönlich würde fast den Weg von GUI zu DB bzw. umgekehrt zumindest in einigen Fällen für eigene Module halten.
Verbunden sind die Module über Konstrukte, die tabellenähnlich sind und die Daten während dem Programmablauf vorhalten.
Das ist jetzt zwar eine etwas grobe Beschreibung, aber mehr kann ich zur Zeit auch nicht liefern, da die Entwicklung grad erst losgeht und ich selbst auch noch nicht so viel davon sehen kann.
Deswegen war auch meine Frage rein theoretisch gemeint.
LG
Kerstin
