Tagesordnung

Umgebungssimulator

Kay Schützler

• Entschuldigung fürs Zuspätkommen
• Motivation
• Umgebungssimulation um Softwareentwicklungen zu testen
• nicht immer ist das Testen in der realen Umgebung möglich (Hardware nicht verfügbar oder zu empfindlich, Entwicklungs- und Einstatzort liegen nicht zusammen)
• Nachteile von Umgebungssimulatoren
• Testen ist erst zu späten Zeitpunkt möglich (System muß in der Entwicklung weit vorangeschritten sein
• Zusatzaufwand für die Entwicklung des Umgebungssimulators
• Was ist bei uns als Ansatzpunkt für die Umgebungssimulation vorhanden?
• bei Motoren und Detektoren gibt es Ansatzstellen f¨r die Simulation
• vorliegende Simulation der Motoren ist nutzbringend, berücksichtigt Positionierungsungenauigkeiten
• Verwendung des Testmotors läßt sich nur durch Ini-File einstellen
• Testdetektor TDevice verwendet einen mathematischen Ausdruck zur Berechnung der Intensitätswerte (ca. 1/x²)

->Werte sind nicht realistisch
• TDevice beachtet den Kollimator nicht (Wert wird auf Null gesetzt)

-> problematisch: Wo sollte Kollimator Wert hinzugerechnet werden?
• Nutzen des vorhandenen Testmotors und Testdetektors zum Testen der Oberfläche

->Testen der Motor- bzw. Counterklassen ist nicht möglich
• wir benötigen auch Test fü Motor- und Counterklassen

->Werte müssen an eine Speicherstelle geschrieben werden
• W¨nsche an einen Umgebungssimulator
• möglichkeit mehere Proben zu testen bzw. Parameter der Proben zu ändern
• Oberfläche für Simulator
• auch zukünftige Hardware soll testbar sein
• Datenerhebung bei der Physik
• 9 Kollimatorstellungen (-280 bis 280), 17 Tilteinstellungen (-40 bis 40) und 601 DF-Einstellungen (-300 bis 300)
• Daten durch Ausführung Makro ermittelt -> da Makro komplett in Speicher geladen wird, kommte es bei Makros mit mehr als 1200 Zeilen zum Systemabsturz -> Meßwerte für Kollimator wurden weit auseinanderliegend gewählt
• Kai Schützler hat eigenen Testdetektor entwickelt, der möglichst realistische Werte liefert
• Testdev:public TDevice
• Erweiterung war leicht möglich, da Zugriff auf Counter immer über polymorphen Zeiger erfolgt
• aktuelle Meßwerte werden in ein dreidimensionalen Feld eingelesen
• Funktion Testdev::PollDevice wurde überladen
• PollDevice berechnet die "angeforderten" Meßwerte
• Testdev ist noch nicht im cvs
• counters.cpp für Testdev erweitert
• für Tilt-Wert erfolgt lineare Interpolation
•  
• beim Kollimator ist lineare Interpolation nicht möglich aufgrund der großen Meßwertabstände, es erfolgt eine Rundung auf den kleineren Wert
• Ausblick:
• bisher nur Zählrohr
• 1-dim evtuell auch 2-dim Detektoren simulieren
• Zähler soll vom User noch weiter konfigurierbar sein über graphisches Interface
• Motorleute wünschen sich Reflexpunktangabe
• komplette bzw. umfangreichere Umgebungssimulation

-> unter Win 16 mit shared memory beschäftigen
-> eventuell weiteres Projekt
• bevor Testumgebung entwickelt werden kann, muß verstanden werden, was das System machen soll, damit bekannt ist, welche Werte das System aus der Umgebung erwartet
• fü Tilt wäre ein gröerer Testwerte bereich nötig
• Was hat sich zum alten Testdetektor geändert?
• Kollimator erweitert
• Werte entsprechen einer realen Meßung
• etwa 200 LOC sind neu; eine neue Klasse

Demonstration der Meßkurven

Terminplanung

nächstes Treffen am 23.5.2000 um 15 Uhr

• jeder hält einen 15 min Kurzvortrag zu seinem aktuellen Stand
• Diskussion zur Wiedergewinnung von Software-Architekturen (Schwerpunkt use cases)

18.5.2000 17 Uhr Großer Hörsaal Vortrag Zeitverhalten von Systemen (Abschätzung der oberen Grenze)

Sonstiges

Was wird zum "Test" gebraucht?

jetzt neu auf den Web-Seiten Grundlagen zum Reverse Engineering

• Konferenzen
• Web Adressen
• Definitionen
• Reengineering Tools