Workspace-Viewer: Unterschied zwischen den Versionen

Aus Physik
Zur Navigation springen Zur Suche springen
Zeile 42: Zeile 42:
 
==Offene Fragen==
 
==Offene Fragen==
   
(Antworten der Bosse in <span style="color:#00AA88">Farbe</span>)
+
(Antworten der Mitarbeiter in <span style="color:#00AA88">Farbe</span>)
   
 
* Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition)
 
* Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition)
Zeile 71: Zeile 71:
 
Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift. <br>
 
Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift. <br>
 
--[[User:Osiris|Osiris]] 19:11, 21 Oct 2005 (CEST)
 
--[[User:Osiris|Osiris]] 19:11, 21 Oct 2005 (CEST)
  +
  +
<span style="color:#00AA88">
  +
Natürlich wär das super, gib dir in allem völlig recht. Bei mir hat einfach die Zeit/Motivation oft nicht ausgereicht, um das auf diese Art anzugehen. Wäre spitze, wenn du das so schreiben könntest. Wenn du das was über GUI-Tests herausfindest, wärs natürlich auch super..
  +
</span>
   
 
Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ...<br>
 
Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ...<br>
 
Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-)<br>
 
Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-)<br>
--[[User:Osiris|Osiris]] 19:34, 21 Oct 2005 (CEST)
+
--[[User:Osiris|Osiris]] 19:34, 21 Oct 2005 (CEST)
  +
  +
<span style="color:#00AA88">
  +
Versteh ich nicht ganz.. Meinst du das updaten der aktuell vorhandenen Variablen?
  +
</span>
   
 
* Soll eine DTD zur Validierung geschrieben werden?<br>
 
* Soll eine DTD zur Validierung geschrieben werden?<br>
 
Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden.
 
Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden.
   
  +
<span style="color:#00AA88">
  +
Es gibt eigentlich ein fertiges Schema (wahrscheinlich sogar leichter zu validieren, als eine DTD, da man genauere Einschränkungen machen kann) für jede Art XML-File, die im Programm vorkommt. Beim konkreten ist aber noch einiges nachzubessern, um der aktuellen Version gerecht zu werden. Kannst aber auch gern eine DTD schreiben, wenn das für dich besser ist, wär aber natürlich eine doppelte Arbeit, da das Schema schon fast fertig ist.
  +
Meiner Meinung nach interessanter Ansatz ist auf [http://www.xmlmodeling.com/hyperModel/index.html http://www.xmlmodeling.com/hyperModel/index.html] zu finden. Hab teilweise mit ArgoUML modelliert und anschließend in ein Schema gewandelt. Das Plugin hat bei mir jedoch nicht unter Eclipse 3.1 funktioniert. Weiß nicht, ob sie es schon upgedated haben.
  +
Wär cool wenn der Schema Test dann miteingebaut werden könnte. Dann könnte man das was von Matlab kommt immer auf Sinnhaftigkeit überprüfen. Ist zwar keine Benutzereingabe, wo das mehr Sinn macht, aber man könnte es as so etwas ähnliches wie einen unittest für die Matlab-Skripte sehen, wenn man z.B. alle Variablenarten durchspielt. Übertragungsfehler könnte man damit natürlich auch ausschließen..
  +
</span>
   
  +
  +
* <span style="color:#00AA88"> Wie füge ich denn Bentzernamen und Zeit so schön ins Wiki ein?
  +
</span>
 
==Benötigte Ressourcen==
 
==Benötigte Ressourcen==

Version vom 22. Oktober 2005, 12:30 Uhr

Grundlagen

Eclipse

Datenaustausch

Bei der ersten Ausführung eines Matlab Programms wird eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt.


Softwareentwicklungsprozess

Ich (Osiris) möchte verstärkt XP-Techniken einsetzten:

  • Incremental Design
  • Unit Tests wo möglich/wichtig

und zwar mit TDD (Test Driven Design) und nicht im Nachhinein


Ziel

Ein an den Workspace-Viewer von Matlab angelehnter Viewer als Eclipse-Plugin.

Folgende Funktionalitäten sollen zur Verfügung gestellt werden:

  • Anzeigen einer Übersicht aller im Workspace momentan vorhandenen Variablen
  • Anzeigen der Details von Variablen, ändern des Inhalts?
  • Export und Import von Variablen (*.mat Files)

Weitere Anforderungen:

  • Flexibilität in Hinblick auf eventuelle Änderungen der XML-Files (Matlab Versionsumstellung)


Weiteres Vorgehen

  1. Einlernen in Eclipse und Pluginentwicklung für Eclipse
  2. Definition der Schnittstellen
  3. Grobplanung (Incremental Design)
  4. Entwicklung der Klassen zum Auslesen des XML-Files
  5. Entwicklung der Oberfläche
    1. Zuerst einfache Darstellung eines Files
    2. Dann Einbindung mit der entgültigen Funktionalität


Offene Fragen

(Antworten der Mitarbeiter in Farbe)

  • Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition)
  • Funktionsweise der Datenübertragung / des Updatens

Nur kurz einmal: Im Endeffekt wird bei der ersten Ausführung eines Matlab Programms eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt. Dh. man müsste eine Matlab-Funktion zur Verfügung stellen, die alle vorhandenen Variablen anzeigt und diese dann nacheinander als XML-Text ausgibt. Dieser Output müsste dann vom Workspace-Viewer gelesen und in einem Eclipse View dargestellt werden. Wie das mit dem Update des Views ausschaut, müsste man sich noch überlegen. Vielleicht wäre ein vom Benutzer ausgelöstes Refresh gar nicht so schlecht.

Aber: Als erster Schritt wäre es wahrscheinlich einmal einfacher zum Testen einen Eclipse-Editor zu schreiben, der auf eine bestimmte Dateiendung reagiert und das ausgewählte File einmal darstellt. Dieses dann mit der Pipe-Funktionalität zu versehen und in einen View umzubasteln, in dem mehrere Variablen angezeigt werden, wäre dann wahrscheinlich kein allzu großes Problem mehr.

So eine Aufteilung finde ich auch auf jeden Fall sinnvoll.
--Osiris 19:22, 21 Oct 2005 (CEST)

  • Unit Tests erwünscht/erbeten/notwendig/üblich oder eher nicht (schwierig bei der Oberfläche)

Schwer zu sagen, üblich sind sie leider nicht, da es so lange dauert sie zu schreiben. Es gibt ca. zu einem drittel der Funktionen unittests od. unittest-ähnliche Konstrukte. In diesem Fall würde es wahrscheinlich reichen, wenn man alle Variablenarten durchspielt und dann händisch die Anzeige der Variablen überprüft.

Ich würd' sie aber nicht schlecht finden. Was den Zeitaufwand betrifft, würd ich das nicht so sagen (zitiere meine Freundin: "TDD ist nicht langwierig!!!". Natürlich ist mehr Code zu schreiben, wenn man Code und Tests zugleich entwickelt, aber dafür fällt die komplette Testphase weg und lange Fehlersuchen gibt's auch nicht. (lang kommt es einem nur vor, wenn man die Tests nachher schreibt, aber das ist ja kein TDD)
Blöd ist nur, dass sich GUIs schwer testen lassen (da gibt's aber auch was). Aber z.B. das komplette XML-File Auslesen und das Datenhandling ließen sich wunderbar überprüfen.
Die Vorteile von TDD würden bei uns voll zum Tragen kommen, insbesondere ist es sehr brauchbar, dass der Code automatisch dokumentiert und abgesichert wäre (und zukünftige Erweiterungen eventuell durch andere Programmierer sind ja nicht so unwahrscheinlich).
Außerdem werd' ich ja auch in Eclipse entwickeln, und das mach Entwickeln mit Unit Tests ja noch einfacher als es ohnehin schon ist.
Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift.
--Osiris 19:11, 21 Oct 2005 (CEST)

Natürlich wär das super, gib dir in allem völlig recht. Bei mir hat einfach die Zeit/Motivation oft nicht ausgereicht, um das auf diese Art anzugehen. Wäre spitze, wenn du das so schreiben könntest. Wenn du das was über GUI-Tests herausfindest, wärs natürlich auch super..

Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ...
Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-)
--Osiris 19:34, 21 Oct 2005 (CEST)

Versteh ich nicht ganz.. Meinst du das updaten der aktuell vorhandenen Variablen?

  • Soll eine DTD zur Validierung geschrieben werden?

Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden.

Es gibt eigentlich ein fertiges Schema (wahrscheinlich sogar leichter zu validieren, als eine DTD, da man genauere Einschränkungen machen kann) für jede Art XML-File, die im Programm vorkommt. Beim konkreten ist aber noch einiges nachzubessern, um der aktuellen Version gerecht zu werden. Kannst aber auch gern eine DTD schreiben, wenn das für dich besser ist, wär aber natürlich eine doppelte Arbeit, da das Schema schon fast fertig ist. Meiner Meinung nach interessanter Ansatz ist auf http://www.xmlmodeling.com/hyperModel/index.html zu finden. Hab teilweise mit ArgoUML modelliert und anschließend in ein Schema gewandelt. Das Plugin hat bei mir jedoch nicht unter Eclipse 3.1 funktioniert. Weiß nicht, ob sie es schon upgedated haben. Wär cool wenn der Schema Test dann miteingebaut werden könnte. Dann könnte man das was von Matlab kommt immer auf Sinnhaftigkeit überprüfen. Ist zwar keine Benutzereingabe, wo das mehr Sinn macht, aber man könnte es as so etwas ähnliches wie einen unittest für die Matlab-Skripte sehen, wenn man z.B. alle Variablenarten durchspielt. Übertragungsfehler könnte man damit natürlich auch ausschließen..


  • Wie füge ich denn Bentzernamen und Zeit so schön ins Wiki ein?

Benötigte Ressourcen