wie fange ich das Projekt richtig an?
-
Ok, also was ich machen soll weiß ich ja.
Ich hab ja das Anforderungsprofil.Aber wie fang ich da jetzt an...
Mach ich zuerst die Oberfläche?
-
tribblexer schrieb:
Ok, also was ich machen soll weiß ich ja.
Ich hab ja das Anforderungsprofil.Aber wie fang ich da jetzt an...
Mach ich zuerst die Oberfläche?Nein, du machst dir erst einmal ein paar Gedanken darueber, welche Schnittstellen
du benoetigst. Frag dich folgendes:Wie will ich die Daten einlesen? (Schnittstelle zum einlesen der Daten)
Wie will ich die Kriterien einlesen? (Schnittstelle zum definieren von Kriterien
evtl. mit Filterfunktionalitaeten innerhalb der Schnittstelle zum einlesen der
Daten?)
Wie will ich die Daten verarbeiten? (Schnittstelle zum verarbeiten der Daten)
Wie sollen die Daten repraesentiert werden?) (Schnittstelle zum ausgeben der
Daten - in Datei, auf dem Bildschirm, wie auch immer)Mach dir erstmal Gedanken ueber die "Hintergrundarbeit" die gemacht werden soll,
srpich die Datenverarbeitung. Ueber die grafische Gestaltung kannst du dir
spaeter immernoch gedanken machen.Am besten du designest das Ganze so, dass du es in einem Konsolenprogramm testen
kannst. Dann schaust du ob deine Implementierung korrekt arbeitet und dann
haust du die grafische Oberflaeche drauf.Denke der Ansatz sollte nicht falsch sein. Fall irgendwer das anders machen
wuerde, oder Verbesserungsvorschlaege hat, nur her damit
mfg
v R
-
"schnittstellen" ist ein schönes wort.
schnittstellen zum ausgeben definieren? ich denke, man kann die daten auch einfach ausgeben!
dito zum einlesen!
filterschnittstellen? hab keine in den anforderungen gesehen.
und verarbeitungsschnittstellen gibts nicht.
ansonsten volle zustimmung.
-
und nach dem alles läuft fängst du an das ganze in uml-bildchen zu malen, damit auch dein vorgesetzter versteht was du fabriziert hast.
viel erfolg.
-
volkard schrieb:
"schnittstellen" ist ein schönes wort.
schnittstellen zum ausgeben definieren? ich denke, man kann die daten auch einfach ausgeben!
dito zum einlesen!
filterschnittstellen? hab keine in den anforderungen gesehen.
und verarbeitungsschnittstellen gibts nicht.
ansonsten volle zustimmung.Naja, mit Schnittstellen meinte ich ich sowas wie Klassen + deren Memberfunktionen
die ich Implementieren muss.Ist vielleicht etwas ungluecklich ausgedrueckt :).
Mit Filter meinte ich, dass die auszugebenen Daten erst einmal anhand von
Kriterien ausgewaehlt werden. Dachte mir, da die Excel-Datei (oder CSV-Datei)
wahrscheinlich eh komplett eingelesen wird, muss man sie ja erstmal mit
hilfe der Kriterien "filtern" um an sein Ergebnis zu kommen. Weiss ja nicht,
wie genau er es haben will/muss.mfg
v R
-
Ich persönlich mach das immer so das ich das Programm so progge das es in einer Konsole zu 100% läuft und Bugfrei ist.
Danach wird eine Gui gebastelt. Finde ich besser weil die GUi eh nur max 5% des Aufwandes ausmachen soll und wenn du dich um beides gleichzeitig kümmert fällt dir immer auf "hmm da is ja noch ein bug, oh hier könnte noch ein button hin" und das lenkt mich persönlich ab.
-
Ich will da jetzt nicht den Experten markieren, aber ich denke, dass das ganze mit SQL doch recht einfach geht. Wenn man mal die Anbindung an die Db (in diesem Fall Excel) hat, kann man sich mit Hilfe der 'Kriterien' doch eine SQL-Abfrage basteln, damit ein Recordset füllen und das anzeigen.
Hört sich doch ganz leicht an, oder?
-
ok, hier mal die relevanten Sachen aus dem Anforderungsprofil:
Also, wenn ich das jetzt mal als Konsolenanwendung schreibe, wie würdet ihr die Klassen definieren?
Oder reicht eine Klasse?
Sorry, aber ich hab wirklich noch nicht soviel Ahnung...
-
Jover schrieb:
aber ich denke, dass das ganze mit SQL doch recht einfach geht.
wie? per ODBC oder per COM über Excel oder Access?
das erfordert entweder, daß der user das ms-office drauf hat, oder daß für odbc zeugs ruminstalliert wird mit setup.exe und so.
schlicht als kommaseparierte *.txt exportiert und neben die eigene *.exe gelegt und gut ists, würd ich sagen. nicht, weil es einfacher zu proggen ist, sondern weil es später für den user einfacher ist.
-
Stimmt, für den User ist es nacher einfacher.
-
Na, da haste doch eine recht coole Aufgabe bekommen
da die Anwendung sowohl von CD als auch Installaliert laufen soll
wirste mit einer DB vielleicht Schwierigkeiten bekommen.Danach wird eine Gui gebastelt. Finde ich besser weil die GUi eh nur max 5% des Aufwandes ausmachen soll und wenn du dich um beides gleichzeitig kümmert fällt dir immer auf "hmm da is ja noch ein bug, oh hier könnte noch ein button hin" und das lenkt mich persönlich ab.
Das mit 5% gefällt mir gut ... (GUI ist lästig, vorallem der User der davor sitzt)
Im Prinzip ist das auch richtig die basis oder funktionalen Objekte mit
einem sehr einfachen Frame zu entwickeln und zutesten. Aber wie du vielleicht
bemerkt hast sind alle strikt dagegen UML, Struktorgramme, Ablaufpläne usw.
zu machen. Sagen dann aber mach dir hier und darüber Gedanken und definiere Schnittstellen.Um ehrlich zu sein kann ich es dir nicht sagen wie du ein Projekt richtig anfangen solltest. Manche machen das aus dem Kopf andere schreiben alles auf.
Vielleicht ist der richtige Weg erstmal zusortieren was du willst und was andere von dir Verlangen. Denn das Programm hast du zwar entwicklet, aber es ist für andere.Um es einfach zumachen. Wie sollten eine Projektstrktur ausehen die sowohl in einer Console als auch mit einer GUI laufen soll. Wo kommen log/traces usw hin?
Wie weit willst du kapseln/abstrahieren? Eine DB kann im einfachsten Fall auch ein File sein. Welche arten von User soll es geben? Wie unterscheides du zwischen instalierte und CD Version? Wie groß wird die Datenmange sein?
Was ist update und was upgrate? Wie werden daten auf- und abwärts kompatibel gehalten? usw.Fragen sind meiner Meinung die richtige Antwort.
-
fang einfach an.
besorg die daten. exportiere die in ein leicht zu lesendes format.
schau, ob alle tabellen leichts ins ram passen (ich nehmen an, das ist der fall).
lies die daten ein und stopfe sie in stl-container.
mach testhalber mal suchen nach achsabstand oder so.
achte nicht so auf performace, wenn heute der user ne sekunde auf die antwort warten muß, isses nicht schlimm. der denkt, es sei sein rechner und kauft sich nen schnelleren.
---
jetzt mach die gedanken um die gui, hau mal nen dialog rein und träum ein wenig, was passieren soll, wenn man diesen oder jenen knopf drückt. kannste das auch mit den drunterliegenden daten schaffen?
---
nu haste viel gelernt. schmeiß nochmal alles weg und fang von vorne an. beim zweiten oder dritten mal schon wirds perfekt.
---
langsam isses an der zeit, den code durchzukommentieren. schreib ne kleine anleitung, wie ein nachfolgeprogrammierer das prog erweitern kann. schreib auch auf, was für einschränkungen da sind.
---
dann bastel uml-diagramme, struktogramme, er-diagramme und wasauchimmer, wenns den chef glücklich macht.
-
volkard schrieb:
...
der denkt, es sei sein rechner und kauft sich nen schnelleren.
...Du hast immer die geilsten Saetze in deinen Antworten :D.
mfg
v R
