Projektverlauf: Erste E-Mails mit der Physik

	Erste Anfrage der Physik	Rückfragen von uns	Antwort auf die Rückfragen	Email an die Physik	Antwort von uns

Erste Anfrage der Physik

(25.06.98)

Sehr geehrter Herr Bothe,

ich wende mich an Sie mit einer Bitte um einen Rat.

Wir sind eine experimentelle Arbeitsgruppe am Institut fuer Physik. In unserem Labor laufen rund 10 Rechner, die Roentgendiffraktometer steuern. Vor einigen Jahren hat ein Ingenieur ein Programm (C++) fuer Windows 3.1 geschrieben, mit dem fast alle diese Geraete gesteuert werden. Von diesem Programm aus werden verschiedene Motor- und Detektorsteuerkarten angesprochen. Leider ist die Hardwareansteuerung weitgehend in einer sehr grossen DLL versteckt und das Programm insgesamt nicht sehr uebersichtlich.

Meine Fragen sind nun folgende: - koennten Sie oder einer Ihrer Mitarbeiter uns beraten, wie wir am besten zu einer sauberen Software-Basis fuer die Zukunft kommen, die wir selbst mit ertraeglichem Aufwand pflegen koennen.

- als Idealversion (aus unserer Sicht): vielleicht ist das Problem von Umfang und Ausrichtung auch fuer Sie interessant genug, um es als Thema einer Diplomarbeit zu vergeben.

Mit freundlichen Gruessen Rolf Koehler

***************************************************************
Prof. Dr. Rolf Koehler
Institut fuer Physik - AG Roentgenbeugung
Humboldt-Universitaet zu Berlin
D-10117 Berlin Hausvogteiplatz 5-7
Tel.: +49-30-20246-734
Fax: +49-30-2044536
email: rolf.koehler@physik.hu-berlin.de
***************************************************************

	Erste Anfrage der Physik	Rückfragen von uns	Antwort auf die Rückfragen	Email an die Physik	Antwort von uns

Rückfragen von uns

(29.06.99)
 

Sehr geehrter Herr Koehler,

...

Um Klarheit zu erlangen, habe ich einige Fragen:

1. Ist der Ingenieur, der das Programm entwickelt hat, noch da?

2. Wie gut ist das Programm dokumentiert bzw. kommentiert?

3. Wie umfangreich ist das Programm (in Zeilen C++-Quellcode)?

4. Wurde eine spezielle Entwurfsmethode zugrunde gelegt, z. B. mit Hilfe des objektorientierten Ansatzes?

5. Soll das vorhandene Programm umstrukturiert (saniert) oder neu geschrieben werden?

6. Welche konkreten Probleme haben Sie mit dem vorhandenen Programm: Fehlerbeseitigung, Erweiterung, Portierung auf andere Rechner...?

7. Welcher C++ bzw. welcher C++-Compiler war die Grundlage fuer die Entwicklungsarbeiten?

8. Wie dringend sind die Arbeiten?

9. Wer soll in Zukunft die Pflege des Programms uebernehmen und mit welchem Ziel (sind z. B. noch groessere Erweiterungen geplant)?

Mit freundlichen Gruessen

Klaus Bothe

	Erste Anfrage der Physik	Rückfragen von uns	Antwort auf die Rückfragen	Email an die Physik	Antwort von uns

Antwort auf die Rückfragen

(01.07.98)

Sehr geehrter Herr Bothe,

vielen Dank fuer Ihre ermutigende Antwort. Nun zu Ihren Fragen:

1. Ist der Ingenieur, der das Programm entwickelt hat, noch da?

Leider nein, er ist aber gegebenenfalls per email oder telefonisch zu erreichen.

2. Wie gut ist das Programm dokumentiert bzw. kommentiert?

Ein ehemaliger Mitarbeiter, der inzwischen an einer Fachhochschule technische Informatik studiert hat, war so nett, sich das Programm anzusehen. Nach seiner Aussage ist das Programm hinreichend kommentiert. Dokumentiert sind die Schnittstellen der DLL's. Im Programm sind zwar bereits objektorientierte Ansaetze enthalten, es ist aber nicht gut strukturiert. Insbesondere ist der Zugriff auf die Hardware mit vielen anderen Funktionen zusammen in einer sehr grossen DLL gebuendelt (z.T. auch Elemente der Bedieneroberflaeche).

3. Wie umfangreich ist das Programm (in Zeilen C++-Quellcode)?

Der Quellcode umfasst 30-40 Dateien mit durchschnittlich 20 kByte.

4. Wurde eine spezielle Entwurfsmethode zugrunde gelegt, z. B. mit Hilfe des objektorientierten Ansatzes?

Siehe oben. Nach Aussage des erwaehnten ehemaligen Mitarbeiters sind nur objektorientierte Ansaetze nachtraeglich eingebaut worden.

5. Soll das vorhandene Programm umstrukturiert (saniert) oder neu geschrieben werden?

Es wird wohl unumgaenglich sein, das Programm voellig umzustrukturieren. Ich kann nicht sagen, inwieweit Teile weiterhin verwendbar sind. Zumindest muesste fuer einen Teil der Hardware erkennbar sein, wie diese anzusprechen ist. Vollstaendig kann wahrscheinlich selbst diese Ebene nicht uebernommen werden, da sie komplett ueber polling funktioniert und moeglicherweise die Verwendung von Hardwareinterrupts an einzelnen Stellen sinnvoller ist. Zeitkritisch sind die Programme nicht. Bisher ist auf allen betroffenen Messrechnern Windows 3.1 installiert. Eine Aufruestung der Rechner soweit, dass Windows NT eingesetzt werden kann, ist praktisch ausgeschlossen. Da Sie wohl kaum noch die Programmierung fuer Windows 3.1 als Aufgabe vergeben werden, koennten wir uns den Einsatz von Linux vorstellen, da das geringere Hardwareanforderungen stellt.

6. Welche konkreten Probleme haben Sie mit dem vorhandenen Programm: Fehlerbeseitigung, Erweiterung, Portierung auf andere Rechner...?

Es gibt folgende Problemfelder:

1. Instabilitaet: Z.T. bei bestimmten Aktionen, z.T. voellig zufaellig stuerzt das Programm ab.

2. Fehler: Offenbar werden selbst essentielle Dinge, wie z.B. das Ansprechen von Endlagenschaltern, nicht immer zuverlaessig erkannt, das hat schon zu Zustaenden gefuehrt, die die Mechanik gefaehrdet haben. Wir koennen aber nicht voellig ausschliessen, das das auch mit den verwendeten Steuerkarten zu tun hat.

3. Darstellung von Messergebnissen: Unter anderem wird ein eindimensionaler positionsempfindlicher Detektor eingesetzt ( mit multi channel analyzer). Die Daten werden als zweidimensionales Feld abgespeichert. Fuer die Beurteilung der Messung ist eine bildliche Repraesentation nach einer Koordinatentransformation (schiefwinklig, krummlinieg) erforderlich. Das ist z.Zt. ueber pseudofarbige bitmap realisiert. Im Prinzip ist da ausreichend, aber die Transformation erfolgt nicht korrekt und das Bitmap ist in der Darstellung nicht befriedigend (kein 'dichtes' bitmap, Farbkodierung unbequem und nicht flexibel genug).

4. Erweiterung: Die verwendeten Motorsteuerkarten werden nicht mehr produziert. Es waere daher erforderlich, die Nachfolgemodelle zu beruecksichtigen. Weiterhin muessen wir demnaechst einen neuen Detektortyp beruecksichtigen, der Daten 1- oder vielleicht sogar 2-dimensional erfasst.

Wir sehen keine Moeglichkeit auf einen anderen Rechnertyp als PC ueberzugehen und die vorhandenen PC's weiter zu nutzen.

7. Welcher C++ bzw. welcher C++-Compiler war die Grundlage fuer die Entwicklungsarbeiten?

Borland C++ , zuletzt Version 4.52

8. Wie dringend sind die Arbeiten?

Bearbeitung binnen 12 Monaten ist adaequat.

9. Wer soll in Zukunft die Pflege des Programms uebernehmen und mit welchem Ziel (sind z. B. noch groessere Erweiterungen geplant)?

Das ist eine schwierige Frage. Natuerlich waere es hervorragend, wenn wir Unterstuetzung von aussen dazu bekommen koennten. Da das sicher nicht zu machen ist, waere es schoen, wenn jene Teile, die die reine Ablaufsteuerung betreffen, hinreichend isoliert und so ohne tiefere Kenntnis des Gesamt-Programms aenderbar waeren. Dann koennten unsere Doktoranden bzw. unser Ingenieur (ohne Ausbildung in Programmierung) das Programm an wechselnde Messaufgaben anpassen. Eine Einbindung neuer Hardware ist so sicherlich nicht moeglich. Allerdings werden wir wahrscheinlich in den naechsten Monaten neue 2 neue Detektoren haben, deren Einbindung ggf. in die Aufgabe einfliessen koennte. Ebenso moechten wir eine neue Motorsteuerkarte kaufen, damit diese ebenfalls gleich beruecksichtigt werden kann.

Ich waere Ihnen sehr dankbar, wenn Sie uns bezueglich des Programms tatsaechlich unterstuetzen koennten.

Mit freundlichen Gruessen Rolf Koehler

	Erste Anfrage der Physik	Rückfragen von uns	Antwort auf die Rückfragen	Email an die Physik	Antwort von uns

Email an die Physik

(29.03.99)

Lieber Herr Koehler,

am 1. 4. 99 - also zu Semesterbeginn - kann ich nun eine studentische Hilfskraft aus unseren Projektmitteln mit 40 Stunden / Monat einstellen. Dieser sowie ein zweiter Student wollen auf diesem Gebiet auch eine Diplomarbeit schreiben. Damit steht von nun an etwas mehr zeitliche Kapazitaet fuer unsere Aufgaben zur Verfuegung, nachdem das Seminar eine erste Aufarbeitung der Programmquellen ermoeglicht und die Teilnehmer fuer die Thematik interessiert hat.

Was die vorgefundenen Quellen anbelangt, so haben wir eine Reihe von Defiziten ermittelt (u. a. schlechte Softwarearchitektur, d. h. Struktur der Komponenten; z. T. unstrukturierter interner Programmcode; Mischung zwischen imperativem C-Code und objektorientiertem C++-Code, Verletzung von Prinzipien der Softwareergonomie in den Dialogfenstern ...), ganz abgesehen davon, dass keinerlei Programmdokumentation und Kommentierung vorliegen, so dass wir alle relevanten Informationen aus den Programmquellen ableiten muessen. Damit bietet das vorhandene Programm unguenstige Voraussetzungen fuer die Wartbarkeit (aendern, erweitern). Vor Erweiterungs- bzw. Aenderungsaktivitaeten muss damit erst eine saubere Struktur erstellt werden.

Ich moechte aber betonen, dass o. g. Zustandsbeschreibung in erster Linie keine Kritik am Entwickler des Programms ist, sondern vielmehr der Normalfall von Softwareentwicklungen, bei denen ein Programm schrittweise erweitert wird, wobei sich die Struktur normalerweise immer weiter verschlechtert.

Abschliessend noch ein Wunsch: Vielleicht koennten Sie aus heutiger Sicht die Dringlichkeit Ihrer Wuensche bzgl.
Programmerweiterungen bzw. -aenderungen noch einmal zusammenfassen, so dass so etwas wie eine Prioritatenliste entsteht. Was ist also wichtig, was weniger wichtig? Dabei sind wir an einer moeglichst genauen Beschreibung der Aufgaben
interessiert. Ausserdem: Wie dringend sind die einzelnen Aufgaben (Wunschtermine: kurzfristig, laengerfristig)?

Unser Seminar setzen wir im SS 99 fort, und ich hoffe damit auf weitere Interessenten an Diplomthemen.

Mit freundlichen Gruessen

Klaus Bothe

P. S. In den letzten beiden Wochen vor Vorlesungsbeginn habe ich Urlaub, ebenso meine Kollege, Herr Sacklowski.

	Erste Anfrage der Physik	Rückfragen von uns	Antwort auf die Rückfragen	Email an die Physik	Antwort von uns

Antwort an uns

(23.04.99)

Lieber Herr Bothe,

vielen Dank fuer Ihre Mail. Ich bin froh, dass es so gut voran geht. Ihre vorangehende Mail hatte ich auch bekommen und meine Mitarbeiter, die mit dem Programm arbeiten, aufgefordert, Ihnen die gewuenschten Prioritaeten zu nenne. Das ist leider nicht geschehen, wie ich auf Ihre zweite Mail hin herausbekommen habe.

Ich habe nun mit meinen Mitarbeitern diskutiert. Die wichtigste Anforderung ist leider nicht genau eingrenzbar:

1. Stabilität (!!) und volle Funktionstüchtigkeit bei den bereits realisierten Funktionen.

2. Erleichterung der spaeteren Einbindung weiterer Hardware (vor allem Detektoren), dh. wohl definierte Schnittstelle samt Dokumentation.

3. Einbindung eines neuen Detektors (r?ntgenempfindliche CCD-Kamera)

4. Eine neue Funktion: Automatische Optimierung (Justage). Dies wuerde beinhalten, dass zuerst in der Routine "Topography" drei Antriebe (Beugung fein, Kollimatorkruemmung, Tilt) so justiert werden, dass in diesen Koordinaten Maximalintensitaet erreicht wird. Einfache alternierende Verstellung der Antriebe ist eine schlechte Strategie. Ein stabiles Gradientenverfahren waere erforderlich.

Wenn es um die Prioritaeten bei einem Neuaufbau (?) des Programms geht, so ist es fuer uns erst ab einem bestimmten Vollstaendigkeitsgrad ueberhaupt einsetzbar.

Eine erste Stufe muesste eine Bedienung aller Antriebe erlauben und mindestens die Anzeige fuer einen (Einkanal-) Detektor enthalten. Eine Anlehnung an bisher vorhandene Oberflaechen ist nicht erforderlich. Es waere nicht schlecht, wenn mehrere jeweils aktuell wesentliche Antriebe parallel angezeigt wuerden, im jeweils zugeordneten Sollwertfenster dann jeweils mit der Tastatur ein neuer Wert eingegeben werden kann, der dann anzufahren ist. Ein aktiver Antrieb sollte wie bisher auch ?ber Cursortasten bedienbar sein und sowohl Schrittbetrieb (einstellbare Schritte) als auch kontinuierliche Fahrt (einstellbare Geschwindigkeit) erlauben. Wenn die Intensitaetsmessung (Detektor) dann unabh?ngig erfolgt (wie bisher auch; einstellbare Messperiode), so ist das ausreichend.

Eine Verknuepfung von Antrieb und Intensitaetsmessung (etwa Messung einer Kurve) koennte ein zweiter Schritt sein. Dabei koennte man sich auch erst einmal auf den Einkanal-Detektor beschraenken. Erforderlich waere dann einerseits eine Fortschrittsanzeige am besten in Form einer Intensitaetskurve bis zum jeweils erreichten Punkt. Nicht schlecht gefallen haben uns in dieser Hinsicht Diffraktometerprogramme, bei denen die Skalierung dieser Kurve vom Nutzer eingestellt und jederzeit geaendert werden kann. Es muess natuerlich auch die Abspeicherung der Messdaten gewaehrleistet werden, ab besten
Abfrage vor der Messung und automatische Abspeicherung nach der Messung. Schoen waere es, wenn auch Kurvenscharen gemessen werden koennten. Zu der bei der Kurvenmessung (evtl. 2 Antriebe simultan) und bei der Kurvenscharmessung (schrittweise Verstellung eines Antriebs zwischen zwei Kurven) sind sicher noch detailliertere Absprachen erforderlich.

Man koennte im naechsten Schritt weitere Funktionalitaet 'revitalisieren', die sich auch auf einen Einkanal-Detektor bezieht, vor allem jene, die mit Topographie zu tun hat, d.h. die automatische Antriebsregelung zur Kompensation von Drift (automatisches Halten der Intensitaet).

Im weiteren muesste dann der Vielkanal (aber 1D) - Detektor (PSD) wieder integriert werden. Die Kurvenanzeige koennte hier wieder eingesetzt werden, aber zur Anzeige der Vielkanalmessung. Da auch ein Kanal fuer die integrale Intensitaet vorhanden ist, waere es nuetzlich, diese parallel anzuzeigen. Sowohl bei den oben erwaehnten Kurvenscharen, als auch bei den
'Kurven' mit PSD fallen 2D-Datensaetze an. Es waere schoen, wenn nach Fertigstellung der Messung (toll waere, das auch bei der Messung zu ermoeglichen) eine 2D (Bitmap) Darstellung aufrufbar waere. Wir hatten eine solche Darstellung integriert, die sogar die Umrechnung von Winkelkoordinaten auf jene im reziproken Raum vornahm - aber offenbar recht fehlerbehaftet ist.

An welchem Punkt evtl. eine Optimierung der Antriebsparameter eingebaut werden koennte, ist mir unklar. Der Weg ueber ein Konfigurationsfile, das man editieren kann, sollte weitgehend ausreichend sein. Allerdings haben wir gelegentlich von den bisher vorhandenen (halb)automatischen Optimierungsmoeglichkeiten Gebrauch gemacht.

Wahrscheinlich ist Ihnen Obiges noch nicht konkret genug. Wir sind natuerlich jederzeit bereit, mit den Bearbeitern zu sprechen. Wir koennen gern versuchen, eine Art Pflichtenheft zu erarbeiten, der notwendige und wuenschenswerte Funktionalitaet auflistet. Ich habe aber den Eindruck, dass das iterativ am besten ginge, da dann der aus unserer Sicht wuenschenswerte Ablauf mit jenem abgestimmt werden koennte, der sich aus der Bearbeitung des Programms ergibt.

Mit besten Gruessen Rolf Koehler

***************************************************************
Prof. Dr. Rolf Koehler
Institut fuer Physik - AG Roentgenbeugung
Humboldt-Universitaet zu Berlin
D-10117 Berlin
Hausvogteiplatz 5-7
Tel.: +49-30-20246-734
Fax: +49-30-2044536
email: rolf.koehler@physik.hu-berlin.de
***************************************************************

. Projekt: Software-Sanierung