DJMesche

Erstmal vielen Dank für die Antwort -leider wusst ich das auch vorher, und habe deswegen den Thread eröffnet Wenn ich bei der Programmierung im Netz gesucht habe, wie ich die Parameter beim Select eines ObjectDataSource (C#) abänder, dann muss ich das doch sicherlich nicht in meine Dokumentation schreiben, da dass für die doch irrelevant ist??

Hallöchen liebste Community der Welt nachdem ich nun nur noch an den Quellen in meiner Dokumentation rumschreibe, ist mir etwas eingefallen: Ich beziehe mich die ganze Zeit auf Quellen, die ich während der Programmierung des Projektes ergoogled habe... ABER: Müssen die Quellen sich nicht eigentlich nur auf die Doku beziehen? Also muss ich nur Quellen nennen, die ich benötigt habe, um meine Doku zu verfassen?? Eigentlich ja schon?! Da wäre die ganze Arbeit nämlich umsonst gewesen!!! Danke für eure Hilfe!:mod:

Goto ist ein Kündigungsgrund!!!

Danke aber dass das Klassendiagramm falsch ist,ist mir bekannt - und es ist auch schon abgeändert. Trotzdem beantwortet niemand meine Frage - wie tief muss es in der Doku gehen bzw., wie muss es aussehen? Danke

Wieso mag jetzt keine mehr mit mir reden?

Also ich meine etwa so..wäre das ok?? : 2.3.4 Entwurf der Klassenhierarchie Basierend auf den Erkenntnissen im Programmablauf und den Anpassungen der Datenbank kann nun ein Klassendiagramm erstellt werden. Die Klassen sollen durchgängig mit „builder pattern“ erstellt werden, um zum einen eine bessere Lesbarkeit des Quellcodes zu erreichen und zum anderen die Instanziierung der Klassen ohne Übergabe von Parametern. So kann erreicht werden, dass die Klassen die zugeordneten Datenbanktabellen repräsentieren und später nur auf diesen gearbeitet wird. Beim Erstellen des Klassendiagramms wird eine Aufspaltung der Daten eines Auftrags vorgenommen. Die Allgemeinen Properties eines Antrags (nicht personengebunden) werden in dem Objekt Antrag behandelt. Daten, welche an die zuzuordnende Person eines Antrags gebunden sind, werden im Objekt AntragGrunddaten vorgehalten. Somit kann eine bessere Übersichtlichkeit der Klassen gewährleistet werden. (Anhang Klassendiegramm) [...] Goto Projektdurchführung2.3.4 Entwurf der Klassenhierarchie (Goto ist ein Kündigungsgrund!!!!) 3.3 Entwicklung der Klassenhierarchie Zuerst wurden die Interfaces für die benötigten Klassen Antrag, AntragGrunddaten und AntragLeistung entwickelt. Diese dienen zur eindeutigen Festlegung der Funktionalitäten der jeweilig untergeordneten Klasse. Die Entwicklung der Klassen an sich erfolgte anhand des bereits in der Planung erstellten Klassendiagramms. Alle Objekte erben dabei von der Basis-Klasse ItemBase, welche grundlegende Properties für alle anderen Klassen enthält. Im Anschluss wurden die Verwaltungsobjekte der Klassen entwickelt, um die Bindung der Objekte an die Datenbank zu ermöglichen. (Auszüge aus Itembase, Antrag, IAntrag) return (isOK) ? "OK" : NotOkException() DANGÖ! Anhang_Interface_IAntrag.pdf

Hallöchen liebe Community:D bald ist es soweit - die Prüfungen kommen immer näher und damit auch das Abschlussprojekt... Dazu habe ich erstmal zwei Fragen - ich werde diese im Laufe meine Dokumentation erweitern 1. Klassen und Funktionen, welche ich geplant habe (UML) - wie genau muss ich in der Durchführung davon berichten? Muss ich nur schreiben, dass ich diese wie geplant umgesetzt habe und kurz wie - oder soll ich ausführlich auf Properties etc der Klassen eingehen? 2. Für das Programm war ein Pflichtenheft vorhanden. Ich programmiere nur ein Modul daraus....soll ich jetzt das komplette Pflichteheft (50 Seiten) in den Anhang stecken oder kann ich auch Auszüge in einem Dokument zusammensetzen, welche dann mit meinem Projekt zu tun haben? Ich habe weiterhin einen Teil des Pflichtenheftes - eben der, der mit dem Projekt zu tun hat - selbst erarbeitet....wie mache ich das deutlich? Vielen Dank! Ich wäre über eine schnelle Hilfe sehr dankbar! :beagolisc Viele Grüße aus dem Osten:D:cool: