Zitat
Original geschrieben von Sencer
Das Wort Prozess wird in der Umgangssprache für zahlreiche verschiedene Sachen verwendet, du solltest versuchen festzulegen was mit einem Prozeß in diesem Zusammenhang gemeint ist. Was genau willst du abbilden? Welche Teile sind davon betroffen? usw.
In erster Linie geht es vor allem darum einzuschränken. Man bekommt gerne mal Aufgaben wie ein möglichst flexibles System zu schreiben, das sich ohne Änderungen in jede erdenklichen Art und Weise anpassen lassen soll, das ist aber a) seltenst tatsächlich was benötigt wird und b) meistens viel zu teuer, aufwendig und komplex, als das es irgendjemand bezahlen oder benutzen möchte - und natürlich muß dann für die Änderungen die nachher tatsächlich benötigt werden, trotzdem noch der Code angepaßt werden.
Das wichtigste für dich dürfte sein, den richtigen Weg zu finden das zu kommunizieren. Das ist insbesondere dann schwierig, wenn es sich um (Entiwcklungs-)Unerfahrene Leute handelt.
Mit "Prozess" sind verschiedene betriebliche Prozesse gemeint. Das Beispiel in diesem Fall ist eine Versionsänderung.
Es gibt eine neue Version, ein Formular wird angelegt und in der DB gespeichert, ein Verantwortlicher bekommt eine E-Mail über den Vorgang und er muß eine Freigabe erteilen. Ist sie erteilt, bekommt der nächste Verantwortliche eine E-Mail und auch er muß die Änderung freigeben.
Und das System soll dann später mit möglichst wenig Aufwand um weitere Prozesse erweiterbar sein, die ähnlich aufgebaut sind, aber unterschiedlich lang sein können. Der Prototyp für den Prozess würde wahrscheinlich so aussehen -> "Ereignis -> Entscheidung -> Ereignis -> Entscheidung"
Und immer so weiter.
Zitat
Dann brauchst du bis hierher im Prinzip nur ein einzelnes Meta-Datum zu dem Objekt was versioniert wird: den Status. Falls die Objekte um die es geht ebenfalls in der Datenbank gespeichert werden, kannst du die jeweilige Tabelle um ein Feld erweitern, und dort einen Quer-Verweis speichern zu einer zweiten Tabelle, welche die möglichen Zustände enthält. Wenn du Zustände nur in eine Richtung durchlaufen werden können sollen, dann kannst du zu den Zuständen ebenfalls noch weitere Informationen ablegen (bspw. alle möglichen Folgezustände).
Ja daran hab ich schon gedacht und so wird das wohl auch ablaufen.
Zitat
Du erwähnst es zwar nicht explizit, aber vermutlich wirst du auch die Historie jeden Objekts speichern wollen, also wann er welche Zustandsänderungen durchgemacht hat.
Außerdem bleibt auch die Frage nach Benutzerverwaltung ungeklärt, darf jeder alles, oder gibt es verschiedene Berechtigungsgruppen?
Ja das will ich in der Tat. 
Und das ist denke ich auch nicht schwer umzusetzen.
Generell werden alle Benutzer die gleichen Rechte haben. Noch unklar ist ob die Benutzerverwaltung über die DB ablaufen wird oder über die Kommunikation mit LDAP.
Zitat
Kommen später nur neue Zustände hinzu, oder soll es in jede Richtung änderbar bleiben? Welche "Module" sind gemeint? Wie gesagt, allgemein erweiterbar in jede denkbare Richtung ist eine unrealistische Aufgabenstellung.
Wie gesagt, mußt du ersteinmal eine klarere Vorstellung davon bekommen was ein "Prozeß" in deinem konkreten Fall ist. Sehr hilfreich sind auch Papierprototypen, in denen du einfach mal die Benutzermasken und deren Abfolge auf Papier bringst, und mögliche Abläufe simulierst.
Wie bereits oben erwähnt, werden die Prozesse ähnlich aufgebaut sein, also in etwa das gleiche Schema haben, nur mit mehr oder weniger Schritten und anderen "Entscheidungen". Deshalb war der Grundgedanke auch, dass das System um weitere Prozesse, ohne Code-Anpassung, erweiterbar sein soll, da sie sich im Grunde sehr ähneln.
