Das deutsche Python-Forum

Hallo,

also das Programm steht. Jetzt muss ich das ganze nur noch in meiner Bachelorarbeit verpacken. Soweit ich weiß, sollte man Quellcode gar nicht oder nur sehr selten direkt in die Bachelorarbeit schreiben.
Bin mir nicht sicher, wie ich das ganze aufbauen soll. Mein Programm läuft über eine grafische Benutzeroberfläche. Mein Plan war es erstmal einen Gesamtüberblick über das Programm zu geben und dann ggf. an der Benutzeroberfläche die einzelnen Funktionen zu erklären. Oder doch lieber in einem Diagramm.
Hat jemand Tipps bezüglich Bachelorarbeit?
Abgesehen von einer Erstsemestervorlesung in C++ hatte ich mit Programmieren noch nicht viel am Hut. Mein Professor ist leider absolut keine Hilfe und in meinem Unternehmen kennt sich niemand so wirklich mit Programmierung aus.

Hat da jemand eine Idee für ein kostenloses Tool um ein ?UMl-Diagramm? oder ähnliches zu erstellen, was vielleicht optisch auch etwas ansprechend ist.

Gruß
Marvin

Es gab mal ArgoUML. Das war kostenlos. Vll gibt das ja noch.

Und was die Gestaltung deiner Arbeit angeht - solltest du da nicht deinen Prof oder die Assis fragen? Deren Vorstellungen sind da doch maßgeblich. Nicht die von zufälligen Leuten aus d Internet.

Hallo,

__deets__ +1: es sollte ja in erster Instanz dem gefallen, der benotet

Von der Erklärung her klingt es so, als ob Screenshots der GUI und Kombination mit einer Erklärung und ggf. Flussdiagramme, was wann beim Druck auf welche Schaltfläche passiert, sinnvoll ist.

Mit yed kannst du Diagramme zeichen, auch UML Diagramme.

Ob du den Quellcode beipackst oder nicht hängt davon ab, wie essentiell der Quellcode für den Arbeit ist. Ggf. reicht es ja, das Listing in einen Anhang zu packen.

Gruß, noisefloor

@Marvin75854: Wenn jemand den Quelltext lesen möchte, kann er ja in den Quelltext schauen. Dafür muss man keine Bäume opfern.

Was man in Bachelor- und ähnlichen Arbeiten zeigen kann sind Implementierungen von selbst entworfenen Algorithmen. Wenn es in C implementiert wäre, würde man da vielleicht auch sagen, besser nicht den C-Code zeigen, sondern Pseudo-Code der das wesentliche enthält, aber Python wird ja manchmal auch als „ausführbarer“ Pseudo-Code bezeichnet. Das heisst man kann das so schreiben, das es tatsächlich lesbar und verständlich ist und Pseudo-Code letztlich fast genau so aussehen würde.

Es kommt letztlich darauf an wie interessant der Code ist. GUI-Code oder ”glue code” der andere Sachen verbindet, ist sicher nicht so wirklich interessant. Also zum Beispiel seitenweise Code der GUI und Menüstrukturen erstellt, bringt wenig Erkenntnisgewinn. Das würde ich auch nicht in den Anhang stecken.

Aufbau ist in der Regel so etwas wie eine Einleitung, was ist das Problem das gelöst werden soll, Stand der Technik, Planung und Umsetzung, Ergebnis und Fazit, Ausblick.

Wie man das Programm benutzt, gehört IMHO in die Arbeit. Also alles was jemand der das in die Hand gedrückt bekommt, wissen muss um es nutzen zu können. Also mindestens eine Beschreibung wofür das gedacht ist, was man an Voraussetzungen und Abhängigkeiten benötigt, und vielleicht auch eine beispielhafte Benutzung durchgehen. Ob ein komplettes Benutzerhandbuch mit in die Arbeit gehört, oder in den Anhang, da bin ich mir nicht so sicher.

Werkzeuge um (UML-)Diagramme zu erstellen gibt's einige. Ich persönlich mag PlantUML, weil man da Quelltext hat.

__deets__ hat geschrieben: Sonntag 16. September 2018, 12:43 Es gab mal ArgoUML. Das war kostenlos. Vll gibt das ja noch.

noisefloor hat geschrieben: Sonntag 16. September 2018, 13:01 Mit yed kannst du Diagramme zeichen, auch UML Diagramme.

__blackjack__ hat geschrieben: Sonntag 16. September 2018, 13:39 Werkzeuge um (UML-)Diagramme zu erstellen gibt's einige. Ich persönlich mag PlantUML, weil man da Quelltext hat.

Super, die werde ich mir alle drei mal anschauen.

Ja habe mit meinem Professor schon gesprochen. Allerdings hält sich die Hilfe da eher in Grenzen. Deswegen einfach mal hier fragen. Denke mein Professor ist was Programmieren angeht auch kein Experte.

Für die Bäume und meinen Geldbeutel sehe ich da schwarz . Der Quellcode soll leider komplett in den Anhang. Am Ende komme ich mal locker auf 150-160 Seiten und das dann mehrmals drucken...

noisefloor hat geschrieben: Sonntag 16. September 2018, 13:01 Von der Erklärung her klingt es so, als ob Screenshots der GUI und Kombination mit einer Erklärung und ggf. Flussdiagramme, was wann beim Druck auf welche Schaltfläche passiert, sinnvoll ist.

Genau. Also meine Idee war ganz grundsätzlich den Aufbau zu erklären. Dann einmal die Benutzeroberfläche. Also was gibt man wo ein und was kommt am ende raus. Dann die Programmstruktur. Ich habe drei Module. Vielleicht drei Spalten in denen ich die Klassen und Funktionen des jeweiligen Moduls aufliste und mit Pfeilen irgendwie zeige was wo aufgerufen wird oder von wo Zahlenwerte bekommt. Und dann die einzelnen Klassen und Funktionen durchgehen. Also nochmal erklären was die Funktionen machen und wie die Berechnungen aussehen.

__blackjack__ hat geschrieben: Sonntag 16. September 2018, 13:39 Wie man das Programm benutzt, gehört IMHO in die Arbeit. Also alles was jemand der das in die Hand gedrückt bekommt, wissen muss um es nutzen zu können. Also mindestens eine Beschreibung wofür das gedacht ist, was man an Voraussetzungen und Abhängigkeiten benötigt, und vielleicht auch eine beispielhafte Benutzung durchgehen. Ob ein komplettes Benutzerhandbuch mit in die Arbeit gehört, oder in den Anhang, da bin ich mir nicht so sicher.

Eine Anleitung habe ich bereits geschrieben. Also Installation, Aufbau und Bedienung der GUI und am Ende noch wie man ein paar Sachen im Programm anpassen kann. Das soll auch in die Arbeit. Was mich hier allerdings massiv stört ist, dass das Programm natürlich von Leuten genutzt wird die sich nicht die ganze Bachelorarbeit durchlesen wollen. Also muss die Anleitung ja recht unabhängig von der Bachelorarbeit geschrieben werden. Deswegen wird es wahrscheinlich einige Wiederholungen geben.

__blackjack__ hat geschrieben: Sonntag 16. September 2018, 13:39 Aufbau ist in der Regel so etwas wie eine Einleitung, was ist das Problem das gelöst werden soll, Stand der Technik, Planung und Umsetzung, Ergebnis und Fazit, Ausblick.

Es ist auch so, dass das Programm zwar irgendwie Hauptbestandteil der Arbeit ist. Allerdings habe ich jetzt schon ca. 25 Seiten geschrieben und das Wort Python noch nicht ein einziges mal erwähnt. Das soll später in der Crashberechnung eingesetzt werden. Da habe ich jetzt den Theorieteil zu verfasst und als nächstes würde dann halt die technische Umsetzung, also der Programmierteil, kommen. Danach kommt noch eine Verifikation und Anwendung. Also wo ich dann auch tatsächlich Crashberechnungen durchführe und die Simulationen analysiere. Diese ganze Programmierung ist dementsprechend nur ein Kapitel in der ganzen Thesis.

Also Codeabschnitte muss ich nicht in die Bachelorarbeit schreiben. Die Berechnungen erkläre ich dann lieber anhand von Word-Formeln. So interessant ist der nicht. Nur in der Anleitung habe ich einen Teil einer Klasse zur Verständnis.