Home
pdf-Format - Institut für Informatik
Contents
1. TManJustage Be 1 ol 1 a 2 L gt TMotorData 8 ol o 0 o om ee 0 1 TManJustageDig 6 48 1 5 88 9 4 54 6l Ir TMotor ffsetDig 3 5 1 2 e 22 n 27 a 1 TPsdoffsetDlg 3 a 1 2 57 29 1 27 a 1 Tab 11 5 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Polling Variante am Ende der Designphase Subsystem Subsystem Benutzeroberfl che Utilities TBasicDialog lt interface gt Tfimer TModalDlg Timer 0 1 TinterfaceTimer N N EL CD HE W i a A A N Er ul w m_inkTimer m_InkManlustage m_InkidanJustane e NN 0 1 m_inkbManlustage lm Motorlist D Ye lt lt struct gt m_InkDetecior Subsystem neue Manuelle Justage DA TDetector TOneDimDetector Lee Subsystem Subsystem Detektornutzung Motorsteuerung Abb 11 36 UML Klassendiagramm f r das OOD Modell der neuen Manuellen Justage mit Polling Variante und bersicht der benutzten Subsysteme Dekomposition beim Forward Engineering 11 3 Designphase Seite 67 Ss KERS Q Z IManJustageDig D 6 0 0 0j 100 0 1 UN Te TManJustage 6 61 10 90 46 3 SI L TMotorData 7 ol ol o 100 57 ol ui TManJustageDlg D 48 1 10 78 18 1 An P 1 IMstor rfserDl ee unver ndert zu Tab II 5 TPsdOffsetDlg Tab 11 6 Ausgew hlte Metriken f r die K
2. 2000000000000000s00000000sssscccee 25 Abb II 6 Auszug aus dem Anhang des Pflichtenheftes M16 bersicht aller Datenelemente Hervorhebung schwarz die vorhandenen blau die abgeleiteten und rot die neuen Elemente ccceee 26 Abb II 7 Auszug aus der Gliederung des Pflichtenheftes M16 Kapitel Daten 26 Abb II 8 Auszug aus der Gliederung des Pflichtenheftes M16 Kapitel Benutzeroberfl che 27 Abb II 9 Auszug aus dem Teil Benutzeroberfl che des Pflichtenheftes M16 28 Abb 11 10 Neuentw rfe des Hauptdialogs Manuellen Justage NEU oben Dialog Offset f r lt PSD gt links und Dialog Offset f r lt Antrieb gt rechts 30 Abb IL 11 Entwicklung der XCtP Hilfe 000000000000s00000000s000seenn0uunnn0onnnnnnssnnssssssensnnnnnnsssnsnnssssnnenseeee 32 Abb 11 12 Verlinkung des Hauptdialogs mit den Hilfe Seiten f r die jeweiligen Steuerelemente am Beispiel der Funktion Relative Null setzen ein Rahmen entspricht einer Hilfe Seite 33 Abb 11 13 gek rzter Auszug aus dem Benutzer Leitfaden M17 Kapitel Referenzteil 35 Abb II 14 Auszug aus dem Referenzteil des Benutzer Leitfadens M17 22cccccccesssss000000sssssssceee 36 Abb 11 15 Auszug aus dem Trainingsteil des Benutzer Leitfadens M17 zur Schrittfolge f r Relative Null von Tilt aufheben
3. 00000000s000000000000000000000000 37 Abb II 16 Auszug aus dem Datenteil des Pflichtenheftes M16 2 000000000000000000000000s000c e 39 Abb 11 17 Auszug aus dem Funktionsteil des Pflichtenheftes M16 2 000000ssss0000000s0s000 e 39 Abb 11 18 Auszug aus dem Funktionsteil des Pflichtenheftes M16 0000000ssss000000ssssccc e 40 Abk 11 19 UML Klassendiagramm f r das OOA Modell der neuen Manuellen Justage gegliedert nach der Erstellungsreihenfolge ihrer Elemente 000uuuuuouoooooouuuuonunnnnnnccee 41 Abb 11 20 Gegen berstellung der von den Autoren vorgeschlagenen Definitionsphase links zur Allgemeinen rechts 0000000u00000ssssss00ssssssssnnnnnnnnnssssssssssssee 42 Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Abb Dekomposition von Software Systemen Abbildungsverzeichnis 11 21 Allgemeines Implementierungsschema f r eine Set Methode mit CanSet 46 11 22 UML Klassendiagramm f r die Funktionskomponente der neuen Manuelle Justage gegliedert nach der Bearbeitungsreihenfolge ihrer Elemente 47 11 23 UML Klassendiagramm f r die Dialogfensterklasse TManJustageDlg gegliedert nach der Erstellungsreihenfolge ihrer Elemen
4. ccc00000ssss0000ssssssssnnnnnnnnnsssssssssssese 64 11 36 UML Klassendiagramm f r das OOD Modell der neuen Manuellen Justage mit Polling Variante und bersicht der benutzten Subsysteme uscesssssessssnsnsnssnonsnnnnnnnnnnnnnnn 66 11 37 UML Klassendiagramm f r das OOD Modell der neuen Manuellen Justage mit Observer Muster und bersicht der benutzten Subsysteme uceossssessssssnsnssnsnsnnnnnnnnnnnnnnn 67 11 35 Auszug f r einen Methoden Eintrag aus dem Designdokument M20 69 11 39 Auszug aus dem Funktionsteil des Pflichtenheftes M16 00000000000000000000000 69 11 40 Implementierung der Bedingung f r den Direktbetrieb Methode CanDoDirect 70 11 41 Auszug f r einen Methoden Eintrag aus dem Designdokument M28 des Subsystems Motorsteuerung ssssssssssssnnssssusennnssnnnssnsnnnsnssnsssssusannunsnnnssnsnnssssnnsnssssssnnnnsnnee 70 11 42 Fortsetzung der Implementierung des Direktbetriebs Methode DoDirect unter Benutzung von CanDoDirect und Methoden des Subsystems Motorsteuerung 70 11 43 Absicherung von Lese und Schreibzugriffen und zur berpr fung von Parameter bergaben in TManJustage ssssssssssssssssssssssssssssnunsnnnssssssssssssssssssssssnsnnnnsssssssssssnse 71 II 44 berpr fung ob der bergebene Parameter g ltig ist eu eecesesessssesnsnssnnnsnennnnennnnennnnnnnne 71 11 45 Nutzung der Mutator Methode SetOffset anstatt eines Direkt
5. kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Klasse f r Druckeransteuerung void TPrinter DoSpoolerJob Versuch n chsten Druckauftrag zu verarbeiten DoPrint Spooler GetJob CanDoPrint hier nicht erforderlich weil Teil von DoPrint bool TPrinter CanDoPrint seit Zwischenstand unver ndert void TPrinter DoPrint seit Zwischenstand unver ndert FRGFRNIS Abb 11l 9 Konstruiertes Beispiel f r die Auslagerung einer CanDo Methode v Diese Vorgehensweise steigert die Robustheit bei der Neuimplementierung einer Nutzeroberfl che Am Ende ist wieder zu kompilieren zu linken und ein Regressionstest der benutzenden Subsysteme ist durchzuf hren Dekomposition beim Reengineering Ill 2 Restructuring Seite 113 10 Entfernen gleicher Do CanDo Methoden Abschlie end sind jeweils die Do M und die CanDo Methoden untereinander zu vergleichen Bei zwei identischen Methodenr mpfen kann eine Methode entfernt werden Bei Do M m ssen auch die gerufenen CanDo Methoden identisch sein um ein Do CanDo Methodenpaar entfernen zu k nnen Jede Benutung der entfernten Methode ist durch den Aufruf der verbliebenen identischen Methode zu ersetzen Wenn eine Do Methode nur aus der Auswertung einer CanDo Methode und dem abschlie enden return true besteht sind Do und CanDo Methode identisch In diesem Fall ist die Do Methode zu entfernen und ihre Aufrufe sind durch
6. M32 M Gollnick U Sacklowski Start und Kontrolle der Topographie Version 3 0 M33 U Sacklowski Topographie Me protokoll_Buch Version 1 0 M34 U Sacklowski Topographie Fehler erstellt 19 06 2000 M35 T Kullmann G Reinecker Designbeschreibung zum Reengineering der Topographie Version 1 4 M36 J Hanisch Regressions Testf lle Topographie Version 2 3 M37 T Kullmann G Reinecker neue Topographie Funktionskomponente CTE XL Diagramm e erstellt 17 07 2002 M38 T Kullmann G Reinecker neue Topographie Nutzeroberfl che CTE XL Diagramm e erstellt 17 07 2002 SUBSYSTEM WINDOWS RESSOURCEN M39 T Kullmann G Reinecker Ressourceniibersicht erstellt 01 06 2002 Seite 144 Anhang C Stichwortverzeichnis Anhang C STICHWORTVERZEICHNIS A Abstract Desien Objects EE 50 Abstract Desien VIEW eurini ende lee ee een 50 Abstract Desien A WT EE 50 AC Codemetiik Attribute Complexity sense sau a I Ea 20 CES lettres 38 Application Programming Interface 0000000oooenonnnnnsssssssssseeerrsensssssssssssrererosnsssssssssseerrreoesssssssssseererreesesssssss 12 Artetak te 2 ee 21 EA E E EE 110 B Basisaniorderunsen un 2 0er EN 18 benutzenden Subsystem sesiones ak lebe 104 Benutzer Leitfaden Benutzerhandbuch 000 00insoeenesessssenssssssssnsssessssrsssessssrsssersssressersserssstrsseresserssersseresere 34 Beobachter Obhserxwer Muster 51 Beziehungsiypen ans REN a
7. ZanDolrvelEDirecton ZanDostepdEDirection ZanDoSstopf ZanDostarMeasuren ZanDostopMeasurei Zansetlhannelt TManJustage m _MotorList TMotorData nn n m_PSD TPsoData GetChannelMaxl gt 0 1 GetAnglePerChannel GethiotorNameg m _MotorList m_FSD0 Get ep GelAnglel GetAngleMind GelrAngleMaxl Gell wot Getofseti GetMotion Type GetAngleDesth GetSpeedi GetSspeedMind GetSpeedhiaxi GetAngleidthi Ger AngleWidthhlind Get ngleidthhlaxi SetMotionType SetAngleDest SetSpeedi Sset nglewsidtho zanselMotonTypeo zanselAngleDesto zanselspeedi CansetAngleidthi m_MotorMame m Llntt m_Angle m_Anglehir m_AnglehMax m_Digits m_Ofset m_MotionType m_Anglebest m_Speed m_SpeedMin mm DppGdhd a m_Anglewidth m_AngleWidthbin m_AngleWidtbax TManlustagen TManJustageo PS a Gewinnung von Attributen m_Channel EZ b Accessor und Mutatormethoden m_Channelklim EZ c Methoden zur Realisierung der m_ChannelMax Funktionalit t m_AnglePerChannel EZ weitere Methoden Abb 11 19 UML Klassendiagramm f r das OOA Modell der neuen Manuellen Justage gegliedert nach der Erstellungsreihenfolge ihrer Elemente 11 2 6 Zusammenfassung Die Dekomposition konnte in der Analyse und Definitionsphase nur beim Pflichtenheft angewendet werden Dazu wurden dieses nachtr glich um den Oberfl chenentwurf erg nzt siehe Abb 11 20 linker Handlungsstrang Die Mitarbeiter
8. break A andere Botschaften behandeln void TAngleCtl DoStartMeasure HWND aWnd Delegieren durch Aufruf von Methoden des Subsystems Ablaufsteuerung void TAngleCt1 DoStopMeasure Steering Reset AUSGANGSZUSTAND void IAngleciLIDlog DIg OnCommand AWND int ald HWND UINT switcha are case cm_MeasureHWB Halbwertsbreite messen abbrechen if m_InkAngleCt1 gt DoStopMeasure Messung ist aktiv abbrechen A Aktualisieren der Nutzeroberfl che else if m_InkAngleCtl gt DoStartMeasure Messung hat begonnen CtrlSetText cm_MeasureHWB amp Messung abbrechen break andere Botschaften behandeln BOOL TAngleCtl CanStartMeasure return m_InkAngleCtl gt IsMeasuring S IsMoving gewonnen aus der Nutzeroberfl che BOOL TAngleCtl DoStartMeasure HWND aWnd if CanStartMeasure return FALSE Delegieren durch Aufruf von Methoden des Subsystems Ablaufsteuerung return TRUE BOOL TAngleCt1l CanStopMeasure return m_lInkAngleCtl gt IsMeasuring gewonnen aus der Nutzeroberfl che BOOLTTAnglelt 1 DostopNMeasurei if CanStopMeasure return FALSE Steering Reset return TRUE ERGEBNIS Abb 111 13 Beispiel zur Gewinnung zus tzlicher Bedingungen f r CanDo Methoden 10 Entfernen gleicher Do CanDo Methode Durch den relativ geringen Funktionsumfang der getrennten Manuellen Ju
9. Anschlie end wurde der in Abb IlI 47 vorgestellte Mechanismus zur Geschwindigkeitsoptimierung in die Nutzeroberfl che integriert Bevor hier eine umfangreiche Bildschirmaktualisierung beginnt wird die Funktionskomponente in den Zustand bzw berf hrt damit die wirklichen Hardwarezugriffe reduziert werden Am Ende der Aktualisierung wird die Funktionskomponente wieder auf default zur ckgesetzt Weil diese Verfahren allein jedoch nicht ausreichten werden die Teilbereiche nun quasi parallel aktualisiert Dies erfolgt wieder durch den oben vorgestellten Not ice Mechanismus Damit k nnen die Teilbereiche gleichzeitig auf Antworten der Hardware warten Als letztes besteht noch die M glichkeit die Zustandsaktualisierung freigeben bzw sperren und ausgrauen der Steuerelemente ber die Konfigurationsdatei vollst ndig zu deaktivieren ber den Eintrag StateRefresh kann bestimmt werden dass die 19 entweder Antrieb bewegt sich oder er befindet sich im Stillstand Seite 78 Dekomposition beim Forward Engineering IA Implementierungsphase Zustandsaktualisierungsmethoden sofort verlassen werden Die Steuerelemente bleiben stets freigegeben Das hat jedoch keinen Einfluss auf die Aktualisierung des Inhaltes z B der Beschriftung der Steuerelemente Bei der Benutzung von eigentlich gesperrten und ausgegrauten Steuerelementen erfolgt keine Reaktion Die Funktionskomponente ist durch die Verwendung der Can Methoden robust g
10. Sobald sich mehrere u U verschiedene Oberfl chen an einer Funktionskomponente anmelden k nnen m ssen diese ein einheitliches Beobachter Interface besitzen Wenn Ereignisse nur durch bestimmte Oberfl chen behandelt werden sollen dann muss die Art des Ergebnisses in der Methode des Beobachter Interfaces durch zus tzliche Parameter bertragen werden Das Oberfl chenfenster kann nach Auswertung dieser Parameter entscheiden ob das Ereignis zu behandeln ist siehe 8 Creational Patterns gt Observer gt push model Damit w re f r die Funktionskomponente nur ein Subjekt Interface erforderlich Der dort implementierte Verwaltungsmechanismus kann auch direkt in das Konkrete Subjekt integriert werden ein Subjekt Interface wird dann nicht ben tigt interface Oz Obert onRefrashl TRefteshinfol vold N N Topert TOberfl2 Topert m_InkFunktTFunkt m_InkFunktTFunkt m_InkFunktTFunkt OnrRefeshiTRefeshlnfolwoid OnrRefreshiTRefreshlnfonvoid OnrefreshiT KEREN d efreshlnfolwoie m_InkFunkt m_InkFunkt T m_InkFunkt e UN ef i l m_InkListener m_InkListener lOberf HinzufuegendlOber void Entfernendl bem void D 1 Benachrichtigend TRefreshlnfo voic Abb 11 32 Bsp f r Observer Muster bei 3 1 Im komplexesten Fall greifen mehrere Nutzeroberfl chen derart auf mehrere Funktionskomponenten zu dass die beiden vorher beschriebenen Varianten verkn pft zur Anwendung kommen m n Auc
11. Diagr f fin femena Abb 1 11 OLE Automation mit Microsoft Excel aus einem anderen Programm heraus 1 starten 2 Datenerfassung 3 Diagrammerstellung ber ActiveX kann z B die Funktionalit t des kompletten Microsoft Office Pakets in eigenen Anwendungen verwendet werden Einen guten Einstieg ins Thema COM bietet 11 1 4 5 Makrosteuerung hnlich ActiveX siehe 1 4 4 gestattet die Makrosteuerung die Automatisierung und Zusammenfassung von Arbeitsabl ufen Dazu werden Makros vom Programm interpretiert und abgearbeitet Diese entsprechen Anweisungsfolgen die ausgew hlte Produktfunktionen realisieren Komplexe Arbeitsabl ufe sind so problemlos reproduzierbar Insbesondere wiederkehrende Aktionen die im eigentlichen Programm nur ber viele Men aufrufe Tastendr cke oder Mausklicks realisiert werden k nnen Heutzutage beinhalten viele Programme bereits eine solche Makroverarbeitung um die Arbeit mit dem immer umfangreicheren Funktionsangebot effizient zu erm glichen Zudem besteht manchmal die M glichkeit einen Makrorekorder zu implementieren der die Aktionen des Benutzers aufzeichnet und selbst ndig in ein Makro umwandelt Um Makrosteuerung und rekorder in die eigene Anwendung zu integrieren empfiehlt sich jeweils die Erstellung eines eigenen Subsystems Makros sollten ausschlie lich auf der Ebene der Funktionskomponente arbeiten Jede einzelne Anweisung in einem Makro kann so auf den Aufruf von Methoden einer
12. DoMeasuregoniralflankwaid DoSbopWessur BTL DoSetDetectorParams wold Ooresetbetechrfaramswoid booSavehlonitorSignalB odL DoSavehiolorSetings BOWL DoLgadhotorsetingds BOOt oer mes wot DoSetTimeExceadedwoid DorReselTimesroid 0 1 Do5elTimeS opnedimid Doniyor DCOL RE DoStartea sure BOOL m_mstance m_InkTopagraphr m_nKTopaograpfr es 2 m_Ir mir rm Jonk dir opa raphi I Time il TinaruliEspose TTirmet Jaramoid ld opograpmy Seite 130 Dekomposition beim Reengineering Ill 2 Restructuring 111 2 2 Zusammenfassung Anwendungsfall Manuelle Justage Dateien e Funktionskomponente MJ_OFUNK CPP MJ_OFUNK H e Nutzeroberfl che MI _OGUI CPP MJ_OGUI H Klassendiagramm Subsystem Subsystem Benutzeroberfl che Utilities TBasicDialog TModalDig AR za db m_InKTimer Subsystem tn Sensor getrennte Manuelle Justage D i TDetector O l Led Dokumentation Subsystem Detektornutzung Analyse Definitionsphase o Verhaltensspezifikationen Verhaltenspezifikation Pflichtenheft XCTL Steuerprogramm M14 o eine kurze Use Case Beschreibung Design Implementierungsphase e Testphase o Regressions Testf lle Manuelle Justage Version 2 2 von Jens Hanisch M21 e Fehler bersicht o Fehler in der alten Manuellen Justage NEU M19 Tab 111 3 bersicht zur getrennten Manuellen Justage Polling Variante M
13. Percentage of Public Membere 20 Produkt Deimton tee 21 Produkt Modell 22 3 22 22 ae seele 21 Prototyping Komplexit tsbew ltigung 00000000nnnnennonnnssssssoeeeerssnsssssssssssrerrresnsssssssssseerrreerssssssssssserrrreeesssssss 14 publish subscribe Observer Muster 00000000ooonnnnnnnnsssssssssseterrssnsssssssssssrerrresnsssssssssserrrreeessssssssssseterreesesssssss 51 R Referenz Handbuch Benutzerhandbuch 00 aoeenesensssenssenssenssssnssensssesssersssesssersssrssscrsserosstreseressersseresserssere 34 RKererenzprod k eeoa ee EO OENE ee De ee else 18 SET EE 5 S S ngleton Muster assu E O E 51 Seite 146 Anhang C Stichwortverzeichnis SO ware ErPonomle a kennen 29 SUBJECT ee Siehe Subjekte Subjekte Observer Muster sa uch a Bu a a 51 EH N SLEME sat a ee ee 21 T TER Codemetrik Troe Comment Ratio au 02a IE ER I a 20 Testtreiber autar e EE 89 Testverfahren E EE Siehe funktionaler Test Lu ae NEE 82 pjektorientert EE 82 eaaa EIA A M K E AREETAN res 82 Ett ele Ee Ee a a ee r aa Siehe Strukturtest Toposraphie 2 2 22 es A ie 7 PEPEL E ae ee ONE ee 98 UrSpruneliche EE EE 98 Trainingshandbuch Benutzerhandbuch 00000000nnnnnnnnnennssssssseseeeresnnssssssssserrereorssssssssssererreesensssssssssseerrrerees 34 V dI ON WEE 11 ACEN ee DEE ee EE EE a Ei 11 Te EE Tt EE 50 Z zustandsver ndernde Anweisung es eseeensssesssoetteeronrsssssssssstttereonsssssssssssre
14. Se Der Wertebereich entspricht der Softwareschranke die von der minimal bis zur maximal m glichen Position reicht Die Nachkommastellengenauigkeit wird vom Antrieb bestimmt HARDWARE INI MOTOR lt M gt Abschnitt ganzzahliger Eintrag Digits S Nur wenn die Halbwertsbreite nicht gemessen wird sich der Antrieb nicht bewegt und zudem ein g ltiger Antrieb nicht kein Antrieb im Direktbetrieb ausgew hlt ist kann die Sollposition eingegeben werden Abb 11 14 Auszug aus dem Referenzteil des Benutzer Leitfadens M17 Die m Trainingsteil behandelten Arbeitsabl ufe wurden als Flussdiagramme umgesetzt Um h ufig auftretende Redundanz zu vermeiden wurden mehrfach ben tigte Schrittfolgen in gesonderte Flussdiagramme ausgelagert Auf diese wurde dann nur verwiesen siehe Abb II 15 _ gt Durch die Aufteilung der Komplexit t wurde auch die Lesbarkeit verbessert Bei der Formulierung der durchzuf hrenden Schritte wird der Leser direkt angesprochen siehe Abb 1 15 lt D und so zum Nachvollziehen angeregt M gliche Entscheidungssituationen sind als Fragen formuliert und bin r als Ja Nein Zweige realisiert Genauso wurden Problemsituationen umgesetzt wenn z B die Ausf hrung einer Produktfunktion im aktuellen Zustand nicht m glich ist Dann ist bei mindestens einem Entscheidungszweig 1 d R dem Problemfall dargelegt an welchen Merkmalen dieser im Dialogfenster zu erkennen ist siehe Abb 1 15 C__D Im Hinblick a
15. Topographie und Manuelle Justage durch Arbeiten am Programmcode schrittweise getrennt um eine allgemeine Herangehensweise f r die Dekomposition zu entwickeln Als Ergebnis entstand ein generalisiertes Regelwerk was eine zeitlich effiziente Dekomposition des Programmcodes erlaubt In jeder Softwareentwicklungsphase wird dabei auf die jeweiligen Besonderheiten beim Forward und beim Reengineering eingegangen Dieses Modell bildet aber nur eine exemplar sche Grundlage da die Inhalte dieser Diplomarbeit auch in alle anderen phasenorientierten Prozess Modellen wie Spiral oder V Modell angewendet werden k nnen Die Projektarbeit diente dabei zur Verifikation und Bewertung der Praxistauglichkeit der hier vorgestellten Ausf hrungen Die Voraussetzungen zum Verst ndnis dieser Arbeit sind Kenntnisse in der objektorientierten Programmierung sowie das Wissen ber Struktur und Arbeitsabl ufe bei der Softwareentwicklung nach Prozess oder Vorgehensmodellen insbesondere dem Wasserfall Modell Die Dekomposition wird im Wesentlichen an einzelnen Subsystemen dargestellt Diese Ausf hrungen sind aber so allgemein gehalten dass die Anwendung der Ausf hrungen auf ein komplettes Softwareprojekt problemlos m glich sein sollte 1 1 1 Aufgabenteilung Die vorliegende Diplomarbeit st vollst ndig als Gemeinschaftswerk zu betrachten Der gesamte Inhalt wurde von beiden Autoren gemeinsam erstellt und bearbeitet Dies trifft auch auf alle von den
16. Typ Zugriff Eintrag RP nur lesen bereits vorhanden Speichertyp als Eintrag in einer ini Datei ASCII Text Speicherort HARDWARE INI gt MOTOR lt M gt gt AngleMin Tabelle 8 minimale Istposition D 70 maximale Istposition Bezeichnung maximale Istposition Typ Zugriff Eintrag MP nur lesen bereits vorhanden Speichertyp als Eintrag in einer ini Datei ASCII Text Speicherort HARDWARE INI gt MOTOR lt M gt gt AngleMax Tabelle 9 maximale Istposition D 80 Nachkommastellen Bezeichnung Nachkommen Typ Zugriff Eintrag P nur lesen bereits vorhanden HARDWARE INI gt MOTOR lt M gt gt Digits BT mme Ip Standardwet 3 o O Tabelle 10 Nachkommastellen der Istposition Abb 11 53 Auszug aus dem Dateiteil des Pflichtenheftes M15 Dekomposition beim Forward Engineering Il 5 Testphase Seite 85 Mit den gewonnenen Testdaten lassen sich folgende quivalenzklassen ableiten quivalenzklasse g ltige Eingaben l MOTOR lt M gt gt AngleMin lt Sollposition lt Aquivalenzklasse ung ltige Eingaben 3 MOTOR lt M gt gt AngleMin MOTOR lt M gt AngleMax IMOTOR lt M gt gt AngleMax Die Anzahl der durchzuf hrenden Testf lle h ngt von den Bedingungen f r das Setzen der Sollposition ab Diese sind im Funktionsteil des Pflichtenheftes zu finden siehe Abb II 54 Damit sind im Zustand Direktbetrieb
17. 0nTB_FPFositionsEnable ETE constiwoid 0nTB_OfsetEnable ETE const woid O0nTB_Superise ETE cons woid Moticecconst int ETE constEOOL cons woid Attribute Methoden der Basisklasse n NEU 1 Verwaltung der Teilbereiche Behandlungsroutinen und Aktualisierung eines Teilbereichs NEU 2 weitere Methoden Abb 11 52 Seit dem OOD leicht ver ndert das UML Klassendiagramm f r die Dialogfensterklasse TManJustageDlg Implementierungsphase D i 11 4 3 Zusammenfassung Die Implementierung der Funktionskomponente gestaltete sich trotz ihres gro en Umfangs 635 LOCr und der Vielzahl an Methoden 71 NO sehr bersichtlich Der durchschnittliche Methodenumfang betr gt etwa 13 LOC Durch die seit der OOA bekannte Klassifizierung der Methoden durch Pr fixe konnte die gro e Datei deutlich gegliedert werden Die stark formalisierte Designbeschreibung incl OOD und das Pflichtenheft bildeten die alleinige Grundlage f r die Erstellung der Funktionskomponente Zu bemerken ist auch der hohe Kommentierungsgrad der Komponente TCRr 55 der die Wartung und das Verst ndnis der z T komplexen Bedingungen Can Methoden erleichtern sollte Seite 80 Dekomposition beim Forward Engineering IA Implementierungsphase Die Implementierung der Oberfl chenklassen erfolgte parallel zur Funktionskomponente und durch einen anderen Bearbeiter als den der Funktionskomponente Mit dem stark formalisierten und codenahen Designdokument und dem Pflichtenhe
18. Dann muss ein neuer Referenzparameter siehe Abb IIL 7 avalid zur Do M hinzugef gt werden Dieser wird am Anfang mit false initialisiert Er wird nur am Methodenende auf true gesetzt und kennzeichnet damit dass die Methode bis zum Ende ausgef hrt wurde Die rufende Methode muss diesen Parameter auswerten und sich bei false selbst mit dem Ergebnis der gerufenen Methode siehe Abb II 7 result verlassen Nur bei true darf fortgesetzt werden EStatus TMotorSteeringDlg StartMove double speed E if m_Motor gt IsMoving Motor ist nicht in Bewegung if m_Motor gt SetSpeed speed return SpeedErr unzul ssige Geschwindigkeit else return MoveErr istin Bewegung m_Motor gt StartMove Bewegung starten or m Statusfield SetText Motor wurde gestareee return NoErr Fehlerstatus zur ck an aufrufendes Fenster AUSGANGSSITUATION Estatus TMotorSteeringDlg StartMove double speed bool valid EStatus result m_Motor gt DoStartMove speed amp valid if valid return result die Do Methode wurde vorzeitig verlassen m_Statusfield SetText Motor wurde gestartet return NoErr Fehlerstatus zur ck an aufrufendes Fenster EStatus TMotor DoStartMove double speed bool aValid aValid false Initialisierung des Ausgabeparameters if m_Motor gt IsMoving Motor ist nicht in Bewegung if m_Motor gt SetSpeed speed return SpeedErr unzul ssige G
19. Dekomposition beim Forward Engineering 11 3 Designphase Seite 51 ADOs assoziiert sein und kennt dann den Zustand all dieser Objekte Ein ADO kann aber auch von mehreren ADVs gleichzeitig beobachtet werden In diesem Fall muss f r eine Konsistenz der Zust nde aller ADVs gesorgt werden im Modell die horizontale Konsistenz Ein ADV Modell konformer Softwareentwurf verlangt somit die Dekomposition in Funktionskomponente und Nutzeroberfl che In den folgenden Kapiteln werden nun Design Mechanismen zur Realisierung der Dekomposition nach den ADV Modell Richtlinien vorgestellt Eine ausf hrliche Beschreibung des ADV Modells ist bei 1 zu finden 17 A Anwendung Del der Dekompositon eg Die Verkn pfung einer spezialisierten GUI Klasse ADV mit einem ADO wird durch Delegation realisiert Im einfachsten Fall erstellt die Nutzeroberfl che dazu selbst ein Objekt der Funktionskomponente und verwaltet dieses als Referenz Beobachten mehrere ADVs dieselbe ADO k nnen Objekt und Referenz durch das Singleton Muster siehe 8 Creational Patterns gt Singleton bereitgestellt werden Damit ist nur die Erstellung eines einzigen Objektes m glich um Zustandsinkonsistenzen der ADVs zu vermeiden Haben mehrere GUI Klassen Zugriff auf eine Funktionskomponenten Klasse dann hat jedes Fenster Objekt eine eigene Referenz auf ein und dasselbe Objekt Die views a Relat on ist damit durch das Designmittel Assoziation realisiert Eingaben die der Anwender
20. Dies bietet die M glichkeit Teile solcher automatisch durch Werkzeuge aus anderen Dokumenten oder aus Programmcode erzeugen oder aktualisieren zu lassen oder umgekehrt Programmcode aus Dokumenten zu erzeugen Die Einbeziehung solcher Funktionen in existierende Entwicklungswerkzeuge wird in Zukunft sicherlich an Bedeutung gewinnen Seite 96 Dekomposition beim Forward Engineering Il 6 Fazit und Ausblick Kapitel III Dekomposition beim Reengineering Kapitel III DEKOMPOSITION BEIM REENGINEERING Mit steigender Komplexit t der heutigen Softwaresysteme r ckt der Einsatz des Reengineerings zunehmend auch ins Interesse der Projektmanager weil Neuentwicklungen sehr zeitaufwendig und damit kostenintensiv sind Zudem bleibt das System stets einsatzbereit was Einsatzausf lle auf der Seite der Anwender weitgehend vermindert Abb III 1 beleuchtet diese Aspekte auch aus der Sicht der universit ren Lehre Forward Engineering es ben tigt viel Zeit bis ein bis zum Ende unvollst ndige gro es System fertig Resultate u U daher ist und vollst ndig katastrophale Resultate getestet werden kann Studenten sind sofort mit umfangreichem Programmcode und es ist immer ein ausf hrbares dokumentationen System vorhanden das konfrontiert Alt Systeme beinhalten i d R getestet und verwendet k nnen Erfahrung nahe an viel Kapital werden kann der realen Welt sammeln Reengineering Abb Ill 1 Vorteile des Reengineering gegen ber
21. Kanal ON IV 1 8 PSD Offset IV 3 5 Dialogfenster verlassen IV 1 9 Hilfe IV 3 5 a OR IV 1 10 Dialogfenster verlassen IV 3 5 b Abbruch Abb 11 8 Auszug aus der Gliederung des Pflichtenheftes M15 Kapitel Benutzeroberfl che Die Beschreibung des Steuerelementverhaltens ist prinzipiell genauso aufgebaut wie die einer Produktfunktion Die Nummerierung erfolgt mit B lt bb gt f r Benutzeroberfl che Jeder Beschreibung ist ein Ausschnitt aus dem Dialogfenster vorangestellt der das entsprechende Steuerelement zeigt Abb II 9 __D So ist der Bezug zum Dialogfenster auch bei unbeschrifteten Steuerelementen garantiert Im Kern steht oft der direkte Verweis auf die F lt f gt Funktion siehe Abb II 9 __ nderungen oder zus tzliche Bedingungen speziell f r die Oberfl che sind separiert siehe Abb 11 9 lt _ gt z B Zust nde der anderen Teilbereiche die beachtet werden m ssen Seite 28 Dekomposition beim Forward Engineering Il 2 Definitionsphase Antrieb ausw hlen J ist auszuf hren Die Steuerelemente sind je nach Art und Zustand des gew hlten Antriebs entweder freizugeben oder zu sperren und auszugrauen nderungen Bei derA Auswahl des speziellen Eintrags kein Antrieb sind alle Steuerelemente im Teilbereich bis auf Antrieb ausw hlen selbst zu sperren und auszugrauen Der ausgew hlte Antrieb ist zu speichern siehe Ill 2 Antriebsauswahl nn nn E RELATIV
22. Subsystem unver ndert bleiben sollte Konnte auf die vorhandenen Regressionstestf lle M18 zur ckgegriffen werden Diese deckten bereits ein repr sentatives Funktionsangebot ab und konnten nach der Erstellung von Testskripten f r ATOS automatisch abgearbeitet werden Ein integrierter Assistent erm glichte eine einfache Erstellung der Skripte Zur Adressierung der Steuerelemente wurden die Dialogressourcen verwendet Trotz dieses Komforts war die Erstellung extrem zeitaufwendig weil die Testf lle sehr umfangreich waren und die Reaktionszeiten auf verschiedenen Rechnern zu Timingproblemen f hrten Vor den Geschwindigkeitsoptimierungen reagierte die Nutzeroberfl che nach Eingaben f r Sekundenbruchteile nicht siehe II 4 2 Dazu mussten Zeitverz gerungen empirisch ermittelt in die Testskripte integriert und getestet werden Nach der ersten Geschwindigkeitsoptimierung wurde die Bildschirmaktualisierung parallel zu den Steuerelementen durchgef hrt Danach var ierten die Wartezeiten von Test zu Test minimal weshalb die Testskripte gewartet werden mussten damit der Regressionstest nicht scheitert Die vier vorhandenen Testf lle wurden an das erweiterte Funktionsangebot z B relative Positionspositionierung und die Zustands berpr fung der Steuerelemente angepasst Zudem mussten die Testskripte so auf die drei Teilbereiche verteilt werden dass mit wenigen Testschritten nahezu und repr sentativ das vollst ndige Verhalten der Dialogfenste
23. Wenn das Testdatum bspw vorschreibt dass ein Steuerelement nach Abarbeitung des Testfalls gesperrt und ausgegraut sein soll hat der Tester d es zu kontrollieren In Abh ngigkeit von der Art des Steuerelementes wurden die Testdaten wie folgt ausgew hlt 1 Beschriftung von Steuerelementen e Ist die Beschriftung eines Steuerelementes statisch d h sie wird nicht durch den Programmcode ge ndert sind daf r keine Testdaten n tig e Kann das Steuerelement nur eine abz hlbare Menge an Beschriftungen anzeigen sollte f r jede einzelne Beschriftung ein Testdatum erstellt werden Die Beschriftungen m ssen durch die Analyse aller B lt bb gt Eintr ge im Kapitel Benutzeroberfl che des Pflichtenheftes ermittelt werden Alle nutzeroberfl chenspezifischen Funktionen s nd zu berpr fen weil jede das behandelte Steuerelement neu beschriften k nnte Bei Steuerelementen wo die Beschriftungs mit den Auswahlm sglichkeiten bereinstimmen z B Kombinations und Listenfelder k nnen die Testdaten aus dem zugeordneten Daten Eintrag im Pflichtenheft abgelesen werden Beispielsweise werden f r das Kombinationsfeld Antrieb ausw hlen Abb II 9 die Antriebsbezeichnungen im zugeh rigen Dateneintrag OD 30 beschrieben Der oberfl chenspezifische Eintrag kein Antrieb wird in B 10 eingef hrt F r den Test wurden daraus drei Antriebe und kein Antrieb ausgew hlt Abb IL58 __ gt M glich ist auch die Zusammenf
24. also r ckw rts Bedingung Der Antrieb darf sich nicht bewegen und die aktuelle Istposition muss gr er der minimalen Istposition sein damit die Bewegung startet Abb 11 18 Auszug aus dem Funktionsteil des Pflichtenheftes M15 Da sich die OOA eigentlich nicht auf die Pr zisierung des Datentyps der Parameterlisten und Zugriffsrechte konzentriert kann nur ein geringer Teil der Metriken ausgewertet werden siehe Tab I 3 Im Mittelpunkt der neuen Manuellen Justage steht die sp tere Funktionskomponente in Form der Klasse TManJustage Sie ist durch die oben vorgestellte Schrittfolge entstanden und repr sentiert die Produktfunktionen Die Datenverwaltung wurde auf die beiden Hilfs Strukturen TMotorData und TPsdData ausgelagert die nach au en nicht sichtbar sind WEE TManJustage 2 49 1 0 3 geg Isi o oo JJI l 1i gt TPsdData a DI ol o JJ JJ Ju Tab Il 3 Ausgew hlte Metriken f r die neue Manuelle Justage nach der Analyse und Definitionsphase Das entstandene OOA Modell der neuen Manuellen Justage zeigt Abb 11 22 Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 41 TManJustage GelMotorzounto SsetikRelatvezero FesetrRelatvezero Set ngle g SAIT DoDirect DoDriwetEDirectioni DosteptEDirectioni Dastopi DosStatMeasure DosStopheasure setthannel Zankeseflrelatvezerong Canset ngle Langen Toi ZanDoblirect
25. che jeweils durch Spezialisten getrennt bearbeitet und getestet werden k nnen Die Kapitel 1 4 2 und 1 4 3 zeigen auch die verbesserte Wiederverwendbarkeit also die Eigenschaft Elemente eines Programmes partiell oder vollst ndig f r andere Zwecke einzusetzen z B Recycling der Funktionskomponente beim Austausch der Nutzeroberfl che Neben den Vorteilen der Dekomposition muss besonders bei paralleler Bearbeitung bedacht werden dass ein erh hter Kommunikationsaufwand zwischen den Entwicklern in der Design Implementierungs und Testphase sowie bei der Dokumenterstellung entsteht Zu beachten ist auch das umfangreichere Design weil ohne die Dekomposition keine Funktionskomponente entstehen w rde Darunter leidet auch die Effizienz weil die zus tzliche Kommunikation der Nutzeroberfl che mit der Funktionskomponente die Ausf hrungsgeschwindigkeit erheblich vermindern kann Dies wird insbesondere durch die Verwendung des im Kapitel 11 2 5 vorgestellte Verfahrens Can Methoden der Funktionskomponente hervorgerufen F r den Anwender erh ht dies jedoch deutlich die Zuverl ssigkeit die sich in Verbindung mit separatem Testen als insgesamt robusteres Software System ausdr ckt Damit sollte die Software auch unter au ergew hnlichen Bedingungen sinnvoll funktionieren weil unzu Test der Nutzeroberfl che ist erst nach Abschluss der Funktionskomponente m glich ausgenommen Funktionsprototypen Seite 12 Einf hrung 1 4
26. che der neuen Manuelle Justage 71 Steuerelemente und die mehrfach vorhandenen identischen Teilbereiche wurde die Auslagerung in einzelne Behandlungsroutinen On Methoden f r jedes Steuerelement nicht vorgenommen Die Autoren entschieden sich spezielle Verwaltungsroutinen f r die Teilbereiche zu erstellen um deren Behandlung zusammenfassen zu k nnen m_InkManldustage TManlustage m_InkTimerTinterfaceTimer Slip OminntCHWWVND HMD LPARAM BOOL m_Selection LIMT FDlg_OncommandcHNMD int HN D JINT oid m_ParalleBO OL SI OmnbiGcrollbarCHwWN D HAWANE JINT inb oid m_StateRefresh BOL LeaveDialogwoid m_DisplayNoActionis g BOOL FOnTimercconst TBasicTimer void TMandJustageDig TB Count JINT TB_CheckLeft ETB const constind BO OL TB_ Next ETE amp BOOL TB_CheckMiddleiETB c0onst constint BOOL TB_SetlYETB constLIMT TB_CheckRightfETB const constind DooOL TB_GetNameiETB const LPSTRYYvoid TB_CheckEsitfETB const Copnst int BOOL GSetResldiETB constERessourceldicanstint TB_StartStopdlickecETB constvoid GetCtrETB const ERessourceld constcHWND D TB_AnglebestEntereckETR const BCOL constivoid TB2 Selection ETB consti LINT TB_SpeedEntered ETB const BOOL consti void Selection TB UJINT consti ETE TB_StepWidthEnteredkETB const BO L constvroid SetSelectionfETB const JINT const BOL TB_Motor hangeckETB constvoid CanSetSelection ETB const UINT const BOOL OnTB_ZontrolstETB constBooLconsboid OnTB_Eind rMowrelETB const
27. hrt e In Eingabefelder wurden g ltige Werte eingegeben Aufgrund des Programmzustands mussten diese Eingaben von der Funktionskomponente ignoriert und die zuvor angezeigten Werte mussten wiederhergestellt werden e Schaltfl chen wurden angeklickt Die Ausf hrung der Produktfunktion musste von der Funktionskomponente ebenfalls ignoriert werden e Betriebsarten wurden ausgew hlt um zu kontrollieren ob die zuvor ausgew hlte Betriebsart w ederhergestellt wurde Beim dritten Test wurde die Zustandsaktualisierung der Steuerelemente aktiviert und ein vollst ndiger Test durchgef hrt Wenn die Schrittfolge eine Zahleneingabe beinhaltete wurden zuerst unzul ssig kleine dann unzul ssig gro e Werte eingegeben um de Einpassung in den Wertebereich zu berpr fen Abschlie end wurde der geforderte g ltige Wert mit einer zu groBen Nachkommastellengenauigkeit eingegeben um die Rundung des Wertes zu berpr fen Damit wurde nochmals die Robustheit der Funktionskomponente bewiesen und getestet Nach den angesprochenen Geschwindigkeitsoptimierungen wurde jeweils nur der dritte Test wiederholt Dekomposition beim Forward Engineering Il 5 Testphase Seite 93 2 Regressions Abnahmetest F r den Abnahmetest der neuen Manuellen Justage der durch die Mitarbeiter des Physikalischen Institutes durchgef hrt wurde mussten typische Arbeitsarbeitsabl ufe ausgew hlt werden Weil das grundlegende Verhalten im Vergleich zum urspr nglichen
28. lt N gt kennzeichnet neu eingef gte Programmcodeelemente beim Reengineering NEU lt ZzsSA gt Zugriffsschutz f r Attribute private protected public lt ZSM gt Zugriffsschutz f r Methoden SLOBAL lt ZSA gt lt SCS gt storage class specifier auto register static extern rolatile mnutable Abb 11 34 Verallgemeinerte Eintr ge f r Typen Attribute Methoden und Variablen vgl oben nach Ausz gen aus M21 Jedem Eintrag ist eine kurze Beschreibung hinzugef gt Neben einem allgemeinen Zweck s nd bei den Methoden alle Parameter erl utert und bei den Typendeklarationen alle Elemente Jeder Do Methode ist sofern m glich ein F lt f gt Eintrag aus dem Pflichtenheft zugeordnet Um zu berpr fen ob alle Eintr ge mm Design ber cksichtigt werden ist bei jeder Methode der entsprechende Eintrag genannt siehe Abb 11 35 Diese Zuordnung ist auch f r Attribute und Datenteil Eintr ge sowie zwischen Botschaftenbehandlungsroutinen und den Funktionen der Benutzeroberfl che vorgenommen worden Seite 64 Dekomposition beim Forward Engineering II 3 Designphase gt BOOL DoStop int PUBLIC stoppt die Antriebsbewegung unabh ngig von der Betriebsart der Parameter ist der Index des Antriebs in der Antriebsliste siehe M8 Funktion F 80 Abb 11 35 Auszug f r einen Methoden Eintrag aus M21 11 3 5 Zusammen
29. mehr als 70 des gesamten Systems jede Steuerelementbotschaft behandelt wurde Im Zuge der Layoutverbesserung erfolgte die Auslagerung des Programmcodes f r jedes Steuerelement in getrennte Methoden Zuordnung siehe Abb III 10 Ein 31 zeiliges Makro war toter Code Da es seit der Ausgangsversion von 1998 ungenutzt blieb konnte es entfernt werden 5 Neuordnung der Attribute Diejenigen Attribute die keine oberfl chenspezifischen Eigenschaften widerspiegelten wurden in die Funktionskomponente verschoben und mit dem Pr fix m_ gekennzeichnet siehe Abb ULI Ga Trotz des hohen Zugriffsschutzes von Seiten der Funktionskomponente mussten nur Accessor und Mutator Methoden f r das dynamische Feld Seite 116 Dekomposition beim Reengineering Ill 2 Restructuring m Speed implementiert werden Die brigen Attribute werden nur intern von den Methoden der Funktionskomponente benutzt Die Initialisierung wurde soweit vorhanden aus der Oberfl chenklasse entnommen bzw mit Standardwerten belegt Von urspr nglich 11 Attributen in TAngleCt1lDlg verbliebenen 4 Attribute Sie wurden mit m_ gekennzeichnet und mit aussagekr ftigen Bezeichnern versehen siehe Abb III 10 mm Zus tzlich werden noch die beiden Referenzen auf die Funktions und Timerkomponente letztere wegen der Polling Variante ben tigt Die bei 4 erw hnten Attribute die den Zustand anderer Subsysteme zwischenspeichern wurden entfernt Stattdessen wurden n der Funktionskomponent
30. nnen Um die anwender und entwicklerseitigen Erfahrungen zu extrahieren wird auf diesem Referenzprodukt eine Ist Analyse durchgef hrt Die Einarbeitung m den Gegenstandsbereich und die Erstellung eines neuen Pflichtenheftes wird erleichtert und die entwicklerseitige Grundlage f r Vertragsverhandlungen verbessert sich Diese Analyse muss n cht zwingend zu Beginn des Forward Engineering abgeschlossen sein Beim Neuentwurf eines umfangreichen Projektes k nnen Erkenntnisse w hrend der Entwicklung wieder verloren gehen wenn die Ist Analyse vollst ndig zu Beginn erfolgte Die vorhandenen Teile des Referenzproduktes sollten deshalb n den entsprechenden Phasen des Forward Engineering unter den jeweiligen Gesichtspunkten betrachtet werden Im g nstigsten Fall stehen neben dem Programmcode alle phasenspezifischen Dokumente Verhaltensspezifikation bzw Pflichtenheft Design Testdokumentation Fehlerliste des Vorg ngerproduktes zur Verf gung Dazu kann der Referenzentwurf w hrend der neuen Designphase mit Computer Aided Software Engineering CASE Werkzeugen extrahiert und analys ert werden Eine Untersuchung des bestehenden Programmcodes sollte hingegen erst bei der Neuimplementierung erfolgen Anwendungsfall Manuelle Justage Manuelle Justage Be Be sl H P W nkel 10 000 Heuer Winkel Grad AntsebsSchreiwahl FMelelive Jerilsuferser Halbwertsbhreite messen Eiugung Feir Ea Ss Relative Hull setzeri M
31. und Stillstand des Antriebs alle drei Testdaten f r die Sollposition auszuwerten In allen anderen Programmzust nden ist einmal der Wert aus der quivalenzklasse g ltige Eingaben anzuwenden um sicherzustellen dass diese Eingabe ignoriert wird Die Suche im Designdokument zeigte dass SetAngleDest zur Manipulation der Sollposition auszuf hren ist Grundlagen Die Sollposition ist nur im Direktbetrieb erforderlich Dort gibt sie an wohin sich der Antrieb bewegen soll Die Sollposition besteht wie die stposition auch aus der Absolutposition des Antriebs verschoben um einen Offset Damit ist die Sollposition auch abh ngig von dem Offset f r lt Antrieb gt und der Relativen Null weil diese intern ber das Offset abgebildet werden Bedingung Der Antrieb darf sich nicht bewegen und der Direktbetrieb muss ausgew hlt sein Abb 11 54 Auszug aus dem Funktionsteil des Pflichtenheftes M15 2 Generierung von Testf llen CTE unterst tzt Die Generierung der Testf lle selbst wurde mit dem Classification Tree Editor CTE von Xerces vorgenommen zu CTE siehe 9 S 138ff F r den Test wurden vier CTE Diagramme erstellt Das erste Diagramm dient zur Auswertung aller n cht zustandsver ndernden Opera tionen die einen Wahrheitswert zur ckgeben logische Operationen Es waren 15 Testf lle mit jeweils 36 Testdaten 18 Methoden R ckgabewert jeweils true und false notwendig Die Testf lle entsprechen den Prog
32. 2 4 Benutzerhandbuch Obwohl integrierte Hilfe Systeme heute bei Software Produkten zum Standard Funktionsumfang geh ren ist ein Benutzer Handbuch dennoch ein unverzichtbarer Bestandteil eines guten Software Produktes Es ist wie auch die Nutzeroberfl che die Visitenkarte eines Software Produktes In vielen F llen ist es die einzige Unterst tzung die der Benutzer f r die Einarbeitung in das System erh lt aus 2 S 640 Die Informationen aus Pflichtenheft Produktmodell und Oberfl chenprototyp gehen didaktisch methodisch aufbereitet und unter Auswahl geeigneter Beispiele in das Benutzerhandbuch ein Empfohlen wird die Erstellung eines solchen bereits in der Definitionsphase siehe 2 S 100 Dadurch sind die Entwickler gezwungen sich so fr h wie m glich in die Rolle des Anwenders zu versetzen Je nach Anwendergruppe werden diese n Form eines Trainings mit Kurs oder Trainingsprogramm f r Anf nger oder Referenz Handbuch als Nachschlagewerk f r Experten erstellt Das Trainings Handbuch beschreibt die n tigen Schritte zum Erreichen von h ufig auftretenden Arbeitszielen bei der Bedienung des Softwaresystems Dies wird durch eine leicht nachvollziehbare Arbeitsanleitung erreicht Damit ergibt sich eine aufgabenorientierte Gliederung wobei die Aufgaben sortiert nach Komplexit t und mit der einfachsten Schrittfolge beginnend strukturiert dargelegt sind Der Schwerpunkt des Referenz Handbuchs liest auf einer deutl
33. BOOL constivoid OnTB_starstopiETB eonst BOOL const woid ThlanJustageDlgi OnTB_MotionF aram ETE const BOOL conshvoid TManJustageDlg OnTB_FositionstETBR constBOOL conshivoid OnbMotionstartselllMT constvoid OnTB_OfsekETB const BOOL constvold OnMotionProgress LINT const void OnTB_Units ETR eonsh void OnMotionstopstlllNT constivoid CnTB_GControlsEnableiE TB constivoid OnMeasureStarts void OrTB_MotorListenakbleiETB conshvoid OnbMeasurefrogress roid 0nTB_KindOhioveEnable ETE cons oid OnMeasureStops void OrTB_StartstopEnahleiETB conshvoid OnPsd fset oid OrTB_MotionFaramEnableiETB const void OnChooseTB woid OrnTB_FositionsEenableiETB constivoid Onblosciondwoid OrnTB_ ffselEnableiE TB constvoid Otherzontrolso void strollbarcalculate TAngle const Tangleiconst EEE Ableitung und Spezialisierung von TAangle cornst Attributen int amp int amp int void DZ berschreiben von Methoden der Basisklasse n EZ Verwaltung der Teilbereiche EZ Behandlungsroutinen und Aktualisierung eines Teilbereichs weitere Methoden Abb 11 23 UML Klassendiagramm f r die Dialogfensterklasse TManJustageDlg gegliedert nach der Erstellungsreihenfolge ihrer Elemente Seite 50 Dekomposition beim Forward Engineering II 3 Designphase m_InkManlustage TManJustage m_InkManlustage TManJustage mids JNT mids INT m_Digits NT Pm Dote NT Dlg_Onlnitt HNO HY NDO LPARAM DOOL Dlg_Onlnitt HW NO HY NDO LPARAM DOO
34. D PFLICHTENHEFT NEUE MANUELLE JUSTAGE VERSION 2 1 sseeecsssscesssccccossceccoseeee 147 ANHANG E BEWERTUNG DER NEUENTW RFE DES OBERFL CHENFENSTERS ZUR MANUELLE JUSTAGE VERSION Lu 8400022 teestehaenaeneeeeenne 167 ANHANG F XCTL STEUERPROGRAMM BENUTZER LEITFADEN DER BASISANWENDUNG NEUE MANUELLE JUSTAGE VERSION 1 6 2222000000020000000000000000000000000u0n000nnennnonsnnsnnennne 175 ANHANG G REGRESSIONS TESTF LLE NEUE MANUELLE JUSTAGE VERSION 1 5 sseeesssssessseceo 193 ANHANG H DESIGNBESCHREIBUNG NEUE MANUELLE JUSTAGE VERSION 2 0 ceessssseesssssneeeseee 203 ANHANG I DESIGNBESCHREIBUNG ZUM REENGINEERING DER TOPOGRAPHIE VERSION 1 4 221 ANHANG J CTE DIAGRAMME DER NEUEN MANUELLEN JUSTAGE essseseecsssceccosccecoseccccossceccsseeee 233 ANHANG K CTE DIAGRAMME DER NEUEN TOPOGRAPHIE s eesceesssssseneossnsnsnesssnssnnsossnssnnssssnsssnennne 239 TABELLENVERZEICHNIS Tab II 1 bersicht zur urspr nglichen Manuellen Justage es seososeseososessoscsessoscsessoscsessoseseosose 19 Tab II 2 Ausgew hlte Metriken f r die Klassen der urspr nglichen Manuellen Justage 20 Tab II 3 Ausgew hlte Metriken f r die neue Manuelle Justage nach der Analyse und Definitionsphase 0 0000000uuuusossssssssssssssssssssnsnnnnssssssssssssssssssssssee 40 Tab II 4 Abstrakte Methoden des Beobachters TManJustage esssssssssssssssssssssssssssnsssnnnsssssssssssne
35. Entwicklers ber die Funktionen und Beziehungen von Klasse Attributen und Methoden untereinander schriftlich festgehalten Zudem f hrt die Erstellung eines solchen Dokumentes nochmals zu einer intensiven Besch ftigung mit der Materie was Fehler und Unvollst ndigkeiten vor der Implementierungsphase aufdeckt So k nnte auch das bei einer sp teren Wartungsphase anfallende Reverse Engineering erheblich vereinfacht werden weil neben der Programmcodekommentierung eine ausf hrliche Beschreibung des Gesamtsystems und seiner einzelnen Teile vorhanden ist Anwendungsfall Manuelle Justage Die Autoren haben f r alle selbst erstellten Designdokumente ein einheitliches stark formalisiertes Dokumentmuster entwickelt Im XCtl Projekt erfolgt die Erstellung getrennt nach Subsystemen So entstanden f r die Ablaufsteuerung M4 und M6 f r die Motorsteuerung M26 und M28 f r die Benutzeroberfl che M7 und M9 f r die neue Topographie M35 f r die urspr ngliche M24 und neue Manuelle Justage M21 jeweils nach dem gleichen Muster Die Gliederung eines Designdokumentes beginnt mit einer allgemeinen verbalen Einf hrung in den Gegenstandsbereich Anschlie end werden die verwendeten globalen Typen aufgelistet und erl utert In C beinhaltet dies structs enums unions und typedefs sofern Dekomposition beim Forward Engineering 11 3 Designphase Seite 63 vorhanden Darauf folgen Konstantend
36. Funktionskomponente beschr nkt werden Es ist wichtig die Makros von der Nutzeroberfl che zu trennen Sonst w rden nur die Oberfl chenfenster ferngesteuert Dadurch w re die Programmierung umfangreicher und w hrend der Abarbeitung des Makros w rden die ben tigten Fenster angezeigt gesteuert und geschlossen werden Bei nderungen an der Nutzeroberfl che w ren alte Makros u U nicht mehr g ltig Besonders problematisch ist dies bei individualisierbaren Nutzeroberfl chen Nur bei grundlegenden nderungen an der Funktionskomponente sind u U Anpassungen an Makrosteuerung und rekorder erforderlich um Abw rtskompatibilit t f r alte Makros zu gew hrleisten Bei Integration oder sp teren nderungen der Makrosteuerung oder des rekorders ist die Nutzeroberfl che davon nicht betroffen Anstatt einem Methodenaufruf zum ndern der Schriftgr e m ssten Men aufruf und Auswahl der Gr e im Dialogfenster erfolgen Anschlie end m sste das Fenster geschlossen werden Kapitel II Dekomposition beim Forward Engineering Kapitel II DEKOMPOSITION BEIM FORWARD ENGINEERING In diesem Kapitel wird die Dekomposition von Funktionskomponente und Nutzeroberfl che beim Forward Engineering beschrieben Dies wird exemplarisch am Neuentwurf des Subsystems Manuelle Justage vorgestellt Neben dem verallgemeinerten Grundger st werden so gewonnene Erkenntnisse und praktische L sungsstrategien f r ausgew hlte Probleme dargest
37. Gegensatz zur Topographie wurden die Can Methoden hier separat implementiert um einen repr sentativen Vergleich zwischen Forward und Reengineering f hren zu k nnen Zudem soll das damit verbundene Potential deutlich gemacht werden dass es der Nutzeroberfl che nach der Dekomposition gestattet sich an Zustands nderungen anzupassen BOOL TAnglectl DoDirect int alndex double aPos BOOL bValid if IsMoving aIndex bValid A Bedingungen f r den Direktbetrieb bValid m_IsMeasuring return FALSE DoSelectMotor alndex mActivateDrive Motor aktivieren sonst bewegt sich der Antrieb nicht wenn er gestartet wird mMoveToDistance aPos BOCH bVal d return IsMoving alndex bValid wurde die Bewegung gestartet AUSGANGSZUSTAND BOOL TAnglectl DoDirect int alndex double spos if CanDoDirect aIndex return FALSE DoSelectMotor aI ndex mActivateDrive Motor aktivieren sonst bewegt sich der Antrieb nicht wenn er gestartet wird mMoveToDistance aPos BOOMO ERa return IsMoving aIndex bValid wurde die Bewegung gestartet Bedingungen f r den Direktbetrieb BOOL TAngleCtl CanDoDirect int alndex BOOM bValid il A sMovange eindex bDvalid J ipbvalad mZTsMeasuring return FALSE return TRUE ERGEBNIS Abb Ill 12 Beispiel zur Auslagerung einer CanDo Methode 9 Erstellung von CanSet und Gewinnung zus tzlicher Bedingungen f r CanDo Methoden
38. Gesellschaft f r Wissenschaftsforschung 2001 8 E Gamma R Helm R Johnson J Vlissides Design Patterns Elements of Reusable Object Oriented Software 1997 Addison Wesley 9 J Hanisch J Letzel Automatisierung von Regressionstests eines Programms zur Halbleiter Strukturanalyse Diplomarbeit November 2002 10 H B Kief NC CNC Handbuch 1999 Carl Hanser Verlag M nchen Wien 11 S Meyers Effektiv C programmieren 50 M glichkeiten zur Verbessung Ihrer Programme Addison Wesley 1995 12 E Rubiko COM DCOM Objektmodell und OLE Architektur Eigenschaften Schnittstellen Konzepte 11 1999 http www mmt inf tu dresden de Lehre Wintersemester_98_99 Hauptseminar COM_DCOM pdf 13 T K Sarma Applying Observer Pattern in C Applications Januar 2001 14 C Szallies On Using the Observer Design Pattern August 1997 15 K Tucker R E K Stirewalt Model Based User Interface Reengineering 6 Working Conference on Reverse Engineering 6 8 Oktober 1999 Atlanta Georgia USA 16 ISO IEC 14882 1998 Information Technology Programming Languages C Seite 142 Anhang B verwendete Materialien Anhang B VERWENDETE MATERIALIEN XCTL GESAMTSYSTEM M1 U Sacklowski Der Anwendungsbereich Eine Einf hrung Version 2 4 M2 K Sch tzler Use Case Diagramm XCtl Gesamtsystem April 2001 M3 S L tzkendorf Toter Code Ergebnisse mit SNIFF und McCabe erstellt 15 06 1999 SUBSYSTEM B
39. Interface vollst ndig definiert Neben den allgemeinen Vorteilen gibt es jedoch Aspekte welche die Verwendung des Observer Musters speziell bei der Dekomposition in Funktionskomponente und Nutzeroberfl che beg nstigen e Das Observer Muster bietet eine hohe Flexibilit t weil die Zustandsaktualisierungen in die Funktionskomponente ausgelagert werden Dadurch ist die Nutzeroberfl che nicht so umfangreich und kann leichter ausgetauscht werden z B beim Prototyping Nachteile des Observer Musters e Der Austausch des Konkreten Subjektes ist durch das Subjekt und das assoziierte Beobachter Interface stark eingeschr nkt Bei der Dekomposition wo das Konkrete Subjekt der Funktionskomponente entspricht st das aber eher selten 1 4 3 Ersetzung der simulierten Reaktion eines Programmes durch die wirkliche Programmfunktionalit t e Fin Subjekt verwaltet eine Liste von Beobachtern Nun kann es sinnvoll sein dass nur ausgew hlte Beobachter ber bestimmte Ereignisse informiert werden sollen um Ressourcen zu sparen Dazu sind aber zus tzliche Informationen n der Beobachter Liste des Subjektes n tig Anwendungsfall Manuelle Justage Bei der Manuellen Justage ist das Konkrete Subjekt die Klasse TManJustage Da nur eine Oberfl che ber Zustands nderungen informiert werden soll kann das Subjekt Interface entfallen Die Erzeugung von TManJustage findet m Konstruktor von TManJustageDlg statt Um das Wissen der Funktion
40. Motivation l ssige Eingaben nicht durch die Funktionskomponente verarbeitet werden und zu Fehler f hren k nnen falls die Nutzeroberfl che diese Situationen nicht bereits ordnungsgem abdeckt 1 4 2 Austausch Flexibilit t und Wartung der Nutzeroberfl che Die M glichkeiten der Oberfl chengestaltung sind heutzutage sehr vielf ltig Der Entwurf ist im Wesentlichen vom Betriebssystem und der verwendeten Programmiersprache abh ngig Die meisten objektorientierten Sprachen bieten hierf r individuelle GUI Bibliotheken an Java z B hat mit seinem Application Programming Interface API deutsch allgemeine Programmierschnittstelle den gro en Vorteil der Plattformunabh ngiskeit Das trifft f r viele Sprachen insbesondere f r das von uns verwendete C leider nicht zu Zudem sind fast alle Sprachen propriet r d h herstellerabh ngig Soll ein Wechsel der Entwicklungsumgebung oder Zielplattform stattfinden ist besonders bei C als Programmiersprache die Nutzeroberfl che oft neu zu implementieren oder grundlegend zu berarbeiten Dann ist bei Anwendungen die derzeit auf mehreren Betriebssystemen arbeiten sollen f r jede Plattform eine eigene Version zu erstellen Dies ist mit hohem programmiertechnischen Aufwand verbunden Erfolgt zudem keine Trennung in Funktionskomponente und Nutzeroberfl che wie in der Praxis oft blich erh ht sich dieser Aufwand erheblich Erst die hier vorgestellte Dekomposition macht den Portierungs bz
41. Nutzeroberfl che den Zustand der Funktionskomponente erfragen und sich daran anpassen z B durch Sperren und Ausgrauen eines Steuerelementes wenn die Funktion nicht verf gbar ist e On Methoden werden als Ergebnis von Zustands nderungen aufgerufen und erm glichen so die Reaktion auf solche Ereignisse Zur Aktualisierung der Nutzeroberfl che k nnte OnDividing z B anzeigen dass eine langwierige Berechnung von DoDivide gestartet wurde Anwendungsfall Manuelle Justage a Gewinnung der Attribute F r jeden Datenteil Eintrag D lt dd gt entstand genau ein Attribut So wurde beispielsweise aus D 110 m_AngleDest abgeleitet Weil dieses Attribut f r jeden Antrieb zu verwaltet ist wurde es mit allen anderen antr ebsspezifischen Daten in der Struktur TMotorData zusammengefasst Die Gr e der Liste dieser Struktur h ngt von der Anzahl der angeschlossenen Antriebe ab 11 Assoziationen Kompositionen und Aggregation 12 Nach Kapitel empfehlen die Autoren diese Modularisierung bereits bei der Erstellung des Pflichtenhefts durchzuf hren Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 39 D 110 eingegebene Sollposition Die Sollposition ist wie die Istposition abh ngig vom aktuellen Offset des Antriebs Die Minimal und Maximalwerte k nnen dem Datenteil entnommen werden ebenso die Nachkommastellengenauigkeit Die Sollposition ist bei jeder Anderung zu speichern Bezeichnung e
42. Softwareentwicklung in der Mitte der 60er Jahre erstmals die Hardwarekosten berschritten haben zur Softwarekrise siehe 2 S off hat man wissenschaftliche Prinzipien zum Management der Komplexit t eines Softwareprojektes entwickelt Die Kernpunkte sind im Wesentlichen Modularisierung Abstraktion und Hierarchiebildung Sie sollen nun im Hinblick auf die Dekomposition betrachtet und erl utert werden Eine der grundlegendsten Managementstrategien ist die Modularisierung siehe 3 S 57 1ff Dieser auch als Separation of Concerns bezeichnete Mechanismus bedeutet d e Zerlegung eines Programmes n einzelne Teilsysteme die m glichst unabh ngig voneinander bearbeitet werden k nnen Dazu m ssen deutlich abgegrenzte Modul Schnittstellen geschaffen werden Im Hinblick auf die Dekomposition werden vorhandene Teil oder Subsysteme in die beiden Komponenten Funktionalit t und Nutzeroberfl che engl Graphical User Interface GUI noch weiter aufgeteilt Modularisierung kann sogar die Aufteilung eines Subsystems auf einzelne Dateien beinhalten um auch den Programmcode voneinander zu separieren Bei der Dekomposition entstehen dann mindestens zwe Dateien Funktionskomponente und Nutzeroberfl che getrennt f r jedes Subsystem Gesamte Programmkomplexit t Subsystem A Subsystem B Nutzeroberfl che A Nutzeroberfl che A 2 Nutzeroberfl che B GUI Klasse in Datei 2 GUI Klasse in Datei 3 GUI Klasse in Datei 5 Funktionskomponente A
43. Trebuchet MS Tungs verdana Ka Schriftkarbe Unkerstreichung Automatisch ohne e Abb 1 9 Beispiel der Schriftformatierung ber eine individualisierbare Symbolleiste oben im Vergleich zum Ausschnitt des Dialogfensters Zeichen unten in Microsoft Word Bei einer ausgelagerten Funktionskomponente werden die grundlegenden Programmfunktionen nicht tangiert wenn die Nutzeroberfl che individualisier gestaltet werden soll GUI Klassen beinhalten dann die Sicherung und Wiederherstellung der gew nschten Anordnung sowie die Verkn pfung der Steuerelemente mit den entsprechenden Methoden der Funktionskomponente Wenn die gew nschte Funktionalit t ber mehrere Steuerelementtypen siehe Abb I 9 Auswahl der Schriftart ber ein Kombinations oder Gruppenfeld realisiert werden kann oder in mehreren Fenstern angeboten werden soll muss die zugeh rige Funktionalit t m eine Funktionskomponente ausgelagert werden Wenn diese Dekomposition nicht erfolgen w rde m sste der Programmcode mehrfach vorhanden sein Das birgt neben Seite 14 Einf hrung 1 4 Motivation dem erh hten Arbeitsaufwand und Fehlerrisiko auch Gefahren bei der Wartung weil Inkonsistenzen entstehen k nnten 1 4 3 Austausch und Wartung der Funktionskomponente Neben dem Wechsel der Nutzeroberfl che besteht auch die M glichkeit die Funktions komponente auszutauschen Ein Szenario w re die Verwendung von simulierten Reaktionen in einer Anwendung
44. Verwendung entsprechender Accessor und Mutator Methoden Oft verwendete friend Relationen wurden so berfl ssig Au erdem erfolgte eine Neustrukturierung im Wesentlichen eine Zusammenfassung nach Sinneinheiten und eine ausf hrlichere Kommentierung des Programmcodes Der bereits in M3 identifizierte tote Programmcode wurde mit Datum gekennzeichnet auskommentiert Die im Repository aufgef hrte Fehler Dokumentation der Subsysteme Motor M27 Ablaufsteuerung M5 und urspr ngliche Manuelle Justage M19 wurde aktualisiert indem neue Fehler hinzugef gt und von den Autoren korrigierte gekennzeichnet wurden Um die neuen Systemzust nde festzuhalten erfolgte eine abschlie ende Dokumentation in den Designdokumenten M28 und M6 Dort wurden schlie lich die Methoden identifiziert die in der neuen Manuellen Justage benutzt werden sollten Zudem konnten einige Datenteil Eintr ge im Pflichtenheft vervollst ndigt werden Dies betraf die Angaben Typ Minimalwert Maximalwert Nachkommastellengenauigkeit nur bei reellwertigen Werten und Maximall nge nur Zeichenketten Bei neuen Projekten besteht diese M glichkeit nicht weil weder Programmcode noch Designdokumente vorhanden s nd Alle Informationen s nd n der Definitionsphase beim Benutzer zu erfragen In jedem Fall sind nun die Attribute der Funktionskomponente zu typisieren und die Signaturen der Methoden zu vervollst ndigen a Sp
45. Zei DG UU OU Bereich 300 Fiozenk z Detekiorzei H ser T HehlschBeicht Beichtungszei Abbrechen he zuklen f Schittweite 2000 Sekunden Sterlwer 2000 Sekunden NERS 0 10 83 0 1 48 TTopographyExecuteDlg 418 13 4 d 4 72 0 28 101 4 1 35 TTopographyole 83 18 1 1 0 0 TTopographysetParamblg 237 7 4 11 4 50 0 50 41 4 146 Tab I1l 1 Ausgew hlte Metriken f r die Klassen der urspr nglichen Topographie Seite 102 Dekomposition beim Reengineering Ill 1 Ist Analyse Dateien e M TOPO CPP TOPOGRFY H Klassendiagramm TdasiebDlalag IModaldid Subsystem A A urspr ngliche Topographie Subsystem Benutzeroberfl che sensor Monitor 0 1 TDetector Subsystem Detektornutzung Dokumentation e Analyse Definitionsphase o Topographie Gesamtvorgang M29 o Verhaltensspezifikationen Einstellen der Parameter f r die Topographie M31 start und Kontrolle der Topographie M32 Topographie Me protokoll_Buch M33 o eine kurze Use Case bersicht M2 e Design Implementierungsphase o Software Struktur M29 e Testphase o Regressions Testf lle Topographie M36 e Fehler bersicht o tabellarische bersicht aller gefundenen Fehler seit 22 6 2000 M34 Tab Ill 2 bersicht zur urspr nglichen Topographie Dekomposition beim Reengine
46. a bis d angeben und das verantwortliche Programmcodefragment fett hervorgehoben In Abb II 3 ist ein Beispiel enthalten wo die Anzahl der F und O Bl cke reduziert werden kann indem die Anweisung zum ndern des Mauszeigers in eine Sanduhr umsortiert wird 2 Sicherzustellen ist dass KEINE Anweisungsfolge auf das Attribut schreibend zugreift Dekomposition beim Reengineering Ill 2 Restructuring Seite 107 void TThrowSimDlg OnStartThrow A Simulation zum schr gen Wurf el aer if m_ThrowModule gt IsBusy return Simulation ist aktiv c d b LE c m_inkFunk gt SetStartAngle angle m_IinkFunk gt SetStartSpeed speed E d AU Berechnungen f r schr gen Wurf AUSGANGSSITUATION void TThrowSimDlg OnStartThrow Simulation zum schr gen Wurf a eg if m_ThrowModule gt IsBusy return Simulation ist aktiv Wr m_InkFunk gt SetStartAngle angle m_IinkFunk gt SetStartSpeed speed Berechnungen f r schr gen Wurf ERGEBNIS Abb Ill 3 Konstruiertes Beispiel zur Verschmelzung zweier O Bl cke der entstandene F Block kann als Ganzes als Do Methode ausgelagert werden Seite 108 Dekomposition beim Reengineering Ill 2 Restructuring void TInkrementalCalcDlg OnStartCalc laufzeitabh ngige Ergebnisgenauigkeit FE if repeatCount lt 0 repeatCount gt 199 false m_InkFunk gt DoStartCalc repeatCount Abb Ill 4 Konstruiertes Beispiel mit ni
47. ausgibt Dekomposition beim Forward Engineering IA Implementierungsphase Seite 71 1dimensionaler Detector PSD und dessen Antrieb vorhanden BOOL TManJustage HasDetectorAxis const return m_InkDetector 0 amp amp GetDetectorAxisldx 1l CS Test ob Index im Intervall der Motorenliste BOOL TManJustage IsIndexValid const int alndex const return 0 lt alndex amp amp alndex lt GetMot srcloune JI Abb 11 43 Absicherung von Lese und Schreibzugriffen und zur berpr fung von Parameter bergaben in TManJustage Name des Antriebs f r einen Index aus der Antriebsliste LPCSTR TManJustage GetMotorName const int alndex BOOL amp aValid const aVal d RAL E if IsIndexValid aIndex return DI beiung ltigem Index leere Zeichenkette aValid TRUE return m_MotorList aIlndex m_1nkMotor gt pCharacteristic der Name J Abb 11 44 berpr fung ob der bergebene Parameter g ltig ist hnlich wie beim Zugriff auf andere Subsysteme unterliegt auch der Zugriff auf Attribute der Funktionskomponente selbst bestimmten Bedingungen Dazu geh rt bei der Manuellen Justage z B ob sich ein Antrieb gerade bewegt welche Betriebsart gerade ausgew hlt ist oder ob die aktuell angezeigte Antriebsposition durch ein nutzerdefiniertes Offset von der absoluten Position abweicht Deshalb wurden anstatt direkt auf die Attribute zuzugreifen Accesor und Mutatormethoden v
48. bersetzt werden Die bertragung der Nutzeroberfl che in andere Sprachen ist einfacher wenn alle GUI spezifischen Teile zusammengefasst sind Im Falle der Dekomposition sind dies eigene Klassen Die Funktionskomponente darf keine Ausgabe erzeugen und kann somit unver ndert bleiben hnlich verh lt es sich wenn Oberfl chen an mehrere Benutzergruppen angepasst werden m ssen Den verschiedenen Nutzern m ssen oder d rfen je nach zugewiesenen Arbeitsaufgaben und Rechten nur ausgew hlte Programmfunktionen zur Verf gung gestellt werden Um nicht f r jede Nutzergruppe eine eigene Oberfl che mit integrierter Funktionalit t bereitzustellen sollte nur eine Funktionskomponente entwickelt werden die alle Produktfunktionen enth lt Die Realisierung der Zugriffsrechte erfolgt ausschlie lich ber neue Nutzeroberfl chen die jeweils nur einen Teil der Schnittstelle der einmal erstellten Funktionskomponente benutzen So wird Redundanz vermieden was Fehler minimiert und die Entwicklungszeit verk rzt Gleichzeitig erleichtert die Dekomposition die individualisierbare Oberfl chengestaltung bei der die Nutzeroberfl che leicht an die Bed rfnisse der Anwender angepasst werden kann Dies ist z B bei nderung der Reihenfolge und Verf gbarkeit von Funktionen in Symbolleisten siehe Abb I 9 der Fall Times Mew Roman 11 F Us o Schriftart Times Men Roman Schriftschnitt ne New Roman Times Hew Roman MT Extra Bold
49. der Nutzeroberfl che schon in der Planungsphase eliminieren Dies ist sonst erst beim Abnahmetest durch den Anwender m glich Neben den Wartungsarbeiten am Programmcode m ssten dann nat rlich auch die Dokumente bspw Benutzerhandbuch Online Hilfe berarbeitet werden Das Pflichtenheft der neuen Manuellen Justage hat die Erstellung von Benutzerdokumentation und Hilfe System extrem vereinfacht weil wesentliche Teile aus dem Kapitel Nutzeroberfl che des Pflichtenheftes leicht abgewandelt bernommen werden konnten Das Pflichtenheft bildete die einzige Grundlage f r diese Artefakte Obwohl Hilfe System und Benutzerleitfaden im Anwendungsfall der neuen Manuelle Justage nacheinander erstellt wurden steht einer parallelen Bearbeitung nichts im Wege F r sich genommen haben die oberfl chenspezifischen Elemente des Pflichtenheftes keinen Nutzen f r die OOA In seiner Gesamtheit hat es die Vollst ndigkeit und Korrektheit des OOA Modells verbessert weil Missverst ndnisse m der Spezifikation schnell aufgefunden und beseitigt wurden Seite 44 Dekomposition beim Forward Engineering Il 3 Designphase 11 3 Designphase In der Designphase ist der Architektur oder Systementwurf durchzuf hren siehe 2 S 986 Hierbei wird die Softwarearchitektur festgelegt Sie ist wesentlich von der Art der Anwendung und der verwendeten Plattform abh ngig Ausgehend vom OOA Modell der Definitionsphase entsteht durch Verfeinerung und An
50. der in den reflektierten Strahl gebracht wird Das zu erfassende Kristall Raumsegment hat eine Fl che von etwa 10 mm x 10 mm und eine Tiefe von max 20 Mikrometern Die Belichtungszeit f r eine Probe kann viele Stunden bis Tage betragen W hrend dieser Zeit kann die Messanlage durch thermische Einfl sse geringf gig deformiert werden was zur Abweichung von eingestellten Ausgangsbedingungen f hrt Aus diesem Grund wird durch einen Kontrolldetektor st ndig die von der Probe reflektierte Strahlung gemessen Bei Abweichungen ber einen vorgegebenen Intensit tsbereich hinaus muss die Stellung der Probe nachreguliert werden Diese Korrektur erfolgt ber den Motor Beugung Fein siehe Abb I 4 DC automatisch Es gibt zwei Arten von Messungen die Einfachbelichtung und die Mehrfachbelichtung Im ersten Fall wird nur ein kleiner Ausschnitt der Probe einmal belichtet Im zweiten Fall werden nacheinander mehrere Belichtungen durchgef hrt Nach Ablauf der Belichtungszeit wird die Probe hier auf ein neues Segment gestellt und erneut belichtet Um die Probe vor einem Topographie Messvorgang in die richtige Ausgangsposition zu bringen wird die Manuelle Justage benutzt Abb I 5 zeigt das Photo eines realen Arbeitsplatzes Seite 8 Einf hrung 1 3 Fallbeispiel das XCtl System P NW d 28 T iL 3 Abb 1 5 Arbeitsplatz RTK14 am Physikalischen Institut Einf hrung 1 4 Motivation Seite 9 I 4 Motivation In den folgenden Abschn
51. der neuen Manuellen Justage zeigt Abb 11 22 Nach dem OOA Modell sollten alle ben tigten Daten durch die neue Manuelle Justage verwaltet werden Durch das Programmcode Review der benutzten Subsysteme konnten dort einige Attribute und Methoden identifiziert werden die ben tigte Daten bereits verwalten Diese konnten damit aus TManJustage entfernt werden Das Element TPsdData wurde sogar komplett entfernt vgl Abb II 19 und Abb 11 22 Die f r den Zugriff auf diese Attribute geplanten Methoden sind erhalten geblieben Statt auf die Attribute direkt zuzugreifen Accessor Methoden muss dort nun an das jeweilige Attribut bzw die Accessor Methode des entsprechenden Subsystems delegiert werden Dekomposition beim Forward Engineering Il 3 Designphase m_MotorListTMotorData m_InkDetector TOnebimbDetector m_Channelint Pm Motor oun JINT r hanpngoiO imt rG pi ngleber hanngelc T nglg GetlMotorNamedint BOOL amp iLPESTR Getlnit int BOOL amp LFESTR Get nglecint BOOL amp TANIE GetAngleMincint BOOL i TAnNgGIE GetAngleMastint BOOL amp TAngle GetDigitscint BOOL Sy INT Get ffsettint BOOL amp TAngle rG Gfhiot on TwpecC rt BOOL Si EMotionT Type GetAngleDesttint BOOL ki TAngIe Gelspeede int BOOL si TSpeed GetAngleidthtint BOOL amp i TAngle GelDetector TDetector SetMotionTypedcint EMotonType Si BO OL Sel AngleDeste int TAngle Si BOL 5et5peediint TSpeed ErHOOL 5et nglewvidthii
52. der vorher zusammenh ngenden Programmfunktionalit t in viele kleine bersichtlichere Methoden Dies beinhaltet haupts chlich die Schritte 5 bis 9 wo die geforderte Robustheit und Wiederverwendbarkeit der Funktionskomponente_ sichergestellt werden Zudem verbessern diese Methoden die Lesbarkeit und Verst ndlichkeit des Programmcodes Damit werden Wartung und Fehlersuche erleichtert Zudem k nnen Fehler meist sofort der Nutzeroberfl che oder der Funktionskomponente zugeordnet werden Obwohl die Schrittfolge algorithmisiert ist sind leider nicht alle Teile automatisierbar dies betrifft in jedem Fall 2 3 6 9 12 und 13 Da diese Schrittfolge nur an zwei Anwendungsf llen und m einer Programmiersprache exemplarisch durchgef hrt werden konnte ist die statistische Aussagef higkeit sehr eingeschr nkt Erforderlich w re hierzu die Anwendung in einer Vielzahl von unterschiedlichen Projekten auf verschiedenen Plattformen und Programmiersprachen Vielleicht l sst sich f r jede Programmiersprache eine angepasste Schrittfolge erstellen um den Grad der Algor thmisierbarkeit weiter zu erh hen W nschenswert ist die Erstellung von programmcode analys erenden Werkzeugen die den Programmierer bei seinen Entscheidungen zur Dekomposition unterst tzen Sinnvoll w re z B ein Werkzeug zum Finden von nicht zustandsver ndernden Anweisungen Interessant wird zudem die Bewertung der Dekomposition durch andere Entwickler m XCtl Projekt
53. des Fachbereichs R ntgenbeugung an d nnen Schichten im Forward Engineering um neue Funktionalit t erweitert Beim Reengineering der einzelnen Subsysteme erfolgt eine Restrukturierung der Systemarchitektur sowie die Analyse und Verbesserung des Programmcodes und der Wartbarkeit Der wesentlichste Punkt ist dabei die Fehlerminimierung Die aktuell auf den Messpl tzen installierte Version Stand 25 04 2003 umfasst 14 Subsysteme mit 38 786 LOC und 208 Klassen in 128 Dateien Pro Subsystem sind durchschnittlich drei Dokumente f r jede Softwareentwicklungsphase vorhanden Alle Dokumente sind im Web Repository des XCtl Projektes phasenspezifisch f r die einzelnen Subsysteme aufgelistet und f r jeden Projektteilnehmer frei verf gbar Zus tzlich existieren eine Vielzahl Projekt begleitender Dokumente wie Beschreibungen von Arbeitsabl ufen Erl uterungen der genutzten physikalischen Prozesse Benutzerdokumentationen Abb I 3 zeigt eine bersicht der Struktur des XCtl Programmes von 2002 als Use Case Diagramm Seite 6 Einf hrung 1 3 Fallbeispiel das XCtl System XCtl Projekt Chutomatsene usage gt Chutomatsene usage gt Manuelle Hanse Aen gt Motorsteuerung Halbwertsbreite messen Ceman X Messprozess durchf hren Topographie V Detektornutzung Protokollbuch l I Messwerte darstellen Diffraktometrie SEN Allgemeine Einstellungen Abb 1 3 Use Case Diagramm des XCtl Gesamtsystems rot
54. die Anzahl der sp teren Do Methoden in der Funktionskomponente zu reduzieren Dies wird durch die Verschiebung der O Bl cke vor oder hinter einen F Block erreicht a Das Verschieben darf nie in eine h here oder tiefere Ebene eines Anweisungsblocks erfolgen b Der zu berspringende F Block darf weder direkt noch indirekt auf dieselben Attribute Parameter lokale und globale Variablen wie der O Block zugreifen es sei denn beide greifen nur lesend zu c Das Verschieben ist auch verboten wenn der zu verschiebende oder der zu berspringende Block zum Verlassen eines Anweisungsblocks f hrt d O Bl cke die erst nach der erfolgreichen Ausf hrung eines F Blockes durchgef hrt werden d rfen z B Benennung von Steuerelementen nachdem eine Aktion ausgel st wurde k nnen nicht verschoben werden Ziel ist es so viele O Bl cke wie m glich an nicht verschiebbaren O Bl cken oder am Anfang oder Ende des Anweisungsblocks zusammenzufassen F Bl cke die durch die Verschiebung eines dazwischen liegenden O Blocks direkt untereinander stehen bilden eine neue Einheit F r zusammenfallende O Bl cke gilt das Gleiche Abb II 3 und Abb III 4 sollen die og Regeln verdeutlichen die eine Umordnung der O Bl cke verhindern Dazu wird jeweils gepr ft ob der O Block vor den davor liegenden oder nach den darauf folgenden F Block verschoben werden kann Bei einem roten Pfeil gt ist dies nicht m glich Dann ist der Hinderungsgrund
55. die Relative Null d h die aktuelle Winkelposition die Istposition wird damit auf 0 gesetzt Das Setzen bedeutet eine Darstellung aller Ausgaben in relativen Winkelpositionen was durch angezeigt wird Die Minimal und Maximalposition werden angepasst Dies wird zur leicheren Justierung einer Probe benutzt indem z B eine h ufig angefahrenen Winkelposition oder die Position von der aus eine Halbwertsbreitenmessung gestartet wird als relative Null gesetzt wird siehe auch Offset Bedingungen ein Antrieb darf nicht ausgew hlt sein Der Antrieb muss sich im Stillstand befinden Die Halbwertsbreite darf nicht gemessen werden Hinweise Das aktuelle Offset f r lt Antrieb gt wird neu berechnet Wenn zuvor ein PSD Kanaloffset definiert war wird es durch diese Aktion aufgehoben d h der zugeordnete Kanal ist wieder 0 Abb 11 12 Verlinkung des Hauptdialogs mit den Hilfe Seiten f r die jeweiligen Steuerelemente am Beispiel der Funktion Relative Null setzen ein Rahmen entspricht einer Hilfe Seite Seite 34 Dekomposition beim Forward Engineering Il 2 Definitionsphase Nach der oben vorgestellten Klass f kation handelt es sich demnach um eine passive uniforme Hilfe mit dynamischen Ans tzen teil dynamisch weil abh ngig vom aktuell angezeigten Dialogfenster ein entsprechendes Hilfe Thema angezeigt wird Am Anfang jedes Hilfe Themas wird das behandelte Dialogfenster genannt siehe Abb IL 12 __D Bei der Beschreib
56. die der CanDo Methode zu ersetzen v Abschlie end muss das Projekt kompiliert und gelinkt werden und ein Regressionstest muss sich anschlie en 11 Kennzeichnung nicht zustandsver ndernder Methoden und konstanter Parameter optional Um ein robustes Design w e beim Forward Engineering zu entwickeln sollten nicht zustandsver ndernde Methoden entsprechend gekennzeichnet werden in C const member functions siehe 16 Gleiches gilt f r unver nderliche Parameter in C durch den type specifier const siehe 16 Dies ist jedoch nicht in allen Programmiersprachen m glich v Zur Verifikation muss das Projekt kompiliert und gelinkt werden Ein Regressionstest ist nicht erforderlich 12 Suche und Korrektur von Fehlern optional An das Ende dieser Schrittfolge sollten sich Wartungsvorg nge anschlie en Weil durch die Dekomposition ein gut strukturierter Programmcode entstanden ist und sich der Entwickler intensiv mit diesem besch ftigt hat sollten Fehlersuche und korrektur zu diesem Zeitpunkt sehr effektiv sein Dazu sind die in der Verhaltensspezifikation oder in separaten Fehlerdokumenten aufgef hrten nderungsw nsche und die im Programmcode markierten Fehler zu beheben Zudem wurden w hrend der Dekomposition wahrscheinlich zus tzliche Fehler gefunden die nicht sofort behoben werden sollten Vielmehr sollten sie im Programmcode gekennzeichnet und beschrieben werden um in diesem Schritt nach einer nochmaligen Pr fung korrig
57. die qualitativen und quantitativen Eigenschaften des Produktes aus der Sicht des Nutzers Ein vorhandenes Lastenheft kann mit den dar n enthaltenen Bas sanforderungen als Grundlage verwendet und verfeinert werden Bei Individualsoftware entstehen Pflichtenhefte meist in enger Zusammenarbeit mit dem Auftraggeber und den sp teren Anwendern des Produktes Die verbalen Ausf hrungen der Produktanforderungen lassen jedoch gro en Interpretationsspielraum und sollten daher in einem vollst ndigen konsistenten Produkt Modell formalisiert werden Die Erstellung eines solchen Modells wird vereinfacht wenn die Produktanforderungen selbst bereits in einem hohen Formalisierungsgrad organisiert und beschrieben sind siehe II 2 1 Nach 2 S 99 k nnen dann aus Pflichtenheft und Produkt Modell erste Oberfl chen Prototypen erstellt und mit Auftraggeber und Anwender abgestimmt werden Ist dieser Prozess abgeschlossen kann eine Vorabversion des Benutzerhandbuches erstellt werden Dadurch sind die Entwickler gezwungen sich in die Rolle des sp teren Anwenders zu versetzen Alle genannten Dokumente auch Artefakte genannt ergeben die Produkt Definition Da diese die Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer bilden kann sind deren Vollst ndigkeit Eindeutigkeit und Widerspruchsfreiheit von gro er Bedeutung Durch weitere Formalisierung der Produkt Definition entsteht in der Designphase das Produktdesign II 2 1 Aufbau von Pflichtenhefte
58. dieselbe Dialogressource Abb II 1 weil das u ere Erscheinungsbild und Bedienverhalten die Spezifikation im Allgemeinen unver ndert bleiben sollte 2 Behandlung von Ans tzen vorhandener Funktionskomponenten Weil im Falle der urspr nglichen Manuelle Justage keine Funktionskomponente existierte wurde eine leere Klasse mit dem Bezeichner TAngleCtl erstellt In der Nutzeroberfl che musste MJ_FUNK H inkludiert werden um im Konstruktor ein Objekt von TAngleCtl erstellen zu k nnen Neben dem neuen Attribut m_InkAngleCtl musste auch der Destruktor ge ndert werden um das dynamisch erzeugte Objekt wieder freizugeben 3 Solldesign festlegen Durch die fehlende Funktionskomponente im urspr nglichen Subsystem war hier kein Kommunikationsmuster vorgeschrieben Aufgrund der Richtlinien aus I1 3 3 5 wurde festgestellt dass hier sowohl Observer Muster als auch Polling Variante anwendbar sind Um diese auch m Reengineering vergleichen zu k nnen wurden beide Muster parallel implementiert Die Implementierung des Singleton Musters w re hier nicht sinnvoll gewesen weil ein Teil der Attribute von TAngleControl bei jedem Aufruf des Dialogfensters neu mit den aktuellen Werten aus den benutzten Subsystemen initialisiert werden muss Beim Singleton h tte eine Dekomposition beim Reengineering Ill 2 Restructuring Seite 115 separate Initialisierungsmethode f r diese Attribute erstellt werden m ssen die dann von der Nutzeroberfl
59. diesen 20 Eintr gen musste bei der sp teren Integration der Oberfl chen Prototypen hier ein zus tzlicher Eintrag hinzugef gt werden Dieses Datenelement wird zum Ausw hlen bzw Anzeigen des zuletzt benutzten Antriebs in einem Steuerelement ben tigt und w re ohne den Nachtrag der Oberfl chenfenster unterschlagen worden Insgesamt werden somit 21 Datenelemente zur Realisierung der neue Manuellen Justage ben tigt Darunter befinden sich sieben Elemente die durch den Anwender manipuliert werden k nnen Da solche Datenelemente direkt an eine Produktfunktion gekoppelt sind Konnte hier auf eine ausf hrliche Erl uterung verzichtet werden Diese Datenelemente sind als Fachtermini im Stichwortverzeichnis aufgef hrt Die brigen 14 Datenelemente werden durch die neue Manuelle Justage nur gelesen und stellen 1 d R weiterf hrende Informationen wie Minimal oder Maximalwert Nachkomma stellengenauigkeit f r die manipulierbaren Datenelemente dar Wie Abb II 5 __ gt zeigt finden sich diese Tabellen als Querverweis in den manipulierbaren Datenelementen wieder D 110 eingegebene Sollposition Die Sollposition ist wie die Istposition abh ngig vom aktuellen Offset des Antriebs Die Minimal und Maximalwerte k nnen demnac Tabelle 7 2ntnommen werden ebenso die Nachkommastellengenauigkeit Die Sollposition ist bei jeder Anderung zu speichern Bezeichnung eingegebene Sollposition Typ Zugriff Eintrag P lesen u
60. ermittelt werden Mtr gt MoveToAngle GetAngleDest alndex bValid return FALSE return TRUE Bewegung erfolgreich gestartet J Abb 11 42 Fortsetzung der Implementierung des Direktbetriebs Methode DoDirect unter Benutzung von CanDoDirect und Methoden des Subsystems Motorsteuerung Vor jedem Zugriff auf andere Subsysteme wird dessen Verf gbarkeit Zustand gepr ft Dazu wurden Methoden implementiert die vorher den Status des gerufenen Systems z B f r das Vorhandensein eines Detektors HasDetectorAxis oder die G ltigkeit eines aus der Nutzeroberfl che bergebenen Parameters berpr fen z B IsIndexValid siehe Abb 11 43 Dazu wird bei Is Has Do und Set Methoden wie bei den Can Methoden die Aufrufumgebung ber den Fehlschlag mit FALSE bzw ber die erfolgreiche Durchf hrung einer Operation mit TRUE informiert Da der R ckgabewert bei Get und Calc Methoden anderweitig verwendet wird erfolgt die R ckgabe ber einen zus tzlichen Referenzparameter siehe Abb II 44 aValid Im Fehlerfall erhalten diese Methoden einen Standardwert als R ckgabewert hier return falls die Aufrufumgebung das Auslesen des G ltigkeits Parameters bergeht und den R ckgabewert wie gewohnt verwendet Dieses Verfahren sichert dass der Entwickler der Aufrufumgebung bei der Dekomposition die Nutzeroberfl che ber eine Problemsituation informiert wird und entsprechend drauf reagieren kann z B eine Fehlermeldung
61. f r Polling in der neuen Manuellen Justage w hrend der Antriebsbewegung 11 3 gt Sardlaliellen yon NulzerobELLACHENTUNG FUNK OO Sowohl das eigentliche Observer Muster als auch die Polling Variante gestatten die Verkn pfung einer Nutzeroberfl che mit einer oder mehreren Funktionskomponenten und umgekehrt Um Fehleranf lligkeit bzw Komplexit t besser zu handhaben sollte die Variante aber nicht beliebig ausgew hlt werden Im Regelfall wird jede Nutzeroberfl che genau eine eigene Funktionskomponente besitzen 1 1 In einigen F llen kann die Nutzeroberfl che aber auch auf mehrere Funktionskomponenten zugreifen 1 n Bei dem eigentlichen Observer Muster w rde f r jede einzelne Funktionskomponente ein Beobachter Interface ben tigt Abb II 30 Seite 60 Dekomposition beim Forward Engineering 11 3 Designphase TFunkt1 interface JOberp mm InkiptertarelOber I E ES Inkinterfach Hinzufusgen vold OnRefteshtliwold Entfernen oid Benachrichtigen void KR KH d U u m_InkFurnkti interface interface iOberf iert eg D DE BE meeeeeeeg m_InkFunkti TFunkti OnRefreshzwald a i a vW lslsdidGlid Mirsliel E Fu nkt37 F unkt3 k Oz m_Inkinterface TFunkt 0 1 m_Inklnterface l berfM m_nkinterface 0 1 TFunkt3 m_Inklnterfacel berfs Hinzufuegen void Entfernen moid Hinzufuegen vold Entfernenvolc m InkFunkt m InkFunkt3 Henachrichtigen voi
62. f r die Aktualisierung dieser Werte zust ndig was der Entwickler z B bei bMoveActive und der Auswahl eines anderen Antriebs vergessen hatte Insgesamt sind dabei neun f r den Anwender offensichtliche Fehler aufgefallen die vorerst nur in M19 dokumentiert werden konnten Zu bem ngeln war auch dass der aktuelle Systemzustand ber Attribute manipuliert wurde um in einer anschlie end gerufenen Methode ein bestimmtes Verhalten auszul sen Zur Korrektur erfolgte die bergabe von Parametern an die jeweilige Methode Zudem sind zahlreiche nutzerdefinierte Botschaften an das Fenster gesendet worden um eine Methode auszuf hren Die Lesbarkeit des Programmcodes war erheblich erschwert weil Botschaften und Methodenbezeichner in keinem Zusammenhang standen Problematisch war dass die Botschaften mit PostMessage versandt wurden was eine Verarbeitung m Hintergrund erlaubt siehe II 4 2 Geschwindigkeitsoptimierungen Deshalb konnten die PostMessage Aufrufe nicht einfach durch den Aufruf der entsprechenden Methode ersetzt werden Bei der getrennten Manuellen Justage waren die Unterschiede zwischen den Ausf hrungszeiten aber so minimal dass sie nicht sp rbar waren Deshalb konnten die Methoden dort doch direkt aufgerufen werden was Verst ndlichkeit bersichtlichkeit und Programmcodeumfang deutlich verbesserte Die Kernfunktionalit t lag zu diesem Zeitpunkt bei der Nutzeroberfl che in Methode Dlg_OnCommand wo auf 327 LOC
63. genannt Ausf hrliche Informationen sind im Anhang nachzuschlagen e Die m glichen Anwendereingaben f r freigegebene Eingabefelder sind im Absatz OC beschrieben Diese Angaben z B Wertebereich und Nachkommastellengenauigkeit sind besonders wichtig weil sie dem Anwender im Dialogfenster nur indirekt angezeigt werden Diese Informationen wurden zusammen mit den Angaben ber die Konfigurationsdateien aus dem Kapitel Daten des Pflichtenheftes entnommen e Im Absatz SS werden die Bedingungen erl utert unter denen die Produktfunktion benutzt werden kann Nicht verf gbare Steuerelemente werden im aktuellen Programmzustand gesperrt und ausgegraut siehe II 2 2 Erleichterung der Bedienung des komplexen Hauptdialogs Diese Informationen entstammen dem Kapitel Benutzer oberfl che des Pflichtenheftes Abschnitt Bedingung des jeweiligen Steuerelementes Wie im Pflichtenheft gibt es blau hervorgehobene Querverweise und Eintr ge im Stichwortverzeichnis __ gt Benutzte und im Stichwortverzeichnis nachzuschlagende Fachbegriffe sind wieder kursiv gekennzeichnet CD Sollpasitior 100 00 Sekunden ies e Us Die_Sollposition_yibt die Zielposition als Relative Positionsangabe siehe Seite 13 an zu der sich der Antrieb im Direktbetrieb bewegen soll In der HARDWARE INI wird im jeweiligen MOTOR lt M gt Abschnitt im Eintrag MJ_AngleDest die zuletzt verwendete Sollposition als reelwertige Zahl gespeichert
64. getestet Es stellt sich also die Frage nach der Notwendigkeit f r den aufwendigen separaten Test der Funktionskomponente Bei der neuen Manuellen Justage besteht die Notwendigkeit aufgrund der hohen Komplexit t des Subsystems bei gleichzeitig hoher Robustheit gegen ber den verschiedenen Anwendergruppen Auch de enge Hardwarekopplung bedingt diesen Test weil die Fehlersuche beim Abnahmetest nicht nur n der Funktionskomponente und der Nutzeroberfl che sondern auch in Teilen der Hardware stattfinden m sste Allgemein l sst sich feststellen dass eine Funktionskomponente die eine hohe Komplexit t eine hohe Robustheit oder eine hohe Wahrscheinlichkeit der Wiederverwendbarkeit aufweist stets separat zu testen ist Weniger umfangreiche aber trotzdem dekomponierte Subsysteme k nnen durch einen Abnahmetest wie hier vorgestellt hinreichend verifiziert und validiert werden Der Feintest der Oberfl che ist zum einen abh ngig von der Anzahl der Steuerelemente die Zustands nderungen ausl sen diese bilden Testf lle und zum Zweiten von der Anzahl der Steuerelemente mit dynamischer Beschriftung ergibt Testdaten Pro zustandsver nderlichem Steuerelement werden zwei zus tzliche Testdaten ben tigt Der Mindestumfang des Feintests kann als Produkt aus Testf llen und Testdaten ganz grob abgesch tzt werden Der oben vorgestellte Feintest w re damit viel zu umfangreich f r einen automatischen Regressionstest Allein 5 301 LOC ATOS Tes
65. in der Nutzeroberfl che durchf hrt erzeugen Zustands nderung in der ADO Dazu werden ffentlichen Methoden ber die Referenz auf die Funktionskomponente gerufen Die wohldefinierte Schnittstelle der Funktionskomponente garantiert Information Hiding gegen ber der Nutzeroberfl che und die unidirektionale Assoziation sorgt f r Environment Hiding In der ADO k nnen Zustands nderungen durch Prozesse von au erhalb ausgel st werden Geschieht dies durch ein ADV hat nur dieses selbst Kenntnis davon Alle anderen ADVs m ssen vom ADO ber Zustandswechsel informiert werden oder sich selbst um die Aktualisierung k mmern Beides bedarf zus tzlichen Aufwands im Design Weil das ADO nichts ber die assoziierten ADVs wissen sollte Environment Hiding ist der Datenaustausch vom ADO zum ADV mit der og Assoziation allein nicht realisierbar Wenn die Synchronisation vom ADV initiiert wird ben tigt diese eine zus tzliche Komponente um regelm ig Zustandsaktualisierungen durchzuf hren Die daf r n tigen Verfahren werden in den folgenden Kapiteln ausf hrlich diskutiert 11 3 3 3 Das Observer Muster Dieses Design Muster engl Pattern beschreibt sprachunabh ngige Designrichtlinien welche Beziehungen von Komponenten in einem modularisierten Softwareprojekt aufbauen Diese Richtlinien gew hrleisten die Konsistenz der Zust nde das Information Hiding sowie die Wiederverwendbarkeit f r die beteiligten Komponenten Ein besonderer Punkt ist
66. in dieser Arbeit bearbeitete Subsysteme Quelle nach M1 Das Programm soll eine m glichst durchg ngige objektorientierte Schichtenarchitektur eine umfassende Kommentierung des Quellcodes und eine vollst ndige Dokumentation aller Software Entwicklungsphasen aufweisen Dadurch kann es von den Physikern selbst weiterentwickelt bzw gewartet werden Die grafische Nutzeroberfl che soll zweisprachig d h wahlweise deutsch oder englisch zur Verf gung stehen Ein wesentliches Ziel des Projektseminars st bereits seit Juni 2003 realisiert Dazu wurde das XCtl Programmes in eine 32bit Anwendung f r das Betriebssystem Windows 2000 mit Microsoft Visual C als Entwicklungsumgebung portiert 1 3 2 Subsystem Manuelle Justage Der Anwendungsbereich Manuelle Justage umfasst die Steuerung aller an einem Messplatz angeschlossenen Antriebe um die Probe eines Halbleiterkristalls im dreidimensionalen Raum zu positionieren siehe M15 Je nach Typ des Messplatzes Topographie Diffraktometrie oder Reflektometrie liegt die Anzahl der angeschlossenen Antriebe zwischen vier und sechs Abb I 4 zeigt einen Topographie Messplatz wo die Halbleiterprobe auf dem Probenteller PT und halter PH positioniert sehr genau in drei Freiheitsgraden bewegt werden kann Daf r wird jeweils einer der Antriebe mit der Bezeichnung az mutale Rotation AR Verkippung TL engl Tilt und Beugung Grob Fein DC DF engl Diffra
67. ist mit insgesamt 35 Testdaten 72 Testf llen f r die Seite 86 Dekomposition beim Forward Engineering Il 5 Testphase Set Methoden und 7 Testf llen f r die Do Methoden das gr te Der jeweilige Programm zustand wird wieder durch die Kombination aus den Betriebsarten den verschiedenen Offsets dem Bewegungsstatus eines Antriebs sowie der Halbwertsbreitenmessung bestimmt Gemeinsames Merkmal der drei beschriebenen CTE Diagramme ist dass alle Operationen nur f r einen ausgew hlten Antrieb getestet werden Dieser eine getestete Antrieb kann aber als gute Referenz betrachtet werden da sich die Steuerung der Antriebe nur in deren Adressierung unterscheidet Um jedoch die gleichzeitige Bewegung mehrere Antriebe zu testen war ein zus tzliches viertes CTE Diagramm mit 14 Testf llen und 10 Testdaten f r 4 Antriebe n tig F r den vollst ndigen Test der Funktionskomponente TManJustage wurden vier CTE Diagramme mit insgesamt 120 Testf llen mit 103 Testdaten erstellt siehe M22 sIndeYalidBOOL HasoffsetBooL 5Moving BOOL scalbrated BOAL HasDetector xis BOL 5Measuring BO OL 5MeasurerResetBo0oL FarsingaxisillINT Gelhlotion ype EMotionType GelAngleDestTAngle GelspeedTSpeed GelAngleWidth TAngle GelkzMoving BOL 5el fsetTAngle GelotorlountllMT GelotorMame LFESTR Setlotion Twpe BOL Sel ngleDestHo0L 5et peed BOOL 5etAngleidth BO GL Setkzoving HOOL 5etofset aiL 5etkzMeasuring oid rot Channel
68. jedoch ber die Funktionskomponente Deshalb entsteht hier ein gewisses Methoden Overhead siehe Abb II 22 ED dass nur der Delegation von Funktionsaufrufen zwischen den beiden Subsystemen dient 1 diese Eigenschaft sollte i d R ein gut dekomponiertes Subsystem kennzeichnen Dekomposition beim Forward Engineering 11 3 Designphase Seite 65 Bei dem Vergleich der Metriken von Funktionskomponente und Nutzeroberfl che Klassen mit Suffix D1g sticht sofort der hohe Anteil an ffentlichen Methoden PPubM bei der Funktionskomponente ms Auge Nur so steht der Nutzeroberfl che die gesamte Funktionalit t zur Verf gung Zusammen mit der Menge an angebotener Funktionalit t NOO garantiert dies aber die hohe Wi ederverwendbarkeit der Funktionskomponente Bei der neuen Manuellen Justage wird diese von drei Nutzeroberfl chen gleichzeitig genutzt Sehr wichtig ist hierbei die Einhaltung der in diesem Kapitel vorgestellten Prinzipien wie zentrale Verwaltung von Wertebereichen und Nachkommastellengenauigkeit sowie die Verwendung von Can in Do und Set Methoden Damit gewinnt die Funktionskomponente eine hohe Robustheit Bei I1 3 2 wurden bereits die minimalen ffentlichen Schnittstellen der Oberfl chenfenster erw hnt die sich nun deutlich in den sehr niedrigen PPubM der Dialogfensterklassen zeigen Dieses Vorgehen sichert die horizontale Konsistenz zwischen den Oberfl chenfenstern und den Funktionskomponenten Aufgrund des mangelnd
69. m ssen die Klassen in den neuen Dateien neu benannt werden Empfohlen wird hier wieder die Kennzeichnung der Oberfl chenklassen mit den Suffixen Dlg oder Wnd siehe 11 3 2 v Beim Kompilieren und Linken wird jede Stelle angezeigt wo Klassen noch mit der alten Benennung benutzt wird berall dort muss der alte Bezeichner durch den neuen ersetzt werden Zur Wahrung der Konsistenz von urspr nglichem Programmcode und existierender Dokumentation werden nun die mit OLD gekennzeichneten Klassen zur ck benannt Da diese Seite 104 Dekomposition beim Reengineering Ill 2 Restructuring Klassen aber nicht benutzt werden ist ein abschlie endes Kompilieren und Linken damit nicht erforderlich aber allgemein stets sinnvoll 2 Behandlung von Ans tzen vorhandener Funktionskomponenten Existieren mehrere von der Nutzeroberfl che unabh ngige Klassen stellen diese Ans tze von Funktionskomponenten dar Ist noch kein solcher Ansatz vorhanden muss in der entsprechenden Header Datei ein leerer Klassenrumpf f r die Funktionskomponente deklariert werden Ansonsten ist eine Dekomposition nur dann problemlos m glich wenn genau eine Funktionskomponente existiert Wenn mehrere vorhanden sind gilt es diese zu einer zu verschmelzen Sonst wird die sp tere Auslagerung von Programmteilen in eine der Funktionskomponenten u U durch die Verteilung der Attribute verhindert Die Verschmelzung ist jedoch nicht m glich wenn mehrere Oberfl chenfenster des zu de
70. parallelisiertt und monochromatisiert wahlweise auch verbreitert aufgef chert Wenn dieser kollimierte Strahl KS auf die kristalline Halbleiterprobe P trifft wird er entweder an den atomaren Netzebenen gebeugt Diffraktometrie Topographie oder an der Oberfl che oder Grenzfl che spiegelnd reflektiert Reflektometrie Das jeweilige Verhalten wird durch den Einfallswinkel zwischen Probe und einfallendem R ntgenstrahl bestimmt Dazu kann die Probe im dreidimensionalen Raum positioniert werden weil sie auf einem beweglich gelagerten Probenteller PH liegt Die gebeugte bzw reflektierte R ntgenstrahlung RS wird bei der Topographie fotografisch F und bei der Diffraktometrie Reflektometrie durch R ntgendetektoren K D erfasst Bei den Detektoren werden die Messdaten digital aufgezeichnet Das erm glicht sp tere Bildtransformation und die Auswertung am Bildschirm Wahlweise k nnen die Daten auch in einer Datei abgelegt werden Die Kr mmung des Kollimators und die Antriebe zur Positionierung von Detektor und Probenteller besitzen zahlreiche Stelleinheiten und k nnen mit minimalen Schrittweiten von ca 1 180 000 Grad bewegt werden K D SC F RS RQ PH Abb LI Schematischer Aufbau eines Topographiearbeitsplatzes Quelle nach M2 Urspr nglich handelte es sich bei der XCtl Software um eine 16bit Windows Anwendung die in der Einsatzumgebung unter dem Betriebssystem Windows 3 11 arbeitete Die Implemen
71. protected Attributen Methoden Operatoren Kon Destruktoren e PPubM Percentage of Public Members ist der prozentuale Anteil an public Attribu ten Methoden Operatoren Kon Destruktoren PPrivM PProtM PPubM 100 e AC Attribute Complexity ist die Summe aus der Gewichtung aller Attribute Dazu ist jedem Attribut ein Wert zugeordnet Beginnend bei eins f r Standardtypen erh ht sich dieser mit steigendem Abstraktionsgrad z B f nf f r void und neun f r nutzerdefinierte Typen e MNOP Maximum Number Of Parameters errechnet sich aus der Anzahl der Parameter in der l ngsten Parameterliste aller Methoden und Operatoren e NOC Number Of Classes z hlt die Anzahl der enthaltenen Unterklassen und Strukturen einer Klasse Sind keine enthalten ist der Wert eins F r jedes weitere Element wird die Anzahl um eins inkrementiert Alle anderen Metriken beziehen sich nur auf die direkt enthaltenen Attribute Methoden Operatoren Kon und Destruktoren Elemente aus den enthaltenen Klassen Strukturen werden nicht beachtet e TCR True Comment Ratio stellt die Leer und Kommentarzeilen in Relation zu LOC in Prozent Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 21 11 2 Definitionsphase Nach 2 S 98 besteht die wichtigste T tigkeit der Softwareentwicklung in der Erstellung der Produkt Definition Dazu werden zuerst die Produktanforderungen ermittelt und im Pflichtenheft gesammelt beschrieben Sie bilden
72. zudem die Wahrung des Environment Hiding Eine ausf hrliche Beschreibung des Observer Musters ist in 8 zu finden Die Basiselemente des Observer Musters sind Subjekte engl Subjects und Beobachter engl Observer Zwischen diesen beiden besteht eine Beziehung die als bekannt machen teilnehmen engl publish subscribe bezeichnet wird S e ist dadurch charakterisiert dass beliebig viele Beobachter mit einem Subjekt assoziiert sein k nnen ohne dass dieses Subjekt genaueres ber seine Beobachter wei Ein Subjekt ist in der Lage Nachrichten an assoziierte Objekte zu versenden ohne wissen zu m ssen wer sie erh lt Zur Umsetzung dieser Beziehung 14 2B Hardwareansteuerung oder langwierige Berechnungen Seite 52 Dekomposition beim Forward Engineering II 3 Designphase werden die vier Elemente Subjekt Beobachter Konkretes Subjekt engl Concrete Subject und Konkreter Beobachter engl Concrete Observer mit folgenden Eigenschaften ben tigt Subjekt e definiert eine Schnittstelle um Beobachter zu binden und wieder freizugeben e speichert die assoziierten Beobachter in eine Liste Beobachter e definiert eine Schnittstelle f r Objekte die bei Zustands nderungen m Subjekt benachrichtigt werden sollen konkretes Subjekt e hat einen inneren Zustand e sendet eine Nachricht wenn s ch dieser Zustand ge ndert hat Konkreter Beobachter e hat einen inneren Zustand der konsistent zum Subjekt Zustand sein soll e hat
73. zwei Timer Komponenten Zus tzlich war noch ein weiterer Timer vorhanden der nie gestartet nur gestoppt wurde Dieser wurde als Toter Code eingestuft und auskommentiert Auch die Klasse TTopographyAdjustDlg wies Toten Code auf wie das Feld SensorList 0 das zwar deklariert aber nirgends benutzt wurde Die Nachrichtenbehandlung in TTopographyExecDlg erfolgte in der Methode Dlqg_OnCommand innerhalb einer gro en switch Fallunterscheidung Dadurch war fast die gesamte Funktionalit t der Klasse dort konzentriert Von insgesamt 422 LOC entfallen allein 314 ca 34 auf diese Methode Jede Behandlung eines case Falls wurde in eine neue private On Methode ausgelagert Um konsistent zur existierenden Benennung zu sein wurden diese mit dem Pr fix Dlg_On versehen Be der Klasse TTopographyAdjustDlg wurde ebenso verfahren siehe Abb III 21 5 Neuordnung der Attribute Jedes Attribut des Subsystems das direkt oder indirekt f r die Berechungen und Messvorg ngen in der Topographie relevant ist wurde in de Funktionskomponente verschoben Zur eindeutigen Kennzeichnung wurde den Attributen dabei das Pr fix m_ vorangestellt Das Attribut Detector war in beiden Oberfl chenklassen deklariert Insgesamt wird aber nur eine Detektorreferenz ben tigt die nun durch die Funktionskomponente verwaltet wird In allen drei Klassen wurde der Zugriffsschutz private f r alle Attr bute gew hlt In der Dialogklasse TTopographyExecDlg verblieben nur die neuen
74. zwei sich gegenseitig rufenden Nutzeroberfl chen gestaltete sich die Dekomposition unkompliziert Eine zuk nftige Zusammenlegung der Dialoge wie bereits in der Projektgruppe geplant ist problemlos m glich Dann sollten sich Vorz ge der Dekomposition deutlich zeugen und eine effiziente Neuimplementierung ist m glich d h schnell und fehlerresistent Durch die Zerlegung der Komplexit t bei der Dekomposition konnte eine Vielzahl der vorhandenen Fehler beseitigt werden Einige grundlegende Probleme sind auch nach der Dekomposition erhalten geblieben die jedoch erst nach nderung der Spezifikation und Absprache mit den Mitarbeitern des Physikalischen Institutes gel st werden k nnen Das betrifft haupts chlich den Zeitpunkt und die Art der Auswertung von Nutzereingaben Durch die verbesserte bersichtlichkeit und Kenntnisse der Spezifikation konnte in Schritt 10 die Robustheit gesteigert werden da mehrfach genutzte Funktionalit t nur an einer Stelle implementiert ist Durch die Dekomposition ist ein umfangreicher Codezuwachs bei alle Klassen festzustellen insgesamt 738 LOC urspr ngliche Topographie zu 1 065 getrennte Topographie vgl Tab III 1 und Tab III 10 Am gr ten ist der Zuwachs bei der Funktionskomponente mit ca 468 Die Komplexit t der Nutzeroberfl chen hat sich dabei nur geringf gig ge ndert Die Anzahl der Methoden hat in der Nutzeroberfl che von NOOo 8 auf 23 deutlich zugenommen Wie bei der ge
75. 1 2004 Thomas Kullmann G nther Reinecker Dekomposition von Software Systemen Inhalt INHALT TABELLENVERZEICHNIS 2 22 22 32 aan BURN ee u ABBIEDUNGSVERZEICHNIS eneen eenegen ee II ABKURZUNGSVERZEICHNIS sunshine ua V EINF HRUNG EL SEHR 1 ELL Aufsabente E E 2 1 2 Kapitel berse Di teen Eegen 3 I 3 Fallbeispiel das et HEES Eege ee 4 13 1 Allsemeine Beschreibungen I a a 4 132 Subsystem Manuelle J ustage nass ee 6 1 33 Subsystem Topographie ua 7 Ek Motivation N E E 9 1 4 1 Bew ltigung der Progerammkomplexv t 9 1 4 2 Austausch Flexibilit t und Wartung der Nutzeroberfl che 12 1 4 3 Austausch und Wartung der Funktionskomponente eeeneeesssssseoeeeereessssssssssssse 14 1 4 4 Kombinierbarkeit von Brogrammersprachen 15 1 45 Jk sense T E EAR E T 16 II DEKOMPOSITION BEIM FORWARD ENGINEERING ILE eelere 18 Anwendunsstall Manuele JUSta ge Hanni 18 DEZ Fettes 21 112 5 Aufbau von Pflicheenhelten aan ae 21 Anwendungsfall Manuelle Justage u 24 122 Obertlachen Protowpi08 ns 28 Anwendungsfall Manuelle Justage u a ae aaa 29 IT2 rte 31 Anwendungsfall Manuelle Justage 2 2 nenn 31 H24 Ben tzerhandbuchs sw aaa 34 Anwendungsfall Manuelle Justage ssnnnnnneeeeesessssssssssseeeerrrssssssssssssseeeereressssssss 35 172 5 Eet 38 Anwendungsfall Manuelle Justage u es 38 12 6 Zaanen as UE a een 41 IE e uns ae eane EEE EENAA A ARE ENAA 44 11 3 1 Verfeiner
76. 6 des Quellcodeumfangs der wirklichen Nutzeroberfl che Auch die Verh ltnisse von NOO 6 zu 60 und NOA 3 zu 12 vgl Tab II 9 und Tab II 7 zeigen deutlich ihre Einfachheit Ein gro er Vorteil der Testoberfl che ist dass es f r das Design der Oberfl che keine Vorgaben gibt Damit konnte das Fenster auf die ffentliche Schnittstelle von TManJustage vgl Abb II 46 zugeschnitten werden was die parallele berwachung fast aller nicht zustandsver ndernder Operationen in jedem Objektzustand erm glicht Nach jeder Nutzereingabe erfolgte dazu eine Aktualisierung Da die Offsetdialoge Offset f r lt Antrieb gt und Offset f r PSD siehe Abb II 10 unten bereits implementiert waren konnten die damit realisierten Produktfunktionen durch Verkn p fung dieser Dialoge mit der Testoberfl che ohne zus tzlichen Aufwand getestet werden WEE TManJustageTestDlg 233 3 6 1 3 55 45 27 4 1 A Tab IO Ausgew hlte Metriken der Testoberfl che O Manuelle Justage Funk Test Motoen Min Position Detectar PSP Actual Dos Detector Anit H Max Position Has Detector e Can MoionT ppe Can Anglebest Can Yelocibp Lan Anglewidth D Can HezetZerm D Can Offsel 1 Can Nenne 1 Can Interrupt D IsHeasur Aeset D Abb 11 56 Dialog Manuelle Justage Funk Test f r TManJustageTestDlg Seite 88 Dekomposition beim Forward Engineering Il 5 Testphase TBasiceDia
77. Anwendung erm glicht eine komfortable Bearbeitung Wartung der rtif Dateien Im Hinblick auf die begrenzten Speicherressourcen wurden f r beide Subsysteme getrennte Hilfedateien erstellt um nur die ben tigten Dateien Im einfachsten Fall ruft ein Druck auf die Taste F1 die Hilfe zum aktuell ge ffneten Fenster auf Concurrent Versions System Anwendung zur Verwaltung verschiedener Programmversionen Seite 32 Dekomposition beim Forward Engineering Il 2 Definitionsphase installieren zu k nnen Abb II 11 F r jede Version existieren jeweils zwei CVS Module einmal mit und einmal ohne Bilder Verschmelzung zu einem Projekt Ausgangsversion incl Automatische Justage bebildert Diffraktometrie Reflektometrie t rein texturell b bebildert Graphische Darstellung der Messwerte t rein texturell b bebildert neue Manuelle Justage und Protokollbuch bebildert Die Hilfe liegt als rtf Datei vor die direkt in eine hip Datei bersetzt werden kann Die Hilfe liegt als HelpScribble Datei vor Diese kann als rtf Datei exportiert und in eine hIp Datei bersetzt werden Abb 11 11 Entwicklung der XCtl Hilfe Anfangs wurde nach weiteren M glichkeiten gesucht um die einfache Erstellung und Wartung der Hilfetexte sowie ein komfortables Hilfe System anzubieten ohne dabei viel Festplattenspeicherplatz zu belegen Da die Hilfe noch unter Microsoft Windows 3 1x nutzbar sein soll
78. Autoren erstellen Dokumente zu Eine wiederholte abwechselnde Bearbeitung sollte dabei zu gut verst ndlichen und gleichzeitig hochgradig formalisierten Dokumenten f hren Review Um die parallele Entwicklung von Funktionskomponente und Nutzeroberfl che w hrend der Implementierungs und Testphase zu beweisen wurde hier eine Aufgabenteilung vorgenommen Beim Forward Engineering bernahm dazu der Autor Thomas Kullmann die Arbeiten an der Funktionskomponente der neuen Manuellen Justage w hrend G nther Reinecker die Nutzeroberfl che entwickelte Um verallgemeinerbare Erfahrungen ber die Trennung im Reengineering zu sammeln wurden zwei eigenst ndige Subsysteme des XCitl Steuerprogrammes ausgew hlt und unabh ngig voneinander von je einem Autor dekomponiert Thomas Kullmann bearbeitete dazu das Subsystem Topographie siehe 1 3 3 und G nther Reinecker die urspr ngliche Manuelle Justage siehe 1 3 2 Die dabei gewonnenen Erkenntnisse wurden analysiert formalisiert und in einer allgemeing ltigen Schrittfolge zusammengefasst Einf hrung 1 2 Kapitel bersicht Seite 3 I 2 Kapitel bersicht Kapitel I soll eine allgemeine Einf hrung in den Gegenstandsbereich und das zugrunde liegende Softwareprojekt geben Dazu werden in Kapitel I 3 Fallbeispiel das XCtl System das Softwaresystem als Ganzes und die beiden Anwendungsf lle Topographie und Manuelle Justage grob skizziert Anschlie end zeigt Kapite
79. BOL m_kzMeasuring BOL m_Updatecount JNT Get hannel int Gel AnglePerZhannelo TAngle GelMotorNamecint BOOL SiLPESTR Getlnit int BOOL Ei LFESTR GetAngle in BOOL amp TAngle GetAnglebincint BOOL k TAnGIE GetAngleMastint BOOL S TAngle GetDigitscinti BOOL INT GetOfsettint BOOL amp TAngle GelMotionTypedcint BOOL amp iEMotionType GetAngleDesttint BOOL ki TAngIe GetSpeedcint BOOL TSpeed GetAnglevidthiint BOOL amp TAngle Getbetector TDetector Setotion ypedcint EMotion Type SAOL 5el nglebDestiint TAngle Si BO OL 5etSpeedtint TSpeed KYHOOL 5etAngleWidthcint TAngle Si BO OL ZanselMotonTypelint BooL CanSetAngleDesttint BOAL CanSetSpeedcint BOOL CanSetAnglevidthiint BOL TManJustage Gethotorcounte LINT 5etRelativeerotint BOOL ResetFelatiwvezerocint BOL 5etoffsettint TAngle Ei DHOOL DoDirecttint BOOL DobrwedintEDirectiom BOOL DoSteptint EDirectionmn BOOL DosStoptcint BOOL DostartMeasure HD BOOL DoStopMeasure BOL 5etthannelcint e BOL CanResetFelatiwvezerocint BOOL rant feet rf BOL rant ioirect mb BOOL ZanDoDrwerint EDirectioni BOOL ZanDoStepd int EDirecton BOOL ZanDoStopeind BOOL ZanDoStartMeasuren BOL ZanDoStopMeasuren BO OL Dekomposition beim Forward Engineering IA Implementierungsphase m_InkhMotorTMotor m Axis Type TAxisType m_Motorld char 512 m_MotionType EMotionType m_AnglebDestTAngle m_Speed TSpeed PT Anglewsidth TAngle Pm kKahdowv
80. BOOL GetMotorldx int GetMotorldx int G5el Angle TAngle GelAngleMin TAngle ZalcChannel ffsetTAngle 2 ale hannel ngle TAngle Zalc ffsetfromAngle TAngle ZalcAngleFromofsetTAngle 5etRelative ero HOL ResetkRelatvelero BOoL GelAngleMaxTAngle GetDigits LINT GetlJnitLFPFCSTR GetDetector xislidxint GetDetectorName LPCSTRH 5et hannelint GelAnglePerlhannel TAngle GelkzMeasuring BoOL GelNeasurefrogress BooL GelNeasureHwh double GelDetectorTDetector CanDoDirect HOL rant iorive BOOL CanDoStep ROOL CanDoStop HOOL ZanselMoton Type BOL Zansel ngleDestBooL 2 anselSspeecBO0OL Zanset ngleidtn BO0OL ZanrReseflrelatvezero BOoL 2 ansel fsetBOoLl 2 anDoStartMeasure BOOL 2 anDoStopMeasure BOOL DoDirect HOOL ODoDrive BOL Dostep BOOL DoStop BOOL DoStopEverthing oid DosStatMeasure DHOOL DostopMeasure BOOL ES nicht zustandsver ndernde Methoden Get Has Is Can und Calc M L 1 zustandsver ndernd mit geringer Komplexit t Set M EZ zustandsver ndernd mit hoher Komplexit t Do M Abb 11 55 ffentliche Schnittstelle von TManJustage zerlegt nach der Komplexit t ihrer Methoden 3 Erstellung einer Testumgebung Anpassung der existierenden Nutzeroberfl che oder Implementierung einer Testoberfl che Die Nutzeroberfl che der Manuellen Justage ist sehr komplex siehe Abb II 10 und wurde parallel zur Funktionskomponente implementiert Da die Ober
81. DIPLOMARBEIT zur Erlangung des akademischen Titels DIPLOM INFORMATIKER DEKOMPOSITION VON SOFTWARE SYSTEMEN IN FUNKTIONSKOMPONENTE UND NUTZEROBERFL CHE IM FORWARD UND REENGINEERING Thomas Kullmann G nther Reinecker Januar 2004 Gutachter Prof Dr sc nat Klaus Bothe Dipl Inf Kay Sch tzler Humboldt Universit t zu Berlin Math Naturwiss Fakult t II Institut f r Informatik Lehrstuhl f r Softwaretechnik und Theorie der Programmierung Danksagung Unser besonderer Dank gilt Herrn Prof Bothe Herrn Sch tzler und Herrn Sacklowski f r die Betreuung sowie den Mitarbeitern des Physikalischen Institutes Prof Dr Rolf K hler Dr Hanke Frau Richter und Herrn Panzner f r die gute Zusammenarbeit Sie unterst tzten uns bei technischen Fragen und stellten uns so oft es ging die Messpl tze zur Verf gung Au erdem m chten wir unseren Eltern Geschwistern und Lebensgef hrtinnen f r ihre Unterst tzung w hrend des Studiums sowie Herrn S ndig recht herzlich f r die orthographische Durchsicht danken Selbst ndigkeitserkl rung Hiermit versichern wir dass wir die vorliegende Diplomarbeit selbst ndig und nur unter Zuhilfenahme der angegebenen Quellen erstellt haben Oranienburg 28 01 2004 Thomas Kullmann G nther Reinecker Einverst ndniserkl rung Wir erkl ren hiermit unser Einverst ndnis unsere Diplomarbeit n der Bibliothek des Institutes f r Informatik ffentlich auszustellen Oranienburg 28 0
82. Dialogfenster Topographie Durchf hrung der Klasse TTopographySetParamDlg f r das ebenfalls modale Dialogfenster Topographie Einstellungen siehe Abb III 2 und dem Ansatz einer Funktionskomponente in Form der Klasse TTopographyOld Alle drei Klassen sind in der Header Date TOPOGRFY H deklariert und in der Datei M_TOPO CPP implementiert Eine Besonderheit ist dass der Dialog Topographie Einstellungen sowohl ber einen Men punkt im XCtl Hauptmen Einstellungen gt Topographie als auch ber die 9 Schaltfl che Einstellungen im Dialog Topographie Durchf hrung aufgerufen werden kann Geschieht dies auf die letztgenannte Weise sind ein Teil der Eingabefelder die zur Eingabe von Parametern vor einer Messung dienen gesperrt und ausgegraut Die brigen gestatten die Einstellungen f r den Detektor w hrend eines Messvorganges zu ndern Die Implementierung der urspr nglichen Topographie umfasst insgesamt 738 LOC ohne Leer und Kommentarzeilen Keines der anderen XCtl Subsysteme greift auf den Programmcode dieser Komponente zu d h das System ist abgeschlossen Dekomposition beim Reengineering IIl 1 Ist Analyse Seite 101 Topographie Durchf hnung Stalueniormsliaor en Beschr nkung auf 500 Sekunden aktuelle Mehzeit DS 00 00 Startposikon einstellen a Lage HILD Prozent Fahren mit 0 300 Sekunden _Begelung starten As lsliche
83. Durch die Modularisierung k nnten einzelne Programmteile mit einer Pseudo Funktionalit t hinterlegt werden welche die eigentlichen Funktionen nur simulieren Beispielsweise wird anstelle des Ergebnisses einer komplexen Berechung nur ein konstanter Wert zur ckgegeben So kann das Zusammenwirken mit anderen Programmteilen oder das Gesamtverhalten vorgef hrt werden obwohl die eigentliche Implementierung unvollst ndig ist Diese Vorgehensweise wird besonders beim Prototypen Modell siehe 3 S 114ff eingesetzt Beim weiteren Fortschreiten des Entwicklungsprozesses wird diese Simulation Schritt f r Schritt durch die eigentliche Funktionalit t ersetzt So erfolgt ein allm hlicher bergang vom Prototyp zum realen Produkt ohne dass die Entwicklung der Nutzeroberfl che davon betroffen ist siehe Abb 1 10 Die M glichkeit zum Austausch der Funktionskomponente kann besonders beim Testen der Verkn pfungen zwischen Nutzeroberfl che und Funktionskomponente eingesetzt werden Hier k nnen die eigentlich vollst ndig getesteten Funktionskomponenten durch Platzhalter engl stubs ersetzt werden um m gliche Verkn pfungsfehler in der Nutzeroberfl che zu identifizieren siehe II 5 2 Hazurlie Seal TE EEE ETTEET ST POSIT iOH ase O Benutzeroberfl che i E J T u ie 1 n CC Fahbarmb l S ch Sch ete SCHRITT arena 1j istemin og LTE rl Oe vn ET Joes C Doektagch ie ipo Ju nind RELATIVE MLL Faber Ge
84. E MULL ken Anbeb ee ee 100 45 selzer Aaufhelien C Dreiabeineb FE Scolposkior T7 E36 ISTFOSITION 75 chkilttbeineb FA Scheilweile 0 0000 Tiisel Coo Abbildung 8 kein Antrieb ist ausgew hlt Quelle 4 Bedingung gt Der gew hlte Antrieb darf in keinem anderen Teilbereich angezeigt werden sonst erscheint die Fehlermeldung Der Antrieb lt Antrieb gt ist bereits ausgew hlt lt Antrieb gt steht f r den Namen des soeben doppelt ausgew hlten Antriebs Der zuletzt angezeigte Antrieb wird wieder ausgew hlt Der Eintrag kein Antrieb darf in beliebig vielen Teilbereichen ausgew hlt werden Abb 11 9 Auszug aus dem Teil Benutzeroberfl che des Pflichtenheftes M15 11 2 2 Oberfl chen Prototyping Nach 2 S 100 ist ein Oberfl chen Prototyp auch Oberfl chenentwurf oder Human Interface Prototyp ein provisorisches ablauff higes Software System bei dem die Bedienoberfl che ohne die dahinter liegenden fachlichen Funktionen realisiert ist Ziel ist es dem Auftraggeber und den sp teren Anwendern einen realistischen Eindruck der Nutzeroberfl che zu geben Die Oberfl chen Prototypen entsprechen stets dem aktuellen Erkenntnisstand des Entwicklerteams Diese sollen aus dem Produkt Modell entstehen siehe 2 S 99 im Falle der Objektorientierung also erst nach der OOA Durch den starken Formalisierungsgrad die deutliche Gliederung und die dargelegten Informationen in einem Pfl
85. EN Aktueller Antrieb ba R Kolimator Schritt Betneb mu De 0 0100 Grad t Fahren mit Y 75 24 sl Verlangen Abb Il 1 Dialogressource zur urspr nglichen Manuelle Justage Der erste Kontakt mit der Manuellen Justage erfolgte bereits im Vorbereitungsseminar Projekt Softwaresanierung als die Verhaltensspezifikation M13 einem Review unterzogen wurde Dieses Dokument besteht aus der funktionalen Beschreibung der verwendeten Nutzeroberfl che Abb II 1 und beschreibt die G ltigkeitsbereiche f r die Eingabefelder und Dekomposition beim Forward Engineering Il 1 Analysephase Seite 19 den Inhalt des Kombinationsfeldes Die konkreten Werte stammen aus der Konfigurationsdatei eines Topographiearbeitsplatzes und haben damit nur exemplarischen Charakter Zudem s nd nderungsw nsche und offene Fragen aufgef hrt Zu Beginn der Diplomarbeit erfolgten eine Bestandsaufnahme der Dokumente und eine bersicht ber die Softwarestruktur des urspr nglichen Subsystems siehe Tab II 1 Dateien e M_DLG CPP SWINTRAC H Subsystem TBasichlalog Benutzeroberfl che TModalDlg Subsystem urspr ngliche Manuelle Justage Sensor DN TDetector Subsystem eh Detektornutzung EventDelertor nl Dokumentation e Analyse Definitionsphase o Verhaltensspezifikationen Verhaltenspezifikation Pflichtenheft XCTL Steuerprogramm M14 o eine kurze Use Case
86. ERS ch TAngleCctl 3 0 d 46 O 10 0 90 36 2 1 44 TAnglectlDlgqg 4388 6 7 1 6 D 13 4 46 4 1 38 Tab I1l 4 Ausgew hlte Metriken f r die Klassen bei der getrennten Manuellen Justage Polling Variante Dekomposition beim Reengineering Ill 2 Restructuring Seite 131 Am anschaul chsten kann der Vergleich zwischen dem Ausgangszustand und dem dekomponierten System anhand der Klassendiagramme von Tab II 1 und Tab III 3 Polling Variante bzw Abb III 22 Observer Muster gef hrt werden Augenscheinlich st bei der Dekomposition zuerst das komplexere Design Hierf r ist insbesondere die Timer Komponente verantwortlich die bei der Polling Variante mit der Nutzeroberfl che und beim Observer Muster mit der Funktionskomponente in Beziehung steht ausf hrlich s ehe 3 Trotz der komplexen Anbindung werden zur Steuerung des Timers nur 6 LOC ben tigt Deutlich sichtbar wird beim Vergleich mit dem urspr nglichen System auch die Trennung der benutzten Subsysteme von der Nutzeroberfl che durch die Funktionskomponente Die meist nicht objektorientierte Anbindung dieser Systeme an die urspr nglichen Manuellen Justage wurde auch in die getrennten Variante bernommen Damit ist die deutliche Schichten Architektur wie bei der Neuentwicklung vgl Abb 11 37 im Klassendiagramm nicht erkennbar W hrend der Dekomposition konnte die vorhandene Fehlerliste M19 von 1 auf 10 Fehler erweitert werden dies allein mit Fehle
87. Ereignisses nnerhalb der Funktionskomponente Konkreter Subjekt durch st ndiges Nachfragen ermittelt Beim Polling entfallen sowohl das Subjekt als auch das Beobachter Interface weil sie nicht ben tigt werden 5 Die Methode hei t Polling weil es wie bei den Bienen darum geht mehrere Bl ten immer wieder zu besuchen um deren neue Pollen einzusammeln Dekomposition beim Forward Engineering 11 3 Designphase Seite 57 Erforderlich ist hier aber meistens ein Mechanismus in der Regel ein Timer der regelm ig Ereignisse ausl st die zum Aufruf von Methoden des Subjektes benutzt werden um dessen Status zu erfragen Diese Statusabfrage kann aber auch zu diskreten Zeitpunkten durch Anwendereingaben ausgel st werden dann wird kein Timer ben tigt Vorteile der Polling Variante e Die Polling Variante ist in allen objektorientierten Programmiersprachen weniger umfangreich als das eigentliche Observer Muster e Das Environment Hiding ist wesentlich besser da das Konkrete Subjekt berhaupt keine Informationen ber die assoziierten Konkreten Beobachter enth lt Deshalb werden weder die Beobachter noch die Subjekte Komponente ben tigt Wie das eigentliche Observer Muster hat auch die Polling Var iante Vorteile die speziell bei der Dekomposition in Funktionskomponente und Nutzeroberfl che zum Tragen kommen e Das einfachere Design der Polling Variante verbessert vor allem die Wiederverwendbarkeit der Funktionskomponente e Wen
88. Funktionskomponente B als Klasse in Datei 1 als Klasse in Datei 4 Abb 1 6 Bew ltigung der Programmkomplexit t durch Zerlegung in zwei Subsysteme Modularisierung und Dekomposition in GUI und Funktionskomponentenklasse Die objektorientierte Programmierung OOP unterst tzt dies zus tzlich durch die Abstraktion des Klassen Konstrukts Hierbei ist die r umliche Trennung von Programmcode Seite 10 Einf hrung 1 4 Motivation mit dem Schutz von Daten und Funktionen vor Zugriffen durch andere Programmteile bersichtlich kombiniert Erfolgt die Dekomposition von Funktionalit t und Nutzeroberfl che n separate Klassen lassen sich alle Vorteile der Objektorientierung ausnutzen So erm glicht OOP die Integration von zwei Kernpunkten der Softwareentwicklung in einem Projektentwurf Der erste Punkt ist das Information hiding deutsch Datenkapselung Dabei wird der Zugriff auf einzelne Komponenten d h Attribute Klassen oder Subsysteme nur ber eine wohl definierte Schnittstelle erm glicht Bei der Dekomposition von Funktionskomponente und Nutzeroberfl che wird Information hiding durch separate Klassen mit gesch tzten Attributen d h meist privatisiert und einer festen Anzahl an ffentlichen Methoden erreicht Damit k nnen Datenaustausch und manipulation zwischen der Nutzeroberfl che den Funktionskomponenten und der Hardwareansteuerung bersichtlich auf das Notwendigste beschr nkt werden Der zweite Punkt ist das Environ
89. HI 1 Ist Analyse Zu Beginn des Reengineering muss das Altsystem analysiert werden Falls keine entsprechenden Dokumente existieren m ssen diese in einem Reverse Engineering erstellt werden Vorhandene Dokumente sind zu analysieren und u U zu aktualisieren Dies dient der Einarbeitung in den Gegenstandsbereich Der Schwerpunkt sollte hierbei auf der Verhaltensspezifikation liegen weil sie am besten den aktuellen Zustand des Systems widerspiegelt Es k nnen auch vorhandene Pflichtenhefte miteinbezogen werden obwohl diese in der Praxis leider oft veraltet sind weil ihre Wartung sehr aufwendig ist oder als berfl ssig angesehen wird Zur Erfassung von Vererbungshierarchie und Beziehungstypen in einem OOD Modell sollte jede Dokumentation der Designphase z B UML Diagramme gesammelt und ausgewertet werden Deshalb ist die Erstellung eines unter II 3 4 beschriebenen Designdokumentes ratsam weil neben den ben tigten Informationen auch die Intentionen des damaligen OOD Entwicklers enthalten sind Zur Bewertung von Design und Programmcode ist der Einsatz von Metriken denkbar Dies kann helfen Designfehler zu identifizieren und in der dekomponierten Version zu vermeiden Anwendungsfall Manuelle Justage Eine Ist Analyse der urspr nglichen Manuelle Justage wurde bereits im Forward Engineering f r die Erstellung der neuen Manuelle Justage vorgenommen siehe II 1 Dies geschah phasenspezifisch um die Effektivit t zu steigern
90. Interfaces in den Klassen der Nutzeroberfl che nach sich Wenn bereits ein Ansatz einer Funktionskomponente existierte empfiehlt es sich das existierende Kommunikationsmuster beizubehalten So werden sp ter nderungen am Programmcode gering gehalten damit keine zus tzlichen Fehlerquellen entstehen Zudem sollte die Einf hrung des Singleton Musters I1 3 3 2 forciert werden wenn sicherzustellen ist dass zu jedem Zeitpunkt nur maximal eine Instanz der Funktionskomponente existieren darf Dabei d rfen die unter 2 genannten Kriterien ber die Initialisierung der Komponente nicht verletzt werden v Nach dem Kompilieren und Linken ist ein Regressionstest auch der benutzenden Subsysteme durchzuf hren 4 Programmcodelayout verbessern optional Zur Verbesserung der Lesbarkeit sollte der Programmcode formatiert kommentiert und potentielle Fehlerquellen markiert werden Toter Code st auszukommentieren und mit dem aktuellen Datum zu kennzeichnen S cherzustellen ist ferner dass keine uninitialisierten Attribute lokale oder globale Variablen verwendet werden Dekomposition beim Reengineering Ill 2 Restructuring Seite 105 v Kompilieren Linken und ein Regressionstest der benutzenden Subsysteme stellt sicher dass keine Fehler unterlaufen sind Um bersichtlichkeit und Lesbarkeit der Nutzeroberfl che weiter zu verbessern ist die Behandlung von Steuerelementbotschaften in einzelne Methode auszulagern Dazu muss der Programmcode durch
91. Justage einen wesentlich h heren Funktionsumfang dies sowohl n der Funktionskomponente als auch der Nutzeroberfl che Zweitens muss hier auch der von den Mitarbeitern des Physikalischen Institutes gew hlte Oberfl chenentwurf mit in die Bewertungskriterien einflie en Allein dies f hrt zu einem wesentlichen h heren LOC NOA NOO Aufkommen auf Seiten der Nutzeroberfl che der neuen Manuellen Justage Drittens haben sich die Autoren dieser Arbeit f r die objektorientierte Anbindung bei der neuen Manuellen Justage entschieden was zus tzliche LOC bei der Funktionskomponente verursacht Der Grund ist dass die nicht objektorientierte Schnittstelle des Subsystems Motorsteuerung keine M glichkeit einer sicheren Anbindung bietet Im getrennten Subsystem musste die gr tenteils n cht objektorientierten Anbindung durch die Schrittfolge aus dem urspr nglichen System bernommen werden f r Gr nde M glichkeiten Vorteile zur Reduzierung der Attributanzahl siehe die drei Teilbereiche im Hauptdialogfenster und die zus tzlichen Offset Dialoge tragen dem Rechnung Seite 132 Dekomposition beim Reengineering Ill 2 Restructuring Weil ein Vergleich der Metriken daher kaum Sinn macht wird an dieser Stelle die Wiederverwendbarkeit der beiden Funktionskomponenten betrachtet Nach Ansicht der Autoren ist der Austausch der Funktionskomponenten untereinander einfach m glich Der Einsatz von TAngleCtl in der neue Manuell
92. L FDlg_oncommandc HAND int HAMDO UIN Trwotgdt Dlg_ontommandg HANDO int HADO LINT void TMotor ffsetbDig TPsd ffsetDlg MotorofsetDlgi JNT const TManJustage ThotorofsetDlgilJNT const TMhandustage ZalcvaluelBOOL BOOL ZalvaluelBO OLO BOOL Choose ngleModec Hogy woid Is ngleMode BOOL Ableitung und Spezialisierung von Attributen Uberschreiben von Methoden der Basisklasse n weitere Methoden l U Abb 11 24 UML Klassendiagramm f r die Dialogfensterklassen TMotorOffsetDlg und TPsdOffsetDlg gegliedert nach der Erstellungsreihenfolge ihrer Elemente 11 3 3 Anbindung der Nutzeroberfl che an die Funktionskomponente In den folgenden Kapiteln soll es darum gehen welche M glichkeiten es gibt Nutzerober fl che und Funktionskomponente miteinander zu verkn pfen Diskutiert wird welche Verfahren f r den Daten und Informationsaustausch existieren so dass die nderung des Zustands in einer Komponente automatisch n allen anderen beteiligten Komponenten nachvollzogen wird 11 3 3 1 Ausgangspunkt ADV Modell Die Dekomposition kann nicht nur als Hilfsmittel bei der Softwareentwicklung dienen sondern auch grundlegender Mechanismus eines Entwicklungsmodells sein Ein solches ist das Abstract Design View ADV Modell Dieses informale Modell f r objektorientierte Softwaresysteme beschreibt die Struktur eines Softwaresystems auf der Designebene Es wurde urspr nglich zur Kapselung der Nutzeroberfl che bei in
93. LAUFSTEUERUNG M4 T Kullmann G Reinecker Reverse Engineering des Subsystems Ablaufsteuerung Version 1 9 M5 U Sacklowski Ablaufsteuerung Fehler erstellt 15 09 2002 M6 T Kullmann G Reinecker Reengineering des Subsystems Ablaufsteuerung Version 1 1 SUBSYSTEM BENUTZOBERFL CHE M7 T Kullmann G Reinecker Reverse Engineering der Basisklassen f r die Benutzeroberfl che Version 1 2 M8 U Sacklowski Benutzeroberfl che Fehler erstellt 06 03 2002 M9 T Kullmann G Reinecker Reengineering der Basisklassen f r die Benutzeroberfl che Version 1 0 M10 T Kullmann G Reinecker Layoutkonventionen und Steuerelemente Version 1 0 SUBSYSTEM DETEKTORNUTZUNG M11 U Sacklowski Detektornutzung Fehler erstellt 19 06 2000 M12 J Picard R Harder A Paschold Reverse Engineering des Subsystems Detektoren des RTK Steuerprogramms November 2000 SUBSYSTEM MANUELLE JUSTAGE M13 K Bothe Verhaltensspezifikation RTK Steuerprogramm Version 1 1 M14 K Bothe Verhaltensspezifikation Pflichtenheft KCTL Steuerprogramm Version 2 2 M15 T Kollmann G Reinecker Pflichtenheft neue Manuelle Justage Version 2 1 M16 T Kullmann G Reinecker Bewertung der Neuentw rfe des Oberfl chenfensters zur Manuelle Justage Version 1 7 M17 T Kullmann G Reinecker XCTL Steuerprogramm Benutzer Leitfaden der Basisanwendung neue Manuelle Justage Versio
94. Leitfaden gibt es dazu ein Kapitel englischsprachige Nutzeroberfl che in dem die englischen Dialogfenster ebenfalls in einer ausklappbaren bersicht dargestellt sind Zus tzlich sind f r jedes abgebildete Steuerelement die deutschen und englischen Beschriftungen in einer Tabelle gegen bersgestellt Abschlie end folgen Literatur und Stichwortverzeichnis und eine Liste der enthaltenen Tabellen und Abbildungen Wie beim Hilfe System wurde die Erstellung des Benutzerleitfadens durch die klare Strukturierung des Pflichtenheftes besonders des Kapitels Benutzeroberfl che wesentlich erleichtert Vor allem die Konsistenz zum Pflichtenheft und damit zum Programm ist sehr hoch weil Bedingungen Hinweise f r jede der Produktfunktionen und jedes Steuerelement explizit formuliert sind Auch ihre Beziehungen untereinander lie en sich gut aus dem Pflichtenheft extrahieren so dass die Erstellung der Abl ufe im Trainingsteil problemlos und einfach m glich war Seite 38 Dekomposition beim Forward Engineering Il 2 Definitionsphase 11 2 5 Objektorientierte Analyse Die objektorientierten Grundkonzepte bilden zusammen mit den Beziehungstypen die objektorientierte Analyse siehe 2 S 251f welche die fachliche L sung eines zu realis erenden Systems repr sentiert Da diese Phase die Software Architektur noch nicht ber cksichtigt besch ftigt sie sich im Sinne der Dekomposition nur mit der Modellierung der Funktionskomponente Sp testen
95. Manuellen Justage gef hrt siehe IIL 2 2 1 Dekomposition beim Reengineering Ill 2 Restructuring Seite 123 Die urspr ngliche Nutzeroberfl che verwendete zur Aktualisierung w hrend eines Messvorganges Windows API Operationen Da diese jedoch ber ein Fenster Handle kommunizieren wurde eine robuste und portablere ohne Fenster Handle Timer Komponenten verwendet Sie wird durch die Klasse TInterfaceTimer verwaltet Zur Behandlung der Timerereignisse muss die Dialogklasse TTopographyExecDlg das Interface ITimer einerben und die virtuelle Methode OnTimer TBasicTimer const berschreiben Der Parameter dient zur Identifizierung des zum Ereignis zugeh rigen Timers da f r eine Messung zwei Timer gleichzeitig ben tigt werden Die in der Funktionskomponente vorhandenen friend Relationen wurden entfernt und die Oberfl chenklassen erhielten je ein privates Attribut TTopography m_1nkTopography f r die Delegation an die Funktionskomponente Von der urspr nglichen Funktionskomponente TTopographyOld d rfte es m gesamten XCtl Programm nur maximal eine Instanz geben Deshalb erfolgte eine globale Instanziierung nicht beim Aufruf eines Dialogs sondern einmal beim Start des XCtl Programmes Es gab aber keinen Mechanismus der die Erzeugung weiterer Instanzen verhinderte Um die einmalige Instanziierung in der getrennten Topographie sicherzustellen wurde ein Singleton Muster f r die Klasse TTopography integriert Elass Trop
96. Methodenaufruf zur ckgegeben siehe Abb 1 7 Schichten Architektur am Beispiel der getrennten Topographie Unter Anwendung dieser Richtlinien wird durch Dekomposition neben der Modulzerlegung auch die hierarchische Architektur in Softwareprojekte eingef hrt oder weiter verfeinert Es Einf hrung 1 4 Motivation Seite 11 entsteht eine Schichtenstruktur in der jede Komponente eindeutig einer Schicht zugeordnet werden kann Die Dekomposition wurde exemplarisch an drei Subsystemen durchgef hrt Dabei wurde das bereits im XCtl Programm vorhandenen Schichtenmodell um die Schicht der Funktionskomponente erweitert Diese Struktur zeigt Abb 1 7 Aufgrund der Erfahrungen am Fallbeispiel XCtl erfolgt nun eine verallgemeinerte Auswertung und Bewertung anhand der inneren und u eren Qualit tsmerkmale Durch die konsequente Anwendung der oben geschilderten Richtlinien zur Dekomposition wird der Programmcode strukturierter Kleinere bersichtliche Fragmente machen den Code zudem erfass und lesbarer die bersichtlichkeit steigt siehe II 6 und III 3 Das f hrt im Allgemeinen auch zu einer Fehlerminimierung und sollte Portierungs und Wartungsarbeiten erleichtern Im Fallbeispiel ACHT zeigten sich deutliche Zeitvorteile w hrend der Produktpflese d h Suche und Korrektur von Fehlern Gleiches gilt auch f r die Erweiterbarkeit also Anpassung der Programmfunktionalit t an Spezifikations nderungen Fehlersuche oder nderu
97. Referenzen auf zwei Timer und eine Funktionskomponente In TTopographyAdjustDlg werden nur zwei Handle auf Kombinationsfelder und die neue Referenz auf die Funktionskomponente ben tigt Ein vorhandenes Flag nRestrictions f r den Aufrufstatus des Dialogfensters Topographie Einstellungen wurde durch den Wahrheitswert m_bCtr1lStatus ersetzt Nach dem Verschieben der funktionsspezifischen Attribute entstandenen f r deren Zugriff jeweils Get und Set Methoden in TTopography Da keine Bedingungen f r den Schreibzugriff vorhanden waren werden keine CanSet Methoden ben tigt die Get und Set Methoden wurden inline deklariert 6 Zusammenfassen von Funktionalit tsaufrufen Das Finden und Zusammenfassen der F Bl cke gestaltete sich unproblematisch da die funktionsspezifischen Anweisungen zum gro en Teil bereits zusammengefasst waren Nur zu Beginn oder am Ende einer Methode einer Oberfl chenklasse wurden oberfl chenspezifische Aktionen ausgef hrt Das Zusammenfassen der F Bl cke beschr nkte sich meist auf die vielen verstreuten Set Methoden die zur Parametrisierung der Messvorg nge ben tigten werden siehe Abb III 17 Dekomposition beim Reengineering Ill 2 Restructuring Seite 125 vorid TTopographyExecDlg Dlg OnGCotoWorkPornte void f OR Cerlserrext id Text _Golostartpoine Beschriftung ndern R SetAngleWidth GetMoveStep Motorschrittweite setzen E E CtrlSetEnabled cm_SwitchControl FALSE Star
98. Seite 70 Dekomposition beim Forward Engineering IA Implementierungsphase ist Direktbetrieb m glich BOOL TManJustage CanDoDirect const int alndex const EE TRUE lt gt g ltiger Antrieb nicht in Bewegung d h auch Halbwertsbreitenmessung ist inaktiv if IsMoving alndex bValid inclusive IsindexValid BVal d rerurn RATIOEN TMotorData MtrData amp m_MotorList alndex return MtrData gt m_MotionType mtDirect TRUE lt gt im Direktbetrieb Abb 11 40 Implementierung der Bedingung f r den Direktbetrieb Methode CanDoDirect gt BOOL MoveToAngle double PUBLIC bersetzt den Parameter Absolutposition in Nutzereinheiten in eine interne _Antriebsposition Methode Translate und f hrt diese an Methode MoveToPosition mlMoveToDistance und mMoveToDistance Abb 11 41 Auszug f r einen Methoden Eintrag aus dem Designdokument M28 des Subsystems Motorsteuerung Bewegung im Direktbetrieb BOOL TManJustage DoDirece const int alndex if CanDoDirect aIndex return FALSE Direktbetrieb kann nicht durchgef hrt werden TMotor Mtr m_MotorList aIndex m_inkMotor Motor aus Motorenliste ausw hlen BOOL bValid FALSE Mtr gt SetSpeed GetSpeed alndex bValid akt Geschw setzen Mtr gt ActivateDrive Antrieb aktivieren anfahren der Sollposition durch Funktion des Subsystems Motorsteuerung if bValid Geschwindigkeit konnte nicht
99. TR int Gethiotoridsi Txis Typeint alc OfsetFromAngle int TAngle Er TAngIe CalcAngleF romofsettint TAngle kr TAnglIe ZalcChannel fsetl TZhannel amp TAngle CaleChannelAnglecTChannel amp TAngle Abb ll 22 UML Klassendiagramm f r die Funktionskomponente der neuen Manuelle Justage gegliedert nach der Bearbeitungsreihenfolge ihrer Elemente Seite 48 Dekomposition beim Forward Engineering Il 3 Designphase 11 3 2 Ableitung der Oberfl chenfenster aus dem Pflichtenheft In einem objektorientierten Design wird jede Nutzeroberfl che ob Fenster oder Dialog durch eine separate GUI Klasse realisiert Die Anzahl und deren Typ kann aus dem Human Interface Prototypen bernommen werden Daraus ergeben sich auch die zu verwendenden Fensterbasisklassen welche wiederum die Vererbungshierarchie festlegen Bis auf das berschreiben von Methoden der Basisklassen gibt es hier keine allgemeinen Vorgaben f r Methoden Einige Datenteil Eintr ge aus dem Pflichtenheft betreffen die Nutzeroberfl che Daraus lassen sich wie bei 11 2 5 a und II 3 1 a Attribute ableiten und spezialisieren Methoden f r den Zugriff auf die Attribute sind nicht erforderlich weil die Nutzeroberfl che nicht durch andere Systeme benutzt wird Empfehlenswert ist die Erstellung separater Ereignisbehandlungsroutinen f r Steuerelemente als Methoden Diese werden bereits von vielen Entwicklungsumgebungen automatisch m der Implementierungsphase erzeugt Sinnvoll ist a
100. Type Wiederherstellen aller zuletzt benutzten GetAngleDest SetAngleDest CanSetAngleDest Antriebsparameter GetoOffset SetOffset Offset f r Antrieb CalcOffsetFromAngle CalcAngleFromOffset GetDetector GetDetectorName HasDetectorAxis GetChannel SetChannel ResetChannelOffset GetAnglePerChannel GetDetectorAxislIdx CalcChannelOffset CalcChannelAngle Offset f r Detektor zus tzliche Informationen wie Fortschritt GetMeasureProgress ParsingAxis 5 S der Messung in der Nutzeroberfl che GetKzMoving SetKzMoving GetKzMeasuring SetKzMeasuring Beginlpdate EndUpdate Geschwindigkeitsoptimierungen DetermineMoving DetermineAngle Tab 111 6 Zus tzlich geforderte Funktionalit t f r TManJustage 30 Methoden realisierte Funktionalit t TAngleCt1 kein entsprechendes Pendant in TManJustage Initialisierung beim Aufruf des Dialogfensters DoIinit i f in TManJustage im Konstruktor beinhaltet DoInitMotor muss vor dem Starten der Antriebsbewegung aufgerufen werden Setlorreetichstate in TManJustage In DoDirect DoStep DoDrive beinhaltet Moves MeasureStopped private Hilfsmethoden TAnglect1 intern Tab 111 7 Durch die Dekomposition entstandene Methoden von TAnglectl die beim Einsatz zu beachten sind 5 Methoden Dekomposition beim Reengineering Ill 2 Restructuring Seite 133 E22 1 Bewerlung yon user ver VLusier unge olinz u Snwendungsiall Im Gegensatz zur neuen Manuellen Justage wurden Polli
101. Untersuchung von Kristallstrukturen an Halbleitern Z Ce wesen zum Beispiel St KEES zum Teil Kapitel Einf hrung Kapitel I I 1 Zusammenfassung Die vorliegende Diplomarbeit entstand im Rahmen des Projektseminars Software Sanierung am Lehrstuhl f r Softwaretechnik und Theorie der Programmierung des Institutes f r Informatik der Humboldt Universit t zu Berlin Dieses Projekt wurde im Wintersemester 1998 99 ins Leben gerufen und steht unter der Leitung von Prof Dr Klaus Bothe Gegenstand der Veranstaltung ist die Sanierung und Erweiterung eines Programmes mit der Bezeichnung ACHT das im Fachbereich R ntgenbeugung an d nnen Schichten am Physikalischen Institut der Humboldt Universit t entwickelt wurde um die dortigen Messger te zur Halbleiter Strukturanalyse zu steuern und die Ergebnisse graphisch aufzubereiten W hrend der mehrj hrigen Arbeit an diesem Softwareprojekt haben sich dabei zwei Hauptaufgaben herausgebildet Der erste Schwerpunkt ist das Reengineering einzelner Programmelemente Dies umfasst das Reverse Engineering Restructuring und Refactoring Der zweite Punkt ist die Entwicklung neuer Programmfunktionen im Forward Engineering mit der Dokumentation der Softwareentwicklungsphasen sowie die Erstellung von Benutzerleitf den und Online Hilfen Dazu werden einzelne Teile dieses Softwareprojektes von ein bis zwei Studenten eigenst ndig unter bestimmten Gesichtspunkten bearbeitet Alle diese Arbeiten en
102. Zugriffs in der Funktionskomponente TManJustage sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssee 71 11 46 UML Klassendiagramm f r die Funktionskomponente der neuen Manuelle Justage am Ende der Implementierungsphase 00s0sssss0000ceuuuuo000e 72 11 47 Stark vereinfachtes Konzept zur Geschwindigkeitsoptimierung 2220000000000000000000000 73 11 48 Nutzung von Methoden zur Verwaltung der Teilbereiche 00s00000000000000000 75 11 49 Realisierung der oberfl chenspezifischen Funktionen B 40 und B 50 0000000 76 11 50 Auszug aus dem Kapitel Benutzeroberfl che des Pflichtenheftes M16 der neuen Manuelen Justase anni ee 76 11 51 Seit dem OOD unver ndert das UML Klassendiagramm f r die Dialog fensterklassen TMotorOffsetDlg und TPsdOffsetDlg Implementierungsphase 78 11 52 Seit dem OOD leicht ver ndert das UML Klassendiagramm f r die Dialogfensterklasse TManJustageDlg Implementierungsphase ssssssessesssssssssssseee 79 11 53 Auszug aus dem Dateiteil des Pflichtenheftes M16 0000000000000000000000000000000000 54 11 54 Auszug aus dem Funktionsteil des Pflichtenheftes M16 0000000000000000000000 85 11 55 ffentliche Schnittstelle von TManJustage zerlegt nach der Komplexit t ihrer Methoden u 0820 seien 86 11 56 Dialog Manuelle Justage Funk Test f r TManJustageTestDIg sscsssssesees
103. arallel entstanden Zur Auswertung siehe II 2 2 1 Dekomposition beim Reengineering Ill 2 Restructuring Seite 121 T nglecti TModalDlg I rmer m_SensorToDetector m_Motorcount JINT m_Move Speed float m_IsMeasuring BOL TAnglect TAnglect DolnitBO OL Dolnitotor BO OL DoSselectMotor BQL DoDirect Bo L Dostep BO0OL Dobrwe BooL Dostop BO0OL DoSstopEvenfhing void rlelndexvaigd BOOL rHae Cteet HOOL rleh oding DOOL scalbrated BOOL G5el ngleidouble 5el AngleMin double Gel AngleMaxdouble Gelspeed doukle 0 4 5el AngleWidthidouble GetDigits WINT In Inge Getlnit LAFESTA rG ptdotorl dr Int GelotorName LFESTR GetMotorcount int 5el ctualMotorint 5SetSpeediBooL 5et ngleidth BOL 5etCorrectionstate BaL 5etRelatiwvezero DOOL FesetFelativezero HOOL DostanMeasureBooL DoStopMeasure BOOL isMeasuring BOL isMeasureReset OOL GelMeasureHwb double WMeasureStopped BOL pdateDetectorwoid C anDOobDirectBO0OL anDosStep HOL CanDoDrive BOOL CanDosStop ROL C angetspeed BOOL Canget ngleidth DHOOL gt ansel ffsetBooL ank esetkelatiwreero BOOL 2 anDoStartMeasure HOOL 2 anDoStopMeasureBooL Moves BODL Abb 111 14 UML Klassendiagramm der getrennten Manuellen Justage Polling Variante Seite 122 Dekomposition beim Reengineering Ill 2 Restructuring Anwendungsfall Topographie Die Bearbeitung des Subsystems Topographie erfolgte wie beim Anwendung
104. ard Engineering IA Implementierungsphase vord TManJustageDlg TB cr co k const ETIB 7B BOOM bval d Aufruf w hrend der Halbwertsbreitenmessung ignorieren f m_1nkManJustage gt IsMeasuring return int mSel TB2Selection aTB den in diesem Teilbereich ausgew hlten Antrieb ermitteln nicht in Bewegung und nicht kein Antrieb ausgew hlt Bewegung starten i El Eeer s amp DYalid wenn Bewegung gestartet wurde Timer f r die Bildschirmaktualisierung wird gestartet Polling ift m_1nkManJustage gt DoDirect mSel m lnkTimer StartTimerIm else OnNoAction A Bewegung kann nicht gestartet werden Fehlermeldung ausgeben wenn Bewegung gestoppt wurde Timer f r die Bildschirmaktualisierung wird direkt gerufen else if m_lnkManJustage gt DoStop mSel m_1nkTimer gt Immediately else OnNoAction A Bewegung kann nicht gestoppt werden Fehlermeldung ausgeben Abb 11 49 Realisierung der oberfl chenspezifischen Funktionen B 40 und B 50 Abbildung 17 Starten der Bewegung im Direktbetrieb Quelle 4 B 40 Starten der Bewegung im Direktbetrieb Die Bewegung kann mit der Schaltfl che Gart gestartet werden F 70 Starten der Bewegung im Direktbetrieb Es soll nicht m glich sein den Antrieb zu starten indem man ENTER dr ckt W hrend der Bewegung werden alle antriebsspezifischen Steuerelemente mit Ausnahme von Antrieb ausw hlen gesperrt u
105. assung von mehreren Testdaten zu einer Klasse wenn laut Spezifikation keine funktionalen Unterschiede bestehen e Bei beliebigen Beschriftungsm sglichkeiten f r ein Steuerelement 1 d R Eingabefelder m ssten f r die Testdaten immer zwei quivalenzklassen z B g ltige ung ltige Eingaben oder korrekte inkorrekte Ausgaben definiert werden Die Auswertung von Eingaben sollte jedoch nicht in der Nutzeroberfl che erfolgen sondern in der Funktionskomponente Diese pr ft selbst ob es sich um g ltige Eingaben handelt d h im gew nschten Wertebereich bzw die L nge von Zeichenketten F r die Behandlung ung ltiger Zeichen in einer Eingabe z B bei Zahlen sollte die Basisklasse der Nutzeroberfl che Methoden bereits stellen Damit entf llt die Auswertung dieser Steuerelemente fast komplett 2 Systemzust nde e Zur Erleichterung der Testaktivit ten k nnen Systemzust nde mit n die Testdaten aufgenommen werden S e dienen dem Tester nur zur schnelleren Erfassung des aktuellen Dekomposition beim Forward Engineering Il 5 Testphase Seite 91 Programmzustands Weil im Hauptdialog der neuen Manuellen Justage z B viele Steuerelemente vom Antriebsstatus abh ngen kennzeichnet Abb 11 58 C__ gt ob sich der Antrieb im aktuellen Zustand bewegen darf Manchmal stehen diese Zustandsinformationen auch stellvertretend f r die Beschriftung eines Steuerelementes Bei M23 steht Halbwertsbreite gt wird gemessen bs
106. asureStopped const ing BOOL Cansetspeediconstint BOOL CanSetAngleidthiconst int BOL rang feet Congt int HOOL ank esetFelatiweerotconstint BOOL CanDoDirecticonst ing BOOL C anDoStepeconstint BOOL const BAOL 2 anDoDrverconst int BOL const BOOL Attribute CanDoStopiconstint BOOL Auslesen von Zust nden der CanDosStatMeasured BOOL benutzten Subsysteme CanDoStopMeasurew BOOL Zugriff auf Attribute und Steuerung der benutzten Subsysteme Can M f r zuvor genannte Methoden weitere Methoden HIRT Abb 111 11 UML Klassendiagramm von TAnglect1 Funktionskomponente nach der Dekomposition Zum Auslesen der benutzten Subsysteme wurden 12 Get 5 Is 1 Has und eine brige Methode erstellt siehe Abb IIL 11 Cs die deren Zustand nicht ndern Seite 118 Dekomposition beim Reengineering Ill 2 Restructuring 8 Erzeugung von CanDo Methoden optional Da die Ausf hrung der og zustandsver ndernden Methoden z T von Bedingungen abh ngig ist wurden daf r Can Methoden siehe Abb IIL11 m abgeleitet Davon werden jedoch nur CanDoStartMeasure und CanResetRelativeZero direkt in der Nutzeroberfl che verwendet Weil sich die existierende Nutzeroberfl che sonst nicht an Zustands nderungen anpasst ist die Verwendung der CanDo in den Do bzw der CanSet in den Set Methoden der Funktionskomponente besonders wichtig Ansonsten k nnte die Nutzeroberfl che Methoden aufrufen ohne die Aufrufbedingungen ausgewertet zu haben Im
107. b II 9 Konstruiertes Beispiel f r die Auslagerung einer CanDo Methode essossssssseseeeeeeoo 112 Abb IIL 10 UML Klassendiagramm von TAngleCt1Dlg Nutzeroberfl che nach der Dekomposition mit Zuordnung der ausgelagerten Methoden sssssssssssseccceeeo 116 Abb IIL 11 UML Klassendiagramm von TAngleCt1 Funktionskomponente nach der Dekompos llon unse en een ee 117 Abb IIL 12 Beispiel zur Auslagerung einer CanDo Methode csssssssssss0sssssssssnnunsunnssssssssssssese 118 Abb 111 13 Beispiel zur Gewinnung zus tzlicher Bedingungen f r CanDo Methoden 119 Abb 111 14 UML Klassendiagramm der getrennten Manuellen Justage Polling Variante 121 Abb 111 15 UML Klassendiagramm der Funktionskomponente TTopographyOld s 122 Abb UL to Implementierung des Singleton Musters f r die Klasse TTopography 123 Abb IIL 17 Zusammenfassen einer Set Methode mit einem gro en F Block ccce0sssssss000000 125 Abb 111 18 Durch Dekomposition entstandene Do Methoden mit langen Parameterlisten 125 Abb ULI Erweiterung einer Set Methode durch zus tzliche Bedingungen ccccss 00000 126 Abb II1 20 Zusammenfassen gleichgesinnter Do Methoden durch zus tzlichen Parameter 127 Abb IIL 21 UML Klassendiagramm der getrennten Topographie 0000000000uuoosssssssss00ee 129 Abb 111 22 UML Klassendiagramm f r die getrennte Manuellen Justage Observer Must
108. beim Austausch der Nutzeroberfl che oder bei Wartungs und Portierungsarbeiten Seite 138 Dekomposition beim Reengineering Ill 3 Fazit und Ausblick Kapitel IV Gesamtfazit Kapitel IV GESAMTFAZIT Da im Forward Engineering nur ein Anwendungsfall und im Reengineering nur zwei Anwendungsf lle ein und desselben Projektes betrachtet werden konnten besteht nur eine beschr nkte Aussagef higkeit der vorgestellten Erkenntnisse Die Verwendung nur einer Programmiersprache l sst zun chst eine zus tzliche Beschr nkung vermuten Da es sich dabei aber um C handelt kann diese Sprache dennoch als repr sentativ f r alle objektorientierten Programmiersprachen angesehen werden Die bertragbarkeit wird gesichert weil nur Elemente der Schnittmenge von Sprachelementen aller objektorientierten Programmiersprachen verwendet werden Sowohl beim Forward als auch beim Reengineering liegt der Schwerpunkt der Dekomposition auf der Wahl eines Musters f r die Kommunikation zwischen Funktionskomponente und Nutzeroberfl che Diese wird durch die in I1 3 3 5 vorgestellten Richtlinien eindeutig vorgeschrieben Bei gleichen Spezifikationen entsteht unabh ngig von Forward oder Reengineering das gleiche Design Auch bei der Strukturierung der ffentlichen Schnittstelle der Funktionskomponente zeigt s ch derselbe Effekt Unter Verwendung der unter 11 2 5 und 11 3 1 Forward bzw III 2 1 Reengineering vorgestellten Richtlinien entsteht das gle
109. bersicht M2 e Design Implementierungsphase e Testphase o Regressions Testf lle Manuelle Justage M18 e Fehler bersicht Tab 11 1 bersicht zur urspr nglichen Manuellen Justage Im Hinblick auf eine prognostizierte Entwicklungszeit von fast einem Jahr wurde keine vollst ndige Ist Analyse durchgef hrt Die vorhandenen Dokumente und der Programmcode wurden immer wieder im Verlauf des Softwareentwicklungsprozesses ausgewertet An den entsprechenden Stellen von Kapitel II wird darauf verwiesen Zur Einarbeitung in den Gegenstandsbereich war bereits die aus dem o g Review resultierende berarbeitete Version der Verhaltensspezifikation M14 verf gbar Bei der intensiven Besch ftigung mit dem existierenden Dialogfenster konnten die Basisanforderungen sowohl Funktionen und Daten vollst ndig und ohne Kontakt zum Auftraggeber abgeleitet werden Da Entwicklungs und Einsatzumgebung bereits vorgegeben und die Bas sanforderungen berschaubar waren wurde auf die Erstellung von Lastenheft Aufwandsabsch tzung und Projektplan f r die neue Manuelle Justage verzichtet Seite 20 Dekomposition beim Forward Engineering Il 1 Analysephase Die Basisanforderungen wurden vielmehr stichpunktartig in die bei Il 2 1 vorgestellte Gliederungsstruktur des Pflichtenheftes eingeordnet Die zu realisierenden Funktionen wurden im Kapitel Funktionale Beschreibung und die anzuzeigenden und zu verwaltenden Datenelemente unte
110. bindung der Nutzeroberfl che das OOD Modell Bei der Dekomposition spielt der Verbindung zwischen Nutzeroberfl che und Funktionskomponente eine wichtige Rolle Dazu werden zwei Kommunikationsmuster das Observer Muster 11 3 3 3 und die Polling Variante II 3 3 4 parallel vorgestellt Es erfolgt zudem eine allgemeine Bewertung In Kapitel II 3 5 1 wird abschlie end auf die Erfahrungen bei der Umsetzung von Observer Muster und Polling Variante eingegangen 11 3 1 Verfeinerung der Funktionskomponente Die in H 2 5 definierte Funktionskomponente muss nun weiter verfeinert werden z B nach 2 S 992 Dies beinhaltet u a den Zugriffsschutz von Attributen und Methoden und deren Pr zisierung e Wenn die Programmiersprache dies erm glicht sollten nicht zustandsver ndernde Methoden d h der Objektzustand bleibt unver ndert gekennzeichnet werden In C const member functions siehe 16 e Alle entstehenden Parameter sollten wenn m glich als konstant gekennzeichnet werden um ihre Unver nderbarkeit sicherzustellen In C durch type specifier const f r Parameter siehe 16 e Zus tzlich zu den im OOA Modell definierten Pr fixen sollten nicht zustandsver ndernde Methoden die durch die Festlegung der Signatur ausschlie lich einen Wahrheitswert zur ckgeben mit den Pr fixen Is oder Has gekennzeichnet werden Je nachdem was dem englischen Sprachgebrauch entspricht z B IsMoving aber HasPermition e Da die Ausf hrung d
111. ble L sung gibt unterst tzen die Basisklassen im Hinblick auf die Portierung Tastenkombinationen sobald das Projekt mit einem Win32 Compiler gelinkt wird pr prozessorgesteuert So sind diese in der neuen Win32 Version der Manuellen Justage automatisch verf gbar Zum neuen Zustand des Subsystems Benutzeroberfl che entstand das Designdokument M9 Da f r die neue Manuelle Justage nur modale Dialogfenster zu erstellen waren erfolgte die Ableitung von TModalDlg Diese Klasse definiert einen Pool von Behandlungsroutinen f r grundlegende Ereignisse die in den Ableitungen berschrieben und spezialisiert werden k nnen Um die Nutzeroberfl che deutlich von der Funktionskomponente zu trennen wurden die Dialogfensterklassen mit dem Suffix D1g gekennzeichnet So entstanden die Klassenbezeichner TManJustageDlg f r Abb HI oben TMotorOffsetDlg Abb 11 10 rechts und TPsdOffsetDlg Abb I 10 links Dieses Vorgehen wurde sogar auf das gesamte XCtl Projekt angewandt Dabei wurde zus tzlich das Suffix Wnd eingef hrt um alle Fenster die keine Dialoge darstellen zu kennzeichnen Dekomposition beim Forward Engineering 11 3 Designphase Seite 49 Den Kernpunkt einer Dialogfensterklasse im XCtl Projekt bildet die Methode void Dlg_OnCommand HWND int HWND UINT Dort k nnen alle Steuerelementbotschaften empfangen identifiziert behandelt oder weitergeleitet werden Durch die Komplexit t der Benutzeroberfl
112. blieben Nur in TManJustageD1lg wurden drei neue Methoden f r die Geschwindigkeitsoptimierungen ben tigt In welche Kategorie diese eingeordnet werden m ssen ist in Abb II 52 gekennzeichnet NEU Die neuen Methoden befinden sich jeweils am Ende der hervorgehobenen Klassierung Die Kennzeichnung nicht zustandsver ndernder Methoden gestaltete sich in der Oberfl chenimplementierung etwas umst ndlicher als bei der Funktionskomponente Verallgemeinert werden kann nur dass die Signatur von den Methoden der Basisklasse n nicht ver nderlich ist Die nachtr gliche Kennzeichnung als const member function oder von const Parametern ist nicht m glich Ereignisse von Bedienelementen und Methoden zur Aktualisierung der Oberfl che stellen stets zustandsver ndernde Methoden dar Die zahlreiche Verwendung von const Parametern ist hnlich wie in der Funktionskomponente m glich siehe Abb 11 52 Dekomposition beim Forward Engineering IA Implementierungsphase Seite 79 Slip OmintCHWWVND HMD LPARAM BOOL FDlg_OnCommandcHW ND mt HMD LIN T void Dlg_onHScrollBarcH O HAD LINT ing void LeaveDialog oid OnTimercconst TBasicTimer void OnEventt HANE JINT AW FARAM LPARAM DOT m_InkMandJustage TMandustage m_InkTimer TintetaceTimer m_Selection IMT mm Parallel BOOL m_StaterRefresh BOOL m_DisplayNMoActonMsco BooL TManJustageDig TIR Gouf INT TB_ Nest ETE EBOL B_GetlidETB consti LINT B_GetNametETB const LPSTRY oid GeirRes
113. bten Beobachters IManJustage zu implementiert So k nnen bei Zustands nderungen in der Funktionskomponente Anpassungen in der Oberfl che durchgef hrt werden um die Konsistenz der Zust nde von Funktionskomponente und Nutzeroberfl che zu wahren Die Initiative f r den Datenaustausch nach einem Zustands bergang liegt bei der Funktionskomponente Kann ein solcher bergang von au erhalb ausgel st werden z B durch ein anderes Subsystem oder eine Hardware und wird die Funktionskomponente dar ber nicht automatisch informiert st eine Timer Komponente zur Generierung von regelm igen Ereignissen n tig Bei deren Eintreten kann der Zustand des ausgelagerten Prozesses ausgelesen werden Die Verwendung eines Timers f r die neue Manuelle Justage resultiert aus der engen Hardwarekopplung ber das Motorsteuerung Subsystem und ber die Halbwertsbreitenmessung des Subsystems Ablaufsteuerung Da im gesamten XCtl Projekt Timerereignisse nur ber Fenster Handle realisiert waren mussten von den Autoren zuvor entsprechende Klassen f r fensterunabh ngige Timer implementiert werden In Hinblick auf die Win32 Portierung entstanden dabei die Klassen TTimer16 und TTimer32 Je nach Plattform bildet die entsprechende Klasse die Basis f r TInterfaceTimer Observer Muster und TwindowTimer fenster handle orientiert Die neue Manuellen Justage verwendet die Klasse TInterfaceTimer als Konkretes Subjekt TManJustage ist hier Konkreter Beoba
114. ch weil OOA und Oberfl chen Prototyping weitgehend unabh ngig voneinander sind Bei der Abstimmung des Pflichtenheftes k nnen Inkonsistenzen Redundanzen und Fehler fr hzeitig in der Spezifikation aufgedeckt und Missverst ndnisse zwischen den Parteien gekl rt werden Dabei m ssen nach dem linken Handlungsstrang nur Pflichtenheft und Oberfl chenentwurf angepasst werden nicht das OOA Modell Abb II 20 vgl dazu Beziehungen zwischen Pflichtenheft Oberfl chen und OOA zwischen der rechten und linken Seite Beginn der Entwicklung ggf Istanalyse und oder Lastenheft Pflichtenheft Pflichtenheft erstellen warten erstellen warten Erg nzung um den favorisierten OOA Oberfl chenentwurf erstellen Oberfl chen entwerfen bearbeiten OOA erstellen Oberfl chen erstellen bearbeiten i Benutzerdok erstellen Erstellungsreihenfolge Benutzerdok erstellen b d i Entwicklungsprozess fortsetzen OOD Implementierung Test Schwerpunkt ist Nutzeroberfl che Kombination m glich Schwerpunkt ist Produktfunktion entwicklerseitige Entscheidung nach erfolgreicher Abstimmung des Quellartefakts mit Auftraggeber Anwender 14 00 wie gt jedoch mit zus tzlichen Informationen f r das Zielartefakt wie gt aber erst nach Fertigstellung des Pflichtenheftes D Bearbeitung des jeweiligen Artefaktes entwickler oder auftraggeberseitig Abb 11 20 Gegen berstellung der von de
115. che gerufen werden m sste Diese Vorgehensweise ist zudem nicht erforderlich weil nur TAngleCt1Dlg auf die Funktionskomponente zugreift Die im urspr nglichen Subsystem eingesetzten Windows API Methoden die zur Verwaltung der Timer Komponente und zur Bildschirmaktualisierung benutzt wurden konnten durch die Klasse TInterfaceTimer ersetzt werden Dadurch wurde die Verwaltung wesentlich komfortabler portabler und fehlerresistenter siehe auch Anwendungsfall Topographie 3 In der Polling Variante muss sich die Oberfl che um die Aktualisierung der Nutzeroberfl che k mmern weil hier die Beziehung zu der Timer Komponente besteht siehe Klassendiagramm in Tab II3 Im Design des Observer Musters liegt die Initiative bei der Funktionskomponente welche die Oberfl che ber Zustands nderungen informiert Deshalb bedient sich hier die Funktionskomponente der Timer Komponente vgl Abb IIL 22 4 Programmcodelayout verbessern optional Zur Verbesserung der Lesbarkeit wurde der Programmcode formatiert kommentiert und potentielle Fehlerquellen markiert Letzteres betraf fast alle Attribute Ein Teil von ihnen wurde nicht im Konstruktor nitialisiert ein anderer zwar geschrieben aber nur einmal und nicht als const gekennzeichnet Anstatt den aktuellen Systemzustand aus der Nutzeroberfl che oder beim benutzten Subsystem direkt auszulesen wurden zwischengespeicherten Werte aus Attributen verwendet Damit war die Nutzeroberfl che selbst
116. cht verschiebbaren O Bl cken hier werden auch die untergeordneten bedingten Anweisungsfolgen untersucht y Die Verifizierung erfolgt durch Kompilieren Linken und einen abschlie enden EE 7 Erzeugen von Do Methoden Jeder F Block ist in eine neue ffentliche Do Methode Name ist aussagekr ftig zu w hlen der Funktionskomponente zu verschieben Der verschobene F Block ist in der Nutzeroberfl che durch einen Aufruf der entstandenen Do Methode zu ersetzen Je nach Typ werden die folgenden Signaturen notwendig Typ 1 Die Do Methode wird nicht fr hzeitig verlassen und hat keinen R ckgabewert vord TEArowS i EE Eet angle speed deklarieren und mit Eingaben aus Nutzeroberfl che initialisieren Sanduhr anzeigen MEy m_inkFunk gt SetStartAngle angle m_inkFunk gt SetStartSpeed speed Berechnungen f r schr gen Wurf AUSGANGSSITUATION void iheoy i mDIg ONG are inrowi angle speed deklarieren und mit Eingaben aus Nutzeroberfl che initialisieren Sanduhr anzeigen m_inkFunk gt DoStartThrow angle speed void TThrowSim DoStartThrow double angle double speed SetStartAngle angle m_inkFunk gt entf lt innerhalb der Funktionskomponente SetStartSpeed speed Berechnungen f r schr gen Wurf ausgelagert aus TThrowSimDlig OnStartThrow ERGEBNIS Abb 111 5 Konstruiertes Beispiel f r die Auslagerung eines F Block
117. chter und das Interface ITimer ist Beobachter Schnittstelle Die Funktionskomponente erstellt den Timer selbst und speichert dessen Referenz inm_1inkTimer um diesen zu steuern Dekomposition beim Forward Engineering 11 3 Designphase Seite 55 Zustandsaktualisierungen mittels Observer Muster gt ug in a nn gn ON oton el EE DR N doud EL NIE e TF TN PS EI 1 m_InkManJustageblg ies m_InkTimer TinterfaceTimer m _InkblanJustageDig IManJust ge EN u TManJustageliManJustage GelAngle DoDirechl Dosiopd OnTimerd m_inkklandJustane Timer Ereignisausl sung ist nur mittels Observer Muster m glich Abb 11 26 UML Klassendiagramm f r Observer Muster in der neuen Manuellen Justage vereinfacht Um eine Bewegung zu starten wird in der Nutzeroberfl che z B die Methode m_1nkTManJustage gt DoDirect gerufen woraufhin sich der Antrieb in Bewegung setzt und der Timer gestartet wird Ist sein Intervall abgelaufen ruft der Timer die Methode OnTimer von TManJustage Damit nun die Nutzeroberfl che aktualisiert wird muss als Folge des Timer Ereignisses eine der Methode aus Tab II 4 an m_1nkTManJustage delegiert werden Das eigentliche Herstellen der Konsistenz erfolgt dann in der Nutzeroberfl che durch OnTB_Positions Auslesen der aktuellen Antriebsposition mittels m_1nkTManJustage gt GetAngle und OnTB_ControlsEnable sperren bzw freigegeben der Steue
118. ction coarse fine benutzt Einf hrung 1 3 Fallbeispiel das XCtl System Seite 7 Abb 1 4 Freiheitsgrade der Probe bei der Topographie Quelle nach M1 Jeder Antrieb kann separat und manuell gesteuert werden Dies erfolgt durch Eingabe verschiedener Parameter wie einer Zielposition einer Bewegungsrichtung oder der Bewegungsgeschwindigkeit So wird die Positionierung der Probe die Anpassung der Kollimator an die Probenkr mmung und die Ausrichtung des R ntgendetektors Diffraktometrie Reflektometrie erm glicht Die Manuelle Justage dient meist der Vorbereitung eines physikalischen Experiments z B der Topographie H ufig wird sie aber auch nur dazu benutzt sich einen berblick ber die aktuellen Antriebsparameter zu verschaffen oder die Halbwertsbreite zu messen Vollst ndige Funktionsbeschreibungen sind in M14 urspr ngliche Manuelle Justage bzw M15 neue Manuelle Justage aufgef hrt 1 3 3 Subsystem Topographie Das Ziel der Topographie ist die Darstellung der Kristallstruktur einer Messprobe von einem Halbleiterkristall siehe M29 Dazu wird in einer R ntgenr hre ein Strahlenb ndel erzeugt das durch einen Kollimatorkristall aufgef chert und parallelisiert wird siehe Abb I 1 Dieses R ntgenlicht trifft in einem bestimmten Winkel nahezu monochromatisch auf die Messprobe und wird reflektiert Zur Erfassung des Abbildes dient eine Fotoplatte ein Film oder ein 2D Detektor die
119. d Henachrichtigen oid Abb 11 30 Bsp f r hohe Komplexit t des Observer Musters bei 1 3 Durch die Verwendung von Polling k nnen Design und Programmcodeumfang bei diesen beiden Varianten problemlos reduziert werden weil die Beobachter Interfaces entfallen Abb II 30 TFunkt3 InkFunktz InkFunkta m m Abb 11 31 Bsp f r das einfache Design von Polling bei 1 3 Wenn mehrere Nutzeroberfl chen auf genau eine Funktionskomponente zugreifen m 1 muss durch das Design immer sichergestellt werden dass maximal eine Instanz der Funktionskomponente erstellt werden kann z B durch das bereits erw hnte Singleton Muster Da jede Nutzeroberfl che bei Zustands nderungen benachrichtigt werden muss kann nur die Verwendung des eigentlichen Observer Musters die horizontale Konsistenz zwischen den Nutzeroberfl chen gew hrleisten Abb 11 32 Wenn eine Nutzeroberfl che eine Zustands nderung in der Funktionskomponente ausl st und die Aktualisierung ber Dekomposition beim Forward Engineering 11 3 Designphase Seite 61 die Polling Variante realisiert wird m ssten entweder st ndig Timer Komponenten f r die Aktualisierung der Zust nde sorgen oder die Nutzeroberfl chen m ssten miteinander kommunizieren Da sich der Informationsaustausch zwischen den Nutzeroberfl chen aber nur auf das Anzeigen Verstecken der Fenster beschr nken sollte blieben allein die Timer Komponenten mit einer zu gro en Ressourcenverschwendung
120. de konnten jede einzelne M glichkeit der Benutzung nachgebildet werden siehe Abb III 20 Diese Art der Vereinfachung kann jedoch nur nach eingehender Analyse des Programmcodes durchgef hrt werden sie ist nicht verallgemeinerbar Parameter ndern Messung immer neu starten void TTopography DoSetDetecParams_Start float Time DWORD Count Detector gt MeasureStop Messung stoppen Detector gt SetExposureSettings TExposureSettings Time Counts Detector gt MeasureStart Messung fortsetzen Parameter ndern Messung nur starten wenn schon gemessen wurde void TTopography DoSetDetecParams_ReStart float Time DWORD Count es wird gerade gemessen if Detector gt IsActive 1 Detector gt MeasureStop Messung stoppen Detector gt SetExposureSettings TExposureSettings Time Counts Detector gt MeasureStart Messung fortsetzen else es wird NICHT gemessen Detector gt SetExposureSettings TExposureSettings Time Counts Parameter ndern Messung nie starten void TTopography DoSetDetecParams_NoStart float Time DWORD Count Detector gt SetExposureSettings TExposureSettings Time Counts AUSGANGSZUST AND Detektorparameter ndern void TTopography DoSetDetectorParanms float Time DWORD Count BOOL Start es wird gerade gemessen ie KmelnkDeteetor TsAetive TI Starte y 4 m_InkDetector gt MeasureStop Messung stoppen m_InkDetector gt SetEx
121. dem Forward Engineering z T zusammengetragen aus 4 In diesem Kapitel geht es daher um die Erl uterung einer allgemeinen Schrittfolge f r die Dekomposition von Funktionskomponente und Nutzeroberfl che eines objektorientierten Kapitel III Dekomposition beim Reengineering Subsystems beim Reengineering Der Schwerpunkt liegt dabei auf den nderungen am Programmcode Diese werden zum leichteren Verst ndnis am Beispiel der Programmiersprache C erkl rt die auch im XCtl Projekt eingesetzt wird Aufgrund der Allgemeing ltigkeit der verwendeten Sprachkonstrukte in der objektorientierten Welt und der weiten Verbreitung der Sprache sollte eine bertragung bspw auf Java keine Probleme bereiten Zudem werden einige als optional gekennzeichnete Punkte ausgewiesen die zur Dekomposition nicht zwingend erforderlich sind Sie dienen nur zur Verbesserung der Struktur Robustheit und Fehleranf lligkeit Diese Schrittfolge wurde aus der Dekomposition der Subsysteme Manuelle Justage und Topographie abgeleitet und verallgemeinert Zur Veranschaulichung wird die Bearbeitung der Altsysteme in Anwendungsf llen dargestellt Dazu werden m Folgenden die vorhandenen Entw rfe als urspr ngliche Manuelle Justage und urspr ngliche Topographie und die im Reengineering dekomponierten als getrennte Manuelle Justage und getrennte Topographie bezeichnet Dekomposition beim Reengineering Ill 1 Ist Analyse Seite 99
122. den Aufruf einer neuen On Methode ersetzt werden Der ersetzte Code ist dann in diese auszulagern Der Name der Methode sollte sich aus dem Ressourcen Bezeichner der Botschaft und dem Pr fix On zusammensetzen Alle ben tigten lokalen Variablen und Parameter sollten von der Behandlungsroutine per Referenz an die On Methode bergeben werden Bei reinem Lesezugriff kann die Referenz durch const ersetzt werden Wenn die Variable nur in dieser Methode benutzt wird k nnen Deklaration und Initialisierung dorthin verschoben werden Eine Ausnahme bildet das Fenster Handle das n cht an die On Methode weiterzugeben ist Stattdessen sollte eine Methode der Fensterbasisklasse verwendet werden die das Fenster Handle zur ckgibt ggf ist eine solche zu erstellen Erfolgt die Behandlung aller Botschaften in einer switch Abfrage ist in jedem ausgelagerten case Zweig das break durch return zu ersetzen v Die genannten Anpassungen k nnen durch Kompilieren und Linken verifiziert werden Ein erfolgreicher Regressionstest des zu dekomponierenden Subsystems und der benutzenden Systeme bildet den Abschluss dieses Schritts 5 Neuordnung der Attribute Um den Zustand des zu dekomponierenden Subsystems ausschlie lich n der Funktionskomponente zu verwalten m ssen alle Attr bute d e keine echten Eigenschaften der Oberfl che sind von der Nutzeroberfl che in die Funktionskomponente verschoben werden Die Initialisierung aller Attribute sowie die Erzeugung a
123. den Kommunikationsmuster wird hier verzichtet weil die Struktur seit der Designphase nahezu unver ndert geblieben ist F r die Geschwindigkeitsoptimierungen sind seitdem vier neue Attribute NOAr NEU 4 und vier neue Methoden NOO NEU 4 in der Funktionskomponente sowie zwei neue Methoden NOO NEU 2 f r die Nutzeroberfl che eingef gt worden Diese nderungen sind unabh ngig vom gew hlten Kommunikations Muster weil die Optimierungen in beiden Systemen identisch implementierbar waren Beim Vergleich des Implementierungsumfanges gibt es insgesamt einen kleinen Nachteil von 12 LOC f r das Observer Muster 1 750 zu 1 738 Polling Variante Dabei ist eine deutliche Umstrukturierung des Programmcodes zu erkennen Weil die Nutzeroberfl che bei der Polling Variante den Kommunikationsmechanismus initiiert ist diese deutlich umfangreicher als beim Observer Muster LOCo 1 103 zu 1054 Observer Muster Dementsprechend muss die Situation der Funktionskomponente komplement r sein Beim Observer Muster stehen LOCr 696 den 635 der Polling Variante gegen ber Ob die Umverteilung von etwa 50 LOC jedoch zu einer deutlich h heren Wiederverwendbarkeit der Observer Funktionskomponente Dekomposition beim Forward Engineering IA Implementierungsphase Seite 81 f hrt und das komplexere Design rechtfertigt ist bei diesem Anwendungsfall eher fraglich In anderen F llen k nnten die u eren Bedingungen jedoch den Einsatz der Polling Variante verhinder
124. denen Dokumente siehe Tab II 2 zur Topographie durchgef hrt Das Hauptdokument der Analysephase ist M29 Topographie Gesamtvorgang Hier werden die physikalischen Grundlagen und die theoretischen Abl ufe der einzelnen verf gbaren Topographie Messvorg nge zum Teil formal siert in einer Pseudocodenotation beschrieben Die Verhaltensspezifikationen M31 Einstellen der Parameter f r die Topographie und M32 Start und Kontrolle der Topographie erl utern die Durchf hrung der Messungen anhand der Nutzeroberfl chen siehe Abb III 2 rechts bzw links Zur Protokollierung einer Messung zeigt M33 Topographie Me protokoll_Buch die allgemeine Verfahrensweise F r die Designphase existiert das Dokument M29 Software Struktur Es beinhaltet die zum Subsystem geh rigen Dateien und ein Klassendiagramm zum Oberfl chendesign mit einer kurzen Erkl rung der Aufgaben der einzelnen Nutzeroberfl chen Da die Topographie auf die Subsysteme Detektorsteuerung Motorsteuerung und Ablaufsteuerung zur ckgreift wird die Nutzung dieser dort ebenfalls beschrieben Dazu werden ein Klassendiagramm des Subsystems Ablaufsteuerung zur automatischen Durchf hrung einer Messung und die Anbindung des Subsystems Motorsteuerung mittels einer nicht objektorientierten C Schnittstelle erl utert Das Subsystem Topographie besteht aus der Dialogklasse TTopographyExecuteDlg f r das modale
125. der abgestimmt Insgesamt werden so 15 vorhandene vier neue mit den Eigenschaften bereits vorhandener und zwei v llig neue Datenelemente beschrieben siehe Abb II 6 D10 Name des ausgew hlten Antriebs f r einen Teilbereich D20 PSD R ntgendetektor vorhanden D30 Antriebsliste D40 physikalische Einheit D50 Eigenschaften der Istposition D60 minimale Istposition D 70 maximale Istposition D80 Nachkommastellen D90 Offset D 100 Betriebsart D 110 eingegebene Sollposition D 120 eingegebene Bewegungsgeschwindigkeit D 130 minimale Bewegungsgeschwindigkeit D 140 maximale Bewegungsgeschwindigkeit D 150 eingegebene Schrittweite D 160 minimale Schrittweite D 170 maximale Schrittweite D 180 eingegebener PSD Kanal D 190 erster Kanal D 200 letzter Kanal D 210 Winkelwert Kanal Abb 11 6 Auszug aus dem Anhang des Pflichtenheftes M15 bersicht aller Datenelemente Hervorhebung schwarz die vorhandenen blau die abgeleiteten und rot die neuen Elemente Die Gliederung des Datenteils hnelt der von Kapitel funktionale Beschreibung vgl Abb II 3 und Abb II 7 Weil nicht jede Produktfunktion Daten verwaltet konnten im Kapitel Daten einige Gliederungspunkte entfallen Um das Nachschlagen der verwendeten Daten el
126. des Physikalischen Institutes bewerteten das entstandene Pflichtenheft trotzdem als zu abstrakt weil die Nutzeroberfl che getrennt von den eigentlichen Produktanforderungen beschrieben wurde Da die Oberfl chenentw rfe in der Praxis jedoch erst nach dem Pflichtenheft entstehen und nicht wie von den Autoren praktiziert nachgetragen werden w ren dort normalerweise gar keine Oberfl chenentw rfe enthalten Nach 2 Abb 2 1 2 beinhalten Pflichtenhefte nur die verbalen Produktanforderungen Dies h tte aber den Abstraktionsgrad noch weiter gesteigert und das Verst ndnis weiter erschwert Wahrscheinlich hatten die Mitarbeiter des Physikalischen Institutes meist nur mit den zahlreichen Verhaltenspezifikationen f r das XCtl Projektes gearbeitet Dort werden die jeweiligen Subsysteme exemplarisch an einer ausgew hlten Nutzeroberfl che erl utern Nach Meinung der Autoren kann dies die abstrakte weil rein verbale Produktbeschreibung im Pflichtenheft f r den Anwender bzw Auftraggeber wesentlich verst ndlicher machen Seite 42 Dekomposition beim Forward Engineering Il 2 Definitionsphase Nach 2 S 99 sollen die Prototypen nach der OOA erstellt werden siehe Abb II 20 rechte Vorgehensweise um die verbalen Ausf hrungen des Pflichtenheftes zun chst st rker zu pr zisieren Um aber die Realisierung des dekomponierten Pflichtenheftes zu beschleunigen wurden die Oberfl chen Prototypen vor dem OOA Modell erstellt Das ist m gli
127. duktstruktur gegeben Um einen berblick ber die vom XCtl Programm verwendeten Ressourcen zu erhalten wird die angesteuerte Hardware zusammen mit den benutzten Eintr gen der Konfigurationsdateien den betreffenden Oberfl chenfenstern und den M glichkeiten zu deren Aufruf stichpunktartig in einer Abbildung zusammengefasst Die Dialogfenster der neuen Manuellen Justage sind ausklappbar abgebildet um beim Studium der Referenz und Trainingsteile verf gbar zu sein Dann folgt eine allgemeine Nomenklatur f r Steuerelemente wo deren Funktion und Bedienung bebildert erl utert werden Entgegen 2 S 647f folgt nun der Referenz vor dem Trainingsteil So sind die in den Schrittfolgen des Trainingsteils verwendeten Produktfunktionen bereits aus dem Referenzteil bekannt Abgesehen von internen Produktfunktionen wie das Betreten eines Dialogfensters die nur im Pflichtenheft beschrieben werden m ssen konnte der Inhalt aus dem Kapitel Benutzeroberfl che des Pflichtenheftes bernommen werden Dementsprechend hnelt die Gliederung des Referenzteils wieder der des Pflichtenheftes vgl Abb II 8 Um das Nachschlagen zu beschleunigen ist der Referenzteil jedoch feiner gegliedert Jedes Steuerelement Bezeichnung in Hochkommata wird dazu im Inhaltsverzeichnis aufgef hrt IV 1 Hauptdialogfenster Manuelle Justage o Dialogfenster verlassen o Antrieb ausw hlen i e OK e Antriebsauswahl e Abbruch e fehlender Referen
128. durch Verwenden der Can Methoden innerhalb der Funktionskomponente automatisch korrigiert weil die unzul ssigen Operationen nicht mehr durchgef hrt werden k nnen Die brigen f nf Fehler mussten durch klassische Wartungsarbeiten am Programmcode korrigiert werden 13 Abschluss durch Fein und Abnahmetest Zun chst wurde hier ein Regressionstest durchgef hrt um zu pr fen ob das Gesamtverhalten durch die Dekomposition nicht beeinflusst wurde Analog zum Forward Engineering wurde anschlie end ein Feintest anhand des CTE Diagrammes M19 durchgef hrt um auch das genaue Verhalten zu testen und sicherzustellen dass durch die Dekomposition keine Fehler entstanden sind Bis auf die Fehlerkorrektur ist das Verhalten dieses Subsystems nach der Dekomposition v llig gleich geblieben Interessant st dabei die Tatsache dass die Mitarbeiter des Physikalischen Institutes den Austausch der urspr nglichen durch die getrennte Manuelle Justage berhaupt nicht bemerkten 14 Dokumentation des entstandenen Designs F r die getrennte Manuelle Justage war kein Designdokument erforderlich weil dieses Subsystem bereits durch die neue Manuelle Justage repr sentiert wird siehe Kapitel II Die Erstellung der getrennten Manuellen Justage hatte nur rein akademischen Charakter Sie dient dem Vergleich der Dekomposition m Forward und Reengineering Zudem sind hier Polling Variante und Observer Muster zu Vergleichszwecken p
129. e Wie bereits erw hnt besteht das XCtl Steuerprogramm aus mehreren Subsystemen siehe Abb 1 3 F r den Anwendungsfall Manuellen Justage konnte deshalb ein separates Pflichtenheft M15 entstehen Um die oben beschriebenen stilistischen und methodischen Hilfsmittel nutzen zu k nnen wurde das Pflichtenheft mit dem Textverarbeitungsprogramm Microsoft Word erstellt Dies erm glichte den Einsatz von Formatierungen und die Navigation innerhalb eines Dokumentes hnlich wie Hyperlinks in html Dokumenten Im ersten Teil des Pflichtenheftes erfolgte die Zielbestimmung welche aus den Bas sanforderungen II 1 abgeleitet wurden Des Weiteren wurden Einsatz und Entwicklungsumgebung Qualit tsanforderungen und die Zielgruppe beschrieben Abgeschlossen wurde dieser Abschnitt mit einer Kapitel bersicht und einem Verweis auf die Layoutkonventionen wo u a die Nomenklatur von Steuerelementen erl utert wird Der letzte Teil wurde ausgelagert weil er die Grundlage f r alle von den Autoren erstellten Artekfakte bildet und somit dokument bergreifend angewendet wird Im Kapitel funktionale Beschreibung entspricht Funktionen aus og Gliederung werden die gew nschten Produktfunktionen ausf hrlich erl utert siehe Abb II 3 Wiederherstellungen beim Start 11 6 Bewegungsparameter Antriebsauswahl 11 6 1 Sollposition Istposition 1 6 2 _Bewegungsgeschwindigkeit Offset f r lt Antrieb gt Relative Null 11 6 3 _Sch
130. e Beschreibung der einzelnen Steuerelemente konnte nicht bersichtlich n diese Seite integriert werden Daher wurden jeweils einzelne Themen erstellt die mit dem entsprechenden Ausschnitt aus der Abbildung des Dialogfensters verkn pft wurden d h der Klick auf ein Steuerelement ruft das entsprechende Hilfe Thema auf siehe Abb II 12 Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 33 Dialog neue Manuelle Justage xj RELATIYE HULL DF E E D l 1251 99 Sekunden 1255 59 setzen aufteekier e Direktbetrich EH Sollposition D I Sekunden ISTPOSITION Fahrbeirieh F3 Stat Geschwindigkeit 42 50 Sekunden sec Sekunden Schitbetrieb F4 Schrittweite Sekunden Diiss O4 RELATIYE NULL d LELET aulteier Hanuelle Justage CO Direktbrehreh FE ibi ek Je ISTPOSITION C Fahrbeirteb F7 Slmt Hikrometei M Schmtbelneir FEB Schalltweile Difteet IT RELATIVE NULL K m l E Mkrometer setzen aufteeher CG Direkibetneb F10 Goin I IGTPOSITION Fahrbetrieb F11 Geschwindegkeit Mikrometer Schrittbetrieb F12 Schr tweite U1 M krometer Difset PSD Difset Halbwertsbreite messen Hilfe Fil H Klicken Sie auf einen Bereich um das dazugeh rige Hilfe Thema angezeigt zu bekommen Hauptdialog neue Manuelle Justage Teilbereich Abbildung eines Teilbereichs zu E E izen ekunden ISTFOSITION Fahrbetnieh F3 Schritlbetrieb F4 Dies setzt
131. e 54 Tab II 5 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Polling Variante am Ende der Designphase 00u0000sssssssssssssssssnnnnnnnnnssssssssssssssssssssseee 66 Tab II 6 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Observer Muster am Ende der Designphase ss00000ssssssnnnuuunnnssssssssssssssssssnnssnsnnnsnnse 67 Tab II 7 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Polling Variante nach Abschluss der Implementierungsphase 0000000ssssnnnuununnnoeee 80 Tab II 8 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Observer Muster nach Abschluss der Implementierungsphase seeeeeeececossssseeseeeeceeooossoo 81 Tab II 9 Ausgew hlte Metriken der Testoberfl che 2 00000000000000s000000ssssssnnunnuunnnsssssssssnnse 87 68 Dekomposition von Software Systemen Abbildungsverzeichnis Ill Tab II 1 Ausgew hlte Metriken f r die Klassen der urspr nglichen Topographie 101 Tab II 2 bersicht zur urspr nglichen Topographie s osessososeseoscseososcsessoscsessoscsessoscsessosesee 102 Tab III 3 bersicht zur getrennten Manuellen Justage Polling Variante 00 0 00000000000000 130 Tab III 4 Ausgew hlte Metriken f r die Klassen bei der getrennten Manuellen Justage Polline Varlante nee EE 130 Tab III 5 Identisches Funkti
132. e Beobachter und TManJustage das Konkrete Subjekt Alle Aktionen f r den Datenaustausch werden von der Nutzeroberfl che gesteuert Dazu wird hier mit m_InkManJustage gt DoDirect die Antriebsbewegung gestartet Auch die Verwaltung des Timers liest bei der Nutzeroberfl che Dieser wird mit m_IinkTimer gt Start gestartet Ist das Timer Intervall abgelaufen wird die in TManJustageDlg implementierte Methode OnTimer gerufen Dort erfolgt die Aktualisierung der Nutzeroberfl che durch OnTB_Positions indem mittels m_inkManJustage gt GetAngle die aktuelle Antriebsposition ausgelesen und angezeigt wird siehe Abb II 29 Beim Starten und Stoppen eines Antriebs werden die Steuerelemente zus tzlich gesperrt bzw freigegeben OnTB_ControlsEnable Dekomposition beim Forward Engineering 11 3 Designphase Seite 59 ITManJustage TManJustageDlg TIinterfaceTimer Funktionskomponente Nutzeroberfl che m 1nkManJustage gt DoDirect Be E m lnkTimer gt Start m InkInterface gt OnTimer OnMotionStarts OnTB ControlsEnable FALSE OnTB Positions m InkManJustage gt GetAngle 3 m InkInterface gt OnTimer a OnMotionProgress OnTB Pss t onst m 1InkManJustage gt GetAngle gt ep Si oO Oo O D Z m InkInterface gt OnTimer N C OnMot1onStops de OnTB ControlsEnable TRUE OnTB Fos t anga t m InkManJustage gt GetAngle E m 1nkTimer gt Start Abb 11 29 Interaktionsdiagramm
133. e DWAR E GelStartTime DWORD stG ll as me rioal zL pll agt ounie DAIRO GelNumberatletORD GeiRestshots WORD Gelcordrolgiepfost GelConlalRangeNoal GelioveSlep Noal zap os AngleEscape Toat GehyorkPointiloat Gelf ngleBetweenShoishost Abb Ill 21 UML Klassendiagramm der getrennten Topographie 521MotorBOOL 5eiMoior DOOL 5atlelectorvoid 581Monilor void 5eiMeasurernenfTireBODL Se1startTimevold Seilurenifimenwoid 58 MaxTime BOOL H 581NumberGyele B90L Lea ounte DOC SeiResiShotsvoid SeilcontolRangeBooL 5el ngleBetweenShols BooL 58151arlAr gle BooL Leit omtrolleeo POOL SerMoeeztep POOL SelAngleWidhBO L 5eiM3 AngleEsc ape COOL 5EWlorkPointBOOL 5 ImeFinish oid rer imeRurnningwold 5e1iAdditionalTirnemwoid 531SlanFoint kvoid 5 HE eRlondecured void Leit 0omttrOol vcHhue wild SeiMonitorJsed waold 5eiMufipleShobwoid 5s1Small ngleSideroid zklasidotor POOL HasAddllonalTimeBddL IsMufiipleshot 50L lsCondrolAcve Bol 12S5mall ngleSide BO L l 5BUROK BO IL 15 S1aFol KBDUL IsMonitorllsedBO L lsTimeRunning BSOL lsExaplion Oceured BOOL 5E151rn4StartFoinbogid Get tmgStarfolntdouble Get tmgDistance dauble betechorRequestBO L GeBStrngreakinler s hiidal Geb5tndaSstartinlersiyNoat Di Getstnalntensiefioat GefstrngHwbrloat boalndSetings UIMT DoReselSellings void DolnibyorkPoinbvaoid DoMoveTorork Point BOOL DobloveToPointwoid Colpdatelounler ndBOGL
134. e Entw rfe erforderlich Die beiden Offset Dialoge sind ber Schaltfl chen siehe Abb II 10 in den Human Interface Prototyp integriert und per E Mail als ausf hrbare exe Datei verschickt getestet und akzeptiert Wie unter II 2 1 beschrieben wurde das Pflichtenheft daraufhin um die favorisierten Oberfl chenentw rfe erweitert und dabei mit dem Funktions und Datenteil verkn pft Bei der Erstellung der Prototypen und Belegung mit einer Pseudofunktionalit t wurde die Notwendigkeit von zus tzlichen oberfl chenspezifischen Funktionen deutlich die im Teil Nutzeroberfl che des Pflichtenheftes ausf hrlich erl utert werden mussten Bei der neuen Manuellen Justage waren dies haupts chlich Wechselwirkungen zwischen den drei Teilbereichszust nden Zur konfliktfreien Bedienung wurde mit den Mitarbeitern des Physikalischen Institutes z B festgelegt dass ein Antrieb nicht in mehreren Bereichen des Hauptdialogs gleichzeitig angezeigt werden darf Mit der Beschreibung solcher Eigenheiten im Pflichtenheft k nnen sp tere Probleme Diskussionen vermieden werden Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 31 11 2 3 Hilfe System Bei den umfangreicher werdenden Softwaresystemen ben tigt der Anwender zunehmend Unterst tzung Dies bezieht sich sowohl auf die Bedienung der Nutzeroberfl che als auch auf den damit angebotenen Funktionsumfang Je nach Produkt k nnen die Anforderungen an ein Hilfe System dabei sehr
135. e au erhalb des zul ssigen Wertebereichs liegt so wird die Positionsangabe auf die minimal oder maximal zul ssige Position korrigiert je nachdem ob der zul ssige Wertebereich unterschritten oder berschritten wurde Kennzeichnung f r den G ltigkeitsbereich Umfang dieser Produktfunktion Abb IA Auszug aus dem Funktionsteil des Pflichtenheftes M15 Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 25 Kernpunkt dieses Kapitels ist die Beschreibung der insgesamt 15 Produktanforderungen Wie oben erw hnt sind diese mit F lt f f gt nummeriert und besonders formatiert siehe Abb II 4 Eine Zusammenstellung aller Produktfunktionen ist im Anhang E des Pflichtenheftes zu finden Ist die Ausf hrung einer Produktfunktion an Bedingungen gekn pft gt sind diese gesondert nach der Beschreibung angegeben Weil Funktionen oft mit vielen Datenelementen verkn pft sind wurden keine Querverweise auf die Tabellen dieser Daten eingef gt Allein in F 70 w ren 21 Verweise notwendig gewesen Da sich die Benennung der Gliederungspunkte im Kapitel Daten grunds tzlich nach den kursiv geschriebenen Fachbegriffen des Funktionsteils richtet ist das schnelle Auffinden der entsprechenden Tabelle unproblematisch Nur f r selten verwendete Begriffe ___ gt wurden Querverweise eingef gt Das dritte Kapitel besch ftigt sich mit den zu verwaltenden Daten welche f r die Produkt funktionen ben tigt werden Neben
136. e bereits vollst ndig getestet zur Verf gung so dass auf eine simulierten Komponente verzichtet wurde F r den Test wurden die beiden oben angesprochenen Steuerungsarten angewandt Zuerst wurde ein manueller Feintest durchgef hrt wobei die Testf lle mit CTE erfasst wurden F r einen einfacheren automatischen Regressionstest wurde anschlie end der im Rahmen des 2 zu Testreiber siehe S 414 Seite 90 Dekomposition beim Forward Engineering Il 5 Testphase XCtl Projekt entwickelte autarke Testtreiber Automatisches Testen oberfl chenbasierter Systeme ATOS Werkzeug siehe 9 S 30ff verwendet 1 Ausf hrlicher Feintest Vor dem Regressions und Abnahmetest sollten Validation und Verifikation durchgef hrt und die Vollst ndigkeit sichergestellt werden Bei der Nutzeroberfl che bedeutet dies die korrekte fehlerfreie und vollst ndige Verkn pfung der Steuerelemente nach den Spezifikationen des Pflichtenheft im Kapitels Benutzeroberfl che Dazu werden Testf lle definiert die Handlungsanweisungen f r den Tester vorgeben und hn z B zu Eingaben auffordern Durch deren sequentielle Abarbeitung sollen der Programmzustand kontrolliert ge ndert und Fehlersituationen provoziert werden Die Gesamtheit der Testdaten repr sentiert den aktuellen Programmzustand Nach der Durchf hrung der Handlungsanweisungen eines Testfalls muss der durch die Testdaten vorgeschriebene Zustand der Oberfl che vorliegen
137. e neue Methoden zum Auslesen des aktuellen Zustands implementiert Auch Eigenschaften der Nutzeroberfl che werden nun direkt ausgelesen was bereits zwei TAnglectiDig TAngle2tiDlgd TAnglectiDlgg Fehler eliminierte siehe M19 m_InkAnglectTanglect m_InKTimerTintefaceTimer OnSsupenisekMovel BOOL GetBarScale double GSetBarEgdeiBQ l conshint GetBarFosg int TAnglectlDig Ornlnito oid OnsScrollbarline Bo0ol constivoid OnsScrollbarEndscroll oid Onlinterrupto oid OnLeaveg oid OnMotarinit oid OnFParamseto void Onsel anglezeroo void OncancelRelatvezero ngid OnStartMeasureH BO woid OnStopheasureH BO voigd n SteeringReady void n CounterSet woid OnStephiode woid OnLongMoveblode oic OnGhooseMotorcintvoid OnGhooseMotorl TAxisTypelvoid nIDOKO void OnMNew ngleEnterediBO0L c0nsb void OnangleWsidthEntereckBO0OL constvoid OnspeedEntered BOOL consbooid Abb 111 10 UML Klassendiagramm von TAngleCt1Dl1g Nutzeroberfl che nach der Dekomposition mit Zuordnung der ausgelagerten Methoden m_BarHandleiHiND m_WotorList HMD m_Selected int m_Step ode BOOL Dlg_Onlnitt HA NO HAMDO LPARAM BOOL DOlg_onHScrollBarcH NDO HD UINT mmfwvoigd Interrupt voic LeaveDialogg void Folg_OnCommandcHNND mt HMD LINT void OnTimer TBasiceTimer consbvolic OnMotonstansowoic OnMotionProgress void OnMotonstopsonoic OnMeasurestans ov
138. e und 39 Testdaten siehe M37 Die jeweiligen Grenzwerte wurden Verhaltensspezifikation M31 entnommen Der Test der Oberfl chenfunktionalit t umfasst das Verhalten der Eingabefelder des Dialogs Topographie Einstellungen w hrend der beiden Messungen F r die 15 Felder waren 30 Testdaten jeweils freigegeben und gesperrt und vier Testf lle zwei f r die Art des Aufrufs und zwei f r die Art der Messung n tig siehe M38 F r den Dialog Topographie Durchf hrung wurde ein CTE Diagramm mit 10 Testf lle und 23 Testdaten erstellt um Reaktionen auf ung ltige Zahlenformate m Eingabefeld und den Status der Schaltfl chen w hrend und nach den Messvorg ngen zu testen F r den abschlie enden Regressionstest konnten die Testf lle f r die urspr ngliche Topographie siehe M36 genutzt werden Diese f hren komplette Messungen mit bestimmten Parametern durch und vergleichen die Ergebnisse mit gespeicherten Referenzwerten 14 Dokumentation des entstandenen Designs Das Dokument Software Struktur M29 war nach der Dekomposition veraltet und musste durch eine neue Dokumentation erg nzt werden Dazu wurde am Ende der Dekomposition entsprechend der Vorgaben aus IlI 3 4 ein neues Designdokument f r die getrennte Topographie erstellt siehe M35 In der alten Dokumentation waren neben dem Subsystem Topographie auch die benutzten Subsysteme erl utert Die Erl uterungen zur Anbindung der Motorsteu
139. efinitionen weil diese die oben erl uterten Typen benutzen k nnten In C sollte sich dies nur auf const Konstrukte beziehen define Direktiven sollten bekanntlich vermieden werden Der Hauptteil des Dokumentes beinhaltet die Klassen Dabei ist wichtig die Beziehungen zwischen den Klassen zu erl utern indem ein Klassendiagramm mit der kompletten Vererbungshierarchie und allen Beziehungstypen aber ohne Methoden und Attribute gezeigt wird Liegt ein dekomponiertes Subsystem vor werden zuerst die Klassen der Funktionskomponente behandelt und anschlie end die der Nutzeroberfl che Bei den letzteren befindet sich jeweils eine bersicht ber die Steuerelemente in den Dialogfenstern in C die Gegen berstellung der Ressourcen Bezeichner und der Beschriftung Abschlie end folgen die globalen Variablen und Methoden Alle Typen Attribute Methoden und Variablen sind nach dem folgenden Schema formalisiert dargestellt siehe Abb 11 34 gt typedef enum tbl tb2 tb3 ETB GLOBAL Aufz hlungstyp f r die Adressierung der Teilbereiche zu deren Verwaltung siehe Methode TB_Next TB_Count TB_GetId TB_GetName gt UINT m_MotorCount lt ZSA gt lt N gt Anzahl der Motoren inm MotorList gt DUINT GetMotorCount void lt AsM gt lt N gt gibt die aktuelle Anzahl der Antriebe in der Antriebsliste zur ck siehe m_MotorCount gt TSteering Steering Role GLOBAL lt N gt Objekt f r den Zugriff auf die Makrosteuerung Legende
140. eifen wird nun an das jeweilige Subsystem delegiert Dadurch kann man am Beispiel der neuen Manuellen Justage aber schlecht erkennen dass die Funktionskomponente die Datenverwaltung bernimmt jedenfalls kann man dazu nicht nur NOA heranziehen Erst wenn man anstelle der ersten beiden Zeilen aus Tab II 5 bzw die ersten drei Zeilen aus Tab II 7 die im OOA geplante Funktionskomponente Tab II 3 verwendet liegt die Verwaltung der Daten wieder eindeutig bei der Funktionskomponente insgesamt verwaltete Daten 21 Funktionskomponente Polling Var iante zu 12 nutzeroberfl chenspezifisch Des Weiteren fehlen einige Methoden in Abb II 22 die f r das Auslesen des Wertebereichs zust ndig sind z B GetChannelMin Da die Set Methoden den ihnen bergebenen Wert selbst ndig berichtigen und den ggf korrigierten Wert zur ckgeben siehe II 3 1 b werden solche Methoden nicht ben tigt Die Oberfl che hat keine Kenntnis ber den Wertbereich In einer deutlich ausgepr gten Schichtenstruktur sollten alle Objekte einer Schicht nur mit der direkt dar ber oder darunter liegenden Schicht kommunizieren d rfen In einem nicht dekomponierten Subsystem das nur aus der Nutzeroberfl che besteht tauscht die Oberfl che daher direkt mit dem niederen Subsystem zur Hardwareansteuerung EZ Daten aus Bei einem dekomponierten System Abb 1 7 erfolgt die Kommunikation durch zwischen Nutzeroberfl che EZ und niederem Subsystem EZ
141. eine Referenz auf das konkrete Subjekt e implementiert die Beobachter Schnittstelle um die Konsistenz herzustellen Im objektorientierten Design werden diese vier Elemente durch Klassen oder Interfaces realisiert Die Beziehungen werden durch Vererbung und Assoziationen beschrieben siehe Abb 11 25 Die im Subjekt definierte Schnittstelle wird als abstrakte Klasse oder Interface entworfen Das Konkrete Subjekt ist eine Klasse die das Subjekt Interface einerbt und f r den jeweiligen Anwendungsbereich spezialisiert Die im Beobachter definierte Schnittstelle st w eder eine abstrakte Klasse oder ein Interface Der als Klasse erstellte Konkrete Beobachter erbt dieses Beobachter Interface ein und besitzt eine unidirektionale Assoziation auf das Konkrete Subjekt Dieses hat ber das Subjekt Interface eine Liste von Referenzen auf Beobachter Interfaces Sulyakt inteface EEE Beobachter Subjekti hinzufuegend Beobachter 7 HeobacherListe e entfernent Beobachter 7 Ge henachrichtigend N tor all b in BeobachterListe Ki D zaktualeioren Konkreter Beobachter Konkretes Subjekt 1 BeobarhterStatus Stalus einSubjekt aktualisierenf Lesestatuso Status Setestatuso un Benh chterStatus RS t die sp tere Nutzeroberfl che einSubjekt gt Lesestatuso die sp tere Funktionskomponente Abb 11 25 UML Klassendiagramm zum allgemeinen Aufbau des Observer Musters nach 8 Dekomposition beim Forward Engineerin
142. einen Unterschied zwischen Observer und Polling Abschlie end wird noch einmal darauf hingewiesen dass die Wahl des Kommunikationsmusters im Reengineering zus tzlich vom vorhandenen Muster im urspr nglichen System abh ngt In allen anderen F llen m ssen wieder die in 11 3 3 4 genannten Kriterien herangezogen werden Verallgemeinert sollte das Observer Muster aufgrund des umfangreicheren Designs nur eingesetzt werden wenn die Polling Variante nicht anwendbar oder zu fehleranf llig ist Seite 134 Dekomposition beim Reengineering Ill 2 Restructuring Subsystem Subsystem Benutzeroberfl che Utilities TBasicDialog lt lt interface gt gt TTimer TModalbig II ner S Tinterface Timer I A mlinkintefacel lt lt interface gt gt L neolerC Hie mm Iok noaleCH 0 1 m_Ink ngleCHDlg T Dei F ewmetertes Le EH m_InkMeasureTimer S 4 m_sensor Subsystem getrennte Manuelle Justage i Subsystem el Detektornutzung Abb Ill 22 UML Klassendiagramm f r die getrennte Manuellen Justage Observer Muster mit bersicht der benutzten Subsysteme MERS TAnglectl 4902 7 47 Unie 226 2 1 4 TAngleCtlDlg 414 5 35 1 10 71 24 5 37 4 1 39 Tab Ill 8 Ausgew hlte Metriken f r die Klassen bei der getrennten Manuellen Justage Observer Muster Dekomposition beim Reengineering Ill 2 Restructuring Seite 135 Anwendungsfall Topographie Dateien e Funktions
143. elles Offset anzeigen Offset eingeben Offset neu definieren e entspricht Winkel Offset eingeben Dialogfenster verlassen OK bzw Abbruch Abb Il 2 Realisierung von Funktionen und Daten als Bedien und Steuerelemente eines Oberfl chenfensters am Beispiel des Dialogfensters Offset f r lt Antrieb gt Die Integration des Oberfl chenentwurfs stellt so die Vollst ndigkeit der Produkt Definition und der Nutzeroberfl che sicher weil e einerseits Produktanforderungen im Oberfl chenentwurf unterschlagen worden sein k nnten S e sind dann mit keinem Bedien oder Steuerelement verkn pft e Andererseits sollte jedes Bedienelement mit dem Daten oder Funktionsteil verkn pft sein Wenn keine Querverweise enthalten sind ist zu pr fen ob das Pflichtenheft erg nzt werden muss Es k nnte sich aber auch um Funktionen handeln die nur diese spezielle Nutzeroberfl che betreffen z B das Anzeigen Verstecken anderer Oberfl chenfenster insbesondere nach nderungsw nschen oder Wartungsarbeiten Seite 24 Dekomposition beim Forward Engineering Il 2 Definitionsphase So werden M ngel fr hzeitig sichtbar gemacht die sonst u U erst beim Einsatz des Produk tes zu Tage getreten w ren Ein um die Nutzeroberfl che erweitertes Pflichtenheft erleichtert zudem die Erstellung des Hilfe Systems und des Benutzer Handbuchs siehe IL 2 3 bzw II 2 4 Anwendungsfall Manuelle Justag
144. ellt Schwerpunkt bildet die Designphase mit der Erl uterung von Design Mustern f r den Datenaustausch zwischen Nutzeroberfl che und Funktionskomponente Im Folgenden wird das vorhandene Subsystem das bereits Teil des Originalprojektes von 1998 war als urspr ngliche Manuelle Justage bezeichnet Das im Forward Engineering erstellte Subsystem erh lt die Bezeichnung neue Manuelle Justage F r eine kurze Einf hrung in den Gegenstandsbereich dieses Systems siehe 1 3 2 Seite 18 Dekomposition beim Forward Engineering Il 1 Analysephase UI Analysephase Am Beginn des Forward Engineering steht die Zusammenfassung der zu realisierenden Basisanforderungen Das sind nur die grundlegendsten Eigenschaften die das Produkt aus Sicht des Auftraggebers erf llen soll Sie werden ohne n here Details im Lastenheft gesammelt und bilden die Grundlage f r die Durchf hrbarkeitsstudie und den Projektplan ausf hrlich in 2 S 62ff Normalerweise entsteht das Lastenheft aus Gespr chen zwischen Auftraggeber und den Vertretern die f r die Softwareentwicklung zust ndig sind Existieren bereits ein Produkt oder ein Subsystem zur L sung derselben Problemstellung Referenzprodukt so k nnen die dort gewonnen Erkenntnisse Dokumentationen und nderungsw nsche f r die Neuentwicklung im Forward Engineering sehr hilfreich sein Das gilt auch f r gescheiterte Projekte weil die Gr nde daf r analysiert und im Neuentwurf ber cksichtigt werden k
145. emente zu erleichtern sind die Punkte sind in beiden Kapiteln identisch benannt und geordnet II 1 Wiederherstellungen beim Start 111 6 Bewegungsparameter IIl 2 Antriebsauswahl III 6 1 Sollposition III 3 Istposition III 6 2 Bewegungsgeschwindigkeit II A Offset f r lt Antrieb gt Relative Null IIl 6 3 Schrittweite IIl 5 Betriebsarten 111 7 lt PSD gt Offset Abb Il 7 Auszug aus der Gliederung des Pflichtenheftes M15 Kapitel Daten Auf den Gliederungspunkt Leistungsanforderungen wurde verzichtet Nach der Analyse der urspr nglichen Manuelle Justage schien die Ausf hrung der Produktfunktionen und der Zugriff auf die ben tigten Daten problemlos m glich zu sein einfache Berechnungen oder Speicherzugriffe Durch das robuste Design der Funktionskomponente das bei der Dekomposition entstand traten durch die Hardwareansteuerung an den Messpl tzen der Physik widererwartend Geschwindigkeitsprobleme auf die nachgebessert werden mussten siehe dazu 11 4 Im anschlie enden Kapitel Benutzeroberfl che entspricht Nutzeroberfl che aus og Gliederungsschema wurden die W nsche der Mitarbeiter des Physikalischen Institutes an die neue Nutzeroberfl che festgehalten Dazu erfolgte auch eine Analyse und Bewertung des urspr nglichen Dialogfensters siehe II 2 2 Die gewonnenen Erfahrungen wurden zun chst Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 27 stichpunktartig in diesem Ka
146. en 4 Set 1 Reset und eine brige Methode zur Steuerung der Subsysteme Motorsteuerung und Detektornutzung sowie Ablaufsteuerung oder zu deren Parametrisierung siehe Abb III 11 CZ m_SensorTDetector Pm Motor oun JNT m_MoveSpeecfoat m_lsMeasuring BO0OL TAnglectl pdatebDetector void 5et5Speedi const int double SAQOL 5et ngdleidthiconst int double M BO0OL 5ettorrectionStatecconst int BOL 5etRelativezerottconst int BOL FesetFelativeZerocconst int BOOL Oolnit const int BOL Doolnitlotorcconst int BOOL cons BOOL DoDirecteconst mt const double BOOL Dostepcconstin B00 const BOL DoDrietconst mt BOOL const BOL DoStop consting BOOL DoStopEvernthingi const Ip wpig DoStatMeasure tH ND const BOOL DoStopMeasurecconstint BOOL T ngletti TAngleci TAnglect DoSelectMotoreconst ind BOOL MovestconstintBOoOL YAGOL Gel ngle constint BOOL amp double Get ngleMinGconstint BOOL Edoublg GetAngleMast constin BOOL amp i double Gelspeed constint BOOL double GetAngleidtheconstint BOOL S double GelDigitscconstint BOOL SiNT Getlniteconstint BOOL i LPCSTR Gethiotoridsi T sis Type const int GethiotorName const int BOOL L LPESTR GelMotorcounto iint GelActualMotoro int rlelndosgv aldi const Im BOOL Hasofset constint BOOL SAGOL 5Movingcconstint BOOL SAGOL 5sGalibratedi const int BOOL Si BOOL sMeasuringo BOOL sMeasureReset BOL GetMeasureHwhbh double Me
147. en Justage hie e jedoch ein Verzicht auf einen Teil der zus tzlichen Funktionalit t von TManJustage siehe Tab II 6 Die drei Teilbereiche im Hauptdialogfenster k nnen trotzdem problemlos angesteuert werden Die in Tab UI aufgef hrten Methoden realisieren in beiden Funktionskomponenten dieselbe Funktionalit t abgesehen von der Art der Ansteuerung der benutzten Subsysteme und der Robustheit Die Methodenbezeichner wurden w hrend der Dekomposition im Reengineering vom Forward Engineering bernommen Wo die bernahme nicht m glich war zeigt Tab III 7 Grundlage dieses Vergleichs sind Abb II 46 bzw Abb III 14 und die Analyse des Programmcodes DoDirect CanDoDirect DoDrive CanDoDrive DoStep CanDoStep DoStop CanDoStop DoStopEverything GetMotorCount GetMotorlIdx IsIndexValid HasOffset IsMoving IsCalibrated GetAngle GetAngleMin GetAngleMax GetDigits GetSpeed SetSpeed CanSetSpeed GetAngleWidth SetAngleWidth CanSetAngleWidth GetUnit GetMotorName SetRelativeZero CanSetOffset ResetRelativeZero CanResetRelativeZero UpdateDetector DostarLMeasure CanDo tartMeasure DoStopMeasure CanDoStopMeasur IsMeasuring IsMeasureReset GetMeasureHwb Tab 111 5 Identisches Funktionsangebot von TManJustage und TAnglecCtl Benennung wurde von TManJustage bernommen 39 Methoden realisierte Funktionalit t TManJustage die TAnglect1 nicht leisten kann GetMotionType SetMotionType CanSetMotion
148. en Platzangebotes kann die neue Manuelle Justage hier nicht vollst ndig mit Attr buten und Methoden abgebildet werden Das komplette Design kann jedoch leicht selbst durch die Abbildungen Abb II 22 f r TManJustage und TMotorData Abb 11 23 f r TManJustageDlg und Abb 11 24 f r TMotorOffsetDlg und TPsdOffsetDlg vervollst ndigt werden 11 72 1 BEWERLINENYON Ouse ver Muster ung EOlbnE un Anwendungs Beim Vergleich des Observer Musters Abb II 37 mit der Polling Variante Abb II 36 f llt sofort die observer typische Kommunikationsschnittstelle IManJustageDlg ins Auge Obwohl das UML Klassendiagramm damit wesentlich umfangreicher st werden daf r insgesamt etwas weniger Attribute NOA 24 Observer zu 26 Polling ben tigt Die Methodenanzahl bleibt gleich NOO 123 Der Grund ist dass bei der Polling Variante Zustands nderungen durch die Nutzeroberfl che kompliziert ermittelt werden m ssen Dazu liest die Nutzeroberfl che den aktuellen Zustand von Attributen der Funktionskomponente aus und vergleicht diese mit zwischengespeicherten Werten Dazu sind zus tzliche Attribute n tig Beim Observer Muster informiert die Funktionskomponente als Ausl ser der Zustands nderungen sofort die Nutzeroberfl che Seite 66 Dekomposition beim Forward Engineering 11 3 Designphase MERSE
149. enesssssssssssssssseererersssssssssssses 74 Anwendungsfall Manuelle Justage 74 TE ue EE 79 II 4 3 1 Bewertung von Observer Muster und Polling im Anwendungsfall 80 Nee Testphase aus ee A E N E 82 11 5 1 Testeiner Funktionskomponenters orses r n E dee 82 Anwendungsfall langehlerTueteueeeougeregeabesgesgetresegrsbasdie deeg Sekge Seege esd dee SE 11 5 2 Testene r NURETIober lache nern 89 Anwendungsfall Manuelle Justage uses nee 89 Es Zusammen UE n A dee 94 11 6 Fazit und A useR oseto rosenes 222 Ha E A e RR 95 III DEKOMPOSITION BEIM REENGINEERING IT CERN seen A A E AT 99 Anwendunsstall Mantelle Justan e un A a 99 Anwendunsstall 1opoSTaphie EE 100 I 2 Restructurns EE 103 IM 2 1 Allgemeine Schrittfolge f r die Dekompospon 103 Anwendungsfall Manuelle Justage 114 Anwendungsfall Topographie 122 M22 Zusammenlassun er Aa eek ne 130 Anwendungsfall Manuelle Justage sonnnonneneesssssssssssssseeerrersssssssssssssseerersssssssss 130 III 2 2 1 Bewertung von Observer Muster und Polling im Anwendungsfall 133 Anwendunsstall Topographie u ee 135 UI ES Fazit und Ausblick 22 2 2228 22a O 137 IV GESAMTFAZIT ANHANG A EITER TURVERZEICHNIS 2 20 2020 0222020 80a aeaeaei selten desekbnsenssnhenedennegeeee 141 ANHANG B VERWENDETE MATERIALIEN seessseessonensnennnsnnnnnnsnnnnensnunnnssnnnensnunnessnnnnsssnnnensnnnnsssnnnesssnnnee 142 ANHANG C STICHWORTYVERZEICHNSS gedet 144 ANHANG
150. enug den legalen Aufruf solcher Funktionen zu ignorieren Zus tzlich wurde deshalb eine R ckmeldung programmiert um den Anwender zu informieren Die Implementierung der wesentlich bersichtlicheren Offset Dialoge gestaltete sich in jeder Hinsicht v llig problemlos Hier mussten weder Methoden f r die Verwaltung der Steuerelemente noch Geschwindigkeitsoptimierungen vorgenommen werden Die Klassen TMotorOffsetDlg und TPsdOffsetDlg bestehen daher fast ausschlie lich aus den berschriebenen Methoden der Bas sklasse damit auf die Benutzung der Bedienelemente reagiert werden kann m_InkManlustage TManJustage m_InkManlustageTManJustage mids INT mids INT m_Digits NT mm Dote NT Dlg_Onlnitt HW NO HY NDO LPARAM BOOL Dlg_Onlnitt HNO HYY NDO LPARAM DOOL FDlg_oncommandc HAND int HAMDO UIN Trwotgdt Dlg_ontommandg HANDO int HDO LINT void TMotor fisetDig TPsd ffsetDlg TMotor fsetiOlgelINT const TManJustage GaicValuecCHOOl B OGL Choose ngleModec hoali void IsAngleMode BOOL Bm Attribute DL Methoden der Basisklasse n DT weitere Methoden TMotoroffsetiOlgellNT const TManJustage GaicMaluecCHOOl BOL Abb 11 51 Seit dem OOD unver ndert das UML Klassendiagramm f r die Dialogfensterklassen TMotorOffsetDlg und TPsdOffsetDlg Implementierungsphase Wenn man die Design nderungen seit dem OOD verfolgt vgl Tab II 7 und Tab II 5 sind die beiden Offset Dialogfensterklassen unver ndert ge
151. er Delegat on an diese Methoden auch die oberfl chenspezifischen Funktionen erf llen implementieren die im Kapitel Benutzeroberfl che verbal beschrieben sind Einer parallelen Implementierung von Nutzeroberfl che und Funktionskomponente steht zun chst nichts im Wege Zum Test wird dann jedoch eine vollst ndig getestete Funktionskomponente ben tigt Anwendungsfall Manuelle Justage Wie bereits aus dem Oberfl chen Prototyping und dem OOD Modell bekannt besteht die Nutzeroberfl che der neuen Manuellen Justage aus drei Dialogfenstern bzw den Klassen TManJustageDlg TMotorOffsetDlg und TPsdOffsetDlg Daf r wurde das Dateip rchen MJ_GUI H und MJ_GUI CPP erstellt hnlich der Funktionskomponente Aufgrund der geringen Komplexit t der beiden Offset Dialogklassen wurden dort die drei Klassen zusammengefasst Aus 11 3 2 ist bekannt dass die Basisklasse f r die Oberfl che der neuen Manuellen Justage TModalDlg ist Sie stellt das Grundger st f r modale Dialogfenster dar und bietet einen Pool an Methoden die m den abgeleiteten Klassen berschrieben und spezialisiert werden k nnen Den Kernpunkt bildet dabei die Methode void Dlg_OnCommand HWND ity HWND UINT wo alle Steuerelementbotschaften empfangen anhand der Parameter identifiziert und behandelt werden k nnen Durch die gro e Anzahl an Steuerelementen im Hauptdialog der neuen Manuellen Justage w re diese Methode entweder zu komplex geworden oder s
152. er entsprechenden Do oder Set Methode direkt an diese Bedingung gekn pft ist sollten alle CanDo und CanSet Methoden das Ergebnis ihrer Bedingung als Wahrheitswert d h per R ckgabewert zur ckgeben So ist leicht feststellbar ob die Funktion vollst ndig ausgef hrt wurde Anwendungsfall Manuelle Justage Weil die neue Manuelle Justage prinzipiell die gleiche Funktionalit t wie die urspr ngliche anbieten soll Antriebsteuerung und Halbwertsbreitenmessung wurde dort ein Programmcode Review durchgef hrt das in M24 dokumentiert wurde Dabei wurden Beziehungen zu den Subsystemen des XCtl Projektes herausgearbeitet die bereits Teile dieser Funktionalit t anbieten Da im Repository des Projektes diese Subsysteme nicht dokumentiert waren mussten sie einem Reverse Engineering unterzogen werden Als Resultat entstanden die Designdokumente M26 Motorsteuerung und M4 Ablaufsteuerung einschlie lich der Fehler d e w hrend dieser Analyse gefunden wurden Einzige Ausnahme war das Subsystem Detektornutzung f r das im Rahmen einer Studienarbeit bereits das Reverse Engineering Dokument M12 erstellt wurde Um die fehlerfreie Anbindung an die Manuelle Justage zu gew hrleisten wurden die Subsysteme anschlie end einem Reengineering unterzogen Schwerpunkt war die Verbesserung Dekomposition beim Forward Engineering 11 3 Designphase Seite 45 des Zugriffsschutzes f r Attribute und die damit verbundene Erstellung und
153. er fr her zu erkennen und zu beheben 111 2 1 Allgemeine Schrittfolge f r die Dekomposition 1 Erstellung neuer Dateien Wie beim Forward Engineering sind auch hier Implementierungs und Header Dateien f r Funktionskomponente und Nutzeroberfl che getrennt zu erstellen Die Benennung dieser vier Dateien sollte die Zugeh rigkeit zu einem Subsystem widerspiegeln und anzeigen ob es sich um Dateien f r die Funktionskomponente bzw Nutzeroberfl che handelt Die in der Ist Analyse f r das zu dekomponierende Subsystem identifizierten Klassen werden entsprechend ihrer Funktion in die verantwortliche Datei kopiert Genauso ist mit den includes zu verfahren Um die urspr nglichen Klassen zu erhalten werden diese vorerst mit dem Suffix OLD gekennzeichnet umbenannt und in den alten Dateien belassen Damit das gesamte Projekt nun stets die zuk nftig getrennte Variante benutzt m ssen die includes anstatt auf die alten Dateien nun auf die neuen Dateien zeigen Zudem muss die Datei mit der Deklaration der Funktionskomponente in der Header Datei der Nutzeroberfl che inkludiert werden Die alten Dateien werden nun nicht mehr benutzt sichern jedoch weiterhin die urspr ngliche Implementierung v Nachdem die neuen Dateien auch in die Projekt Makedatei aufgenommen wurden kann das Gesamtsystem kompiliert und gelinkt werden Noch nicht bearbeitete includes werden dabei immer erkannt weil die Klassen im alten Subsystem nicht mehr gefunden wurden Jetzt
154. er mit bersicht der benutzten Subsysteme sssssssssssuseeuesssssssssssssese 134 ABK RZUNGSVERZEICHNIS A ADD 5 33 Abbildung ADO Abstract Design Object ADV sa je nach Kontext Abstract Design View bzw Abstract Design Viewer AKA audi akademisch elerles APl ua Application Programming Interface B bspw beispielsweise DZ Weesp beziehungsweise C Cds circa CASE Computer Aided Software Engineering COM Component Object Modell CIE see Classification Tree Editor propriet res Testwerkzeug D Uhse das hei t Disease Dynamic Link Library VI Zur Dekomposition von Software Systemen Abk rzungsverzeichnis E LE et cetera F EEE folgende UNTEREN tortfolgende G U EE gegebenenfalls GUN er Graphical User Interface H Elise na Herausgeber l Ea D E E in der Regel insbes insbesondere ISO International Organisation for Standardization M REN Methoden MFC ua Microsoft Foundation Class propriet re Bibliothek f r MVC MVC 2 Microsoft Visual C propriet re Programmiersprache O OLE Object Linking and Embedding OOA oaeee Object oriented Analysis Objektorientierte Analyse Eegen Object oriented Design Objektorientiertes Design OOP ses Object oriented Programming Objektorientierte Programmierung S Deet Seite n T KT GE Tabelle U Vai unter anderem Heed unter Umst nden V EE eege Verlag Vol vergleiche X RE steht f r X Ray Control Steuerung von R ntgenstrahlung
155. ering Ill 2 Restructuring Seite 103 111 2 Restructuring Bei der Dekomposition eines vorhandenen Systems ist eine phasenorientierte Bearbeitung nicht von Vorteil bzw nicht m glich Die Analyse und Definition werden bei dieser Dekomposition nur zur Einarbeitung m den Gegenstandsbereich ben tigt Die Anforderungen bleiben w hrend der Dekomposition unver ndert nderungen m ssen nach dem eigentlichen Prozess erfolgen Die Designphase ist nicht explizit durchf hrbar weil die Dekomponierbarkeit erst nach nderungen am Programmcode festgestellt werden kann Dies umfasst die Bestimmung und ggf Ver nderung der Kard alit t von Funktionskomponenten und Nutzeroberfl chen siehe III 2 1 2 sowie nderungen an den Beziehungstypen und der Vererbungsstruktur Zudem ergeben s ch Anzahl Funktion und Benennung von Methoden erst am Ende der Dekomposition aus der resultierenden Implementierung Urspr ngliche Zuordnungen der Attribute zu den Klassen k nnen sich dann ge ndert haben Das Design entwickelt sich also indirekt w hrend der Anwendung der Schrittfolge Die Implementierungsphase bildet den Kern der Dekomposition S e beinhaltet Aspekte des Designs und st ndige Tests um den korrekten Verlauf der Dekomposition sicherzustellen Die Schrittfolge ist so gestaltet dass sich Testaktivit ten und Implementierung st ndig abwechseln Jeder Implementierungsschritt wird durch eine Testphase abgeschlossen um so Folgefehler zu vermeiden neue Fehl
156. erung konnten entfallen da sie bereits in den selbst erstellten Artekfakten M26 bzw M28 vorhanden sind F r die Ausf hrungen zur Ablaufsteuerung gilt das gleiche da f r dieses Subsystem eigene Designdokumente mit ausf hrlichen Klassenbeschreibungen vorhanden sind siehe M4 bzw Mol Seite 129 Dekomposition beim Reengineering Ill 2 Restructuring m_InkbeteciorTDetector m_InkkonitarTOeiector M kM or kF oin Trlacro Tag m number iE RD m_NYvorkPolniflost m_fControlRange float m_K ontrolStep float TT MneSlepNoat m_MarAngleEscapeTnoal m _Motor int m_dwhazCounie DWORD mm dange doubie m_AngleBebwreanS5hols Adal m_MeasuremenlTineLOMG m_farTimetloat m_detlurertTimeDN RD m_d SlartTime DWVORD ri_bSrrall n gleSsideDOOL m_blonliorIsediBOOL m_bMlulbipleShar BOL pm bCGopbsoi rcbree POOL M b ebzpOxDOoOL fr h btarbombk BOIL m ARestShots WORD m_bTimerfinish BO OL m_bAddiionalT me Biol fri_bErsa Mio cc red COOL fr hismmebuonpino POOL m_InstanceTTopography TTopography TTopagrap ny operator TTopograpfr amp Gellnsiance TTopography GelDetector TOeterctor GelsciDeleciorTDelacior GelMoritor TDelector Gel OrkPoint TMacroTag Gethlotorint GellotorName LPCSTR GellolorlAniELFESTR GellJnilFormalLPGSTR stzpl cHh tor le stGelt otoroupt mt GelStart nglesdouble 5elAngle double GelolorbDigits l INT GeleasuremenTimeLONG GetlurrentTim
157. erwendet In Abb II 45 wird vor dem Setzen des Kanal Offsets gepr ft ob das Offset vorher erfolgreich ermittelt werden konnte siehe aValid setzen eines neuen aktuellen Kanals BOOL TManJustage SetChannel int amp achannel BOOT Ee ie HasDeteetorAxris 4 m_Channel 0 return FALSE int idx GetDetectorAxislId x achannel max m_InkDetector gt GetFirstChannel min aChannel m_IinkDetector gt GetLastChannel Anpassung ResetChannelOffset idx alten Kanaloffset zuerst entfernen TAngle NewOffset GetOffset idx bValid CalcChannelOffset aChannel if bValid SetoOffset idx NewOffset return FALSE A Offset konnte nicht gelesen oder gesetzt werden m_Channel aCchannel erstnach SetOffset weil m_Channel dort auf FirstChannel gesetzt wird IniWriteLong GetHWFile m_DetectorlId MJ_Channel m Channel ji EE JI Abb 11 45 Nutzung der Mutator Methode SetOffset anstatt eines Direkt Zugriffs in der Funktionskomponente TManJustage Wie bei Il 3 1 gefordert wurden alle nicht zustandsver ndernden Methoden als const member functions deklariert Bei der neuen Manuellen Justage sind dies alle Is Has Can Calc und Get Methoden des OOD Modells S mtliche Parameter die keine Referenz darstellen wurden mit const gekennzeichnet Seite 72 m_MotorListTMotorData m_InkDetectorTOnebDimbDetector m_Channelint Pm Motor oun INT m_Detectorld char 50 m_IsMeasuring
158. eschwindigkeit else return MoveErr istin Bewegung m_Motor gt StartMove Bewegung starten aValid true Methode wurde bis zum Ende ausgef hrt return NoErr ausgelagert aus TMotorSteeringDlig StartMove ERGEBNIS Abb 11l 7 Konstruiertes Beispiel f r die Auslagerung eines F Blocks in eine Do Methode Typ3 Die eigentliche Dekomposition ist mit diesem Schritt erfolgt Alle Programmfunktionen sind damit von den oberfl chenspezifischen Programmcodeelementen getrennt Jede weitere Arbeit am Programmcode ist optional kann aber den Austausch der Nutzeroberfl che erleichtern Es entstehen die aus II 2 5 bekannten Can Methoden zum einfachen Auslesen des Programmzustandes und zur Anpassung der Nutzeroberfl che an diesen v Abschlie endes Kompilieren Linken und der Regressionstest sichern dass korrekt gearbeitet wurde 8 Erzeugung von CanDo Methoden optional Alle Anweisungen vom Anfang eines Do Methodenrumpfes bis vor die erste zustandsver ndernde Anweisung d h Aufruf von zustandsver ndernden Methoden nderung von Attributen Parametern sowie lokalen oder globalen Variablen sind potentielle Anweisungsfolgen f r eine CanDo Methode Die Initialisierung von lokalen Variablen und Ausgabeparametern ist nicht als zustandsver ndernde Anweisung zu betrachten Ausgabe parameter sind hierbei Referenzparameter deren bergebener Wert in jedem Fall berschrieben wird und die nur der R ckgabe von Werten dienen z B
159. essung erforderlich Der Bereich Diffraktometrie Reflektometrie ben tigt den PSD Offset der bei der Topographie nicht verf gbar sein darf Die m urspr nglichen Dialogfenster definierten Tastenkombinationen wurden f r wichtige Steuerelemente wieder bernommen Inhaltlich hn liche Steuerelemente oder Elemente die im Arbeitsprozess in st ndigem Wechsel benutzt wer den wurden gruppiert Gr en und Abst nde wurden vereinheitlicht Freifl chen vermieden Die Mitarbeiter des Physikalischen Institutes akzeptierten die entwicklerseitigen Vorschl ge und w nschten zus tzlich die Aufteilung des Hauptdialogs damit die wichtigsten Antriebsparameter von drei Antrieben gleichzeitig sichtbar sind Die vorhandene horizontale Bildlaufleiste zur Anzeige der aktuellen Antriebsposition bzgl der minimal und maximal m glichen Positionen war beizubehalten Diese Treffen hatten auch eine Erweiterung der Produktfunktionen zur Folge Es sollten der Zustand und Inhalt der Steuerelemente bei jeder nderung gesichert werden So ist der letzte g ltige Zustand nach einem Programmabsturz wiederherstellbar Als Ergebnis entstanden sechs Oberfl chen Prototypen welche die ermittelten Unzul nglich keiten auf unterschiedliche Weise beheben siehe M16 Vorschlag 1 bis 6 Es resultierten drei sehr komplexe Oberfl chenfenster aus der gleichzeitigen Anzeige von drei Antrieben siehe z B Abb 1 10 oben Mit mehr als 90 Steuerelementen allein 29 pro Ant
160. etAngleDest Dazu ist eine Methode CanSetAngleDest notwendig weil im Funktionsteil des Pflichtenheftes eine Bedingung zum Setzen der Sollposition aufgef hrt ist siehe Abb II 17 Grundlagen Die Sollposition ist nur im Direktbetrieb erforderlich Dort gibt sie an wohin sich der Antrieb bewegen soll Die Sollposition besteht wie die stposition auch aus der Absolutposition des Antriebs verschoben um einen Offset Damit ist die Sollposition auch abh ngig von dem Offset f r lt Antrieb gt und der Relativen Null weil diese intern ber das Offset abgebildet werden Bedingung Der Antrieb darf sich nicht bewegen und der Direktbetrieb muss ausgew hlt sein Abb 11 17 Auszug aus dem Funktionsteil des Pflichtenheftes M15 c Methoden zur Realisierung der Funktionalit t Jeder F lt ff gt Eintrag im Funktionsteil des Pflichtenheftes ist eine potentielle Do Methode Da dort jedoch die gesamte Programmfunktionalit t beschrieben wird muss sich nicht jeder Eintrag auf die Funktionskomponente beziehen Es k nnte s ch auch um allgemeine Anforderungen an die Benutzeroberfl che handeln Andererseits k nnen mehrere Eintr ge in einer parametrisierten Do Methode zusammengefasst werden Die Signatur ist stets abh ngig von der verbalen Spezifikation im Pflichtenheft und kann deshalb nicht allgemeing ltig daraus konkretisiert werden Wenn die Ausf hrung solch einer Funktion an Bedingungen gekn pft ist sollte eine CanDo Methode ers
161. ewegung fortsetzen starten or Bewegung abwarten SZ Schrittbetrieb testen g GO Schrittbetr w hlen und weite eingeh a Schritt r ckw rts ni ci Bemegung stoppen a Schritt vonw rts ag GO Bewegung abwarten Abb 11 58 Ausschnitt aus dem CTE Diagramm zum Test der Nutzeroberfl che der neuen Manuellen Justage Die drei vorgestellten Kategorisierungen sind untereinander nicht disjunkt Es ist demnach m glich diese f r ein Steuerelement zu kombinieren um die Beschriftung den Systemzustand und den Zustand des Elementes freigegeben bzw gesperrt und ausgegraut gleichzeitig zu Seite 92 Dekomposition beim Forward Engineering Il 5 Testphase beschreiben In Abb 11 58 ist das Steuerelement zur Auswahl eines Antriebs in Form eines Kombinationsfeldes dargestellt Die Testdaten umfassen dort die aktuelle Beschriftung C_D der Zustand C_D und dem Zustand des Antriebs 21 F r den Hauptdialog wurden insgesamt 93 Testf llen mit jeweils 35 Testdaten definiert Die ersten 57 Testf lle sichern dass die Steuerelemente in den drei Teilbereichen vollst ndig korrekt und fehlerfrei verkn pft sind Es werden alle mit einer Funktion belegten Steuerelemente n allen drei Teilbereichen in verschiedener Reihenfolge getestet Danach folgen 21 Testf lle die Wechselwirkungen zwischen den Teilbereichen siehe M23 z B Antriebe in anderer Reihenfolge ausw hlen und die Fehlertoleranz M23 z B versuchen Antrieb dop
162. exen Operationen d h Do Methoden getestet Diese bewirken im XCtl System eine Zustands nderung der angeschlossenen Hardware Bei der neuen Manuellen Justage ist dies das Starten oder Stoppen einer Antriebsbewegung und die programmgesteuerte Durchf hrung einer Halbwertsbreitenmessung siehe Abb II 55 EZ In der Testoberfl che werden alle Do Methoden durch Schaltfl chen repr sentiert da s e alle keine durch den Nutzer manipulierbaren Parameter besitzen Die Bewegungsparameter werden ausschlie lich aus den Objekt Attributen gelesen die zuvor mit Set Methoden eingegeben wurden Dazu wurden die Bewegungen erst an einen Antrieb und danach an mehreren Antrieben gleichzeitig durchgef hrt 11 5 2 Test einer Nutzeroberfl che Die Nutzeroberfl che entspricht der ffentlichen Schnittstelle ber die der Anwender mit dem Programm kommuniziert Bei den Testaktivit ten steht die Bedienung der Oberfl che m Mittelpunkt In 11 3 2 wurde bereits erl utert dass die Eingaben des Anwenders bei botschaftenbasierten Systemen in Nachrichten an das Programm bersetzt werden Beim XCtl Projekt sind dies Windows Botschaften an Dlgq_OnCommand der entsprechenden Fensterklasse Dort werden anhand der Parameter das benutzte Steuerelement und das eingetretene Ereignis dentifiziert und verarbeitet Die Botschaftenbehandlungsroutinen k nnen somit nicht direkt aufgerufen und getestet werden Es muss immer der Umweg ber das Betriebss
163. ezialisierung der Attribute In den Designdokumenten konnten die in den anderen Subsystemen verwalteten Daten abgelesen werden In Folge dessen wurden einige Attribute aus dem OOA Modell entfernt z B m Angle f r die Istposition Der Typ f r alle brigen Attribute musste nicht aus dem Produktmodell abgeleitet werden Aufgrund der Programmcoden he der Reengineering Dokumente war dieser dort direkt ablesbar So wurde z B das Attribut m_AngleDest zu double m_AngleDest pr zisiert Durch die im Pflichtenheft aufgef hrten Beziehungen zwischen Istposition UD 50 Sollposition D 110 Schrittweite D 150 und Offset D 90 wurde der gemeinsame Typ typedef double TAngle f r alle Winkelangaben erkannt und definiert Um die Attribute besser vor direkter Manipulation von au en zu sch tzen wurden alle private deklariert Da diese Vorgehensweise Bestandsteil eines guten objektorientierten Designs sein sollte war sie bereits im OOA Modell geplant Ausdruck dessen sind die dort eingef hrten Get Set Methoden die nun weiter verfeinert werden mussten b Signatur f r Accessor und Mutator Methoden F r alle unter a konkretisierten Attribute ist der R ckgabewert der entsprechenden Get Methode zu vervollst ndigen Daf r wird der Typ des Attributes bernommen F r GetAngleDest ergab sich TAngle GetAngleDest int BOOL amp Der erste Parameter st der Index des Antriebs m Motorsteuerungs Subsystem dessen Sollposition ausgelesen
164. fassung Obwohl im Falle der neuen Manuellen Justage mehrere Dialogfenster auf die Funktionskomponente zugreifen konnte dennoch die Polling Variante gew hlt werden Dies war m glich weil alle Oberfl chenklassen modale Dialogfenster repr sentieren und damit nicht gleichzeitig auf die Funktionskomponente zugreifen k nnen Die horizontale Konsistenz muss so nur beim Verlassen eines Dialogfensters beachtet werden Zum Vergleich wurden beide Varianten Observer Muster und Polling Variante entworfen und sp ter implementiert Zu diesem Zeitpunkt st nur ein marginaler Unterschied zwischen Observer Muster und der Polling Variante ersichtlich Er beschr nkt sich fast ausschlie lich auf die Kommunikation zwischen Funktionskomponente und Nutzeroberfl che vgl Abb 11 37 Observer und Abb II 36 Polling Die Erweiterung des OOA Modells zu einem OOD Modell gestaltete sich unproblematisch Hier zeigten sich klar die Vorz ge der Objektorientierung Verursachte die Dekomposition bereits im OOA Modell eine erh hte Komplexit t so hat sich dieser Trend leider auch in der Designphase fortgesetzt Bei einem Vergleich von Abb II 19 OOA und Abb II 22 OOD ist besonders auff llig dass ein Gro teil der Attribute entfernt wurde Wie bei II 3 1 erw hnt konnte deren Verwaltung in den benutzten Subsystemen identifiziert werden Die f r den Zugriff geplanten Methoden sind erhalten geblieben statt Accessor Methoden die direkt auf die Attribute zugr
165. fgerufen werden Alle nutzeroberfl chen unabh ngigen Teile k nnen dann zus tzlich in die entsprechende Can Methode aufgenommen werden wenn sie nicht zustandsver ndernde Anweisungen darstellen und bei JEDEM Aufruf der Do bzw Set Methode auf die gleiche Weise berpr ft werden Wenn noch keine Can Methode vorhanden ist sollte eine erstellt werden Die Do bzw Set Methode bleiben unver ndert siehe Abb US Zwischenstand 3 Sie muss false zur ckgeben wenn die Do bzw Set M nicht ausgef hrt werden darf Seite 112 Dekomposition beim Reengineering Ill 2 Restructuring Nur wenn die Can Methode vor der Auslagerung der Bedingung en noch nicht existierte d rfen diese durch Aufruf und Auswertung der Can M ersetzt werden siehe Abb II 8 Ergebnis Wenn bereits eine Can M vorhanden war darf nicht ersetzt werden Grund sind die bereits in der alten Can M aufgef hrten Bedingungen Diese f hren zu zus tzlichen Einschr nkungen die u U zu Fehlern f hren k nnten s kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Fenster f r Druckerwartung void TPrinterServiceDlg OnPrintTestPage Versuch Testseite zu drucken iL m Printer Tmoerviee Iim Printer ISPrinting return De m Printer 1 o arti SE N 1m Printer HasPaper return m Statusfield SetText Testseite wird gedruckt DoPrint m_Printer gt GetTestPage ve kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
166. fl che zu Beginn der Testaktivit ten f r die Funktionskomponente noch nicht fertig war wurde eine separate Testoberfl che erstellt Diese ist dabei Testtreiber und Objektzustands Initialisator zugleich Die Aufgaben von Botschaften Generator Auswerter und Testmonitor siehe oben waren hingegen nicht automatisierbar Grund daf r ist die sehr gro e Anzahl von Testf llen und daten welche die Entwicklung eines automatischen Testverfahrens in angemessener Zeit nicht m glich machte Zudem h tte die umfangreiche Implementierung selbst wieder getestet werden m ssen Dekomposition beim Forward Engineering Il 5 Testphase Seite 87 Das Hauptmerkmal einer guten Testoberfl che ist die einfache Gestaltung und Implementierung Aufgabe ist die Ansteuerung aller public Methoden der Funktionskomponente und dabei jede zus tzliche Oberfl chen Funktionalit t zu vermeiden Obwohl diese sehr komplex wirkt Abb II 56 hat sie im Vergleich zum Hauptdialog Abb II 10 oben deutlich weniger bedienbare Steuerelemente So ist die Implementierung weniger komplex und fehleranf llig Der Grund ist dass im Hauptdialog fast alle Funktionen in den drei Teilbereichen nahezu identisch vorhanden sind Zudem gibt es keine Adressierungsprobleme wie im Hauptdialog d h Funktionen werden statt im ersten im dritten Teilbereich ausgel st die Werte werden im falschen Teilbereich aktualisiert Der Quellcode der Klasse TManJustageTestDlg umfasst mit 233 LOC nur ca 1
167. flichtenheftes eine Aktualisierung eines Steuerelementes fordert wird stattdessen eine der soeben angesprochenen Methoden gerufen die die Funktion bernimmt Diese Vorgehensweise sicherte die unten vorgestellte Geschwindigkeitsoptimierung Punkt eins und sechs Dekomposition beim Forward Engineering IA Implementierungsphase Seite 77 Aus den bereits bei der Funktionskomponente angesprochen Gr nden traten w hrend der Vorstellung der neuen Manuellen Justage w dererwartend Probleme mit der Ausf hrungs geschwindigkeit auf Von Seiten der Oberfl che wurden folgende nderungen durchgef hrt Der fl ssige Arbeitsablauf wurde nach dem Starten Stoppen einer Antriebsbewegung zun chst durch die Oberfl chenaktualisierung behindert Der Aufruf der Methoden die f r die Anpassung der Steuerelemente zust ndig sind f hrte zu vollst ndiger Prozessorauslastung was die Bedienung des Dialogfensters f r einige Augenblicke behinderte Zur Behebung wurden die Methoden Notice und Dlg_OnEvent eingef hrt Anstatt des direkten Methodenaufrufs wird nun per Notice eine entsprechende benutzerdefinierte Windowsbotschaft an das Dialogfenster geschickt Diese kommt in Dlg_OnEvent an wo wieder die eigentliche Aktualisierungsmethode gerufen wird Weil die Queue f r benutzerdefinierte Botschaften neben der Kommandoqueue existiert k nnen die dar n enthaltenen Steuerelement Ereignisse parallel verarbeitet werden Die Bedienung des Dialogfensters i
168. ft als Ausgangspunkt entstanden die Oberfl cheklassen Die Implementierung des Hauptdialogfensters war durch die Geschwindigkeitsoptimierungen und die vielen Steuerelemente sehr aufwendig 1 103 LOCo und besitzt mit etwa 19 LOC einen etwas komplexeren durchschnittlichen Methodenumfang als die Funktionskomponente Darin enthalten sind jedoch fast 50 Kommentierung TCRo 44 und zahlreiche Leerzeilen zur bersichtlicheren Gestaltung der Methoden TMandJustage Ly TMotorData TManJustageDlg TMotorOffsetDlg Tree rrsernlg Tab Hd Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Polling Variante nach Abschluss der Implementierungsphase Bei der Integration der neuen Manuellen Justage in das XCtl Programm zeigte sich dass wirklich nur die Nutzeroberfl che nach au en sichtbar sein muss Bei der Verkn pfung des XCtl Programmes mit der Oberfl che der neuen Manuellen Justage musste deshalb nur MI GUTH inkludiert werden Die w hrend der Implementierungs Test und Wartungsphase anfallenden nderungen am Programmcode konnten fast immer im Vorhinein entweder auf die Funktionskomponente oder die Oberfl che eingegrenzt werden Durch die deutliche Gliederung und die konsistente Benennung der Methoden der Funktionskomponente konnten Wartungsarbeiten sogar auf die Methode genau abgegrenzt werden EE yon Obseryer NINSlerung E ONE In AnwengungsIHlE Auf die graphische Gegen berstellung dieser bei
169. g 11 3 Designphase Seite 53 Bei der Dekomposition stellt die Funktionskomponente das Konkrete Subjekt dar weil sie nderungen ihres inneren Zustands an die Nutzeroberfl che senden soll der Informationsfluss von der Oberfl che zur Funktionskomponente wurde bereits bei I1 3 3 2 erkl rt Wenn die Funktionskomponente mehrere Nutzeroberfl chen gleichzeitig ber einen Zustands bergang informieren soll ist ein Subjekt n Form einer abstrakten Klasse zu erstellen Diese beinhaltet eine Beobachter Liste und Methoden die es gestatten Beobachter Interfaces dynamisch hinzuzuf gen oder zu entfernen Die Funktionskomponente erbt so den Verwaltungsmechanismus f r Beobachter Interfaces und hat somit Kenntnis ber die assoziierten Nutzeroberfl chen Jede einzelne Nutzeroberfl che wird durch einen konkreten Observer repr sentiert und ist von einer G UlI Bas sklasse und einem Beobachter Interface abgeleitet Da Interface Vererbung keine Mehrfachvererbung darstellt ist das auch in Sprachen mit Einfachvererbung wie z B Java m glich Vorteile des Observer Musters e Es findet nur dann ein Informationsaustausch zwischen Subjekt und Beobachter statt wenn wirklich ein Zustands bergang stattgefunden hat e Bei einer Zustands nderung im Subjekt werden sofort alle assoziierten Beobachter benachrichtigt e Beim Austausch des Konkreten Beobachters z B Neuimplementierung sind alle m glichen Zustands nderungen durch das einzuerbende Beobachter
170. gnatur f r Methoden zur Realisierung der Funktionalit t Die Parameterliste dieser Methoden st v llig von der verbalen Spezifikation abh ngig und daher nicht verallgemeinerbar Nur der R ckgabewert kann wie bei b vom Vorhandensein einer CanSet Methode abgeleitet werden F r die bei c in Kapitel II 2 5 abgeleiteten Methode des Fahrbetriebs resultiert aus der Existenz von BOOL CanDoDrive it EDirecetion die Signatur BOOL DoDrive int EDirection d Kapselung fremder Funktionen und weitere Methoden Nach a liegen einige Attribute unter der Verwaltung anderer Subsysteme Die Nutzeroberfl che darf auf diese Attribute und Methoden nicht direkt zugreifen so dass n der Funktionskomponente einige zus tzliche Methoden erforderlich sind Diese kapseln das benutzte Subsystem indem sie Anfragen entsprechend weiterleiten In der neuen Manuellen Justage entstand so z B die Methoden BOOL IsMoving int welche im Motorsubsystem anfragt ob sich der Antrieb bewegt Die Benennung dieser Methoden sollte identisch zu den Methoden im Subsystem sein Bei der neuen Manuellen Justage waren vier zus tzliche Methoden erforderlich welche die Offset Berechnungen durchf hren diese aber nicht den Objektzustand ndern Sie sind deshalb nicht zustandsver ndernd und fallen in keine bislang genannte Kategorie Aufgrund ihrer Berechnungsfunktion wurden s e mit dem Pr fix Calc benannt Das Ergebnis der Anwendung der Schritte a bis d bei
171. gsphase weiterentwickelt Da sich die anzuwendende Schrittfolge jedoch nicht unterscheidet sind die Beispiele in diesem Kapitel aus der Polling Var ante Die Unterschiede zwischen Observer Muster und Polling Variante werden abschlie end in Kapitel II 4 3 1 verglichen 11 4 1 Schwerpunkte bei der Funktionskomponente Die Grundlage f r die Programmierung der Funktionskomponente bildet das in der Definitionsphase erstellte OOA und in der Designphase verfeinerte OOD Modell Wurden das zugeh rige Designdokument und das Pflichtenheft nach der n Kapitel beschriebenen Weise erstellt wird die Implementierung der vollst ndigen Funktionalit t erleichtert Die Anforderungen an Methoden und Eigenschaften von Attributen sind bereits im Designdokument festgelegt Durch zus tzliche Anmerkungen z B ber die n Methoden zu benutzenden Attribute ist dem Programmierer damit vorgeschrieben wie und was zu implementieren ist So wird verhindert dass Abweichungen von der urspr nglichen Strategie Idee f r die Funktionsweise einer Methode entstehen zumal gerade bei umfangreichen Softwareprojekten einige Zeit zwischen dem Design und der eigentlichen Codierung einer Operation vergehen kann In der Funktionskomponente sollte beim Zugriff auf andere Subsysteme besonders bei Hardwarezugriffen deren Verf gbarkeit berpr ft werden Ziel ist im Fehlerfall einen g ltigen Zustand zu hinterlassen so dass die Aufrufumgebung ber die ffentliche Schnittstelle
172. h Nur w hrend des Reverse Engineering zur Ermittlung des Ist Zustands ist die Bearbeitung in der Reihenfolge Test Implementierung Design Analyse und Definition durchf hrbar Bei der eigentlichen Dekomposition liegt der Schwerpunkt auf der Arbeit am Programmcode Die Analyse und Definitionsphase entf llt w hrend dieser Arbeit komplett und wird durch das Reverse Engineering ersetzt Das Design entsteht indirekt aus der vorgestellten Schrittfolge Die Testphase wird wiederholt am Ende jedes Schrittes durchgef hrt um die Arbeit des dekomponierenden Entwicklers zu verifizieren 1 Erstellung neuer Dateien 2 Behandlung von Ans tzen vorhandener Funktionskomponenten 3 Solldesign festlegen 4 Programmcodelayout verbessern optional 5 Neuordnung der Attribute 6 Zusammenfassen von Funktionalit tsaufrufen 7 Erzeugen von Do Methoden 8 Erzeugung von CanDo Methoden optional 9 Erstellung von CanSet und Gewinnung zus tzlicher Bedingungen f r CanDo Methoden optional 10 Entfernen gleicher Do CanDo Methoden 11 Kennzeichnung nicht zustandsver ndernder Methoden und konstanter Parameter optional 12 Suche und Korrektur von Fehlern optional 13 Abschluss durch Fein und Abnahmetest 14 Dokumentation des entstandenen Designs Der dadurch entstehende Programmcode ist im dekomponierten Subsystem fast immer wesentlich umfangreicher als der des urspr nglichen Subsystems Das resultiert aber nur aus der Aufteilung
173. h hier ist das eigentliche Observer Muster zu verwenden da die Herstellung der horizontalen Konsistenz der Nutzeroberfl chen h here Priorit t hat als die Verringerung des Umfangs des Programmcodes Dies bedeutet dass f r jede einzelne Verkn pfung einer Funktionskomponente mit einer Nutzeroberfl che ein Beobachter Interface in das Design zu integrieren ist Abb 11 33 Seite 62 Dekomposition beim Forward Engineering II 3 Designphase interface interface Kierf Iiferft OnRefrashtlT Refteshinfto ll void QnRefreashzrTRefteshinftoz void RS A A Oz TAI ii D a a i BE Fu Ze Oberfli Obert Ka e m_inkFunkt1 TFunkti m_InkF unkti TFunkti E Pi es EE KEE ER es l OnrRefresh1 TRefreshlnfot vold E N 01 m_InkFunkti 01 m_InKFunktz N TFunkt1 TFunkt EEN wun Pm InkOberttIObert m_Ink berl l ber Hinzufuegendl beri Y yald Entfernendl berli void HinzufuegendlOber void EntfernendlObemMz void Benachrichtigend void HBenachrichtigen woic Abb 11 33 Bsp f r Observer Muster bei 2 2 11 3 4 Aufbau von Designdokumenten Um Missverst ndnisse zwischen dem OOD Entwickler und dem Programmierer zu verringern empfiehlt sich die Erstellung eines Designdokumentes Dieses sollte alle w hrend der Designphase entstandenen Diagramme z B Klassen oder Interaktionsdiagramme und deren verbalen Beschreibungen zusammenfassen So werden die Vorstellungen des OOD
174. h um Elementen des funktionalen Tests Black Box Testverfahren siehe 3 S 426ff erg nzt werden Dies betrifft die Gewinnung von zus tzlichen Testdaten und f llen aus der Spezifikation Neben den direkt ableitbaren Testf llen k nnen zus tzliche mittels Grenzwertanalyse und quivalenzklassenbildung siehe 3 S 427ff bzw 431ff gewonnen werden Die Grundlage f r den Test von Funktionskomponenten bilden ausgew hlte Schritte eines Testverlaufs f r objektorientierte Komponenten zusammengetragen aus 3 Kapitel 5 13 1 e Durch quivalenzklassenbildung und Grenzwertanalyse werden aus den Parametern Testf lle abgeleitet Das Objekt muss vorher in einen f r diesen Testfall zul ssigen Zustand versetzt werden aus 3 Seite 489 Schritt 2a e Dann wird jede Operation einzeln getestet Zuerst sollten nicht zustandsver ndernde Methoden berpr ft werden nach 3 Seite 489 Schritt 2 e Anschlie end werden die zustandsver ndernden Operationen getestet nach 3 Seite 489 Schritt 2 Nach jeder Operationsausf hrung muss der neue Objektzustand gepr ft und der oder die Ergebnisparameter mit den Sollwerten verglichen werden nach 3 Seite 489 Schritt 2b e Danach folgt der Test jeder Folge voneinander abh ngigen Operationen innerhalb der Klasse Alle potentiellen Verwendungen einer Operation sollte unter praktisch relevanten Bedingungen ausprobiert werden nach 3 Seite 489 Schritt 3 Dekomposit
175. haffung eines bestimmten Vorzustandes und e einem Testmonitor zur Protokollierung der Ausf hrungsfolge von Operationen Wenn Botschaften Generator bzw Auswerter nicht automatisierbar sind empfiehlt sich die Verwendung einer Testoberfl che m Falle der Funktionskomponente 1 d R die sp tere Nutzeroberfl che Es ist jedoch m glich dass diese noch nicht in ihrer endg ltigen Form vorliegt oder aufgrund ihrer Komplexit t nicht f r diesen Einsatz geeignet st Dann kann f r 3 eine separate Testoberfl che erstellt werden wenn der daf r aufzubringende Mehraufwand abgewogen wird Durch den Einsatz der Testoberfl che wird sichergestellt dass eine vollst ndig getestete Funktionskomponente f r den Test der eigentlichen Nutzeroberfl che bereit steht Zum Beginn des eigentlichen Testes 4 m ssen die erforderlichen Objekte Systemkomponente benutzte Subsysteme Test Nutzeroberfl che und Funktionskomponente instanziiert und gezielt initialisiert sein Bezogen auf die Struktur der Funktionskomponente befasst sich Punkt 5 ausschlie lich mit Get Is Has Can M Punkt 6 nur mit Mutator Methoden Set M und Punkt 7 mit Do Methoden und dem brigen ungetesteten Teil der ffentlichen Schnittstelle Anwendungsfall Manuelle Justage Der Test erfolgte nicht an den Messpl tzen im Physikalischen Institut d h ohne angeschlossene Hardware Die Reaktionen der Antriebe und Detektoren wurden durch Subsysteme des XCtl Sys
176. he Abb 11 38 21 Damit war z B eindeutig erkennbar welche Aspekte der Pflichtenheftfunktion F 70 n die Methode DoDirect zu integrieren waren siehe Abb II 39 gt BOOL DoDirect const int PUBLIC l st Antriebsbewegung im Direktbetrieb aus der erste Parameter ist der Index des Antriebs in der Antrielt etztm IsMoving siehe M8 Funktion F 70 Abb 11 38 Auszug f r einen Methoden Eintrag aus dem Designdokument M21 F 70 Starten der Bewegung im Direktbetrieb Nach der Beschleunigungsphase bewegt sich der Antrieb mit der angegebenen Geschwindigkeit um kurz vor dem Ziel abzubremsen und an der Sollposition zu halten Wenn die Sollposition gr er bzw kleiner ist als die stposition bewegt sich der Antrieb vorw rts bzw r ckw rts Die maximale Abweichung zwischen der angefahrenen und der gew nschten Sollposition darf maximal DeathBand betragen Wenn Ist und Sollposition bereinstimmen findet keine Bewegung statt Die Genauigkeit betr gt hier wiederum DeathBand Bedingung Der Antrieb darf sich nicht bewegen Wenn eine Sollposition eingegeben wird die au erhalb des zul ssigen Wertebereichs liegt so wird die Positionsangabe auf die minimal oder maximal zul ssige Position korrigiert je nachdem ob der zul ssige Wertebereich unterschritten oder berschritten wurde Abb 11 39 Auszug aus dem Funktionsteil des Pflichtenheftes M15 Durch die in Abb II 39 angegebene Bedingung war im OOA eine
177. he behindert dieses durch die schwer anzusteuernde Ereignisgenerierung von Nutzerinteraktionen Den Ansto f r die Dekomposition von Anwendungen bildet die Wi ederverwendbarkeit der Funktionskomponente mit dem daraus entstehenden wesentlichen Vorteil die Nutzeroberfl che einfach austauschen zu k nnen Jede neu entwickelte Klasse der Nutzeroberfl che beschr nkt s ch nur auf d e Verkn pfung der Nutzerinteraktionen mit der von der Funktionskomponente bereitgestellten Funktionalit t Da diese unver ndert bleibt kann die Bas sfunktionalit t als Fehlerquelle ausgeschlossen werden Damit beschr nkt sich die Fehlersuche bei einer neuen Nutzeroberfl che wirklich nur auf die Nutzeroberfl che Es hat sich gezeigt dass die in Kapitel I 4 erl uterte allgemeine Motivation f r die Dekomposition sich vollst ndig best tigt hat Sowohl beim Forward als auch beim Reengineering konnten alle dargelegten Vorteile nachgewiesen und wie erwartet umgesetzt werden Aus Sicht der Autoren stellt die Dekomposition stets eine Verbesserung der Softwareentwicklung dar da sie sich sowohl auf den Entwicklungsprozess als auch die Eigenschaften des Produktes positiv auswirkt Dekomposition hat stets verbesserte Strukturierung des Programmcodes zur Folge Dies gilt auch f r die Artefakte der Softwareentwicklung Wie in dieser Arbeit gezeigt l sst sich auch die Struktur dieser Dokumente verbessern Wird zus tzlich eine starke Formalisierung innerhalb der Artefak
178. hnen 38 C Classihication Tree WE 85 Computer Aided Software knoineering 18 Kegel ee Siehe Konkreter Beobachter Concrete Sub eCie EE EE E TEE E EET E Te Siehe Konkretes Subjekt A U EE EE Siehe Classification Tree Editor EA E 31 D Dekom posi ee senken Bei Zu RI Rue ee Bu 2 Delegation ee ne una Re un Re ns en re ee 51 Dialog OM eTM e BU EEN 30 SOHSet E MT KEE EE 30 10pP02raphie Durchfuhrune u a u A EEA AAEN A E E NE AT 101 1 0pP02r amp phie Einstellungen esse erahnen 101 neue Manuelle Ir 30 Test der neuen Manuellen Justage 00220000002200002sneennnsnnnennnnnnneenessssennnnnnsennnnnnssessessseesnnssssessnenn 87 urspr ngliche Manuelle Justage a urn ae ae 18 F E TE 106 Iormale ASSOZAU ON u ee ee lasse Be Base thesis Mensen Metern 50 Forward NM EE TEE 3 Funktionskomponente u ren ei eek 2 e BE VON a a a 104 G Gliederung H EE e E een EEEE EE A4 Produktorienlierie E A4 Graphical User Interface 22 22 00 a een 9 Anhang C Stichwortverzeichnis Seite 145 H hierarchische Softwarearchitektur Komplexit tsbew ltigung 0000000nnnnnnnennnssossseoeeernnnnsssssssssserrrressssssssss 10 Hilfe System aktives teilen ee 31 dynan se NES oia ET EA een NEE EA E ee 31 ie fe re TEEN 31 Dass ves ee 31 E RENE EE EE 31 DOE 2 u Rue dE E 31 Euren Siehe Oberfl chenprototyp K Konkreter Beobachter z2 002022202220000000200eneeosnnnnneennensnnnnnnenneeosnnnnnennee
179. iche Ergebnis das sich zudem durch eine einheitliche und hohe Robustheit auszeichnet Dabei l sst sich die Basisfunktionalit t anhand des Do Methoden Pr fixes leicht lokalisieren Diese Richtlinien f hren beim Forward und Reengineering zwangsl ufig zu einer besseren Verteilung der Komplexit t auf mehrere Methoden und zu einer daraus resultierenden hohen bersichtlichkeit Der Unterschied besteht nur in der Herangehensweise Beim Neuentwurf entsteht dies schrittweise und phasenorientiert aus der Produktspezifikation wo hingegeben beim Reengineering die vorhandene Komplexit t restrukturiert und verteilt wird Klassenkonstrukt mit Methoden und Attributen Referenzparameter verwendetet aber optional Zugriffsschutz f r Attribute und Methode Methoden mit R ckgabewerten Kennzeichnung nicht zustandsver ndernder Methoden und konstanter Parameter Klassenvererbung automatische Ereignisgenerierung Timer f r Kommunikationsmuster Polling Interfacevererbung mit abstrakten Methodendeklarationen f r Kommunikationsmuster Kapitel IV Gesamtfazit Eine deutliche phasenorientierte Bearbeitung ist hier unm glich siehe III 2 weil sich die Schrittfolge vorrangig auf die Implementierung bezieht Gleiches gilt auch f r die Arbeitsteilung die nur bei der Dekomposition von Subsystemen beim Forward Engineering anwendbar ist Die wesentlichen Nachteile der Dekomposition sind in beiden Softwareentwicklungsprozessen die verschlechterten_ Laufze
180. ichen Gliederung um die ben tigten Informationen schnell nachzuschlagen eine produktorientierte Gliederung Es werden alle Anzeigen und Produktfunktionen in der Reihenfolge beschrieben wie sie sich aus der Struktur des Programmes ergeben Im Gegensatz zum Trainings Handbuch k nnen und m ssen alle Informationen m Referenz Handbuch deutlicher gegliedert werden Durch die Verwendung von Querverweisen k nnen unbekannte Begriffe schnell nachgeschlagen werden Trainings und Referenz Handbuch k nnen auch in einem Benutzer Leitfaden kombiniert werden wenn die Anwendergruppen in ihrem Wissen stark differenzieren Wissen bezieht sich Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 35 hier sowohl auf den Umgang mit Softwaresystemen im Allgemeinen als auch auf das fachliche Wissen ber die Aufgaben die durch das Programm unterst tzt werden Anwendungsfall Manuelle Justage Weil die Manuellen Justage zum einen regelm ig durch die Mitarbeiter des Physikalischen Institutes als Experten und zum anderen durch Studenten einmalig im Rahmen ihres Prakti kums benutzt wird musste ein Benutzer Leitfaden erstellt werden mit einem Trainingsteil f r die Studenten und einem Referenzteil f r die Mitarbeiter des Physikalischen Institutes Begonnen wurde mit der Einleitung und einer kuren Einf hrung in den Gegenstandsbereich der Manuellen Justage Anschlie end wird eine Kapitel bersicht gefolgt von einer Pro
181. ichtenheft das nach IZ entstanden ist empfehlen die Autoren das Oberfl chen Prototyping direkt auf dem Pflichtenheft aufzubauen Grundanliegen ist dass so wieder fr h Missverst ndnisse zwischen den beiden Parteien aufgedeckt und gekl rt werden k nnen Dadurch m ssen nur Pflichtenheft und Oberfl chenentw rfe ge ndert werden nicht aber das OOA Modell weil dieses nun erst nach dem Prototyping entsteht ausf hrlich diskutiert bei II 2 6 Zur Ableitung der Oberfl chenfenster existieren allgemeine Regelwerke Ein so gewonnener Oberfl chenentwurf bildet aber nur die erste Grundlage F r die Anordnung der Steuerelemente ist zudem das Verst ndnis ber das System und die damit realisierten Aufgaben unerl sslich Die Anspr che der Anwender an die zuk nftige Nutzeroberfl che m ssen ebenfalls Beachtung finden Dazu s nd die Notizen m Kapitel Benutzeroberfl che des Pflichtenheftes zu verwenden Nach Abstimmung der Oberfl chen Prototypen mit dem Auftraggeber Anwender steht die zuk nftige Nutzeroberfl che im Wesentlichen fest Nun kann nach Il 2 1 die Ersetzung der Notizen durch die Beschreibung des gew hlten Oberfl chenentwurfs erfolgen Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 29 Anwendungsfall Manuelle Justage Zu Beginn musste die existierende Nutzeroberfl che unter dem Gesichtspunkt der Software Ergonomie analysiert und kritisch bewertet werden Der erste Kontakt mit dem urspr ng
182. ie Eingabeparameter siehe 9 Von den im Fehlerdokument siehe M34 bereits vorhandenen 15 Fehlern konnten weitere 12 beseitigt werden Dies umfasst das Entfernen von Totem Code die Beseitigung redundanter Operationen und die Anpassung von Variablentypen Um die Software Ergonomie zu verbessern wurden die Ressourcen der beiden Fenster berarbeitet Dies beinhaltet die Minimierung von Freifl chen die Ausrichtung an Fluchtlinien und die Gruppierung von Steuerelementen Die Verhaltensspezifikationen der Analysephase konnten unver ndert bleiben da sie nur allgemeine Verfahren zur Topographie beinhalten Eine Anpassung wird erst dann n tig wenn die Nutzeroberfl che v llig neu gestaltet wird Aus Sicherheitsgr nden ist die urspr ngliche Topographie unver ndert im XCtl System verblieben Die Fehler wurden nur in der dekomponierten Version entfernt Die korrigierten Fehler sind im Fehlerdokument siehe M34 nicht entfernt sondern besonders gekennzeichnet 13 Abschluss durch Fein und Abnahmetest Aufgrund der vielen Korrekturma nahmen am Programmcode und der ge nderten Funktionalit t bzgl des Eingabeverhaltens wurde vor dem eigentlichen Abnahmetest ein Feintest durchgef hrt Das Subsystem Topographie wurde funktional gegen die Spezifikation Black Box Testverfahren getestet Zur berpr fung des Verhaltens bei Eingaben innerhalb und au erhalb der jeweiligen Wertebereiche entstand ein CTE Diagramm mit 35 Testf ll
183. ie Jl Dee Sir EL ame RELATIVE MULL C Fahrbetrinb Is Get Heumann Schaiibeisch Autaben Zort Im i DI Is GecHococloung OI LFF i Here LaflLizsc MAPi i J r MoeroelLize 1 sm Lnkfliocoere s Nee HocorListc Liv AxiaType m Lp Liac P arsing xis i speine2i Horortgd ratocid Mee Goeeld J apropie Hosoebises ij m Rorcor Id Hosoelcdae vd Ing d dim ER EE BerrctLebanrrt Lex TZ EE ER n m l E H ve ps EET 8 As ETa m m mn mua S d Funktionskomponente j e i ml entsprechend dem aktuellen Entwicklungasstand nen m en SEE ee Abb E Evolution der Nutzeroberfl che Oberfl chen Prototyping Einf hrung 1 4 Motivation Seite 13 Ein weiterer Grund f r die Dekomposition sind multilinguale Anwendungen Dabei stehen mehrere Nutzeroberfl chen in verschiedenen Sprachen zur Steuerung der gleichen Programmfunktion zur Verf gung Nur die Fenster unterscheiden sich in der Beschriftung der Steuerelemente Aufgrund der sprachspezifischen Eigenheiten z B sehr gro e Wortl nge k nnen sie auch in der Gestaltung variieren Die programmiersprachliche Einbindung mehrerer Nutzeroberfl chen ist erforderlich wenn die Oberfl chenelemente nicht dynamisch eingebunden werden k nnen was einige GUI Bibliotheken heute bereits unterst tzen z B das Ressourcen Konstrukt in C Aber auch dann m ssen Meldungsausgaben oder dynamische Beschriftungen oft verstreut im gesamten Quelltext gesucht und
184. ie h tte f r jedes der 71 Steuerelemente zu einer separaten Behandlungsroutine verzweigen m ssen Beides h tte den Nachteil dass die nahezu identisch zu behandelnden Teilbereiche separat zu implementieren w ren Daher wurden bereits im OOD mehrere kleine Methoden zur Verwaltung der Teilbereiche und der darin enthaltenen Steuerelemente geplant die eine f r alle Teilbereiche generalisierte Implementierung erlauben siehe Abb II 48 Dekomposition beim Forward Engineering IA Implementierungsphase Seite 75 void TManJustageDlg Dlg_OnCommand HWND aHWnd int ald ENEE ele pr fe zuerst die Steuerelemente in den Teilbereichen diese wurden in drei Gruppen aufgeteilt LINKS Auswahlliste Antrieb Betriebsarten MITTE Start Stop und Betriebsarten wenn ENTER gedr ckt wurde RECHTS Relative Null setzen aufheben Offset setzen wird das entsprechende Steuerelement zu ald gefunden gibt die Check Methode TRUE zur ck ETB tb ETB 0 nur so gibt TB_Next beim ersten Aufruf tb1 zur ck while TB_Next tb pr fe der Reihe nach die Teilbereiche if TB_CheckLeft tb ald TB_CheckMiddle tb ald TB_CheckRight tb ald aCode ONEXIT amp amp TB_CheckExit tb ald return pr fe dann die Steuerelemente au erhalb der Teilbereiche EE Ee default Ee EE ee ele Abb 11 48 Nutzung von Methoden zur Verwaltung der Teilbereiche Auf die Vorstellung einer oberfl chenspezifischen Fun
185. iert zu werden v Zum Abschluss dieser Schrittfolge m ssen die nach dem Kompilieren und Linken angezeigten Hinweise und Warnungen korrigiert werden Ein Regressionstest sollte sich anschlie en Die wichtigste Grundregel bei dieser Schrittfolge ist so wenig wie m glich am Programmcode zu ndern Das verhindert versehentliche nderungen am eigentlichen Programmverhalten 13 Abschluss durch Fein und Abnahmetest Nach Abschluss aller Implementierungsarbeiten sollte ein Black Box Testverfahren der gesamten ber die Oberfl chenfenster steuerbaren Funktionalit t des dekomponierten Subsystems durchgef hrt werden Damit wird sichergestellt dass das Programmverhalten auch nach der Dekomposition weiterhin der Spezifikation entspricht Seite 114 Dekomposition beim Reengineering Ill 2 Restructuring 14 Dokumentation des entstandenen Designs Erst w hrend der Schrittfolge kristallisieren sich Attribute und Methoden der Funktionskomponente und Nutzeroberfl che heraus Mit Abschluss dieser Arbeiten kann durch Reverse Engineering aus dem Programmcode ein Designdokument erstellt werden Dort h lt der dekomponierende Entwickler die endg ltige Schnittstelle mit eigenen Anmerkungen versehen fest Diese Dokumentation ist f r den sp teren Austausch der Nutzeroberfl che sehr wichtig Anwendungsfall Manuelle Justage Um die Dekomposition auch im Reengineering durchzuf hren und gleichzeitig einen Vergleich zu einem Neuentwurf herzuste
186. ierung der Funktionalit t und bilden etwa 50 des Programmcodes Trotz des guten Kommentierungsgrades TCR 25 sind diese Aufrufe kaum beschrieben Die Aktualisierung der Oberfl che hingegen ist fast zu ausf hrlich und der Zugriff auf Attribute und Methoden innerhalb der Manuellen Justage ist teilweise sogar falsch kommentiert Da der Programmcode durch die Schrittfolge n mehreren P ssen intensiv analys ert und schlie lich modifiziert wird ist genaueres Wissen hier noch nicht sinnvoll Nur ein allgemeiner berblick ber das aktuelle Design siehe M24 und wie beim Forward Engineering auch die Seite 100 Dekomposition beim Reengineering Ill 1 Ist Analyse Anbindung der benutzten Subsysteme Motorsteuerung M28 Ablaufsteuerung M6 Detektornutzung M12 ist zu diesem Zeitpunkt erforderlich Anwendungsfall Topographie Auch das Subsystem Topographie wurde einem Reengineering zur Dekomposition von Nutzeroberfl che und Funktionskomponente unterzogen Die urspr ngliche Topographie umfasst zwei Dialogfenster siehe Abb III 2 Der Dialog Topographie Einstellungen dient zur Eingabe verschiedener Parameter f r den Detektor und den Antrieb am Anfang und w hrend einer Messung Im Dialog Topographie Durchf hrung wird der eigentliche Messvorgang durchgef hrt und berwacht Zu Beginn der Ist Analyse wurde ein Review der im Repository des XCtl Projektes vorhan
187. ifische Anweisungsfolgen zu unterteilen Alle von der Gestaltung der Oberfl che z B von der Wahl der Art der verwendeten Steuerelemente unabh ngigen Anweisungsfolgen m ssen in die Funktionskomponente ausgelagert werden Dies sind alle Methoden wo Botschaften f r die Nutzeroberfl che ankommen und ausgewertet werden z B OnCommand Seite 106 Dekomposition beim Reengineering Ill 2 Restructuring e Lesezugriffe auf Attribute der Funktionskomponente nur wenn sie nicht der Aktualisierung der Nutzeroberfl che dienen Schreibzugriffe nur wenn sie nicht der Daten bernahme von Eingaben dienen e Steuerung von Hardware oder Benutzung anderer Subsysteme e Berechnungen und Simulationen e Zustands und Datenverwaltung sofern unabh ngig von der Nutzeroberfl che Alle brigen Anweisungen sind eindeutig oberfl chenspezifisch e Lese und Schreibzugriffe auf Attribute der Nutzeroberfl che e alle Anweisungen die ein Fenster Handle als Parameter ben tigen e Meldungsfenster und sonstige texturelle Ausgaben e alle Aufrufe von Methoden aus Oberfl chenklassen e Anweisungen zur Steuerung des Mauszeigers z B Sanduhr e Akustische Ausgaben z B Kl nge Warnt ne Der Beginn einer funktionsspezifischen Anweisungsfolge F Block ist nun mit dem Kommentar F und der einer oberfl chenspezifischen O Block mit dem Kommentar O zu kennzeichnen Es gilt die so entstandenen F Bl cke im Programmcode zusammenzufassen um
188. im Polling auf die Verwendung der T merkomponente angewiesen Dazu ist wieder der oben erw hnte TInterfaceTimer n tig der hier an die Nutzeroberfl che TManJustageDlg gebunden ist Diese Anbindung erfolgt jedoch durch das eigentliche Observer Muster Dazu erbt TManJustageDlg neben TModalDlg auch das Timer Interface ITimer ein Das ist keine Mehrfachvererbung weil TTimer nur ein Interface ist TManJustageDlg erzeugt im Konstruktor dynamisch eine Referenz auf ein Timer Objekt das im Attribut m_inkTimer gespeichert wird Um die 16 in Design und Implementation Seite 58 Dekomposition beim Forward Engineering Il 3 Designphase Timer Ereignisse zu behandeln muss die Methode OnTimer implementiert werden F r die Instanziierung der Oberfl che ist dies sogar zwingend weil diese Methode in ITimer als pure virtual function deklariert ist Nur bei der Anbindung der Timer Komponente ist die Klasse TInterfaceTimer das Konkrete Subjekt TManJustageDlg der Konkrete Beobachter und das Interface ITTimer wieder die Beobachter Schnittstelle Timer Ereignisausl sung ist nur mittels Observer Muster m glich GelAngle DoDirechl Dostup m_InkTimer m _InkManlusiage Zustandsaktualisierungen mittels Pollings Variante s un Abb 11 28 UML Klassendiagramm f r Polling in der neuen Manuellen Justage vereinfacht Bei der Anbindung der Nutzeroberfl che an die Funktionskomponente mittels Polling ist TManJustageDlg der Konkret
189. ime long nMlotorint 5ensorTDetector STE allure float FMaxTimerfoat Slh dhd at oumte DO FhMonitsorlsecBO OL Monitor TDetector hhMultikleshot BOOL dStat ngle double HAngleBetweenshots oa TP_FUNK CPP kopiert und bildet dort als TTopography die neue Funktionskomponente Die urspr nglichen Oberfl chenklassen wurden in TTopographyExecuteDlg bzw TTopographySetParamDlg umbenannt Die zu nz dekomponierenden Versionen hei en a und App 111 15 UML Klassendiagramm TTopographyAdjustDlg und befinden s ch n TP_GUI H und TP_GUI CPP der Funktionskomponente TTopographyold 3 Solldesign festlegen Durch das Vorhandensein der Funktionskomponente TTopographyOld musste n der urspr nglichen Topographie bereits ein Kommunikationsmuster existieren Dieses wurde als Polling Var iante identifiziert weil die Initiative f r die Herstellung der vertikalen Konsistenz bei der Nutzeroberfl che liegt Obwohl beide Dialoge gleichzeitig ge ffnet sein k nnen muss die Nutzeroberfl che w hrend einer Messung nur m Dialogfenster TTopographyExecDlg aktualisiert werden Daher konnte Polling auch bei der getrennten Topographie beibehalten werden Weil nach der allgemeinen Schrittfolge zudem das vorhandene Kommunikationsmuster beibehalten werden sollte konnte auf die Implementierung des Observer Musters verzichtet werden Zudem w re der Unterschied nur minimal und h tte zu den gleichen Ergebnisse wie bei der getrennten
190. informiert werden kann Auf diese Weise kann die gesamte Fehlerbenachrichtigung in der Nutzeroberfl che implementiert werden Diese gibt dann ggf Fehlermeldungen etc aus denn das darf n cht Aufgabe der Funktionskomponente sein Durch die zus tzliche Kommunikation ist aber stets eine h here Ressourcenbelastung insbesondere der Ausf hrungsgeschwindiskeit verbunden Auch funktionskomponenten interne Zugriffe auf Attribute sollten zur Verbesserung der Robustheit ber die dazugeh rigen Accessor und Mutator Methoden durchgef hrt werden Die Fehler berpr fung bzw stabilisierung muss so nur dort implementiert werden Dies gilt besonders f r Schreibzugriffe weil diese 1 d R von Bedingungen abh ngen Eine unter diesen Pr missen erstellte Funktionskomponente sichert Robustheit hohe Benutzerfreundlichkeit und somit Wiederverwendbarkeit des Subsystems Anwendungsfall Manuelle Justage Bei der Realisierung der neuen Manuellen Justage wurde die Funktionskomponente TManJustage n das Dateip rchen MJ_FUNK H und MJ_FUNK CPP implementiert Durch das ausf hrliche Pflichtenheft und das Designdokument war f r jede geplante Methode die vollst ndige Signatur und eine kurze Beschreibung vorhanden Wo die Zuordnung der Dekomposition beim Forward Engineering IA Implementierungsphase Seite 69 Methoden und Attribute zu Produktanforderungen m glich war wurde diese als weiterf hrende Informationsquelle im Designdokument angegeben sie
191. ing BOL m_SpAngle TAngle m_HasAngleBooL PT DphMoingHOOL m_HasMovring BO L m_Moatorlist Attribute NEU 4 links 5 rechts Accessor und Mutatormethoden Methoden zur Realisierung der Funktionalit t Kapselung fremder Funktionen weitere Methoden NEU 10 sMovingdcint BOOL SAQOL sZalibratedtint BOOL eM BOOL FParsingAxis LPCSTRYUINT GelDetector isldxg int GelDetectoramer BO OL amp iLFESTR HagsDetector xis BOOL 5Measuringo BOOL 5MeasurerReset BooL GelMeasurefrogresscint amp LPSTR int EiBOOL GelMeasureHwhlidouble UpdatebDetectoro void TManJustage TManlustagel TManlustagel sindesvalidcint BOL HasOfsetcint BOOL SROOL GetMotorldseLF ESTRY int GetMotorldse TAxisTypejint Calc Ofset romAngle cint TAngle amp TAngle CalcAngleFromofsettint TAngle amp TAngle ZalcChannel fsetil TZhannel Ei TAngle CalcChannelAnglecT channel amp TAngle DosStopEverthingi void GetkzMoving const int BOOL BOL Setkzlowingeconst int BOOL const BOOL GetkzMeasuring BOOL 5etkzMeasuring Bog consti woid Resetthannelofseteconst int BOOL Beginpdate INT EndUpdate JINT DetermineAngle constint BOOL amp TAngle DetermineMowingcconstint BOOL Si BoOoL Abb 11 46 UML Klassendiagramm f r die Funktionskomponente der neuen Manuelle Justage am Ende der Implementierungsphase Dekomposition beim Forward Engineering IA Implementierungsphase Seite 73 Beim Abnahmetest an den Messpl tzen
192. ingegebene Sollposition Typ Zugriff Eintrag RP lesen und schreiben NEU Speichertyp als Eintrag in einer ini Datei ASCIl Text Speicherort HARDWARE INI gt MOTOR lt M gt gt MJ_AngleDest Minimalwert siehe Tabelle 8 siehe Tabelle 9 Standardwert aktuelle Istposition Nachkommastellen siehe Tabelle 10 Tabelle 15 Eigenschaften der Sollposition Abb 11 16 Auszug aus dem Datenteil des Pflichtenheftes M15 b Accessor und Mutator Methoden F r jedes Attribut muss eine Get Methode zum Auslesen erstellt werden deren R ckgabewert sp ter dem des Attributes entspricht Aus der Zelle Zugriff im Datenteil des Pflichtenheftes kann abgeleitet werden ob eine Set Methode zum Setzen ben tigt wird Der aktuelle Inhalt des Attributes sollte wenn m glich von der Set Methode zur ckgegeben werden weil der zu setzende Wert in ein Intervall eingepasst werden k nnte oder weil das Setzen m aktuellen Zustand unzul ssig war der Inhalt des Attributes bleibt unver ndert Finden sich im Funktionsteil des Pflichtenheftes Bedingungen f r das Setzen des Attributes ist eine Methode mit dem Pr fix CanSet zu erstellen Die Set Methode sollte dann auch das Ergebnis des Can Methodenaufrufs zur ckgeben um zu zeigen ob das Attribut gesetzt wurde Zu dem bei a abgeleiteten Attribut m_AngleDest m ssen laut Abb II 16 Zugriff zwei Methoden zum Lesen und Setzen entworfen werden Diese Methoden hei en GetAngleDest und S
193. ion beim Forward Engineering Il 5 Testphase Seite 83 Aus dieser allgemeinen Schrittfolge und der klaren Strukturierung der ffentlichen Schnittstelle der Funktionskomponente aus II 2 5 konnte ein genereller Testverlauf abgeleitet werden 1 Gewinnung von Testdaten 2 Generierung von Testf llen 3 Erstellung einer Testumgebung Anpassung der existierenden Nutzeroberfl che oder Implementierung einer Testoberfl che 4 Erzeugung von Objektinstanzen 5 Test nicht zustandsver ndernder Methoden 6 Test zustandsver ndernder Methoden mit geringer Komplexit t 7 Test zustandsver ndernder Methoden mit hoher Komplexit t Die starke Formalisierung von Pflichtenheft und Programmcode wird das Finden von Testdaten bei 1 erleichtert Durch die Tabellarisierung der Datenelemente im Pflichtenheft mit konsequenter Zuordnung der Grenzwerte k nnen fast alle Testdaten allein aus diesem Dokument gewonnen werden F r 2 werden die aus dem Programmcode gewonnenen Testf lle durch die im Funktionsteil des Pflichtenheftes aufgef hrte Spezifikation erg nzt F r den Test einer Klasse ist stets eine Testumgebung siehe 3 Seite 493 n tig um den Objektzustand gezielt zu manipulieren und zu analysieren Sie besteht aus e einem Testtreiber um Operationen gezielt aufzurufen e einem Botschaften Generator zur Generierung von Eingaben e einem Botschaften Auswerter zur Bewertung der Ausgaben e einem Objektzustands Initialisator zur Sc
194. iteigenschaften und ein erh hter Entwicklungsaufwand der sich in einem deutlich umfangreicheren Programmcode zeigt Letzteres wirkt sich aber nicht negativ auf die Wartbarkeit aus Im Gegensatz zu einem nicht dekomponierten System werden Erweiterbarkeit Fehlersuche und korrektur sogar deutlich verbessert Die Ursache f r die schlechten Laufzeiteigenschaften bildet die hohe Robustheit der Funktionskomponente die jeweils berpr ft ob die gew nschte Aktion im aktuellen Programmzustand zul ssig ist Wenn man auf den Aufruf von Can Methoden innerhalb der Funktionskomponente verzichtet kann die Robustheit gegen Laufzeit ausgetauscht werden Dies ist von der Spezifikation der Qualit tsmerkmale m Produktmodell abh ngig und somit von Anwendungsfall zu Anwendungsfall zu entscheiden Zudem besteht die Funktionskomponente zum Gro teil aus ffentlichen Methoden die sich n einer hohen PubM Metrik widerspiegeln Die umfangreiche Schnittstelle ist jedoch erforderlich damit die Nutzeroberfl che auf die angebotene Basisfunktionalit t zugreifen kann Zu den Vorteilen der Dekomposition z hlt die M glichkeit dass Funktionskomponente und Nutzeroberfl che getrennt getestet werden k nnen Neben dem sonst blichen Test der Nutzeroberfl che kann die Funktionskomponente zus tzlich einem White Box Testverfahren unterzogen werden Sie ben tigt hierzu aber eine Testumgebung welche z B ein Debugger oder eine Testoberfl che sein kann Die Nutzeroberfl c
195. itior Minuten ISTPOSITION C Fahrbetrieb ES Start Geschwindigkeit Minuten sec Minuten C Sehntibetieb FA Schrtwene Minuten Difser HDF FSET Direktbetrieb FE Sollposition 100 00 ISTPOSITION o Fahrbeirieb EZ Start Geschwindigkeit 47 50 Sekunden C Schnttbetrieh F8 RELATIVE NULL zes 1255 60 seilzen oglbeben Schntterite II OO Offset KEINER RELATIVE NULL KT ur e z 43 889 Grad 67 222 selzen aulheben Dircktbetnich F10 Sollpasitior pooo Grad ISTPOSITION Fahrbetiieb F11 Gar Geschwindigkeit Grad sec 20 000 Grad Schnltbetrieb F12 Schriltweite 0 0100 Grad Ditzet OFFSET Ten Halbwestsbeeite een LEI Die Beenden Difset f r FSD Difset f r Til Istposition von Theta Grad aktuelle Istposition Winkelweit pro Kanal DU Grad aktueller Offset neu zugeondneter Kanal BE F entspricht Winkel 20 0 Minuten PSD Kanaloffset 20 000 Jos C Dffset eingeben 7 0 Minuten entspricht Winkel Kanal 0 Grad I Abbruch Abb 11 10 Neuentw rfe des Hauptdialogs Manuellen Justage NEU oben Dialog Offset f r lt PSD gt links und Dialog Offset f r lt Antrieb gt rechts Durch die Produktanforderungen an die beiden Offsets waren zwei zus tzliche Dialogfenster erforderlich Aufgrund ihrer Einfachheit waren hier nicht mehrer
196. itten werden die Gr nde und die Motivation f r die design und programmiertechnische Trennung der Funktionskomponente von der Nutzeroberfl che erl utert Im nachfolgenden werden Funktionskomponenten oder Teile von diesen mit DI gekennzeichnet Bei Nutzeroberfl chen oder deren Programmcodefragmente erfolgt die Hervorhebung mittels DI Es wird gezeigt wann es sinnvoll ist oder nicht und wann unumg nglich die Dekomposition bei einem kompletten Softwareprojekt oder einzelnen Subsystemen anzuwenden Der folgende Abschnitt zeigt wie sie zur Bew ltigung der Komplexit t eines Software projektes beitr gt Schwerpunkt ist hier die Bedeutung f r das Design der Software und die Bewertung anhand von Qualit tsmerkmalen Die beiden nachfolgenden Abschnitte zeigen nach Funktionskomponente und Nutzeroberfl che unterschieden Vorteile f r d e Anpassungs f higkeit und Wartbarkeit eines dekomponierten Softwareprojektes Der vierte Abschnitt erl utert warum es zweckm ig sein kann mehrere Programmiersprachen m einem Software projekt zu verwenden und welche Rolle dabei die Dekomposition spielt Im letzten Abschnitt wird die entscheidende Bedeutung bei der Realisierung einer Makrosteuerung dargestellt Die Bearbeitung aller Themen erfolgt nur unter dem Gesichtspunkt der objektorientierten Programmierung weil sie ein essentieller Bestandteil der hier vorgestellten Dekomposition ist 1 4 1 Bew ltigung der Programmkomplexit t Nachdem die Kosten der
197. keit von der Nachkommastellengenauigkeit des Antriebs bestimmen float min 1 pow float 10 float GetMotorDigits eSF if aStep lt min aStep gt 99999 0 return FALSE Grenzwerte m_fMoveStep aStep Ferurm TR e JI ERGEBNIS Abb 11 19 Erweiterung einer Set Methode durch zus tzliche Bedingungen Auch in der Nutzeroberfl che waren keine Bedingungen zur Ausf hrung von Do Methoden vorhanden In Zusammenhang mit dem vorhergehenden Schritt 8 der Dekomposition sind in der getrennten Topographie berhaupt keine CanDo Methoden enthalten 10 Entfernen gleicher Do CanDo Methode In der Dialogklasse TTopographyExecDlg konnten die Einstellungen f r den Detektor auch w hrend der Messung ge ndert werden Ein ggf laufender Messvorgang wird dazu unterbrochen die Detektorparameter ge ndert und die Messung dann fortgesetzt Dieses Verhalten war an verschiedenen Stellen implementiert jedoch mit unterschiedlichen Aufrufbedingungen Bei Schritt 7 der Dekomposition entstanden so die Methoden DoSetDetecParams_Start DoSetDetecParams_ReStart und DoSetDetecParams_NoStart Obwohl diese nicht v llig identisch waren konnten sie in einer Methode DoSetDetectorParams zusammengefasst werden weil die Kernfunktionalit t das ndern der Parameter mittels Dekomposition beim Reengineering Ill 2 Restructuring Seite 127 Detector gt SetExposureSettings die gleiche war Indem der zus tzliche Parameter BOOL Start hinzugef gt wur
198. kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Klasse f r Druckeransteuerung void TPrinter DoSpoolerJob Versuch n chsten Druckauftrag zu verarbeiten ee Tnservice y NT TsPbrineing er urn ii Is CartcridgceEmoLty II lHasPaper return DoPrint Spooler GetJob voro Terimter DePbrine ee 1 aktuellen Auftrag abarbeiten AUSGANGSZUSTAND kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Fenster f r Druckerwartung void TPrinterServiceDlg OnPrintTestPage seit Ausgangszustand unver ndert kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Klasse f r Druckeransteuerung void TPrinter DoSpoolerJob seit Ausgangszustand unver ndert bool TPrinter CanDoPrint NEU if InService IsPrinting return false if IsCartridgeEmpty HasPaper return false return true volde IPrimrer DORILE lt 4 if CanDoPrint return NEU die immergleichen Bedingungen besser hier pr fen aktuellen Auftrag abarbeiten ZWISCHENSTAND kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Fenster f r Druckerwartung void TPrinterServiceDlg OnPrintTestPage Versuch Testseite zu drucken if m_Printer gt CanDoPrint return m_Statusfield SetText Testseite wird gedruckt DoPr ine m Printer GetIlestPagel
199. komponente TP_FUNK CPP TP_FUNK H e Nutzeroberfl che TP_GUI CPP TP_GUI H Klassendiagramm Subsystem Subsystem Benutzeroberfl che Utilities TBasicDialog lt lt interface gt gt TTimer TModalDlg ITimer D 1 Tinterface Timer m_InkTimerMeasunng m_InkTopography m_InkTopography 0 1 0 1 Subsystem TTopography getrennte Topographie 0 1 O A m_Instance m_IinkManitor m_InkDetector Ni AN Bu TMacroTagy Everibetecio Subsystem Subsystem Detektornutzung Ablaufsteuerung Dokumentation e Analyse Definitionsphase o Topographie Gesamtvorgang M29 o Verhaltensspezifikationen Einstellen der Parameter f r die Topographie M31 start und Kontrolle der Topographie M32 Topographie Me protokoll_Buch M33 o eine kurze Use Case Beschreibung e Design Implementierungsphase o Designbeschreibung zum Re Engineering der Topographie NEU M35 e Testphase o Regressions Testf lle Topographie M36 e Fehler bersicht o tabellarische bersicht aller gefundenen Fehler seit 22 6 2000 erweitert M34 Tab IO bersicht zur getrennten Topographie Seite 136 Dekomposition beim Reengineering Ill 2 Restructuring WEE TTopography 472 TTopographykExecDlg 398 TTopographyAdjustDlg 195 Tab 111 10 Ausgew hlte Metriken f r die Klassen der getrennten Topographie Trotz des unzweckm igen Designs mit
200. komponierenden Subsystems gleichzeitig angezeigt werden k nnen und jedes Fenster dabei eine eigene Instanz einer Funktionskomponente benutzt Wenn Bezeichner Attribute und Methoden mehrfach vorhanden sind m ssen diese vor der Verschmelzung in einer Klasse umbenannt werden v Dies wird durch den Compiler unterst tzt der jede Stelle anzeigt wo die Umbenennung von Attributen und Methoden unterschlagen wurde Anschlie end k nnen die Funktionskomponenten problemlos n einer Klasse vereinigt werden berall im System m ssen die alten Klassenbezeichner durch den der neuen Klasse ersetzt werden Die verschmolzene Funktionskomponente muss genau zum gleichen Zeitpunkt wie die urspr nglichen Komponenten im System initialisiert werden v Beim Finden der alten Klassenbezeichner hilft wieder der Compiler Ein Regressionstest aller benutzenden Subsysteme verifiziert dass durch die Verschmelzung keine schwerwiegenden Fehler entstanden sind Der Test muss alle Anwendungsf lle des zu dekomponierenden Subsystems und aller benutzenden Systeme beinhalten 3 Solldesign festlegen Zu Beginn der eigentlichen Dekomposition muss das zuk nftige Bas sdesign durch die Wahl eines Kommunikationsmusters festgelegt werden siehe 11 3 3 Die Entscheidung sollte nach den in Kapitel I11 3 3 5 vorgestellten Kriterien getroffen werden Dies zieht 1 d R die Deklaration und Initialisierung neuer Attribute die Einf hrung neuer Methoden und u U die Einerbung eines
201. ktion wird hier verzichtet ihre Beschreibung im Pflichtenheft beschr nkt sich nur auf e die Umgestaltung der Nutzeroberfl che e das Anzeigen von Meldungsfenstern e die Ausgabe von Warnt nen e zum Anzeigen Verstecken anderer Oberfl chenfenster e Zustands nderungen innerhalb der Oberfl chenklasse Zus tzlich sind bestimmte Steuerelemente mit einer Produktanforderung verkn pft so dass die Anbindung an Methoden der Funktionskomponente n tig wird Mit dem in Abb 11 50 abgebildeten Steuerelement werden die beiden Funktionen F 70 und F 80 realisiert F r F 70 wurden die Implementierung der Methoden DoDirect und CanDoDirect bereits in 11 4 1 erl utert f r F 80 wurden dazu DoStop und CanDoSt op implementiert Bei Bet tigung der Start Stop Schaltfl che wird ber den in Abb II 48 dargestellten Mechanismus in Dilg_OnCommand zuerst der entsprechende Teilbereich ermittelt TB_CheckMiddle ruft dann TB_StartStopClicked siehe Abb 11 49 Wenn sich der Antrieb nicht bewegt IsMoving wird die Bewegung mit DoDirect gestartet ansonsten f hrt DoStop zum Stoppen des Antriebs Im Erfolgsfall sichert ein Timer die in Abb 11 50 geforderte Bildschirmaktualisierungen Im Fehlerfall wird OnNoAction aufgerufen was in Abh ngigkeit vom Eintrag DisplayNoActionMsg der Konfigurationsdatei zur Ausgabe der Fehlermeldung Aktion ist im aktuellen Zustand nicht verf gbar f hren kann Seite 76 Dekomposition beim Forw
202. l LA Motivation eine allgemeine bersicht ber Gr nde Richtlinien und Besonderheiten f r die Dekomposition von Nutzeroberfl che und Funktionskomponente Die untersuchten Aspekte werden auf f nf Abschnitte verteilt behandelt Kapitel II st nach den Softwareentwicklungsphasen gegliedert und besch ftigt sich mit der Dekomposition bei der Entwicklung neuer Subsysteme oder ganzer Projekte im Forward Engineering Am Anfang eines jeden Abschnittes werden die allgemeinen Grundlagen vorgestellt und diskutiert Anschlie end wird ausf hrlich auf die Besonderheiten und Erfahrungen bei der Neuentwicklung der neuen Manuellen Justage eingegangen Kapitel II 1 Analysephase besch ftigt sich mit der Erstellung des Lastenheftes und beschreibt die Einbeziehung existierender Software bei einem Neuentwurf Kapitel 11 2 Definitionsphase betrachtet die Dekomposition bei der Erstellung eines Pflichtenheftes bis hin zum Entwurf eines objektorientierten Analyse Modells Das folgende Kapitel 11 3 Designphase bildet den ersten Schwerpunkt dieser Arbeit Hier werden die Grundlagen zur Dekomposition auf der Designebene vorgestellt und unter Gesichtspunkten wie Zugriffsschutz Robustheit und Komplexit t allgemein und am Beispiel der neuen Manuelle Justage bewertet Durch den starken handwerklichen Charakter der in Kapitel IA beschriebenen Implementierungsphase wird dort nur kurz auf die Probleme bei der Implementierung von Nutzeroberfl che und Funktionskompone
203. lassen der neuen Manuellen Justage Observer Muster am Ende der Designphase Subsystem Subsystem Benutzeroberfl che Utilities TBasicDialog TModalbig lt lt intlefate gt gt NaandustageDig m_InkidanJustage m_InkklanJustage UN Al IN TManJustage a ees o Mm_Motorlist lt lt siruci gt E A Subsystem m_InkDetector g 4 m_inkhtotor neue Manuelle Justage TDetect r ege Li MEN Subsystem Subsystem Detektornutzung Motorsteuerung Abb 11 37 UML Klassendiagramm f r das OOD Modell der neuen Manuellen Justage mit Observer Muster und bersicht der benutzten Subsysteme Seite 68 Dekomposition beim Forward Engineering IA Implementierungsphase 11 4 Implementierungsphase Nach der Erstellung des OOD Modells sind die wichtigsten Aspekte der Dekomposition bereits abgearbeitet Das OOD enth lt nun die Richtlinien f r die Implementierungsphase Bei der Implementierung sollte zuerst die Benennung der Dateien beachtet werden Dabei ist sowohl die Zugeh rigkeit zum Subsystem als auch die Unterscheidung in Funktionalit t und Oberfl che zu kennzeichnen In C sind deshalb f r Funktionskomponente n und Nutzeroberfl che n je ein Dateip rchen bestehend aus Header und cpp Datei zu erstellen Die beiden aus der Designphase bekannten Kommunikationsmuster Observer Muster und Polling Variante wurden zum Vergleich auch in der Implementierun
204. lichen Dialogfenster erfolgte bereits m Vorbereitungsseminar Projekt Softwaresanierung beim Review der Verhaltenspezifikation M1 Dabei fiel sofort die unvorteilhafte Anordnung der Steuerelemente auf welche den Arbeitsfluss behindert H ufig benutzte Steuerelemente sind zu weit voneinander entfernt Zudem sind die angebotenen Tastenkombinationen nicht konsequent zugewiesen und f r einige grundlegende Funktionen sind gar keine definiert Bei der eigentlichen Analyse wurde intensiv mit dem existierenden Dialogfenster gearbeitet Die M ngel und Fehler wurden vorerst nur in einer Fehlerliste M19 dokumentiert da sie auf grund der fehlenden Einarbeitung in die Implementierung noch nicht behoben werden konnten Als Resultat dieser Arbeit entstand eine ausf hrliche Bewertung M16 die der urspr ng lichen Nutzeroberfl che eine f r den Anwendungszweck unzweckm ige Struktur bescheinigt Daraus ergab sich auch eine Liste von Zielen f r den Neuentwurf Diese wurde in die Vorabver sion des Pflichtenheftes Kapitel Benutzeroberfl che als Notizen bernommen siehe II 2 1 Dazu z hlten u a dass die im aktuellen Programmzustand verf gbaren Steuerelemente visuell hervorgehoben werden indem alle brigen Elemente gesperrt und ausgegraut sind Dieses Vor gehen ist besonders wichtig weil die beiden Anwendergruppen z T unterschiedliche Produkt anforderungen stellen Nur f r den Bereich Topographie ist z B die Halbwertsbreitenm
205. lierbar gestaltet werden soll ist die Dekomposition der Funktionskomponente von der Nutzeroberfl che unerl sslich weil die Steuerung unabh ngig von der Nutzeroberfl che erfolgen muss Neuere Versionen des zu kontrollierenden Programmes w ren mit nderung der Nutzeroberfl che sonst nicht mehr abw rtskompat bel steuerbar z B durch Benutzung von Common Object Request Broker Architecture CORBA oder Microsofts Distributed Component Object Modell DCOM Seite 16 Einf hrung 1 4 Motivation EI Microsoft Excel Mappel xls BET DI xl SI Datei Bearbeiten Ansicht Einf gen Format Extras Daten Fenster la x DEB2a8sRBR A 2 i s les BERTFTR beer D EHRE G nu 1 EJ Microsoft Excel Temperaturen xls RN Bee se E EE icht Einf gen Format Extras Daten Fenster le x cu w Lech S kA Ce 0 Bsu088BR Br 8 21a ales A Se D E F G EEE be J Ken z I En iM tzmitteltemperateren 1 Halbjahr Lee Ser EE Less af ES ge K anuar od ee i mi 8 April f i Mai Fa Microsoft Excel Temperaturen als Ba Ce E AB ol sl on T Ee Cem TT fE Datei Bearbeiten Ansicht Einf gen Format Extras Diagramm Fenster 1 x 7 2 EA D I ZA 25 3 A u ID 13 4 12 4 SS A 7 D r S amp 7 d aola lz pi u zl DREAS EEn rer Ser s AA 21 EA SEA D 15 8 LA Fr KR D A4 240 AA GP UE ER Fat 12 H D 4 4 MN s6 Jan Fob Mrz Apr Mai Jun Jul Aug Sop Okt Nav Dex 14141 In 36 97 38 399
206. ligkeit bedingt durch die Komplexit t des Design und Umfang des Programmcodes des zu testenden Systems Dank der bei II 4 3 1 vorgestellten Gemeinsamkeiten wird hier v llig auf eine Unterscheidung verzichtet Zur Wahrung des roten Fadens wurden die Beispiele wieder der Polling Variante entnommen 11 5 1 Test einer Funktionskomponente Beim Testen der Funktionskomponente ist zu berpr fen ob alle im Pflichtenheft geforderten Produktspezifikationen vorhanden s nd Vollst ndigkeit das Programm das Gew nschte leisten Validation und fehlerfrei arbeitet Verifikation Die Funktionskomponente und ihre Anbindung an die benutzten Subsysteme sind vollst ndig objektorientiert Hierbei besteht eine Datenkopplung zwischen den Operationen eines Objektes und den gemeinsam benutzten Objektattributen Eine Methode kann durch nderung eines Attributes einen Objektzustand hinterlassen der das Verhalten des Folgezustands beeinflusst Beim Testen muss daher die Aufrufreihenfolge der Objektoperationen beachtet werden Nach 3 S 488ff ist ein Test objektorientierter Komponenten durchzuf hren Innerhalb dieses Tests wird zur Verifikation ein kontrollflussorientierter Strukturtest White Box Testverfahren siehe 3 S 400ff verwendet Ziel ist mit einer Anzahl von Testf llen und daten alle vorhandenen Anweisungen und Verzweigungen des Programmcodes auszuf hren und zu bewerten F r die Validation und Sicherung der Vollst ndigkeit muss dieses jedoc
207. lirETR constERessourceldiconshint GetCtriETB constERessourceldiconsbcHWYND B2 Selection ETB consti JINT SelectionzZ TB INT consbiETB 5etSelection ETE const UINT const BOOL angetSelection ETR const JINT const BOOL TManJustagebig TManlJustageDlg TManJustageDlgl OnMotionstatstUlNT constbivoid OnMotionProgresse_llMNT consbwvoid OnMotionstopstUlNT constivoid OnMeasurestans void OnMeasurerrogresso void OnMeasurestiops void OnPsoofset void On hooseTBo void OnMoActond void OtherZontrolsovoid strollbarbalculate TAngleiconst Tangleiconst TAangle const int amp int eint amp wold B_checkLetETE consti consting BOOL TB_CheckMiddle ETB constconst Ip DHOOL TB_CheckRightfETB c0onstconstint oBO OL TB_CheckEkitfE TB constconstint BO L TB_StanStopllickect ETB consbvoic TB_AnglebDestEntereclETB c0onst BOOL consbvoid TB_SpeedEnterediETB const BOQL constvoid TB_StepidthEnterecktETB c0nst BO OL c0nsb old TB_Motor amp hangediETB consb oid OnTB_Controls ETB constBO L c0nsbold OnTB_Eind rMowrelETB const BOOL constivoid OnTB_StarstoptETB const BOOL constwoid OnTB_MotionraramiETB constBOoL consbivoid OnTB_Fositions lETB constBO0OL consbvoid OnTB_ofsetiETB constBOoLconsbooid OnTB_UnitsiETB consbwoid OnTB_ControlsEnablelETB constivoid O0nTB_MotorListEnable ETE cons void 0nTB_KindOfhioveEnable ETE const void 0nTB_StatStopEnable ETE cons wvoid O0nTB_MotionFaramEnable ETE const woid
208. llen wurde die urspr nglich vorhandene Implementierung der Manuellen Justage ebenfalls in Nutzeroberfl che und Funktionskomponente getrennt Die oben vorgestellte Schrittfolge diente dabei als Grundlage weshalb hier nur auf Eigenheiten bei der getrennten Manuellen Justage hingewiesen wird Erg nzt werden diese Ausf hrungen im Anschluss durch den Anwendungsfall Topographie wo ebenfalls die Dekomposition im Reengineering vollzogen wurde Zur Gegen berstellung von Observer Muster und Polling Variante wurden f r die getrennte Manuelle Justage wieder beide Kommunikationsmuster implementiert Durch die minimalen Unterschiede zwischen diesen Mustern sind die Beispiele wieder der Polling Variante entnommen Auf Besonderheiten des Observer Musters wird in III 2 2 1 eingegangen 1 Erstellung neuer Dateien Wie beim Forward Engineering wurden auch hier zwei Dateip rchen f r Funktionskomponente und Oberfl che erstellt F r die Deklaration entstanden MJ_OFUNK H und MJ_OGUI H und f r die Implementierung MJ_OFUNK CPP und MJ_OGUI CPP Die urspr ngliche Oberfl chenklasse TAngleControl wurd in die M J_ Dateifamilie aufgenommen indem sie in die Dateien MJ_OLD H und MJ_OLD CPP verschoben wurde Zuvor war diese Klasse mit Oberfl chenfenstern anderer Subsysteme zusammen in der Datei SWINTRAC H bzw M_DLG CPP enthalten F r die zu dekomponierende Nutzeroberfl che wurde TAngleCtlDlg anstatt TAngleControl gew hlt Beide verwenden
209. ller dynamischen haben dann im Konstruktor der Funktionskomponente zu erfolgen Die Nutzeroberfl che darf nur Attribute enthalten welche Eigenschaften wie Gr e und Layout allgemein den Zustand von Fenstern und Dialogen kennzeichnen Auch Referenzen auf Fenster oder Fenster Handles verbleiben in der Oberfl che Alle Attribute sind mit dem h chsten Zugriffsschutz zu versehen egal ob in der Funktionskomponente oder der Nutzeroberfl che Daraufhin sind in der Funktionalit t Mutator Methoden f r den direkten Schreib Zugriff und Accessor Methoden f r den Lese Zugriff zu implementieren Sie bilden einen Teil der ffentlichen Schnittstelle der Funktionskomponente Ihre Benennung sollte nach Kapitel 11 2 5 b erfolgen Falls oberfl chenspezifische Attribute in einer bereits vorhandenen Funktionskomponente enthalten sein sollten s nd diese n die entsprechende n Nutzeroberfl che n zu verschieben zusammen mit deren Initialisierung Dort sind sie mit dem h chsten Zugriffschutz zu versehen Keine Methode der Funktionskomponente darf auf solche Attribute zugreifen ggf sind solche Methoden in die Nutzeroberfl che zu verschieben v Diese Umsortierungen werden durch den Compiler und Linker unterst tzt Zur Sicherheit sollte sich ein Regressionstest der oben benannten Subsysteme anschlie en 6 Zusammenfassen von Funktionalit tsaufrufen Nur der bestehende Programmcode der Nutzeroberfl che st noch n funktions und oberfl chenspez
210. log intefater gt Trimer TModalbig Thmer TinterfaceTimer e L Aminkinterface E 5 EEE m_inkTimer m_nkManlustage U 1 m_InkManlustage EK TManJust age E E m_InkManlustage U 1 Abb 11 57 UML Klassendiagramm der Manuellen Justage mit Testoberfl chenklasse TManJustageTestDlg 4 Erzeugung von Objektinstanzen Zuerst erfolgte die Erzeugung eines Objektes der Funktionskomponente TManJustage innerhalb der Testoberfl che TManJustageTestDlg Da nur der Standardkonstruktor implementiert ist wird immer auf die gleiche Art und Weise instanziiert Da der Konstruktor aber Daten aus einer Konfigurationsdatei liest und Attribute mit Werten aus anderen Subsystemen initial s ert kann der Ausgangszustand des Objektes doch variieren Beim Programmstart wurden deshalb verschiedene Einstellungen der Betriebsarten der Offsets und vom Antriebs und Detektorstatus getestet Es waren 7 Testf lle verschiedene Versionen einer Konfigurationsdatei n tig 5 Test nicht zustandsver ndernder Methoden Get Is Has Can M Hier sollten alle Methoden der Funktionskomponente TManJustage mit den Pr fixen Get Can Has Is und Calc getestet werden Dies entspricht 66 der ffentlichen Schnittstelle bzw 47 Methoden siehe Abb II 55 P Die Testoberfl che berwacht davon st ndig die R ckgabewerte von 31 Methoden alle Can Is und Has M sowie die Ausgaben ber den Antriebs und Detektorstatus Neun von restlichen nicht zu
211. ment hiding d h die Minimierung von Umgebungswissen innerhalb einer Komponente Treiberprogramme zur Hardwareansteuerung z B d rfen nichts ber die sie benutzenden Anwendungen wissen Bezogen auf die Dekomposition darf eine Funktionskomponente nichts ber Anzahl und Zust nde der assoz ierten Nutzeroberfl chen wissen berhaupt muss deren Schnittstelle aus Sicht der Funktionskomponente m glichst gering gehalten werden um Austausch Flexibilit t und Wartung der Nutzeroberfl che einfach zu gestalten Insgesamt l sst sich das Environment hiding jedoch schwierig umsetzen da hierf r keine allgemeing ltigen Designmuster existieren nachzulesen bei 1 L sungsans tze werden ab Kapitel II 3 ausf hrlich diskutiert Nutzeroberfl che des h heren Subsystems z B Dialog Topographie Einstellungen GUI Schicht Methodenaufrufe POLLING oder PUSHING Funktionskomponente des h heren Subsystems z B Topographie Methodenaufrufe R ckgabewerte Referenzparameter Schicht der Basisfunktionalit t niederes Subsystem zur Hardwareansteuerung z B Motorsubsystem Schreiben von Lesen von Speicheradressen Ports Hardware Komponente z B Controller Karte Hardware Schicht h heres Subsystem besteht aus Nutzeroberfl che und Funktionskomponente niederes Subsystem Basisfunktionalit t unabh ngig von der Nutzeroberfl che gt zeigt den Datenfluss Ergebnis wird ber einen
212. mit realer Hardware traten Probleme mit der Ausf hrungsgeschwindigkeit auf Schnell konnten diese auf den Zugriff der dort installierten Motorcontrollerkarten zur ckgef hrt werden Weil sich die Nutzeroberfl che an jede Zustands nderung anpassen sollte wurden die Steuerelemente regelm ig aktualisiert Dazu wurde jeweils auf die Hardware zugegriffen weil diese Zustand und Inhalt der Steuerelemente mitbestimmt Der Schwerpunkt der Optimierung liegt somit bei der Nutzeroberfl che Zu deren Unterst tzung wurde ein zus tzlicher Mechanismus in die Funktionskomponente integriert der durch die Nutzeroberfl che aktiviert BeginUpdate bzw deaktiviert EndUpdate werden kann siehe Abb II 47 default read return readHW BeginUpdate EndUpdate EndUpdate en savetreturn readHW read return saved default bei read wird die Hardware ausgelesen und dieses Ergebnis zur ckgegeben Anfangszustand bei read wird die Hardware auslesen das Ergebnis wird zwischengespeichert und zur ckgegeben bei read wird der zwischengespeicherte Wert zur ckgegeben d h kein Hardwarezugriff Abb 11 47 Stark vereinfachtes Konzept zur Geschwindigkeitsoptimierung So kann die Nutzeroberfl che durch BeginUpdate kennzeichnen dass viele Hardwarezugriffe bevorstehen Nur beim ersten Zugriff read wird wirklich auf die Hardware zugegriffen alle brigen Zugriffe geben einen zwischengespeicherten Wert zur ck bis EndUpdate aufgerufen und n den Ausgang
213. n In vielen F llen ist das Pflichtenheft das alleinige Anforderungsdokument weil in der Praxis oft auf die Erstellung eines Lastenheftes verzichtet wird Im Hinblick auf eine gute Produkt Definition und damit auf einen effizienten und erfolgreichen Entwicklungsprozess ist dem Pflichtenheft besondere Aufmerksamkeit zu schenken Zudem bildet es die Grundlage f r alle weiteren Aktefakte der Produkt Definition W hrend des gesamten Softwareentwicklungsprozesses birgt der geringe Formalisierungsgrad von verbalen Ausf hrungen jedoch stets die Gefahr des Kommunikationsproblems siehe 7 S 174ff durch Missverst ndnisse zwischen Auftraggeber und nehmer Darum sollten Beschreibungen so fr h wie m glich formal siert werden Gr ere Projekte sollten im Hinblick auf bersichtlichkeit Wartung und Arbeitsteilung anstatt in der Designphase bereits hier in mehrere Teile sp tere Subsysteme aufgeteilt werden Im Anschluss an die Erfassung aller Produktanforderungen muss dazu zun chst eine Modularisierung erfolgen nach der dann die Zuordnung auf das jeweilige Subsystem erfolgt So entsteht pro System ein separates Pflichtenheft F r die aufgeteilten Produktanforderungen sind dann w e gewohnt Daten und Funktionen zu modellieren Zudem m ssen dort die zeitlichen Anforderungen Zugriffszeiten f r den Datenzugriff Berechnungen und Steuerungsvorg nge sowie die Einsatzumgebung definiert werden F r das Gesamtsystem Steuerprogramm bzw Programm
214. n und ben tigt damit auch mindestens f nf Parameter wenn diese Eigenschaften nicht global in der Funktionskomponente gespeichert werden k nnen Bei einer anderen Methode DoReset Times resultieren die Parameter aus der Vielzahl an Set Methoden die in einem F Block zusammengefasst sind Die Folge ist ein unsch nes Gesamtdesign siehe Tab IIH 10 MNOP 5 Alternativ h tten die Parameter auch in einer Struktur gesammelt bergeben werden k nnen obwohl dies wieder die Komplexit t erh ht h tte Durchf hrung einer Messung mittels Kommandoverarbeitung BOOL TIL Opogra phy Bo Larc Me asure TCmaid aC mald ne pr 1ni p2 EPs aSr HMAND aconctcr rolne i return Steering StartCmdExecution aCmdId pl p2 aStr aControlWnd J Herstellen des Ausgangszustandes void TTopography DoResetTimes DWORD aStart DWORD aCurrent BOOMaRktn ROOEZ Kee Ee ep SetStartTime aStart SetCurrentTime aCurrent SetTimeRunning aRun SetAdditionalTime aAdd SetTimeFinish aFinish N Abb 111 18 Durch Dekomposition entstandene Do Methoden mit langen Parameterlisten Seite 126 Dekomposition beim Reengineering Ill 2 Restructuring 8 Erzeugung von CanDo Methoden optional Eine Besonderheit der Topographie ist dass keine CanDo Methode ben tigt werden da die sich die Nutzeroberfl che nicht an Zustands nderungen der Funktionskomponente anpassen muss Die Bedingungen m den Do Methoden pr fen nicht die Durchf hrbarkeit selbst
215. n 1 6 M18 J Hanisch Regressions Testf lle Manuelle Justage Version 2 2 M19 J Wegener Systemtest Probe und Kollimator justieren CTE 32 Diagramm e erstellt 10 02 2000 M20 T Kullmann G Reinecker Regressions Testf lle neue Manuelle Justage Version 1 5 M21 T Kullmann G Reinecker Designbeschreibung neue Manuelle Justage Version 2 0 M22 T Kullmann G Reinecker neue Manuelle Justage Funktionskomponente CTE XL Diagramm e erstellt 25 04 2002 M23 T Kullmann G Reinecker neue Manuelle Justage Nutzeroberfl che CTE XL Diagramm e erstellt 07 02 2002 Anhang B verwendete Materialien Seite 143 M24 T Kullmann G Reinecker Reverse Engineering des urspr nglichen Subsystems Manuelle Justage Version 1 6 M25 T Kollmann G Reinecker Fehler alte Manuelle Justage Version 1 0 SUBSYSTEM AMOTORSTEUERUNG M26 T Kullmann G Reinecker Reverse Engineering der objektorientierten Teile des Subsystems Motorsteuerung Version 1 5 M27 U Sacklowki Motorsteuerung Fehler erstellt 19 06 2000 M28 T Kullmann G Reinecker Reengineering der objektorientierten Teile des Subsystems Motorsteuerung Version 1 1 SUBSYSTEM TOPOGRAPHIE M29 M Gollnick Software Struktur Version 1 0 M30 U Sacklowski Topographie Gesamtvorgang Version 2 2 M31 M Gollnick U Sacklowski Einstellen der Parameter f r die Topographie Version 3 0
216. n Autoren vorgeschlagenen Definitionsphase links zur Allgemeinen rechts Damit wird das Oberfl chen Prototyping jedoch zu einem unerl sslicher Bestandteil der Definitionsphase weil es zur Vervollst ndigung des Pflichtheftes ben tigt wird Heutzutage wird aus konomischen Gr nden leider h ufig auf das Prototyping verzichtet obwohl neben den oben genannten Vorteilen auch der Bedienkomfort f r den sp teren Anwender steigt da er auf eine unvorteilhafte oder komplizierte Oberfl chengestaltung fr h einwirken kann Zudem kann es die Notwendigkeit zus tzlicher Produktfunktionen sichtbar machen Im Falle der neuen Manuellen Justage waren dies die Offsets f r die Antriebe und den PSD Auch wenn es zun chst zeitaufwendiger ist die abgestimmte Oberfl che im Pflichtenheft nachzutragen so verbessert es doch deutlich die Vollst ndigkeit der Produktanforderungen Bei Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 43 der neuen Manuellen Justage wurden so mehrere oberfl chenspezifische Funktionen und ein zus tzliches Datenelement ermittelt und im Pflichtenheft erfasst Durch die starke Formalisierung Gliederung und Informationsauswahl des nach IZ erstellten Pflichtenheftes lassen sich f r die nachfolgenden Entwicklungsschritte eindeutigere und umfangreichere Informationen gewinnen Des Weiteren kann die Integration der Oberfl chenentw rfe und deren Beschreibung unvorteil oder sogar fehlerhaftes Verhalten
217. n die Aktualisierung zudem nur zu diskreten Zeitpunkten wie Anwendereingaben stattfinden soll muss nicht jede Zustands nderung behandelt werden Beim Observer Muster entsteht dort ein Overhead weil stets jeder neue Zustand gemeldet wird Nachteile der Polling Variante e Bei der Verwendung eines Timers ist es sehr schwierig den richtigen Zeitpunkt f r die Abfragen zu finden Werden diese in zu gro en Zeitabst nden gestellt reagiert das Programm verz gert auf Ereignisse Sind die Zeitabst nden zwischen den Anfragen zu kurz werden Rechenressourcen und Prozessorzeit verschwendet Weil zur Gew hrleistung der Aktualit t eher fter abgefragt wird hat timergest tztes Polling fast immer Ressourcen Verschwendung zur Folge e Da die Implementierung eines Konkreten Beobachters hier komplizierter ist als beim eigentlichen Observer Muster st Polling nachteilig wenn mehrere angeboten werden sollen e Muss zudem eine horizontale Konsistenz zwischen mehreren Konkreten Beobachtern gew hrt werden darf sie nicht durch zus tzliche Kommunikation zwischen diesen realisiert werden Erforderlich wird dann eine Timer Komponente f r jeden Konkreten Beobachter Eine zeitgleiche Aktualisierung ist damit trotzdem unm glich weil die Timer Komponenten schlecht synchronisierbar s nd Anwendungsfall Manuelle Justage Um die Bewegung der Antriebe und die Halbwertsbreitenmesssung in der neuen Manuellen Justage zu verfolgen st man auch be
218. n oder sie unvorteilhaft machen Abschlie end favorisieren die Autoren hier die Polling Variante Im Allgemeinen sollte dem Observer Muster nur Vorrang gew hrt werden wenn die Polling Variante nicht anwendbar oder zu fehleranf llig ist siehe I1 3 3 4 S IManJustageDlg 13 D 6 0 0 o 0100 D 1 1 52 TManJustage em 8 ee In 12 1 87 6 3 2 55 L TMotorData 8a 800 o o 100 66 0 1 100 TManJustageDlg 869 5 50 1 11 77 9 A A 6 1 46 IMsr r rfrserD Sen u unver ndert zu Tab II 7 IPsdO ffsetDlg Tab 11 8 Ausgew hlte Metriken f r die Klassen der neuen Manuellen Justage Observer Muster nach Abschluss der Implementierungsphase Seite 82 Dekomposition beim Forward Engineering Il 5 Testphase 11 5 Testphase Inhalt dieses Abschnittes ist die Vorgehensweise f r das separate Testen von Funktionskomponente und Nutzeroberfl che bei einem dekomponierten Softwareprojekt In dieser Phase der Entwicklung ist es unerheblich ob die zu testende Anwendung ein Neuentwurf oder ein saniertes Projekt ist Die Ausgangsbasis f r alle Testaktivit ten ist stets eine fertig mplementierte Anwendung bzw ein Subsystem So gelten die in diesem Kapitel vorgestellten Schrittfolgen f r das Testen nicht nur f r das Forward sondern auch f r das Reengineering Die Wahl des Kommunikationsmusters beeinflusst diese Schrittfolgen nur durch die unterschiedliche Fehleranf l
219. nbieten Dieses Verhalten wird insbesondere erforderlich weil die durch den Anwender vermuteten Konzepte mit zunehmender Softwarekomplexit t immer st rker von der tats chlichen Funktionalit t abweichen Solche Systeme werden aber nie in ihrer Reinform auftreten sondern stets durch passive Hilfe Systeme erg nzt werden die warten bis der Anwender selbst aktiv wird und eine Hilfeleistung anfordert Anwendungsfall Manuelle Justage Zu Beginn dieser Diplomarbeit war das Hilfe System des XCtl Projektes nahezu im gleichen Zustand wie es der Erstentwickler Heiko Damerow 1998 siehe 1 3 hinterlassen hatte Die Hilfe bestand aus einer rtf Datei die mit dem Microsoft Hilfe Compiler in eine windowskompatible hlp Date konvertiert werden konnte Anfangs existierte nur ein Hilfe Thema bestehend aus drei Seiten W hrend der Analyse und fr hen Definitionsphase f r die neue Manuelle Justage haben Sebastian Freund und Derrick Hepp diese um eine Einleitung in das von ihnen erstellte Subsystem der Automatischen Justage erg nzt F r die Subsysteme Diffraktometrie Reflektometrie und die Graphische Darstellung der Messwerte folgten wenig sp ter durch Stephan Berndt Jens Ullrich und Bernhard Buss zwei Hilfemodule im CNS Durch die schlechte Wartbarkeit der rtf Dateien aufgrund der Syntax die der Hilfe Compiler ben tigt entschieden sich die drei Autoren f r das Werkzeug HelpScribble von Just Great Software Diese
220. nd ausgegraut Start wird mit Stop beschriftet und bleibt w hrend der Bewegung freigegeben D Ej 8 D RELATIVE NULL 100 78 Grad 100 45 ELE Ge prekers FE Solpositior r 6363 Grad ISTFOSITION Cramer Stop if Geschwindigkeit 25000 e ze DIE Eiad C Gch thereh Fol H Schiiltweite 040000 Grad Abbildung 18 Teilbereich w hrend der Bewegung im Direktbetrieb Grat wird zu Stop Quelle 4 B 50 Stoppen der Bewegung im Direktbetrieb Ein bewegter Antrieb kann mit Stop angehalten werden F 80 Stoppen der Bewegung Stoppt der Antrieb sei es weil die Sollposition erreicht ist oder weil die Bewegung abgebrochen wurde dann werden die zuvor gesperrten Steuerelemente wieder freigegeben Stop wird erneut zu Start Abb 11 50 Auszug aus dem Kapitel Benutzeroberfl che des Pflichtenheftes M15 der neuen Manuellen Justage Beim Programmcode Review der urspr nglichen Manuellen Justage war negativ aufgefallen dass die Aktualisierung eines Steuerelementes an vielen Stellen im Programmcode zu finden war Diese Art der Implementierung ist wartungsunfreundlich und extrem fehleranf llig Deshalb wurden im OOD einige Methoden bereitgestellt die f r die Aktualisierung von Inhalt und Zustand von kleinen disjunkten Steuerelement Gruppen zust ndig sind Nur dort wird die Aktualisierung der Steuerelemente zentral verwaltet Wenn die verbale Funktionsbeschreibung des P
221. nd durch in Spitzklammern eingeschlossene Platzhalter realisiert z B lt Antrieb gt als Platzhalter f r die Bezeichnung des Antriebs der diese Funktion anbietet IV 1 Hauptdialogfenster Manuelle Justage IV 2 Dialogfenster Offset f r lt Antrieb gt IV 1 1 Dialogfenster betreten IV 2 1 Dialogfenster betreten IV 1 2 Antriebsauswahl IV 2 2 Ausgangsdaten IV 1 3 Istposition gt IV 2 2 a aktuelle Istposition IV 1 3 a absoluter Wert IV 2 2 b aktueller Offset 1 amp 6telative Positionierung IV 2 3 Offset f r lt Antrieb gt definieren IV 1 4 Offset f r lt Antrieb gt Relative Null IV 2 3 a entspricht Winkel IV 1 4 a Relative Null setzen IV 2 3 b Offset angeben IV 1 4 b Relative Null aufheben IV 2 4 Dialogfenster verlassen IV 1 4 c Offset IV 2 4 a OR IV 1 4 d Offset f r lt Antrieb gt IV 2 4 b Abbruch anzeigen IV 3 Dialogfenster Offset f r lt PSD gt IV 1 5 Betriebsarten IV 3 1 Dialogfenster betreten IV 1 5 Direkibetrieb gt IV 3 2 Ausgangsdaten IV 1 5 b Fahrbetrieb IV 3 2 a Istposition von Theta IV 1 5 c Schrittbetrieb IV 3 2 b Winkelwert pro Kanal IV 1 6 Bewegungsparameter IV 3 3 PSD Kanaloffset definieren IV 1 6 a Sollposition IV 3 3 a neu zugeordneter Kanal IV 1 6 b Geschwindigkeit IV 3 4 Ausgabedaten IV 1 6 c Schrittweite IV 3 4 a PSD Kanaloffset IV 1 7 Halbwertsbreitemessung IV 3 4 b entspricht Winkel
222. nd schreiben Speichertyp als Eintrag in einer ini Datei ASCII Text HARDWARE INI gt MOTOR lt M gt gt MJ_AnigeDest ___Minimalwert sin Tele O Tabelle 13 Eigenschaften der Sollposition Abb 11 5 Auszug aus dem Datenteil des Pflichtenheftes M15 Zum besseren Verst ndnis wurde eine allgemein bekannte Symbolik Abb II 5 gt z B f r reelle Zahlen gew hlt Eine genaue Typfestlegung wie float w re hier nicht m glich weil die Programmiersprache bei neuen Projekten zu diesem Zeitpunkt noch nicht feststeht Zudem w ren solche Angaben f r Auftraggeber und Anwender schwer verst ndlich Existiert bereits ein Referenzprodukt k nnen die daraus bernommenen Datenelemente speziell gekennzeichnet werden siehe Abb II 5 __ bereits vorhanden anstatt NEU Obwohl fast alle Elemente der neuen Manuellen Justage aus anderen Subsystemen stammen Seite 26 Dekomposition beim Forward Engineering Il 2 Definitionsphase konnten keine Verkn pfungen zu deren Dokumentationen hergestellt werden da die Elemente nirgends detailliert beschrieben werden Nur die Verhaltensspezifikation M14 half in Ans tzen indem sie exemplarische Werte einer Konfigurationsdatei zur Verf gung stellte Die genauen Eigenschaften wurden durch ein problembezogenes Programmcode Review der existierenden Manuelle Justage und der benutzten Subsysteme ermittelt Die neuen Datenelemente wurden wie beim Neuentwurf blich mit dem Anwen
223. nfachten Funktionskomponente mit s mulierten Eigenschaften siehe Abb 1 10 begn gen oder abwarten Prinzipiell besteht auch die M glichkeit des Nutzeroberfl chentests obwohl die Funktionskomponente noch ungetestet ist Voraussetzung hierf r ist jedoch der Abschluss der Implementierungsarbeiten Diese Methode hat aber den Nachteil dass auftretende Fehler nicht eindeutig der Nutzeroberfl che zuzuordnen sind Die Dekomposition bietet zudem die M glichkeit Teile eines Sub oder des Gesamtsystems strukturorientiert zu testen Dies st nur den Funktionskomponenten vorbehalten denn f r Nutzeroberfl chen kann der Gro teil von Methoden nicht einzeln aufgerufen und getestet werden Somit lassen sind nicht dekomponierte Systeme nur auszugsweise kontrollflussorientiert testen Die vorgestellte Herangehensweise zur Dekomposition ist im Kern eine seit l ngerem bekannte und angewandte Technik Dies beschr nkt sich jedoch nur auf die Designphase Problematisch ist hier dass es unterschiedliche Auffassungen ber die zu verwendenden Kommunikationsmuster g bt und dass versucht wird eine Pauschalisierung f r alle An wendungszwecke vorzunehmen Wie I1 3 3 5 zeigt ist dies zwar m glich aber nicht sinnvoll Die Autoren haben die Dekomposition auf den gesamten Softwareentwicklungsprozess erweitert und diesen ausgewertet Um die eigene Arbeit und die nachfolgender XCtl Entwickler zu erleichtern wurden die entstandenen Dokumente stark formalisiert
224. ng Variante und Observer Muster f r die getrennte Version parallel erstellt Hier gab es keine Unterschiede f r die Schrittfolge so dass sie robust genug ist die beiden Kommunikationsmuster zuzulassen Das resultierende Design zeigen Abb II 22 Observer Muster und das Klassendiagramm aus Tab III 3 Polling Variante Wie beim Forward Engineering zeigt der Vergleich des Implementierungsumfanges wieder einen kleinen Nachteil von 8 LOC f r das Observer Muster 816 zu 808 Polling Variante vgl Tab II 8 und Tab II 4 Bei der Nutzeroberfl che ist die Polling Variante mit 438 LOCo etwas umfangreicher als beim Observer Muster 414 LOCo Entsprechend ist der Umfang der Funktionskomponente komplement r d h das Observer Muster hat 402 LOCr und die Polling Variante 370 LOC7z Der Unterschied zwischen den beiden Kommunikationsmustern ist wie beim Forward Engineering minimal Es entsteht mit der Auswahl eines Musters kaum zus tzlicher Aufwand f r die Realisierung der Kommunikation Vielmehr besteht der Unterschied in einer Umverteilung der Verantwortlichkeiten Die Anzahl von verschiedenen Arten der auszutauschenden Nachrichten schl gt sich m Interface des Observer Musters nieder Damit w chst die Differenz zwischen den beiden Mustern mit steigender Komplexit t der Kommunikation Dies darf jedoch nicht auf die Anzahl der ausgetauschten Nachrichten reduziert werden Wenn nur ein einzelner Nachrichtentyp immer wieder versendet wird macht dies k
225. ngen konnten bereits m Vorhinein entweder auf Funktionskomponente oder Nutzeroberfl che eingegrenzt werden Durch die objektorientierten Mechanismen d h hoher Zugriffsschutz und einfaches Schnittstellendesign der Funktionskomponente k nnen diese und die Nutzeroberfl che unabh ngig voneinander und nahezu zeitgleich getestet werden siehe U S Die Geschwindigkeit der Projektentwicklung sollte sich durch die M glichkeiten der Arbeitsteilung generell erh hen weil auch die Implementierung von Funktionskomponente und Nutzeroberfl che grunds tzlich parallel m glich ist siehe I 4 Unter dem gestiegenen Umfang an zu testenden Programmfunktionen vorrangig durch die zus tzliche Schnittstelle der Funktionskomponente leidet vorerst die Entwicklungsgeschwindigkeit Daf r werden aber Verifikation fehlerfreies Arbeiten siehe 3 S 101 und Validation erf llt die geforderte Spezifikation siehe 3 S 101 in der Testphase erleichtert Durch die Dekomposition werden mehr Fehler bereits w hrend der Entwicklung der Funktionskomponente bzw Nutzeroberfl che bemerkt und korrigiert Dadurch treten w hrend der Modulintegration in den Anwendungskontext weniger Fehler auf die analysiert und behoben werden m ssen das f hrt letztendlich zur Fehlerminimierung Auch w hrend und nach der Anpassung der Software an andere Betriebssysteme Portierung sollte die Fehlerwahrscheinlichkeit deutlich sinken weil Funktionskomponente und Nutzeroberfl
226. nskomponente Bei konsequenter Dekomposition sind alle Algorithmen und Daten in der Funktionskomponente zusammengefasst Es besteht so keine Gefahr dass durch Bearbeitung des Programmcodes der Nutzeroberfl che ungewollt Produktfunktionen ge ndert werden Andererseits ziehen nderungen an der Schnittstelle der Funktionskomponente fast immer Anpassungen an der Implementierung der Nutzeroberfl che nach sich In Cl ent Server orientierten Anwendungen oder Subsystemen werden Teile der Funktionalit t zentral durch einen Server bereitgestellt oder verwaltet Die zur Client Server Kommunikation notwenigen Arbeitsabl ufe sind unabh ngig von der Nutzeroberfl che und k nnen durch die Dekomposition in die Funktionskomponente ausgelagert werden obwohl die steigende Leistungsf higkeit heutiger Rechnersysteme diesen Anwendungsfall zunehmend auf zentrale Daten und Ressourcenverwaltung beschr nkt 1 4 4 Kombinierbarkeit von Programmiersprachen Durch die Dekomposition ergibt sich prinzipiell die M glichkeit Funktionalit t und Nutzeroberfl che in verschiedenen Programmiersprachen zu implementieren Durch die Dekomposition k nnte man die Funktionskomponente in einer f r den Anwendungszweck besser geeigneten Programmiersprache entwickeln und eine Dynamic Link Library DLL erstellen die von der Nutzeroberfl che eingebunden wird Linux und Microsoft Windows bieten damit ein Konstrukt f r kompilierte Modulbibliotheken mit einer definierten Schnitt
227. nt TAngle si BOOL CangethotionType tini BOOL CanSetAngleDesttint DOOL CanSetSpeedcint BOOL CanSetAnglevidthiint BOL TManJustage Gethotorcounte LINT 5etRelativezerotint HOOL ResetFelatiwrezerocint BOL 5etoffsettint TAngle Si BO L DoDirecttint BOOL Do rivetint EDirectionmn BOOL DoSteptint EDirectiomn BOOL DoStoptint BOOL DoStatheasurec HA NOYA COL DoStopMeasure BOOL 5etthanneltint BOOL CanResetRelativeerotcini BOOL F n Teo Inf BOL rant ioirect im BOOL CanDoDrive int EirechonuBHOOtL CanDoSteptint EirechoniHOOL ZanDoStopeind BOOL ZanDoStarMeasuren BOL ZanDoStopMeasuren BO OL Seite 47 m_InkMotorTMotor PT AHisType TAaxisType m_Motorld char 512 m_MotionType EMotionType m_AngleDestTAngle Mm_SpeedTSpeed m Angolevvidtn T Angle m_Matorlist Spezialisierung von Attributen Signatur f r Accessor und Mutatormethoden Signatur f r Methoden zur Realisierung der Funktionalit t Kapselung fremder Funktionen weitere Methoden II a UN sMovingdcint BOOL SAGOL sGalibratediint BOOL Si BOL FParsingsxis t LPCSTRYUINT GetDetectord amp isldsgtint GelDetectorNamelBO0L amp iLPESTR HasDetector aiso BOOL 5MeasuringocBOOL 5MeasurerResetl BooL G5elNeasurefrogresscint amp LPSTR nt BOAL GelNMeasureHwh double UpdateDetect org void TManJust age TManJustagel TManJustagen rle lndoguv aldi Ip BOL Has fsetcint BOOL MBa GelMotorldslLFPES
228. nte aus dem Anwendungsfall neue Manuelle Justage eingegangen Im Kapitel II 5 Testphase werden aus dem Anwendungsfall abgeleitete Verfahren zum unabh ngigen Testen von Funktionskomponente und Nutzeroberfl che vorgestellt und bewertet Da ein gro er Teil des heutigen Software Engineering dar n besteht Alt Systeme instand zuhalten und zu sanieren wird in Kapitel III die M glichkeit einer nachtr glichen Dekomposition bei existierenden Softwareprojekten im Reengineering untersucht Um m glichst viele Aspekte bei dieser Art der Dekomposition herauszuarbeiten wird die Trennung der beiden voneinander unabh ngigen Subsysteme Topographie und Manuelle Justage vorgestellt Dazu erfolgt in Kapitel ULI eine Ist Analyse speziell f r die Topographie Danach wird in Kapitel II 2 Restructuring eine allgemeine Schrittfolge f r die Dekomposition in einem Reengineering Prozess ausf hrlich erl utert Sie bildet den zweiten Schwerpunkt dieser Arbeit und w rd exemplarisch jeweils an beiden Subsystemen schrittweise abgearbeitet So kann der Umgang mit einer Vielzahl von Besonderheiten im Programmcode der Anwendunsgsf lle bei der Dekomposition erkl rt werden Im Anhang befinden sich ein Literaturverzeichnis mit weiterf hrenden Nachschlagewerken welche die Grundlage dieser Arbeit bilden Die unter verwendete Materialien aufgef hrten Dokumente wurden f r die Arbeiten mit dem XCtl Projekt ben tigt oder von den Autoren neu er
229. ographnyolLe 4 Balearen rTropogreapayoOLel g 77 TTopographyOld TopographyOld globale Instanz AUSGANGSZUSTAND elass TTrTopogreaphny i private TTopography ken Standard Konstruktor verf gbar TTopography const TTopography amp keinen Copy Konstruktor TTopography amp operator const TTopography amp keinen Zuweisungsoperator static TTopography m_Instance listdie EINZIGE Instanz EE static TTopography GetlInstance istdie einzige M glichkeit zur Instanziierung JI TTopography TTopography m_Instance 0 Initialisierung des Singleton Erzeugung einer Singleton Instanz TIepogrsphy TITopography Getinstanee if m_Instance 0 m_Instance new TTopography return m_Instance wenn noch keine Instanz existierte wurde diese zuvor erzeugt ERGEBNIS Abb Ill 16 Implementierung des Singleton Musters f r die Klasse TTopography Die Nutzeroberfl chen in Form der Dialoge TTopographyExecDlg und TTopographyAdjustDlg erben die Bas sklase f r modalen Dialogfenster TModalDlg ein siehe Klassendiagramm in Tab III 9 und sind damit in ihrer Grundstruktur festgelegt siehe Abb IIL 21 4 Programmcodelayout verbessern optional Die Strukturierung des Programmcodes erfolgte nach den gleichen Kriterien wie bei der getrennten Manuellen Justage Die Dialogklasse TTopographyExecDlg besitzt zur Seite 124 Dekomposition beim Reengineering Ill 2 Restructuring berwachung einer Messung
230. oid OnMeasurestopsonvold ES Attribute EL Methoden der Basisklasse n EZ Verarbeitung von Botschaften BE Antriebsbewegung Messung DD 777 weitere Methoden 6 Zusammenfassen von Funktionalit tsaufrufen Die Identifikation von F und O Bl cken gestaltete sich in den neuen On Methoden von TAngleCt1lDlg problemlos Etwa die H lfte aller Anweisungen konnte anhand des Handle Parameters leicht f r das Auslesen bzw die Aktualisierung der Nutzeroberfl che identifiziert werden Diese Methoden wurden fast komplett durch die entsprechende Variante der Fensterbasisklasse ersetzt um einen h heren Bedienkomfort zu garantieren Damit wurde bspw das Problem mit der Konvertierung von Zahlenwerten gel st Wunschkriterium n M19 Zudem wurde dadurch der Programmcodeumfang reduziert Bei den zuvor benutzen Dekomposition beim Reengineering Ill 2 Restructuring Seite 117 API Funktionen mussten die Zahlen zuerst in einer Zeichenkette formatiert und dann in die Steuerelemente eingetragen werden Die brigen Methoden beschr nken sich entweder auf den Zugriff anderer Subsysteme F Bl cke die Ausgabe von Meldungsfenstern oder die Anpassung des Mauszeigers O Bl cke Auf die zeitaufwendige Analyse der F und O Bl cke konnte verzichtet werden weil pro On Methode selten mehr als ein F Block existierte 7 Erzeugen von Do Methoden Neben 9 Do Methoden alle vom Typ 2 der oben vorgestellten Klassifikation siehe IIIL 2 1 7 dien
231. ommastellen nur bei ganzen bzw reellwertigen Zahlen in einigen Anwendungen kann die Nennung der physikalischen Einheit f r diese Werte erforderlich sein e Anzahl der Zeichen nur bei Zeichenketten Diese Informationen werden in fast allen sp teren Entwicklungsschritten ben tigt Oberfl chen Prototyping 11 2 2 Erstellung von Hilfe System 11 2 3 und Benutzerhandbuch 11 2 4 OOA II 2 5 a und et OOD OLAI a c und d bzw 11 3 2 Implementierung II 4 1 und u U II 4 2 und Test IL 5 1 und 11 5 2 Sie k nnen so in die Vertragsverhandlungen aufgenommen werden wenn sie bereits im Pflichtenheft vollst ndig zusammengetragen wurden Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 23 Um InkonsistenzenT T bei Datenelementen die in mehreren Subsystemen eines Projektes verwendet werden zu vermeiden sind diese nur einmal tabellar sch zu erfassen Alle weiteren Subsysteme verweisen auf das Pflichtenheft wo das benutzte Datenelement definiert ist Stichwort Tabellen und Abbildungsverzeichnis k nnen zum schnellen Nachschlagen der gew nschten Information beitragen Auch eine bersicht ber die Produktfunktionen Leistungsanforderungen Datenelemente und sp ter der Funktionen der Nutzeroberfl che k nnen hinzugef gt werden Weil ein solches Pflichtenheft noch keine konkreten Oberfl chenentw rfe enth lt diese entstehen erst w hrend des Human Interface Prototypings siehe II 2 2 ist die Dekom
232. onsangebot von TManJustage und TAnglecCtl Benennung wurde von TManJustage bernommen 39 Methoden sssssssssssssssssseee 132 Tab III 6 Zus tzlich geforderte Funktionalit t f r TManJustage 30 Methoden 132 Tab 111 7 Durch die Dekomposition entstandene Methoden von TAnglecCt1l die beim Einsatz zu beachten sind 5 Methoden sssssssssssssssssssssssssssssssssssssssssssssssssssssssso 132 Tab III 3 Ausgew hlte Metriken f r die Klassen bei der getrennten Manuellen Justage Observer Muster EE 134 Tab III 9 bersicht zur getrennten Topographie ssessososessoscsessoscsessoscsessoscsessoscseseososessosesecso 135 Tab II1 10 Ausgew hlte Metriken f r die Klassen der getrennten Topographie eeeeee 136 Abb 1 2 XCtl Programm mit Z hler und AreaScan Fenster und Dialog zur Konfiguration der Detektoren Quelle XCtl Programm sssssssssesessesseeeceee 5 Abb 1 3 Use Case Diagramm des XCtl Gesamtsystems rot in dieser Arbeit bearbeitete Subsysteme Quelle nach M1 000000000000000000000000 6 Abb 1 4 Freiheitsgrade der Probe bei der Topographie Quelle nach M1 7 Abk 1 5 Arbeitsplatz RTK14 am Physikalischen Institut cccc000000000000000sssnnnnunuunnnsssssssssssssssssssseee 8 Abb I 6 Bew ltigung der Programmkomplexit t durch Zerlegung in zwei Subsysteme Modularisierung und Dekom
233. optional Abb III 13 zeigt ein Beispiel wo durch die Analyse der Aufrufbedingungen f r Do und Set Methoden innerhalb der Nutzeroberfl che zus tzliche Bedingungen bzw neue Can Methoden gewonnen werden konnten Damit wurde die Robustheit der Funktionskomponente weiter gesteigert weil die Ausf hrung von zustandsver ndernden Methoden an weitere Bedingungen gekn pft wurde Zudem verbessert sich auch die Wi ederverwendbarkeit der Funktionskomponente weil die in diesem Schritt gewonnen zus tzlichen Bedingungen dort nicht mehr nach dem Austausch der Nutzeroberfl chen beachtet werden m ssen Um den Umfang des Programmcodes zu reduzieren wurde hier auf den Aufruf der CanDo Methode in der Nutzeroberfl che verzichtet Weil die Do Methode denselben R ckgabewert wie die Can M besitzt und die Do M bei Nichterf llung sofort verlassen wird war der direkte Aufruf m glich Dekomposition beim Reengineering Ill 2 Restructuring Seite 119 void TAngleceiD e Pig Onlommand EWNp me ald HuyND umge switcha larch 1 case cm_MeasureHWB Halbwertsbreite messen abbrechen if m lnkAngleCtl gt IsMeasuring Messung ist aktiv abbrechen e Geer Se ee KE Aktualisieren der Nutzeroberfl che break Messung beginnen Makro Inquire Hwb ausf hren if m_InkAngleCt1 gt IsMoving break Antrieb ist in Bewegung Abbruch m_IinkAngleCtl gt DoStartMeasure GetHandle CtrlSetText cm_MeasureHWB amp Messung abbrechen
234. osnnnnneenneessnnnnsennesosnnensennessnnnseene 52 Konkretes E EE 52 L EastenBefit EE 18 ER Ee Ee E Lines OF Es I re ee eine ee 20 logische CHE eege 85 M Manuelle DEE EE 6 e EE 17 enner Tel EE 17 MNOP Codemetrik Maximum Number Of Parameter 20 Mutator Methode u a a Eu Re an 38 N nicht zustandsver ndernde Methoden oeeeeeeesseeeeesesserrrsssssrrrersesssrterrssssrttrrrsssstttresssstteresssseteressseereeresseere 44 NOA Codemetrik Number Of Attributes eeeeseesensesseesssscensssserssseerssseerssscressstrrssstrrsssersseseressseressseeereseeerseeeere 20 NOC Cod emetik Number Of Classes Near 20 NOCON Codemetrik Number Of Constructors uussssseseesnnsssesnnnnnsnennnnnnnennnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnenn 20 NOO Codemetrik Number Of Operapnonst 20 NOOM Codemetrik Number Of Overriden Methode 20 O ODer ehe nenin WEE Siehe Oberfl chenprototyp OberBlachen Prololyp eene Dee ae nee 28 objektorientierte Analyse 38 objektorientierte Programmierung nnneoonso00so0eeeeerennssssssssssererrreonsssssssssssetrrrosssssssssssseeerrrosesssssssssseeereeeenee 9 O Bl ck EE 106 S E KEE Siehe Beobachter ODserver NSIET ena eege de O A AA A 51 VON See ee ee ee Siehe objektorientierte Analyse P Pfilichtenheft u 222 as Eee ale see 21 PPrivM Codemetrik Percentage of Private Member 20 PProtM Codemetrik Percentage of Protected Member 20 PPubM Codemetrik
235. osos000 87 11 57 UML Klassendiagramm der Manuellen Justage mit Testoberfl chenklasse TMa nJustageTestD1lg E 88 11 58 Ausschnitt aus dem CTE Diagramm zum Test der Nutzeroberfl che der neuen Manuellen Justage ees 91 11 59 Ausschnitt aus dem Testdokument M25 Testfall 1 2 000000000000000000000000000000000 93 Dekomposition von Software Systemen Abk rzungsverzeichnis V Abb III 1 Vorteile des Reengineering gegen ber dem Forward Engineering z I zusammengetragen aus A unse 97 Abb III 2 Dialoge Topographie Durchf hrung links und Topographie Einstellungen rechts 0 000 sssssssssssssssnnnuununnsssssssssssssssssssssssnnnnnssssssssssese 101 Abb II 3 Konstruiertes Beispiel zur Verschmelzung zweier O Bl cke der entstandene F Block kann als Ganzes als Do Methode ausgelagert werden 107 Abb II 4 Konstruiertes Beispiel mit nicht verschiebbaren O Bl cken hier werden auch die untergeordneten bedingten Anweisungsfolgen untersucht 108 Abb 111 5 Konstruiertes Beispiel f r die Auslagerung eines F Blocks in m D8 Meihode pl en N Ensign 108 Abb III 6 Konstruiertes Beispiel f r die Auslagerung eines F Blocks in eine Do Methode Eeer eege 109 Abk II 7 Konstruiertes Beispiel f r die Auslagerung eines F Blocks ineme D Methode TYPI eege ees 110 Abb I S Konstruiertes Beispiel f r die Auslagerung einer CanDo Methode eeesossssssseseeeceeoo 111 Ab
236. pelt auszuw hlen testen Dazu werden nacheinander die drei Teilbereiche bedient Dann wird das Dialogfenster verlassen und wieder betreten um das Wiederherstellen der zuletzt benutzten Einstellungen B 10 zu berpr fen 12 Testf lle Dar n enthalten ist auch das Testen der Verf gbarkeit des PSD Detektors Abschlie end wird das Programm komplett beendet und mit einer anderen Konfigurationsdatei neu gestartet Dabei wird das Wiederherstellen der zuletzt benutzten Einstellungen nach einem Neustart gepr ft Die Funktionen PSD Offset und Halbwertsbreite d rfen aufgrund der ge nderten Hardwarekonfiguration nicht mehr verf gbar sein 3 Testf lle Der gesamte Testvorgang wurde mehrfach durchgef hrt Bei den ersten beiden Tests war die Zustandsaktualisierung der Steuerelemente abgestellt d h die Nutzeroberfl che d rfte keine Can Methode aufrufen um sich an Zustands nderungen anzupassen Der erste Test sollte berpr fen ob die Nutzeroberfl che richtig mit der Funktionskomponente verkn pft ist Dazu wurden die laut CTE Diagramm freigegebenen Steuerelemente Funktion ja mit g ltigen Eingaben getestet Diese mussten von der Funktionskomponente akzeptiert werden Nach dem erfolgreichen Durchlauf wurde ein zweiter Test mit der gleichen Implementierung durchgef hrt Nun wurden die laut CTE Diagramm gesperrten und ausgegrauten Steuerelemente Funktion nein benutzt Folgende Aktionen wurden durchgef
237. pitel festgehalten und bildeten das Grundger st f r die Entwicklung der Oberfl chen Prototypen siehe II 2 2 Nachdem die Prototypen erstellt und mit den Mitarbeitern des Physikalischen Institutes abgestimmt waren wurden diese Notizen wieder entfernt Der von den Anwendern favorisierte Oberfl chenentwurf wurde nachtr glich in dieses Kapitel aufgenommen und beschrieben Weil der Entwurf aus drei Dialogfenstern besteht bilden diese die erste Gliederungsebene des Kapitels Dort ist jedes Fenster mit exemplarischen Werten f r die Bedien und Steuerelemente abgebildet Abb II 2 rechte Seite In der n chsten Gliederungsebene befinden sich jeweils die Punkte aus dem Kapitel funktio nale Beschreibung siehe Abb II 3 Es m ssen alle Produktfunktionen genannt werden Zus tzlich wurden auch oberfl chenspezifische Funktionen z B zum Betreten und Verlassen des Dialogfensters aufgenommen die im Funktionsteil nicht beschrieben werden konnten Den Produktfunktionen z B Abb II 8 lt D wurden die betroffenen Steuerelemente untergliedert Wie im Beispiel der Istposition k nnen das auch mehrere sein sowohl Bildlaufleiste als auch Eingabefeld zur Anzeige der Antriebsposition Die Gliederungspunkte sind entweder die Beschriftungen der Steuerelemente in Hochkommata Abb I 8 __ oder eine abstrakten Aufgabenbeschreibung Abb II 8 C_D bei unbeschrifteten Steuerelementen Variable Anteile in der Beschriftung der Steuerelemente si
238. position von Nutzeroberfl che und Funktionskomponente hier bereits voll umgesetzt Der Oberfl chenentwurf erm glicht Auftraggeber und Anwender einen realistischen Einblick n das sp tere Produkt weil die Produktfunktionen und daten visualisiert werden Um den Abstraktionsgrad des Pflichtenheftes zu senken k nnen die mit dem Auftraggeber abgestimm ten Oberfl chenfenster nachtr glich in den Gliederungspunkt Nutzeroberfl che aufgenommen werden Dort erfolgt die Erl uterung der Oberfl chen indem die Bedien oder Steuerelemente beschrieben und durch Querverweise mit dem Daten bzw Funktionsteil verkn pft werden F r eine konkrete Anwendung siehe z B Abb II 9 Die Dekomposition bleibt dabei bestehen weil Funktionen und Nutzeroberfl che weiterhin deutlich von einander getrennt sind Besonders empfehlenswert finden die Autoren die Erweiterung der oben vorgestellten Num merierung auf die Elemente des neuen Gliederungspunktes Dazu sind die Beschreibungen von Bedien und Steuerelementen mit B lt bb gt eindeutig zu adressieren siehe z B Abb II 9 Dialogfenster betreten anzeigen der physikalischen Einheit f r alle Ein und Ausgabewerte o Verweis auf aktuelle Istposition 7 H Diizer f r Ti anzeigen und aktuelles Offset anzeigen beschriften der Titelleiste mit der aktuelle Istposition Bezeichnung des Antriebs e aktueller Offset aktuelle Istposition anzeigen E entspiicht Winkel aktu
239. position in GUI und Funktionskomponentenklasse H Abk 1 7 Schichten Architektur am Beispiel der getrennten Topographie 00000000000000 0 10 Abb 1 8 Evolution der Nutzeroberfl che Oberfl chen Prototyping 2 0 00000ss0ss000000ssssssccee 12 Abb I 9 Beispiel der Schriftformatierung ber eine individualisierbare Symbolleiste oben im Vergleich zum Ausschnitt des Dialogfensters Zeichen unten in Microsoft Word 13 Abb 1 10 bergang von der simulierten Funktionskomponente ber die Wartung zum Endprodukt 2 ceeseeossssssssssssssssssssnsnsnnssssssssssssssssssssssssnnnsssssssssssnse 14 Abk I 11 OLE Automation mit Microsoft Excel aus einem anderen Programm heraus 1 starten 2 Datenerfassung 3 Diagrammerstellung 000000000000000000000000000000000000e 16 Abk II 1 Dialogressource zur urspr nglichen Manuelle Justage 02000000000000sssss00000sssssssccee 18 Abb II 2 Realisierung von Funktionen und Daten als Bedien und Steuerelemente eines Oberfl chenfensters am Beispiel des Dialogfensters Offset f r lt Antrieb gt sssssssseeseeeee 23 Abb II 3 Auszug aus der Gliederung des Pflichtenheftes M16 Kapitel funktionale Beschreibung u uk 24 Abb II 4 Auszug aus dem Funktionsteil des Pflichtenheftes M16 0 00000000000ss0000000ssssscc e 24 Abb II 5 Auszug aus dem Datenteil des Pflichtenheftes M16
240. posureSettings TExposureSettings Time Count m_InkDetector gt MeasureStart Messung fortsetzen es wurde NICHT gemessen oder es soll NICHT gestartet werden else m_IinkDetector gt SetExposureSettings TExposureSettings Time Count JI ERGEBNIS Abb 111 20 Zusammenfassen gleichgesinnter Do Methoden durch zus tzlichen Parameter 11 Kennzeichnung nicht zustandsver ndernder Methoden und konstanter Parameter optional In der Funktionskomponente TTopography konnten alle 42 nicht zustandsver ndernden Methoden betrifft alle Get Is und Has M als const member functions deklariert werden Dies war auch bei 7 Do Methoden m glich weil dort keine Attribute aus TTopography geschrieben sondern nur Funktionen anderer Subsysteme ausgef hrt werden In jeder vorkommenden Methode konnten alle Parameter als konstant gekennzeichnet werden wie z B bei void DoSetTimes const DWORD const DWORD const BOOL F r die Methoden SetDetector und SetMonitor beschr nkt sich das allerdings auf die Deklaration ihrer Parameter als konstante Zeiger es entstanden so SetDetector TDetector const und SetMonitor TDetector const 12 Suche und Korrektur von Fehlern optional Die verbesserte Lesbarkeit des Programmcodes hatte deutliche Auswirkungen auf die Fehlerbeseitigung Es wurden 21 neue Fehler entdeckt und behoben Die meisten davon Seite 128 Dekomposition beim Reengineering Ill 2 Restructuring waren fehlerhafte Grenzwerte f r d
241. pw stellvertretend f r die Beschriftung der Statuszeile wo der Fortschritt der Messung angezeigt wird 3 Zustand von Steuerelementen e Zustandsunver nderliche Steuerelemente sind unabh ngig vom aktuellen Systemzustand oder sollen sich nicht an diesen anpassen Sie sind entweder immer freigegeben oder gesperrt und ausgegraut Daf r sind keine Testdaten n tig e Zustandsver nderliche Steuerelemente sind im Kapitel Benutzeroberfl che des Pflichtenheft OR lt bb gt Element leicht am Bedingung Absatz identifizierbar Wenn das Steuerelement eine Produktanforderung realisiert gen gt auch ein Bedingung Absatz bei der zugeordneten Produktanforderung ein F lt gt Element ist also vorhanden F r solche Steuerelemente wurden die beiden quivalenzklassen o Funktion ja Steuerelement soll im aktuellen Programmzustand freigegeben sein o Funktion nein Steuerelement muss gesperrt und ausgegraut sein definiert Weil z B f r das Kombinationsfeld Antrieb ausw hlen eine Bedingung siehe Abb I 9 lt D angegeben ist wurden die Testdaten Abb 11 58 C__ erstellt ausgew hlt Auswahl I7 mit Funktion DF kein Antrieb Tit mega i s ini Dateien 1 EEE SEI erstes Betreten gv i DC Teilbereich 1 Ste ersten verf gb Antrieb im Direktbetrieb testen ees Ze Gescht und Sollposition eingeben er Bewegung starten Sen ei Bewegung stoppen Sp or B
242. r Daten aufgef hrt Weil das Referenzprodukt des zu realisierenden Subsystems bereits existierte konnte die Durchf hrbarkeitsstudie entfallen TAngleControlDlg 457 Tab Il 2 Ausgew hlte Metriken f r die Klassen der urspr nglichen Manuellen Justage Die in Tab II 2 verwendeten Metriken wurden dem CASE Werkzeug Togethersoft Together 5 5 entnommen Sie wurden ausgew hlt um Programmcodestruktur zugriffsschutz Design und Umfang der in dieser Arbeit vorgestellten Subsysteme effektiv zu bewerten Dabei werden der Zustand vor und nach der Dekomposition und die verschiedenen Designmuster verglichen Alle nachfolgenden Metrik bersichten enthalten die gleichen Elemente e LOC Lines Of Code ist die Anzahl der Codezeilen ohne Leer und Kommentarzeilen e NOA Number Of Attributes entspricht der Anzahl an Attributen einer Klasse e NOO Number Of Operations ist die Anzahl der Methoden und Operatoren einer Klasse ohne Kon und Destruktor en e NOCON Number Of Constructors umfasst alle Konstruktoren einer Klasse Destruktoren werden nicht erfasst weil es pro Klasse immer genau einen gibt e NOOM Number Of Overridden Methods ist die Anzahl aller berschriebenen Methoden und Operatoren der eingeerbten Basisklasse n e PPrivM Percentage of Private Members zeigt den prozentualen Anteil an private Attributen Methoden Operanden Kon Destruktoren e PProtM Percentage of Protected Members ist der prozentuale Anteil an
243. r getestet werden kann Um die Wechselwirkungen zwischen den Teilbereichen zu berpr fen wurden zwei zus tzliche Testskripte eingef gt Diese sechs Testskripte entstanden am Ende der Analyse und Definitionsphase Sie wurden in dem separaten Dokument M18 beschrieben wo die vom Anwender abzuarbeitenden Schritte und die vom Programm durchgef hrten Bildschirmaktualisierungen beschrieben werden siehe Abb II 59 In Aktion sind f r jeden Sch die Handlungsanweisungen angegeben Die durch den Anwender zu kontrollierenden Bildschirmaktualisierungen sind in Ereignisse und Ausgaben fett hervorgehoben In normaler Schrift werden Hinweise z B Zustands nderungen gegeben Schritt Ereignisse und Ausgaben i Auswahl der Antriebe Azimutal Hot das Dialogfenster wird f r die Testf lle Beugung Grob und DF im vorbereitet Kombinationsfeld Antrieb ausw hlen ii Auswahl von Direktbetrieb Fahrbetrieb und Schrittbetrieb in den drei Teilbereichen iii erneute Auswahl von Beugung Grob im Kombinationsfeld Antrieb ausw hlen des zweiten Teilbereichs Auswahl von Tur im Kombinationsfeld i Parameter von Tilt werden angezeigt Antrieb ausw hlen ii Istposition steht auf 0 0 arcmin iii aufheben ist ausgegraut und gesperrt iv Halbwertsbreite messen ist freigegeben Abb 11 59 Ausschnitt aus dem Testdokument M18 Testfall 1 Der automatisch ablaufende Regressionstest wi
244. rammzust nden unter denen die Methoden ausgewertet werden sollen Sie stellen eine Kombination aus den Betriebsarten dem Antriebs Offset dem Bewegunsgsstatus eines Antriebs sowie der Halbwertsbreitenmessung dar In jedem Programm zustand werden die R ckgabewerte aller 18 Methoden auf ihre Richtigkeit hin berpr ft Das zweite Diagramm beinhaltet die berpr fung der Verf gbarkeit eines ausgew hlten Antriebs und Detektors und die berwachung ihrer Daten in den einzelnen Zust nden Die daf r zust ndigen 11 Methoden werden mittels 22 Testdaten und 12 Testf llen berpr ft W hrend das erste Diagramm haupts chlich zur Validation der Projektspezifikationen diente wird hier die Kopplung der neuen Manuellen Justage mit den ni ederen Subsystemen haupts chlich also der Hardware bewertet Auch hier werden in jedem Programmzustand alle Methoden parallel beobachtet Zustands nderungen wurden durch die Steuerung der Hardware z B Bewegen und Anhalten eines Antriebs erreicht Die Testf lle f r die brigen nicht zustandsver ndernden Methoden ausgenommen den log schen Operationen aus Diagramm eins sind in einem dritten Diagramm mit den zustands ver ndernden Set und Do Methoden zusammengefasst Da diese Methoden Eingaben erfordern und sich die Testdaten teilweise berschneiden wurden sie in einem CTE Diagramm kombiniert Es umfasst 4 Calc 7 Do 10 Set sowie die zur Auswertung n tigen 8 Get Methoden Dieses CTE Diagramm
245. rd in unregelm igen Abst nden f r das gesamte System oder nach Wartungsarbeiten angewandt Seite 94 Dekomposition beim Forward Engineering Il 5 Testphase 11 5 3 Zusammenfassung Durch die strikte Aufgabenteilung zwischen Funktionskomponente und Nutzeroberfl che ist ein bersichtlicher und strukturierter Programmcode entstanden siehe II 4 3 der die Fehlersuche und korrektur erleichtern sollte Das bei der Funktionskomponente der Manuellen Justage angewendete Testverfahren ist zwar kontrollflussorientiert bleibt aber selbst f r einen Co Anweisungs berdeckungstest ungen gend Der Grund ist dass die Implementierung der Funktionskomponente auch m gliche Probleme bei der Kommunikation mit der Hardware ber cksichtigt Da die verschiedenen Fehlerzust nde nur durch die reale Hardware z B durch Unterbrechung der Verbindung mit der Controllerkarte im richtigen Zeitpunkt ausgel st werden kann der Test diese Fehlerbehandlung nicht abdecken So k nnen nicht einmal alle Knoten des Kontrollflussgraphen erreicht werden Trotzdem hat dieses Testverfahren nach den Erfahrungen der Autoren eine sehr stabile Funktionskomponente zum Ergebnis Zudem sind Hardwareausf lle sehr seltene Fehler bei denen der gesamte Messplatz untersucht und anschlie end neu konfiguriert werden muss Beim Abnahmetest wird allgemein gegen die Spezifikation getestet d h die eigentlichen Produktfunktionen werden verifiziert validiert und auf Vollst ndigkeit
246. relemente siehe Abb II 27 Seite 56 Dekomposition beim Forward Engineering II 3 Designphase TInterfaceTimer TManJustage TManJustageDlg Funktionskomponente Nutzeroberfl che m 1nkManJustage gt DoDirect m lnkTimer gt Start S m InkInterface gt OnTimer m InkManJustageDlg gt OnMotionStarts OnTB ControlsEnable FALSE OnTB Positions m inkManJustage gt GetAngle Ho DH T m InkInterface gt OnTimer m 1nkManJustageDlg gt OnMotionProgress OnIB Pos tT sast D m inkManJustage gt GetAngle 5 D D oO E m iInkInterface gt OnTimer S m 1nkManJustageDlg gt OnMotionStops OnTB ControlsEnable TRUE OntB Positicshefl m inkManJustage gt GetAngle m 1nkTimer gt Stop Abb 11 27 Interaktionsdiagramm f r Observer Muster in der neuen Manuellen Justage w hrend der Antriebsbewegung 11 3 3 4 Die Polling Variante Neben der im vorigen Kapitel beschriebenen eigentlichen Vorgehensweise f r das Observer Muster gibt es eine zweite M glichkeit zur Umsetzung einer Subjekt Beobachter Beziehung Diese Variante wird allgemein als Polling bezeichnet Polling ist eine Programmiertechnik bei der das Auftreten eines Ereignisses durch st ndiges Abfragen ermittelt wird aus 10 Angewendet auf die Dekomposition bedeutet dies dass die Nutzeroberfl che Konkreter Beobachter das Auftreten eines
247. rerosesssssssssseerrreorssssssssssseerereeeno 110
248. rieb schienen diese zu komplex Deshalb entstanden zwei Entw rfe wo nur die Daten eines ausgew hlten Antriebs angezeigt werden siehe Abb I 8 mittlerer Entwurf Die Anzahl der Steuerelemente konnte so auf 3 reduziert werden Der letzte Vorschlag versuchte diese beiden Konzepte zu kombinieren siehe Abb LS Entwurf ganz rechts indem nur die wichtigsten Parameter der drei Antriebe und die ausgew hlte Statusinformationen des aktuell ausgew hlten Antriebs angezeigt wurden Aufgrund der komfortablen und vielschichtigen Gestaltungsm glichkeiten wurde die Borland Delphi Entwicklungsumgebung zur Erstellung der Oberfl chenentw rfe benutzt So entstanden schnell und einfach Realisierungen die mit einer vom XCtl Projekt unabh ngigen Pseudofunktionalit t belegt waren Den Mitarbeitern des Physikalischen Institutes wurde schlie lich ein komplexer und der letztgenannte Dialog vorgestellt wobei berraschend der komplexere Vorschlag favorisiert Seite 30 Dekomposition beim Forward Engineering Il 2 Definitionsphase wurde Der entscheidende Vorteil war die Sichtbarkeit aller Antriebsparameter Neben minimalen Layoutver nderungen vgl Abb I 10 oben mit Abb II 10 oben wurde zudem der Wunsch einer weiteren Produktanforderung ge u ert der als PSD Offset nachtr glich in das Pflichtenheft aufgenommen werden musste Hanuelle Justage NEU 7 7 RELATIVE NULL mooo o E aufheben 294 3 HT Direktbetrieh F2 Sollpas
249. rittweite Betriebsarten 11 7 Halbwertsbreitenmessung 11 5 1 Direktbetrieb 11 8 lt PSD gt Offset 11 5 2 Fahrbetrieb 11 5 3 __Schrittbetrieb Abb Il 3 Auszug aus der Gliederung des Pflichtenheftes M15 Kapitel funktionale Beschreibung Dazu geh ren die ben tigten physikalischen Vorg nge und Begrifflichkeiten sowie der Zweck der Datenelemente Um Missverst ndnisse zwischen Entwicklern und Auftraggebern zu vermeiden wurden alle Fachbegriffe nur einmalig im Text erl utert und fett hervorgehoben Dazu gibt es ein Stichwortverzeichnis siehe M15 Anhang B in dem die Seitenzahlen der Begriffsdefinitionen bzw Verweise auf andere Begriffe zu finden sind Im Stichwortverzeichnis aufgef hrte Fachtermini sind bei jeder Verwendung im Text kursiv formatiert _ F 70 Starten der Bewegung im Direktbetrieb Nach der Beschleunigungsphase bewegt sich der Antrieb mit der angegebenen Geschwindigkeit um kurz vor dem Ziel abzubrem nd an det Sollposition Zu halten Wenn die Sollposition gr er bzw kleiner ist als die Istposition Dewegt sich der Antrieb vorw rts bzw r ckw rts Die maximale Abweichung zwischen der angefahrenen und der gew nschten Sollposition darf macmal OeathBand che Tabelle 14 betragen Wenn Ist und Sollposition bereinstimmen findet keine Bewegung statt Die Genauigkeit betr gt hier wiederum Deathband d Bedingung ar AnH darf sich nicht bewegen Wenn eine Sollposition eingegeben wird di
250. rn die f r den Anwender sichtbar sind Davon konnten 50 bereits w hrend der Schrittfolge einige sogar allein durch Anwendung dieser korrigiert werden siehe 12 Die intensive Besch ftigung mit dem Programmcode im Laufe der Dekomposition erlaubte es die brigen Fehler am Ende der Dekomposition zu entfernen Die Dekomposition macht sich jedoch negativ im Programmcodeumfang bemerkbar Von urspr nglich 457 LOC ist die Anzahl auf 808 LOC gestiegen Zuwachs von 85 vgl Tab II 2 und Tab III 4 Abz glich der deutlich gestiegenen Kommentierung relativiert sich der Zuwachs auf nur noch 40 von 342 LOC auf 479 LOC Verantwortlich ist daf r fast ausschlie lich die in 4 vollzogene Auslagerung der Behandlung von Steuerelementbotschaften aus Dlgq_OnCommand in separate Methoden Dadurch waren allein f r die mit Funktionalit t belegen Steuerelemente mindestens 9 zus tzliche LOC notwendig F r die 20 Steuerelemente ergibt dies allein 180 LOC Durch die Verteilung des Programmcodes verringert sich der durchschnittliche Methodenumfang f r die Nutzeroberfl che wesentlich Aus urspr nglich 57 LOC 8 NOOo wurden 11 LOC 37 NOOo Die Anzahl der Attribute sank von 11 NOAo auf 6 NOAo Im Vergleich dazu besitzt die Funktionskomponente einen durchschnittlichen Umfang von 8 LOC 46 NOOr und 4 NOA7 Attribute Der Vergleich von Forward und Reengineering ist am Beispiel der Manuellen Justage nicht einfach Erstens hat die neue Manuellen
251. rst hiernach kann das Pflichtenheft um die Nutzeroberfl che erweitert werden und Hilfe Systeme sowie Benutzerhandb cher k nnen entstehen Diese Arbeitsteilung wird in der Designphase fortgesetzt indem das OOA Modell zur sp teren Funktionskomponente verfeinert wird und parallel die Oberfl chenklassen entstehen Zur Erstellung des OOD muss gemeinsam ein Kommunikationsmodell ausgew hlt und an das jeweilige Design angepasst werden Hier findet die eigentliche Dekomposition statt Die Dokumentation kann dann wieder parallel erfolgen weil jeder Entwickler nur seine Klassen beschreiben muss In der Implementierungsphase liegt der Schwerpunkt auf der L sung des eigentlichen Anwendungsproblems Die Kodierung von Funktionskomponente und Oberfl chenklassen kann v llig unabh ngig stattfinden Die Programmierer m ssen sich dazu nur an die im Design festgelegten Richtlinien halten W hrend dieser Phase k nnen fehlende Operationen der Funktionskomponente sichtbar werden die der Nutzeroberfl chenprogrammierer ben tigt Als Folge dessen stellt er nderungsw nsche an den Programmierer der Funktionskomponente der diese Operationen bereitstellen und dokumentieren muss Der abschlie ende Test der Nutzeroberfl che ist nur mit einer lauff higen Funktionskomponente m glich Das bedeutet dass diese vollst ndig implementiert und getestet sein muss Steht diese noch nicht zur Verf gung kann sicher der Tester der Nutzeroberfl che vorerst mir einer verei
252. s n diesem Abschnitt der Softwareentwicklung empfiehlt es sich gro e Projekte in mehrere Subsysteme zu Paketen siehe 2 S 205 zu zerlegen Dadurch kann pro Subsystem eine Funktionskomponente als Klasse erstellt werden wobei der Klassenbezeichner den Charakter des Subsystems widerspiegeln sollte Der wichtigste Teil der objektorientierten Analyse ist der Entwurf einer ffentlichen Schnittstelle f r Funktionskomponenten Um die Komplexit t bersichtlich zu gestalten und gleichzeitig eine hohe Flexibilit t Robustheit dieser Klasse zu garantieren wird ein von den Autoren zusammengestelltes Muster vorgestellt Dies beinhaltet im Wesentlichen eine Klassierung der Methodenbezeichner durch Pr fixe e Nach 11 S 95ff soll der direkte Zugriff auf Datenelemente ber eine ffentliche Schnittstelle vermieden werden Deshalb bedient man sich so genannter Accessor und Mutator Methoden zum Lesen und Schreiben eines gleichnamigen Attributes Allgemein blich ist die Benennung als Get Set Methoden z B GetValue und SetValue f r das Attr butm_Value e Do Methoden initiieren die Steuerung der Programmfunktionalit t oder Berechnungen z B DoDivide e Wenn die Ausf hrung von Set Do Methoden an Bedingungen gekn pft st K nnen diese in Can Methoden ausgelagert werden z B CanDoDivide und CanSetValue Die CanDo und CanSet Methoden sollen sp ter das Ergebnis der Bedingung zur ckgeben So kann die
253. s in eine Do Methode Typ1 Dekomposition beim Reengineering Ill 2 Restructuring Seite 109 Typ 2 Wird die ausgelagerte Methode fr hzeitig ohne R ckgabewert verlassen ist false und am Ende des Methodenrumpfes t rue zur ckzugeben Die aufrufende Methode darf nur bei t rue fortgesetzt werden und ist bei false zu verlassen WEE ek een One number user password deklarieren und mit Eingaben aus Nutzeroberfl che initialisieren FFY if RasIsDeviceBusy return Leitung ist belegt CRasDialupPacket packet number packet UserName user packet Password password RasSendPacket packet W hlfortschritt im Fenster anzeigen AUSGANGSSITUATION EE EEN EE number user password deklarieren und mit Eingaben aus Nutzeroberfl che initialisieren if m_InkFunk gt DoDialup number user password false return W hlfortschritt im Fenster anzeigen bool TDialup DoDialUp String number String user String password if RasIsDeviceBusy return false Leitung ist belegt CRasDialupPacket packet number packet UserName user packet Password password RasSendPacket packet return true ausgelagert aus TDialupWizardDiIg OnDialup ERGEBNIS Abb Ill 6 Konstruiertes Beispiel f r die Auslagerung eines F Blocks in eine Do Methode Typ2 Seite 110 Dekomposition beim Reengineering Ill 2 Restructuring Typ 3 Sonst wird die neue Do Methode mit einem R ckgabewert verlassen
254. sMoving Motor ist nicht in Bewegung if m_Motor gt SetSpeed speed return SpeedErr unzul ssige Geschwindigkeit else return MoveErr istin Bewegung m_Motor gt StartMove Bewegung starten Zustandsver nderung aValid true recurn NOTLA AUSGANGSZUSTAND Estatus TMotor Doscear Move double speed Boolean aValid false Initialisierung des Ausgabeparameters EStatus result if m_Motor gt CanDoStartMove speed amp result return result m_Motor gt StartMove Bewegung starten Zustandsver nderung aVal d true recurra Noker Bedingungen f r den Start einer Bewegung bool TMotor CanDoStartMove double speed EStatus result if m_Motor gt IsMoving Motor ist nicht in Bewegung if m_Motor gt SetSpeed speed unzul ssige Geschwindigkeit result SpeedErr return false zustandsver ndernde Anweisung nicht ausf hren else istin Bewegung result MoveErr return false zustandsver ndernde Anweisung nicht ausf hren return true ERGEBNIS Abb 111 8 Konstruiertes Beispiel f r die Auslagerung einer CanDo Methode v Das Projekt ist zu kompilieren zu linken Ein Regressionstest der benutzenden Subsysteme sollte durchgef hrt werden 9 Erstellung von CanSet und Gewinnung zus tzlicher Bedingungen f r CanDo Methoden optional Es gibt F lle wo Do und Set Methoden nur unter immer gleichen Bedingungen au
255. sfall Manuelle Justage nach der allgemeinen Schrittfolge f r die Dekomposition Im Folgenden werden ausgesuchte Schwerpunkte besondere Schwierigkeiten und Abweichungen zum vorherigen Anwendungsfall erl utert 1 Erstellung neuer Dateien F r die getrennte Topographie wurden die Dateip rchen TP_GUI H TP_GUI CPP f r die Klassen der Nutzeroberfl che und TP_FUNK H TP_FUNK CPP f r die Funktionskomponente erstellt Weil die Bezeichner der urspr nglichen Klassen die Zugeh rigkeit zum Subsystem Topographie gut erkennen lie en wurden f r die getrennte Topographie diese Bezeichner bernommen Dazu mussten aber d e vorhandenen Klassen neu bezeichnet werden 2 Behandlung von Ans tzen vorhandener Funktionskomponenten In diesem Subsystem existierte bereits der Ansatz einer Funktionskomponente in Form der Klasse TTopographyOld Diese diente ausschlie lich zur Initialisierung und Sicherung von Attributen die durch beide Dialoge gemeinsam genutzt werden Im Konstruktor werden 12 Attribute mit festen Zahlwerten und in der einzigen Methode Initialize werden weitere 6 Attribute mit Werten aus einer Konfigurationsdatei initialisiert Der Zugriff erfolgt f r beide Dialoge durch die in TTopographyOld deklarierte friend Relationen Diese Klasse wurde in die TP_FUNK H und TTopographyo ld h5SmallAngleside DO0L nMumberycle YORD ForkFointioat ontrolRangetoat Zontrolsteptoat Fucvestepfoat HMas ngleEscapefloat MeasurementT
256. siehe Abb II 7 avalid Parameter Jede Anweisung aus dem genannten Bereich von Do Methoden die als Bedingung zur Ausf hrung aller zustandsver ndernden Anweisungen fungieren k nnen in eine neue CanDo Methode verschoben werden Dies ist insbesondere der Fall wenn eine Bedingung zum fr hzeitigen Verlassen der Do Methode f hrt Alle Parameter der Do Methode die in den Dekomposition beim Reengineering Ill 2 Restructuring Seite 111 ausgelagerten Anweisungen verwendet werden m ssen an die CanDo M weitergereicht werden Deklaration und Initialisierung von lokalen Variablen der Do Methode die in der CanDo M benutzt werden sind in diese zu kopieren Attribute der Klasse werden nicht ge ndert da nur nicht zustandsver ndernde Anweisungen ausgelagert wurden Wenn die Programmiersprache dies erlaubt sind alle CanDo Methoden als nicht zustandsver ndernd zu kennzeichnen Die CanDo Methode darf nur true zur ckgeben wenn alle Bedingungen die Ausf hrung der zustandsver ndernden Anweisungen in der Do M erlauben Am Anfang der Do Methode ist die CanDo Methode aufzurufen und der R ckgabewert auszuwerten Danach erfolgt die bisherige Deklaration und Initialisierung der lokalen Variablen und Ausgabeparameter von denen u U einige entfernt werden k nnen von den meisten Compilern als Warnung angezeigt Estatus TMotor DoStartMove double speed bool aValid aValid false Initialisierung des Ausgabeparameters if m_Motor gt I
257. skelett sind grundlegende Anspr che an die Nutzeroberfl che festzuhalten Dazu k nnen u a Men struktur sowie Anzahl und Zweck von Dialogfenstern und deren Zuordnung zu den einzelnen Subsystemen z hlen bei der objektorientierten Softwareentwicklung ist dies i d R ein OOA Modell gt dem n Softwareentwickler n die bei Gespr chen zwischen Auftraggeber und nehmer oder bei informalen texturellen Beschreibungen eingesetzt werden siehe S 110 Seite 22 Dekomposition beim Forward Engineering Il 2 Definitionsphase F r jedes Pflichtenheft ben tigt man somit die folgenden Gliederungspunkte e Funktionen e Daten e Leistungsanforderungen Dynamik von Daten und Funktionen e Nutzungsoberfl che Anspr che an diese e Einsatzumgebung Qualit tsmerkmale Je nach Anwendungszweck spielen nat rlich auch andere Punkte eine wichtige Rolle auf die hier jedoch nicht eingegangen werden kann Ein universelles Gliederungsmuster wird bei 2 S 115ff vorgestellt Ein einfaches Mittel f r einen semiformalen Ansatz ist die fortlaufende Nummerierung der Elemente aus dem Funktions Daten und Leistungsanforderungsteil Nach 2 S 1107ff ist die Kategorisierung mit F lt ff gt f r Funktionen D lt dd gt f r Daten und L lt 11 gt f r Leistungsanforderungen eine M glichkeit Durch den Einsatz deutlich unterscheidbarer Formatierungen zahlreicher Abbildungen und Tabellen kann die Eindeutigkeit der verbalen Ausf hrungen
258. skomponente ber die Nutzeroberfl che auf die Methoden des Observer Interface zu beschr nken erh lt der Konstruktor der Funktionskomponente nur Seite 54 Dekomposition beim Forward Engineering II 3 Designphase eine auf IManJustageDlg gecastete Referenz von TManJustgeDlg die beim Erzeugen des Fensters Konstruktor von TManJustageDlg bergeben wird TManmJustage le TNManJustageBlea m_InkManJustage new TManJustage IManJustageDlg this Initialisierung der Attribute IManJustageDlg ist hier das Beobachter Interface Es enth lt die abstrakten Methoden die bei Zustands nderungen innerhalb der Funktionskomponente gerufen werden Ereignisse Methode Beschreibung Die Bewegung des als Parameter bergebenen Antriebs OnMotionProgress Der Antrieb bewegt sich OnMot ionStops Der angegebene Antrieb hat gestoppt OntessureStarts Die Halbwertsbreitenmessung hat gestartet OnMeasureProgress Die Halbwertsbreite wird gemessen OnMeasureStops Die Messung wurde gestoppt oder unterbrochen Tab 11 4 Abstrakte Methoden des Beobachters TManJustage TManJustage ruft diese Methoden ber die Referenz m_1nkManJustageDlg die dem Konstruktor bergeben wurde Die Nutzeroberfl che der neuen Manuellen Justage TManJustageDlg ist ein modaler Dialog Sie erbt TModalDlg und das Beobachter Interface IManJustageDlg ein Um eine Instanz von TManJustageDlg erstellen zu k nnen sind alle abstrakten Methoden des eingeer
259. sondern beschr nken sich auf die Auswahl eines bestimmten Messvorganges 9 Erstellung von CanSet und Gewinnung zus tzlicher Bedingungen f r CanDo Methoden optional Werden im Dialog Topographie Einstellungen unzul ssige Werte eingegeben erfolgt weder eine Korrektur dieser noch die bernahme in die Funktionskomponente Laut Verhaltensspezifikation soll nur eine Fehlermeldung ausgegeben werden die den Anwender auffordert den Wert selbst zu korrigieren Weil die bernahme der Eingabe nicht vom aktuellen Systemzustand abh ngt sondern nur vom zu setzenden Wert konnte auf die Erstellung von CanSet M verzichtet werden Die Bedingungen wurden direkt in die Set Methoden implementiert Die Nutzeroberfl che ruft die Set Methode und gibt beim Fehlschlag eine Fehlermeldung aus Dabei zeigte sich dass die Wertebereiche f r de Eingaben zum Teil erheblich von der Spezifikation abwichen weil die Genauigkeit statisch anstatt antr iebsabh ngig war Teilweise fehlte die Grenzwert berpr fung v llig So mussten alle Bedingungen neu bewertet und implementiert werden siehe Abb III 19 Schrittweite zum Anfahren des Arbeitspunktes setzen GetDlgItemText GetHandle id_MoveStep buf 10 valuer atof buf if valueF gt 0 0001 TopographyOld fMoveStep valuer Grenze else return FALSE AUSGANGSZUSTAND Schrittweite zum Anfahren des Arbeitspunktes setzen EE EE pny 22 2 elle ce pen ee pa Minimalwert in Abh ngig
260. st problemlos m glich F r schnellere Rechnersysteme kann dieses Verhalten ber den Eintrag Parallel der Konfigurationsdatei deaktiviert werden Statt eine Windowsbotschaft zu verschicken ruft Notice dazu direkt Dlg_OnEvent Beim Aufruf des Timers zur Bildschirmaktualisierung Methode OnTimer wurde urspr nglich der Zustand aller Antriebe berwacht Durch eine nderung reduzierte sich diese Anzahl auf maximal drei weil nur noch die in den drei Teilbereichen angezeigten Antriebe gepr ft wurden die Hardwarezugriffe wurden deutlich reduziert Deshalb musste nun aber die Antriebsauswahl berwacht werden Am Topographie Arbeitsplatz konnte das Geschwindigkeitsproblem nur beobachtet werden wenn die Antriebe Beugung fein und Beugung grob gleichzeitig angezeigt wurden Dieses Verhalten basierte auf der im Pflichtenheft geforderten Bedingung dass diese Antriebe nicht gleichzeitig bewegt werden d rfen weil sie in dieselbe Bewegungsrichtung wirken Wenn der Bewegungsstatus von einem dieser Antriebe ausgelesen wurde musste daher auch der Zustand des anderen Antriebs aus der Hardware ausgelesen und ausgewertet werden Wurden beide Antriebe angezeigt hatte dies viermal so v ele Hardwarezugriffe zur Folge Beseitigt wurde dieses Problem indem die Nutzeroberfl che nun das zeitgleiche Anzeigen der Antriebe verhindert damit konnte dann die gegenseitige berpr fung der Antriebe in der Funktionskomponente entfernt werden
261. stage entstanden hier keine Methoden doppelt Bei der Analyse der entstandenen Funktionskomponente sind jedoch wiederkehrende Anweisungsfolgen aufgefallen die in zwei private Hilfsmethoden ausgelagert werden konnten Dies sind MeasureStopped zum Testen ob die Halbwertsbreitenmessung beendet ist und Moves um zu ermitteln ob sich der Antrieb bewegt Seite 120 Dekomposition beim Reengineering Ill 2 Restructuring 11 Kennzeichnung nicht zustandsver ndernder Methoden und konstanter Parameter optional Analog zum Forward Engineering wurden nicht zustandsver ndernde Methoden EZ und EZ aus Abb III 11 als const member function gekennzeichnet Bei s mtlichen Methoden konnten bis auf Referenzparameter alle Parameter als const deklariert werden z B double GetAngleWidth const int BOOL amp const 12 Suche und Korrektur von Fehlern optional W hrend dieser Schrittfolge wurde bereits an mehreren Stellen darauf hingewiesen wo Fehler vermutet und offensichtliche Fehler bereits korrigiert wurden Ein Teil der im Fehlerdokument aufgef hrten Fehler wurde so schon w hrend der Schrittfolge behoben Dies betraf auch den schlechten Bedienkomfort bei Zahleneingabefeldern vor der Dekomposition der durch die Verwendung der neuen Fensterbasisklasse automatisch behoben wurde Die unter 4 benannten Fehler wurden im Zuge von 5 behoben indem zwischengespeicherte Werte z B durch die Methode IsMoving ersetzt wurden Drei weitere Fehler wurden
262. standsver ndenden M s nd Get Methode mit einer zugeh rigen Set M so dass ihre berpr fung erst bei 6 erfolgt Die vier Calc Methoden wurden mit Hilfe der Offsetdialoge Offset f r lt Antrieb gt und Offset f r PSD getestet Sie f hren nur Offset Berechnungen durch ohne den Objektzustand zu ndern Sie sind damit nicht zustandsver ndernd Es sind noch 3 Get Methoden brig deren R ckgabewert von Do Methoden abh ngig ist und somit bei 7 getestet wird 6 Test zustandsver ndernder Methoden mit geringer Komplexit t Set M Das Kriterium geringe Komplexit t bezieht sich auf Set Methoden siehe Abb 11 55 CZ Dort werden Attribute der Funktionskomponente geschrieben und oder der Zustand n ederer Subsysteme ge ndert Die Auswahl einer Set Methode erfolgte in der Testoberfl che durch das Kombinationsfeld __ gt woraufhin zuerst die dazugeh rige Get Methode ausgef hrt wird um den aktuellen Zustand des zu ver ndernden Attributes festzuhalten C_D Nach Eingabe des Parameters werden die Ergebnisse der Set Methode R ckgabewert oder Referenzparameter und ein erneuter Aufruf der zugeh rigen Get Methode ausgegeben C_D um die beiden Werte zu vergleichen So wurden nacheinander alle Set Methoden ausgef hrt Dekomposition beim Forward Engineering Il 5 Testphase Seite 89 7 Test zustandsver ndernder Methoden mit hoher Komplexit t Do M Im letzten Testabschnitt wurden die kompl
263. stelle die sich zur Laufzeit durch andere Programmiersprachen mit DLL Schnittstelle einbinden lassen Dort befindet sich dann nur ein Verweis auf die entsprechende Methode einer DLL Heute bieten fast alle Programm ersprachen M glichkeiten DLLs zu im und exportieren In C C sind bspw das Pointerkonstrukt und die schnelle Ausf hrungsgeschwindiskeit f r Port basierten low level Hardwarezugriff in 16Bit Windows Anwendungen nutzbar Eine java bas erte Nutzeroberfl che ist daf r frei portabel Der Umstieg auf ein anderes Betriebssystem w re dann durch Anpassung und Austausch der Funktions DLL problemlos m glich Die Oberfl che bliebe unver ndert ActiveX vor 1996 Object Linking and Embedding OLE ist Teil von Microsofts Component Object Model COM das die DLL Philosophie f r die objektorientierte Programmierung erweitert ActiveX erm glicht die Zusammenarbeit von verschiedenartigen Anwendungen und Komponenten auf Basis einer einheitlichen Schnittstelle ActiveX Steuerelemente und dokumente k nnen umfassende Funktionen anbieten und in die eigene Nutzeroberfl che integriert werden Will man solche Elemente einbinden oder selbst Fenster anbieten muss die Programmiersprache der Nutzeroberfl che den ActiveX Standard unterst tzen ActiveX Code Komponenten erlauben das Starten und die Interprozesskommunikation mit anderen Programmen m ActiveX Standard aus der eigenen Anwendung heraus Wenn die Anwendung durch andere Programme kontrol
264. stellt Im Stichwortverzeichnis befindet sich eine alphabetische Liste der verwendeten Terminologie mit entsprechenden Seitenzahlen wo diese Begriffe eingef hrt definiert oder erl utert werden Seite 4 Einf hrung 1 3 Fallbeispiel das XCtl System LA Fallbeispiel das XCtl System 1 3 1 Allgemeine Beschreibung Die Basis der praktischen Arbeit bildet eine Software mit der Bezeichnung SC die zur Steuerung von Messger ten zur Halbleiter Strukturanalyse benutzt wird Dort werden Halbleiterkristalle mit Licht im R ntgenspektrum bestrahlt Dabei wird ein Teil der Strahlung an der Probe reflektiert und von Detektoren erfasst Die XCt Software bernimmt die Messwerte wertet sie aus und stellt sie grafisch dar So k nnen Aussagen ber Struktur und Qualit t der Probe getroffen werden Das XCtl Programm wird bei den Untersuchungsverfahren R ntgendiffraktometrie Reflektometrie und Topographie siehe M1 eingesetzt um Defekte und Unregelm igkeiten in den Halbleiterkristall Proben zu untersuchen Zum Zeitpunkt der Entstehung dieser Arbeit existierten vier unabh ngige Messpl tze die jeweils ber einen separaten PC gesteuert wurden Auf jedem der Rechner lief eine eigenst ndige Version des XCtl Steuerprogrammes Der folgende Abschnitt beschreibt den Aufbau eines Messplatzes nach Abb I 1 Die von einer R ntgenquelle RQ ausgehende prim re R ntgenstrahlung PS wird durch einen oder mehrere Kollimatorkristall e K
265. szustand zur ckgekehrt wird Bei der neuen Manuellen Justage werden die Antriebsposition und der Status der Bewegung f r jeden Antrieb zwischengespeichert Au erdem sind die BeginUpdate Aufrufe kaskadierbar d h EndUpdate muss so oft gerufen werden wie BeginUpdate zuvor gerufen wurde in der Abbildung generalisiert Durch die Geschwindigkeitsoptimierungen wurden in der Funktionskomponente zus tzliche Methoden und Attribute erforderlich Fast ausschlie lich diese sind f r de Erweiterung des OOD Modells verantwortlich vgl Tab II 7 und Tab II 5 Wie sich dese 19 Elemente verteilen ist in Abb II 46 gekennzeichnet sie befinden sich jeweils am Ende der Klassierung 18 entweder Antrieb bewegt sich oder er befindet sich im Stillstand Seite 74 Dekomposition beim Forward Engineering IA Implementierungsphase 11 4 2 Schwerpunkte bei der Nutzeroberfl che Die Hauptaufgabe des Oberfl chen Programmierers ist die Behandlung der Ereignisse die durch die Nuteroberfl che ausgel st werden Im Kapitel Benutzeroberfl che des dekomponierten Pflichtenheftes s nd dazu die Reaktion bzw Funktion jedes Bedienelementes aufgef hrt F r oberfl chenunabh ngige Elemente sind dort Verkn pfungen f r die zu realisierenden Produktanforderung angegeben die in der OOA in Methoden der Funktionskomponente bersetzt wurden auch der Zugriff auf Attribute wird ber Methoden Accessor und Mutator M realisiert Der Programmierer muss neben d
266. tchendighe EFE EI irah Heu peirer Srtetaeah Sch iete ECHRITT Late Aufheben wW 9 Ieren ng 3 Foi Am In sekunden IF gea ET oa Claes RELATE L Hou totar Schalke ES uthaben nach Benutzerwunsch t 1 Funktionskomponente Lee ggf simuliert LI D i TalndexValid KEN KL San S Leuna eNalide TRUE p no Motockizt sInda e mann 2 Funktionskomponente Destophensure u U partiell simuliert ri Dbatakiter mau starten There Perteno Gert ETATON Zoe L ine I U Ig 5 Aerc LpAlize HMP ene e mte Funktionskomponente n MotocLkizxt i si sn HocoeLias LI GO 3 speine2i Motor ZE Se z SCtGbuN Cen KorseLiaclil OI Horor Id Macie Ids iJ TE Index der ini 3ekeion d die zuletzt vervandeta Betciobznce LHE idx IniPsadLongyi GecHMFilech Hocoeld HJ Hor ionType D Y3 L LU idx 1 j m MotocLizt i m_MotionTypa r ebeivm i Tntaztzr I heres or jae ii batsetsr FopFattirer F Peranto jeas eA ji L e eben elae LI i L dtssz j pn HozoeLias ij Rot LonType s rtepl alza mi Horcocttarttl e Hortontupge r amp Dicact j dafmule vi MoeoeLise i m Anglobozc e IniAosdooublo GerHnupilech Horoctd Ad Angloboze Go Abb 1 10 bergang von der simulierten Funktionskomponente ber die Wartung zum Endprodukt Einf hrung 1 4 Motivation Seite 15 Ein wichtiger Vorteil st auch die unabh ngige Wartbarkeit der Funktio
267. te s e00s0ssss000000ssssssnnunenunnnnnee 49 11 24 UML Klassendiagramm f r die Dialogfensterklassen TMotorOffsetDlg und TPsdOffsetDlg gegliedert nach der Erstellungsreihenfolge ihrer Elemente 50 11 25 UML Klassendiagramm zum allgemeinen Aufbau des Observer Musters DACRIS ee tee ae een essen 52 11 26 UML Klassendiagramm f r Observer Muster in der neuen Manuellen Justage vereinfacht RE 55 11 27 Interaktionsdiagramm f r Observer Muster in der neuen Manuellen Justage w hrend der Antriebsbewegung ssssssssssensssssssanssnnnnnsssnnnsnsennnsssssnnnnnsnnnsssnnnsnssnnssssssennnnsnnnssnes 56 11 25 UML Klassendiagramm f r Polling in der neuen Manuellen Justage vereinfacht WEE 58 11 29 Interaktionsdiagramm f r Polling in der neuen Manuellen Justage wahrend der Antriebsbewegung eu anreisen 59 11 30 Bsp f r hohe Komplexit t des Observer Musters bei 1 3 00000000000000000000000000000000 60 11 31 Bsp f r das einfache Design von Polling bei 1 3 222 0cecc000000ss00000sssssssnnnnnunnnssssssssssnsee 60 IT 52 Bsp f r Obseryer Muster bei 3 unse are ann 61 II 33 Bsp f r Obseryer Muster bei 2 2 ns ann 62 11 34 Verallgemeinerte Eintr ge f r Typen Attribute Methoden und Variablen vgl oben nach Ausz gen aus M20 000000ss00000000000000000000000000000nnnnununnnnsnsssssssssssssssssssee 63 11 35 Auszug f r einen Methoden Eintrag aus M20
268. te beschr nkte sich das Angebot auf 16 Bit hlp Dateien Somit wurde HelpScribble als beste und komfortabelste L sung weiter genutzt Problematisch blieben jedoch die Dateigr en der bebilderten Versionen Durch eine ausgiebige Recherche der Autoren zum Microsoft Hilfe Compiler bez glich unterst tzter Bildformate und Kompressionsm glichkeiten Konnte die Gesamtgr e in mehreren Build Test Zyklen auf etwa 400 kB reduziert werden Bei der h chsten Kompression f r Microsoft Windows 3 1x reduzierte sich die Gr e der bebilderten Hilfedateien auf etwa 1 2 Zudem erm glichte der neueste Hilfe Compiler die Verringerung der Farbtiefe von 24 auf 8 Bit f r die Bilddateien und eine Dateigr e von 4A ausgehend von der urspr nglichen Hilfeversion Durch diesen Erfolg konnten die einzelnen Dateien in einem Hilfeprojekt d h einer hlp Datei zusammengefasst werden Nur so waren ein universelles Inhaltsverzeichnis und die Verlinkung der einzelnen Hilfe Themen untereinander m glich Das Resultat dieser Arbeit zeigt Abb I 11 Mitte F r die neue Manuelle Justage wurde nun ein wartungsfreundliches Konzept gesucht das sowohl der Komplexit t des Hauptdialogfensterss als auch dem geringen Festplattenspeicherplatz auf den Arbeitspl tzen der Physik gerecht wird Im Stil der vorhandenen Hilfe Ihemen wurden pro Dialogfenster separate Seiten erstellt die eine allgemeine Funktionsbeschreibung eine Abbildung und die Tastenkombinationen enth lt Di
269. te umgesetzt k nnte der Softwareentwicklungsprozess teilautomatisiert werden Als m gliches Ziel steht dann die automatische Gewinnung von Programmcode aus den Entwicklerdokumenten und umgekehrt Anhang A Literaturvezechnis 5 Seiteldi Anhang A LITERATURVERZEICHNIS 1 P S C Alencar D D Cowan C J P Lucena A Logic Theory of Interfaces and Objects IEEE Transactions on Software Engineering Vol 28 No 6 Juni 2002 2 H Balzert Lehrbuch der Software Technik Software Entwicklung 2000 Spektrum Heidelberg Berlin Spektrum Akad Verl 3 H Balzert Lehrbuch der Software Technik Software Managment Software Qualit tssicherung Unternehmensmodellierung 1998 Spektrum Heidelberg Berlin Spektrum Akad Verl 4 K Bothe Praxisn he durch Reverse Engineering Projekte Erfahrungen und Verallgemeinerungen Februar 2001 7 Workshop SEUH Z rich 5 M El Ramly P Iglinski E Stroulia P Sorenson B Matichuk Modeling the System User Dialog Using Interaction Traces 8 Working Conference on Reverse Engineering 2 5 Oktober 2001 Stuttgart 6 G Fischer A Lemke T Schwab Knowledge based Help Systems CHI 85 Proceedings April 1985 7 K Fuchs Kittowski H Parthey W Umst tter R Wagner D bler Hrsg Wissenschaftstheoretische Positionen in Bezug auf die Gestaltung von Software Organisationsinformatik und Digitale Bibliothek in der Wissenschaft Wissenschaftsforschung Jahrbuch 2000 Berlin
270. tellt werden Diese kennzeichnet ob die Funktion durchgef hrt werden 13 Eigentlich ist die Angabe der Methodensignatur in der OOA nicht blich Ein Teil ist hier jedoch bereits kanonisch im Pflichtheft ablesbar Seite 40 Dekomposition beim Forward Engineering Il 2 Definitionsphase darf Der R ckgabewert der Do Methode sollte dann das Ergebnis des Can Methodenaufrufs sein Die in Abb II 18 beschriebenen Funktionen weisen z B eine verwandte Funktionalit t auf so dass sie zu der Methode DoDrive EDirection zusammengefasst wurden Dieser intuitiv notwendige Parameter zur Regelung der Bewegungsrichtung sollte daher schon hier ber cksichtigt werden Grundlagen Im Fahrbetrieb kann der Antrieb kontinuierlich mit einer vorgegebenen Bewegungsgeschwindigkeift entweder vorw rts oder r ckw rts bewegt werden F 90 Vorw rtsbewegung im Fahrbetrieb Nach der Beschleunigungsphase bewegt sich der Antrieb solange der Reiz der zum Starten der Bewegung gef hrt hat anliegt kontinuierlich mit der angegebenen Geschwindigkeit vorw rts Wenn die maximale Istposition erreicht wird stoppt der Antrieb automatisch Bedingung Der Antrieb darf sich nicht bewegen und die aktuelle stposition muss kleiner der maximalen Istposition sein damit die Bewegung startet F 100 R ckw rtsbewegung im Fahrbetrieb Die Steuerung des Antriebs ist quivalent zu F 90 die Bewegung erfolgt jedoch in entgegengesetzter Richtung
271. tems s muliert Seite 84 Dekomposition beim Forward Engineering Il 5 Testphase 1 Gewinnung von Testdaten Die Testdaten wurden aus dem Datenteil des Pflichtenheftes abgeleitet Dies soll hier exemplarisch f r das Datenelement Sollposition nachvollzogen werden Der Datenteil Eintrag D 110 siehe Abb 11 53 Tabelle 13 zeigt dass es eine untere und eine obere Grenze f r die Sollposition gibt Dort ist erkennbar dass die minimalen und maximalen Grenzen antriebsspezifisch d h hardwareabh ngig sind siehe Abb IL 53 Tabelle 8 und 9 Die Testdaten sind den Eintr gen Speichertyp und Speicherort nach aus der Konfigurationsdatei f r den betrachteten Antrieb zu entnehmen Zus tzlich ist die antriebsspezifische Nachkommastellen Genauigkeit zu ber cksichtigen siehe Abb 11 53 Tabelle 10 die auch einer Konfigurationsdatei entnommen wird D 110 eingegebene Sollposition Die Sollposition ist wie die Istposition abh ngig vom aktuellen Offset des Antriebs Die Minimal und Maximalwerte k nnen dem Datenteil entnommen werden ebenso die Nachkommastellengenauigkeit Die Sollposition ist bei jeder Anderung zu speichern Bezeichnung eingegebene Sollposition Typ Zugriff Eintrag T lesen und schreiben Speicherort HARDWARE INI gt MOTOR lt M gt gt MJ_AnigeDest Tabelle 13 Eigenschaften der Sollposition D 60 minimale Istposition Bezeichnung minimale Istposition
272. teraktiven Softwaresystemen benutzt Die Bas selemente dieses Modells sind Programm und Schnittstellenkomponenten Die Programmkomponenten werden im ADV Modell als Abstract Design Objects kurz ADOs bezeichnet Sie sind die Tr ger der grundlegenden Funktionalit t eines Programmes Sie besitzen einen inneren Zustand und bieten eine ffentliche Schnittstelle zur Zustands nderung Eine Schnittstellenkomponente im Modell als Abstract Design Viewer ADV bezeichnet ist eine Programmkomponente mit Sonderfunktionalit t Dies kann sein Timing Funktionalit t Netzwerkkommunikation Druckvorg nge oder Kommunikation mit dem Anwender also die Nutzeroberfl che Jedes ADV ist im Kern ein ADO und besitzt damit ebenso einen inneren Zustand und eine ffentliche Schnittstelle Die Beziehung zwischen einem ADO und einem ADV wird als views a Relation bezeichnet Es bedeutet dass ein ADV ein ADO beobachtet Besteht eine solche Beziehung kennt ein ADV den Zustand des beobachteten ADOs Wird ein ADV als Nutzeroberfl che eingesetzt dann beobachtet diese ein ADO und zeigt dem Anwender dessen aktuellen Zustand Zur Realisierung der views a Beziehung soll ein ADO durch eine formale Assoziation an ein ADV gebunden werden Diese ist durch eine gemeinsame Namensgebung von ADO und ADV der Konsistenz der Zust nde im Modell die vertikale Konsistenz und der M glichkeit zur Zustands nderung des ADO durch das ADV gekennzeichnet Ein ADV kann mit mehreren
273. tierungssprache f r das Projekt ist C die Entwicklungsumgebung war Borland Version 4 5 Die Ausgangsversion des XCtl Programmes wurde 1998 durch den Physiker Heiko Damerow einem damaligen Mitarbeiter im Fachbereich Einf hrung 1 3 Fallbeispiel das XCtl System Seite 5 R ntgenbeugung an d nnen Schichten erstellt und bestand aus vier Subsystemen mit 27 000 LOC Da diese Version M ngel und Fehler in Design und Implementierung aufwies der Quellcode kaum kommentiert war und wenige System und Benutzerdokumentationen existierten wandte sich der Physikalische Fachbereich an Prof Dr Klaus Bothe mit der Bitte das Programm zu warten und zu erweitern D I gtt rem sep 2 Dale Bassbeiten Himen Guihen Ereiebroasn Fenger Hii 1 Z hler Coantes F ls E Zshler Konligueatior 584 00 Grpascop CAM ID Omega LI UI GES 121 463 Theta Abb I 2 XCtl Programm mit Z hler und AreaScan Fenster und Dialog zur Konfiguration der Detektoren Quelle XCtl Programm Seitdem besch ftigt sich das Projektseminar Software Sanierung mit der Analyse der kontinuierlichen Umstrukturierung und Erweiterung des XCtl Programmes Dazu werden die existierenden Dokumente der fr hen Phasen der Software Entwicklung im Reverse Engineering analysiert und erg nzt bzw angepasst Fehlende Dokumente werden neu erstellt Darauf aufbauend wird das Projekt in Zusammenarbeit mit den Mitarbeitern
274. tposition anfahren und CtrlSetEnabled cm_GotoWorkPoint FALSE Regelung starten ausgrauen E Anfahren des um dStartAngle vom aktuellen Stand entfernten Punktes Steering Reset weitere funktionsspezifische Anweisungsfolgen AUSGANGSZUSTAND void TIopeoor aphyBx2 eBlg Pre OnNGotoWorkPoine void J Or CtrlSetEnabled cm_SwitchControl FALSE Startposition anfahren und CtrlSetEnabled cm_GotoWorkPoint FALSE Regelung starten ausgrauen Cerlsecenexze id Text Colostarcepeine Beschriftung ndern Ei SetAngleWidth GetMoveStep Motorschrittweite setzen Anfahren des um dStart Angle vom aktuellen Stand entfernten Punktes Steering Reset weitere funktionsspezifischen Anweisungsfolge JI ERGEBNIS Abb 111 17 Zusammenfassen einer Set Methode mit einem gro en F Block 7 Erzeugen von Do Methoden F r die Klasse TTopography entstanden 19 Do Methoden Die identifizierten F Bl cke waren soweit zusammengefasst dass innerhalb einer Methode der Oberfl chenklasse h chstens eine Do Methode gerufen werden muss Die dabei entstandenen Methoden haben meistens sehr viele Parameter weil die aus den benutzten Subsystemen gerufenen Methoden meist selbst viele Parameter erfordern Die neu entstandene Methode DoStartMeasure ruft bspw StartCmdExecution Subsystem Ablaufsteuerung mit f nf Parametern Durch die Dekomposition muss die Funktionskomponente diesen Methodenaufruf in einer Do M kapsel
275. trennten Manuellen Justage ist erkennbar dass die Anzahl der On Methoden direkt proportional zur Anzahl der Steuerelemente ist Durch die Auslagerung von Programmcode aus Dlg_OnCommand konnte diese Methode von LOC 314 auf 61 reduziert werden Jede neue Methode ben tigt jedoch zus tzliche 6 LOC Trotzdem konnte der Umfang der Nutzeroberfl che von LOCo 655 auf 593 reduziert werden bei deutlich gesteigerter bersichtlichkeit Die Funktionskomponente ist von NOOr 1 auf 93 angewachsen Das liegt zum gro en Teil am neu hinzugef gten Zugriffsschutz der sich in fast 60 Accessor und Mutator Methoden ausdr ckt Einen erheblichen Anteil an LOC ben tigen diese f r die berpr fung der G ltigkeitsbereiche die oftmals durch die dynamischen Grenzen sehr komplex sind Die ausgelagerte Funktionalit t beansprucht den restlichen Teil NOO Nachteilig ist dort die Entstehung langer Parameterlisten was aber stark vom Design der benutzten Subsysteme Schritt 7 abh ngig ist MNOP von 0 auf 5 Die LOCYr ist zwar von 83 auf 472 gestiegen daf r sind fast alle Fehler korrigiert und die Robustheit verbessert worden die Aufforderung an den Anwender seine Eingabe selbst zu korrigieren ohne einen Hinweis auf den G ltigkeitsbereich Dekomposition beim Reengineering Ill 3 Fazit und Ausblick Seite 137 111 3 Fazit und Ausblick Im Gegensatz zum Forward Engineering ist eine deutliche phasenorientierte Dekomposition beim Reengineering nicht m glic
276. tskript w ren nach der Anzahl an Testf llen und Testdaten erforderlich Aus Komplexit tsgr nden ist die berpr fung des Inhaltes der Steuerelemente dabei in der Hand des Testers Pro dynamisch beschriftetem Steuerelement m sste also ein weiteres Testdatum integriert werden Zudem besteht ein Testfall aus mindestens einer Handlungsanweisung de in etwa mit LOC gleichgesetzt werden k nnte Die Wartung dieser Testskripte w re damit nahezu unm glich weil auch die Wartezeiten ermittelt und aufgenommen werden m ssten Der Regressionstest musste sich daher auf eine repr sentative Auswahl an Testf llen beschr nken Trotz des relativ geringen Umfangs von 931 LOC ATOS Testskript konnte die Stabilit t und Fehlerresistenz der sehr komplexen Nutzeroberfl che dennoch sichergestellt werden Dekomposition beim Forward Engineering 11 6 Fazit und Ausblick Seite 95 II 6 Fazit und Ausblick In der Analysephase werden nur grundlegende Bas sanforderungen an das zuk nftige Produkt festgehalten Damit ist diese Phase unabh ngig von der Nutzeroberfl che Die Dekomposition beginnt erst in der Definitionsphase Nach der Sammlung der Produktanforderungen kann die durch die Dekomposition erm glichte Arbeitsteilung beginnen W hrend die Entwicklung der Oberfl chen Prototypen stattfindet k nnte sich der Anwendungsspezialist bereits mit den oberfl chenunabh ngigen Teilen des Produkt Modells besch ftigen im Wesentlichen die Erstellung des OOA Modells E
277. tstehen in enger Zusammenarbeit mit den Mitarbeitern des Physikalischen Institutes die als Fachwissenschaftler bei physikalischen und technischen Problemen zu Rate gezogen werden k nnen Neben dieser Anwenderklientel arbeiten auch Studenten im Rahmen eines Praktikums an den Messpl tzen mit dem Programm und bilden so eine zweite Nutzergruppe Die Wartung des XCtl Projektes bildet die Grundlage f r Studien oder Diplomarbeiten Seite 2 Einf hrung I 1 Zusammenfassung Thema dieser Diplomarbeit ist die Trennung Dekomposition der Nutzeroberfl che von der dazugeh rigen Funktionskomponente d h Programmfunktionalit t Dazu z hlen der Zugriff auf andere Subsysteme Hardware jede von der Oberfl che unabh ngige Datenhaltung verwaltung sowie das Festhalten des Systemzustands Berechnungen und Simulationen Dieses Vorgehen wird sowohl im Forward als auch im Reengineering untersucht Dazu wurde ein im XCtl Steuerprogramm vorhandenes Subsystem Manuelle Justage grundlegend neu analysiert entworfen implementiert und getestet Die theoretischen Ans tze zur Formalisierung des gesamten Softwareentwicklungsprozesses sind daraus abgeleitet Die gewonnenen Erkenntnisse und zusammengetragenen Fakten werden am klassischen Wasserfall Modell d h von Analyse und Definition ber Design Implementierung bis hin zum Test phasenspezifisch angewendet und am Anwendungsfall erl utert Im Reengineering wurden die beiden Anwendungsf lle
278. uch hier wieder die Benennung mit dem Pr fix On was bspw konform zu Microsoft Visual C MVC ist F r alle Methoden und Attribute kann ein strenger Zugriffsschutz gew hlt werden da ein Zugriff von au en nicht erforderlich ist Nur das Anzeigen und Verstecken anderer Fenster ist erlaubt um die horizontale Konsistenz zwischen den Nutzeroberfl chen zu wahren Ein Informationsaustausch darf nur ber eine gemeinsame Funktionskomponente erfolgen Anwendungsfall Manuelle Justage Im XCtl Projekt waren die Fensterbasisklassen nicht von Borland C bernommen sondern mit Hilfe von API Funktionen realisiert und im Subsystem Benutzeroberfl che zusammengefasst Da eine entsprechende Dokumentation im Web Repository fehlte erfolgte ein Reverse Engineering des Programmcodes durch die Autoren Dabei wurden so viele Design und schwerwiegende Laufzeitfehler identifiziert dass eine komplette Umstrukturierung als beste L sung erachtet wurde Der urspr ngliche Zustand wurde in M7 festgehalten Im Verlauf des Reengineering wurde eine v llig neue Vererbungshierarchie entwickelt welche die sp tere Win32 Portierung in ein MVC Projekt ber cksichtigt Dazu wurden die GUI Basisklassen des XCTL Projektes soweit separiert dass dieses Subsystem in einem solchen Projekt getestet werden konnte Zudem soll die neue Manuelle Justage auch ber Tastenkombinationen steuerbar sein Weil es in Winl6 Anwendungen daf r keine praktika
279. uf g nzlich unerfahrene Anwender wurden die zu bedienenden Steuerelemente bei jedem Arbeitsschritt abgebildet Besonders zu beachtende Beschriftungen werden zudem durch ein dickes rotes Oval umrahmt 1 bei der Eingabe eines unzul ssigen Wertes wird dieser automatisch in den Wertebereich eingepasst siehe Kapitel Fehlertoleranz der Benutzeroberfl che Dekomposition beim Forward Engineering Il 2 Definitionsphase Seite 37 EE Falls sich TI bewegt warten Sie bis Stillstand J siefe Bewegen von TI nach 0 34 Minuten im Direktbetrieb u Bet tigen Sie die Schaltfl che aufheben Cl KEINER weist auf absolute Positionierungen hin D Be Be aufheben Istposition zeigt automatisch die Absolutposition aufheben unm glich KEINER weist auf absolute Positionierungen hin f j an ISTPOSITION 0 3 H inuten _Offser KEMER Abb 11 15 Auszug aus dem Trainingsteil des Benutzer Leitfadens M17 zur Schrittfolge f r Relative Null von Tt aufheben Im Anhang werden die benutzten Eintr ge aus den Konfigurationsdateien gesammelt erl utert Dazu z hlen auch die Nennung des Datentyps logisch aufgez hlt ganzzahlig reellwertig oder Zeichenkette und die Angabe g ltiger Werte z B Wertebereich und Nachkommastellengenauigkeit bei reellwertigen Eintr gen Das XCtl Programm ist auch als englischsprachige Version auf den Rechnern des Physikalischen Institutes verf gbar Im
280. und die Komplexit t besser bew ltigen zu k nnen Hier lag der Schwerpunkt auf der Erstellung neuer und dem Studium der vorhandenen Artefakte der benutzten Subsysteme weil die Interaktion mit diesen Schnittstellen und Funktionsweise m Mittelpunkt stand Am wichtigsten bei der Ist Analyse im Reengineering ist das Verst ndnis des Programmcodes des zu dekomponierenden Subsystems selbst Die Implementierung beschr nkt sich auf das Dialogfenster Manuelle Justage siehe Abb II 1 TAngleControlDlg besteht aus 457 LOC siehe Tab II 2 mit sechs Nachrichtenbehandlungsroutinen die aus der Basisklasse f r Dialogfenster stammen und berschrieben wurden NOOM 6 Die brigen beiden Methoden NOO 8 sind intern benutzte Methoden f r Berechnung der Bildlaufleiste Der Programmcode ist mit einer durchschnittlichen Methodengr e von 57 LOC entsprechend un bersichtlich zumal die Steuerelement basierten Nachrichten in der Methode Dlg_OnCommand auf 330 LOC behandelt werden Das Subsystem urspr ngliche Manuelle Justage st abgeschlossen weil kein anderes System auf ihren Programmcode zugreift Damit ist die ffentliche Kennzeichnung aller Methoden mit public PPubM 45 weder notwendig noch sinnvoll Die elf Attribute NOA 11 sind jedoch vollst ndig gesch tzt PPrivM 55 Zur Ansteuerung der Antriebe und Detektoren und zur Messung der Halbwertsbreite werden andere Subsysteme verwendet Die dazu benutzten Methodenaufrufe dienen der Realis
281. ung der Funktionskomponente sssssssssssssooeeeeeesssssssssssssssetreressssssssssssee 44 Anwendungsfall Manvelle Justase rare ae E 44 11 3 2 Ableitung der Oberfl chenfenster aus dem Pifchtenbheft 48 Anwendunestall Manuelle J sta g ni a a de a a 48 11 3 3 Anbindung der Nutzeroberfl che an die Funktonskomponente seeseeeeseeeseeeeeee 50 11 3 3 1 Ausgangspunkt ADV Modell nnnennneenneesssssssssseeerrsssssssssssssseeeerrressssssss 50 11 3 3 2 Anwendung bei der Dekompospon 51 Hoo Dar Observer Mister ae eine Sl Anwendungsfall Manuelle Justage AN 53 Eege De Rolln 5 Yarante es ee 56 Anwendungsfall Manuelle Justage sssssssssssssseseeeeeeeennnnnnnnnnnnnnnnnnnenenenennn 57 11 3 3 5 Kardialit ten von Nutzeroberfl chen und Funktionskomponenten 59 11 3 4 Aufbau von Desgsndokumenten nennen 62 Anwendungsfall Manuelle Justage ssonnonnnneesssessssssssseeeeeeresssssssssssssseeereressssssss 62 13 9 HEIEREN 64 11 3 5 1 Bewertung von Observer Muster und Polling im Anwendungsfall 65 Dekomposition von Software Systemen Tabellenverzeichnis RE DE Implementierungsphase II 4 1 Schwerpunkte bei der Funktionskomponente ssensoeeeneesssssssssssssssetreressssssssssssse 68 Anwendungsfall Manuelle Justage ssnnnnoneeeessessssssssseeeeeressssssssssssseeeereeesessssss 68 11 4 2 Schwerpunkte bei der Nutzeroberfl che nn00ooosseooooe
282. ung von Steuerelementen wird zudem die Benennung aus dem Kapitel Benutzeroberfl che des Pflichtenheftes verwendet Wenn das Element unbeschriftet ist wird eine abstrakte Aufgabenbeschreibung verwendet die mit einer kursiven Schriftart hervorgehoben wird siehe Beschreibung von Abb II 8 Die eigentliche Funktionsbeschreibung konnte leicht modifiziert aus dem gleichen Kapitel des Pflichtenheftes bernommen werden Abstrakte Begriffe werden dabei n gr ner Schrift und unterstrichen hervorgehoben siehe Abb II 12 __ gt und sind zudem als Querverweis auf eine weiterf hrende Hilfe Seite realisiert Insgesamt entstanden so 38 Hilfe Seiten die sich mit dem Hauptdialog und den beiden Offset Dialogen besch ftigen Die Beschreibung ist insgesamt nicht so ausf hrlich wie im Referenzteil des Benutzerleitfadens siehe II 2 4 Die Onlinehilfe verzichtet hier z B auf die Angabe von Wertebereichen Es wird stichpunktartig erl utert wann das Steuerelement bedienbar bzw die Produktfunktion ausf hrbar ist siehe Abb IL 12 21 Dies entspricht genau den Bedingungen f r die Produktfunktionen aus dem Funktionsteil des Pflichtenheftes Abschlie end wird unter Hinweise ggf erl utert welche Auswirkung die Produktfunktion auf die Nutzeroberfl che hat Die Integration der Benutzeroberfl che in das Pflichtenheft bei gleichzeitiger klarer Abgren zung von Funktionen und Daten haben die Erstellung des Hilfe Systems wesentlich erleichtert 11
283. unterschiedlich sein Dementsprechend gibt es zahlreiche Klassifizierungen Im Gegensatz zu Hilfsmitteln die dem Anwender in gedruckter Form vorliegen z B Benutzerhandbuch erlaubt ein elektronisches Hilfe System eine gewisse Anpassung an die aktuellen Bed rfnisse des Anwenders So wird bei dynamischen Hilfe Systemen bspw der aktuelle Programmkontext verwendet um ein entsprechendes Hilfe Thema vorzuschlagen Statische Hilfe Systeme hingegen liefern unabh ngig vom aktuellen Programmzustand immer denselben Hilfe Text Zudem variieren die Anforderungen an ein Hilfe System auch stark durch die unterschiedlichen F higkeiten der jeweiligen Anwender Beim Suchen Vorschlagen eines Hilfe Themas ber cksichtigt ein individuelles Hilfe System daher das bisherige Nutzungs verhalten des Anwenders Dies erfordert jedoch die Erstellung eines umfangreichen Benutzer modells siehe 2 S 670ff f r das Informationen gesammelt und aufbereitet werden m ssen Dazu z hlt n erster Linie wann wie und wie oft eine Produktfunktion benutzt wird Weil die Erstellung einer solchen Hilfe und die Integration ins Softwaresystem extrem zeitaufwendig sind bilden heute noch uniforme Hilfe Systeme den Gro teil der Hilfe Systeme Sie liefern unabh ngig vom aktuellen Anwender immer dieselben Informationen In Zukunft werden aktive Hilfe Systeme das Benutzungsverhalten der Anwender beobachten und bei der Verwendung von ausgew hlten Funktionen selbst ndig Hilfe a
284. w Entwicklungsprozess konomischer und fehlerresistenter Hier m ssen nur die Klassen der Nutzeroberfl che ersetzt werden welche die bereits vorhandenen Schnittstellen der Funktionskomponenten neu einbinden Daher ist die Dekomposition auch beim Oberfl chen Prototyping sehr empfehlenswert weil die Funktionskomponente dort lange Zeit unver ndert bleibt und nur verschiedene provisorische Nutzeroberfl chen ohne die echte Funktionalit t erstellt und diskutiert werden Die Programmfunktionen Funktionskomponente m ssen nur selten angepasst werden z B bei einem Plattformwechsel von 16 nach 32 Bit Hazucli Ssabage Sr EX E Oberfl chenprototyp 1 1 ia A SESCH ETR Ma up br Zenlasr P Weg L oset nigen H BI Bell i O O u dema Ar kb 3 mE Oberti chenprototyp2 2 mm a Huazucli d RS j um Trsta n ter Oberfl chenprototyp IS Schaltoetich Schiene OORT Zutaten Iess i bskteiieh C Fett 1Verkippung IL Bi E Br ninin RELATE HLLL z Ges ae un al RELATIVE HILL OFFSET r POSITE zj ERSTEN HI CA re 07E narad IIO gea ET It Ep Ziteben Die 1 1 Wel Ce Sie eu nad RELATIVE PULL BETFIERSARTEN FPAREMI Fahrberiet f Se ER Inte Heu HET e Dreh E Salgo Setetaeah Scl tasie ECHRITT Iapsed Ziieten p kerk Bes TS IE WET J RNA W z gew reen Cutter Echte may D gen JDL 78 niin 10 a lIBI O D sst bagie m
285. weiter verbessert werden Dazu z hlt auch die Verwendung von uerverweisen innerhalb eines Dokumentes oder Verkn pfungen zu anderen Dateien bzw Literatur Um Auftraggeber und Anwender die Arbeit mit dem Pflichtenheft zu erleichtern sollte stets ihre Fachterminologie angewendet werden Um das Verst ndnis des Entwicklerteams f r diese Begriffe zu sichern sollten sie entweder in einem Glossar gesammelt erl utert oder an den entsprechenden Stellen im Flie text erkl rt hervorgehoben und in einem Stichwortverzeichnis zusammengefasst werden Die verbale Beschreibung der Produktanforderungen sollte stets kurz knapp und so eindeutig w e m glich erfolgen Um Beginn und Ende von umfangreichen Erl uterungen deutlich zu kennzeichnen haben die Autoren dem Text eine vertikale Linie siehe Abb II 4 vorangestellt Bedingungen Hinweise und Warnungen werden zudem besonders gekennzeichnet Datenelemente lassen sich gut in einer Tabelle formalisieren Dabei sind die folgenden grundlegenden Informationen zu integrieren siehe z B Abb II 5 e Datentyp logisch aufgez hlt ganzzahlig reellwertig oder Zeichenkette e Zusgriffsart nur lesen nur schreiben oder lesen und schreiben e Speichertyp Arbeitsspeicher Textdatei mit zu nennender Zeichenkodierung sequentielle Dateistruktur Datenbank und typ e Speicherort Position n einem Feld bzw Dateiname und Hierarchie innerhalb einer Datei e Minimal Maximalwert und Nachk
286. werden soll Der Weg Antriebe zu adressieren konnte erst im Programmcode Review ermittelt werden Der zweite Parameter zeigt die G ltigkeit des R ckgabewertes die z B vom bergebenen Index abh ngt Da die Methode CanSetAngleDest zur ckgeben soll ob SetAngleDest durchf hrbar ist ergab sich BOOL CanSetAngleDest int Weil diese Can Methode existiert ist der R ckgabewert f r SetAngleDest nicht void sondern von der CanSet Methode bernommen BOOL SetAngleDest int TAngle amp Der erste Parameter ist w eder der Index des Antriebs und der zweite gibt die zu setzende Sollposition an Er wurde als Referenz deklariert um stets den wirklich m der Funktionskomponente gespeicherten Wert zur ckzugeben Ein vom Anwender eingegebenen Wert wird in der Set Methode auf Seite 46 Dekomposition beim Forward Engineering Il 3 Designphase Wertebereich und Nachkommastellengenauigkeit berpr ft ggf korrigiert und an die aufrufende Nutzeroberfl che per Referenz zur ckgegeben Diese kann so jederzeit den aktuellen Systemzustand anzeigen Die G ltigkeit der gesetzten Attribute muss damit nur einmal zentral in der Funktionskomponente verwaltet werden BOOL SetValue Type s amp aValue if CanSetValue aValue FALSE aValue GetValue vorher gesetzten Wert zur ckgeben return FALSE aValue m_Value Manipulierel aValue return TRUE Abb 11 21 Allgemeines Implementierungsschema f r eine Set Methode mit CanSet c Si
287. ystem gew hlt werden um das jeweilige Fenster berhaupt adressieren zu k nnen Weil damit jedoch nicht jeder Parameter der Nachrichten bertragung von au en manipulierbar st Kann nicht jeder m gliche Programmzustand durch Bedienung der Nutzeroberfl che erreicht werden Es kann kein vollst ndig kontrollflussorientierter Test durchgef hrt werden Da zudem alle vom Anwender sichtbaren und durchf hrbaren Aktionen der Nutzeroberfl che in der Programmspezifikation aufgef hrt sind sollte ein funktionaler Test Black Box Testverfahren angewandt werden Alle Testf lle und daten sind aus der Spezifikation ableitbar Die Anwendung wird dabei manuell bedient und das Verhalten vom Tester kontrolliert oder es wird ein autarker Testtreiber siehe 9 S 19ff verwendet Dieser simuliert die Eingaben steuert das Programm fern und berpr ft die ihm zugewiesenen Steuerelemente auf Inhalt und Zustand F r einen groben Vorabtest der Nutzeroberfl che muss die Funktionskomponente noch nicht vollst ndig getestet implementiert zur Verf gung stehen In diesen F llen kann eine simulierte Funktionskomponente siehe 3 S 506 Platzhalter bzw stubs benutzt werden bei der die einzelnen Methoden nur Standardwerte zur ckgeben Unumg nglich bleibt der abschlie ende Feintest mit der wirklichen Funktionskomponente Anwendungsfall Manuelle Justage Zum Oberfl chentest der neuen Manuellen Justage stand die Funktionskomponent
288. zpunktlauf o Betriebsarten IV 3 Dialogfenster Offset f r lt PSD gt e Direktbetrieb o Ausgangsdaten e Fahrbetrieb e Istposition von Theta e Schrittbetrieb e Winkelwert pro Kanal Se PSD Kanaloffset definieren o Dialogfenster verlassen e neu zugeordneter Kanal Beenden Ausgabedaten e PSD Kanaloffset IV 2 Dialogfenster Offset f r lt Antrieb gt e entspricht Winkel Kanal 0 o Ausgangsdaten Dialogfenster verlassen e aktuelle Istposition e OK e aktueller Offset e Abbruch Abb 11 13 gek rzter Auszug aus dem Benutzer Leitfaden M17 Kapitel Referenzteil Die produktorientierte Gliederung erkennt man z B an den Unterpunkten von IV 3 Abb II 13 wo zuerst die gegebenen Ausgangsdaten dann die m glichen Anwendereingaben und abschlie end die daraus resultierenden Ausgabedaten dargestellt werden Vor der eigentlichen Funktionsbeschreibung ist das jeweilige Steuerelement siehe Abb 1 14 _ abgebildet So sind auch Steuerelemente nachzuschlagen die im Dialogfenster nicht benannt sind abstrakte Aufgabenbeschreibung Nach der ausf hrlichen Beschreibung der Produktfunktion folgen drei Abschnitte mit Informationen aus dem Pflichtenheft Kapitel Daten Seite 36 Dekomposition beim Forward Engineering Il 2 Definitionsphase e Im Absatz amp siehe Abb II 14 werden kurz die ben tigten Eintr ge aus den Konfigura tionsdateien
289. zugeh rige CanDo Methode geplant worden die nun als CanDoDirect implementiert wurde siehe Abb II 40 Durch die Eindeutigkeit und Einfachheit der Bedingung konnte im Falle der neuen Manuellen Justage auf Entscheidungstabellen verzichtet werden Bei komplexeren Bedingungen sollte dieses Bas skonzept jedoch als Implementierungshilfe genutzt werden Es muss dann auch als Teil des OOA Modells n die Vertragsverhandlungen aufgenommen werden Nachdem die Ausf hrung der Do Methode gesichert war CanDo M mussten die Methoden zur Realisierung der eigentlichen Funktionalit t in den brigen Subsystemen gesucht werden In den Designdokumenten der Subsysteme Motorsteuerung Ablaufsteuerung und Detektornutzung konnten die ben tigten Methoden einfach identifiziert werden Im Falle von F 70 DoDirect waren dies nur Methoden der Motorsteuerung im Wesentlichen zur Bewegung eines Antriebs zu einer neuen Antriebsposition siehe Abb II 41 Es erfolgt nun die Implementierung der eigentlichen Do und Set Methode Dazu wird anfangs die dazugeh rige Can Methode aufgerufen die bei Nichterf llung zur vorzeitigen Beendigung der Do bzw Set Methode f hrt Danach werden die identifizierten Methoden aus den Subsystemen aufgerufen die u U auch zu einer vorzeitigen Beendigung der Methode f hren k nnen Nur bei vollst ndiger und erfolgreicher Abarbeitung ist der R ckgabewert am Ende TRUE sonst immer FALSE siehe Abb II 42
Download Pdf Manuals
Related Search
Related Contents
Guide d`utilisation SQ617 - セイコークロック the user manual for bulk sms reseller platform Gemini GPS 148 ANNTS USER`S MANUAL Chariot Carriers Chariot 2008 User's Manual Unison File Synchronizer - the Department of Computer and MSI H61M-P20/W8 motherboard Copyright © All rights reserved.
Failed to retrieve file