Dokumentation von Quellcode in wiss. Arbeiten

[Katrin_K]

Hallo

Wie wird der Quellcode in wiss. Arbeiten dokumentiert?
Klassen via Klassendiagramm:
--------------------
| Klassenname |
--------------------
| + Attribute1 |
| - Attribute2 |
--------------------
| Methode1 |
| Methode2 |
--------------------

+ = public
- = private

usw. darüber findet man viel im netz

Aber wie ist das bei der Dokumentation von Methoden?

Beschreibt man die Funktion der Methode und liefert ein Diagramm mit
1. Methodenname
2. Übergabeparameter
3. Rückgabeparameter

????

Danke



ps: wie kann ich die kategorie ändern????

[marabu]

Hallo Katrin,

Zitat von Katrin_K:

Wie wird der Quellcode in wiss. Arbeiten dokumentiert?

wenn du noch an der Uni bist, dann so wie es dein Prof oder Doktorvater gerne hat. Sollte der Prof keine Meinung dazu haben wollen, dann hilft ein Blick in seine Skripte. Ist dort nichts zu entdecken, dann nach Art des Hauses. Danach würde ich die Fachbereichsbibliothek zum Thema Software Engineering filzen.

Zitat von Katrin_K:

Beschreibt man die Funktion der Methode und liefert ein Diagramm mit
1. Methodenname
2. Übergabeparameter
3. Rückgabeparameter

Eher so:

1. Vorbedingung
2. Kurzbeschreibung
3. Nachbedingung

Zitat von Katrin_K:

wie kann ich die kategorie ändern????

Das macht ein Mod für dich, wenn du ihn darum bittest.

Freundliche Grüße vom marabu

[Katrin_K]

Danke für die Antwort marabu,

ich merke du bist einer der fleißigsten hier. Du hast mir ja schon des öffteren geholfen.
das mit dem Ändern der kategorie und dem moderatorhat bestens geklappt.

in den Unerlagen meines Prof´s habe ich nichts gefunden.
Nur das mit der Methodenbeschreibung( Funktionen oder Prozeduren)

Zitat:

Eher so:

1. Vorbedingung
2. Kurzbeschreibung
3. Nachbedingung

verunsichert mich.
Es muss doch irgendein standardisiertes model geben, wie das zu machen ist. Es gibt doch auch standards zur erstellung von klassendiagrammen bei uml. Gibt es keine Methodendiagramme????
alle die irgend so etwas schon mal im netz gesehen haben bitte ich: schickt mir bitte den link!
lesen kann ich alleine nur beim finden brauche ich hilfe.

danke
gruss katrin

[marabu]

Hallo Katrin,

bei meinem 1-2-3 Hinweis habe ich mehr an die Dokumentation durch Kommentare im Code gedacht. Die Vor- und Nachbedingungen stammen aus der algebraischen Definition. Beschrieben werden Ausgangs- und Endzustände der Objektvariablen über Prädikate.

Die Parameter sollten kaum Beschreibung nötig haben. Eine gute Namenskonvention und die konsequente Verwendung auch optionaler Schlüsselworte für die Aufrufkonvention (var, in, out, named, ... ) - zur Not auskommentiert, falls die Programmiersprache es nicht unterstützt - sollten ausreichen. Hilfreich ist darüberhinaus ein konsistentes Fachvokabular mit prosaischer Einführung aller Begriffe und Glossar.

Wenn du darüberhinaus noch diagrammgestützte Beschreibungen einzelner Methoden anfertigen möchtest, dann bist du bei UML schon richtig. Es dürfte kaum einen Aspekt geben, den du nicht mit UML beschreiben kannst. Alle Diagramme der behavioural model view kommen für deine Zwecke in Betracht: state-charts, sequence diagramms, collaboration diagrams und activity diagrams. Dein einziges Problem sollte die Wahl des Werkzeuges sein.

Freundliche Grüße

marabu

[Olli]

Ich denke, daß dein Professor sicher nichts dagegen hat, wenn du eine doxygen-kompatible Syntax in deinem Projekt benutzt. Mithilfe von Doxygen kann man die Dokumentation als LaTeX oder HTML erzeugen ... es gibt auch andere Systeme.

Hier ein Beispiel was Doxygen für dich machen kann:
http://clam.iua.upf.edu/doc/CLAM-dev...s__Xerces.html

Hier ein Beispiel (geklaut von CommentMaker-Pro). Das Problem könnte sein, daß man einen Parser für Pascal-Code braucht.

Code:

///////////////////////////////////////////////////////////////////////////////
///  [public|private] [FunctionName]
///  <TODO: insert function description here>
///
///  @param $P_INOUT$ $P_NAME$ $P_TYPE$ $P_DEFAULT$   <TODO: insert parameter description here>
///
///  @return $R_TYPE$ <TODO: insert return value description here>
///
///  @remarks <TODO: insert remarks here>
///
///  @see <TODO: insert text here>
///
///  @author $AUTHOR$
///////////////////////////////////////////////////////////////////////////////

Die Konvention was du wie beschreibst, bleibt natürlich ganz dir überlassen. Bin allerdings nciht sicher, ob es eher eine praktische oder eher eine theoretische Frage war.