Yevgen Reznichenko wrote:
Ich habe mir auch schon einige Gedanken gemacht. Ich fände es von
Vorteil, wenn wir eine Art Komponentenmodel entwickeln. Das
Hauptprogramm wäre dann also lediglich eine Laufzeitumgebung für
verschiedene Module und würde nur ein rudimentäres GUI und ein API zur
verfügungstellen. Die eigentlichen Funktionen könnten wir dann in
verschiedene Module/Plugins auslagern. Das hätte den Vorteil, dass mann
Funktionen leichter austauschen bzw. neue hinzufügen kann. Ausserdem
würde es die Entwicklung vereinfachen, da sich jeder aus ein anderes
Modul konzentrieren könnte( das muss man aber nicht unbedingt... ).
Ausserdem könnte man zwischen Client und der DB noch eine weitere
Instanz "einschieben". Ich habe da an eine Art Application Server
gedacht. Das kann man mit RMI/CORBA realisieren und man könnte dan die
gesamte DB Abfragelogik dorthin verschieben. Das würde die Komplexität
der Clients zwar verringern, aber das System als Ganzes würde wieder an
Komplexität zunehmen - obwohl es (glaube ich) bei SAP etwas ähnliches gibt.
Hier sollten wir uns gleich um die Abbildung auf der DB Gedanken machen, damit wir als aler erstes die ER Modelle entwerfen können. Schliesslich muss die DB als erstes stehen. Wir sollten uns auch möglichst früh für eine DB entscheiden. Am besten wäre es natürlich, wenn wir mehrere unterstützen würden.
Zu weit treiben können wir nicht, zumindest ich, weil ich komme da nicht mehr mit mit der Entwicklung. Obwohl Modellierung gewinnt immer mehr an Bedeutung. Egal, ein Glossar brauchen wir auf jeden Fall und ich schlage vor wir fangen gleich damit an und machen uns gegenseitig klar wovon wir bei den Begriffen sprechen und wie sollten sie aussehen. Wäre schön wenn Roland zumindest in dieser Phase etwas Zeit gefunden hätte, da er wirklich etwas von WWS versteht.
Ok, dann komme ich zu Sache und fangen mit den unter Stichpunkt "Stammdaten" bezeichnet Stämmen.
[0] Definition von Stammdaten (von der Homepage):
"Stammdaten sind wichtige Basisdaten. Hier werden Daten wie Adressen, Kunden, Lieferanten, Artikeldaten, Lagerstände, Lagerpositionen, Preise usw. verwaltet. Aber auch solche Kleinigkeiten wie Postleitzahlen, Schlüssel, Versandattribute, Gültigkeiten etc. werden in den Stammdaten gepflegt."
Ich bin mir auch nicht sicher, würde aber für trunk oder historical data pledieren.
[1] Als aller erstes brauchen wir dafür eine *passende* englische Bezeichnung. Mein dict wirft dazu "historical data", aber ich glaube das ist nicht das richtige. Für Stamm liefert er unter anderem "root", "phylum", "trunk" und "tribe". Ich bin nicht so gut im englischen, was meinen die anderen dazu?
[2] Stammdaten ist unserer Oberbegriff für alle mögliche Stammdaten, also muss Stammdaten (natürlich engl. Begriff an deren Stelle) eine Oberklasse oder zumindest ein Interface sein. Jetzt müssen wir uns überlegen was haben alle Stammdaten gemeinsam und welche Operationen sollen auf allen Stammdaten durchgeführt werden können. Was Gemeinsamkeiten anbetrifft habe ich noch nichts gefunden, aber manche Operationen:Genau so habe ich mir das mit RMI/CORBA gedacht. Die Methoden(apply(), remove(),etc) würden dann dem Remote Objekt gehören. Aber wie gesagt, ich weiss nicht, ob das der optimale Weg ist.
- apply() fügt ein Datum hinzu
- remove() (bzw. drop() ) löscht ein Datum
- get() liefert ein Datum
- exportCSV() exportiert eine Art von Stammdaten in ein "comma separated format"
- importCSV() importiert eine Art von Stammdaten in ein "comma separated format"
- save() speichert die Stammdaten in die DB
- load() lädt die Daten aus der DB
[3] Wir müssen uns Gedanken machen wo wir unsere Daten verwalten. Zuerst wollte Roland den CVS-Server auf seinem Rechner laufen lassen, aber ich finde etwas belästigend für ihn und für uns, falls er momentan nicht soviel Zeit hat. Wir müssen uns umhören wo wir unseren "Nest" aufbauen können. Ideen? Wie wäre sourceforge.net? Ich habe es mir gerade angeschaut scheint perfekt zu sein.An Sourceforge habe ich auch als erstes gedacht. Hab's mir aber noch nicht angesehen. Wir sollten uns wenn möglich auch auf eine einheitliche IDE einigen. Das erspart uns vielleicht einigen Ärger wegen inkompatiblität(ich bevorzuge NetBeans und JBuilder).
Genau
Ich glaube für das erste Mal reicht es wir müssen voran kommen und nicht sich mit Arbeit überhaufen, denn dann vergeht schnell Lust dran.
Das sollten wir auf jeden Fall vermeiden. Also lieber zweimal über etwas nachdenken.
Laut Prof.Dr. Frank Leymann (Mister Web-Services Germany) in Zukunft werden haufenweise Modellierer gebraucht und einwenig Programmierer. Naja, wir werden sehen. Modellieren müssen wir auf jeden Fall, denn sonst bauen wir 100% irgend so ein Mist. Daher zuerst Entwerfen dann Implementieren, auf Fehler und neue Anforderungen stossen und wieder Modellieren und Implementieren usw. es ist ein fast *unendlicher* Zyklus.
MfG Michael
--
panic ("Splunge!");
2.2.16 /usr/src/linux/drivers/scsi/psi240i.c-- Projekt: Warenwirtschaft. Projektname: Jana Infos: http://jana.bbf7.de
-------------------------------------------------------------------- Zum AUSTRAGEN schicken Sie eine Mail an idefix-request@xxxxxxxxxxxxx mit dem Subject "unsubscribe". mailto:idefix-request@xxxxxxxxxxxxx?subject=unsubscribe
Mailarchive: //www.freelists.org/archives/idefix Probleme? Mail an mailto:rkruggel@xxxxxxx (deutsch)
