Home

DIPLOMARBEIT - Institut für Informatik - Support Server - Hu

1. Anhang C Wichtige Datentypen im Vergleich Seite 194 Anhang C Wichtige Datentypen im Vergleich Datentyp Win16 Win32 Bemerkung int int 2 int INT 4 uj char char 1 char CHAR 1 short short 2 short SHORT 2 BOOL int 2 int 4 0 BYTE unsigned char 1 unsigned char 1 WORD unsigned short 2 unsigned short 2 DWORD unsigned long 4 unsigned long 4 UINT unsiged int 2 unsiged int 4 1 LONG signed long 4 signed long 4 WPARAM UINT 2 UINT 4 1 LPARAM LONG 4 LONG 4 LRESULT LONG 4 LONG 4 PSTR char NEAR 2 char 4 1 NPSTR char NEAR 2 char 4 1 LPSTR char FAR 4 char 4 2 LPCSTR const char FAR 4 const char 4 2 PBYTE BYTE NEAR 2 BYTE 4 1 LPBYTE BYTE FAR 4 BYTE 4 2 PINT int NEAR 2 INT 4 1 LPINT int FAR 4 INT 4 2 PWORD WORD NEAR 2 WORD 4 1 LPWORD WORD FAR 4 WORD 4 2 PLONG long NEAR 2 long 4 1 LPLONG long FAR 4 long 4 2 PDWORD DWORD NEAR 2 DWORD 4 1 LPDWORD DWORD FAR 4 DWORD 4 2 LPVOID void FAR 4 void 4 2 HANDLE STRICT const void NEAR 2 void 4 1 HANDLE normal UINT 2 void 4 1 HWND STRICT const struct HWND_NEAR 2 const struct HWND_ 4 1 3 HWND normal UINT HANDLE 1 3 PHANDLE HANDLE 2 HANDLE 4 1 4 SPHANDLE HANDLE NEAR 2 HANDLE 4 1 LPHANDLE HANDLE FAR
2. gt gt LA TBraun_Psd TC_812 TC_812GPIB s TC_812ISA TC_832 2 TCalibrate 3 TCalibratePsd s TChooseDeviceCmd TCmd AN N gt OO Om OM dh Oo PA gt ONN OS h hM WH e a O O O O O e a a a ee e O aS Fee e a N ech Anhang F Daten der Quelltextanalyse Seite 229 TCommonDevParam TCounterShowParam _ TCounterWindow TCurve TDC_Drive TDevice TDList TEditWindow e TEncoder TExecuteCmd y TGenericDevice e TMacroExecute TMain TMDIWindow TMList TModalDig TModelessDig TMotor TMotorParam TOptimizeDC_812 TPlotData TPosControl TPsd TPsdRemoteSync TRadicon TScan TScanCmd TScsParameters TSetAdjustmentParam TSetupAreaScan TSetupContinuousScan TSetupScanCmd TSetupStepScan TShowValueCmd TSteering TStoe_Psd TTopographyExecute Tx gt N _ FH OD ON OO G OO A P GO A A ON zl OO P A d OO MOO GO SM Oh Oooh P d d OM GAMM FA gt E VK Gey VKGgy VKG yy g 0 703 SYS PAN s KOMP VKGs s 956 KOMP s 0 703 F 4 Ma komponente Komplexit t VWMC EWMC DIT VK PA Class Name sum v G avgv G max v G max NOC Depth RFC WMC RFC CBO LOCM Parents PubDataAcc PubData DepOnChild Kopplungsmechanismus Kommunikationsart ev G WMC TAbout 6 1 5 3 1 0 2 10 4 6 0 0 1 0 0 FALSE 8 0 6 TAdjustmentExecute 33 4 71 17 1 0 2 13 7 6 3 73 1 0 0 FALSE 9 5 1 65 TAdjustmentPa
3. Formal SU PAN su KOMP y VKG mit PAN BSM BIBM UTM Anzahl der potentiellen Anpassungen von Aufrufen von Routinen der Software Umgebung KOMP BSM BIBM UTM Namen der Komponenten mit Aufrufen von Routinen der Software Umgebung und deren Anzahl VKG BAM BIBM UTM Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten Mit vorhandenen Portierungserfahrungen Metriken und Portierungsaufwand Seite 110 SU K4 s PAgs SAsu BAsy PAN su KOMP VEG mit KA BSR BSR Namen der BS Routinen die nicht angepa t werden k nnen PA ps Anz BSR BSR Anz BSR BSR Anzahl der Namen der BS Routinen ber die w hrend der m Messung keine Informationen vorliegen SAgy SAgs SAg SAT Gesamtzahl der Aufrufe von SU Routinen die anpa bar sind f r die aber keine Aufwandswerte vorliegen BA BAzs BAgyg BA Summe der bewerteten SU Routinen f r die ein Aufwand vorliegt PAN BSM BIBM UTM Anzahl der potentiellen Anpassungen von Aufrufen von Routinen der Software Umgebung KOMP BSM BIBM UTM Namen der Komponenten mit Aufrufen von Routinen der Software Umgebung und deren Anzahl VKG BSM BIBM UTM Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten Betriebssystem Aufrufe BS BSM BSM BSM BSM BSM oder BSM abh ngig von der gegebenen Situation
4. M_arscan cpp 3403 MessageBox GetFocus szMsgLine015 szMsgFailure MBSTOP TSetupAreaScan Dig_OnCommand HWND___ int HWND___ unsigned M_arscan cpp 3466 MessageBox GetFocus szMsgLine015 szMsgFailure MBSTOP TSetupAreaScan Dig_OnCommand HWND___ int HWND___ unsigned KOMP TSetupAreaScan Anz BIBA 3 M_scan cpp 1516 SetFocus GetDigltem GetHandle id_Actor TSetupContinuousScan TSetupContinuousScan TScan_ M_scan cpp 1535 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage TSetupContinuousScan TSetupContinuousScan TScan_ KOMP TSetupContinuousScan Anz BIBA 2 M_steerg cpp 151 MessageBox GetFocus Unbekannter Schritt Meldung MBINFO TSetupScanCmd TSetupScanCmd TCmdTag KOMP TSetupScanCmd Anz BIBA 1 M_scan cpp 1465 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 TSetupStepScan CanClose M_scan cpp 1559 SetFocus GetDlgltem GetHandle cm_InitializeScan TSetupStepScan Dlg_OnCommand HWND___ int HWND___ unsigned M_scan cpp 1577 PostMessage GetFrameHandle WM_COMMAND cm_InitializeScan 0l TSetupStepScan Dlg OnCommand HWND___ intHWND___ unsigned M_scan cpp 1619 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 TSetupStepScan Dlg_OnCommand HWND___ int HWND___ unsigned M_scan cpp 1192 SetFocus GetDlgltem GetHandle id_ChooseMotor TSetupStepScan Dlg_OnInit HWND___ HWND___ long M_scan cpp 1234 SetFocus GetDigltem GetHandle IDOK TSetupStepScan Dlg_OnInit HWN
5. Mit der klassischen Bindung wird die logische Bindung um den zeitlichen Aspekt erweitert D h da die Elemente neben der logischen Bindung auch noch zeitlich miteinander verbunden sind Ein Beispiel hierf r sind Initialisierungskomponenten deren unterschiedliche Initialisierungen eine logische Beziehung aufweisen und zus tzlich zu einem bestimmten Zeitpunkt ausgef hrt werden Prozedurale Bindung liegt immer dann vor falls eine Komponente mehrere Funktionen ausf hrt die einen bestimmten Bezug zu einem gemeinsamen bergeordneten Problem haben Eine Komponente ist kommunikativ gebunden wenn ber die prozedurale Bindung hinaus alle Elemente miteinander kommunizieren D h sie greifen gemeinsam auf bestimmte Daten zu oder tauschen Daten miteinander aus beispielsweise bei der bergabe von Funktionsparametern in der die Ausgabe einer Funktion die Eingabe einer anderen Funktion darstellt Informal gebundene Komponenten f hren verschiedene Funktionen aus welche durch den Einsprungspunkt in der jeweiligen Komponente repr sentiert werden Jeder Einsprungspunkt hat hierbei die Eigenschaften einer funktional gebundenen Komponente Eine funktionale Bindung besteht wenn alle Elemente einer Komponente an der Ausf hrung einer einzigen abgeschlossenen Funktion beteiligt sind So sind z B einfache mathematische Funktionen wie die Berechnung der Quadratwurzel Systemkomponenten mit funktionaler Bindung Funktionale Bindung erm glicht
6. PS LE A PAps SAps BAps mit KA ps SK SK Konstrukte die nicht angepa t werden k nnen PA Anz SK SK Anz SK SK Anzahl und Namen der Konstrukte ber die w hrend der Messung keine Informationen vorliegen SAps Anz SK Anz SK Anzahl der Konstrukte die anpa bar sind f r die aber keine Aufwandswerte vorliegen BA Anz SK B Anz SK RB Bewertung der Sprachkonstrukte fiir die ein Aufwand vorliegt B Aufwand f r die Anpassung des i ten Konstruktes b Rs Verh ltnis Gesamtzahl an Statements zur Anzahl anzupassender Statements PS Anzahl aller zu ndernden Statements Gesamtzahl aller Statements i Verwendung mehrerer Programmiersprachen und Messung dialektspezifischer Aufrufe mit vorhandenen Portierungserfahrungen f r jede Programmiersprache PS LKA ces P ps Gus S ps Gus BAps_ces mit KAgps ces LE Jet KAps Menge der nicht anpa baren Konstrukte der einzelnen Programmiersprachen P i 1 n PA Ges PApg1 gt PAps Menge der Konstrukte der einzelnen Programmiersprachen zu denen keine Informationen existieren SAps ces SAps Ada Summe der anpa baren Konstrukte der einzelnen Sprachen PS zu denen keine Bewertungen existieren BAps Ges BAps BAps Summer der bewerteten Konstrukte der einzelnen Sprachen PS 1 Zusammenfassung der zweiten Ma e der Programmiersprachen PS PS PS Metriken und Portierungsa
7. mGetAxisUnit mGetSF mGetDF mExecuteCmd char_ mPushSettings mPopSettings TMParameter LibMain HINSTANCE____ unsigned_short unsigned_short char_ DilEntryPoint void_ unsigned_long void_ LibMain HINSTANCE___ unsigned_short unsigned_short char_ WEP int mSavePosition unsigned_int unsigned_int unsigned_long unsign mGetMoveScan M_layer cpp 459 LPCSTR _export WINAPI mGetAxisUnit void M_layer cpp 464 LPCSTR _export WINAPI mGetSF void M_layer cpp 469 LPCSTR _export WINAPI mGetDF void M_layer cpp 474 int _export WINAPI mExecuteCmd LPSTR cmd M_layer cpp 479 void _export WINAPI mPushSettings void M_layer cpp 484 void _export WINAPI mPopSettings TMParameter mp M_layer cpp 492 int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR M_layer cpp 496 BOOL DIIEntryPoint HANDLE hModule DWORD dwFunction LPVOID M_layer cpp 527 int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR M_layer cpp 535 int CALLBACK WEP int M_layer h 233 void CALLBACK mSavePosition DWORD DWORD DWORD M_layer h 240 LPLONG WINAPI mGetMoveScan M_layer h 304 typedef LPLONG WINAPI TGetMoveScan void M_layer h 307 typedef void CALLBACK TSavePosition UINT UINT DWORD DWORD DWORD m_Iscan h 19 DWORD GetlmageSize BITMAPINFOHEADER amp m_lscan h 73 void rButtonDown LONG IParam M_main cpp 154 int PASCAL WinMain HINSTANCE hinstance HINSTANCE M_main cpp 178 wndClass IpfnWndProc FrameWndProc M_main cpp 179 wndClass cb
8. EWMC Max ev M ev M H mit ev M essentielle Komplexit t der j ten Methode in der i ten Komponente Dokumentation Die Teilma e zur Standart und Portierungsdokumentation sind unabh ngig vom zugrunde liegenden Programmierparadigma da sie lediglich das Vorhandensein von Dokumentationsteilen feststellen und Metriken und Portierungsaufwand Seite 130 keinen direkten Messungen am Quellcode vornehmen Die programminterne Dokumentation vermi t hingegen das Vorhandensein von Dokumentationsteilen innerhalb der Quellen und mu daher an objektorientierte Software Systeme angepa t werden Im vorgestellten Portabilit tsma werden der Komponentenkopf Kommentarzeilen die u ere Form und die Namensgebung gepr ft Der Komponentenkopf sollte zus tzlich zur Methoden und Attributbeschreibung auch eine entsprechende Klassenbeschreibung enthalten soda hier ein weiteres bin res Ma dazugenommen werden sollte Au erdem m ssen Attribute und Methoden als Klassenkomponenten ber cksichtigt werden Alle anderen Ma e lassen sich ebenfalls ohne nderung auf objektorientierte Software Systeme bertragen Aufbau Teilma Programminterne Dokumentation f r objektorientierte Software Systeme DOK y Programminterne Dokumentation KK KZ AF NL Komponentenkopf Kommentarzeilen u ere Form Namensgebung Klassenbeschreibung Autor Erstellungsdatum Import Export Aufrufende Aufgerufene Methoden KB AE der Methoden
9. k d d Gewichtungsfaktoren der Datenkopplungsart PK Parameter der i ten Komponente GDK globale Datenzugriffe der i ten Komponente Aufruf und Verzweigung KP m AK m FE mit KP Kopplung der i ten Komponente i k m m Gewichtungsfaktoren der Kopplungsmechanismen AK Aufrufe der verschiedenen Komponenten VP Verzweigungen in verschiedene Komponenten Aufbau Teilma Interne Komponentenkomplexit t IKK Interne Komponentenkomplexit t Zyklomatische Komplexit t Strukturelle Komplexit t V K S K Formal Metriken und Portierungsaufwand Seite 118 IKK V K S K Zyklomatische Komplexitat k V K DIV K i l mit V K Komplexit t der i ten Komponente k Anzahl der Komponenten V K e n 2 mit e Anzahl der Pfeile in einem Graphen n Anzahl der Bedingungen in Entscheidungsknoten i i te Komponente bzw einfacher durch V K 6 1 mit b Anzahl der Bedinungen der i ten Komponente Verschachtelung k S K 9S K i l mit S K Verschachtelungswert der i ten Komponente k Anzahl der Komponenten z 1 SK 20 7 mit j 12 n K i te Komponente n Anzahl aller Verzweigungen in einem Graphen d Anzahl der vom j ten Verzweigungsknoten dominierten weiteren Verzweigungsknoten 1 Es folgt der Aufbau f r das Teilma Dokumentation DOK Dokumentation Standarddokumentation Portierungsdokumentation Programminterne Dokumantation DO
10. Autor und Erstellungsdatum AE Autor und Erstellungsdatum vorhanden nicht vorhanden Import Export IE Auflistung Import Export vorhanden nicht vorhanden Aufrufende Aufgerufene Komponente AS Auflistung der abh ngigen Systemkomponenten vorhanden nicht vorhanden 3 2 3 5 Bewertung Das vorgestellte Ma bestimmt den Aufwand einer Portierung anhand der Einflu faktoren Systemumgebung Komplexit t und Dokumentation Um von einem Ma sprechen zu k nnen m ssen nach der Definition von Balzert siehe Kapitel 3 1 2 bestimmte G tekriterien erf llt sein Objektivit t Intersubjektivit t d h da ein Ma erst dann als objektiv bezeichnet werden kann wenn keine subjektiven Einfl sse des Messenden auf die Messung m glich sind Zuverl ssigkeit Me genauigkeit d h bei der Wiederholung der Messung unter denselben Me bedingungen werden dieselben Me ergebnisse erzielt womit ein Ma als stabil und pr zise bzw zuverl ssig bezeichnet werden kann Validit t G ltigkeit Me tauglichkeit d h da die Me ergebnisse einen eindeutigen und unmittelbaren R ckschlu auf die Auspr gung der Kenngr e erlauben Normierung d h es existiert eine Skala auf der die Me ergebnisse eindeutig abgebildet werden und zus tzlich eine Vergleichbarkeitsskala sozusagen als Referenzsystem zur Klassifizierung von Me ergebnissen vorhanden ist die das Ma entsprechend normiert Vergleichbarkeit d h da das Ma
11. Emulatoren Ein im Vergleich zu portablen Betriebssystemen umgekehrtes Konzept n mlich die Hardware an die Software anzupassen erschlie t sich durch die Realisierung von Emulatoren Hierbei werden die Eigenschaften der Hostumgebung auf dem Zielrechner abgebildet und erm glichen somit die Portierung von Software Systemen ohne dessen explizite Anpassung Wird die Nachbildung softwaretechnisch realisiert so ist dies nach Gewald Gewald 79 ein Simulator Bei hardwaretechnisch realisierten Abbildungen spricht man von Emulatoren Diese Unterscheidung trifft man heutzutage jedoch nur noch selten und es hat sich f r beide Formen der Begriff Emulator etabliert Man spricht im Allgemeinen von Simulatoren wenn reale Abl ufe rechnergest tzt simuliert werden Somit soll hier nur von Emulatoren die Rede sein Softwaretechnisch realisierte Emulatoren werden h ufig dann eingesetzt wenn das zu portierende Software System keine allzu gro en Anforderungen an die Ausf hrungsgeschwindigkeit stellt Hierin liegt auch der gr te Nachteil von softwarem ig realisierten Emulatoren Die Ausf hrungsgeschwindigkeit der darauf ablaufenden Programme ist im Vergleich zur realen Hostumgebung stark verringert Ein Beispiel f r einen solchen Emulator ist der von Doyle und Mandelberg entwickelte PDP 11 Emulator Doyle 84 Dieser Emulator wurde entwickelt um Unix auf eine SPERRY UNIVAC 90 80 einem 32 Bit Rechnersystem und auf eine NOVA 3 eine
12. Komplexit t der i ten Komponente k Anzahl der Komponenten Portabilit tsanalyse am Beispiel des XCTL Systems Seite 162 VWMC Y g M und g M v M j l mit HOM Komplexit t der j ten Methode einer i ten Komponente n Anzahl der Methoden F r das XCTL System ergeben sich hierf r folgender Werte ermittelt mit dem McCabe Toolset k V K VWMC 3285 i l Strukturiertheit Schritte zur Ermittlung der MaBkomponente Strukturiertheit Ermittlung EWMC McCabe Toolset auswerten Berechnung der Strukturiertheit des Software Systems S K F r das Ma der Strukturiertheit eines Software Systems wird die essentielle zyklomatische Zahl als Grundlage genommen Das Maf hatte folgenden Aufbau S K Y EWMC i l mit EWMC Maximale essentielle Komplexit t der i ten Komponente ber alle Methoden k Anzahl der Komponenten EWMC Max ev M ev M mit ev M essentielle Komplexit t der j ten Methode in der i ten Komponente Das XCTL System weist f r das Ma der Strukturiertheit S K folgenden Wert auf k S K Y EWMC 398 i l Aggregation zum Gesamtma Interne Komponentenkomplexit t Das Ma f r die interne Komponentenkomplexit t setzt sich aus zwei Ma zahlen zusammen IKK V K S K Eine Addition der beiden Komplexit tswerte wird auf dieser Ebene nicht durchgef hrt da beide Ma e unterschiedliche Komplexit tsarten messen So mi t die
13. Maschinenarchitektur Peripherieger te MAM PGM ON SC Anzahl Architektur Aufrufe f Anzahl Peripherie Aufrufe x a x MAM Einarbeitungsaufwand PGM Einarbeitungsaufwand N 2 2 MAM Verhaltnis Gesamtkomponenten zur PGM Verh ltnis Gesamtkomponenten zur 3 Anzahl anzupassender Komponenten 3 Anzahl anzupassender Komponenten Schritte zur Ermittlung des Teilma es Hardware Umgebung Ermittlung der Ma komponente Maschinenarchitektur Ermittlung der Ma komponente Peripherieger te Zusammenfassung zur Ma komponente Hardware Umgebung Maschinenarchitektur Schritte zur Ermittlung der Ma komponente Maschinenarchitektur Ermittlung Anzahl unterschiedlicher BS Aufrufe MAM Alternativ MAM Porttool auswerten Berechnung MAM Ermittlung der Komponenten mit jew Gesamtzahl MAM Porttool auswerten Berechnung MAM Komponentenverh ltnis berechnen MAM Berechnung der Ma komponente MA Zu den entscheidenden Abh ngigkeiten bei der Maschinenarchitektur geh ren Zugriffe auf Register wie z B Steuer oder Statusregister Zugriffe auf Speicherstellen z B in gemeinsam genutzten Speicherbereichen oder Bildschirmspeicher Zugriffe auf Ports bzw Kommunikation ber Ports z B um Mausabfragen zu realisieren Aufrufe von Assemblerroutinen Hardwarezugriffe lassen sich bei einer statischen Untersuchung des Quellcodes nicht immer
14. Programmiersprachen PS Verhaeltnis Statements PS2 mehrere Prog sprachen PS2 Verhaeltnis DKK Verhaeltnis KPK HEE Aufrufe versch Komponenten RFC Komponentenkopplung KP nicht eingeerbte Methoden WMC Massbaum Portabilitaet eingeerbte Methoden VB Schnittstellenkomplexitaet SK von Klassen CBO Kommunikationsart bzw Datenkopplung S DK Vererbungshierarchie DIT Globale Daten PA Komplexitaet KPL zyklomatische logische Komplexitaet Interne Komponentenkomplexitaet IKK V K Strukturiertheit S K durchschnittliche zykl Komplexitaet DLK Designdokumentation DD Implementierungsdokumentation ID Standarddokumentation DOKst Benutzerdokumentation BD Technische Dokumentation TD Angabe der Portierungsschritte PS Angabe ueber Annahmen zum Zielrechner AZ Installationsdokumentation INS Portierungsdokumentation DOKpt Komponenten HK Begriffsklaerung VB Dokumentation DOK Testdaten TDA Beschreibung Systemkomponente KB Beschreibung Klassenkomponenten MB Autor und Erstellungsdatum AE Komponentenkopf KK Auflistung Import Export IE Programminterne Dokumentation DOKpi Systemkomponenten AS Kommentarzeilen KS Auessere Form AF Namensgebung BL Abbildung 25 bersicht Ma baum f r das Qualit tsmerkmal Portabilit t D
15. TC_812 87 2 81 8 6 2 3 67 33 34 15 80 1 0 100 FALSE 50 5 6 15 TC_812GPIB TC_8121SA TC_832 TDataBase TDC_Drive TDevice TDList TEditWindow TEncoder TExecuteCmd TGenericDevice TGetData TGotolntensityCmd TGotoPeakCmd TinquireCmd TLoadPointCmd TMacroExecute TMain TMDIWindow TMeasurementParam TMList TModalDig TModelessDlg TMotor TMotorParam TMoveToPointCmd TOptimizeDC_812 TOptimizeDC_832 TPiezoDrive TPlotData TPosControl TPsd 20 44 62 17 43 74 63 28 13 26 20 20 39 87 71 68 18 21 135 28 105 30 86 4 4 2 14 1 42 1 59 1 57 3 71 1 47 1 86 2 25 2 89 3 33 3 33 1 5 7 8 6 21 1 42 4 25 4 38 3 75 2 25 11 13 27 25 32 12 30 13 12 15 10 63 64 63 12 60 47 17 58 48 10 70 51 11 16 12 18 54 11 15 11 11 48 58 13 58 10 29 12 27 47 17 19 14 51 16 12 18 54 24 38 57 54 34 33 39 41 61 10 10 13 13 12 47 34 20 17 18 13 50 71 92 73 97 94 78 80 100 75 16 35 56 70 90 95 90 86 94 95 75 50 51 84 65 94 42 80 94 100 100 100 89 75 17 75 71 73 FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
16. TModalDlg Anz BIBA 3 308 if IDYES MessageBox GetFocus szMsgLine001 szMsgFailure MBASk 441 FORWARD_WM_COMMAND GetHandle cm_InquireExeption 0 0 PostMessage TMList InitializeModule TMList MP TModalDlg TModalDlg TModalDlg TModalDlg char_ TModalDlg TModalDlg char_ Dig_tpl cpp 141 dialogFunc DLGPROC MakeProcinstance FARPROC ModelessProc GetMainInstance TModelessDig TModelessDig char_ Dig_tpl h 59 virtual void Dlg_OnSetFocus HWND HWND KOMP TModelessDlg Anz BIBA 2 0 Motors cpp 1870 MessageBox GetFocus buffer szMsgFailure MBINFO KOMP TMotor Anz BIBA 1 Motors cpp 1051 SetFocus GetDigltem GetHandle id_Velocity KOMP TMotorParam Anz BIBA 1 M_data cpp 1507 SetCapture hWndChild M_data cpp 2337 MessageBox GetFocus msg Fehler MB_OK MB_ICONHAND KOMP TPlotData Anz BIBA 2 Motors cpp 923 FORWARD_WM_COMMAND hwnd cm_SetupDlgltem hwndCtl 0 SendMessage TPosControl Motors cpp 936 FORWARD_WM_COMMAND hwnd cm_Motorlnit hwndCtl 0 PostMessage Motors cpp 958 FORWARD_WM_COMMAND hwnd cm_MoveButton hwndCtl 0 PostMessage Motors cpp 959 SetFocus GetDlgltem GetHandle id_Bar Motors cpp 966 FORWARD_WM_COMMAND hwnd cm_SetupDigltem hwndCtl 0 PostMessage TPosControl Motors cpp 875 SetFocus BarHandle Motors cpp 895 FORWARD_WM_COMMAND hwnd cm_SetupDlgltem 0 0 SendMessage KOMP TPosControl Anz BIBA 7 Counters cpp 785 MessageBox GetF
17. also noch vor dem Macintosh auf dem Markt f r IBM PC s und wurde durch einige Modifikationen in der Benutzeroberfl che durch die Version 2 0 1 im Jahre 1987 abgel st Beide Versionen kamen mit den Prozessormodellen 8086 und 8088 von Intel zurecht die im Real Mode liefen und maximal 1 MB Speicher adressieren konnten Kurz nach dem Erscheinen von Version 2 0 kam ein Windows 386 im Jahre 1988 f r den Prozessor 80386 auf den Markt das den Virtual 8086 Mode unterst tzte Dadurch war es zum erstenmal m glich DOS Programme durch Simulation mehrerer voneinander unabh ngiger Computer parallel ablaufen zu lassen wobei diese auch direkt auf die zugrundeliegende Hardware zugreifen konnten Die Version 3 0 von Windows wurde im Mai 1990 vorgestellt Sie vereinigte die 386er und 286er Version Bezeichnung der Nachfolgeversion von Windows 2 0 die konsequenterweise als Windows 286 eingef hrt wurde und unterst tzte den Protected Mode f r Modelle ab dem 80286 Diese Version fand im Heim und B robereich eine weite Verbreitung Mit Hilfe des Protected Mode konnten Anwendungsprogramme einen Hauptspeicher von bis zu 16 MB adressieren und somit die 640 KB Grenze von MS DOS berschreiten Windows 3 1 erschien im April 1992 und hatte wesentliche Neuerungen aufzuweisen Dazu geh rten die TrueType Technologie skalierbare Outline Schriften auch f r den Bildschirm ein Grundger st f r Mutimedia Anwendungen das Einbetten und Verkn pfen
18. atic DWORD dwExposureCounts KOMP TChooseDeviceCmd Anz MAA 1 M_device cpp 363 value_s short atoi buf KOMP TCounterShowParam Anz MAA 1 M_device cpp 180 void TCounterWindow rButtonDown LONG IParam KOMP TCounterWindow Anz MAA 1 TC_832 UINT UINT DWORD DWORD DWORD TC_832 UINT UINT DWORD DWORD DWORD TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_832 TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB TC_812GPIB CheckBoardOk FARPROC gBoardPresent GetProcAddress hGPIBModule IEEE488_BOARD_PRESENT TC_812GPIB TC_812GPIB Drive628 unsigned_char unsigned_short long LimitWatch unsigned_int unsigned_int unsigned_long u LimitWatch unsigned_int unsigned_int unsigned_long u SetLimit unsigned_long SetLimit unsigned_long SetVelocity unsigned_long StopDrive int LimitWatch unsigned_int unsigned_int unsigned_long u SetVelocity unsigned_long GetVelocity SetAcceleration unsigned_long GetAcceleration SetLimit unsigned_long GetStatus GetStatus Drive628 unsigned_char unsigned_short long Drive628 unsigned_char unsigned_short long TC_832 TChooseDeviceCmd TChooseDeviceCmd TCmdTag TCounterShowParam CanClose TCounterWindow rButtonDown long Anhang F Daten der Quelltextanalyse Seite 217 Motors cpp 2
19. carriage return und ein newline CRLF um eine Zeile zu beenden wobei Unix Systeme nur newline verwenden Ohne diese Markierungen des Zeilenendes k nnte man eine Textdatei als eine riesige Zeile betrachten und die Zahl der Zeilen bzw Zeichen w re somit falsch oder w rde sich unerwartet ndern Werden f r dieses Portabilit tsproblem Standardschnittstellen eingesetzt die CLRF s in jeder Umgebung konsistent behandeln w ren damit weitere Portierungsprobleme eliminiert Wobei f r h ufig zu transportierende Textdateien Programme zur Umwandlung der beiden Formate notwendig sind Bin rdateien hingegen ben tigen spezialisierte Werkzeuge und k nnen manchmal sogar auf dem gleichen Rechnersystem nicht zusammen verwendet werden Sie sind mit gro en Portabilit tsproblemen behaftet Reihenfolge der Bytes Um Bin rdateien von einem Rechnersystem auf ein anderes zu bertragen sollten diese auch wegen der Fehlererkennung f r den Transport portabel kodiert werden Bin re Daten sind bei vielen Aspekten in Netzwerken unentbehrlich da sie erheblich schneller und kompakter zu dekodieren sind Benutzt man f r den Datenaustausch eine festgelegte Byte Reihenfolge f r Sender und Empf nger sind die wichtigsten Portabilit tsprobleme bereits behoben Verallgemeinert l t sich dieses Vorgehen auch auf Strukturen anwenden Man mu sich jedoch darauf verst ndigen in welcher Reihenfolge die Bytes und wie viele davon bertragen
20. ev M 1 EWMC gy Max ev M go ev M 1 k S K Y EWMC 398 IKK V K S K 3285 398 IKK k V K k S K 0 5 3285 0 5 398 1841 5 ager Anhang F Daten der Quelltextanalyse Seite 234 F 4 3 Ermittlung Ma komponente Komplexit t KPK KP E KP Ri 1622 5 0 506 Anzahl der Kopplungen aller Komponenten RFC VK 2048 1161 ee DK DK IS 9999 i Anzahl aller Datenkopplungen CBO PA DIT 8 259 0 177 DLK V K 295 23 Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 235 Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit The procedure for migrating XCTL project from Borland to Visual C consists of the following steps 2 3 4 5 2 Create new Visual C projects described in Section 1 Update project settings as described in Section 2 Make neccessary changes to source files as described in section 3 Make neccessary changes to resources as described in Section 4 Build all executable files exe and dlls Project Rebuild all If there are any errors left these errors can guide you to make more changes to source files Once the build is successful copy other neccessary files to output directory Debug directory under the project root for debug build which is active by default such as other dlls ini mak hlp dat You should now be able to execute program I tested it only for
21. 262 loat WINAPI _ export Getintensity_A913 void 507 loat WINAPI _ export maxf float value1 float value2 511 loat WINAPI _ export minf float value1 float value2 18 BOOL WINAPI dSetExposureValues float DWORD float 19 BOOL WINAPI dGetExposureValues float amp DWORD amp float amp InitializeCountersDLL GetCounterListPtr diSetDevice int dMeasureStart dMeasureStop dSetExposureValues float unsigned_long float dSetExposureValues float unsigned_long float dGetExposureValues float_ amp unsigned_long_ amp float_ amp dSetExposureValues float unsigned_long float diGetDevice a IGetldByName TDeviceType a IParsingDevice char_ dllsDeviceValid TDeviceType nquirelntensity_SCS unsigned_int unsigned_int unsigned_long nquirelntensity_SCS unsigned_int unsigned_int unsigned_long nquirelntensity_SCS unsigned_int unsigned_int unsigned_long GetiIntensity_SCS nquirelntensity_TDC unsigned_int unsigned_int unsigned_long nquirelntensity_TDC unsigned_int unsigned_int unsigned_long nitializeTDC_Event float HWVND___ Getintensity_TDC nquirelntensity_A913 unsigned_int unsigned_int unsigned_lon nquirelntensity_A913 unsigned_int unsigned_int unsigned_lon nquirelntensity_A913 unsigned_int unsigned_int unsigned_lon Getintensity_A913 maxf float float minf float float dSetExposureValues float unsigned_long float dGetExposureValues float_ amp unsigned_long_ amp float_ amp 21 vo
22. INS 0 4 PS 0 3 AZ 0 2 HK 0 1 VB Testdaten TDA Testdaten vorhanden nicht vorhanden Angabe Portierungsschritte PS Angabe der Portierungsschritte vorhanden nicht vorhanden Annahme Zielrechner AZ Angabe der ber den Zielrechner gemachten Annahmen vorhanden nicht vorhanden Angabe hardwareabh ngiger Komponenten HK Angabe der hardwareabh ngigen Komponenten vorhanden nicht vorhanden Begriffskl rung Metriken und Portierungsaufwand Seite 121 VB Erkl rung der verwendeten Begriffe vorhanden nicht vorhanden Aufbau Teilma Programminterne Dokumentation DOK y Programminterne Dokumentation KK KZ AF NL Komponentenkopf Kommentarzeilen u ere Form Namensgebung Funktionsbeschreibung Autor Erstellungsdatum Import Export Aufrufende Aufgerufene Komponente Formal 4 DOK y 8 KK g KZ g AF g NL wobei gilt gt e 1 i 1 Hypothese DOK w 0 3 KK 0 3 KZ 0 3 AF 0 1 NL Komponentenkopf 4 KK g FB g AE g IE g AS wobei gilt Y g 1 i l Hypothese KK 0 25 FB 0 25 AE 0 25 JE 0 25 AS Kommentarzeilen KZ Benutzung von Kontrollstatements dokumentiert nicht dokumentiert u ere Form AF Quellcode strukturiert nicht strukturiert Namensgebung BL durchschnittliche Bezeichnerl nge 5 9 Zeichen nicht 5 9 Zeichen Funktionsbeschreibung Metriken und Portierungsaufwand Seite 122 FB Beschreibung der Systemkomponente vorhanden nicht vorhanden
23. In dem Qualit tsmodell f r Software Produkte der DIN ISO 9126 werden neben den Qualit tsmerkmalen wie Funktionalit t Zuverl ssigkeit Benutzbarkeit Effizienz und nderbarkeit auch die bertragbarkeit als Merkmal f r die Eignung eines Software Systems von einer Umgebung in eine andere bertragen zu werden festgelegt F r das Qualit tsmerkmal Ubertragbarkeit werden in Balzert 98 die Teilmerkmale Anpafbarkeit M glichkeiten ein Software System an verschiedene festgelegte Umgebungen anzupassen Installierbarkeit Aufwand der Installation eines Software Systems in einer festgelegten Umgebung Konformit t Grad in dem die Software Normen oder Vereinbarungen zur bertragbarkeit erf llt und Austauschbarkeit M glichkeit oder Aufwand das Software System anstelle eines anderen spezifizierten Software Systems in einer Umgebung einzusetzen vorgeschlagen Andere Qualit tsmodelle beschreiben in Bezug auf die bertragbarkeit von Software Systemen hnliche Teilmerkmale Software Qualit t Qualit ts Merkmal 1 Qualit ts Merkmal 2 z B Funktionalit t z B Zuverl ssigkeit en Q Teilmerkmal 1 Qualit ts Merkmal n z B bertragbarkeit Q Teilmerkmal n Q Teilmerkmal 2 z B Anpa barkeit Q Teilmerkmal 3 Q Indikatoren Metriken z B zur Portabilit tsanalyse Abbildung 23 Qualit tsmodelle als Anwendungsrahmen f r Met
24. Porttool auswerten Berechnung BIBM Ermittlung der Komponenten mit jew Gesamtzahl B BM Porttool auswerten Berechnung BIBM Komponentenverh ltnis berechnen BIBM Berechnung der MaBkomponente BIB bzw BIB Portabilit tsanalyse am Beispiel des XCTL Systems Seite 143 Bei Anpassungen in Hinblick auf Bibliotheksroutinen herrscht in etwa die gleiche Situation wie bei den Betriebssystem Aufrufen Auch hier werden zun chst die Anzahl der anzupassenden Aufrufe von Bibliotheksroutinen ermittelt Danach wird wie zuvor bei den Betriebssystem Aufrufen die Verteilung auf die Komponenten berechnet Zum Schlu wird dann das Verh ltnis zur Gesamtkomponentenzahl gebildet Stehen au er dem Verzeichnis der Bibliotheksroutinen die an das Zielsystem anzupassen sind Inhalt der zentralen Problembibliothek keine weiteren Informationen zur Verf gung weil etwa noch keine Portierung stattgefunden hat so wird in einem ersten Schritt nur die Anzahl potentieller nderungen ermittelt BIBM Anz BIBR Anz BIBR mit BIBR i ter unterschiedlicher BIB Aufruf i 1 n Die anzupassenden Bibliotheksroutinen werden sofern sie in der zentralen Problembibliothek erfa t sind automatisch durch das Porttool Werkzeug ermittelt und manuell in das Ma BIBM eingebracht Der ermittelte Wert f r das XCTL System betr gt BIBM Anz BIBR Anz BIBR 353 siehe Anhang F Nach erfolgter Porti
25. SK KP DK F r das XCTL System konkretisiert hei t das SK KP DK 1622 5 11 95 4 2 2 2 Interne Komponentenkomplexit t Wie bereits diskutiert unterscheidet man eine Vielzahl von Bindungsarten zwischen den Elementen einer Komponente Da jedoch die automatische Bestimmung der Bindungsart aufgrund fehlender objektiv me barer Kriterien nicht m glich ist und sie nur mittels eines Code Review bestimmbar ist kann dieser Ansatz nicht in das Portierungsma eingehen Es ist jedoch m glich die interne Komplexit t einer Komponente durch die Anzahl Tests zu bestimmen die notwendig sind um deren Korrektheit zu berpr fen Hierf r hat McCabe zur Ermittlung der Testbarkeit einer Komponente oder Portabilit tsanalyse am Beispiel des XCTL Systems Seite 161 Programms die zyklomatische Zahl vorgeschlagen Der Vorteil hierbei ist die einfache Berechnung dieser Ma zahl f r die logische Komplexit t Nachteil ist wie bereits oben erw hnt worden ist da nur das Programmger st und nicht die Komplexit t einzelner und verschachtelter Anweisungen ber cksichtigt wird Um auch die Strukturiertheit eines Software Systems in das Portierungsma mit eingehen zu lassen kann u a die Schachtelungstiefe berechnet werden und als Gradmesser f r die Strukturiertheit eines Systems gelten Neben der Schachtelungstiefe kann auch die essentielle zyklomatische Zahl als Ma f r die Strukturiertheit eines Software Systems herangezogen werden
26. TAbout Anz BIBA 2 M_steerg cpp 3164 SetFocus GetDlgltem GetHandle cm_Start M_steerg cpp 3129 FORWARD_WM_COMMAND GetHandle cm_ParamSet 0 0 PostMessage KOMP TAdjustmentExecute Anz BIBA 2 TAdjustmentExecute Dig_OnInit HWND___ HWND___ long M_steerg cpp 3348 MessageBox GetFocus ContinuousScan wurde ausgef hrt Justagen MBINFO KOMP TAdjustmentWindow Anz BIBA 1 Am9513 cpp 274 Am9513 cpp 317 TAdjustmentExecute Dlg_OnInit HWND___ HWND___ long TAdjustmentWindow CounterSetRequest long MessageBox GetFocus Fehler beim Zerlegen Am9513a MBINFO TAm9513a SplitNumber unsigned_long unsigned_short_ amp unsigne MessageBox GetFocus buf Device Fehler Am9513a MBINFO KOMP TAm9513a Anz BIBA 2 M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d M_d g cpp g cpp CDD g cpp g cpp CDD g cpp g cpp g cpp CDD g cpp g cpp CDD g cpp g cpp g cpp CDD g cpp CDD CDD g cpp g cpp g cpp g cpp g cpp 767 396 757 745 742 740 732 729 695 680 679 637 636 628 627 619 618 610 609 597 570 543 542 526 519 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage SetFocus BarHandle FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWARD_WM_COMMAND hwnd cm_MoveButton 0 0 SendMessage mMoveToDistance mGetValue MaxDistance FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWA
27. m_motcom h Motorsteuerung Anhang D Quellen bersicht des XCTL Systems Seite 197 dig_tpl cpp motors rc counters dll counters cpp c_layer cpp am9513 cpp braunpsd cpp kisl1 c kmpt1 c dlg_tpl cpp selbstdefinierte Templateklassen f r Dialogobjekte inklusive der Methoden Dialogressourcen f r Motoren Klassen f r die Ansteuerung der Detektoren C Schnittstelle f r die Ansteuerung der Detektoren Klassen f r die Ansteuerung der Z hlerkarte Am9513A Klassen zur Ansteuerung des BraunPSD Radicon SCSCS Treiber Funktionen f r Kommunikation mit der Radicon Controllerkarte selbstdefinierte Templateklassen f r Dialogobjekte inklusive der Methoden m_mothw h m_layer h rc_def h comhead h dgl_tpl h rc_def h rc_def h comhead h m_devcom h m_devhw h c_layer h m_layer h rc_def h comhead h m_devcom h m_devhw h c_layer h m_layer h dfkisl h rc_def h comhead h am9513a h rc_def h comhead h m_devcom h m_psd h dfkisl h prkmpt1 h radicon h dfkisl h prkmpt1 h Motorsteuerung Motorsteuerung Interaktion mit der Software Windows Ressourcen Nicht zugeordnet Interaktion mit der Software Windows Ressourcen Windows Ressourcen Detektornutzung Windows Ressourcen Nicht zugeordnet Detektornutzung Detektornutzung Detektornutzung Motorsteuerung Detektornutzung Windows Ressourcen Nicht zugeordnet Detektornutzung Detektornutzung Detektornu
28. mit wachsender Programmgr e und fallender Programmebene der Aufwand einer Implementierung eines Software Systems steigt definiert Halstead diesen durch das Verh ltnis von Programmvolumen zu Programmebene Die erforderliche Zeitdauer der Implementierung 7 wird dann mit der sogenannten Stroudschen Zahl ins Verh ltnis gesetzt Die Stroudsche Zahl gibt die Anzahl elementarer geistiger Vergleiche an die ein Mensch physisch pro Sekunde durchf hren kann In der Programmierpraxis hat sich hier ein Wert von 18 als realistisch erwiesen Neben den hier angesprochenen Metriken existieren noch weitere Metriken und Alternativen auf die hier nicht weiter eingegangen werden soll Die von Halstead definierten Metriken besitzen den Vorteil da sie einfach zu ermitteln und zu berechnen sind f r alle Programmiersprachen eingesetzt werden k nnen und als gr tenteils signifikant eingestuft werden So korrelieren beispielsweise 7 und 77 stark mit der Programmgr e und der Fehlerrate d h da mit zunehmender Programmgr e auch ein Metriken und Portierungsaufwand Seite 90 entsprechender Anstieg von 77 und 77 zu verzeichnen war Andere Metriken wie das potentielle Volumen H oder die Programmebene E scheinen nicht darauf hinzudeuten das zu messen was sie scheinbar vorgeben zu messen Ein grundlegendes Problem besteht auch in den Mehrdeutigkeiten des MeBansatzes Dies betrifft z B die Klassifikationsregeln f r Operanden und Operator
29. nderungen erforderlich machen Portabilit t und Upgrades Verschiedene Portabilit tsprobleme treten immer dann auf wenn die zugrunde liegende System Software wie z B das Betriebssystem w hrend der Lebensdauer des Software Systems modifiziert wird und somit Inkompatibilit ten zwischen vorhandenen Programmversionen hervorruft Somit k nnen nderungen an der System Software unterschiedliche Versionen eines bestimmten Software Systems erzeugen die sich zwar absichtlich unterschiedlich verhalten aber auch zu unabsichtlichen Portabilit tsproblemen und Versionskonflikten f hren Eine konsistente auf die einzelnen Versionen abgestimmte Namensgebung kann hier viel zur bersichtlichkeit beitragen Ein weiteres Problem ist die Kompatibilit t zu vorhandenen Software Systemen und deren Daten So ist es allgemein blich da neuere Versionen einer bestimmten Software Daten aus lteren Versionen uneingeschr nkt verarbeiten k nnen Abw rtskompatibilit t Somit ist es ebenfalls notwendig darauf zu achten da man nicht in Konflikt mit bestimmten Vorg ngerversionen und den Daten die davon abh ngen in Konflikt ger t Internationalisierung Betrachtet man das menschliche Umfeld in das Computersysteme eingebettet sind so zeigt sich hier eine Vielfalt an Sprach und Kultureigenheiten auf die bei der Portierung von Software Systemen ebenfalls R cksicht genommen werden mu Das Prinzip der Internationalisierung bedeutet im Bereich
30. 4 2 1 3 Programmiersprachen essen ran nne nn 152 4 2 1 4 Aggregation zum Gesamtma System Umgebung s ss sssssssessssesssessesressesresseeres gt 154 ADD Komplexit t 442 42 a its 156 4 2 2 1 Schnptstellenkomplesit t 157 4 2 2 2 Interne Komponentenkomplexvm t nennen ne 160 4 2 2 3 Aggregation zum Gesamtma Komplexit t sennnensensenennenensnenne 163 4 273 Dokumentation neoane e a a ea aaa a a a E naa S EEE 164 4 2 3 1 Sondarddokumentaton nennen nennen 165 4 2 3 2 Portierungsdokumentation esse nnse nn 167 4 2 3 3 Programminterne Dokumentation essen 169 4 2 3 4 Aggregation zum Gesamtma Dokumentation uneennsnnsenseseseennennen nenne 172 4 3 Zur Portabilit t des SCTI Svstemg 173 Zusammenfassung Anmerkungen Ausblick ssus0000s0000ss000nsenonnsnnnsnesnnnsnsnnnsnnnnesnnsssnnnsnannne 181 Literaturverzeichnis corssosssonssonsssnsssnnssnnssnnssnnssnnssnnnsnnnsnnnsnnnsnsnssonnsnnnsnnnsnnnssnnsnnnssnnnsnnnsnnnsnnsnsnnssnnsnnne 183 Anhang Anhang A Wesentliche Systemunterschiede des betrachteten Portierungsfelds omooooo 187 Anhang B Inhalt der zentralen Problembibliothek ssusssoosssonsesnssssnnssnonnssnnnsesnnnsnsnunnnnne 190 Anhang C Wichtige Datentypen im Vergleich uss0usssussoosssonssonssnnssnnssnnssnnssnnnsnnnsnnnsnonsnannnne 194 Anhang D Quellen bersicht des XCTL Systems u0s00ss0000s0000u00nnnnesnnssssnnnsnsnnnsnnssssnnnsnsn
31. Analog hierzu f r das Ma der internen Komponentenkomplexit t wiederum mit rein hypothetischen Gewichten da noch keine Portierungserfahrungen vorliegen IKK iger k V K k S K 0 5 3285 0 5 398 1841 5 Das Ma KPK wird durch das Verh ltnis der Anzahl der Kopplungen des Software Systems und der gewichteten Kopplungsmechanismen KP aller Komponenten gebildet Das Verh ltnis soll den Grad der Kopplungen unter den Komponenten verdeutlichen Je h her der Wert gegen 1 geht desto schwieriger wird die Einarbeitung und um so umfangreicher ist der nderungsaufwand KP Anzahl der Kopplungen aller Komponenten KPK 0 506 Das gleiche Verh ltnis wird f r die Datenkopplungen des Software Systems gebildet Je h her der Datenkopplungsgrad um so schwieriger die Einarbeitung und desto h her die Zahl der durchzuf hrenden nderungen Portabilit tsanalyse am Beispiel des XCTL Systems Seite 164 pa 0 027 DKK Anzahl aller Datenkopplungen Auch hier bleibt anzumerken daf bei der Vermessung des XCTL Systems keine ausreichenden Me werte f r den Zugriff auf globale Daten ermittelt werden konnten Dieses Ma ist vom McCabe Toolset offensichtlich unkorrekt bestimmt worden Deswegen an diese Stelle noch einmal der Hinweis da die Datenkopplung ber globale Daten in diese Version der Portabilit tsanalyse nicht mit eingeht Neben den bereits ber cksichtigten Ma en soll auch die durchschnittliche zyklomatische Komple
32. Anz BIBA 8 C_layer cpp 259 PostMessage hControlWnd WM_COMMAND cm_CounterSet 77 Inquirelntensity_A913 unsigned_int unsigned_int unsigned_lon C_layer cpp 195 PostMessage hControlWnd WM_COMMAND cm_CounterSet 77 Inquirelntensity_SCS unsigned_int unsigned_int unsigned_long C_layer cpp 213 PostMessage hControlWnd WM_COMMAND cm_SteeringReady 77 Inquirelntensity_TDC unsigned_int unsigned_int unsigned_long C_layer cpp 227 PostMessage hControlWnd WM_COMMAND cm_CounterSet 77 Inquirelntensity_TDC unsigned_int unsigned_int unsigned_long Counters cpp 78 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage Counters cpp 114 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage Counters cpp 187 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage Counters cpp 337 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage Counters cpp 440 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage Counters cpp 1610 PostMessage GetHandle WM_COMMAND cm_ParamSet 0 Counters cpp 1838 PostMessage hEventControlWnd WM_COMMAND cm_CounterSet nCalledEvents Counters cpp 1985 PostMessage GetHandle WM_COMMAND cm_ParamSet 0 Dig_tpl cpp 23 HANDLE_MSG hDlg WM_COMMAND TheDialog gt Dlg_OnCommand DialogProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 24 HANDLE_MSG hDIg WM_HSCROLL TheDialog gt Dlg_OnHScrollBar DialogProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 25 HANDLE_MSG hDlg WM_VSCROLL
33. Auch in Abreu 94 wird die bertragbarkeit der zyklomatischen Komplexit t nach McCabe angezweifelt und sei nur auf Methodenebene direkt anwendbar da nur dort ein Kontrollflu graph im Sinne von McCabe konstruierbar ist Andere Autoren bef rworten die Anwendung der zyklomatischen Komplexit t auch auf Klassenhierarchien und schlagen hierf r eigene Ma e vor Fetcke 95 Chidamber et al Chidamber 94 machen den Vorschlag das Ma von McCabe als Gewichtung f r die Berechung der WMC Metrik einzusetzen und somit f r die Verwendung auf Klassen oder Systemniveau nutzbar zu machen Eine interne Bindungsmetrik f r objektorientierte Systemkomponenten bestimmt die Anzahl der durch die Operationen einer Klasse gemeinsam benutzten Objektattribute LCOM lack of cohesion in methods Diese ist bislang schlecht definiert und bereits mehrmals modifiziert worden und daher als Qualit tsindikator ebenfalls nur bedingt geeignet Balzert 98 Die Frage nach der bertragbarkeit klassischer Produkt Metriken ist umstritten Die Tendenz geht eher in Richtung Anpassung vorhandener klassischer Ma e Diese haben den Vorteil von Anwendern und Forschern wohlverstanden zu sein und ruhen auf empirischen Erfahrungen die diese Metriken zus tzlich unterst tzen Auch wird versucht klassische Metriken durch Akkumulation in neue Vorschl ge f r den objektorientierten Bereich einzubinden z B McCabes zyklomatische Komplexit t als Gewichtung f r die WMC Metrik Ins
34. BOOL _ export WINAPI mSetValue TValueType vtype double value TUnitType _ export WINAPI mGetUnitType void BOOL _ export WINAPI mlsCalibrated void void _export WINAPI mActivateDrive void void _export WINAPI mSetCorrectionState BOOL onoff LPCSTR _export WINAPI mGetAxisName void LibMain HINSTANCE____ unsigned_short unsigned_short char_ mlGetVersion mlGetInstance mGetScanSize mStartMoveScan int int mGetMoveScan mGetMoveScan mGetMoveScan mGetMoveFinishldx mSavePosition unsigned_int unsigned_int unsigned_long unsign mSavePosition unsigned_int unsigned_int unsigned_long unsign milnitializeMotorsDLL mlSetAxis int mlGetAxis mlGetldByName TAxisType mlParsingAxis char_ mllsAxisValid TAxisType mllsServerOK mlGetAxisNumber mlGetOffset int mlSetAngleDefault mlOptimizingDlg mlGetDistance int double_ amp mlGetValue int TValueType mlMoveToDistance int double misMoveFinish mlSetParametersDlg mlPositionControlDlg mlSaveModuleSettings mlinquireReferencePointDlg int mSetLine int int mSetRelativeZero int double misDistanceRelative misRangeHit mMoveByDistance double mMoveToDistance double misMoveFinish mGetDistance double_ amp mGetDistanceProcess mStopDrive int mGetValue TValueType mSetValue TValueType double mGetUnitType misCalibrated mActivateDrive mSetCorrectionState int mGetAxisName Anhang F Daten der Quelltextanalyse Seite 223
35. F 4 3 Ermittlung MaBkomponente Komplexitat sesenssesesensenseennennensnnnnennenn 234 Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit conoomommommmmo 235 Abbildungsverzeichnis Seite 9 Abbildungsverzeichnis Abbildung 1 Schnittstellenmodell f r die Portabilit t von Software Systemen sssssesssesessesesesee 32 Abbildung 2 Proze modell f r die Portierung nach Mooney nn 33 Abbildung 3 Alternatives Proze modell f r die Portierung Anpassung in Hostumgebung 34 Abbildung 4 Portierungsmodell nach Buschhorn essen 35 Abbildung 5 bersicht zur Historie von Windows 38 Abbildung 6 Systemarchitektur von Windows 3 1 Gnbanced Mode 51 Abbildung 7 Systemarchitektur von Windows Us 52 Abbildung 8 Systemarchitektur Windows NIT 55 Abbildung 9 Adre raum einer Win32 Anwendung und Verwaltung von Speicherseiten 58 Abbildung 10 Adre raum einer Win16 Anwendung und Verwaltung von Speicherseiten 59 Abbildung 11 Win16 Zeigertypen und deren Gr en im Vergleich zu Win32 Zeigern 60 Abbildung 12 Getrennte Adre r ume unter Win32 und Interproze Kommunikation 61 Abbildung 13 Eingabenachrichten unter Win16 und Wm 63 Abbildung 14 Dll Speicherverwaltung unter Win32 uuseeseenseenssenseennennnnnnennnnnnnnnnnenne nennen 67 Abbildung 15 Dll Speicherverwaltung unter Wamle nennen 67 Abb
36. H lfte aller Systemkomponenten ohne Komponentenkopf mit entsprechenden Einzelinformationen sind so wird dem jeweiligen Ma der Bin rwert 1 zugeteilt ansonsten der Wert 0 Das aggregierte Ma f r den Komponentenkopf mit den jeweiligen Gewichtungsfaktoren sieht wie folgt aus 5 KK g KB g MB g AE g IE g 4S wobei gilt g 1 i l Eine Code Inspektion im XCTL System ergab da lediglich der Autorenname und das Erstellungsdatum einer Quelldatei teilweise aufgef hrt waren Alle anderen Teile waren nicht oder nur auszugsweise vorhanden Deshalb folgende Bewertung wiederum mit angenommener Gewichtung da noch keine Portierungserfahrungen vorliegen KK 0 2 0 0 2 0 0 2 1 0 2 0 0 2 0 0 2 Kommentarzeilen Hierbei k nnte man das Verh ltnis von Kommentarzeilen zur Gesamtzeilenzahl des Software Systems zugrunde legen Dadurch w rde aber die Fehlannahme impliziert je mehr Kommentarzeilen ein Software System in seinen Quellen aufweist desto besser Was nat rlich so nicht der Fall sein kann Um das Ma der Kommentarzeilen zu bestimmen wird davon ausgegangen da es sinnvoller ist zu berpr fen ob mindestens die Benutzung von Kontrollstatements ausreichend dokumentiert ist Dabei wird durch eine subjektive Einsch tzung der Einhaltung des Prinzips der Verbalisierung Gedanken und Vorstellungen in Worten ausdr cken und damit ins Bewu tsein bringen Hier die Ideen und Konzepte des Entwicklers Rechnung getragen Das fol
37. IKK Interne Komponentenkomplexit t V K S K Zyklomatische Komplexitat Strukturiertheit Schritte zur Ermittlung des Teilma es Interne Komponentenkomplexit t Ermittlung der Ma komponente Zyklomatische Komplexit t Ermittlung der Ma komponente Strukturiertheit Zusammenfassung zur Ma komponente Interne Komponentenkomplexitat Zyklomatische Komplexit t Schritte zur Ermittlung der Ma komponente Kopplungsmechanismus Ermittlung VWMC McCabe Toolset auswerten Berechnung der zyklomatischen Komplexit t V K Die Diskussion zur Anwendung der zyklomatischen Zahl auf objektorientierte Systeme ergab die Reduzierung auf Methodenebene da nur dort ein Kontrollflu graph im McCabeschen Sinne konstruierbar ist Andere Autoren schlagen vor die zyklomatische Komplexit t auch auf Klassenhierarchien anzuwenden AC Die Verwendung der zyklomatischen Zahl auf Klassen oder Systemniveau ist durch Akkumulation m glich Chidamber et al haben das bei der Vorstellung der WMC Metrik vorgeschlagen wobei dann die Gewichtung der Methodenkomplexit t durch die auf Methodenebene ermittelte zyklomatische Zahl vorgenommen wird Ausgehend von den bisherigen berlegungen soll die zyklomatische Zahl des zu portierenden Software Systems ber die entsprechend gewichtete WMC Metrik in das Portierungsma f r objektorientierte Systeme eingehen Es hatte folgenden Aufbau k V K 3 VWMC i l mit VWMC
38. In diesem Abschnitt sollen die wichtigsten dieser Konzepte kurz vorgestellt werden und es soll gezeigt werden welche M glichkeiten bestehen Windows basierte Software Systeme zu entwickeln 2 2 2 1 Konzepte von Windows Systemen API Application Programming Interface Aus Programmierersicht definiert sich ein Betriebssystem ber dessen Programmierschnittstelle Im Falle von Windows ist dies die Windows API die mittlerweile mehrere tausend Funktionen umfa t und s mtliche bei diesen Aufrufen verwendbaren Strukturen und Datentypen festlegt F r die Oberfl chen ab Windows 95 bzw Windows NT ab Version 3 5 wird diese Programmierschnittstelle zusammenfassend als Win32 API bezeichnet Im Gegensatz dazu werden die 16 Bit Versionen bis Windows 3 1 und Windows f r Workgroups als Win16 API bezeichnet Der Grund f r diese Unterteilung soll hier kurz aufgef hrt werden n heres dazu siehe Abschnitt 2 2 3 Die Versionen Windows 1 0 bis einschlie lich 3 1 mu ten mit dem Adressierungsmodell der Prozessoren 8086 8088 bis 80286 von den nachfolgenden Prozessoren aus Kompatibilit tsgr nden weiterhin unterst tzt auskommen das eine Segmentunterteilung des Speichers in jeweils 64 KB vornimmt Das Modell legt die Registerbreite des Prozessors auf 16 Bit fest d h ein ganzzahliger C Datentyp belegt 16 Bit Adre speicher und setzt seine Speicheradresse aus zwei 16 Bit Komponenten zusammen einem Segment und einem Offset innerhalb dieses Seg
39. Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp 2370 2495 2499 2500 2510 2516 2520 2528 2530 2535 2550 2557 2575 2581 2606 2611 WORD torque BOOL TC_812 SetDynamicGain WORD dygain dygain min dygain WORD 255 dygain max dygain WORD 1 WORD TC_812 GetDynamicGain void BOOL TC_812 SetTorque WORD torque BOOL TC_812 SetTorque WORD torque WORD TC_812 GetTorque void wTorque min torque WORD 127 BOOL TC_812 SetVelocity DWORD velocity DWORD TC_812 GetVelocity void BOOL TC_812 SetAcceleration DWORD acceleration DWORD TC_812 GetAcceleration void BOOL TC_812 SetLimit DWORD limit WORD TC_812 GetStatus void WORD status KOMP TC_812 Anz MAA 20 Motors cpp 2757 Motors cpp 2767 Motors cpp 2768 Motors cpp 2791 Motors cpp 2834 Motors cpp 2770 2785 WORD hostio hostaddr hostio WORD GetPrivateProfilelnt Ident IOAddr 0x200 GetCFile hostaddr WORD GetPrivateProfilelnt Ident GPIBAddr 1 GetCFile TC_812 GetMoment TC_812 SetDynamicGain unsigned_short TC_812 SetDynamicGain unsigned_short TC_812 SetDynamicGain unsigned_short TC_812 GetDynamicGain TC_812 SetTorque unsigned_short TC_812 SetTorque unsigned_short TC_812 GetTorque TC_812 GetTorque TC_812 SetVelocity unsigned_long
40. PGM KOMP Anz PGA KOMP Anz PGA TAm9513a 8 TBraun_Psd 1 TC_812ISA 2 TC_832 o 35 TStoe_Psd 7 Tx 14 PGM Anzahl aller Komponenten mit PG Zugriffen _ 6 0 074 Anzahl der Komponenten E Damit l t sich nun das Gesamtma PG PGM PGM PGM f r das XCTL System zusammensetzen PG PGM PGM PGM 37 PGM 0 074 Aggregation zum Gesamtma Hardware Umgebung Die Teilma e der Hardware Umgebung Maschinenarchitektur und Peripherieger te stimmen in allen drei Positionen berein und k nnen deshalb leicht zusammengef hrt werden Die Aggregation zum Gesamtma erfolgt analog zum Ma Software Umgebung HU PAN y KOMP y VKG 7 mit PAN y MAM PGM Anzahl der potentiellen Anpassungen von Zugriffen auf die Hardware Umgebung KOMP y MAM PGM Namen der Komponenten mit Zugriffen auf die Hardware Umgebung und deren Anzahl VKG y MAM PGM Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten Portabilit tsanalyse am Beispiel des XCTL Systems Seite 152 Dabei ist anzumerken da der Wert von VKG hierbei eine wichtige Rolle spielt Dieser dr ckt aus inwieweit ein Software System portabilit tsf rdernde Prinzipen wie beispielsweise Lokalit t einh lt nach dem die Hardwareabh ngigkeiten in einigen wenigen Komponenten zusammengefa t werden sollten F r das XCTL System ergibt sich bez glich
41. Standardbibliotheken gibt es eine Reihe von Merkmalen die nicht Bestandteil eines Standards sind So ist z B die in vielen standardkonformen Umgebungen vorhandene String Kopierfunktion strdup kein Teil des ANSI C Standards wird aber dennoch f lschlicherweise als Standardfunktion angenommen und routinem ig eingesetzt Somit ist es auch hier aus Portabilit tssicht sehr wichtig sich strikt an die Definition der benutzen Standardbibliothek zu halten und das Software System in einer Vielzahl von Umgebungen zu testen Portabilit t von Software Systemen Seite 46 Wie bereits erl utert gibt es zahlreiche weitere Standards die ebenfalls nicht Teil einer Programmiersprachendefinition sind Dazu z hlen zum Beispiel Betriebssystem und Netzwerkschnittstellen Grafikschnittstellen usw Einige davon wie POSIX sind f r mehr als ein Betriebssystem bestimmt andere hingegen wie die verschiedenen Windows API s f r ein bestimmtes Betriebssystem spezifisch Auch hier sollten m glichst auf breiter Ebene etablierte Standards ausgew hlt und nur bestimmte Hauptkomponenten sowie die am h ufigsten benutzten Teile Verwendung finden Datenaustausch Die einfachste Form des Datenaustausches zwischen beliebigen Rechnersystemen stellen Textdaten dar Diese k nnen durch verschiedene Werkzeuge leicht gelesen und manipuliert werden Beim Austausch von Text kommt es jedoch immer wieder zu bestimmten Verwirrungen So nutzen z B PC Systeme ein
42. Systems Abbildung 1 Schnittstellenmodell fiir die Portabilitat von Software Systemen Das Modell in Abbildung 1 zeigt das Software System und dessen Interaktion mit Systemkomponenten ber deren Schnittstellen In einer weiteren Verfeinerung des Modells wird das Software System in einzelne Systemkomponenten aufgeteilt die entweder mit der Systemumgebung Portabilit t von Software Systemen Seite 33 interagieren oder nicht d h unabh ngig von dieser sind Die Abbildung zeigt beispielsweise die Beziehung der Software Systemkomponente A zur Schnittstelle des Betriebssystems direkte Schnittstelle ausgef llter Pfeil welche wiederum mit dem Speicher der Systemumgebung ber dessen Schnittstellen interagiert indirekte Schnittstellen schraffierter Pfeil Systemkomponente B hat dagegen keine Systemabh ngigkeiten Die Portabilit t eines Software Systems ist somit direkt abh ngig von den benutzten Schnittstellen seiner Komponenten Ein wichtiger Aspekt der bei diesem Modell nicht direkt aufgezeigt wird ist die unterschiedliche Repr sentation solcher Schnittstellen Einige repr sentieren sich auf Quellcodeebene andere wiederum auf Objektcode oder Ausf hrungsebene Maschineninstruktionen Jede Ebenenrepr sentation ist hierbei mit einem spezifischen Verlust an Portabilit t behaftet Aus diesem Grund wird dieses Modell als statisches Schnittstellenmodell bezeichnet Ein von ihm aufgestelltes Proze modell f r die Portierung zeigt Ab
43. WORD bRealLifeTime TBraun_Psd TBraun_Psd BraunPSD cpp 198 echo 15 4 WORD bRealLifeTime TBraun_Psd TBraun_Psd BraunPSD cpp 204 befehl 10 3 WORD nDeathTime TBraun_Psd TBraun_Psd BraunPSD cpp 205 echo 10 4 WORD nDeathTime TBraun_Psd TBraun_Psd BraunPSD cpp218 hReadBuf GlobalAlloc GHND GetBufferSize sizeof DWORD TBraun_Psd TBraun_Psd BraunPSD cpp 294 LPDWORD __IpdwCountBuf TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 295 LPDWORD IpdwReadBuf TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 334 IpdwReadBuf LPDWORD GlobalLock hReadBuf TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 337 Words UINT IpfnGetData WORD TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 348 memcpy LPLONG amp Header LPLONG IpdwReadBuf 16 sizeof long TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 371 pdwCountBuf LPDWORD GlobalLock hCountBuf TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp524 transform IWert 0 WORD uEnergyHigh TBraun_Psd SetEnergyRange unsigned_int unsigned_int BraunPSD cpp 531 transform IWert 0 WORD uEnergyLow TBraun_Psd SetEnergyRange unsigned_int unsigned_int BraunPSD cpp 596 pfnSetPort WORD nBaseAddr zgrbefehl i TBraun_Psd BuildOperation unsigned_char_ unsigned_char_ i BraunPSD cpp 603 EchoRead i 2 IpfnGetPort WORD nBaseAddr 2 TBraun_Psd BuildOperation unsigned_char_ unsigned_char_ i BraunPSD cpp 604 EchoRead i 1 IpfnGet
44. basic operations Creating Visual C projects Create new Visual C Project File New choose win32 Application then choose empty project Name this project XControl it is for the main program Add projects for each dll in the same workspace Projects Add to project New Project choose win32 dll then choose empty project Repeat this step for each dll At any time you can set any one of these projects as an active project by right clicking on its name in the workspace window The active project name is shown in bold letters Define project interdependecies In that way VC knows how to build the whole app Use Project Dependencies XControl depends on motors counters and splib Counters depends on motors and splib Motors depend on splib Splib is not dependent of anything Copy all source files h cpp c rc to the project root directory for the dlls also in the same directory Add these files to corresponding projects for h files this is not neccessary compiler itself will place them under external dependencies group updating project settings Project Settings for splib General tab set Output files to Debug leave intermediate files in separate folder C C tab add to defines Build_Library C C tab make sure there is option MD for release or MDd for debug Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 236 eliminate MT or ML Projec
45. d h ob Portierungserfahrungen vorliegen oder nicht Anzahl BS Aufrufe BSM Anz BSR Anz BSR mit BSR i ter unterschiedlicher BS Aufruf i 1 7 Anzahl BS Aufrufe bei vorhandener Portierungserfahrung BSM KAgs PAgs SAgs BAgs mit KAzs BSR BSR Namen der BS Routinen die nicht angepa t werden k nnen PA Anz BSR BSR Anz BSR BSR Namen und Anzahl der BS Routinen ber die w hrend der Messung keine Information vorliegt SAzs Anz BSR Anz BSR Gesamtzahl der Aufrufe von BS Routinen die anpa bar sind f r die aber keine Aufwandswerte vorliegen Metriken und Portierungsaufwand Seite 111 BA ys 4nz BSR B Anz BSR H Summe der bewerteten BS Routinen f r die ein Aufwand vorliegt B Aufwand f r die Anpassung der i ten BS Routine i 1 r KA Keine Anpassungen PA Potentielle Anpassungen SA Sichere Anpassungen BA Bewertete Anpassungen Einarbeitungsaufwand BSM Komp Anz BSA KOMP Anz BSA mit KOMP i te betroffene Komponente des Programms i 1 n BSA anzupassender Aufruf einer BS Routine Verh ltnis Gesamtkomponenten zur Anzahl anzupassender Komponenten Anzahl aller Komponentenmit BS Anpassungen BSM 7 Anzahl aller Komponenten Bibliotheksroutinen Aufrufe BIB BIBM BIBM BIBM mit BIBM BIBM oder BIBM abh ngig von der gegebenen Situation Anzahl Bibliotheksroutinen Aufrufe bei vorhan
46. en ist das Ma nur als eingeschr nkt n tzlich anzusehen und h chstens f r erste grobe Portabilit tsanalysen brauchbar Diese erlauben jedoch keinesfalls pr zise Aussagen zum zeitlichen Portierungsaufwand eines dementsprechend analysierten Software Systems Zusammenfassend kann gesagt werden da es sich bei dem vorgestellten Ma eher um eine Software Metrik im Sinne der Definition von Balzert siehe Kapitel 3 1 2 handelt als um ein Software Ma Dies wird begr ndet durch die Untersuchung auf einzuhaltende G tekriterien f r Software Ma e wie sie in Balzert Balzert 98 beschrieben werden Hierbei werden keine der geforderten G tekriterien vollst ndig erf llt Es wird jedoch formal definiert wie die Kenngr e Portabilit t eines Software Produkts gemessen werden kann und f llt somit in den Rahmen der Definition einer Software Metrik Die Auswahl der Einflu gr en stellt einen Kompromi zwischen gew nschter Objektivit t und gezwungener Subjektivit t dar und ist nicht als vollst ndig anzusehen zumal die Erfahrungen und Kenntnisse eines Porteurs die den Aufwand einer Portierung ma geblich beeinflussen k nnen nicht oder nur teilweise Dokumentation ber cksichtigt werden F r eine erste und grobe Portabilit tsanalyse stellt dieser Ansatz jedoch ein brauchbares Fundament dar und soll als Basis f r die Untersuchung eines Windows basierten Software Systems dienen Hierbei ist zu ber cksichtigen da das vorgestellt
47. keine Eigenschaften in seine Quellen einzubauen die so ungew hnlich oder unklar sind da man ein Experte auf dem Gebiet von Sprachdefinitionen sein mu um sie zu verstehen Ein Beispiel hierf r ist die uneinheitliche Nutzung von komplizierten Zeiger und Vektorausdr cken in der Programmiersprache C bzw C wie a 1 statt allt falls man auf den Inhalt eines Vektors verweist oder f int vektor 12 statt f int vektor 2 12 vereinbart um klar zu machen da hier ein Vektor an eine Funktion zu bergeben ist wobei der Sprachstandard diese quivalenz wohlwollend duldet Auch sollte man mehrere Compiler ausprobieren und alle Compiler Warnungen aktivieren um so weitere Portabilit tsprobleme zu erkennen die sonst vielleicht im Verborgenen bleiben w rden Standardbibliotheken Neben einer pr zisen Sprachdefinition die nur in relativ wenigen und eindeutig identifizierbaren Punkten implementationsabh ngig ist sind eindeutig definierte Standardbibliotheken die grundlegende Funktionsbereiche abdecken ebenfalls eine wichtige Voraussetzung f r die Portabilit t von Software Systemen Standardbibliotheken werden meist gleichzeitig mit einer Sprache definiert und mit ihr zusammen in der Systemumgebung angeboten sind aber kein Teil der Sprache selbst Bibliotheken arbeiten h ufig eng mit dem zugrunde liegenden Betriebssystem zusammen und k nnen daher trotzdem unportable Teile enthalten Auch bei den Implementierungen verschiedener
48. m glich ist und die Daten zwischen der aufrufenden und der aufgerufenen Systemkomponente ber gemeinsame Datenbereiche shared data area ausgetauscht werden in FORTRAN beispielsweise durch die COMMON Anweisung d h verschiedene Komponenten greifen auf eine gemeinsame Datenstruktur zu Der Nachteil dieser Kopplung besteht darin da die Daten nicht explizit bergeben werden und damit die Schnittstellen nicht eindeutig identifizierbar bzw schwer ersichtlich sind Eine externe Datenverbindung liegt immer dann vor wenn eine Prozedur direkt auf ein Datenelement oder eine Anweisung innerhalb einer anderen Prozedur zugreift Inhaltskopplung z B Verzweigung einer Systemkomponente in eine andere ohne da ein externer Einsprungspunkt definiert ist In PL 1 kann diese Zugriffsart beispielsweise mittels der EXTERNAL Anweisung realisiert werden Der Kopplungsmechanismus der externen Datenverbindung hat den Nachteil da ein Fehler in einer extern gekoppelten Komponente durch eine mit ihr gekoppelten Komponente entstanden sein kann und deshalb in manchen F llen alle extern gekoppelten Komponenten betrachtet werden m ssen Dieser Kopplungsmechanismus ist der komplexeste verwirrendste und fehleranf lligste und sollte daher nach M glichkeit vermieden werden Metriken und Portierungsaufwand Seite 84 Schnittstellenbreite Diese wird bei Stevens durch die Anzahl der einzelnen ausgetauschten Datenelemente und deren Datentyp bes
49. m_layer h c_layer h rc_def h comhead h m_devcom h m_steerg h m_layer h c_layer h m_dlg h rc_def h comhead h rc_def h Motorsteuerung Ablaufsteuerung Topographie Interaktion mit der Software Windows Ressourcen Nicht zugeordnet Detektornutzung Interne Funktionalit t Windows Ressourcen Nicht zugeordnet Detektornutzung Ablaufsteuerung Topographie Diffraktometrie Reflektrometrie Interaktion mit der Software Online Hilfe Diffraktometrie Reflektrometrie Interne Funktionalit t Motorsteuerung Detektornutzung Interaktion mit der Software Windows Ressourcen Nicht zugeordnet Detektornutzung Ablaufsteuerung Motorsteuerung Detektornutzung Interaktion mit der Software Interaktion mit der Software Windows Ressourcen Nicht zugeordnet Windows Ressourcen Windows Ressourcen Tabelle D5 Quellen bersicht des XCTL Systems Anhang E Hardwareausstattung der Arbeitspl tze f r das XCTL System Seite 200 Anhang E Hardwareausstattung der Arbeitspl tze f r das XCTL System PC Nutzer Projekt Prozessor Memory HDisk Controller x ray7 PC RTK7 Mhling i486 DX 33MHz 4MB 152MB SCSI x ray8 PC RTK3 Mini2 1486 DX 33MHz 8MB 203MB AT 2 x ray6 PC RTK4 Frank 1 Pentium 66MHz 32MB 2100MB NOR on Bord EIDE VL Grenoble PC RTK Grenoble 1486 DX2 66MHz 8MB 406MB DC 2000 PromiseTech 1x C832 HRMI 486 DX2 20MB 1000MB Ix C812 1x C832
50. rd to mov dx WORD PTR rd in inline asm code in several places to eliminate error operand size conflict also for mov dx rs mov ax d and mov 1 ax eliminated return _AX because it is Borland specific Visual C does not need return statement to return with result in AX according to MSDN Power2 sample radicon h macro CALLTYPE changed to define CALLTYPE __cdecl Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 238 _Cdecl changed to __cdecl kisll c changed mov dx rd to mov dx WORD PTR rd and similar 1_layer cpp comment out include lt bwcc h gt comment out HANDLE hTheModule line change line BOOL DIlEntryPoint HANDLE hModule DWORD dwFunction LPVOID to BOOL WINAPI D11Main HINSTANCE hModule DWORD dwFunction LPVOID change line hTheModule hModule to hModuleInstance hModule comment out BWCCRegister line add at the end of line with SearchAgain label replace timeGetTimeQ with clock m_data cpp add cast float to MaxInt and MinInt m_devcom h change __rtti keyword to nothing m_layer h add if defined Build_Motors define _MOTORCLASS __declspec d1lexport elif defined Use_Motors define _MOTORCLASS __declspec d1limport else define _MOTORCLASS endif add _MOTORCLASS before the word WINAPI in each declaration remove words WINAPI and CALLBACK from lines beginning with typedef m_layer cpp add _MOTORCLASS in front of WI
51. und die Anzahl der Bedingungen obere Grenze gegeben sind F r die erste Entscheidung ergebe sich dann der Wert 2 2 f r die zweite der Wert 2 3 und f r die dritte 3 3 Eine weitere Schwachstelle besteht in der Tatsache da die Komplexit t der Knoten selbst nicht ber cksichtigt wird So ist jeder Knoten mit Ausnahme der Knoten von Entscheidungen nach McCabe ein sequentielles Code Segment mit jeweils einem Eingangs und einem Ausgangsknoten Das hat zur Folge da keine Unterscheidung zwischen Knoten die eine Anweisung oder eine Folge von Anweisungen enthalten stattfindet Hansen Hansen 78 schl gt vor als weitere Ma zahl die Anzahl der Operatoren mit anzugeben da ein Software System mit mehr Operatoren sowohl gr er als auch komplexer ist Neben diesen exemplarischen Beispielen f r Schwachpunkte der McCabe Metrik existieren eine Reihe weiterer Kritikpunkte So werden nach Balzert 98 unterschiedliche Programmerkmale zu stark vereinfacht und das Quellprogramm wird als zentrales Me objekt zu stark berbetont Au erdem wird nur das Programmger st und nicht die Komplexit t einzelner und verschiedener Anweisungen ber cksichtigt Die aufgef hrten Nachteile haben dazu gef hrt da zahlreiche Weiterentwicklungen der McCabe Metrik stattgefunden haben bzw diese den Ausgangspunkt f r weitere Metrikentwicklungen bildete Roth schl gt zur Berechung der zyklomatischen Komplexit t beispielsweise vor jede Komponente entspr
52. 2 1 3 sodaB m die Anforderungen an ein Ma erf llt Neben einer Vielzahl von Definitionen zum Begriff Metrik wie z B die des IEEE IEEE 93 A metric is synonymous with a software quality metric and defines a software quality metric as a function with input and output Software quality metric have software data as inputs and a single numeric value as output The output is interpreted as the degree to which software processes a given attribute that affect its quality welche Metriken ebenfalls als Funktion mit bestimmten Eingabedaten durch ein Software System und einem entsprechend numerischen Wert als Ausgabe sieht Wobei der Ausgabewert als Grad f r ein bestimmtes Qualit tsmerkmal eines Software Systems angesehen wird Metriken und Portierungsaufwand Seite 81 Die ISO ISO IEC 9126 1991 ISO 91 beschreibt den Begriff der Software Qualtit tsmetriken folgenderma en A software quality metric is a quantitative scale and method that can be used to determine the value a feature takes for a specific product als Definition einer quantitative Skala mit einer entsprechenden Methode den Wert f r das entsprechende Produkt auf dieser zu bestimmen Ein gro er Teil der textuellen Definitionen von Metriken bezieht sich somit auf die Messung bestimmter Qualit tsmerkmale eines Produkts oder Prozesses und deren numerischer Repr sentanz In Balzert 98 wird folgende Beschreibung f r Metriken angegebe
53. 386 486 Pentium Pentium Pro bis hin zum 64 Bit Mikroprozessor P7 Itanium Objektcode der f r einen bestimmten Prozessor X eines IBM PC erzeugt wird l uft ohne weitere Modifikation auch auf einem IBM PC mit Prozessoren der lteren Generationen Ein von der Firma Sun 1987 eingef hrter und von der IEEE Std 1754 weiterentwickelter Architekturstandard ist SPARC Scalable Processor Architecture Catanzaro 91 Dieser war die erste offene RISC Prozessorarchitektur und ist f r den Einsatz in Laptop Desktop High End und Multiprozessorsystemen bestimmt F r alle SPARC Systeme die mit UNIX System V laufen wird Bin rkompatibilit t garantiert Der ABI Standard Application Binary Interface beschreibt das Format und den Inhalt der SPARC ABI Binaries Die SPARC Architektur definiert den Zweck der Integer Floating Point und Coprozessor Register den Prozessorzustand und die Statusregister 69 Basisbefehle und einen 32 Bit breiten virtuellen Adre raum f r User Applikationen Die Systemkomponenten wie z B I O Interface die Cache Memory Architektur oder eine MMU werden nicht definiert Die erste SPARC wurde 1987 von Fujitsu implementiert und hie MB86900 Viele Anstrengungen werden unternommen die Architektur von Rechnersystemen zu vereinheitlichen Eine Vielzahl von Architekturphilosophien und die rasche Entwicklung der Hardwaretechnologie haben aber bisher die Entwicklung eines universellen Standards verhindert Portabilit t vo
54. AS Methoden und Attribut IE beschreibung MB Formal 4 DOK y 8 KK 8 KZ 8 AF g NL wobei gilt Jg 1 i l Komponentenkopf 5 KK g KB g MB g AE g IE g AS wobei gilt Jg 1 i 1 Klassenbeschreibung KB Klassenbeschreibung vorhanden nicht vorhanden Methoden und Attributbeschreibung MB Beschreibung der Klassenkomponenten vorhanden nicht vorhanden Autor Erstellungsdatum Metriken und Portierungsaufwand Seite 131 AE Autor und Erstellungsdatum vorhanden nicht vorhanden Import Export der Methoden IE Auflistung Import Export von Methoden vorhanden nicht vorhanden Aufrufende Aufgerufene Klassenkomponenten AS Auflistung der abh ngigen Methoden vorhanden nicht vorhanden Portabilit tsanalyse am Beispiel des XCTL Systems Seite 133 4 Portabilit tsanalyse am Beispiel des XCTL Systems Auf dem Fundament der theoretischen Ausf hrungen der vorangegangenen Kapitel soll nun die Portabilit tsanalyse f r ein reales Software System durchgef hrt werden Bei dem Fallbeispiel handelt es sich um ein Windows basiertes Software System zur Steuerung einer R ntgen Topographie Kamera Nach kurzer Einf hrung in den Gegenstandsbereich und Vorstellung des Software Systems wird die Portabilit tsanalyse durchgef hrt Hierbei wird das Software System auf der Grundlage des vorgestellten Portabilit tsma es untersucht und es werden Aussagen zur Portabilit t des Systems getroffen Den Abschl
55. Am9513 cpp 430 void TAm9513a WriteData WORD daten Am9513 cpp 446 test BYTE WORD daten gt gt 8 amp 0x00FF Am9513 cpp 461 WORD TAm9513a ReadData void Am9513 cpp 463WORD value Am9513 cpp 468 value WORD inp addr Am9513 cpp 480 value WORD WORD inp addr lt lt 8 Am9513 h 109 int IOCTL TIOCCmd DWORD Am9513 h 113 DWORD GetTicksPerSecond void Am9513 h 121 void WriteData WORD Am9513 h 122WORD ReadData void Am9513 h 123WORD ReadStatus void Am9513 h 134 BOOL SplitNumber DWORD WORD8 WORD8 Am9513 h 136 WORD wLowTicks wHighTicks Am9513 h 137 WORD wLowCounts wHighCounts KOMP TAm9513a Anz MAA 39 M_arscan cpp 384 void TAreaScan rButtonDown LONG IParam M_arscan cpp 2420 DWORD dwReadCnt M_data cpp 440 M_data cpp 902 Screen dy RLdy max WORD O min WORD 700 RLdy KOMP TAreaScan Anz MAA 4 M_arscan cpp266 AppendMenu TheMenu MF_POPUP WORD hMAdd amp Scan M_data cpp 230 DWORD memsize M_data cpp 290 DWORD TBitmapSource GetlmageSize void M_data cpp 292 DWORD nBits M_data cpp 301 nBits DWORD IpBMP InfoHdr gt biHeight M_data cpp 403 nColors short lpBMPInfo gt bmiHeader biClrUsed M_data cpp 758 int nEnlargedLines DWORD nBits M_data cpp 768 DWORD addr 1014DWORD M_data cpp addr MaxAddr GetlmageSize TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513
56. B Dateiverwaltung I O und Basisdienste z B Speicher und Taskverwaltung Schnittstellen zu anderen Subsystemen wie OS 2 oder Posix Console API Textmodus Ausgabe Auch sorgt das Win32 Subsystem daf r da alle Sicherheitsregeln und pr fungen die den Kernel absichern strikt eingehalten werden Funktionen des Win32 Subsystems liegen in zwei Formen vor Portabilit t von Software Systemen Seite 57 entweder sie sind in einer Win32 Subsystem DLL implementiert die in den Adre raum eines Software Systems abgebildet und aufgerufen wird oder sie finden sich auf dem Win32 Subsystem Server Hierbei mu dann das Software System ber den LPC Mechanismus mit dem Server kommunizieren wobei aber auch hier System DIl s mit entsprechenden Schnittstellen Funktionen eigenh ndig die LPC Kommunikation regeln und den Entwickler von der Arbeit mit dem LPC Protokoll entlasten Somit hat sich an der Oberfl che f r den Entwickler obwohl die Implementation im Vergleich zu Windows 3 1 eine v llig andere ist nichts Wesentliches ge ndert Damit sind auch die Unterschiede zu Windows 9x f r den Entwickler nur in seltenen F llen von Bedeutung da die Win32 API eine gemeinsame Programmierschnittstelle f r beide Betriebssysteme definiert und wesentliche Unterschiede nur den internen Aufbau u a den System Kernel der Systeme betreffen 2 2 3 3 Identifikation und Klassifikation Windows spezifischer Portierungsprobleme Die grundlegenden A
57. Distance mGetValue Width mMoveToDistance mGetValue Distance mGetValue Width FORWARD_WM_COMMAND GetHandle cm_ParamSet 0 0 PostMessage MFT MoveToDistance FreeModule hGP IpMList gt MP mid PostMessage Ge BOOL _ export W TMoveToDistance mMoveToDistance BModule gt MoveToAngle distance FrameHandle WM_COMMAND cm_CallExecuteScan 0l NAPI mMoveToDistance double angle IpMList gt MP gt MoveToAngle angle PostMessage Ge PostMessage Ge FreeModule hGP FrameHandle WM_COMMAND cm_MoveScanReady 8 FrameHandle WM_COMMAND cm_MoveScanReady 8 BModule Cmd GET_WM_COMMAND_ID wParam IParam MessageBox GetFocus Trial to stop all drives Message MBINFO switch GET_WM_COMMAND_ID wParam Param MessageBox GetFocus Bibliothek counters dll nicht geladen Fehler PostMessage hwnd WM_COMMAND cm_AngleControl 0 PostMessage hwnd WM_COMMAND cm_CallExecuteMacro 0 SendMessage hChildWnd WM_COMMAND wParam Param nDevice GET_WM_COMMAND_ID wParam lParam DeviceTimerldStart case WM_COMMAND case WM_MENUSELECT vs GET_WM_COMMAND_ID wParam lParam MSGF_DIALOGBOX ostMessage HWND LOWORD IParam WM_COMMAND cm_Index 0 GET_WM_COMMAND_ID wParam lParam MSGF_MENU amp amp Main DrawStatus hWindow ATOM IParam GET_WM_COMMAND_ID wPar 2 lt GetModuleUsage hMDLL OxFFFF WORD GET_WM_COMMAND_HWND wParam lParam MF_POPUP amp UINT GE
58. Dynamische Laufzeitbibliothek zur Ansteuerung und motors dll e Verwaltung der einzelnen Antriebe Dynamische Laufzeitbibliothek zur Ansteuerung der counters dll are unterschiedlichen Detektoren Dynamische Laufzeitbibliothek zum Verwalten von splib dll Intensitats und Diffraktrometriekurven win488 dll 16 Bit Treiber f r 6812 Motorsteuerkarte sphelp hlp Hilfebibliothek 16 Bit Treiber f r die Ansteuerung des BTaunPSD asa dil Detektors Dynamische Laufzeitbibliothek der Borland SEKR Entwicklungsumgebung standard mak Makroscript f r die Steuerung von Basisaufgaben splib dll dig tpl cpp nen f r Dialogobjekte Interaktion mit der Software rc_def h Windows Ressourcen comhead h Nicht zugeordnet _layer cpp Allgemeine Hilfsfunktionen Interne Funktionali t rc_def h Windows Ressourcen comhead h Nicht zugeordnet m_curve cpp Klassen und Instanzen f r die Datenhaltung Repr sentation und D rstellung der Me daten rc_def h Windows Ressourcen comhead h Nicht zugeordnet splib rc Dialogressource f r About Dialog Windows Ressourcen _layer h Interne Funktionalitat motors dll motors cpp Klassen zur Motorenansteuerung Motorsteuerung rc_def h Windows Ressourcen comhead h Nicht zugeordnet m_motcom h Motorsteuerung m_mothw h Motorsteuerung m_layer h Motorsteuerung ieee h Motorsteuerung m_layer cpp C Schnittstelle f r die Motorenansteuerung Motorsteuerung rc_def h Windows Ressourcen comhead h Nicht zugeordnet
59. FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE 60 59 48 5 46 5 23 5 8 5 48 5 44 5 65 5 8 5 13 13 14 14 14 5 25 5 27 8 5 13 5 8 5 8 5 47 5 46 39 7 15 7 5 5 45 0 65 1 65 0 3 1 35 1 65 0 95 0 6 1 65 0 6 0 95 0 95 0 95 0 95 1 65 0 65 0 3 0 6 0 3 0 3 0 65 1 65 0 95 0 95 1 65 1 3 3 4 TPsdParameters 16 3 2 9 1 0 2 17 5 12 5 70 1 0 0 FALSE 14 5 2 35 TPsdRemoteSync 41 3 15 12 1 0 2 18 13 5 3 77 1 0 0 FALSE 11 5 1 65 TRadicon 73 6 08 14 12 0 2 51 13 38 4 69 1 0 100 FALSE 44 5 2 TSaveDataCmd 12 6 7 1 0 2 15 2 13 5 0 1 0 0 FALSE 14 2 35 TScan 104 4 51 22 22 0 3 69 27 42 11 96 2 0 0 FALSE 55 5 4 75 TScanCmd 25 5 9 4 0 2 15 5 10 4 73 1 0 0 FALSE 12 5 2 TScanParameters 6 6 6 3 1 1 1 1 0 1 0 0 0 100 FALSE 0 5 0 65 TScsParameters 14 2 8 6 3 0 2 11 5 6 2 40 1 0 0 FALSE 8 5 1 3 TSetAdjustmentParam 8 1 13 2 1 0 2 13 7 6 0 100 1 0 100 FALSE 9 5 0 6 TSetFileNameCmd 8 4 5 1 0 2 15 2 13 2 50 1 0 0 FALSE 14 1 3 TSetupAreaScan 39 7 8 23 5 0 2 11 5 6 5 50 1 0 0 FALSE 8 5 2 35 TSetupContinuousScan 22 4 4 13 1 0 2 11 5 6 2 67 1 0 0 FALSE 8 5 1 3 TSetupScanCmd 7 3 5 4 1 0 2 15 2 13 3 50 1 0 0 FALSE 14 1 65 TSetupStepScan 45 9 25 6 0 2 11 5 6 2 68 1 0 0 FALSE 8 5 TSetWidthCmd 3 1 5 2 1 0 2 15 2 13 1 0 1 0 0 FALSE 14 0 95 TShowValueCmd 6 3 4 1 0 2 15 2 13 1 0 1 0 0 FALSE 14
60. GetHandle WM_COMMAND cm_ParamSet 0 M_steerg cpp 1593 FORWARD_WM_COMMAND GetHandle cm_ParamSet 0 0 PostMessage M_steerg cpp 2014 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage M_steerg cpp 3489 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 PostMessage M_topo cpp 1106 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_topo cpp 1119 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_topo cpp 2055 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_topo cpp 2076 FORWARD_WM_COMMAND GetHandle cm_ActivateChanges 0 0 PostMessage M_topo cpp 2092 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_topo cpp 2102 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_topo cpp 2639 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage M_topo cpp 3538 FORWARD_WM_COMMAND GetHandle cm_SetupParameters 0 0 SendMessage Motors cpp 2667 MessageBox GetFocus msg TimeOut MS MBFAILURE Motors cpp 2672 MessageBox GetFocus msg Fehler MBFAILURE Motors cpp 2708 MessageBox GetFocus msg TimeOut MS MBFAILURE Motors cpp 2713 MessageBox GetFocus msg Fehler MBFAILURE Motors cpp 2974 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage Motors cpp 3217 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage Motors cpp 3244 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage Motors cpp 3336 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage Motors cpp 3414 FORWARD_WM_COMMAND hwnd cm_ParamSet
61. HRM2 f 486 DX 8MB 200 MB 1x C812 1x C832 ESRF 486 DX 8MB 27 1x C812 Me platz AFM Atomkraftmikroskop Pentium 100 kein MMX 32 MB RAM 1000 MB IDE HD S3 Grafik on Board Motorsteuerungskarte 1x C832 XY Tisch mit Mikedriveantrieben Betriebssystem IBM PCDOS 7 0 Windows 3 11 Offline Me platz Digitalisierung von Bilddaten mit Kugelumlaufspindeln und Antrieb ber Faulhaber DC Motorgetriebekombination Motorsteuerungskarte 1x C832 AMD KS PR100 2GB IDE HD 48MB RAM PCI Framegrabber Matrox Pulsar monochromer Universalframegrabber mit MGA Grafik mit RS422 Digitalinterface Betriebssystem Win NT4 0SP4 notwendig wegen 32 bit Framegrabbersoftware Tabelle E6 Hardwareausstattung der Arbeitspl tze f r das XCTL System Anhang F Daten der Quelltextanalyse Seite 201 Anhang F Daten der Quelltextanalyse F 1 Ma komponente Software Umgebung F 1 1 Ermittlung der Ma komponente Betriebssystem Aufrufe zum Ma BS siehe Kapitel 4 2 1 1 BSR memcpy Anz BSR 1 BSR hmemcpy Anz BSR 2 M_arscan cpp 2500 memcpy HPSTR buf HPSTR daten cnt KOMP TAreaScan Anz BSA 1 M_data cpp 865 hmemcpy HPBYTE amp hpData addr L_PBYTE IpBuf Screen dx M_data cpp 1324 hmemcpy hpNewData szInfo hpData GlobalSize hDIBData KOMP TBitmapSource Anz BSA 2 TAreaScan LoadOldData int TBitmapSource GenerateAngleSpaceBitmap int int int unsigned TBitmapSource
62. HUGE Segment e Offset 2 Byte FLAT 32 Bit Segment Offset 4 Byte 5 HUGE Segmente die einen bis zu 320 KB gro en Bereich adressieren k nnen TEEF Local Descriptor Table LDT Abbildung 11 Win16 Zeigertypen und deren Gr en im Vergleich zu Win32 Zeigern Ein Handle Typ wie z B HWND beschreibt als Parameter in zahlreichen Windows Funktionen die Eigenschaften eines bestimmten Fensters F r das Betriebssystem ist dieser Handle ein NEAR Zeiger auf eine interne Datenstruktur und folglich in 32 Bit Systemen ebenfalls verbreitert Da ein NEAR Zeiger in 16 Bit Systemen immer aus einem Segment und einem Offset besteht zeigt dieser in einem solchen Fall in die Datensegmente der jeweilig beteiligten Systemkomponenten User exe GDl exe oder Kernelx86 exe und ist z B bei HWND ein NEAR Zeiger in ein User Datensegment Da diese Systemkomponenten in einem 32 Bit System nun in einem eigenen virtuellen Speicherbereich von insgesamt 4 GB laufen ist es notwendig die Handle Typen dementsprechend zu verbreitern Die Verbreiterung der Datentypen hat insbesondere Konsequenzen im Bereich der sogenannten Callback Prozeduren z B WNDPROC DLGPROC Dies sind Routinen die nicht von anderen Stellen des Programms sondern von Windows aus aufgerufen werden und sich au erhalb des programmeigenen Adre raums befinden Hierbei ist insbesondere der dritte Parameter entscheidend Portabilit t von Software Systeme
63. M die Komplexit t bzw Gewichtungsfaktoren der Methode M darstellt WMC steht aus diesem Grund f r eine Familie von Ma en Die Ma e dieser Familie ergeben sich aus dem gew hlten Gewichtungsma F r die Gewichte existieren verschiedene Vorschl ge Chidamber et al schlagen f r die Methodenkomplexit t g M 1 vor womit WMC gleich der Anzahl der Methoden einer Klasse wird Dieses Ma wird dann allgemein als NOM Number of Methods bezeichnet und ist unabh ngig von der Implementierung bzw kann bereits in den Phasen der objektorientierten Analyse und dem objektorientierten Design angewendet werden Gez hlt werden nur die Methoden die lokal in der Klasse C definiert werden Solche Methoden die von Oberklassen geerbt werden werden nicht ber cksichtigt Auch bei dieser Metrik gilt je gr er der Wert von WMC desto gr er ist die Fehlerwahrscheinlichkeit Metriken und Portierungsaufwand Seite 101 Legt man f r die Methodenkomplexitat bzw die Gewichtungsfaktoren g M 1 zugrunde l t sich die Anwendung von WMC beispielsweise so verdeutlichen Abbildung 22 Beispiel f r das Ma WMC Eine Klasse A hat drei Methoden M1 M2 und M3 Allgemein gilt dann f r die Berechnung WMC A g M g M g M bzw f r die Annahme g M 1 d h die einfache Form von WMC WMC 1 4 3 Die Autoren schlagen dar ber hinaus als Gewichte die zyklomatische Komplexit t nach McCabe vor Andere Autoren erscheint dies logisch denn
64. M_main cpp 910 M_main cpp 916 M_main cpp 918 M_main cpp 934 M_main cpp 167 M_main cpp 169 M_main cpp 199 FORWARI FORWARI FORWARI FORWARI FORWARI FORWARI FORWARI FORWARI FORWARI R FORWA FORWARI D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND D_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage hwnd cm_ParamSet hwndCtl 0 SendMessage hwnd cm_ParamSet hwndCtl 0 SendMessage hwnd cm_MoveButton hwndCtl 0 SendMessage hwnd cm_MoveButton hwndCtl 0 SendMessage hwnd cm_MoveButton hwndCtl 0 SendMessage hwnd cm_ParamSet hwndCtl 0 PostMessage hwnd cm_SetupParameters hwndCtl 0 SendMessage hwnd cm_InquireRelevantData hwndCtl 0 SendMessage GetHandle cm_SetupParameters 0 0 SendMessage GetHandle cm_SetupParameters 0 0 PostMessage 1056 1084 i if ISize gt GlobalCompact ISize MessageBox GetFocus Msg Message MBINFO MessageBox GetFocus Msg Message MBINFO MessageBox GetFocus Msg Message MBINFO MessageBox GetFocus Msg Message MBINFO MessageBox GetFocus Msg Message MBINFO MessageBox GetFocus Msg Message MBINFO SetFocus GetDigltem hwnd IDOK FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit hwndCtl 0 SendMessage mMoveToDistance mGetValue
65. MakeProcinstance FARPROC ModelessProc GetMainInstance TModelessDig TModelessDig char_ TMotor GetLimit TMotor SetLimit unsigned_long TMotor GetStatus TMotor TMotor TMotor Initialize TMotor Initialize TMotor Initialize TMotor Initialize TMotor Initialize TMotorParam CanClose TMotorParam CanClose TMotorParam CanClose TMotorParam CanClose Dlg_ OnCommand HWND___ int HWND___ unsigne Dlg_OnCommand HWND___ int HWND___ unsigne Dlg_OnCommand HWND___ int HWND___ unsigne Dlg_OnCommand HWND___ int HWND___ unsigne CanClose CanClose CanClose Dig_OnCommand HWND___ int HWND___ unsigne Dig_OnCommand HWND___ int HWND___ unsigne Dlg_OnCommand HWND___ int HWND___ unsigne DIg_OnCommand HWND___ int HWND___ unsigne Dlg_OnCommand HWND___ int HWND___ unsigne TPlotData IButtonDown unsigned_int long TPlotData IButtonDown unsigned_int long TPlotData IButtonDown unsigned_int long TPlotData IButtonDown unsigned_int long TPlotData MouseMove unsigned_int long TPlotData MouseMove unsigned_int long Anhang F Daten der Quelltextanalyse Seite 219 Counters cpp 806 hCountBuf GlobalAlloc GHND GetBufferSize sizeof DWORD Counters cpp 858 LPDWORD IpdwData Counters cpp 869 IpdwData LPDWORD GlobalLock hCountBuf Counters cpp 1097LPDWORD IpdwCountBuf Counters cpp 1098DWORD counts Counters cpp 1103 IpdwCountBu
66. Metriken und Portierungsaufwand Seite 114 wee MAM Anzahl aller Komponenten mit MA ugriffen Anzahl der Komponenten Peripherieger te PG PGM PGM PGM Anzahl Peripherie Aufrufe PGM Anz PG Anz PG mit PG i ter unterschiedlicher PG Zugriff i 1 n Einarbeitungsaufwand PGM KOMP Anz PGA KOMP Anz PGA mit KOMP i te betroffene Komponente des Programms i 1 n PGA anzupassender PG Zugriff Verh ltnis Gesamtkomponenten zur Anzahl anzupassender Komponenten Anzahl aller Komponenten mit PG Zugriffen PGM 3 Anzahl der Komponenten Aufbau Teilma Programmiersprachen PS Programmiersprachen Eine Programmiersprache benutzt Mehrere Programmiersprachen benutzt PS Dialektspezifische Aufrufe mit vorhandenen Portierungserfahrungen Dialektspezifische Aufrufe 1 mit vorhandenen Portierungserfahrungen f r jede verwendete Programmiersprache Verh ltnis Gesamtzahl an Statements Verh ltnis Gesamtzahl an Statements Der zur Anzahl anzupassender Statements ees 2 zur Anzahl anzupassender Statements fiir jede verwendete Programmiersprache Formal PS PS PS mit PS PS oder PS i 1 2 abh ngig von der gegebenen Situation d h je nach Anzahl verwendeter Programmiersprachen Verwendung einer Programmiersprache und Messung dialektspezifischer Aufrufe mit vorhandenen Portierungserfahrungen Metriken und Portierungsaufwand Seite 115
67. Portabilit tsanalyse am Beispiel des XCTL Systems Seite 153 kann Aus diesem Grunde existiert kein Ma f r die Anzahl potentieller nderungskandidaten Nach erfolgter Portierung k nnen wiederum genauere Informationen in das Ma einflie en und dar ber informieren ob bestimmte programmiersprachliche Konstrukte anpa bar sind und welche ermittelten Aufw nde vorliegen vergleiche Kapitel 3 2 3 4 PS KAps PAps SAps BAps mit KA ps SK SK Konstrukte die nicht angepa t werden k nnen PA Anz SK SK Anz SK SK Anzahl und Namen der Konstrukte ber die w hrend der Messung keine Informationen vorliegen SAps Anz SK Anz SK Anzahl der Konstrukte die anpa bar sind f r die aber keine Aufwandswerte vorliegen BA Anz SK B Anz SK B Bewertung der Sprachkonstrukte f r die ein Aufwand vorliegt B Aufwand f r die Anpassung des i ten Konstruktes i 1 r berwiegt der Teil von zu ndernden Codekonstrukten so spricht dies eventuell f r eine Neuimplementation Um diesen Sachverhalt geeignet auszudr cken existiert bei den Programmiersprachen ein zweites Ma in welchem die Anzahl der zu ndernden Konstrukte in Beziehung zur Gesamtzahl aller Ausdr cke gesetzt wird und sich wie folgt ausdr ckt _ Anzahl aller zu ndernden Statements PS Gesamtzahl aller Statements Bei der Analyse des XCTL Systems spielt das Programmiersprachenma u U dann eine Rolle wen
68. Process Proceedings of the 4th Int Conf on Software Quality McLean VA USA 1994 Adamov R Structural Metric Proposal for Complex Software Dortmund Universit t Dissertation 1985 Balzert H Lehrbuch der Software Technik Software Entwicklung Heidelberg Berlin Oxford Spektrum Akad Verl 1996 Balzert H Lehrbuch der Software Technik Software Managment Software Qualit tssicherung Unternehmensmodellierung Heidelberg Berlin Spektrum Akad Verl 1998 Basili V R Product Metrics In Tutorial on Models and Metrics for Software Managment and Engineering COMPSAC80 Computer Society Press 1980 Bojic D Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit URL https www informatik hu berlin de swt lehre PROJEKT98 produktdoku porting_vc txt Aktualisierungsdatum 01 03 2002 Humboldt Universit t zu Berlin Borland Inc Borland C 5 02 Programmierhandbuch Borland International Inc 1996 Bothe K Reverse Engineering the Challenge of Large Scale Real World Educational Projects 14th Conference on Software Engineering Education and Training Charlotte USA 2001 Bothe K Sacklowski U Praxisn he durch Reverse Engineering Projekte Erfahrungen und Verallgemeinerungen 7 Workshop SEUH Z rich Schweiz 2001 Boyle J M Programm Adaption and Programm Transformation In Ebert R L gger J G cke L Practice in Software Adaption and Maintenance Proceedings of the SAM Workshop Berli
69. SU Routinen und PS Konstrukten die anpa bar sind f r die aber keine Aufwandswerte vorliegen BA sys Bian BAps Ges Summe aus bewerteten SU Routinen und PS Konstrukten fiir die ein Aufwand vorliegt Metriken und Portierungsaufwand Seite 109 PAN ys PAN y PAN pu Summer der potentiellen Anpassungen aus Software und Hardware Umgebung KOMP ys KOMP KOMP y Namen der Komponenten mit Anpassungen an die Software und Hardware Umgebung und deren Anzahl VKG ys VKG VKG y Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten VSG ys PS Verh ltnis aus der Anzahl der zu ndernden Statements zur Gesamtzahl der Statements Aufbau Teilma Software Umgebung SU SU Sofware Umgebung BS BIB UT Betriebssystem Auftufe Bibliotheksroutinen Aufu Utility Aufu UTM Anzahl Util Aufu Anzahl Util Aufrufe U 1 M bei vorhandener Portierungserfahrung UTM Einarbeitungsaufwand 2 Verh ltnis Gesamtkomponenten zu Anzahlanzupassender Komponenten Anzahl Bib R Aufrufe Anzahl Bib R Aufrufe BIBM 1 bei vorhandener Portierungserfahrung BIBM Einarbeitungsaufwand BSM 2 Einarbeitungsaufvand Verh ltnis Gesamtkomponenten zu Verh ltnis Gesamtkomponenten zu B T B MM 3 Anzahlanzupassender Komponenten l J AM 3 B Ss A 3 Anzahlanzupassender Komponenten BSM Anzahl BS Aufu Anzahl BS Aufru BSM bei vorhandener Portierungserf hrung
70. Systeme aus einer 16 Bit Windows Umgebung Win16 heraus in eine 32 Bit Windows Umgebung Win32 portiert werden sollen Der Ausgangspunkt f r die in diesem Kapitel angesprochenen Probleme sind 16 Bit Software Systeme die in C oder C geschrieben sind und direkt auf der Win16 API aufsetzen Der Vorteil von C bzw C zu anderen Programmiersprachen wie z B Java die von einer Standardisierung noch weit entfernt ist oder Pascal es existiert zwar ein ISO Standard f r Pascal dieser ist aber nicht m chtig genug soda ihn jeder Hersteller mit zahlreichen Erweiterungen versieht liegt zum einen darin da diese durch anerkannte und pr zise Sprachstandards sowie standardisierte Laufzeitbibliotheken definiert werden zum anderen aber hohe Optimierungsf higkeiten und Verf gbarkeit f r Windows Systeme aufweisen Unter Benutzung der Standardbibliotheken und des ANSI Sprachstandards sowie konsequenter Beachtung bestimmter Portabilit tsrichtlinien geschriebene Software Systeme unter Windows sind mit vergleichsweise geringem Aufwand auf andere Plattformen zu portieren sofern dort ein entsprechendes ANSI C bzw ANSI C Entwicklungssystem zur Verf gung steht So werden zun chst grundlegende Richtlinien f r portable C bzw C Programme vorgestellt Anschlie end werden die Architekturunterschiede der zu betrachtenden Host Win16 und Zielumgebungen Win32 behandelt um anschlie end auf die Portierungsprobleme in diesem Portierungsfel
71. Systeme bereitgestellt Die von der Windows API abstrahierende Programmierbibliothek ist hierbei die Objekt Windows Library OWL bzw bei C Builder die Visual Component Library VCL Legt man eine andere Programmiersprache zugrunde so bieten sich weitere L sungen Die gleichfalls von der Firma Borland angebotene Delphi Entwicklungsumgebung eine objektorientierte Pascal Variante erm glicht es ebenfalls Oberfl chen Design mit Codeerstellung effizient zu verbinden Sie bietet gleichfalls eine umfangreiche Klassenbibliothek und die M glichkeit diese mit direkten Aufrufen der Windows API zu kombinieren Der Einsatz von Entwicklungsumgebungen ist wie bereits kurz angesprochen mit Vor und Nachteilen verbunden So ndert eine zus tzliche Schicht oberhalb der Windows API nichts an der Komplexit t des Systems sondern versteckt sie lediglich und ist zwangsl ufig mit Einschr nkungen verbunden wenn sie nicht den gleichen Komplexit tsgrad erreicht wie die Windows API selbst So setzen zus tzlich gew nschte Mechanismen die die eingesetzte Bibliothek berfordern eine solide Kenntnis der zugrunde liegenden Programmierschnittstelle voraus und verlangen einen direkten Gebrauch der Windows API Demgegen ber stehen alle Vorteile der objektorientierten Programmierung beim Einsatz von objektorientierten Programmierbibliotheken wie beispielsweise der MFC Software Systeme k nnen in k rzerer Zeit entwickelt werden als dies mit der rein
72. Systemkomponenten Hierbei wurden die meisten der traditionellen Metriken in unver nderter oder modifizierter Form aus der Vermessung von prozeduralen Systemkomponenten bernommen Auch findet man hier wie bei den Metriken zur Vermessung der strukturellen Komplexit t von Systemkomponenten die bereits aufgef hrte Klasseneinteilung Jedoch erweitert um zentrale objektorientierte Konzepte wie Klasse und Vererbung Die Bindung wird hinsichtlich abstrakter Datenstrukturen Klassen Vererbungsstrukturen und Objekten untersucht Vorschl ge zur Festlegung von entsprechenden Bindungsarten f r die semantische Bindung befinden sich noch im Forschungsstadium und sind noch nicht einheitlich definiert Balzert 98 Kopplungsmetriken und Analyse der Kopplungsart in objektorientierten Software Systemen Auf intermodularer Ebene m ssen Besonderheiten des objektorientierten Paradigmas wie Kopplung von Klassen durch Vererbungsgraphen oder Kopplung von Operationen durch Assoziationen und Aggregationen sowie tempor rer Botschaftswege ber cksichtigt werden Auch mu hierbei die Vererbung unter der Sichtweise Vererbung als Kopplung und Vererbung als Bindung unterschieden werden Wobei die zweite Alternative dann einer externen Bindungsmetrik intramodulare Ebene entspricht und der erste Fall im Bereich der Kopplungsmetriken und somit auf intermodularer Ebene anzusiedeln ist Auch die Klassifizierung von Kopplungsarten zwischen Datenabstraktionen Klass
73. Systems Seite 145 TScsParameters TSetAdjustmentParam TSetupAreaScan R TSetupContinuousScan TSetupScanCmd TSetupStepScan i TShowValueCmd 5 TSteering TStoe_Psd TTopographyExecute xw e y O O O O O O e e OO OO MOO Go OO ANW gt cS Tx N Auch im dritten Schritt stimmt der Ma aufbau mit dem der Betriebssystem Aufrufe berein und definiert sich wie folgt BIBM Anzahl aller Komponentenmit BIB Anpassungen Anzahl aller Komponenten Das Verh ltnisma berechnet sich f r das XCTL System mit Anzahl aller Komponenten mit BIB Anpassungen _ BIBM 0 667 Anzahl aller Komponenten 1 Im vierten Schritt erfolgt wieder die Aggregation des Ma es f r die Bibliotheksroutinen Dabei wird analog dem Ma f r die Betriebssystem Aufrufe zusammengefa t weil auch hier die Ma e hnlich 1 Ma oder sogar gleich 2 und 3 Ma sind BIB BIBM BIBM BIBM mit BIBM BIBM oder BIBM abh ngig von der gegebenen Situation Damit ergibt sich f r das Teilma der Bibliotheksroutinen im XCTL Systems folgendes Ergebnis BIB BIBM BIBM BIBM 353 BIBM 0 667 Utility Aufrufe F r das XCTL System wurden keine Utility Aufrufe identifiziert die im Sinne des Zielsystems anzupassen w ren Die Probleme bei Utility Aufrufen sind prinzipiell die gleichen wie bei den Bibliotheksroutinen deshalb k nnen die Ausf hrungen der zuvor vorgestellten Ma e
74. TAreaScan rButtonDown long TAreaScan LoadOldData int nColors min WORD IpBMPInfo gt bmiHeader biClrUsed WORD pPal gt palNumEntries TAreaScan TAreaScan TAreaScan TAreaScan TBitmapSource FormatDBaseToBitmapSource TBitmapSource ProcessBitmapFile int TBitmapSource ProcessBitmapFile int TBitmapSource GetlmageSize TBitmapSource GetlmageSize TBitmapSource CreatePaletteFromDIB void TBitmapSource GenerateAngleSpaceBitmap BOOL bStretch int nAddedPoints TBitmapSource GenerateAngleSpaceBitmap int int int unsigned TBitmapSource GenerateAngleSpaceBitmap int int int unsigned TBitmapSource GenerateRLBitmap Anhang F Daten der Quelltextanalyse Seite 215 M_data cpp 1132nColor short GetColor fIntens TBitmapSource GenerateRLBitmap M_data cpp 1142addr rlx DWORD rly Screen dx TBitmapSource GenerateRLBitmap M_data cpp 1191 DWORD nBits dwSize TBitmapSource FormatDBaseToBitmapSource M_data cpp 1261 Screen dy RLdy max WORD 0 min WORD 700 RLdy TBitmapSource FillBMInfoFromPalette tag_LOGPALETTE_ M_data cpp 1274nEnlargedLines min WORD 6 max WORD 1 WORD 440 nScanNumber TBitmapSource DrawMeasurementArea HDC___ M_data h 81 DWORD GetlmageSize void TBitmapSource GetlmageSize M_data h 146 void GenerateAngleSpaceBitmap BOOL int int DWORD TBitmapSource GenerateAngleSpaceBitmap int int int unsigned M
75. TC_812 GetVelocity TC_812 SetAcceleration unsigned_long TC_812 GetAcceleration TC_812 SetLimit unsigned_long TC_812 GetStatus TC_812 GetStatus wGPIBAddr WORD GetPrivateProfilelnt Ident GPIBAddr 15 GetCFile WORD length KOMP TC_812GPIB Anz MAA 6 m_mothw h 156 m_mothw h 161 m_mothw h 194 m_mothw h 105 115 m_mothw h 175 188 m_mothw h 31 47 Motors cpp 3415 Motors cpp 3450 Motors cpp 3607 Motors cpp 3616 Motors cpp 3623 Motors cpp 3632 Motors cpp 3638 Motors cpp 3645 Motors cpp 3647 Motors cpp 3723 Motors cpp 3817 Motors cpp 3308 3311 wkl WORD GetPrivateProfilelnt Ident IntegralGain 10 GetCFile friend long Drive628c BYTE WORD long WORD WORD void CALLBACK IpfnLimitWatch static void CALLBACK LimitWatch BOOL SetLimit DWORD BOOL SetLimit DWORD virtual BOOL SetVelocity DWORD return TRUE WORD ctr 0x0400 Stop smoothly gt programming manual page 29 void CALLBACK TC_832 LimitWatch UINT IDEvent UINT DWORD dwUse TC_832 BOOL TC_832 SetVelocity DWORD velocity DWORD TC_832 GetVelocity void BOOL TC_832 SetAcceleration DWORD acceleration DWORD TC_832 GetAcceleration void BOOL TC_832 SetLimit DWORD limit WORD TC_832 GetStatus void return WORD Drive628 RDSTAT 0 0 long TC_832 Drive628 BYTE cmd WORD ctrl_word long param int GetWord WORD base WORD regaddr KOMP TC _ 832 Anz MAA 18 M_steerg cpp 43 st
76. TheDialog gt Dlg_OnVScrollBar DialogProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 61 dialogFunc MakeProcInstance FARPROC DialogProc hinstance DialogProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 115 HANDLE_MSG hDlg WM_COMMAND TheModeless gt Dlg_OnComma ModelessProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 116 HANDLE_MSG hDlg WM_HSCROLL TheModeless gt Dig_OnHScrollB ModelessProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 117 HANDLE_MSG hDlg WM_VSCROLL TheModeless gt Dig_OnVScrollB ModelessProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 120 HANDLE_MSG hDlg WM_SETFOCUS TheModeless gt Dig_OnSetF ModelessProc HWND___ unsigned_int unsigned_int long Dig_tpl cpp 409 GlobalCompact MaxMemldx 3 sizeof float sizeof BOOL Dig_tpl h F BOOL CALLBACK _export DialogProc HWND UINT WPARAM LPARAM DialogProc HWND___ unsigned_int unsigned_int long Dig_tpl h 16 friend BOOL CALLBACK DialogProc HWND UINT WPARAM LPARAM DialogProc HWND___ unsigned_int unsigned_int long L_layer cpp 45 UnlockData 0 LibMain HINSTANCE___ unsigned_short unsigned_short char_ M_arscan cpp 151 FORWARD_WM_COMMAND GetHandle cm_SetPositionRange 0 0 SendMessage M_arscan cpp 237 SetFocus GetDlgltem hwnd IDOK M_arscan cpp 336 M_arscan cpp 433 FORWA PostMes RD_WM_COMMAND sage hWndChild WM _ hwnd cm_Motorlnit COMMAND cm_DataAquisi hwndCtl 0 SendMessage ion Ol M_arscan
77. Verwendung einer Systemkomponente in verschiedenen Software Systemen welche auf Common Bereiche zugreift da hier meist keine quivalente Umgebung vorhanden ist Generell sollten keine gemeinsam benutzten Datenbereiche und keine globalen Variablen verwendet werden Betrachtet man die Parameter einer Schnittstelle so k nnte man versuchen durch Zusammenfassen von Datentypen in Datenstrukturen eine Minimierung der Schnittstellenbreite und damit der Kopplung zu erreichen Deshalb spielt der Datentyp der einzelnen Datenelemente einer Schnittstelle eine wesentliche Rolle So sind z B zusammengesetzte Datentypen wie Arrays oder Records auf dessen Elemente einzeln zugegriffen werden kann nur in homogenen Datenreihungen jedes Element tr gt die gleiche Art von Information bzw zusammengeh rigen Datenreihungen sinnvoll Durch die B ndelung von Parametern Datenstrukturkopplung sinkt zwar die Anzahl der Parameter die Kopplungsst rke wird aber erh ht da die Verst ndlichkeit der Schnittstelle beeintr chtigt wird falls man mehrere nicht zusammengeh rige Daten zuf llig b ndelt Deshalb ist Stevens der Ansicht da die Anzahl der Datenelemente an der Schnittstelle in dem Sinne maximiert werden sollte da jedes ben tigte Datenelement das eine logische Einheit darstellt auch explizit aufgef hrt sein sollte Je mehr Daten zu einer Struktur k nstlich zusammengefa t und bergeben werden um so unverst ndlicher und schlechter wartbar
78. _ export RecallSteering UINT UINT DWORD DWORD DWORD RecallSteering unsigned_int unsigned_int unsigned_long unsig DWORD CurrentTime StartTime WORD nNumberCycle Anzahl der Me Zyklen DWORD dwMaxCounts II Maximale Anzahl Impulse WORD nNumberCycle Anzahl der Me Zyklen DWORD dwMaxCounts JI Maximale Anzahl Impulse DWORD dwMaxCounts II Maximale Anzahl Impulse DWORD dwMaxCounts DWORD dwMaxCounts DWORD dwExposureCounts static long Drive628c BYTE WORD long WORD WORD static WORD drive static WORD badar static int GetWord WORD WORD static long GetDWord WORD WORD static void PutWord int WORD WORD static void PutDWord long WORD WORD static BOOL LM628Ready WORD void _export WINAPI msSetSimulationType TSimulationType t void _export WINAPI msRegister_C812ISA_Get T812ISA_GET_CALLBACK cb void _export WINAPI msRegister_C812ISA_Put T812ISA_PUT_CALLBACK cb void _export WINAPI msRegister_C832_Get T832_GET_CALLBACK cb void _export WINAPI msRegister_C832_Put T832_PUT_CALLBACK cb long Drive628c BYTE cmd WORD ctrl_word long param WORD base long GetDWord WORD base WORD regaddr void PutWord int data WORD base WORD regaddr void PutDWord long data WORD base WORD regaddr BOOL LM628Ready WORD base const WORD CB_UP 3 aufw rts z hlen define BiosDataSeg WORD __0040h define CALLTYPE _far _Cdecl _export define CALLTYPE _far _Cdecl _export int CALLTYPE setprm int int WORD WORD int double
79. anf lliger gegen Tippfehler und Verwechslungen Zu lange Bezeichner haben den Nachteil da sie schwer zu merken sind Eine Untersuchung ergab eine optimale Bezeichnerl nge zwischen 5 und 9 Zeichen Dieses Kriterium wird dem Ma f r die Bezeichnerl nge zugrunde gelegt wobei die durchschnittliche Bezeichnerl nge automatisch ermittelt werden kann BL durchschnittliche Bezeichnerl nge 5 9 Zeichen nicht 5 9 Zeichen Eine manuelle berpr fung des XCTL Systems ergab da die durchschnittliche Bezeichnerl nge den Grenzwert f r das Optimum bersteigt und somit folgenderma en bewertet wird BL 0 Aggregation zum Gesamtma Programminterne Dokumentation Die vier Ma e f r die programminterne Dokumentation sind unabh ngig voneinander und werden deshalb zu einem Gesamtma gewichtet und normiert aufsummiert 4 DOK 81 KK g KS g AF g BL wobei gilt g 1 i l F r das XCTL System ergibt sich mit hypothetischen Annahmen zur Gewichtung der einzelnen Teilma e folgendes Gesamtma f r die programminterne Dokumentation DOK 0 3 0 2 0 3 0 0 3 1 0 1 0 0 36 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 172 4 2 3 4 Aggregation zum Gesamtma Dokumentation Die Teilma e werden zu einem Gesamtma zusammengesetzt in dem man auch hier wieder eine Gewichtung vornimmt Das macht Sinn da man annehmen kann da die Portierungsdokumentation den Aufwand am st rksten beeinflu t w hrend
80. aus der Tatsache da das XCTL System nicht durchg ngig objektorientiert implementiert wurde Die Teile des Software Systems die keiner Klasse au er Tx zugeordnet werden konnten werden deshalb zun chst nicht ber cksichtigt Da das XCTL System innerhalb eines Reengineering Projekts bearbeitet wird ist es jedoch sehr wahrscheinlich da in einer weiteren Version der Portabilit tsanalyse in diesem Teil genauere Me daten zur Verf gung stehen Diese Aussage gilt f r den gesamten Teilbereich der Komplexit tsanalyse Kommunikationsart Datenkopplung Schritte zur Ermittlung der Ma komponente Kopplungsmechanismus Ermittlung CBO Ermittlung PA Ermittlung DIT McCabe Toolset auswerten Berechnung der Ma komponente Kommunikationsart DK Bei der Datenkopplung f r objektorientierte Systeme wird die CBO Metrik zugrunde gelegt und f r das XCTL System bestimmt Die CBO Metrik mi t die Anzahl der Klassen mit denen eine Klasse gekoppelt ist wenn Methoden der einen Klasse Methoden oder Instanzvariablen einer anderen Klasse aufrufen bzw verwenden Das Ma ber cksichtigt keine Vererbungshierarchie deshalb soll zus tzlich die DIT Metrik in das Ma mit einflie en Sie gibt Aufschlu dar ber wie tief die Vererbungshierarchie der Klassen geht und z hlt konkret die Anzahl der Vorfahren einer Klasse im Vererbungsbaum Der Datenaustausch zwischen den Komponenten ber globale Daten wird durch das Ma PA ausg
81. bei gleichbleibender Umgebung und nicht wie in ihrer Definition des Portabilit tsbegriffs auf einen Umgebungswechsel In vorangegangenen Definitionen wird eine Portierung von einer Umgebung in eine andere vorgenommen Auch wird immer von der Software Eigenschaft Portabilit t gesprochen Eine Definition von Kaindl definiert daher den Begriff der Portierung eines Programms und pr zisiert dazu den Umgebungsbegriff n her Kaindl 88 An environment E is a triple l l 0 m where J J ieN is a set of language processors o is an operating system and m is a machine A port is a mapping P E l 1 0o m gt P E l 1 0 m where P is the program to be ported P the resulting program after the port E the original and EI e target environment The following condition must be hold Lo LAA Ly vw 0 0 v m m Hierbei besteht eine Umgebung aus einer Menge von Compilern zusammen mit dem Betriebssystem und dem Rechner auf dem diese installiert sind Damit ist eine Portierung die bertragung eines Programms von einer urspr nglichen Umgebung in eine Zielumgebung bei der die obige Bedingung gilt Dadurch wird ausgeschlossen da eine bertragung ohne nderungen als Portierung bezeichnet wird Ford definiert im Zusammenhang mit erforderlichen Adaptierungs nderungen den Begriff Transport von Software Ford 77 Portabilit t von Software Systemen Seite 18 A
82. bestimmte Portierungsprobleme den Verursachern besser zuordnen SYS System Umgebung Software Umgebung Hardware Umgebung Programmiersprachen SU HU PS Schritte zur Ermittlung des Teilma es System Umgebung Ermittlung der Ma komponente Software Umgebung Ermittlung der Ma komponente Hardware Umgebung Ermittlung der Ma komponente Programmiersprachen Zusammenfassung zur Ma komponente System Umgebung Portabilit tsanalyse am Beispiel des XCTL Systems Seite 139 4 2 1 1 Software Umgebung SU Sofware Umgebung u Betriebssystem Aufrufe Bibliotheksroytinen Aufu Utility Aufu UTM Anzahl Util Aufrufe BIBM Anzahl Bib R Auftufe Anzahl Bib R Auftufe BIBM 1 bei vorhandener Portierungserfahrung Portierungserfahrung B d BM Einarbeitungsaufwand BSM 2 Einarbeitungsaufwand Verh ltnis Gesamtkomponenten zu Verh ltnis Gesamtkomponenten zu BIBM 3 Anzahlanzupassender Komponenten UTM 3 BSM Anzahlanzupassender Komponenten Anzahl Util Aufu l J 1 AM 1 bei vorhandener Portierungserfahrung BSM Anzahl BS Aufru Anzahl BS Aufru ei a BSM 1 bei vorhandener UTM Einarbeitungsaufwand Verh ltnis Gesamtkomponenten zu AnzahlanzupassenderKomponenten Schritte zur Ermittlung des Teilma es Software Umgebung Ermittlung der Ma komponente Betriebssystem Aufrufe Ermittlung der Ma komponente Bibliotheksroutinen Aufru
83. comment out CLASS bordlg lines change custom bwcc elements to standard controls 1 change word CONTROL to GROUPBOX if there is BorShade string in the same line 1b change word CONTROL to EDITTEXT if there is EDIT string in the same line 2 change CONTROL to AUTOCHECKBOX if there is Borcheck string in the same line and there is no BS_3STATE in the line 3 change CONTROL to AUTO3STATE if there are Borcheck and BS_3STATE in the same line 4 change word CONTROL to CTEXT if there is BorStatic string in the same line 5 change word CONTROL to PUSHBUTTON if there is BorBtn string in the same line 6 change word CONTROL to RADIOBUTTON if there is BorRadio string in the same line 7 change word CONTROL to PUSHBUTTON if there is BS_USERBUTTON string in the same line 8 in these lines delete the part after the second comma but do not delete the trailing four numbers e g change the line CONTROL Belichtungsregelung 1 BorShade BSS_RGROUP BSS_CAPTION BSS_CENTER WS_CHILD WS_VISIBLE 119 93 101 50 to GROUPBOX Belichtungsregelung 1 119 93 101 50
84. dar ber hinaus die Anzahl der in einer Klasse implementierten Methoden ohne Eingeerbte in das Ma mit aufgenommen WMC Die Differenz aus den beiden zuvor gemessenen Werten ergibt die Zahl der eingeerbten bzw bernommenen Methoden und hebt damit den Vererbungsaspekt hervor Das angepa te Ma f r die Kopplungsst rke in Bezug auf den Kopplungsmechanismus zwischen den Systemkomponenten in objektorientierten Software Systemen lautete vergleiche Kapitel 3 2 3 6 KP Y KP i l mit k Anzahl der Komponenten KP Kopplung der Gren Komponente ber den Aufruf Kopplungsmechanismus Portabilit tsanalyse am Beispiel des XCTL Systems Seite 159 KP m RFC m VK mit KP Kopplung der i ten Komponente 1 k m m Gewichtungsfaktoren der Ma anteile RFC Anzahl der aufrufbaren Methoden der i ten Komponente sowie die Anzahl der internen und externen Aufrufe die sie selbst durchf hrt VK Anzahl der eingeerbten bzw bernommenen Methoden der i ten Komponente wobei VK RFC NOM mit NOM Anzahl der in der i ten Komponente implementierten und nicht eingeerbten Methoden Mit Hilfe des McCabe Toolsets werden die Metrikwerte automatisch f r das XCTL System ermittelt Gollnick 99 siehe Anhang F KP Y KP 1622 5 i l Hierbei ergibt sich das Problem da eine Reihe von identifizierten potentiell anzupassenden Aufrufen einer gedachten Systemkomponente Tx zugeordnet werden Diese Hilfestellung resultiert
85. das Zielsystem angepa t werden k nnen und eine Portierung deshalb nicht realisierbar ist Dar ber hinaus ist zu beachten da der Aufwand bei der ersten Anpassung wesentlich gr er ist als im Vergleich zu sp teren Portierungen Hier liegen die erforderlichen Kenntnisse von vorangegangenen Portierungen bereits vor Die Werte f r eine erste Anpassung sollten demnach im differenzierten Ma nicht erfa t werden Das entsprechende Ma f r die Betriebssystem Aufrufe lautet wie folgt BSM KAys PAzs SAys BAzs mit KAzs BSR BSR Namen der BS Routinen die nicht angepa t werden k nnen PA ys Anz BSR BSR Anz BSR BSR Namen und Anzahl der BS Routinen ber die w hrend der m Messung keine Information vorliegt Ada Anz BSR Anz BSR Gesamtzahl der Aufrufe von BS Routinen die anpa bar sind f r die aber keine Aufwandswerte vorliegen Portabilit tsanalyse am Beispiel des XCTL Systems Seite 141 BA ys 4nz BSR B Anz BSR B Summe der bewerteten BS Routinen f r die ein Aufwand vorliegt B Aufwand f r die Anpassung der i ten BS Routine i 1 r KA Keine Anpassungen PA Potentielle Anpassungen SA Sichere Anpassungen BA Bewertete Anpassungen Auch diese Teile des differenzierten Ma es sind mit Hilfe von geeigneten Werkzeugen zu realisieren d h sollten wegen der sonst fehlenden Objektivit t des Ma es automatisch ermittelt werden Hierzu ist eine Datenbasis
86. der Einflu der internen Dokumentation geringer ist Man trifft hierbei eine erste Annahme die wie folgt lauten k nnte und durch konkrete Portierungserfahrungen zu best tigen ist 3 DOK g DOK 5 g DOK p 83 DOK y wobei gilt Dg 1 i l Annahme 3 DOK 0 15 DOK 5 0 6 DOK pp 0 25 DOE wobei gilt Y g 1 i 1 Bei dem XCTL System ergibt sich f r das Dokumentationsma folgender Wert DOK 0 15 0 5 0 6 0 7 0 25 0 36 0 59 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 173 4 3 Zur Portabilit t des XCTL Systems Alle Ma komponenten werden wie folgt zum Gesamtma zusammengefa t wobei ein Tupel gebildet wird da die Ma e sehr unterschiedliche Systemaspekte messen PORT SYS KPL DOK mit SYS KAgys 3 PAgys SAsys BAsys PAN sys H KOMP ys H VKGsys H VSG an KPL KPK DKK SK gs DLK IKK DOK g DOK g DOK py g DOK y ager Das Gesamtma der Portabilitat l t sich aus den bisher ermittelten Daten f r das XCTL System wie folgt berechnen Tabellenf hrung 474 SYS PAN pys KOMP ys VKG sy 956 TModelessDlg 3 TAbout 2 TMotor 10 TAdjustmentExecute 2 TMotorParam 5 TAdjustmentWindow 4 TOptimizeDC_812 12 TAm9513a 49 TPlotData 8 TAngleControl 32 TPosControl 7 TAquisition i 2 TPsd 11 TAreaScan 18 TPsdRemoteSync 4 TAreaScanCmd 1 TRadicon 16 TAreaScanParameters 1 TScan 1
87. der Portabilit t von Software Systemen da dieses so gestaltet werden und gem der Spezifikation funktionieren mu da keine Annahmen ber das kulturelle Umfeld zugrunde liegen Ein erstes Problem sind hierbei die reichhaltigen Zeichens tze in vielen Teilen der Welt So reicht hier die bereits angesprochenen ASCII Codierung der verschiedenen Zeichen nicht aus Auch sind die in vielen Teilen Europas benutzten vollen 8 Byte Erweiterungen des ASCII Zeichensatzes z B Latin Portabilit t von Software Systemen Seite 48 1 Kodierung f r viele Sprachen nicht ausreichend So erfordern Kodierungen im asiatischen Raum beispielsweise 16 Bit pro Zeichen Um diese Situation zu verbessern wurde der 16 Bit Unicode Zeichensatz geschaffen wodurch eine konsistente Kodierung f r alle Sprachen der Welt m glich wird Dadurch entsteht aber wieder ein neues Problem welches daraus resultiert da die Zeichen nicht mehr l nger in ein Byte passen und somit Verwirrungen um die Byte Reihenfolge auftreten Um dieses Problem zu vermeiden benutzt man f r Unicode Dokumente vor der bertragung zwischen Software Systemen oder ber Netzwerke eine Byte Strom Kodierung namens UTF 8 Hierbei kann man von einer Abw rtskompatibilit t zur ASCH Kodierung ausgehen was Software Systemen die Text als nicht interpretierten Byte Strom ansehen erm glicht mit Unicode Text in jeder Sprache zu funktionieren C und C unterst tzen wide characters d h breite
88. der aufrufbaren Routinen des Host Betriebssystems notwendig Die Bewertung erfolgt dann unter Nutzung der vorhandenen Aufwandsdaten Dieser Teil des Aufwandsma es ist jedoch erst f r sp tere Phasen der Portierung relevant und hat bei der hier durchgef hrten Analyse des XCTL Systems zun chst keine Bedeutung Ist das XCTL System erfolgreich portiert worden werden die Portierungserfahrungen durch dieses Ma ausgedr ckt womit sich die Genauigkeit des Aufwandsma es deutlich verbessert Im zweiten Schritt werden die von nderungen betroffenen Komponenten eines Software Systems mit der darin befindlichen Anzahl von anzupassenden Betriebssystem Aufrufen erfa t Dieses Ma ist deshalb erforderlich da es f r einen Porteur notwendig ist sich in die betroffenen Programmkomponenten einzuarbeiten Sind die anzupassenden Aufrufe ber viele Komponenten zerstreut ist auch der Einarbeitungsaufwand gr er Ziel des zweiten BS Aufruf Ma es ist es Aussagen ber den Einarbeitungsaufwand und wichtige Entscheidungen z B in Richtung einer Neuimplementation zu erm glichen BSM komm Anz BSA KOMP Anz BSA mit KOMP i te betroffene Komponente des Programms i 1 n BSA anzupassender Aufruf einer BS Routine F r die Ermittlung des zweiten BS Aufruf Ma es BSM werden die einzelnen Systemkomponenten des XCTL Systems identifiziert in denen die Betriebssystem Aufrufe stattfinden Hiermit sollen Aussagen ber den Einarbeitungsaufwa
89. des XCTL Systems cooooconococonoconnnonnnonnnnononanonnn nono coon nooo nono nono narra rannrnnnnnnss 199 Tabelle E6 Hardwareausstattung der Arbeitspl tze f r das SCT Swvstem 200 Tabelle F7 Me ergebnisse des McCabe Toolsets f r die Komplexit tskomponente enee 232 Einleitung Seite 13 1 Einleitung Die Entwicklung von Software Systemen ist mit st ndig steigenden Kosten verbunden Aus Herstellersicht wird daher die Ausdehnung der Zykluszeit von Anwendungssystemen und deren weite Verbreitung zunehmend wichtiger Auch aus Anwendersicht ist die lange Lebensdauer und die weite Verbreitung mit geringeren Anschaffungskosten und verringertem Einarbeitungsaufwand verbunden wodurch sich schlie lich die Amortisierungsdauer von Anwendungssoftware verk rzt Einer ausgedehnten Zykluszeit f r Anwendungssoftware steht aber eine wesentlich niedrigere Zykluszeit f r Systemsoftware und eine noch geringere Hardware Zykluszeit entgegen Entwickelt man heute Anwendungssoftware dann bedeutet dies da w hrend der Lebenszeit der Software mindestens einmal die zugrunde liegende Systemsoftware und mindestens zweimal die Hardware ausgetauscht wird Die weite Verbreitung einer Anwendungssoftware mu neben der Lebenszykluszeit von Komponenten eines Computersystems zus tzlich den Aspekt der l nderspezifischen Varianten ber cksichtigen Um die Lebensdauer und die weite Verbreitung bereits bestehender Software Systeme zu erm glichen ist es n
90. die Gr e eines Fensters ver ndert werden nicht nur Nachrichten an das GDI sondern auch an den Kernel geschickt der die neuen Daten ber die zugrunde liegende Hardware verarbeitet und im Speicher ablegt Der Kernel ist der Teil des Systemkerns der alle peripheren Elemente des Rechnersystem rund um die CPU kontrolliert Bei Windows 3 1 unterscheidet man zwischen dem Protected Mode f r Prozessoren mit der Architektur einer 80286 CPU und dem f r 80386 Modelle Somit wird f r jeden Prozessortyp ein entsprechend kompatibler Kernel KRNL286 Standard Mode oder KRNL386 Enhanced Mode geladen Um eine bestm gliche Anpassung an die Prozessoren zu erreichen kennt Windows drei Betriebsarten die sich an den F higkeiten und den Betriebsarten der jeweils zugrundeliegenden CPU des Rechnersystems orientieren An erster Stelle w re der Real Mode zu erw hnen der aus Kompatibilit tsgr nden zu Rechnersystemen mit 8086 88 Prozessoren existiert Im Real Mode laufen nicht nur ltere DOS Anwendungen es lassen sich sogar speziell f r die vorherige Fassung 2 x erstellte Treiberprogramme zur Anpassung von Fremd Hardware direkt verwenden Im Real Mode wird f r Speicherweiterungen ber die engen Verwaltungsgrenzen von DOS 640 KB hinaus prozessorbedingt die Expanded Memory Technologie benutzt Alle weiteren Modi arbeiten mit verbesserten Technologien wie dem Extended Memory welche durch nachfolgende Prozessoren unterst tz wird Ei
91. die jeweilige Programmierschnittstelle hier die Windows API ber die sich aus Programmierersicht ein Betriebssystem definiert Mit Hilfe von integrierten Entwicklungsumgebungen als automatisches Werkzeug nicht nur f r den Erstellungsproze sondern auch f r den gesamten Entwicklungsproze werden komplexe Software Systeme f r Windows realisiert Abstrakte Entwicklungsumgebungen und Programmierbibliotheken verbergen jedoch meist die internen Abl ufe eines Systems und verhindern somit ein tieferes Verst ndnis der zugrunde liegenden Strukturen und Datentypen Da Windows selbst berwiegend in der Programmiersprache C geschrieben ist liefert diese in Kombination mit direkten Aufrufen der Windows API nat rlicherweise die bestm gliche Performance und Flexibilit t Dar ber hinaus schult der direkte Umgang mit der Windows API auch das Wissen ber die internen Abl ufe und macht sich bei einem Wechsel auf eine abstraktere Entwicklungsumgebung durch ein solide geschultes API Wissen bezahlt Demgegen ber steht die einfache und zeitsparende Programmerstellung mittels einer Programmierumgebung und bibliothek Dieser erlauben die Konzentration auf das Wesentliche z B die Elemente der Benutzeroberfl che die dann ber relativ einfache Mechanismen mit entsprechenden Aktionen verbunden werden Somit kommt man relativ schnell zu komplexen Software Systemen unter Windows ohne die Komplexit t des Systems zu ber hren Portabilit t von Software S
92. export WINAPI mllnitializeMotorsDLL void BOOL _ export WINAPI mlSetAxis int axis int _export WINAPI mlGetAxis void int _export WINAPI mlGetlIdByName TAxisType at TAxisType _export WINAPI mlParsingAxis LPSTR axisname BOOL _ export WINAPI mllsAxisValid TAxisType type BOOL _ export WINAPI mllsServerOK void int _export WINAPI mlGetAxisNumber void double _export WINAPI mIGetOffset int mid void _export WINAPI mlSetAngleDefault void void _export WINAPI mlOptimizingDlg void BOOL _export WINAPI mlGetDistance int mid double amp distance double _export WINAPI mlGetValue int mid TValueType vtype BOOL _export WINAPI mIMoveToDistance int mid double distance BOOL _export WINAPI mllsMoveFinish int mid void _export WINAPI mlSetParametersDlg void void _export WINAPI mIPositionControlDig void void _export WINAPI mlSaveModuleSettings void void _export WINAPI mllnquireReferencePointDlg int task BOOL _ export WINAPI mSetLine int number BOOL state void _export WINAPI mSetRelativeZero BOOL yes double value BOOL _ export WINAPI mlsDistanceRelative void BOOL _ export WINAPI mlsRangeHit void BOOL _ export WINAPI mMoveByDistance double angle BOOL _ export WINAPI mMoveToDistance double angle BOOL _ export WINAPI mlsMoveFinish void BOOL _ export WINAPI mGetDistance double Sang double _export WINAPI mGetDistanceProcess void void _export WINAPI mStopDrive BOOL restart double _export WINAPI mGetValue TValueType vtype
93. hwndCtl 0 SendMessage St_layer cpp 38 St_layer cpp 261 St_layer cpp St_layer h 16 St_layer h 34 Testdev cpp 33 Testdev cpp 36 KOMP Tx 145 147 MessageBox GetFocus Die Antriebe sind nicht Ok Fehler MBINFO MessageBox GetFocus Bibliothek motors dll nicht geladen Fehler MBSTOP BOOL WINAPI _ export UnlockDataBase void BOOL WINAPI UnlockDataBase typedef BOOL WINAPI TUnlockDataBase PostMessage hControlWnd WM_COMMAND wpJumpTo Getld PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld Anz BIBA 129 Anzahl GROUP GROUP Ergebnis GDI 71 MBE 46 DOK 4 Gesamtergebnis 121 BIBM Anz BIBR Anz BIBR 353 BIBM KOMP Anz BIBA KOMP Anz BIBA TAbout f 2 TAdjustmentExecute 2 TAdjustmentWindow 1 TAm9513a j 2 TAngleControl 32 Anhang F Daten der Quelltextanalyse Seite 211 TAquisition TAreaScan TAreaScanCmd TAreaScanParameters TBitmap Source TBraun_Psd TC_812 TC_812GPIB f TC_832 y TCalibrate TCalibratePsd gt TCmd 5 TCommonDevParam _ TCounterShowParam _ TCounterWindow TCurve j TDC_Drive TDevice TDList TEditWindow d TEncoder TExecuteCmd TGenericDevice TMacroExecute TMain A TMDIWindow 3 TMList TModalDlg TModelessDig TMotor TMotorParam TPlotData TPosControl i TPsd j TPsdRemoteSync TRadi
94. je mehr Methoden eine Klasse hat desto komplexer ist die Klasse Je mehr Kontrollfl sse in den Methoden einer Klasse enthalten sind um so schwerer sind diese zu verstehen und zu warten Folgende Standpunkte werden f r die WMC Metrik vertreten Fetcke 95 Die Anzahl und Komplexit t der Methoden bestimmen den Aufwand f r Entwicklung und Wartung Je gr er die Anzahl der Klassen desto gr er ist der Einflu auf abgeleitete Klassen die diese Methoden dann erben Klassen mit vielen Methoden sind wahrscheinlich anwendungsspezifischer als Klassen mit wenigen Methoden 3 2 Metriken zur Portabilit tsanalyse In diesem Abschnitt geht es im Speziellen um die Darstellung von Metrikvorschl gen zur Vermessung der Portabilit t von Software Systemen Die Einordnung von Portabilit ts Metriken in den Rahmen von Qualit tsmodellen soll zun chst zeigen in welchem Gesamtzusammenhang sich die vorgestellten Metriken bewegen Im Anschlu daran werden eine Reihe von Metrikvorschl gen zur Vermessung der Portabilit t von Software Systemen vorgestellt und bewertet Dieser Abschnitt bildet damit u a die Grundlage f r die Berechnung einer Portabilit ts Metrik an einem Windows basierten Software System Metriken und Portierungsaufwand Seite 102 3 2 1 Einordnung von Portabilit ts Metriken Wie bereits erw hnt werden Software Metriken prim r f r die Vorhersage von Wartungs und Entwicklungsaufwand und zur Bewertung von Software Qua
95. oder auch verbundene Komponente ist hierbei ein Untergraph in dem jeder Knoten von jedem anderen Knoten erreichbar ist So besteht ein Kontrollflu graph eines Software Systems ohne Prozeduren oder Funktionen aus einer verbundenen Komponente p 1 Ein Software System das aus mehreren Prozeduren oder Funktionen besteht und jede durch einen eigenen Untergraph dargestellt wird hat somit eine entsprechende Anzahl verbundener Komponenten Reduziert man einen Graphen in dem man alle Untergraphen entfernt die nur einen Ein und einen Ausgangsknoten haben primitive Kontrollstrukturen der strukturellen Programmierung Sequenz If Case While Repeat so bezeichnet man die zyklomatische Komplexit t des reduzierten Graphen G als essentielle Komplexit t ev G v G v n Diese dr ckt den Grad der Unstrukturiertheit eines Graphen bzw Moduls aus und wird mittels Differenz von zyklomatischer Komplexit t des vollst ndigen Graphen v und der minimalen Anzahl von Untergraphen n ermittelt Die essentielle Komplexit t sollte f r strukturierte Programme immer den Wert I haben da nach einer vollst ndigen Reduzierung eines Graphen nur eine Sequenz brig bleiben sollte McCabe formuliert in diesem Zusammenhang vier F lle die zu unstrukturierten Metriken und Portierungsaufwand Seite 91 Programmen f hren Aus und Einsprung aus einer oder in eine Schleife sowie Aus und Einsprung aus einer oder in eine Entscheidung Wobei er zeigt da jew
96. program is transportable between configurations a and b if it will compute to prescribed levels of accuracy and efficiency in each computing environment with automated changes made by a computer program Lassen sich erforderliche nderungen automatisch durchf hren so spricht Ford nicht von Portierung sondern von Transport von Software In den 90er Jahren definiert Mooney die Portabilit t von Programmen in Abh ngigkeit zum vorhandenen Aufwand der f r die Adaptierung und den Transport notwendig ist Mooney 90 An application is portable across a class of environments to the degree that the effort required to transport and adapt it to anew Auf die Begriffe Transport und Adaptierung von Programmen im Zusammenhang mit dem Proze einer Portierung geht er wie folgt ein The porting process has two principal components which may be called adaption and transportation Adaption is any modification that must be performed on the original version Transportation is physical movement with low level adaptation Adaptierung bedeutet also die nderung von Programmen im Proze der Portierung und Transport bezeichnet hierbei die physikalische bertragung von Programmen auf die Zielumgebung Mit low level adaption sind Anpassungen bzgl eines unterschiedlichen Datenformats gemeint Den Begriff Portierung definiert Mooney wie folgt Mooney 97 Porting is the act of producing an executable versio
97. sich im Wesentlichen bei den Funktionen die sich mit der Verwaltung und Ver nderung des Eingabestatus befassen Dies betrifft insbesondere die Verwaltung des Fokus bzw der aktiven Fenster sowie das systemweite Abfangen aller Mausnachrichten Jeder Anwendungsproze besitzt eine eigene Nachrichtenschlange f r alle an ihn bestimmten abh ngig vom aktuellen Eingabefokus welcher auf ein aktives Fensters eines Anwendungsprozesses gerichtet ist eingehenden Nachrichten Unter Win16 ist es jederzeit m glich das Handle des Fokus Windows zu erfragen GetFocus Unter Win32 nur dann wenn das Fenster auch zum aufrufenden Proze der Anwendung geh rt Auch kann unter Win16 jeder beliebigen Anwendung sobald ihr Handle bekannt ist der Fokus zugewiesen werden SetFocus Dies ist unter Win32 nur noch f r die vom Anwendungsproze eigens erzeugten Fenster m glich Auch das Erfragen oder Setzen von Portabilit t von Software Systemen Seite 64 aktiven Fenstern bezieht sich unter Win32 nur noch auf den lokalen Eingabestatus von Anwendungsprozessen Zus tzlich zum standardm igen Abfangen von Mausnachrichten ber das jeweils aktive Fenster eines Anwendungsprozesses besteht f r Fenster unter Winl6 jederzeit die M glichkeit sich dem Eingabestrom der Mausnachrichten zu bem chtigen SetCapture Wie der Fokus ist der mouse capture eine Art Pseudo Ressource in deren Besitz immer nur ein einziges Fenster kommen kann Unter Win3
98. ssen berechnet Datenstrukturmetriken messen die Komplexit t der Struktur und der Komponenten eines Software Systems indem sie die Zugriffe auf Daten und Datenstrukturen analysieren Sie vermessen die Anzahl an Variablen eines Software Systems deren G ltigkeit und Lebensdauer Au erdem berpr fen sie Metriken und Portierungsaufwand Seite 79 ob diese auch referenziert werden Eine wichtige Datenstrukturmetrik ist die Segment global usage pair Metrik Sie vermi t die Anzahl der Lese oder Schreibzugriffe von Komponenten auf globale Variablen und wird als relative H ufigkeit RUP relative usage pair ausgedr ckt Eine weitere Datenstrukturmetrik ist die Datenbindungsmetrik welche die Beziehung zwischen den Komponenten eines Software Systems bestimmt indem sie deren Informationsaustausch ber globale Variablen mi t Stilmetriken vermessen die psychologische Komplexit t von Software Systemen und beziehen sich somit auf die Faktoren die es dem Menschen erschweren Software Systeme zu verstehen Hierbei werden Software Systeme z B daraufhin untersucht ob der zugrundeliegende Quellcode richtig einger ckt ist und bestimmte Namenskonventionen eingehalten werden Ein Beispiel f r eine Stilmetrik ist die von Halstead definierte Berechnung der Schwierigkeit ein Programm zu schreiben oder zu verstehen Hierbei wird ausgehend vom verwendeten Vokabular und der Anzahl der Operanden ein Ma f r den Aufwand zum Schreiben von Progra
99. stellt sich somit die Frage was mit einer einzigen Ma zahl zur Dokumentation ausgesagt wird Ein Problem hierbei ist die Granularit t der einzelnen Ma e da diese in einem Bin rwert das Vorhandensein von Dokumentationsteilen erfassen und somit eine sehr grobe subjektive Messung vornehmen Um den Einflu der Dokumentation auf die H he des Portierungsaufwands zu bewerten sind eine Reihe von Portierungen mit entsprechenden Untersuchungen notwendig Da die Dokumentation in erster Linie einen Indikator f r den Einarbeitungsaufwand in das entsprechende Software System darstellt lassen sich dann auch zeitliche Aufwandsprognosen f r diesen Aspekt der Portierung ableiten DOK 0 59 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 179 Im Zusammenhang mit zeitlichen Aufwandsprognosen kann es sinnvoll sein die allgemein anerkannte Einheit von Mitarbeiter Monaten zu verwenden Hierzu mu dann ein Gesamtma Portabilit t gebildet werden welches dann auf die Anzahl der ben tigten Mitarbeiter Monate als zeitlicher Aufwand f r die Portierung des Software Systems abgebildet wird Dies kann z B durch die Summation der ermittelten Ma komponenten erfolgen Daf r sind jedoch eine Reihe empirischer Portierungsuntersuchungen notwendig die dann einen entsprechend funktionalen Zusammenhang herausstellen wie das z B bei der Function Point Methode der Fall ist Zusammenfassung Anmerkungen Ausblick Seite 181 Zusammenfassu
100. t werden k nnen dar ber hinaus aber eine weitergehende Interpretation aufgrund fehlender Erfahrungsdaten nicht zulassen Auch hierbei entsteht durch die Aggregation zwar wieder eine kompaktere Aussage aber auch diese ist mit Informationsverlust behaftet F r genauere Analysen mu deshalb auf die Subma e zur ckgegriffen werden Auch ergibt sich hier wieder das Problem der Zuordnung verwaister Systemelemente Die Teile des Software Systems die keiner Systemkomponente au er Tx zugeordnet werden konnten werden deshalb zun chst nicht ber cksichtigt Da das XCTL System innerhalb eines Reengineering Projekts bearbeitet wird ist es jedoch wahrscheinlich da in einer weiteren Version der Portabilit tsanalyse in diesem Teil genauere Me daten zur Verf gung stehen Portabilit tsanalyse am Beispiel des XCTL Systems Seite 178 Das Ma SK als gewichtete Summe der Kopplungen zwischen den Systemkomponenten aggr innerhalb eines untersuchten Software Systems ist hierbei ein Indikator f r die Kopplungsst rke zwischen den Systemkomponenten Die Summe beinhaltet Portierungserfahrungen ber die Gewichtung der Subma e und erlaubt Aussagen bez glich des potentiellen nderungsaufwands oder der Testbarkeit eines Software Systems SK joo 817 23 aggr Bei diesem Ma mu noch einmal darauf hingewiesen werden da bei der Vermessung des XCTL Systems keine ausreichenden Me werte f r den Zugriff auf globale Daten ermittelt w
101. von GUI s ist die symbolische oder grafische Repr sentation von Informationen und deren Manipulation Neben der so entstehenden Interaktion zwischen Mensch und Maschine liegt der gr te Vorteil von grafischen Portabilit t von Software Systemen Seite 40 Benutzeroberfl chen darin da sie Programme berwiegend einheitlich repr sentieren Durch das Einhalten des Prinzips der Uniformit t bei der Repr sentation und Manipulation von Informationen steigt die Lernkurve des Benutzers exponentiell an und erleichtert somit auch das Einarbeiten in hnliche Umgebungen mit grafischer Benutzeroberfl che Aus Programmiersicht zeigt sich die Uniformit t darin da das System nicht nur die Funktionen zum Anlegen von Fenstern Men s Dialogen etc definiert sondern auch die Teile der Funktionalit t dieser Komponenten So haben z B Men s deshalb eine einheitliche Maus und Tastaturschnittstelle weil diese Arbeit von Windows bernommen wird und nicht Aufgabe der jeweiligen Anwendung ist Multitasking Hinter diesem Konzept steht die Idee der quasi parallelen Ausf hrung von Software Systemen die bei Bedarf untereinander Informationsaustausch betreiben k nnen und durch jeweils ein Hauptanwendungsfenster auf der Benutzeroberfl che repr sentiert werden Benutzer k nnen diese Anwendungsfenster dann z B in ihrer Gr e ver ndern verschieben oder beliebig von einem Anwendungsfenster in ein anderes wechseln und Informationen zwischen diesen a
102. wParam lParam anders verpackt MBE message cracker oder alternative Makroschale benutzen STRUCTURES cbClsExtra WNDCLASS Falls 0 verbreiterte Datentypen beruecksichtigen LA Evtl Groesse anpassen cbWndExtra WNDCLASS Falls 0 verbreiterte Datentypen beruecksichtigen LA Evtl Groesse anpassen DCB DCB Bitfelder geaendert neue Komponenten DOS TYPES HTASK HTASK Datentyp gestrichen LA Ersetzen durch Thread Id DWORD LONG LONG LONG Variable oder Parameter pruefen LA Ggf durch LPARAM LRESULT ersetzen short short Cast auf 16 oder 32 Bit pruefen LA 16 Bit Datentypen mit ihren 32 Bit Aequivalenten ersetzen WORD WORD Cast auf 16 oder 32 Bit pruefen LA 16 Bit Datentypen mit ihren 32 Bit Aequivalenten ersetzen Anhang B Inhalt der zentralen Problembibliothek Seite 193 WORD WORD WORD Variable oder Parameter pruefen LA Ggf durch UINT oder WPARAM ersetzen CONSTANTS CS_GLOBALCLASS RegisterClass Windows Klassen sind nicht nicht mehr global SEP Explizites Laden der betreffenden DLL GCW_ATOM GetClassLong Kein Win32 Aequivalent SEP GCW_CBWNDEXTRA GetClassLong Datentyp Verbreiterung LA Ersetzen durch GCL_CBWNDEXTRA GCW_CBCLSEXTRA GetClassLong Datentyp Verbreiterung LA Ersetzen durch GCL_CBCLSEXTRA GCW_HCURSOR GetClassLong Datentyp Verbreiterung GDI Ersetzen durch GCL_HCURSOR GCW_HBRBACKGROUND GetClassLong Datentyp Verbreiterung GDI Ersetzen durch GCL_HBRBACKGROUND GCW_HICON GetClassLong Datenty
103. wird Eine Aggregation zu einem Gesamtma Portabilit t wird nicht durchgef hrt Einen umfassenderen Ansatz findet man in einer Arbeit von Buschhorn und Kuchnowski Buschhorn 88 die auf der Basis eines von ihnen aufgestellten Portabilit tsmodells siehe Abbildung 4 in Kapitel 2 1 4 ebenfalls ein Ma zur Bestimmung der Portabilit t eines Software Systems aufstellen PORT SYS DOK KPL mit SYS Systemumgebung bzw Software Umgebung DOK Dokumentation KPL Komplexit t Die einzelnen Ma faktoren setzen sich aus me baren Einflu gr en zusammen die neben anderen anhand des Portierungsmodells identifiziert werden Hierbei wird versucht ein umfassendes Portierungsma aufzustellen und die einzelnen Ma faktoren zu einem Gesamtma f r die Portabilit t eines Software Systems zusammenzuf hren Es wird der evolution re Aspekt des Ma es betont der dieses durch praktische Verwendung und den daraus resultierenden Erfahrungswerten weiter anpa t Dieses soll dann immer genauere Aussagen bzw Vorhersagen zum Portierungsaufwand eines untersuchten Software Systems erm glichen Erfahrungswerte bei der Anwendung des Ma es in konkreten Portierungsprojekten werden von den Autoren jedoch nicht angegeben Zusammenfassend kann gesagt werden da Metriken zur Bestimmung des Aufwands einer Portierung in Ans tzen vorhanden sind Neben der Bestimmung des Portabilit tsgrads eines Software Systems die den Aufwand einer Neue
104. 0 95 TSteering 250 6 1 70 24 0 1 42 42 0 3 94 0 0 68 FALSE 21 1 35 TStoe_Psd 32 2 91 10 5 0 3 59 11 48 12 81 1 0 0 FALSE 53 5 5 1 TTopography 2 1 1 1 0 1 2 2 0 1 50 0 0 100 FALSE 1 0 65 TTopographyExecute 52 10 4 38 7 0 2 10 5 5 4 46 1 0 0 FALSE 7 5 2 TTopographySetParam 34 6 8 14 1 0 2 11 5 6 1 60 d 0 13 FALSE 8 5 0 95 V K S K Class Name sum v G avg v G max v G max NOC Depth RFC WMC RFC CBO LOCM Parents PubDataAcc PubData DepOnChild KP DK Total 295 23 1027 65 177 2084 923 Hee 259 4667 65 0 3662 1622 5 11 95 Average 31 89 2 87 9 97 3 86 0 63 1 72 20 23 8 96 11 27 2 51 45 31 0 63 0 35 55 Maximum 307 10 4 70 34 24 4 72 54 61 18 100 2 0 100 Minimum 1 1 1 1 0 1 0 0 0 0 0 0 0 0 Rows in Report 103 Tabelle F7 Me ergebnisse des McCabe Toolsets f r die Komplexit tskomponente Anhang F Daten der Quelltextanalyse Seite 233 F 4 1 Ermittlung Ma komponente Schnittstellenkomplexit t KP 0 5 RFC 0 5 VK 0 5 10 0 5 6 8 KP 0 5 RFC 0 5 VK 0 5 11 0 5 6 8 5 k KP KP 1622 5 i l DK 0 35 CBO 0 35 PA 0 3 DIT 0 35 0 0 35 0 0 3 2 0 6 DK 0 35 CBO 0 35 PA 0 3 DIT 0 35 1 0 35 0 0 3 2 0 95 k DEES DE 11 95 i l SK KP DK 1622 5 11 95 zk s KP s DK 0 5 1622 5 0 5 11 95 817 23 ager F 4 2 Ermittlung Ma komponente Interne Komponentenkomplexitat VWMC A M 6 j l VWMC A v M 34 j l k V K 3 VWMC 3285 i l EWMC Max ev M
105. 0 DWORD valueDW Motors cpp 1165 valueDW DWORD atol buf Motors cpp 1175 valueW WORD atoi buf KOMP TMotorParam Anz MAA 4 Motors cpp 1380 Drive gt wStaticGain WORD atoi buf Motors cpp 1382 Drive gt wDynamicGain WORD atoi buf Motors cpp 1384 Drive gt wTorque WORD atoi buf Motors cpp 1386 Drive gt wPositionWidth WORD atoi buf Motors cpp 1407 Drive gt wStaticGain WORD atoi buf Motors cpp 1409 Drive gt wDynamicGain WORD atoi buf Motors cpp 1411 Drive gt wTorque WORD atoi buf KOMP TOptimizeDC_812 Anz MAA 7 Motors cpp 1273 Drive gt wKD WORD atoi buf Motors cpp 1275 Drive gt wKP WORD atoi buf Motors cpp 1277 Drive gt wKI WORD atoi buf Motors cpp 1279 Drive gt wKL WORD atoi buf Motors cpp 1281 Drive gt wPositionWidth WORD atoi buf KOMP TOptimizeDC_832 Anz MAA 5 M_data cpp 1514 xi LOWORD IParam xBorder M_data cpp 1515 yi Screen y1 HIWORD IParam yBorder M_data cpp 1520 xi LOWORD IParam xBorder M_data cpp 1521 yi Screen y1 HIWORD IParam M_data cpp 1640 xi _LOWORD IParam xBorder M_data cpp 1641 yi Screen y1 HIWORD IParam KOMP TPlotData Anz MAA 6 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_812 TOptimizeDC_832 TOptimizeDC_832 TOptimizeDC_832 TOptimizeDC_832 TOptimizeDC_832 141 dialogFunc DLGPROC
106. 128 wDeathBand WORD GetPrivateProfilelnt Ident DeathBand 1 GetCFile TDC_Drive TDC_Drive Motors cpp 2129 wDeccelerationPoint WORD GetPrivateProfilelnt Ident DeccelerationPoint 20 GetCFile TDC_Drive TDC_Drive Motors cpp 2221 DWORD velocity Motors cpp 2232 DWORD vel KOMP TDC_Drive Anz MAA 4 Counters cpp 281 int TDevice SetExposureValues float et DWORD ec float ef TDevice Counters cpp 295 void TDevice GetExposureValues float amp et DWORD amp ec float amp ef TDevice Counters cpp 302 double TDevice CalcTime DWORD mssum TDevice Counters cpp 334 CALLBACK TDevice EventHandler UINT UINT DWORD DWORD DWORD TDevice M_devcom h 60 int SetExposureValues float DWORD float TDevice M_devcom h 71 void GetExposureValues float amp DWORD amp float amp TDevice M_devcom h 80 virtual int GetData WORD WORD WORD return 0 TDevice M_devcom h 119 static CALLBACK EventHandler UINT UINT DWORD DWORD DWORD TDevice TDC_Drive SetSpeed double TDC_Drive GetSpeed SetExposureValues float unsigned_long float GetExposureValues float_ amp unsigned_long_ amp float_ amp CalcTime unsigned_long EventHandler unsigned_int unsigned_int unsigned_lon SetExposureValues float unsigned_long float GetExposureValues float_ amp unsigned_long_ amp float_ amp GetData TCurve_ amp EventHandler unsigned_int unsigned_int unsigned_lon M_devcom h 151 double CalcTime DWORD TDevice CalcTime unsigned
107. 2 199 M_scan cpp 3277 M_steerg cpp 38 M_steerg cpp 121 M_steerg cpp 755 M_steerg cpp 1885 M_steerg cpp 1885 M_topo h M_topo h M_topo h M_xscan h M_xscan h M_xscan h M_xscan h M_xscan h M_xscan h Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp Pcl_830 inc Radicon h Radicon h Radicon h Radicon h Radicon h St st St St St St St st st st st St ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp ayer cpp _layer cpp 23 55 66 58 61 254 669 745 891 11 90 91 94 95 96 97 98 111 115 119 123 127 3751 3837 3861 3884 3910 37 84 36 43 43 54 56 19 28 33 57 62 72 77 87 87 95 100 115 LONG LWert WORD IWert 2 LONG PositionsDatenHeader 16 LONG IPositionStop Countstop fuer Positionskanaele 0 EFFFFFFFFFFF hex LONG IMeasTime JI Messzeit 1 9999999 dec sec AppendMenu TheMenu MF_POPUP WORD hM2 amp Vergleichs Scan static DWORD dwStartTimeTicks friend LRESULT CALLBACK FrameWndProc HWND UINT WPARAM LPARAM DWORD dwElapsedTicks void CALLBACK _ export RecallSteering UINT UINT DWORD DWORD DWORD RecallSteering unsigned_int unsigned_int unsigned_long unsig void CALLBACK
108. 2 kann nur das Fenster oder eines seiner Child Windows den mouse capture erhalten das sich gerade im Vordergrund befindet bzw aktiv ist F r alle nicht im Vordergrund befindlichen Fenster ist ein Versuch die Mausnachrichten abzufangen unter Win32 wirkungslos und f hrt zu Portierungsproblemen Das systemweit eigenm chtige Abfangen von Mausnachrichten verletzt das Prinzip von Win32 jederzeitige Bedienbarkeit aller gegenw rtig laufenden Anwendungen zu gew hrleisten Dazu geh rt auch die Nutzung modaler Dialogboxen nderungen am GDI Das GDI unter Win32 ist nicht nur komplett neu implementiert in C statt wie unter Win16 in C und somit objektiv verbessert worden sondern es ist auch mit seinen Koordinaten gewachsen Die im Zusammenhang mit dem GDI auftretenden Problemf lle betreffen im Wesentlichen die verbreiterten GDI Koordinaten und das Verpacken von Koordinaten Die Funktionen f r die Darstellung von Text und Grafik die ber die grafische Ger teschnittstelle zur Verf gung gestellt werden benutzen unter Windows 3 x 16 Bit breite GDI Koordinaten f r die Darstellung von Informationen auf dem jeweiligen Ausgabemedium Diese wurden unter Win32 auf 32 Bit verbreitert Portierungsprobleme ergeben sich hierbei in den Strukturen die mit Koordinaten bzw Gr enangaben umgehen POINT RECT etc W hrend die meisten Strukturkomponenten die Koordinaten beschreiben konsistent auf 32 Bit erweitert wurden und eine
109. 32 Funktionen abgedeckt F r die zweite Gruppe der Hardware Zugriffe werden unter Windows NT eigene Ger tetreiber ben tigt welche im Kernel Mode auf die einzelnen Hardwarekomponenten zugreifen Eng mit der Hardware und dem Betriebssystem verbunden ist die Speicherung und Bearbeitung von Dateinamen Unter Windows NT werden verschiedene Dateisysteme unterst tzt NTFS HPFS etc die sich von dem Dateisystem unter Windows 3 1 FAT unterscheiden Das Problem der unterschiedlichen Dateisysteme macht sich in den meisten F llen dann bemerkbar wenn man implizit Annahmen ber die L nge und das Format von Dateinamen macht 80 Zeichen Limit unter Windows 3 1 im 8 3 Format Hierbei entstehen Probleme bei der nach Win32 portierten Version dieser Anwendung sobald diese auf einem Win32 System ohne FAT Dateisystem l uft und einen Dateinamen verwendet der l nger als die vorgegebene Gr e von z B 80 Byte ist bzw das 8 3 Format nicht einh lt Weiterhin ist die unterschiedliche Semantik einzelner Zeichen sowie verschiedenartige Konventionen in Bezug auf Dateinamen in den unterschiedlichen Dateisystemen Portabilit t von Software Systemen Seite 66 zu ber cksichtigen Auch m ssen alle Programmteile die Pfad oder Dateinamen zeichenweise analysieren entsprechend den Namenkonventionen angepa t werden Das Konzept der zentralen Registrierungsdatenbank f hrt zu weiteren Problemstellen bei der Portierung So ist unter Windows 3 1 jede Anw
110. 32 g Anzahl der Komponenten MA MAM MAM MAM 563 MAM 0 395 0 395 1 F 2 2 Ermittlung der Ma komponente Peripherieger te zu Ma PG siehe Kapitel 4 2 1 2 PG outp Anz PG 4 PG inp Anz PG 5 PG IpfnSetPort Anz PG 1 PG MK _ FP Anz PG 3 PG C832 _ Put Anz PG 10 PG asm Anz PG 14 Am9513 cpp 286 outp nBaseAddr 3 data Am9513 cpp 293 data inp nBaseAddr 2 Am9513 cpp 400 return inp addr Am9513 cpp 418 outp addr cmd Am9513 cpp 437 outp addr test Am9513 cpp 448 outp addr test Delay loWaitAm9513a Am9513 cpp 468 value WORD inp addr Am9513 cpp 480 value WORD WORD inp addr lt lt 8 KOMP TAm9513a Anz PGA 8 BraunPSD cpp 706 IpfnSetPort WORD nBaseAddr zeichen KOMP TBraun_Psd Anz PGA 1 Motors cpp 2945 lpOut1 LPSTR MK_FP FP_OFF __C000h 0x03fc 0x10 wBaseAddr Motors opp 2961 IpOut1 LPSTR MK_FP FP_OFF __D000h 0x03fc 0x10 wBaseAddr KOMP TC_812ISA Anz PGA 2 Motors cpp 3465 C832_Put baddr config 0x07 status C832_Get baddr 1 Motors cpp 3500 C832_Put wBaseAddr cConfig 0x07 status C832_Get wBaseAddr 1 Motors cpp 3522 C832_Put wBaseAddr cConfig 0x07 Motors cpp 3706 C832_Put wBaseAddr cConfig nOnBoardld lt lt 1 Motors cpp 3763 C832_Put base regaddr H Ja Fordere Auslesen des Configuration KOMP TC_832 Anz PGA 5
111. 4 HANDLE 4 2 ATOM UINT 2 WORD 2 SI HFILE int 2 int 4 1 FARPROC void CALLBACK int WINAPI 4 2 6 void 4 WNDPROC LRESULT CALLBACK LRESULT CALLBACK 2 7 HWND UINT WPARAM HWND UINT WPARAM LPARAM 4 LPARAM 4 Tabelle C4 Die wichtigsten Datentypen von Win16 und Win32 im Vergleich Anhang C Wichtige Datentypen im Vergleich Seite 195 1 Die Gr e des Datentyps hat sich ge ndert 2 Win32 Zeiger bestehen nicht mehr aus Segment und Offset sondern nur noch aus einem vergr erten Offset daher ist keine Segmentarithmetik m glich Es gibt keine Unterscheidung zwischen NEAR und FAR Zeigern 3 ebenso weitere mit DECLARE HANDLE definierte Typen wie z B HDC HMENU etc 4 Zeigertyp der unter Win 16 vom Speichermodell small mdium etc abh ngig ist 5 Hier handelt es sich um eine Ausnahme aus einem Win16 UINT wird ein Win32 WORD die Gr enverh ltnisse ndern sich nicht 6 Einer der F lle in denen die beiden entsprechenden Header Dateien inkonsistent sind 7 Gilt bis auf die Parameterliste auch f r alle anderen Callback Funktionen wie DLGPROC etc Anhang D Quellen bersicht des XCTL Systems Seite 196 Anhang D Quellen bersicht des XCTL Systems Quelldateien Beschreibung ee Use Case F r die Ausf hrung des XCTL Systems ben tigte Programmdateien steerng exe lausf hrbares Steuerprogramm steerng ini Initialisierungsdatei
112. 620 533 52 278 525 596 628 652 3828 3848 3872 3896 3917 LPSTR pTime LPSTR MK_FP FP_OFF __0040h 0x006c _asm mov dx rs out dx al d inp rd _asm _asm mov dx rd in al dx _asm mov dx rd in al dx _asm mov dx rd Portadresse des Datenregisters in dx schreiben _asm sub ax ax Register ax loeschen _asm mov dx rs Portadresse des Steuerregisters in dx schreiben _asm mov dx rs Portadresse des Steuerregisters in dx schreiben C832_Put base regaddr 1 temp byte 1 C832_Get base 1 C832_Put base regaddr 1 C832_Put base regaddr 1 C832_Put base regaddr 1 command register vom aktiven drive C832_Put base config drive lt lt 1 KOMP Tx Anz PGA 14 PGM Anz PG Anz PG 37 PGM KOMP Anz PGA KOMP Anz PGA TAm9513a 8 TBraun_Psd 1 TC_812ISA 2 TC_832 9 TStoe Psd 7 Tx 14 PGM Anzahl aller Komponenten mit PG Zugriffen _ 6 _ 0 074 gi Anzahl der Komponenten PG PGM PGM PGM 37 PGM 0 074 LibMain HINSTANCE____ unsigned_short unsigned_short char_ reset int init_b unsigned_char_ unsigned_int int int tr_message int int int unsigned_char_ int rc_message int int int unsigned_char_ int int_ out_byte int int int in_byte int int int_ status_rd int status_wr int GetWord unsigned_shor
113. 631 MessageBox GetFocus msg TimeOut MS MBFAILURE TC_812 GetStatus Motors cpp 2636 MessageBox GetFocus msg Fehler MBFAILURE TC_812 GetStatus KOMP TC_812 Anz BIBA 2 Anhang F Daten der Quelltextanalyse Seite 204 Motors cpp 2829 MessageBox GetFocus buf Failure MBSTOP TC_812GPIB CheckBoardOk Motors cpp 2998 MessageBox GetFocus buf Fehler MS MBSTOP TC_812GPIB CheckBoardOk Motors cpp 3023 MessageBox GetFocus buf Fehler MS MBFAILURE TC_812GPIB CheckBoardOk Motors cpp 2907 MessageBox GetFocus LPSTR pString Command Failure MBSTOP TC_812GPIB ExecuteCmd char_ Motors cpp 2909 MessageBox GetFocus LPSTR pString Command Failure MBSTOP TC_812GPIB ExecuteCmd char_ Motors cpp 3156 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage TC_812GPIB ExecuteCmd char_ Motors cpp 3175 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage TC_812GPIB ExecuteCmd char_ Motors cpp 3198 MessageBox GetFocus TimeOut read C 812 MBINFO TC_812GPIB ExecuteCmd char_ Motors cpp 2805 MessageBox GetFocus Can t find win488 dll Motor Library MBSTOP TC_812GPIB Initialize Motors cpp 2810 MessageBox GetFocus No GPIB Controller present Failure MBSTOP TC_812GPIB Initialize Motors cpp 2783 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage TC_812GPIB TC_812GPIB KOMP TC_812GPIB Anz BIBA 8 Motors cpp 3471 PostMessage GetFrameHandle WM_COMMAND cm_SetWatch
114. 7 TBitmapSource 24 TScanCmd 6 TBraun_Psd 48 TScsParameters 1 TC_812 22 TSetAdjustmentParam 1 TC_812GPIB 17 TSetupAreaScan 3 TC_812ISA f 2 TSetupContinuousScan 4 TC_832 25 TSetupScanCmd 1 TCalibrate 5 TSetupStepScan 6 TCalibratePsd 8 TShowValueCmd 3 TChooseDeviceCmd 1 TSteering 9 TCmd 2 TStoe_Psd 16 TCommonDevParam 4 TTopographyExecute 8 TCounterShowParam _ 2 Tx 441 TCounterWindow 3 0 703 TCurve i 2 TDC_Drive 5 TDevice 3 17 TDList 1 TEditWindow y 7 TEncoder e 4 TExecuteCmd 2 TGenericDevice j 9 TMacroExecute 5 TMain 22 TMDIWindow 10 TMList 2 TModalDig 4 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 174 KPL KPK DKK SK DLK IKK aggr gt aggr zu 0 506 0 027 817 23 2 87 y 1841 5 DOK 0 15 0 5 0 6 0 7 0 25 0 36 0 59 PORT SYS KPL DOK 956 TScsParameters TAbout TSetAdjustmentParam TAdjustmentExecute TSetupAreaScan TAdjustmentWindow TSetupContinuousScan TAm9513a TSetupScanCmd TAngleControl TSetupStepScan TAquisition TShowValueCmd TAreaScan A TSteering TAreaScanCmd TStoe_Psd TAreaScanParameters TTopographyExecute TBitmapSource Tx TBraun_Psd 0 703 0 506 i 0 027 817 23 i 2 87 e 1841 5 0 59 gt oO 2000002 BPW A _ oc on N gt E O
115. 81 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 M_steerg cpp 2696 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 KOMP TMacroExecute Anz BIBA 5 M_main cpp 150 FreeResource hVersion M_main cpp 125 if msg message WM_QUIT M_main cpp 1616 MessageBox GetFocus strMessage13 strMessage MBINFO KOMP TMain Anz BIBA 3 Comclass h 79 virtual void SetFocus void M_devcom h 220 void SetFocus void M_main cpp 1862 MessageBox GetFocus strMessage02 strFailure MB_Ok M_main cpp 1916 void TMDIWindow SetFocus void KOMP TMDIWindow Anz BIBA 4 TGenericDevice PollDevice TGenericDevice PollDevice TGenericDevice PollDevice TMacroExecute Dlg_OnInit HWND___ HWND___ long TMacroExecute Dlg_OnInit HWND___ HWND___ long TMacroExecute Dlg_OnInit HWND___ HWND___ long TMacroExecute Dlg_Onlnit HWND___ HWND___ long TMacroExecute Dlg_OnInit HWND___ HWND___ long TMain GetVersion char_ TMain MessageLoop TMain TellMessage int TMDIWindow SetFocus TMDIWindow SetFocus TMDIWindow CanOpen TMDIWindow SetFocus Anhang F Daten der Quelltextanalyse Seite 206 Motors cpp Motors cpp KOMP TMList Anz BIBA 2 Dig_tpl cpp 67 FreeProcinstance dialogFunc Dig_tpl cpp 16 BOOL CALLBACK _export DialogProc HWND hDlg UINT msg WPARAM wParam LPARAM IParam Dig_tpl cpp 61 dialogFunc MakeProcinstance FARPROO DialogProc hInstance KOMP
116. 977 Microsoft 95 Microsoft Corporation Microsoft Windows 95 Die technische Referenz UnterschleiBheim Microsoft Press 1995 Microsoft 98 Microsoft Corporation Microsoft Windows 98 Die technische Referenz Unterschlei heim Microsoft Press 1998 Microsoft 98a Microsoft Corporation Windows NT Workstation Version 4 0 Die technische Referenz Unterschlei heim Microsoft Press 1998 Microsoft 98b Microsoft Corporation Hg MSDN Library Visual Studio 6 0 Release 1998 Mooney 90 Mooney J D Strategies for Supporting Application Portability IEEE Computer V23 N11 pp 59 70 Nov 1990 Mooney 93 Mooney J D Issues in the Specification an Measurement of Software Portability Technical Report TR 93 6 Dept of Statistics and Computer Science West Virginia University Morgantown WV 1993 Mooney 94 Mooney J D Portability and Reusability Common Issues and Differences Technical Report TR 94 2 Dept of Statistics and Computer Science West Virginia University Morgantown WV 1994 Mooney 97 Mooney J D Bringing Portability to the Software Process Technical Report TR 97 1 Dept of Statistics and Computer Science West Virginia University Morgantown WV 1997 Moreau 89 Moreau D R Dominick W D Object Oriented Graphical Information Systems Research Plan and Evolution Metrics The Journal of Systems and Software Vol 10 pp 23 28 1989 Myers 75 Myers G J Reliable Software Through Composite Design
117. A Spezifika vor dem Rest des Systems kapselt und der Executive die alle restlichen prozessor und architekturunabh ngigen Komponenten enth lt Unter Windows NT k nnen Anwendungen laufen die f r verschiedenen Betriebssysteme geschrieben worden sind Win32 OS 2 DOS Winl6 POSIX Um diese Flexibilit t zu erreichen mu te der Betriebssystemkern recht allgemein gehalten werden In seinen Aufgabenbereich fallen deshalb nur elementare Dienste wie Proze und Threadverwaltung Speicherverwaltung etc Auf Rechnersystemen ohne INTEL Befehlssatz etwa auf den Alpha oder Mips Systemen wird der Bin rcode der DOS Windows und OS 2 Programme zur Laufzeit interpretiert und in entsprechende Anweisungen f r den Zielprozessor umgesetzt Genauso werden Aufrufe an das OS 2 API zur Laufzeit so modifiziert da sie auf die entsprechenden Funktionen im OS 2 Subsystem verweisen Auch innerhalb der Executive verwendet NT oft mehrere Schichten So handelt es sich bei Dateisystemen letztendlich um Treiber die auf dem Treiber f r blockorientierte Ger te aufsetzen der seinerseits wieder auf den z B SCSI Treiber zur ckgreift Sie haben somit f r den NT Kern den Status von Ger tetreibern F r die Portabilit t von Software Systemen Seite 55 Subsysteme werden abstrakte Systemdienste exportiert aus denen diese die notwendigen Funktionen f r die Emulation ableiten m ssen Die Ger tetreiber und installierbaren Dateisysteme sind so vom Rest de
118. Ber cksichtigung der Benutzt Relation sondern auch der Vererbungsrelation Dar ber hinaus besteht die M glichkeit da Objekte als Instanzen einer Klasse durch Beziehungen wie Assoziationen Aggregation oder tempor re Botschaftswege gekoppelt sein k nnen Das Verhalten von Objekten wird ber die Methoden definiert die von Nachrichten an das Metriken und Portierungsaufwand Seite 127 Objekt ausgel st werden und man betrachtet daher die Methodenebene Um diese beiden Aspekte von objektorientierten Software Systemen zu ber cksichtigen werden f r die Teilma e Kopplungsmechanismus und Kommunikationsart bzw Datenkopplung folgende Vorschl ge f r die Verwendung objektorientierter Metriken unterbreitet Gemessen werden soll die Kopplung zwischen den Komponenten eines objektorientierten Software Systems und deren Kopplungsst rke Hierbei werden nur noch Aufrufe betrachtet womit eine entsprechende Gewichtung auf dieser Ma ebene entfallen kann und die Kopplungsst rke direkt aus der Anzahl aufgerufener Methoden bestimmbar ist Um bei objektorientierten Software Systemen die Anzahl von Systemkomponenten zu bestimmen die ber den vorgestellten Kopplungsmechanismus Aufruf in Verbindung stehen eignet sich die bereits vorgestellte RFC Metrik welche die Anzahl der Funktionen die durch Operationen einer Klasse aufgerufen werden intern und extern mi t Hierzu z hlen auch eingeerbte Methoden Um den Aspekt der Vererbung n
119. Bildschirm usw existieren Portierungsbarrieren im Bereich der unterschiedlichen Zeichendarstellungen Bei einem Drucker k nnen beispielsweise die maximale Zeilenl nge die Steuerzeichen oder die benutzten Zeichens tze differieren Auch bei der Bildschirmausgabe hat sich noch kein einheitlicher Standard etabliert der die zeichen zeilen oder sogar seitenweise Verarbeitung von Zeichenketten definiert Auch f hren unterschiedliche End of Line Konventionen oder verschiedene Steuerzeichen zu Portierungsproblemen 2 1 2 2 Systemsoftware Systemsoftware ist Software die f r eine spezielle Hardware oder eine Hardwarefamilie entwickelt wurde um den Betrieb und die Wartung der Hardware zu erm glichen bzw sie zu erleichtern Zur Systemsoftware z hlt man das Betriebssystem in der Regel aber auch Compiler Datenbanken Kommunikationsprogramme und spezielle Dienstprogramme In diesem Abschnitt sollen die Portierungsprobleme angesprochen werden die im Zusammenhang mit unterschiedlichen Compilern bzw Programmiersprachen und den darunterliegenden Betriebssystemen auftreten k nnen Portabilit t von Software Systemen Seite 22 Ein Betriebssystem l t sich aus zwei Perspektiven betrachten Zum einen ist es ein Software System welches die realen Eigenschaften der Hardware vor dem Benutzer bzw Programmierer versteckt und eine einfache Abstraktion auf hohem Niveau in Form von benannten Dateien und Schnittstellen f r die Programmierung liefert T
120. Bit Zeitalter eingeleitet Diese Windows Version wird sowohl f r 32 Bit x86 Systeme als auch f r Intels zuk nftige 64 Bit Prozessoren Itanium zur Verf gung stehen Hierbei wurde die technische Basis von Windows 9x ME und Windows 2000 vereinigt um so eine einheitliche Basis f r alle Windows Versionen zu schaffen Eine bersicht zur Historie von Windows zeigt Abbildung 5 WindowsXP 32 Bit x86 und 64 Bit Itanium e WindowsME 2000 Wie Windows9x Windows 2000 Wie WindowsNT A Windows98 Wie Windows95 Windows NT 4 0 1997 E Ken Server Windows95 Unterst tzung 16 32 Bit Prozessoren 2000 Windows Z 3 1 3 5 1993 Vorr 32 Bit Porzessoren Workstation Server z B 80386 80486 Pentium Windows f r Workgroups 199 Windows Y 1 1992 Mind 16 Bit 80286 und 1 MByte Hauptspeicher 1990 Windows 3 0 1990 16 Bit 80286 32 Bit 80386 Protected Mode Ca Windows 386 1988 32 Bit 80386 Virtual 86 Mode Windows 286 1988 80286 Real Mode Windows 2 0 1987 16 Bit 8086 8 16 Bit 8088 Prozessor Real Mode Windows 1 01 1985 IBM kompatible PC s 7 MS DOS 1981 IBM kompatible PC s 1980 Abbildung 5 bersicht zur Historie von Windows Portabilit t von Software Systemen Seite 39 2 2 2 Windows Konzepte und Strategien zur Windows Programmierung Die Windows Betriebssystem definiert sich durch eine Vielzahl unterschiedlicher Konzepte die bei der Programmierung zu ber cksichtigen sind
121. CTL System Das vierte und letzte Kapitel soll die Erkenntnisse der vorangegangenen Untersuchungen im Rahmen eines Reengineering Projekts auf ein 16 Bit Windows basiertes Software System anwenden Hierbei wird der Versuch unternommen den Aufwand zu ermitteln der im Falle einer geplanten Portierung auf die Win32 Plattform entsteht Portabilit t von Software Systemen Seite 15 2 Portabilit t von Software Systemen Dieses Kapitel dient der Einf hrung in die Thematik der Portabilit t von Software Systemen Zun chst wird anhand von Definitionen versucht einen allgemeinen Sprachgebrauch f r die Arbeit zu finden Es werden allgemein Probleme behandelt die bei der Portierung von Software Systemen auftreten k nnen und welche Werkzeuge den Proze der Portierung unterst tzen Danach wird im Speziellen die Portierung von Windows basierten Software Systemen behandelt Hierbei werden die Probleme einer Windows basierten Portierung aufgezeigt und klassifiziert Es werden u a Werkzeuge vorgestellt die eine Analyse der Quellen von Software Systemen im Hinblick auf die vorgestellten Portierungsprobleme vornehmen 2 1 Portabilit t im Allgemeinen Um korrekte und effiziente Software zu produzieren sind gro e Anstrengungen erforderlich Arbeitet ein Programm in einer bestimmten Umgebung m chte man den ganzen Aufwand bei einem Wechsel des Compilers des Prozessors oder des Betriebssystems nicht wiederholen Im Idealfall sollten hierbei berha
122. Clear ProfClear Profiling API gestrichen siehe Tools Dokumentation GDI ProfFinish ProfFinish Profiling API gestrichen siehe Tools Dokumentation GD ProfFlush ProfFlush Profiling API gestrichen siehe Tools Dokumentation GDI ProflnsChk ProflnsChk Profiling API gestrichen siehe Tools Dokumentation GDI ProfSampRate ProfSampRate Profiling API gestrichen siehe Tools Dokumentation GDI ProfSetup ProfSetup Profiling API gestrichen siehe Tools Dokumentation GD ProfStart ProfStart Profiling API gestrichen siehe Tools Dokumentation GDI ProfStop ProfStop Profiling API gestrichen siehe Tools Dokumentation GDI QuerySendMessage QuerySendMessage Kein Win32 Aequivalent MBE ReadComm ReadComm COMM Funktionen auf File 1 O gemappt DOS Ersetzen durch ReadFile RemoveFontResource RemoveFontResource Nur Dateinamen String keine Handles verwenden GDI ScaleViewportExt ScaleViewportExt Kein Win32 Aequivalent GDI Ersetzen durch portable ScaleViewportExtEx ScaleWindowExt ScaleWindowExt Kein Win32 Aequivalent GDI Ersetzen durch portable ScaleWindowExtEx SetActiveWindow SetActiveWindow GDI Lokalen Eingabestatus beruecksichtigen SetBitmapDimension SetBitmapDimension Kein Win32 Aequivalent GDI Ersetzen durch portable SetBitmapDimensionEx SetBrushOrg SetBrushOrg Kein Win32 Aequivalent GDI Ersetzen durch portable SetBrushOrgEx SetCapture SetCapture GDI Lokalen Eingabestatus beruecksichtigen SetClassWord SetClassWord Verbr
123. ClsExtra 0 M_main cpp 274 CountersDLLInstance GetModuleHandle counters dll M_main cpp 369 NewWindow TCounterWindow mea TCounterWindow LOWORD IParam M_main cpp 499 HWND hChildWnd HWND LOWORD SendMessage Main hWndClient WM_ DoCommandsFrame HWND M_main cpp 664 LPLONG data mGetMoveScan M_main cpp 746 window gt LoadOldData LOWORD IParam M_main cpp 991 LRESULT CALLBACK _export FrameWndProc HWND M_main cpp 991 LRESULT CALLBACK _export FrameWndProc HWND M_main cpp 998 char buf MaxString M_main cpp 1127 PostMessage HWND LOWORD IParam WM_COMMAND cm_Index 0 M_main cpp 1146 LRESULT CALLBACK _export WndProc HWND M_main cpp 1161 SetWindowLong hWindow 1 DWORD window M_main cpp 1715 LONG LPMDICREATESTRUCT amp mdiCreate M_main cpp 1762 wndClass gt cbWndExtra 8 M_main cpp 1771 wndClass gt lpfnWndProc WndProc M_main cpp 1056 if 1 lt GetModuleUsage hMDLL M_main cpp 1083 bShutdown TRUE if 2 lt GetModuleUsage hMDLL M_main cpp 259 hMDLL GetModuleHandle motors dll M_motcom h 106 WORD wPositionMinWidth M_motcom h 107 WORD wPositionMaxWidth M_motcom h 112 WORD wPositionWidth M_motcom h 133 DWORD dwRemoveLimit M_motcom h 137 DWORD dwHysteresis M_motcom h 156 DWORD dwinterval M_motcom h 204 typedef TMList FAR LPMList M_motcom h 205 typedef TMotor FAR LPMotor M_motcom h 141 143DWORD dwVelocity m_mothw h 134 WORD wBaseAddr m_m
124. Counters cpp 1294 _asm mov dx base add dx 6 Counters cpp 1303 _asm mov dx base add dx 4 Counters cpp 1327 asm init PSD interface mov dx base add dx 4 Counters cpp 1337 _asm start PSD interface with clearing memory mov dx base add dx 4 Counters cpp 1365 asm stop PSD interface mov dx base Counters cpp 1375 asm start PSD interface with clearing memory mov dx base Counters cpp 1392 KOMP TStoe_Psd Anz PGA 7 _asm si di retten push di push si A initiate data transfer mov dx 0x304 PC TAm9513a DigitalOut unsigned_char TAm9513a Digitalln unsigned_char_ TAm9513a ReadStatus TAm9513a WriteCmd unsigned_char TAm9513a WriteData unsigned_short TAm9513a WriteData unsigned_short TAm9513a ReadData TAm9513a ReadData TBraun_Psd LoadHexFile TC_812ISA TC_812ISA TC_812ISA TC_812ISA TC_832 LimitWatch unsigned_int unsigned_int unsigned_long u TC_832 IsLimitHit TC_832 IsLimitHit TC_832 CheckBoardOk TC_832 Drive628 unsigned_char unsigned_short long TStoe_Psd Psdlnit TStoe_Psd Psdlnit TStoe_Psd PsdStart TStoe_Psd PsdStart TStoe_Psd PsdStop TStoe_Psd PsdStop TStoe_Psd PsdRead int int int unsigned_short_ Anhang F Daten der Quelltextanalyse Seite 227 C_layer cpp Kisl1 c Kisl1 c Kmpt1 c Kmpt1 c Kmpt1 c Kmpt1 c Kmpt1 c Kmpt1 c Motors cpp Motors cpp Motors cpp Motors cpp Motors cpp 12
125. Counters cpp 705 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp 708 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld KOMP TEncoder Anz BIBA 3 M_dlg cpp 182 SetFocus GetDlgltem hwnd id_CommandLine TExecuteCmd TDevice TDevice TDevice TDevice TDevice TDC_Drive Initialize EventHandler unsigned_int unsigned_int unsigned_lon EventHandler unsigned_int unsigned_int unsigned_lon InitializeEvent HWND___ int TDevice PollDevice PollDevice PollDevice PollDevice TDevice UpdateDisplay TDList InitializeModule TEditWindow SetFocus TEditWindow SetFocus TEditWindow SetFocus TEncoder PollDevice TEncoder PollDevice TEncoder PollDevice Dig_Onlnit HWND_ HWND___ long M_dlg cpp 213 SetFocus GetDlgltem hwnd id_CommandLine TExecuteCmd Dlg_OnInit HWND___ HWND___ long KOMP TExecuteCmd Anz BIBA 2 Counters cpp 624 if IDYES MessageBox GetFocus Time 0 0 n Neustart Generic Device MBASK Counters cpp 633 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp 637 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld KOMP TGenericDevice Anz BIBA 3 M_steerg cpp 2634 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage M_steerg cpp 2668 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 M_steerg cpp 2669 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0 M_steerg cpp 26
126. DIPLOMARBEIT zur Erlangung des akademischen Titels Diplom Informatiker Metriken zur Portabilit tsanalyse Windows basierter Software Systeme von Michael M ller M rz 2002 Betreuer Prof Dr Klaus Bothe Institut f r Informatik Math Naturwiss Fakult t II Lehrstuhl f r Softwaretechnik Rudower Chaussee 25 Humboldt Universit t zu Berlin Selbstst ndigkeitserkl rung Hiermit erkl re ich Herr Michael M ller die vorliegende Diplomarbeit zum Thema Metriken zur Portabilit tsanalyse Windows basierter Software Systeme selbst ndig und ausschlie lich unter Verwendung der im Quellenverzeichnis aufgef hrten Literatur und sonstigen Informationsquellen verfa t zu haben Berlin am 28 3 2002 Unterschrift Michael M ller Einverst ndniserkl rung Hiermit erkl re ich mein Einverst ndnis mit der ffentlichen Ausstellung meiner Diplomarbeit in der Bibliothek des Instituts f r Informatik Berlin am 28 3 2002 Unterschrift Michael M ller Inhaltsverzeichnis Seite 5 Inhaltsverzeichnis Abbildungsverzeichnis 000s000000000ssesnnssssnnssnonnennnssusnnnsnsnnnsnnnnssnnnsssnnnsnnnnssnnssssnnnsnsnnnsnnnsssnnssnnnsnnnsnnne 9 Tabellenverzeichnis 0s020u0000ssoossonssonssonssonssnnssnnssnnssonnsnnnsnnnsnansssnnssnssnnnssnnssnnssnnssnnssnnnsnnnsnnnssanssnn 11 Vu UEL TU seinen insalensasctisntesinebessisehnnhesnsuhhe reesste ukenne 13 2 Portabilit t von Software Systemen sssusssossesn
127. DWORD int int int int CALLTYPE getinf int int int double DWORD int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR int CALLBACK WEP int BOOL WINAPI _export InitializeLineScanModule HWND hewnd BOOL WINAPI _export AquireOptimalExTime void BOOL WINAPI _export SetLineScanParameters void BOOL _export WINAPI GetScanRanges TFrameDimension fd BOOL _export WINAPI SetlmageSaveOptions void BOOL _export WINAPI GetHistogram LPWORD IpHist int len BOOL _export WINAPI GetHistogram LPWORD IpHist int len BOOL _ export WINAPI InitializeAxis int _LPSTR int BOOL WINAPI _export InitializeTask TScannerTask task BOOL WINAPI _ export ExecuteNextSubTask TScannerTask task Drive628c unsigned_char unsigned_short long unsigned_short u GetWord unsigned_short unsigned_short GetDWord unsigned_short unsigned_short PutWord int unsigned_short unsigned_short PutDWord long unsigned_short unsigned_short LM628Ready unsigned_short Drive628c unsigned_char unsigned_short long unsigned_short u GetDWord unsigned_short unsigned_short PutWord int unsigned_short unsigned_short PutWPutDWord long unsigned_short unsigned_short LM628Ready unsigned_short setprm int int unsigned_short unsigned_short int double unsi getinf int int int double_ unsigned_long_ LibMain HINSTANCE___ unsigned_short unsigned_short char_ WEP int Anhang F Daten der Quelltextanalyse Seite 225 St_layer cpp 134 BOOL WINAPI _export ReadOutCCD int fkt St
128. D___ HWND___ long KOMP TSetupStepScan Anz BIBA 6 M_steerg cpp 701 MessageBox GetFocus Start Scan failed Steering MBSTOP TShowValueCmd TShowValueCmd TCmdTag M_steerg cpp 707 MessageBox GetFocus Start Scan Fehler MBSTOP TShowValueCmd TShowValueCmd TCmdTag M_steerg cpp 1795 MessageBox GetFocus Das laufende Macro erst unterbrechen Meldung MBINFO TShowValueCmd TShowValueCmd TCmdTag KOMP TShowValueCmd Anz BIBA 3 M_steerg cpp 1812 MessageBox GetFocus Makroausfthrung ist fehlgeschlagen Steuerung TSteering ExecuteNextCmd M_steerg cpp 2431 MessageBox GetFocus Makrodatei fehlt fn MBSTOP TSteering LoadMacro char_ char_ M_steerg cpp 2472 MessageBox GetFocus Kommandoliste unvollstaendig makname MBSTOP TSteering LoadMacro char_ char_ M_steerg cpp 2490 MessageBox GetFocus Makro ohne Kommandos makname MBSTOP TSteering LoadMacro char_ char_ M_steerg cpp 2526 MessageBox GetFocus Makro fehlt makname MBSTOP TSteering LoadMacro char_ char_ Anhang F Daten der Quelltextanalyse Seite 208 M_steerg cpp 1859 PostMessage hHostWindow WM_COMMAND cm_SteeringReady 0l M_steerg cpp 1870 PostMessage hHostWindow WM_COMMAND cm_SteeringReady 0l M_steerg cpp 2336 MessageBox GetFocus buf Macro einlesen MBINFO M_steerg cpp 1377 MessageBox GetFocus Kein AreaScan Fenster offen Fehler MBSTOP KOMP TSteering Anz BIBA 9 Cou
129. Detektoren RADICON SCSCS Scintillation Counter Single Channel Spectrometer Portabilit tsanalyse am Beispiel des XCTL Systems Seite 135 Sogenannter Szintillationsdetektor mit eigener Schnittstellenkarte im PC und einem 32 Bit Z hler Kanal russ SCSCS Scintillation Counter Single Channel Spectrometer Szintillationsdetektor ohne eigene Schnittstellenkarte AXIOM AX5216 Schnittstellenkarte im PC F nf 16 Bit Z hler integriert auf einem IC Am9513 Sinnvoll einsetzbar bei Messungen mit 0 dim Detektoren wird bspw f r den russ SCSCS benutzt dimensionale Detektoren Braun PSD Position Sensitive Detector der Firma Braun besitzt eigene Schnittstellenkarte im PC Stoe PSD PSD der Firma Stoe Einzeiliger CCD CCD Charge Couple Device Ladungsgekoppeltes Ger t Schnittstellenkarte im PC Halbleiterdetektor 2 dimensionale Detektoren CCD von Proscan Schnittstellenkarte im PC Neues Ger t noch keine Details CCD Eigenbau nur offline keine Schnittstellenkarte und geringere Aufl sung als CCD von Proscan PC Z hlerkarte Detektor Motorcontroller 4 Kan le C 812 gt Probenhalter und Kallimatorantriebe Motorcontroller 2 Kan le C 832 XCTL System Software Abbildung 24 Me platzschema mit Arbeitsplatz PC und Peripherie 4 2 Anwendung des Portabilit tsma es auf das XCTL System In diesem Abschnitt geht es um
130. Focus void TCounterWindow SetFocus KOMP TCounterWindow Anz BIBA 2 M_curve cpp 143 GlobalCompact MaxMemldx sizeof CPoint TCurve TCurve int M_curve cpp 151 MessageBox GetFocus Kein Speicher TCurve Fehler MB_OK MB_ICONSTOP TCurve TCurve int Anhang F Daten der Quelltextanalyse Seite 205 KOMP TCurve Anz BIBA 2 Motors cpp 2158 MessageBox GetFocus buf szMsgFailure MBSTOP KOMP TDC_Drive Anz BIBA 1 Counters cpp352 PostMessage hEventControlWnd WM_COMMAND cm_SteeringReady 0l Counters cpp356 PostMessage hEventControlWnd WM_COMMAND cm_CounterSet nCalledEvents Counters cpp370 MessageBox GetFocus Me zeit wurde zu klein gew hlt InitializeEvent MBINFO TDevice Counters cpp 1044 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp 1047 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld Counters cpp484 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp487 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld Counters cpp383 FORWARD_WM_COMMAND hDisplayWnd cm_CounterSet 0 0 SendMessage KOMP TDevice Anz BIBA 8 Counters cpp 171 MessageBox GetFocus buf Device Fehler MBSTOP KOMP TDList Anz BIBA 1 M_steerg cpp 2835 void TEditWindow SetFocus M_steerg cpp 2837 SetFocus M_steerg h 583 void SetFocus void KOMP TEditWindow Anz BIBA 3 Counters cpp 700 MessageBox GetFocus Encoder fehlt Fehler MBINFO
131. FormatDBaseToBitmapSource M_data cpp 783 MessageBox GetFocus Cannot create memory object 2 Message MBINFO TBitmapSource GenerateAngleSpaceBitmap int int int unsigned M_data cpp 1035 MessageBox GetFocus Cannot create memory object 2 Message MBINFO TBitmapSource GenerateRL Bitmap M_data cpp 600 MessageBox GetFocus Screen 1 Message MBINFO TBitmapSource SetScreen HDC___ TScreen_ amp KOMP TBitmapSource Anz BIBA 5 BraunPSD cpp 242 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd TBraun_Psd BraunPSD cpp 472 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd Psdlnit BraunPSD cpp 353 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 453 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd PsdReadOut THowReadOutPsd BraunPSD cpp 505 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd PsdStart BraunPSD cpp 576 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd PsdStop BraunPSD cpp 281 MessageBox GetFocus Kein g ltiger Typ TPsdDataType MBINFO TBraun_Psd SetDataType TPsdDataType BraunPSD cpp 544 MessageBox GetFocus TBraunError nErrorCode 0 HeadLine MBINFO TBraun_Psd SetEnergyRange unsigned_int unsigned_int KOMP TBraun_ Psd Anz BIBA 8 Motors cpp 2
132. Indicator LP TC_832 LimitWatch unsigned_int unsigned_int unsigned_long u Motors cpp 3487 PostMessage GetFrameHandle WM_COMMAND cm_LimitHitOccure LPARAM TC_832 LimitWatch unsigned_int unsigned_int unsigned_long u KOMP TC_832 Anz BIBA 2 M_arscan cpp 2902 MessageBox GetFocus Vorgang bitte wiederholen szMsgFailure MBINFO TCalibrate Dlg_ OnCommand HWND___ int HWND___ unsigned_int M_arscan cpp 2941 MessageBox GetFocus Vorgang bitte wiederholen Fehler MBINFO TCalibrate Dlg_ OnCommand HWND___ int HWND___ unsigned_int Motors cpp 610 if IDYES MessageBox GetFocus buf Meldung MBASK TCalibrate DIg_OnCommand HWND___ int HWND___ unsigned_int Motors cpp 652 FORWARD_WM_COMMAND hwnd IDCANCEL hwndCtl 0 PostMessage TCalibrate DIig_OnCommand HWND___ int HWND___ unsigned_int Motors cpp 731 FORWARD_WM_COMMAND hwnd IDCANCEL hwndCtl 0 PostMessage TCalibrate DIig_OnCommand HWND___ int HWND___ unsigned_int KOMP TCalibrate Anz BIBA 5 M_arscan cpp 2857 SetFocus hBar TCalibratePsd Dlg_OnCommand HWND___ int HWND___ unsigned M_arscan cpp 2968 SetFocus hBar TCalibratePsd Dlg_OnCommand HWND___ int HWND___ unsigned M_arscan cpp 2983 SetFocus hBar TCalibratePsd DIlg_OnCommand HWND___ int HWND___ unsigned M_arscan cpp 3015 mMoveToDistance atof buf TCalibratePsd Dlg_OnCommand HWND___ int HWND___ unsigned M_arscan cpp 3021 SetFocus hBar TCalibratePsd Dlg_OnCommand HWND___ int HWND
133. K sr DOK pp DOK y Formal Metriken und Portierungsaufwand Seite 119 DOK g DOE g DOK pp 23 DOK jy mit g 2 g Gewichtungsfaktoren der einzelnen Teile der Dokumentation Hypothese 3 DOK 0 15 DOK 0 6 DOK py 0 25 DOK yy wobei gilt Y g 1 i l Aufbau Teilma Standarddokumentation DOK sp Standarddokumentation Benutzerdokumentation BD Implementierungsdokumentation Technische Dokumentation ID TD Designdokumentation DD Formal 4 DOK sp 8 DD 2 ID g BD g TD wobei gilt gt g i l Hypothese DOK 0 25 DD 0 25 BD 0 25 TD 0 25 ID Designdokumentation DD Designdokumentation vorhanden nicht vorhanden Implementierungsdokumentation ID Implementierungsdokumentation vorhanden nicht vorhanden Benutzerdokumentation BD Benutzerdokumentation vorhanden nicht vorhanden Technische Dokumentation TD Technische Dokumentation vorhanden nicht vorhanden Metriken und Portierungsaufwand Seite 120 Aufbau Teilma Portierungsdokumentation DOK py Portierungsdokumentation INS TDA Installationsdokumentation Testdaten Angabe Portierungsschritte Annahme Zielrechner Angabe hardwareabh ngiger Komponenten Begriffskl rung PS AZ HK VB Formal DOK 8 INS g TDA wobei gilt g g 1 Hypothese DOK pp 0 6 INS 0 4 TDA Installationsdokumentation 4 INS g PS g AZ g HK g VB wobei gilt Y g 1 i l Hypothese
134. KOMP i te betroffene Komponente des Programms i 1 n UTA anzupassender Aufruf einer UT Routine Verh ltnis Gesamtkomponenten zur Anzahl anzupassender Komponenten UTM Anzahl aller Komponentenmit UT Anpassungen i Anzahl aller Komponenten i Metriken und Portierungsaufwand Seite 113 Aufbau Teilma Hardware Umgebung HU Hardware Um EN Maschiner archi 6 MAM PGM AN Anzahl Architektur Aufru fe Anzahl Peripherie Aufrufe d Einarbeit fwand Einarbeit fwand gt MAM inarbeitungsaufwan PGM inarbei ungsau an S Verh ltnis Gesamtkomponenten zur Verh ltnis Gesamtkomponenten zur MAM 3 Anzahl anzupassender Komponenten P GM 3 Anzahl anzupassender Komponenten Formal HU PAN y KOMP VKG mit PAN y MAM PGM Anzahl der potentiellen Anpassungen von Zugriffen auf die Hardware Umgebung KOMP u MAM PGM Namen der Komponenten mit Zugriffen auf die Hardware Umgebung und deren Anzahl VKG u MAM PGM Verh ltnis der Komponentenzahl aus KOMP y zur Gesamtzahl der Programmkomponenten Maschinenarchitektur MA MAM MAM MAM Anzahl Architektur Aufrufe MAM Anz MA Anz MA mit MA i ter unterschiedlicher MA Zugriff i 1 n Einarbeitungsaufwand MAM KOMP Anz MAA KOMP Anz MAA mit KOMP i te betroffene Komponente des Programms 1 n MAA anzupassender MA Zugriff n Verh ltnis Gesamtkomponenten zur Anzahl anzupassender Komponenten
135. Kategorie zuordnen lassen Aus diesem Grund werden alle identifizierten Portierungsprobleme im betrachteten Portierungsfeld zentral in einer Problembibliothek verwaltet und bei der sp teren Portierungsanalyse falls m glich einem der Problembereiche zugeordnet siehe Anhang B Linearer 32 Bit Adressraum 32 Bit Software Systeme laufen wie bereits an verschiedenen Stellen angesprochen im Vergleich zu 16 Bit Anwendungen in einem virtuellen linearen Adre raum Windows 9x benutzt wie Windows NT den virtuellen Speicher nach dem Prinzip des Demand Paging der auf einem flachen linearen Adre raum beruht Auf diesen Adre raum wird mit 32 Bit breiten Adressen zugegriffen Demand Paging bezeichnet hierbei eine Methode bei der Code und Daten seitenweise aus dem physischen Speicher in eine Datei auf der Festplatte ausgelagert werden Sobald ein Proze den Code und die Daten wiederben tigt werden die Seiten in den physischen Speicher verschoben Jeder Proze besitzt Portabilit t von Software Systemen Seite 58 einen eigenen virtuellen Adre raum von 4 GB Die oberen 2 GB dieses Adre raums stehen allen Anwendungen gemeinsam zur Verf gung die unteren 2 GB sind f r die jeweilige Anwendungen reserviert Dieser virtuelle Adre raum wird in gleich gro e Bl cke aufgeteilt die sogenannten Speicherseiten Die Speicherverwaltung bildet die virtuellen Adressen aus dem Adre raum eines Prozesses auf die physisch vorhandenen Speicherseiten des C
136. Keine FAR Pointer unter Win32 LA Ersetzen durch flat memory model Code SELECTOROF SELECTOROF Keine FAR Pointer unter Win32 LA Ersetzen durch flat memory model Code CUSTOM export export Keine export Aufrufkonvention unter Win32 SEP CALLBACK oder WINAPI benutzen far far Win32 kennt keine Segmente daher FAR NEAR Nichts LA FAR far Win32 kennt keine Segmente daher FAR NEAR Nichts LA huge huge huge Bereiche ueberfluessig LA HUGE huge huge Bereiche ueberfluessig LA near near Win32 kennt keine Segmente daher FAR NEAR Nichts LA NEAR near Win32 kennt keine Segmente daher FAR NEAR Nichts LA pascal pascal Keine pascal Aufrufkonvention unter Win32 LA CALLBACK oder WINAPI benutzen PASCAL pascal Keine pascal Aufrufkonvention unter Win32 LA CALLBACK oder WINAPI benutzen stress h STRESS H Stress Funktionen bis auf weiteres nicht verfuegbar DOK Durch entsprechendes Win32 API ersetzen oder streichen STRESS H STRESS H Stress Funktionen bis auf weiteres nicht verfuegbar DOK Durch entsprechendes Win32 API ersetzen oder streichen toolhelp h TOOLHELP H ToolHelper Funktionen bis auf weiteres nicht verfuegbar DOK Durch entsprechendes Win32 API ersetzen oder streichen TOOLHELP H TOOLHELP H ToolHelper Funktionen bis auf weiteres nicht verfuegbar DOK Durch entsprechendes Win32 API ersetzen oder streichen
137. MOSI 1990 Die Arbeiten an MOSI starteten in der Unix Komune zur gleichen Zeit wie POSIX Anfang der fr hen 80er Jahre POSIX wurde dann von der IEEE im Jahre 1985 bernommen und steht seitdem unter dessen Obhut was zu einer breiten Anerkennung dieses Standards f hrte und viele Unix Systeme aber auch Windows NT POSIX konforme Subsysteme anbieten Portable Betriebssysteme Wie oben bereits erw hnt ist die Schnittstelle zum Betriebssystem ein entscheidender Faktor f r die Portabilit t von Software Systemen Dies betrifft sowohl System als auch Anwendungssoftware Die oben vorgestellten Standards f r Betriebssystemschnittstellen bieten einen Weg diese Schnittstellen zu vereinheitlichen Eine andere Strategie verfolgt das Konzept der portablen Betriebssysteme Hierbei wird die einheitliche Schnittstelle durch das Betriebssystem selbst geschaffen indem es auf die jeweilige Zielumgebung portiert und somit die Verantwortung f r die Portabilit t von Software Systemen auf das zugrunde liegende Betriebssystem verlagert wird Ein Beispiel f r ein portables Betriebssystem ist Unix Hierbei werden maschinenabh ngige Funktionen in einzelnen Komponenten zusammengefa t die f r den Rest des Betriebssystems die Hardware Schnittstelle darstellen Hardwarenahe Funktionen Interrupts Systemaufrufe etc werden mittels Assemblerroutinen realisiert die zusammen mit einigen in C implementierten maschinennahen Funktionen z B Treiber den so
138. Main HINSTANCE___ unsigned_short unsigned_short char_ LibMain HINSTANCE___ unsigned_short unsigned_short char_ LibMain HINSTANCE____ unsigned_short unsigned_short char_ WEP int spGetVersion spGetlnstance AboutTheMaker GetCFile GetFrameHandle GetClientHandle GetMainInstance GetDataBasePtr InitializeSPLibrary TMainParameters_ ParsingXScanType char_ CreateDefaults Setinfo char_ Setinfo char_ SetStaticlnfo char_ PostMessage MainP hWndFrame MainP wm_DrawStatus 1000 LONG hAtom SetStaticInfo char_ void _export WINAPI SetStatus LPCSTR status_txt SetStatus char_ PostMessage MainP hWndFrame MainP wm_DrawStatus 1001 LONG hAtom SetStatus char_ BOOL _export WINAPI FileOpen LPCSTR HeadLine LPSTR szFilter LPSTR DWORD Errval Error value BOOL _export WINAPI FileSave LPCSTR HeadLine LPSTR szFilter LPSTR FileOpen char_ char_ char_ char_ FileOpen char_ char_ char_ char_ FileSave char_ char_ char_ char_ DWORD Errval Error value BOOL _export WINAPI SetFPOnData HFILE hfile int WINAPI _export GetBufferLine LPSTR src LPSTR dst int dstsize static WORD cnt_s int WINAPI _export GetFileLine int hFile LPSTR dst int dstsize TUnitType WINAPI _export UnitEnum LPSTR sz_unit LPSTR WINAPI _ export UnitStr TUnitType n_unit void WINAPI _export Delay long count void WINAPI _export DelayTime int MilliSec DWORD StartTime timeGetTime
139. NAPI for each function that has _export keyword change line Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 239 BOOL DIlEntryPoint HANDLE hModule DWORD dwFunction LPVOID to BOOL WINAPI D11Main HINSTANCE hModule DWORD dwFunction LPVOID comment out BWCCRegister line and after that line add hModuleInstance hModule motors cpp I eliminated word _export maybe it should be changed to __declspec d1lexport I also commented out lines with calls to inp and outp but under windows 95 only _inp and _outp can be used I changed some casts in this manner FARPROC gInitialize GetProcAddress hGPIBModule IEEE488_INITIALIZE to gInitialize TInitialize GetProcAddress hGPIBModule IEEE488_INITIALIZE Change FARPROC gSend GetProcAddress hGPIBModule IEEE488_SEND to gsend TSend GetProcAddress hGPIBModule IEEE488_SEND etc c_layer cpp remove include lt bwcc h gt in all other files also comment out pragma argsused disables unknown pragma warning in all other files also eliminate call BwccRegister hModule change _export to __declspec dllexport This should be placed in front of WINAPI or CALLBACK words the order is important here add extern C to FakeDevice and pTime declarations Add dummy initializer to pTime declaration because 32bit dlls behave differently during load you need to guard LibMain and WEP functions w
140. New York Van Nostrand Reinholt Company 1974 Orth 74 Orth B Einf hrung in die Theorie des Messens Stuttgart Verlag W Kohlhammer 1974 Peck 78 Peck J L Schrack G F The portability of quality software experiences with BCPL In Hibbard W G Schuman S A Hrsg Construction Ouality Software Proceedings ofthe IFIP Working Conference on Construction Quality Software Amsterdam New York Oxford North Holland Publishing Company 1978 Perlis 68 NATO Science Committee Software Engineering Concepts and Techniques Proceedings ofthe NATO Conferences Garmisch 1968 New York Petrocelli Charter 1976 Petzold 98 Petzold C Programming Windows 5th ed Microsoft Press 1998 Pivaldi 93 Pirvali B Portable Window Programming Graz Techn Univ Dipl Arb 1993 Poole 73 Poole P C Waite W M Portability and Adaptibility In Goos J Hartmanis J Advanced Course in Software Engineering Lecture Notes in Computer Science 30 Berlin Heidelberg New York Springer 1977 Richter 99 Richter J Programming Applications for Microsoft Windows 4th ed Microsoft Press 1999 Literaturverzeichnis Seite 186 Roth 87 Schmidt 87 Sch tzler 01 SHARE 68 Sibley 61 Soltendick 96 Soltendick 99 Soltendick 99a Soltendick 99b Soltendick 99c Stevens 81 Stroustrup 98 Swan 95 Tegarden 92 VMWare O1 Weiskamp 93 Xctl 01 Zuse 91 Zuse 98
141. O d OO P AJ oO hM OO oO PM Oh Oo oO P rd A d OM oh PM A OO OO OM JM oO P gt gt OO MM oO PM MM gt KW Loo N N TC_ 812GPIB TC_812ISA f P CA N N TCalibrate TCalibratePsd 3 TChooseDeviceCmd TCommonDevParam TCounterShowParam _ TCounterWindow j TCurve TDC_Drive e TDevice TDList y TEditWindow 5 TEncoder TExecuteCmd 3 TGenericDevice TMacroExecute Y S D a N TMDIWindow TMList TModalDlg TModelessDlg Q O S ERS TMotorParam TOptimizeDC_812 TPlotData TPosControl 4 D Co Q TPsdRemoteSync TRadicon ch _ xw a O O O O O O O OO O O O OU WS WS OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU OU e OU OU OU OU ee Se OU a TScanCmd Portabilit tsanalyse am Beispiel des XCTL Systems Seite 175 Das Ma f r die Systemumgebung SYS ist ein Ma das konkrete Aufwandsdaten liefern kann Im Falle des XCTL Systems liegen noch keine Portierungserfahrungen vor soda hier nur die Anzahl potentieller Anpassungen in das Ma einflie en Die ermittelten Daten geben einen ersten berblick ber die eventuell anstehende Portierungsarbeit Es h ngt hierbei jeweils von den Erfahrungen des Porteurs ab der die Daten interpretiert wie aufschlu reich die Daten f r ihn sind Das erste f r
142. P TAdjustmentWindow Anz MAA 3 Am9513 cpp 33 WORD wValue TAdjustmentWindow rButtonDown long TAdjustmentWindow rButtonDown long TAdjustmentWindow rButtonDown long TAm9513a SplitNumber unsigned_long unsigned_short_ amp unsigne Anhang F Daten der Quelltextanalyse Seite 214 Am9513 cpp 72 DWORD dwData 0 Am9513 cpp 76 int TAm9513a IOCTL TIOCCmd cmd DWORDA param Am9513 cpp 78 WORD regH regL Am9513 cpp 79 WORD wValue Am9513 cpp 85 param DWORD double param fTimeCorrection Am9513 cpp 91 param DWORD wLowTicks wHighTicks Am9513 cpp 92 param DWORD double param fTimeCorrection Am9513 cpp 97 param DWORD wLowCounts wHighCounts Am9513 cpp 158 param DWORD wHighTicks regH DWORD wLowTicks Am9513 cpp 159 param DWORD wLowTicks regL Am9513 cpp 160 param DWORD double param fTimeCorrection Am9513 cpp 175 param DWORD wHighCounts regH DWORD wLowCounts Am9513 cpp 176 param DWORD wLowCounts reg Am9513 cpp 181 WriteData WORD param Am9513 cpp 218 BOOL TAm9513a SplitNumber DWORD value WORD amp low WORD amp high Am9513 cpp 220 LONG fi f2 f fail Am9513 cpp 227 low WORD value Am9513 cpp 263 high WORD f1 Am9513 cpp 264 low WORD f2 Am9513 cpp 270 high WORD f2 Am9513 cpp 271 low WORD f1 Am9513 cpp 278 DWORD TAm9513a GetTicksPerSecond void Am9513 cpp 299WORD value Am9513 cpp 395 WORD TAm9513a ReadStatus void
143. PAN py KOMP VKG yy PS KAps PApssSAps BAps sPS5 bzw PS KAps_ars dee ve Be oe BAps_ces PS2 Das Gesamtma System Umgebung setzt sich wie folgt zusammen Portabilit tsanalyse am Beispiel des XCTL Systems Seite 155 SYS LK dee PAsys SAsys gt BAsys PAN sys KOMP ys VKG sys VSG5ys mit KAgys KAgs KAps ces Namen der BS Routinen und der PS Konstrukte die nicht angepa t werden k nnen SYS PAys f PA se Anzahl und Namen der BS Routinen und PS Konstrukte ber die w hrend der Messung keine Informationen vorliegen SA sys AA SAps Ges Gesamtzahl aus Aufrufen von SU Routinen und PS Konstrukten PA die anpa bar sind f r die aber keine Aufwandswerte vorliegen BAgys BAsy BAps ces Summe aus bewerteten SU Routinen und PS Konstrukten f r die ein Aufwand vorliegt PAN ys PAN sy PAN py Summer der potentiellen Anpassungen aus Software und Hardware Umgebung KOMPsys KOMP KOMP Namen der Komponenten mit Anpassungen an die Software und Hardware Umgebung und deren Anzahl VKG ys VKG su VKG py Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten VSG ze PS Verh ltnis aus der Anzahl der zu ndernden Statements zur Gesamtzahl der Statements Damit ergibt sich f r das XCTL System folgendes Ma f r die System Umgebung wobei die einzelnen Ma e automatisch berechnet werden k nnen da sie auf bereits ermittelte Me werte zur ckgreife
144. PINT 46 typedef int WINAPI TEnter LPSTR WORD LPWORD int LPINT 47 ypedef int WINAPI TTransmit LPSTR WORD LPINT 48 ypedef int WINAPI TReceive LPSTR WORD LPWORD LPINT 51 typedef void WINAPI TSetPort int WORD 52 typedef void WINAPI TSetTimeout WORD 69 void far pascal ieee488_protcheck int 69 void far pascal ieee488_protcheck int 13 39 void far pascal ieee488_ initialize int int 13 39 void far pascal ieee488_ initialize int int DialogProc HWND___ unsigned_int unsigned_int long ModelessProc HWND___ unsigned_int unsigned_int long DialogProc HWND___ unsigned_int unsigned_int long ModelessProc HWND___ unsigned_int unsigned_int long Anhang F Daten der Quelltextanalyse Seite 221 leee h 75 82 Kmpt1 c 681 L_layer cpp 27 L_layer cpp 42 L_layer cpp 42 L_layer cpp 42 L_layer cpp 42 L_layer cpp 53 L_layer cpp 60 L_layer cpp 65 L_layer cpp 87 L_layer cpp 129 L_layer cpp 134 L_layer cpp 139 L_layer cpp 144 L_layer cpp 149 L_layer cpp 155 L_layer cpp 162 L_layer cpp 174 L_layer cpp 179 L_layer cpp 185 L_layer cpp 188 L_layer cpp 194 L_layer cpp 198 L_layer cpp 204 L_layer cpp 207 L_layer cpp 210 L_layer cpp 258 L_layer cpp 261 L_layer cpp 311 L_layer cpp 364 L_layer cpp 367 L_layer cpp 402 L_layer cpp 443 L_layer cpp 459 L_layer cpp 472 L_layer cpp 483 L_layer cpp 485 L_layer cpp 491 L_layer cpp 495 L_layer cpp 499 L_layer cpp 503 L_layer cpp 515 L_la
145. Port WORD nBaseAddr 3 TBraun_Psd BuildOperation unsigned_char_ unsigned_char_ i BraunPSD cpp 629 pfnSetPort WORD nBaseAddr 1 0x00 TBraun_Psd ResetDelayTime BraunPSD cpp 646 while IpfnGetPort WORD nBaseAddr 1 gt Bit7 TBraun_Psd Look_till_BaseAddr1 int BraunPSD cpp 667 pfnSetPort WORD nBaseAddr 0x3A TBraun_Psd SynchronHexFile unsigned_char_ amp unsigned_char_ amp BraunPSD cpp 669 pfnGetPort WORD nBaseAddr 3 TBraun_Psd SynchronHexFile unsigned_char_ amp unsigned_char_ amp BraunPSD cpp670 R_String IpfnGetPort WORD nBaseAddr 2 TBraun_Psd SynchronHexFile unsigned_char_ amp unsigned_char_ amp BraunPSD cpp 758 pfnSetPort WORD nBaseAddr zeichen TBraun_Psd LoadHexFile BraunPSD cpp 765 pfnGetPort WORD nBaseAddr 3 TBraun_Psd LoadHexFile BraunPSD cpp 766 ReadString i 1 IpfnGetPort WORD nBaseAddr 2 TBraun_Psd LoadHexFile BraunPSD cpp 336 338 Words UINT IpfnGetData WORD TBraun_Psd PsdReadOut THowReadOutPsd KOMP Braun Psd Anz MAA 39 m_mothw h 98 WORD GetStatus void TC_812 GetStatus Motors cpp 2292 wStaticGain WORD GetPrivateProfilelnt Ident Gain 100 GetCFile TC_812 TC_812 Motors cpp 2293 wDynamicGain WORD GetPrivateProfilelnt Ident DynamicGain 37 GetCFile TC_812 TC_812 Motors cpp 2296 wTorque WORD GetPrivateProfilelnt Ident Torque 110 GetCFile TC_812 TC_812 Anhang F Daten der Quelltextanalyse Seite 216
146. Portierungsfelds statt Der Ausgangspunkt hierbei ist ein funktionierendes Software System in einer bestimmten Systemumgebung Die Zielsetzung besteht in der Portierung dieses Software Systems in seine zuvor bestimmte Zielumgebung Hierbei k nnen unterschiedliche Strategien und Werkzeuge zur Zielerreichung genutzt werden In diesem Kapitel sollen deshalb zun chst m gliche Ausgangspunkte und Zielsetzungen n her eingegrenzt und m gliche Strategien beleuchtet werden Dar ber hinaus werden Werkzeuge identifiziert die den Portierungsproze unterst tzen jedoch nicht automatisieren 2 2 4 1 Ausgangspunkt und Zielsetzung F r ein Portierungsprojekt und deren Planung mu zun chst der Ausgangspunkt d h die Beschaffenheit der Quellen des zu portierenden Software Systems und die Systemumgebung von der aus portiert werden soll eindeutig bestimmt werden Windows basierte Software Systeme k nnen unter Win16 allgemein vier verschiedenen Varianten bzw deren Mischformen zugeordnet werden Software Systeme die noch unter Windows 2 x laufen Real Mode und nicht an Windows 3 x angepa t wurden Software Systeme die unter Windows 3 0 im Protected Mode arbeiten und nicht auf die erweiterte API von Windows 3 1 umgestellt wurden solche Software Systeme die unter Windows 3 1 laufen zus tzlich ohne ernste Warnmeldungen des Compilers mit dessen STRICT Option compiliert sind und dar ber hinaus ANSI C bzw C kompatibel sind Liege
147. RD_WM_COMMAND hwnd cm_MoveButton 0 0 SendMessage mMoveToDistance mGetValue MinDistance SetFocus BarHandle FORWARD_WM_COMMAND hwnd cm_MoveButton 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_MoveButton 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_Motorl nit 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 PostMessage FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 SendMessage SendMessage hwnd WM_COMMAND cm_ParamSet 0 SendMessage hwnd WM_COMMAND cm_Motorlnit 0 SetFocus GetDlgltem hwnd id_SpeedValue SetFocus BarHandle TAm9513a SelectChip unsigned_char TAngleCon TAngleControl TAngleCon TAngleCon TAngleCon TAngleCon TAngleCon TAngleCon TAngleCon TAngleControl TAngleControl TAngleControl TAngleCon TAngleControl TAngleCon TAngleControl TAngleCon TAngleControl TAngleCon TAngleControl TAngleControl TAngleCon TAngleControl TAngleCon TAngleCon rol ro rol ror TO ror rol FOr ror TO ror
148. Radicon EventHandler UINT UINT DWORD KOMP TRadicon Anz MAA 10 TRadicon EventHandler unsigned_int unsigned_int unsigned_lo TRadicon EventHandler unsigned_int unsigned_int unsigned_lo M_main cpp 1598 AppendMenu hTheMenu MF_POPUP WORD hmPL1 LPSTR amp Help TScan TScan M_scan cpp 1085 void TScan rButtonDown LONG Param TScan rButtonDown long M_scan cpp 1094 pp x LOWORD IParam TScan rButtonDown long M_scan cpp 1095 pp y HIWORD IParam TScan rButtonDown long KOMP TScan Anz MAA 4 M_steerg cpp 325 DWORD ocounts counts KOMP TScanCmd Anz MAA 1 M_scan cpp 1495 switch HIWORD IParam X M_scan cpp 1498 sprintf buf Es ist ein Fehler aufgetreten d LOWORD IParam KOMP TSetupContinuousScan Anz MAA 2 Counters cpp 1143 hReadBuf GlobalAlloc GHND GetChannelNumber 1 sizeof DWORD Counters cpp 1218 LPDWORD IpdwCountBuf Counters cpp 1219 LPWORD IpwReadBuf Counters cpp 1221 IpdwCountBuf LPDWORD GIobalLock hCountBuf Counters cpp 1222 IpwReadBuf LPWORD GlobalLock hReadBuf Counters cpp 1392 int TStoe_Psd PsdRead int FirstCh int LastCh int blsLong LPWORD buf Counters cpp 1503 int TStoe_Psd PsdRead int int int _LPWORD KOMP TStoe_Psd Anz MAA 7 Am9513 h 40 86 const WORD CB_UP 3 aufw rts z hlen C_8x2 inc 0 extern C WORD FAR PASCAL __D000h void C_8x2 inc 1 extern C WORD FAR PASCAL __D000h void C_layer cpp 35 static DWORD expcounts C_la
149. RenderDIB Anzahl GROUP GROUP Ergebnis DOS 21 Gesamtergebnis 21 BSM Anz BSR Anz BSR 3 BSM KOMP Anz BSA KOMP Anz BSA TAreaScan 1 TBitmapSource 2 BSM Anzahl aller Komponentenmit BS Anpassungen 7 2 0 025 Anzahl aller Komponenten BS BSM BSM BSM 3 TAreaScan 1 TBitmapSource 2 0 025 F 1 2 Ermittlung der Ma komponente Bibliotheksroutinen Aufrufe zum Ma BIB siehe Kapitel 4 2 1 1 BSR DialogProc Anz BSR 4 BSR FreeModule Anz BSR 2 BSR FreeProcInstance Anz BSR 1 BSR FreeResource Anz BSR 1 BSR GetFocus Anz BSR 112 BSR GetModuleUsage Anz BSR 1 BSR GlobalCompact Anz BSR 3 BSR MakeProcInstance Anz BSR 2 Anhang F Daten der Quelltextanalyse Seite 202 BSR MoveTo Anz BSR 12 BSR SetCapture Anz BSR 1 BSR SetFocus Anz BSR 41 BSR SetMessageQueue Anz BSR 1 BSR UnlockData Anz BSR 4 BSR WM _ COMMAND Anz BSR 162 BSR WM _ HSCROLL Anz BSR 2 BSR WM _ MENUSELECT Anz BSR 1 BSR WM _ QUIT Anz BSR 1 BSR WM _VSCROLL Anz BSR 2 L_layer cpp 119 MessageBox GetFocus AuthorAddress Adresse MBINFO TAbout Dlg_OnCommand HWND___ int HWND___ unsigned_int L_layer cpp 115 MessageBox GetFocus WorkAddress Adresse MBINFO TAbout Dlg_OnCommand HWND___ int HWND___ unsigned_int KOMP
150. Roth C Ein Verfahren zur Ouantifizierung der Strukturiertheit von Software In Fromm H Steinhoff A Hrsg Software Metriken Arbeitsgespr ch der Fachgruppe Software Engineering Gesellschaft f r Informatik IBM Bildungszentrum M rz 1987 Schmidt M ber das Messen und Bewerten von Software Qualit t mit Ma und Metrik In In Fromm H Steinhoff A Hrsg Software Metriken Arbeitsgespr ch der Fachgruppe Software Engineering Gesellschaft f r Informatik IBM Bildungszentrum M rz 1987 Sch tzler K Wiedergewinnung von Subsystemen durch Use Case Analyse und Dateirestrukturierung am Beispiel des XCTL Systems Berlin Humboldt Universit t Dipl Arb 2001 SHARE Ad Hoc Commitee on Universal Languages The Problem of Programming Communication with Changing Machines A Proposed Solution CACM 1 1968 pp 12 15 Sibley R A The SLANG System CACM 4 Jan 1961 S 75 84 Soltendick W Borland C Version 5 Das Buch M nchen tewi Verl 1996 Soltendick W Hg Das Win32 API Band 1 LZ32 ComCtl32 Kernel32 Vaterstetten Computer und Literaturverl 1999 Soltendick W Hg Das Win32 API Band 2 Shell32 ComDlg32 OLE32 OLE Interfaces MS DOS Extensions in Windows 95 Vaterstetten Computer und Literaturverl 1999 Soltendick W Hg Das Win32 API Band 3 User32 advanced API Vaterstetten Computer und Literaturverl 1999 Soltendick W Hg Das Win32 API Band 4 GDI32 Diskcopy Multimed
151. T _MAX_DRIVE respectively change fnsplit to _splitpath change fnmerge to _makepath change chdir to _chdir and add include lt direct h gt change try var new A catch xalloc B to var new if var LA else B you can remove warning truncation from const double to float by adding f to the end of Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 237 float constants e g 1 0f you can remove warning truncation from const int to char by adding cast to the right side e g b i j char 255 m_curve h change _export to __declspec dllexport in define _CURVECLASS change _import to __declspec dllimport in define _CURVECLASS m_devcom h and m_psd h change _export to __declspec dllexport in define _COUNTERCLASS change _import to __declspec dllimport in define _COUNTERCLASS m_d1g cpp introduce variable int edgeTmp in function TAnglecontrol Dlg_OnCommand replace line setscrollRange BarHandle SB_CTL GetBarEgde LEFT GetBarEgde RIGHT TRUE with edgeTmp GetBarEgde LEFT SetScrollRange BarHandle SB_CTL edgeTmp GetBarEgde RIGHT TRUE comhead h comment out include lt cstring h gt lt dir h gt lt _defs h gt add include lt windows h gt in front of lt windowsx h gt add define M_PI 3 14159265358979323846 comclass h delete all words _export dlg_tp1 cpp comment out Ctl3dcolorchange lines kpmt1 c changed mov dx
152. TScanCmd f TScsParameters A TSetAdjustmentParam N oO gt OWAPRPANNA HANWNAWAWNWWAWANNA ANWANANON A HA ANNN gt N voor D e Ze D De Ze Ze Ze D e Ze De D e e Ze De D ie Ze Dee D D e Ze D D D Ze D Deet D D Ze D D e e Anhang F Daten der Quelltextanalyse Seite 213 TSetupAreaScan TSetupContinuousScan TSetupScanCmd TSetupStepScan TShowValueCmd i TSteering i TStoe_Psd TTopographyExecute Tx OMAN OWD DN W org N VKG BSM BIBM UTM 0 025 0 667 0 0 691 SU PAN sy KOMP VKGy 356 KOMP 0 691 F 2 Ma komponente Hardware Umgebung F 2 1 Ermittlung der Ma komponente Maschinenarchitektur zum Ma MA siehe Kapitel 4 2 1 2 MA LibMain Anz MA 4 MA GetModuleHandle Anz MA 2 MA GetModuleUsage Anz MA 2 MA short Anz MA 3 MA WORD Anz MA 102 MA cbClsExtra Anz MA 2 MA cbWndExtra Anz MA 2 MA export Anz MA 131 MA FAR Anz MA 19 MA HIWORD Anz MA 10 MA huge Anz MA 3 MA LONG Anz MA 26 MA LOWORD Anz MA 14 MA pascal Anz MA 4 MA WEP Anz MA 4 MA Wnd Pr oc Anz MA 9 MA WORD Anz MA 224 MA WORD FAR PASCAL Anz MA 2 M_steerg cpp 3353 void TAdjustmentWindow rButtonDown LONG IParam M_steerg cpp 3357 pp x LOWORD IParam M_steerg cpp 3358 pp y HIWORD IParam KOM
153. T_WM_COMMAND_HWND wParam Param Main CurrentPopup HMENU GET_WM_COMMAND_ID wParam lParam Main CurrentID GET_WM_COMMAND_ID wParam lParam MessageBox GetFocus Kein Konfigurationsfile Fehler MBSTOP MessageBox GetFocus Configuration file not founded Failure MBS while SetMessag eQueue cnt DIlEntryPoint void_ unsigned_long void_ DIlEntryPoint void_ unsigned_long void_ mlMoveToDistance int double mlOptimizingDlg mMoveToDistance double mMoveToDistance double mSavePosition unsigned_int unsigned_int unsigned_long unsign mSavePosition unsigned_int unsigned_int unsigned_long unsign WEP int DoCommandsChild TMDIWindow_ HWND___ unsigned_int long DoCommandsChild TMDIWindow_ HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long MenuSelect HWND___ unsigned_in
154. Web Browser ein sogenannter Just in time Compiler bereitgestellt der den Zwischencode in ein Objektprogramm f r einen speziellen Prozessortyp bersetzt und dann direkt auf diesem ausf hrt ohne den Umweg ber einen Interpreter Weitere Beispiele f r Java hnliche Konzepte ist der an der Universit t von Kalifornien Sant Diago entwickelte portable Pascal Compiler UCSD Pascal mit P Code oder aber der portable BCPL Compiler mit O Code als Zwischensprache Peck 78 Bei portablen Betriebssystemen wie MUSS wird die generische Architektur ebenfalls durch virtuelle Maschinen realisiert die als Zwischenschicht bis auf die Ebene der Maschineninstruktionen abstrahieren Der generierte Objektcode wird dann von diesen virtuellen Maschinen interpretiert und direkt auf dem zugrunde liegenden Prozessortyp ausgef hrt wird Ein weiteres Beispiel f r eine generische Architektur ist das eingesetzte Konzept der Hardware Abstraktionsschicht Hardware Abstraction Layer kurz HAL von Windows NT Diese zus tzliche Schicht abstrahiert Teile der darunterliegenden realen Hardware Komponenten und spiegelt den bei einer Portierung auf ein anderes Rechnersystem anzupassenden Betriebssystemkern wieder Der Unterschied zu Betriebssystemen wie MUSS besteht darin da hier nur bestimmte Teile der Hardware einer generischen Architektur unterworfen sind wie z B Karten Treiber Es wird nicht bis auf die Ebene der Maschineninstruktionen in Form von virtuelle
155. Zeichen die aus ganzzahligen Werten mit 16 oder noch mehr Bits bestehen jedoch ist die Interpretation des Zeichensatzes und die Definition der Byte Strom Kodierung gut in den Bibliotheken versteckt und nur schwer zu ermitteln Die Situation ist zur Zeit bestenfalls unbefriedigend und es herrscht keine bereinstimmung dar ber welcher Zeichensatz benutzt werden soll Eine Entscheidung f r einen bestimmte Zeichensatz Kodierung sollte jedoch immer ber das Standard ASCH hinausgehen Mithin sollten bestimmte Sprachannahmen bei der Nutzung von Benutzeroberfl chen ebenfalls vermieden werden Dazu geh ren die Breite von Dialogfeldern f r Meldungen in verschiedenen Sprachen das Einhalten des Prinzips der Lokalit t f r die Verwaltung der einzelnen Meldungen sowie der l nderspezifischen Datumsformate oder kulturabh ngigen Icons in grafischen Benutzeroberfl chen Aus den hier betrachteten Problemen lassen sich somit bestimmte allgemeine Grunds tze f r portablen C bzw C Code ableiten Einhaltung der vorhandenen Standards ANSI C bzw C Programmierung im C bzw C Mainstream Kompilieren mit unterschiedlichen Compilern auf h chster Warnstufe Nutzung von C und C Standardbibliotheken Benutzung von Text f r den Datenaustausch Benutzung einer festgelegten Byte Reihenfolge f r den Datenaustausch Nutzung berall verf gbarer Merkmale Vermeidung von bedingter bersetzung Vereinigung Konzentration v
156. ___ unsigned Motors cpp 538 FORWARD_WM_COMMAND hwnd cm_CarryOnZero hwndCtl 0 PostMe TCalibratePsd Dlg_OnInit HWND___ HWND___ long Motors cpp 566 FORWARD_WM_COMMAND hwnd cm_IndexArrived 0 idx SendMessage TCalibratePsd Dlg_OnTimer HWND___ unsigned_int Motors cpp 576 FORWARD_WM_COMMAND hwnd cm_DistanceSet 0 idx SendMessage TCalibratePsd Dlg_OnTimer HWND___ unsigned_int KOMP TCalibratePsd Anz BIBA 8 M_steerg cpp 652 MessageBox GetFocus Kein Scan Fenster offen Fehler MBSTOP TCmd DoAction M_steerg cpp 128 if mlMoveToDistance mid dDistance TCmd StartMove const_int double KOMP TCmd Anz BIBA 2 Counters cpp 2052 FORWARD_WM_COMMAND GetFrameHandle cm_CallExecute TCommonDevParam Dlg_OnCommand HWND___ int HWND___ unsigne Counters cpp 2070 FORWARD_WM_COMMAND GetHandle cm_ActivateChanges 0 0 TCommonDevParam Dlg_OnCommand HWND___ int HWND___ unsigne Counters cpp 2010 SetFocus GetDlgltem hwnd id_Level TCommonDevParam Dig_Onlnit HWND___ HWND___ long Counters cpp 2015 FORWARD_WM_COMMAND hwnd cm_Initialization hwndCtl 0 Sen TCommonDevParam Dlg_OnInit HWND___ HWND___ long KOMP TCommonDevParam Anz BIBA 4 M_device cpp332 SetFocus GetDlgltem GetHandle IDOK TCounterShowParam Dlg_OnInit HWND___ HWND___ long KOMP TCounterShowParam Anz BIBA 1 M_device cpp82 MessageBox GetFocus LPSTR buf Fehler MB_Ok TCounterWindow CanOpen M_device cpp 202 void TCounterWindow Set
157. _layer cpp 140 BOOL WINAPI _export Savelmage LPSTR fname St_layer cpp 145 BOOL WINAPI _export UnlockDataBase void St_layer cpp 150 BOOL WINAPI _export GetDataBaseAccess HPBYTE hpDB SIZE size St_layer cpp 527 int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR St_layer h 14 BOOL WINAPI GetHistogram LPWORD int St_layer h 30 typedef BOOL WINAPI TInitializeTask WORD St_layer h 31 typedef BOOL WINAPI TExecuteNextSubTask WORD Ra t_layer h 33 typedef BOOL WINAPI TGetHistogram LPWORD int Testdev cpp 2 long _huge testDevData 9 17 601 KOMP Tx Anz MAA 298 Anzahl GROUP GROUP Ergebnis LA 109 SEP 34 Gesamtergebnis 143 MAM Anz MA Anz MA 563 MAM KOMP Anz MAA KOMP Anz MAA TAdjustmentWindow TAm9513a TAreaScan y TBitmapSource TBraun_Psd TC_812 TC_812GPIB y TC_832 TChooseDeviceCmd TCounterShowParam TCounterWindow TDC_Drive a TDevice TEditWindow y TEncoder TGenericDevice TMain oO N SAM b zooA bo Oe bb 088 TMDIWindow TModalDlg TModelessDlg TMotor TMotorParam TOptimizeDC_812 A TOptimizeDC_832 j TPlotData TPsd e TRadicon TScan TScanCmd TSetupContinuousScan TStoe_Psd 3 Tx a Sep sangen onen E N co Anhang F Daten der Quelltextanalyse Seite 226 MAM Anzahl aller Komponenten mit MA Zugriffen _
158. _long KOMP TDevice Anz MAA 9 M_steerg cpp 2952 void TEditWindow rButtonDown LONG IParam TEditWindow rButtonDown long M_steerg cpp 2958 pp x LOWORD IParam TEditWindow rButtonDown long M_steerg cpp 2959 pp y HIWORD IParam TEditWindow rButtonDown long M_steerg h 576 void rButtonDown LONG IParam TEditWindow rButtonDown long KOMP TEditWindow Anz MAA 4 M_devhw h 41 int GetData WORD WORD WORD TEncoder GetData TCurve_ amp KOMP TEncoder Anz MAA 1 Counters cpp 534 DWORD param TGenericDevice Initialize Counters cpp 550 DWORD value TGenericDevice SetParameters Counters cpp 552 value fExposureTime DWORD GetTicksPerSecond TGenericDevice SetParameters Counters cpp 589DWORD counts ticks TGenericDevice PollDevice Counters cpp 646 CALLBACK TGenericDevice EventHandler UINT UINT DWORD DWORD DWORD TGenericDevice M_devhw h 22 static CALLBACK TGenericDevice EventHandler UINT UINT DWORD TGenericDevice KOMP TGenericDevice Anz MAA 6 EventHandler unsigned_int unsigned_int unsig EventHandler unsigned_int unsigned_int unsig M_main cpp 910 if OxFFFF WORD GET_WM_COMMAND_HWND wParam lParam TMain TMain M_main cpp 1429 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Datei TMain LoadMenuBar M_main cpp 1434 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Bearbeiten TMain LoadMenuBar M_main cpp 1449 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Off
159. _scan cpp 154 AppendMenu TheMenu MF_POPUP WORD hM2 Sca amp n TBitmapSource FormatDBaseToBitmapSource KOMP TBitmapSource Anz MAA 17 BraunPSD cpp 125 void WINAPI IpfnSetPort WORD WORD TBraun_Psd TBraun_Psd BraunPSD cpp 126 BYTE WINAPI IpfnGetPort WORD TBraun_Psd TBraun_Psd BraunPSD cpp 127 void WINAPI IpfnSetTimeout DWORD TBraun_Psd TBraun_Psd BraunPSD cpp 128 int WINAPI IpfnGetData WORD WORD WORD LPLONG WORD long amp TBraun_Psd TBraun_Psd BraunPSD cpp 128 int WINAPI IpfnGetData WORD WORD WORD LPLONG WORD long amp TBraun_Psd TBraun_Psd BraunPSD cpp 141 FARPROC IpfnSetPort GetProcAddress AsaDllinstance SetPort TBraun_Psd TBraun_Psd BraunPSD cpp 142 FARPROC IpfnGetPort GetProcAddress AsaDllinstance GetPort TBraun_Psd TBraun_Psd BraunPSD cpp 143 FARPROC IpfnSetTimeout GetProcAddress AsaDllinstance SetTimeout TBraun_Psd TBraun_Psd BraunPSD cpp 144 FARPROC IpfnGetData GetProcAddress AsaDllinstance GetData TBraun_Psd TBraun_Psd BraunPSD cpp 166 transform IWert 0 WORD uEnergyHigh TBraun_Psd TBraun_Psd BraunPSD cpp 174 transform Wert 0 WORD uEnergyLow TBraun_Psd TBraun_Psd BraunPSD cpp 184 transform IWert 0 WORD uMuxTimeDet1 TBraun_Psd TBraun_Psd BraunPSD cpp 192 befehl 11 3 WORD bRatemeter TBraun_Psd TBraun_Psd BraunPSD cpp 193 echo 11 4 WORD bRatemeter TBraun_Psd TBraun_Psd BraunPSD cpp 197 befehl 15 3
160. a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a TAm9513a IOCTL TIOCCmd IOCTL TIOCCmd IOCTL TIOCCmd IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd unsigned_long_ amp IOCTL TIOCCmd SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SplitNumber unsigned_long unsigned_short_ amp unsigne SelectChip unsigned_char ChooseDataPtr WriteData unsigned_short WriteData unsigned_short ReadData ReadData ReadData ReadData Init GetTicksPerSecona WriteData unsigned_short ReadData ReadStatus SplitNumber unsigned_long unsigned_short_ amp unsigne
161. a der Portierungsaufwand nur indirekt ber dessen Einflu faktoren bestimmbar ist existiert ein funktionaler Zusammenhang der Form Aufwand n f F F3 F3 mit F System Umgebung F Dokumentation F Komplexit t Portabilit tsanalyse am Beispiel des XCTL Systems Seite 137 Die einzelnen Einflu faktoren sind in Subfaktoren zerlegbar und es ergibt sich auch hier eine funktionale Abh ngigkeit der Form F fo SF SF mit 1 SF j ter Subfaktor des Faktors F mit i 1 3 undj 1 k Die Verfeinerung wird in dem Ma e fortgef hrt bis die jeweiligen Subfaktoren direkt me bar sind und damit die unterste Hierarchieebene erreicht worden ist F r die Subfaktoren dieser Ebene werden entsprechende Ma e aufgestellt SM Subma f r den j ten Subfaktor SF des Faktor F mit i 1 n undj 1 m Die Ermittlung des Portierungsma es erfolgt dann in umgekehrter Richtung zur obersten Ebene der Einflu faktor Hierarchie und geschieht durch Aggregation der Subma e zum Faktorma den die entsprechenden Subfaktoren bestimmen bspw gewichtete Addition der Me werte Damit existiert zu jeder Hierarchieebene ein entsprechendes Ma M g8 SM 2 SM p Im folgenden wird diese allgemeine Vorgehensweise auf alle drei Einflu gr en angewendet und f r das XCTL System durch entsprechende Messungen realisiert Bei den Messungen zur System Umgebung werden die Messungen direkt an den Quellen durchgef hrt un
162. aber nicht nur die Realisierung einfacher sondern auch komplexer Funktionen Diese werden mit Hilfe weiterer Prozeduren importierte Prozeduren realisiert welche ebenfalls funktional gebunden sein sollten Nach Balzert 98 besitzt eine funktionale Bindung folgende Kennzeichen Alle Elemente tragen dazu bei ein einzelnes spezifisches Ziel zu erreichen Es gibt keine berfl ssigen Elemente Die Aufgabe l t sich mit genau einem Verb und genau einem Objekt vollst ndig beschreiben Leichter Austausch gegen ein anderes Element das denselben Zweck erf llt Hohe Kontextunabh ngigkeit d h einfache Beziehungen zur Umwelt Neben der hohen Kontextunabh ngigkeit sind geringe Fehleranf lligkeit bei nderungen ein hoher Grad an Wiederverwendbarkeit leichte Erweiterbarkeit und Wartbarkeit wichtige Vorteile einer funktionalen Bindung und f hren zu einer wesentlichen Verfestigung der internen Prozedurstruktur Problematisch bei der Bestimmung der Bindungsart ist jedoch da diese noch nicht automatisch ermittelt werden kann bzw keine objektiv me baren Kriterien zu deren Bestimmung vorliegen und nach Balzert nur durch manuelle Pr fmethoden bestimmbar ist Entwurfs oder Code berpr fung Im Entwurf wird anhand der Aufgabenbeschreibung analysiert welche Bindungsart vermutlich vorliegt Eine endg ltige Entscheidung dar ber wird anhand der Implementierung getroffen Das Ziel einer guten Bindung liegt demnach darin nur solche El
163. alb wird auch hier die H ufigkeit des Auftretens von Portabilit tsanalyse am Beispiel des XCTL Systems Seite 144 potentiell anzupassenden Aufrufen einer Komponente gemessen wobei jede Komponente einmal gez hlt wird Das Ma hierf r lautet BIBM KOMB Anz BIBA KOMP Anz BIBA mit KOMP i te Komponente des Programms 1 n BIBA anzupassender Aufruf einer Bibliotheksroutine Die Realisierung f r das Ma BIBM sieht damit wie folgt aus siehe Anhang F BIBM KOMP Anz BIBA KOMP Anz BIBA TAbout j TAdjustmentExecute TAdjustmentWindow TAm9513a TAngleControl i TAquisition TAreaScan TAreaScanCmd j TAreaScanParameters TBitmapSource TBraun_Psd TC_812 TC_812GPIB e TC_832 TCalibrate 7 TCalibratePsd TCmd TCommonDevParam TCounterShowParam TCounterWindow i TCurve TDC_Drive i TDevice xw e e O O O O O O O OU OU WS OU OU WS OU OU OU OU OU OU OU OU OU OU OU OU OU OU ee OU OU OU OU ee ee aw aS Fee ee ee Se wa LA UOA NNa ANWNAWAWNWWHA WANNA PM OO OM AM OO A A WBNHNNDND A TDList TEditWindow j TEncoder TExecuteCmd e TGenericDevice TMacroExecute TMain TMDIWindow TMList y TModalDlg TModelessDig 5 TMotor TMotorParam j TPlotData TPosControl TPsd j TPsdRemoteSync TRadicon TScan TScanCmd Portabilit tsanalyse am Beispiel des XCTL
164. ale Variable R zugreift Die Menge aller in einem Software System auftretenden Segment global usage pairs bezeichnet man als AUP actual Metriken und Portierungsaufwand Seite 93 usage pair Sind in einem Software System alle globalen Variablen einer jeden Komponente bekannt und alle Variablen R jeweils mit Komponenten P durch Bildung sogenannter potentieller Benutzungspaare P R verkn pft so bilden diese die Menge aller potentiellen Benutzungspaare PUP possible usage pair Das Ma f r die relative H ufigkeit der Verwendung globaler Variablen RUP relative usage pair ist das Verh ltnis der Anzahl der aktuellen zu den potentiellen Benutzungspaaren RUP AUP PUP 3 1 3 7 Datenbindungsmetrik Die Datenbindungsmetrik ist wie die Segment global usage pair Metrik eine Datenstruktur Metrik und bestimmt die Bindung zwischen zwei Komponenten ber eine globale Variable Basili 80 Diese Bindung wird durch ein Tripel P R O beschrieben und als Segment global segment data binding bezeichnet Folgende Bedingungen m ssen f r ein Tripel gelten in der Komponente P wird die globale Variable R ver ndert in der Komponente Q wird auf die Variable R zugegriffen und die Komponenten P und O d rfen nicht gleich sein d h Pas Die aktuelle Datenbindung ADB actual data binding ist die Menge aller existierenden Datenbindungen im Software System Die Menge der potentiellen Datenbindungen beinhaltet alle m glichen Datenb
165. als weitere Instanz einer Anwendung registriert wird So ist zum Beispiel die Praxis von einigen Grafikprogrammen h ufig ben tigte Grafikobjekte nur einmal anzulegen und in mehreren Instanzen zu benutzen unter Win32 unzul ssig Global definierte Daten werden unter Win32 anders verwaltet als im 16 Bit Windows So existieren unter Winl6 zwei Mechanismen zur dynamischen Anforderung von Speicherbereichen der lokale Heap mit einem theoretischen Maximum von 64 KB einem Zeigertyp Offset 2 Byte und anwendungsweiter Verf gbarkeit f r kleinere Objekte und der globale Heap mit einem je nach Betriebsmodus maximal allokierbarem Speicher von mehreren Megabyte im Rahmen der physischen Verf gbarkeit einem Zeigertyp Selektor und Offset 4 Byte und systemweiter Nutzung der Speicherbereiche der in erster Linie gr ere Bereiche allokiert oder aber zum Austausch von Daten zwischen Anwendungen benutzt wird Die Verf gbarkeit des lokalen und globalen Heaps beschr nkt sich unter Win32 wie unter Win16 der lokale Heap auf den Speicherbereich der Anwendung hier aber bis zu maximal 2 GB ber einen Offset 4 Byte adressierbar Somit befindet sich die Speicherverwaltung von Win32 konzeptionell n her am lokalen Heap von Windows 3 x als am globalen Heap und Portierungsprobleme entstehen hierbei u a bei Zeigerzuweisungen an verbreiterte Datentypen verschicken von NEAR Zeigern in privaten Nachrichten oder Datensegment Modifikati
166. and HWND___ int HWND___ unsigned_ M_dlg cpp 509 SetFocus GetDigltem hwnd id_AngleWidth TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ M_dlg cpp 504 SetFocus BarHandle TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ M_dig cpp 503 SendMessage hwnd WM_COMMAND cm_Motorlnit O TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ M_dig cpp 458 SetFocus BarHandle TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ M_dlg cpp 448 SetFocus BarHandle TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ M_dlg cpp 434 SetFocus BarHandle TAngleControl Dig_OnCommand HWND___ int HWND___ unsigned_ KOMP TAngleControl Anz BIBA 32 M_arscan cpp 3770 MessageBox GetFocus buf Meldung MBINFO TAquisition CanClose M_arscan cpp 3761 if IDYES MessageBox GetFocus buf Meldung MBASK TAquisition CanClose KOMP TAquisition Anz BIBA 2 M_arscan cpp 344 switch GET_WM_COMMAND_ID wParam IParam TAreaScan TAreaScan M_arscan cpp 495 MessageBox GetFocus Eingabe wird verworfen Fehler MBINFO TAreaScan InitializeDlg unsigned_int long M_arscan cpp 650 MessageBox GetFocus buf Meldung MBINFO TAreaScan InitializeDlg unsigned_int long M_arscan cpp 671 MessageBox GetFocus buf Daten Erhebung MBINFO TAreaScan InitializeDlg unsigned_int long M_arscan cpp 1062 if IDNO MessageBox GetFocus msg HeadLine MBASK TAreaScan InitializeTask unsigned_i
167. aram IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen EM_SETSEL EM_SETSEL Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_ACTIVATE WM_ACTIVATE Information in wParam lParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_CHANGECBCHAIN WM_CHANGECBCHAIN Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_CHARTOITEM WM_CHARTOITEM Information in wParam lParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_COMMAND WM_COMMAND Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_COMMNOTIFY WM_COMMNOTIFY Nachricht unter Win32 gestrichen MBE Siehe berlappende File 1 O Funktion WM_CTLCOLOR WM_CTLCOLOR Ersetzt durch 7 neue Nachrichten Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_DDE_ACK WM_DDE_ACK IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_ADVISE WM_DDE_ADVISE IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_DATA WM_DDE_DATA IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_EXECUTE WM_DDE_EXECUTE IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_POKE WM_DDE_POKE IParam fuer Informatione
168. are l st die Aufgaben des Anwenders mit Hilfe eines Computersystems und setzt auf Systemsoftware und Hardware auf Anwendungssoftware Systemsoftware und Hardware bilden zusammen ein Computersystem bzw DV System Unter Umgebung soll aber nicht nur die Hardware und Software Umgebung im Sinne eines Computersystems verstanden werden sondern auch das Umfeld in dem das Computersystem existiert Dazu geh ren technische und organisatorische Systeme Benutzer Anwender Mitarbeiter welche zusammen mit dem Computersystem ein rechnergest tztes Informationssystem Anwendungs system bilden Unter einer Umgebung soll somit ein rechnergest tztes Informationssystem verstanden werden also der komplette Umfang an Elementen der mit dem zu portierenden Software System interagiert Der von vielen Autoren benutzte Begriff Plattform bezieht sich nur auf das Betriebssystem und die verwendete Hardware Der Hardwarebegriff bezieht sich auf alle materiellen Teile eines Computersystems Zentraleinheit Ein Ausgabesteuerung Peripherieger te Die bertragbarkeit eines Software System wird durch den Portabilit tsgrad gekennzeichnet Ein Software System ist in dem Ma e portabel je h her die Kosten verursacht durch den nderungsaufwand f r eine Neuentwicklung im Vergleich zur Portierung sind Ein Software System wird durch seinen Portabilit tsgrad Funktion von Portierungs und Neuentwicklungskosten bzgl einer bestimmten Zielumgebung cha
169. ationsart what is communicated Es sollen deshalb die drei Dimensionen nach Stevens n her betrachtet werden Er erw hnt zus tzlich eine vierte Dimension die Klarheit clarity welche sich auf die Einfachheit der Kopplung bezieht und f r das Verst ndnis einer Systemkomponente relevant ist Diese Dimension soll hier nicht n her betrachtet werden da sie keine me bare Gr e darstellt und im Wesentlichen durch die drei anderen Dimensionen bereits erfa t wird Kopplungsmechanismus Stevens unterscheidet drei Arten um Komponenten untereinander zu koppeln Aufruf CALL Prozedur bzw Funktionsaufruf Verzweigung PERFORM goto und externe Verbindung Ein Aufruf mit der expliziten Angabe von Parametern ist die einfachste verst ndlichste flexibelste und am wenigsten fehleranf llige Form der Kopplung In den meisten Programmiersprachen wird dieser Kopplungsmechanismus ber das Prozedur oder Funktionskonzept realisiert Der Datenaustausch erfolgt ber Parameter die in einer Parameterliste enthalten sind Kennt eine Programmiersprache diesen Aufrufmechanismus mit Parameterkonzept nicht k nnen auch andere Mechanismen verwendet werden die aber zu einer Erh hung der Kopplungsst rke f hren Der wesentliche Unterschied zwischen einer Verzweigung in der Praxis einer goto Anweisung z B PERFORM Anweisung in Cobol und dem Aufruf einer Prozedur besteht darin da im ersten Fall keine explizite Parameter bergabe stattfindet bzw
170. au und die Funktionsweise voraus Damit Fehler gefunden und korrigiert werden k nnen ist eine gewisse Einarbeitung in das entsprechende System notwendig Hierbei spielen die Schnittstellen zwischen den Systemkomponenten eine tragende Rolle da nderungen an bestimmten Komponenten nur geringe Auswirkungen auf andere Komponenten haben sollten Aus diesem Grund wird zun chst das Ma f r die Schnittstellenkomplexit t von Systemkomponenten vorgestellt und f r Portabilit tsanalyse am Beispiel des XCTL Systems Seite 157 das XCTL System berechnet Ein weiterer wichtiger Punkt bei der Bestimmung der Komplexit t eines Systems ist die Kenntnis ber die logische und strukturelle Komplexit t die sich entscheidend auf den Testumfang auswirkt Aus diesem Grund wird in einem weiteren Schritt das Ma f r die interne Komponentenkomplexit t zun chst noch einmal vorgestellt und ebenfalls f r das XCTL System bestimmt Beide Komplexit tsma e werden im Anschlu daran zu einem Gesamtma f r die Komplexit t zusammengefa t KPL Komplexit t Schnittstellenkomplexit t Interne Komponentenkomplexit t SK IKK Schritte zur Ermittlung des Teilma es Komplexit t Ermittlung der Ma komponente Schnittstellenkomplexit t Ermittlung der Ma komponente Interne Komponentenkomplexit t Zusammenfassung zur Ma komponente Komplexit t 4 2 2 1 Schnittstellenkomplexit t SK Schnittstellenkomplexitat KP DK Kop
171. auf die Utility Aufrufe bertragen werden Die Definition der Utiltity Ma e wurde bereits im Kapitel 3 2 3 4 dargestellt und soll hier nicht noch einmal wiederholt werden Aggregation zum Gesamtma Software Umgebung Bei der Aggregation zum Gesamtma f r die Software Umgebung werden jeweils die zweite und dritte Stelle der drei Ma e BS BIB und UT zusammengefa t da sie f r alle drei Ma e gleich sind Hierbei besteht die M glichkeit da in einer Komponente unterschiedliche Aufrufarten vorkommen so etwa von Bibliotheks und Utility Routinen In diesem Fall werden die jeweiligen Anzahlen f r Portabilit tsanalyse am Beispiel des XCTL Systems Seite 146 jede Komponente addiert Der hierbei entstandene Informationsverlust besteht dann darin da nicht mehr einzelne Aufrufarten in das Ma eingehen sondern nur noch pauschal die Aufrufe von Software Umgebungs Routinen In der ersten Position stimmen die Ma e dann berein wenn keine Portierungsinformationen vorliegen und zun chst nur die potentiellen nderungen gez hlt werden Die nderungen bzgl der verschiedenen Aufrufarten sind disjunkt und lassen sich deshalb addieren Im differenzierten Fall erfolgt die Aggregation indem die Positionen der nicht anpa baren Routinen und die Routinen ber die nichts bekannt ist addiert werden und die ersten beiden Positionen des BS Aufrufma es unver ndert bernommen werden Falls noch keine Portierungsinformationen in das Ma
172. be Sch tzungen die jedoch keinesfalls konkrete Aussagen zum eigentlichen Portierungsaufwand beinhalten k nnen Eine andere Sicht ergibt sich sobald eine Portierung erfolgreich durchgef hrt wurde Nun k nnen die vorhandenen Informationen in Aufwandsprognosen einflie en und erlauben es mit der Zeit immer pr zisere Aussagen zum Portierungsaufwand von Software Systemen zu machen Wird z B ein Software System in eine Umgebung portiert die ber ein anderes Betriebssystem verf gt so l t sich nun da bereits dokumentierte Anpassungsaufw nde f r einzelne Betriebssystemroutinen vorliegen der Aufwand anhand der Zahl vorhandener Betriebssystemaufrufe realistischer absch tzen Das Portierungsma befindet sich somit in einer Art evolution rem Proze und wird mit seinen Aussagen zum Portierungsaufwand mit wachsenden Erfahrungswerten immer pr ziser Die Autoren beschreiben als Zielgruppe eher solche Benutzer die h ufiger Software Systeme portieren wie z B Softwarefirmen Diese k nnen die M glichkeiten des Ma es besser nutzen als einmalige oder seltene Benutzer Aber auch die einmalige Nutzung soll eine ganze Reihe von Informationen bringen die eine Entscheidung f r oder gegen eine Portierung auf eine breitere Basis stellt 3 2 3 2 Ma objekte Mit dem Ma sollen Software Systeme oder Systemkomponenten gemessen werden die in einer h heren Programmiersprache implementiert sind Hardwarenahe Software Systeme wie z B Systemsoftwar
173. beispielsweise keinen Sinn ein Software System zu portieren zu dem keine oder nur unzureichende Dokumentation existiert da es vom Porteur nur sehr schwer zu verstehen und vom Anwender kaum benutz und erweiterbar ist Die Autoren gehen daher einen Kompromi ein in dem sie die Dokumentation als stark subjektive Einflu gr e in das Ma aufnehmen und diese durch manuelle Code Inspektion bestimmen lassen etwa durch ein entsprechendes Code Review in Form von vorgegebenen Checklisten welche die Dokumentation auf das Vorhandensein wichtiger Dokumentationskomponenten hin berpr fen Metriken und Portierungsaufwand Seite 108 3 2 3 4 Mafaufbau Das betrachtete Ma f r die Bestimmung des Portierungsaufwands von Software Systemen hat folgenden grundlegenden Aufbau PORT Portierungsaufwand System Umgebung Dokumentation Komplexit t SYS KPL DOK Formal PORT SYS KPL DOK Es folgt der Aufbau f r das Teilma System Umgebung SYS System Umgebung Software Umgebung Hardware Umgebung Programmiersprachen SU HU PS Formal SYS KAsys PAsys SAsys BAsys PAN sys KOMP ys VKGsy5 VSGsy5 mit KAsys EA KAps_ ces Namen der BS Routinen und der PS Konstrukte die nicht angepa t werden k nnen PA PA BS zg pel PAgys Anzahl und Namen der BS Routinen und PS Konstrukte ber die w hrend der Messung keine Informationen vorliegen SAgys S sy SAps Ges Gesamtzahl aus Aufrufen von
174. ber der 66er Standard keine echte Teilmenge des 77er Standards war gab es Probleme bei der Portierung von alten FORTRAN Programmen auf Rechner mit FORTRAN Compilern die den 77er Standard unterst tzten Bei der Entwicklung eines Sprachstandards mu ten also Kompromisse in Bezug auf existierende Programme eingegangen werden und es hat sich gezeigt da die nachtr gliche Festlegung eines Standards f r eine existierende Programmiersprache nicht unproblematisch ist Hierbei m ten entweder alle Dialekte bei der Definition ber cksichtigt werden mit zum Teil widerspr chlichen Forderungen oder bestehende ltere Programme werden als nicht portabel deklariert Nicht nur die Entwicklung und Einf hrung eines Sprachstandards gestaltet sich schwierig sondern auch die Einhaltung bei der Entwicklung von Software Systemen ist keine Garantie f r dessen Portabilit t Zwar werden sehr viele Systemabh ngigkeiten von einem Sprachstandard heute bereits abgedeckt jedoch gibt es weitere Abh ngigkeiten die aus Portierungssicht immer noch nicht zufriedenstellend vereinheitlicht wurden Hierzu geh ren die bereits aufgef hrten Probleme wie Steuerung von Ein Ausgabeger ten Dateisysteme Wertebereiche von Datentypen Adressierung sowie die Proze verwaltung Proze Scheduling und Synchronisation Ein weiteres Problem im Zusammenhang mit Sprachstandards ist darin zu sehen da sie meist keine Aussagen ber die Zul ssigkeit von Spracherweiterungen e
175. besitzt eine System VM in der alle Systemprozesse und alle Win32 Anwendungen in jeweils einem eigenem Adre raum und Win16 Anwendungen in einem gemeinsam genutzten Adre raum laufen Eine MS DOS Anwendung l uft in ihrer eigenen DOS VM da diese zum Teil exklusiven Zugriff MS DOS Modus des VMM auf die Systemressourcen erfordern und w hrenddessen keiner anderen Anwendung ein Zugriff auf Rechenzeit oder Systemressourcen zugeordnet wird Der Proze Scheduler ordnet die Systemressourcen den Anwendungen und anderen Prozessen zu und legt f r deren gleichzeitige d h preemptive Ausf hrung bestimmte Zeitscheiben fest Die Speicherseitenverwaltung erfolgt wie bei Windows NT nach der Methode des Demand Paging Code und Daten werden seitenweise aus dem physischen Speicher in eine Datei oder auf die Festplatte ausgelagert Dieser Mechanismus arbeitet auf einem flachen linearen Adre raum auf den mit 32 Bit Adressen zugegriffen wird Das Modell der linearen Speicheraddressierung vereinfacht die Entwicklung von Software Systemen und beseitigt die Leistungseinbu en durch segmentierten Speicher das Betriebssystem und die Anwendungen unter Windows 3 1 k nnen Speicher au erhalb eines Segments nur unter Leistungsverlusten ansprechen Es erm glicht jeder 32 Bit Komponente den Zugriff auf 4 Gigabyte adressierbaren Speicher wobei jede Anwendung bis zu 2 Gigabyte privaten Speicher anfordern kann Windows 9x unterst tzt durch seine ges
176. bildung 2 Das Modell repr sentiert ein einfaches Beispiel f r die Portierung eines Software Systems auf Quellcodeebene Hierbei wird das Quellprogramm zun chst in die Zielumgebung transportiert und dann entsprechend an diese angepa t Im Allgemeinen werden jedoch nur einzelne Software Systemkomponenten portiert und die Anpassung der einzelnen Komponenten erfolgt je nach Zielstellung entweder in der Hostumgebung Original Environment oder in der Zielumgebung Target Environment Original Environment Target Environment Source Library Compiler Procedures transport Source Source Program Program amp adapat Object Program Translator Translator Object Procedures Executeable Executeable Program Program Abbildung 2 Proze modell f r die Portierung nach Mooney Der bersetzer beinhaltet den Compile und Link Proze wobei jeweils einzelne Bibliotheken auf Quellcode oder Objektebene hinzugenommen werden k nnen Jede Transformationsebene eines Quellprogramms beinhaltet Anpassungsm glichkeiten an die Zielumgebung Das Modell kann daf r genutzt werden um festzustellen was portiert werden mu und wo im Portierungsproze die Anpassungen ihren Eingang finden Findet die Anpassung an die Zielumgebung in der Hostumgebung statt ergibt sich ein alternatives Modell welches in Abbildung 3 dargestellt wird und in der die Anpassung des Software Systems vollst ndig in der Hostumgebung vorgenommen wird Diese V
177. brochen wird und erst dann eine Nachricht erh lt wenn die angeforderten Daten eingetroffen sind Aus Entwicklersicht spielen die Kernel Funktionen der NT Executive keine gro e Rolle da sie in Win32 Programmen nur in Ausnahmef llen aufgerufen werden Auch existieren wenig Informationen zu den Kernel Funktionen und der Entwickler wird f r die Entwicklung von Software Systemen auf die Win32 API verwiesen Die zus tzliche Abstraktionsebene durch die Win32 API und deren Trennung vom Kernel hat den Vorteil Kernel Funktionen Systemdienste anzupassen oder zu erweitern ohne da die laufenden Software Systeme von nderungen der Datentypen Parameter etc bei Kernel Funktionen direkt betroffen sind Somit legt sich das Win32 Subsystem als zus tzliche Schale zwischen den Entwickler und die tiefer liegenden Kernel Funktionen Das Win32 Subsystem ist der Mittelpunkt des NT Systems Es bestimmt als Instanz die das ger teunabh ngige grafische Ausgabesystem GDI Graphical Device Interface beherbergt ma geblich das Look and Feel des gesamten Betriebssystems Alle anderen Subsysteme erledigen die Ausgabe von Daten auf Bildschirm und Drucker ber das Win32 Subsystem und greifen somit ebenfalls auf dessen Dienste zur ck Man unterscheidet bei NT zwischen zwei Subsystemen den sogenannten environment subsystems wie z B das Win32 Subsystem und den integral subsystems Erstere stellen ein definiertes Betriebssystem API zur Verf gung
178. ch wodurch viele Portierungsfehler im Verborgenen bleiben Es hat sich gezeigt da die Probleme bei der Portierung von Software Systemen relativ vielschichtig sind und eine Aussage ber die Portabilit t von Software Systemen eine Vielzahl der allgemein m glichen Portierungsprobleme ber cksichtigen mu 2 1 3 Strategien Konzepte und Werkzeuge Um Portierungsprobleme zu bew ltigen existieren eine Reihe von Konzepten Strategien und Werkzeugen Dieses Kapitel soll einen berblick dar ber geben welche L sungen f r Portierungsprobleme existieren Hierbei spielt das Prinzip der Uniformit t eine zentrale Rolle wobei man versucht durch einheitliche Schnittstellen ein hohes Ma an Portabilit t zu gew hrleisten 2 1 3 1 Sprachebene Dieser Teil beschreibt die Konzepte Strategien und Portierungswerkzeuge f r Probleme die den Bereich der Compiler und Programmiersprachen betreffen Hierzu geh ren in erster Linie die Entwicklung von einheitlichen Sprachstandards und Standardbibliotheken sowie die Verwendung von Werkzeugen wie Filtern Pr und Makroprozessoren portablen Compilern und Translatoren Standards Die Idee bei der Entwicklung von Sprachstandards besteht darin einen einheitlichen Sprachdialekt f r eine gegebene Programmiersprache zu definieren der von allen Compilern dieser Sprache akzeptiert wird Damit kann eine einheitliche Basis f r die bertragung von Software Systemen die innerhalb dieses Sprachstandards entwic
179. che Schnittstelle zwischen Compiler und Betriebssystem ein offenes Portierungsproblem Translatoren sind Portierungswerkzeuge welche die Quellen eines zu portierenden Software Systems so ver ndern da sie von Compilern auf der Zielmaschine verarbeitet werden k nnen Man unterscheidet Higher Level Sprach Translatoren und die bereits angesprochenen Pr prozessoren Erstere bersetzen ein Programm das auf einer h heren Programmiersprache implementiert wurde in eine andere h here Programmiersprache Pr prozessoren transformieren aus Portierungssicht zwischen verschiedenen Sprachdialekten Bei den Higher Level Translatoren ergeben sich die gr ten Probleme durch die einzelnen Levelunterschiede bei den Programmiersprachen bersetzt man zum Beispiel ltere Software Systeme in eine Umgebung mit einer m chtigeren Programmiersprache als die die dem bisherigen Software System zugrunde liegt k nnen die Unterschiede der einzelnen Konstrukte komplexe Kontrollflu analysen erforderlich machen Solche und andere Schwierigkeiten z B erhebliche Performanceverluste im umgekehrten Fall sorgen daf r da ein Translator nur ein unterst tzendes und kein vollautomatisches Portierungswerkzeug sein kann 2 1 3 2 Betriebssystemebene Weitere Strategien auf dem Weg zur Portabilit t von Software Systemen sind auf der Ebene der Betriebssysteme zu finden Auch hier versucht man durch einheitliche Standards dem Prinzip der Vereinheitlichung zu folgen
180. cher geladen und durch die Win32 Speicherverwaltung Virtual Memory Manager f r die Prozesse ber das sogenannte Paging der CPU in deren Adre raum abgebildet Von Portierungsproblemen ist deshalb nur der Umgang mit den Datenbereichen einer DI betroffen So wird f r jeden Proze eine eigene private Kopie einer Dll in dessen Adre raum geladen und initialisiert Aus diesem Grund Portabilit t von Software Systemen Seite 67 k nnen hierbei keine f r alle Prozesse wichtigen Informationen public global in den DIl s gehalten werden siehe Abbildung 14 virtuelle Adre raum virtuelle Adre raum Proze 1 Proze 2 System System Frei Frei Daten DI A Daten DII A Code DII A Code DII A Phys Speicher mit Daten DII B Daten DII A Daten DII B y Phys Speicher mit Daten DII A r Code DII B Code DII B Phys Speicher mit Frei Code DII A Frei Code und Code und Daten Anw 1 Phys Speicher mit Daten Anw 1 1 Daten DII B Stack und Phys Speicher mit Stack und Heap Daten DII B Heap Frei Frei Phys Speicher mit Code DII B if Physikalischer Speicher Abbildung 14 DIl Speicherverwaltung unter Win32 Unter Win16 wird eine Dll einmalig in den Speicher geladen ist danach systemweit sichtbar und jeder Proze kann auf deren Datensegment zur ckgreifen bzw dieses manipulieren z B f r dynamisch globa
181. cherpl tze bereinigt nur einzelne Teile des Speichers allokiert werden k nnten und nicht als gemeinsamer Speicherplatz nutzbar w ren absolute Speicheradressen statisch verwaltet Die Idee der dynamischen Speicherverwaltung l st das Problem in Form von Indirektion Jeder Speicheradresse wird eine eindeutige Kennziffer zugewiesen ber eine Tabelle miteinander verkn pft und entsprechend verwaltet Somit kann das Betriebssystem die realen Speicherbereiche ber die Kennziffern beliebig umverteilen und nicht ben tigte Bereiche auf die Festplatte auslagern d h virtuellen Speicher simulieren Die Idee der dynamischen Speicherverwaltung wurde seit der ersten Windows Version konsequent umgesetzt Sp ter durch die Unterst tzung von Speichererweiterungskarten Expanded Memory Support in der Version Windows 2 0 erweitert und in der Version 3 0 auf die Verwaltung von bis zu 16 MB Hauptspeicher ausgebaut Voraussetzung f r die dynamische Speicherverwaltung bis zur Windows Version 3 1 waren aufgrund der Prozessorarchitekturen eine Vielzahl von Hilfskonstruktionen die den Speicher in einzelne Segmente Portabilit t von Software Systemen Seite 41 unterteilen mu ten und die Speicherpl tze ber sogenannte Offsets in einem Segment eindeutig adressierten In den 32 Bit Versionen von Windows wird die notwendige Indirektion nicht mehr ber Hilfskonstruktionen wie Segmentarithmetik abgehandelt sondern direkt vom Prozessor vorgenommen Die Adressier
182. chichtete Dateisystemarchitektur unterschiedliche Dateisysteme wie VFAT Virtual File Allocation Table oder CDFS CD ROM File System und erh ht damit im Vergleich zu Windows 3 1 die Geschwindigkeit beim Zugriff auf Laufwerke und Dateien Zu den Funktionen der Architektur geh ren unter anderem die Unterst tzung langer Portabilit t von Software Systemen Seite 54 Dateinamen und ein dynamischer Cache f r Zugriffe auf Dateien und das Netzwerk Die Dateisystemverwaltung wird durch den IFS Manager geregelt Installable File System Manager Das Block I O Subsystem von Windows 9x erweitert die 32 Bit Plattenzugriffe gegen ber Windows 3 1 Damit erh ht sich die Geschwindigkeit des gesamten Dateisystems hnlich wie unter Windows 3 1 besteht der Systemkern von Windows 95 aus drei Komponenten User Kernel und GDI Graphical Device Interface Jede Komponente besteht aus einem Paar von DIl s einer DI f r 16 Bit Systeme und einer f r 32 Bit Systeme die alle Dienste f r Anwendungen enthalten Hier spiegelt sich der Kompromi zur R ckw rtskompatibilit t wieder Windows 9x benutzt weiterhin alten 16 Bit Code wenn entweder die Kompatibilit t zu alten Anwendungen erhalten bleiben soll oder der 32 Bit Code die Speicheranforderungen erh ht ohne dabei die Ausf hrungsgeschwindigkeit zu verbessern Alle I O Subsysteme z B Netzwerkroutinen oder die Dateisysteme und die Ger tetreiber sind komplett in 32 Bit gehalten Ebenso die Komp
183. chiedliche Funktionalit t aufweisen auf dem Zielsystem die erforderlichen Funktionen nicht mehr zur Verf gung stehen In einem ersten Schritt wird zun chst die Anzahl der unterschiedlichen Betriebssystem Aufrufe bestimmt Hierzu braucht der Porteur spezielle Kenntnisse der Host und Zielumgebung die jedoch in einer Portabilit tsbibliothek f r die syntaktische Analyse gesammelt und durch ein entsprechendes Werkzeug verf gbar gemacht werden k nnen Solch ein Werkzeug ist das bereits vorgestellte Porttool mit der zugeh rigen Portierungs bzw Problembibliothek Port ini siehe Anhang B Das erste zu ermittelnde Ma lautet BAM Anz BSR Anz BSR mit f De f vergleiche Kapitel 3 2 3 4 BSR i ter unterschiedlicher BS Aufruf i 1 n Nach der Anwendung von Porttool auf die Quellen und Auswertung der Ergebnisse ergibt sich f r die Anzahl der Betriebssystemaufrufe BSM Anz BSR Anz BSR 3 siehe Anhang F Wird eine Portierung vorgenommen f llt dieses Ma aufgrund von Erfahrungswerten deutlich differenzierter aus Die aus Portierungserfahrungen gewonnenen Aufwandswerte m ssen dann f r weitere und somit genauere Aufwandsabsch tzungen nutzbar gemacht werden Hierbei werden nicht nur Aufwandswerte dokumentiert sondern auch wie konkrete nderungen durchzuf hren sind Hierzu z hlt ebenfalls die Dokumentation der verwendeten Werkzeuge Weiterhin kann es sich zeigen da manche Aufrufe nicht an
184. con s TScan TScanCmd y TScsParameters A TSetAdjustmentParam TSetupAreaScan j TSetupContinuousScan TSetupScanCmd TSetupStepScan TShowValueCmd TSteering TStoe_Psd i TTopographyExecute Tx OMAN oO Ga OO A MG A A OU GO PANNA ANWNAWAWNWWAWANNAHANAWAANAN WH gt A WD wae Ze O O O OO O O ee e OU e OU WS WS WS WS ee e e OU OU se WS OU OU WTS e OU TNS e TNS OU ee e Ze Fee ee e Fe ee Fee ee e Fe ee a Y N BIBM Anzahl aller Komponenten mit BIB Anpassungen _ 54 0 667 Anzahl aller Komponenten 81 BIB BIBM BIBM BIBM 353 BIBM 0 667 Anhang F Daten der Quelltextanalyse Seite 212 F 1 3 Ermittlung der Ma komponente Software Umgebung zum Ma SU siehe Kapitel 4 2 1 1 PAN 4 BSM BIBM UTM 3 353 0 356 KOMP BSM BIBM UTM TAbout TAdjustmentExecute TAdjustmentWindow TAm9513a TAngleControl TAquisition TAreaScan TAreaScanCmd g TAreaScanParameters TBitmapSource 3 TBraun_Psd i TC_812 TC_812GPIB e TC_832 TCalibrate f TCalibratePsd TCmd g TCommonDevParam TCounterShowParam TCounterWindow TCurve TDC_Drive i TDevice TDList TEditWindow TEncoder TExecuteCmd TGenericDevice TMacroExecute f TMain TMDIWindow TMList TModalDlg TModelessDig TMotor TMotorParam TPlotData R TPosControl TPsd TPsdRemoteSync TRadicon TScan A
185. cpp 571 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_arscan cpp 596 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 SendMessage M_arscan cpp 662 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage M_arscan cpp 726 M_arscan cpp 739 M_arscan cpp 874 M_arscan cpp 935 mMoveT mMoveT FORWA FORWA O RD_WM_COMMAND RD_WM_COMMAND hwnd cm_ParamSe hwnd cm_ParamSe Distance mGetValue Distance mGetValue Width oDistance mGetValue Distance mGetValue Width hwndCtl 0 SendMessage hwndCtl 0 SendMessage Anhang F Daten der Quelltextanalyse Seite 209 M_arscan cpp 946 M_arscan cpp 1050 M_arscan cpp 1206 M_arscan cpp3017 M_arscan cpp 3051 M_arscan cpp 3059 M_arscan cpp 3064 M_arscan cpp 3337 M_arscan cpp 3412 M_arscan cpp 3507 M_arscan cpp 3514 M_curve cpp 236 M_data cpp 2473 M_data cpp 2486 M_data cpp 2496 M_data cpp 2512 M_data cpp 2525 M_data cpp 2535 M_data cpp 3407 M_dlg cpp 1233 M_dlg cpp 1346 M_dlg cpp 2782 M_dlg cpp 3050 M_dlg cpp 3058 M_dlg cpp 3141 M_layer cpp 509 M_layer cpp 519 M_layer cpp 270 layer cpp 239 layer cpp 352 layer cpp 364 layer cpp 120 Z EXE EXE FE layer cpp 126 M_layer cpp 539 M_main cpp 547 M_main cpp 601 M_main cpp 249 M_main cpp 279 M_main cpp 315 M_main cpp 325 M_main cpp 501 M_main cpp 1008 M_main cpp 1033 M_main cpp 1119 M_main cpp 1124 M_main cpp 1127 M_main cpp 1129 M_main cpp 1140 M_main cpp
186. d einzugehen und diese zu klassifizieren 2 2 3 1 Portable C und C Software Systeme Blickt man zun chst auf die Sprachebene von Windows Programmen unabh ngig von spezifischen Betriebssystemen oder Entwicklungswerkzeugen auf der Basis der Programmiersprachen C bzw C so lassen sich allgemeine Richtlinien erkennen die konsequent angewendet zu portableren Software Systemen f hren Portabilit t von Software Systemen h ngt nicht nur von der Uniformit t der Programmierschnittstellen ab sondern ist auch ein kennzeichnendes Merkmal von Quelltexten unabh ngig vom Zielsystem Der Aufwand f r die Portierung eines Windows basierten Software Systems h ngt einerseits von der m glichst r ckw rtskompatiblen Gestaltung der zur Verf gung stehenden Windows API ab Andererseits m ssen die zu portierenden Quellen bestimmten allgemeinen Portabilit tsgrunds tzen gen gen damit die Portierung nicht zu aufwendig wird Sprachstandards Der erste Schritt zu portablen Software Systemen f hrt ber die Benutzung einer standardisierten Hochsprache Ein solcher Sprachstandard wird dann entwickelt wenn eine Reihe von widerspr chlichen Implementierungen existieren die es zu vereinigen gilt So gibt es mehrere Lieferanten oder Versionen von Compilern f r bestimmte Hochsprachen und Betriebssysteme Dies f hrt dazu da einige Compiler die Quellen nicht einheitlich bersetzen Die Einhaltung eines Sprachstandards stellt aber noch keine Garantie f r
187. d entsprechen den Techniken einer syntaktischen Analyse eines Compilers d h sie k nnen automatisch durchgef hrt werden Daneben kann die Vermessung des Einflu faktors Komplexit t ebenfalls mit entsprechenden Werkzeugen durchgef hrt werden wobei hierbei ebenso der Quelltext des Software Systems zugrunde gelegt wird Die Einflu gr e Dokumentation kann nicht automatisch auf ihre Qualit tsaspekte hin untersucht werden Diese kann aber wesentlichen Einflu auf den Portierungsaufwand haben Die Messung erfolgt durch manuelle Inspektion in Form eines sogenannten Code Reviews Hierbei sind alle wesentliche Dokumentationsteile in Form einer Checkliste aufgef hrt Dieses Vorgehen setzt jedoch bestimmte Kenntnisse des Porteurs voraus die eine gewisse Subjektivit t in das Ma einbringen und deren Bestimmung einen gewissen Aufwand erfordert Es entsteht hierbei ein notwendiger Kompromi zwischen geforderter Objektivit t und konomie des Portierungsma es Die G te von Portierungswerkzeugen zeigt sich erst nach durchgef hrter Portierung Vor der Portierung l t sich nur deren Existenz feststellen F r die genaue Beurteilung von Portierungswerkzeugen ist jedoch ein intensives Einarbeiten notwendig Aus diesem Grund ist hierf r keine direkte Messung vorgesehen Die Portierungswerkzeuge gehen jedoch ber die bewerteten nderungsaufw nde indirekt in das Portierungsma ein spielen aber bei der Vermessung des XCTL Systems k
188. damit eine Kenngr e f r die Anzahl Vorg nger die Einflu auf die betrachtete Klasse haben k nnen Um die Eigenschaften einer Klasse vollst ndig zu ermitteln mu die Vererbungshierarchie bis zur Wurzelklasse durchsucht werden da eine Basisklasse auch die Eigenschaften f r abgeleitete Klassen definiert Bei der Verwendung von Programmiersprachen in denen Klassen stets als Spezialisierung von Systemklassen definiert werden z B in Smalltalk Object als generelle Oberklasse ergeben sich allgemein h here Me werte f r die Klassen Dies gilt auch bei der Verwendung von Klassenbibliotheken Es wird empfohlen die Z hlung unterhalb der Klassenbibliotheken zu beginnen Man kann sagen je gr er der Wert von DIT f r eine Klasse C ist desto gr er ist die Wahrscheinlichkeit des Auftretens von Fehlern hohe Signifikanz Balzert 98 Abbildung 18 Beispiel f r das Ma DIT Metriken und Portierungsaufwand Seite 98 Ein Beispiel soll die Verwendung der DIT Metrik veranschaulichen Hierbei ist die Wurzel der Hierarchie die Klasse A DIT A 0 F r die Klassen B und C ergeben sich DIT B DIT C 1 Demzufolge hat die Klasse E den Wert DIT E 3 weil der maximale Weg von Klasse A zu Klasse E ber die Klassen B und D verl uft 3 1 4 3 CBO Coupling between Object Classes Eine weitere ebenfalls von Shyam Chidamber und Chris Kemerer Chidamber 94 definierte OO Metrik ist CBO Coupling between Object Cla
189. das XCTL System ermittelte Ma PAN ys gibt Auskunft dar ber wie hoch die Gesamtzahl der potentiell anzupassenden Systemelemente ist Diese ergeben sich aus den Unterschieden von Host und Zielumgebung und vermitteln einen ersten Eindruck ber den zu erwartenden Umfang der Portierungsarbeiten Im Falle des XCTL Systems war hierbei die Hostumgebung Windows 3 1 16 Bit und die Zielumgebung Windows 98 32 Bit PAN ys 956 Das zweite Ma KOMP liefert die Namen der potentiellen Anderungskandidaten mit der jeweiligen Anzahl anzupassender Systemelemente siehe Abbildung 26 F r das XCTL System wird damit ausgesagt in welchen Systemkomponenten der gr te Portierungsaufwand zu erwarten ist und es kann daraus gefolgert werden welche Komponenten des Software Systems mit relativ geringem Aufwand portiert werden k nnen Hierbei entstand das Problem der Zuordnung von Systemelementen die in keiner Systemkomponente klassifiziert wurden da das XCTL System bisher nicht durchg ngig objektorientiert implementiert ist Diese Elemente wurden f r die durchgef hrte Portabilit tsanalyse in einer gedachten Systemkomponente Tx gekapselt und so der Vermessung zug nglich gemacht Somit k nnen die hier zur Verf gung stehenden Informationen als erste Entscheidungstr ger f r oder gegen eine Portierung herangezogen werden Sind die Umgebungszugriffe breit ber das gesamte Software System gestreut mu sich der Porteur u U in viele Systemteile eina
190. den ebenfalls uneinheitlich definiert Zuse sieht das Software Ma als strukturvertr gliche Abbildung mit homomorphen Eigenschaften zwischen der empirischen Welt und der Welt der Zahlen Ein Ma wird von ihm definiert als empirische Relation zwischen den beteiligten Objekten dieser beiden Mengen Schmidt Schmidt 87 definiert den Begriff Maf allgemein wie folgt Sei A eine beliebige Menge und P A deren Potenzmenge Eine Abbildung m P A gt R hei t ein Ma auf P A wenn gilt Jm 4 VA eP A 20 VA e P A m A 0 falls A m A VA V UA m A m A m A f r jede Folge paarweise disjunkter Teilmengen A A 4 P A Bei der Komplexit t nach McCabe beispielsweise wird eine zyklomatische Zahl ermittelt um so die logische Komplexit t eines Software Systems zu messen Die zyklomatische Komplexit t eines sogenannten Kontrollgraphen wird durch die Formel v G e n 2p ermittelt siehe Kapitel 3 1 3 5 Hat man zwei Kontrollgraphen G mitv G 2 und G mit v G 1 so kann folgendes gesagt werden Die Menge der Kontrollgraphen eines Software Systems sei A und im Beispiel ist somit 4 G G Die Abbildung v A gt R sei eine Funktion die jeden Graphen auf seine zyklomatische Zahl abbildet Weiterhin sei eine Funktion m P AJ gt R mit m B v a definiert wobei BCA und a eB Die Potenzmenge von A ist PA Go Ga G G dh m 0 m G w G 2 m G w G 1 und m G G
191. dener Portierungserfahrung BIBM SAyp BA mit SA yg Anz BIBR Anz BIBR Gesamtzahl der Aufrufe von Bibliotheksroutinen zu denen keine Aufw nde vorliegen BA yp Anz BIBR B Anz BIBR B Summe der bewerteten Bibliotheksroutinen fiir die ein Aufwand vorliegt B Aufwand f r die Anpassung des Aufrufs der i ten Bibliotheksroutine i 1 7 Einarbeitungsaufwand BIBM KOMP Anz BIBA KOMP n Anz BIBA mit KOMP i te Komponente des Programms 1 n BIBA anzupassender Aufruf einer Bibliotheksroutine Verh ltnis Gesamtkomponenten zur Anzahl anzupassender Komponenten Metriken und Portierungsaufwand Seite 112 BIBM Anzahl aller Komponenten mit BIB Anpassungen g Anzahl aller Komponenten Utility Aufrufe UT UTM UTM UTM mit UTM UTM oder UTM abh ngig von der gegebenen Situation Anzahl Utility Aufrufe UTM Anz UTR Anz UTR mit UTR i ter unterschiedlicher UT Aufruf i 1 7 Anzahl Utility Aufrufe bei vorhandener Portierungserfahrung UTM SAyr BAyr mit SA y Anz UTR Anz UTR Gesamtzahl der Aufrufe von UT Routinen zu denen keine Aufw nde vorliegen BA Anz UTR B Anz UTR B Summe der bewerteten UT Routinen f r die ein Aufwand vorliegt B Aufwand f r die Anpassung des Aufrufs der i ten UT Routine i 1 n Einarbeitungsaufwand UTM KOMP Anz UTA KOMP n Anz UTA mit
192. der Einzelma e DOK pp 0 6 0 5 0 4 1 0 7 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 169 4 2 3 3 Programminterne Dokumentation DOK y Programminterne Dokumentation KK KS AF NL Komponentenkopf Kommentarzeilen u ere Form Namensgebung Klassenbeschreibung Autor Erstellungsdatum Import Export Abh ngigkeiten KB AE Methoden Systemkomponenten A Methoden und Attribut IE 5 beschreibung MB Neben der externen Dokumentation der Quellen wie z B Verzeichnisse der Quelldateien des Software Systems etc wird bei der programminternen Dokumentation der ber die Codezeilen hinausgehende dokumentierende Informationsgehalt in den Quelltexten bewertet Eine gute programminterne Dokumentation erm glicht dem Porteur eine schnelle Einarbeitung in die Quellen und deren einfache Bearbeitung Au erdem stellt sie dem Porteur alle wichtigen Informationen der zu bearbeitenden Softwarekomponente u a nach den Prinzipien der integrierten Dokumentation direkt in den Quellen zur Verf gung Zu den wichtigsten programminternen Informationen z hlen Komponentenkopf Kommentarzeilen u ere Form Namensgebung Diese werden nacheinander manuell ermittelt und zur Ma komponente Programminterne Dokumentation zusammengef hrt Komponentenkopf Der Kopf einer Systemkomponente sollte deren Beschreibung beinhalten Also die Beschreibung der Aufgabe der Komponente um nicht erst den Quelltext analysieren ode
193. der prinzipiellen Unterschiede der aufgef hrten Programmierparadigmen zeigt welcher Zusammenhang zwischen den klassisch prozedural implementieren und den objektorientierten Software Systemen besteht Im folgenden sollen nun die Teilma e des betrachteten Portabilit tsma es auf die Verwendung im objektorientierte Bereich untersucht werden System Umgebung Bei der Ma komponente System Umgebung werden die Anweisungen des Software Systems identifiziert und bewertet die im Verlauf einer Portierung bedingt durch Unterschiede in der Host und Zielumgebung angepa t werden m ssen Bei den Ma en f r die Software und Hardware Umgebung werden die Systemkomponenten des Software Systems auf spezielle Zugriffe in die Systemumgebung hin vermessen die bei der Portierung potentielle nderungsaufw nde verursachen k nnen Bei der Software Umgebung sind dies Betriebssystem Aufrufe Aufrufe von Bibliotheksroutinen und Aufrufe von sonstigen Hilfsroutinen Analog hierzu werden bei der Hardware Umgebung maschinenabh ngige Zugriffe und Zugriffe auf Peripherieger te untersucht Metriken und Portierungsaufwand Seite 126 Beide Teilma e bewegen sich damit innerhalb einer Prozedur bzw Funktion Einhaltung der Prinzipien der strukturierten Programmierung vorausgesetzt und bewerten die Anweisungen innerhalb des Anweisungsblocks einer solchen Systemkomponente Diese Ma e lassen sich somit auch auf die Komponenten einer Klasse den Methoden anwenden
194. des Gesamtma es der Hardware Umgebung folgendes Tupel HU PAN yyy KOMP yy VKG 1 600 KOMP 0 395 KOMP MAM PGM TAdjustmentWindow 3 TAm9513a 47 TareaScan y 4 TBitmapSource 17 TBraun_Psd 40 TC_812 20 TC_812GPIB 6 TC_812ISA 2 TC_832 23 TChooseDeviceCmd 1 TCounterShowParam 1 TCounterWindow 1 TDC_Drive 4 Tdevice 9 TeditWindow j 4 Tencoder 1 TGenericDevice i 6 Tmain 9 TMDIWindow 6 1 1 9 4 2 6 0 0 4 1 2 4 TmodalDlg TmodelessDlg f Tmotor TmotorParam e TOptimizeDC_812 i TplotData TPsd Tradicon Tscan TscanCmd TSetupContinuousScan TStoe_Psd E eel a Tx 4 2 1 3 Programmiersprachen Bei diesem Ma soll bestimmt werden wie hoch die nderungsaufw nde sind die durch Unterschiede in der verwendeten Programmiersprache auf Host und Zielrechner entstehen Diese unterscheidet sich entweder in ihrem Dialekt oder ist eine v llig andere soda die Konstrukte die in der jeweiligen Zielsprache nicht vorhanden sind an diese angepa t werden m ssen Um dieses Ma berechnen zu k nnen m ssen jedoch Informationen der Zielsprache in Form geeigneter Beschreibungen vorliegen Fehlen solche Beschreibungen so macht es anders als z B bei den BS Aufrufen wenig Sinn nderungskandidaten zu ermitteln da diese ja die Menge aller Ausdr cke sein
195. det werden Pr prozessoren sind gr tenteils eng mit einer Programmiersprache verbunden z B C Pr prozessor oder sind explizit f r eine Programmiersprache entwickelt worden z B RATFOR Eng im Zusammenhang mit Pr prozessoren stehen die meist darin enthaltenen oder auch eigenst ndigen Makroprozessoren Diese untersuchen ein Programm auf die Benutzung sogenannter Makros bzw deren Aufrufe LeCarme 89 Makroaufrufe werden vom Makroprozessor durch definierte Zeichenketten ersetzt die in Makrodefinitionen angegeben worden sind Im Rahmen der Portabilit t von Software Systemen werden Makroprozessoren daf r eingesetzt Portabilit t von Software Systemen Seite 27 Systemabh ngigkeiten durch entsprechende Makrodefinitionen zu beherrschen Man unterscheidet hierbei drei Kategorien von Makroprozessoren Makroassembler syntaktische Makroprozessoren und General purpose string processing Makroprozessoren z B STAGE2 Letztere spielen bei der Portabilit t die wichtigste Rolle weil sie nicht an eine bestimmte Assemblersprache gebunden sind und somit eine gr ere Umgebungsunabh ngigkeit bieten Makrodefinitionen die Systemabh ngigkeiten beinhalten werden hierbei als Definition einer Art abstrakten Maschine aufgefa t Auf dieser l uft dann die portable Software welche in der entsprechenden Makrosprache formuliert wurde Um das Software System in verschiedenen Systemumgebungen ausf hren zu k nnen m ssen die Makrodefinitionen jeweils a
196. die Ermittlung des Qualit tsmerkmals Portabilit t des XCTL Systems Auf der Grundlage des vorgestellten Portabilit tsma es wird hierbei der Versuch unternommen aufgrund von gemessenen Kenngr en richtungsweisende Aussagen zur Portabilit t des analysierten Software Systems zu machen Ausgehend von der in Abbildung 25 dargestellten Portabilit tsanalyse am Beispiel des XCTL Systems Seite 136 Ma baumhierarchie werden die einzelnen Einflu gr en bestimmt und zu einem Aufwandsma f r die Portierung aggregiert Anzahl untersch Aufrufe BSM1 Portinfo differenziert BSM1 Batriebesystem Aufrufe BS Komponenten mit jew Gesamtzahl BSM2 Komponentenverhaeltnis BSM3 Anzahl untersch Aufrufe BIBM1 Portinfo differenziert BIBM1 Software Umgebung SU Bibliotheksroutinen Aufrufe BIB Komponenten mit jew Gesamtzahl BIBM2 Komponentenverhaeltnis BIBM3 Anzahl untersch Aufrufe UTM1 Portinfo differenziert UTMT Utility Aufrufe UT Komponenten mit jew Gesamtzahl UTM2 System Umgebung SYS Komponentenverhaeltnis UTM3 Anzahl untersch Zugriffe MAM1 Maschinenarchitektur MA Komponenten mit jew Gesamtzahl MAM2 Komponentenverhaeltnis MAM3 Hardware Umgebung HU Anzahl untersch Zugriffe PGM1 Pheripheriegeraete PG Komponenten mit jew Gesamtzahl PGM2 Komponentenverhaeltnis PGM3 Anzahl untersch Konstrukte PS1 mehrere Prog sprachen PS1
197. die Portabilit t von Software Systemen dar Viele Standards sind unvollst ndig und definieren verschiedene Merkmale einer Sprache bewu t unvollst ndig Somit suggerieren Sprachstandards den Eindruck einer genauen Spezifikation Sie Portabilit t von Software Systemen Seite 45 definieren eine Sprache aber niemals vollst ndig soda unterschiedliche Implementierungen g ltige aber dennoch inkompatible Interpretationen vornehmen k nnen Dennoch ist die Einhaltung von Sprachstandards wie der offizielle ANSI ISO Standard f r C bzw der ISO Standard f r C eine notwendige Bedingung f r portable Programmierung Den unterschiedlichen Spracheigenschaften und verschiedenen Implementationen eines Sprachstandards in bestimmten Compilern begegnet man gr tenteils mit der Programmierung im sogenannten Mainstream Hierbei benutzt man nur die Eigenschaften eines Sprachstandards f r welche die Sprachdefinition eindeutig ist und die Implementierung durch den Compiler feststeht Konstrukte die sich au erhalb des Mainstreams befinden und von den aufgestellten Standards nicht eindeutig definiert werden sind z B die Gr e von Datentypen die Reihenfolge der Auswertung von Operanden Seiteneffekten und Funktionsargumenten die Vorzeichenbehaftung von Zeichen arithmetisches oder logisches Verschieben die Byte Reihenfolge die Ausrichtung von Strukturen und Klassenelementen und Bit Felder Eine Faustregel besagt
198. die sequentielle Verkn pfung aber auch Schleifen oder die Auswahl kommen hierbei in Betracht Klassische Metriken Metriken und Portierungsaufwand Seite 125 werden auf den beschriebenen Kontrollstrukturen definiert und haben damit den hier vorgestellten G ltigkeitsbereich Bei objektorientierten Software Systemen kann das System als eine Menge von Klassen mit bestimmten Eigenschaften erg nzt um zwei Relationen auf dieser Menge der Vererbungs und Benutzt Relation verstanden werden Die Eigenschaften einer Klasse werden durch ihre Attribute festgelegt und als Instanzvariablen dargestellt Klassen beschreiben dar ber hinaus das Verhalten von Objekten bei der jede Instanz einer Klasse Objekt ber den gleichen Satz solcher Variablen verf gt Das Verhalten von Objekten wird mit sog Methoden definiert mit denen auf Botschaften an ein Objekt reagiert wird Auch k nnen Klassen solche Methoden enthalten die durch entsprechende Nachrichten an die jeweilige Klasse angesto en werden und analog hierzu kann es Variablen geben die global von allen Instanzen gemeinsam benutzt werden Die interne Beschaffenheit einer Methode die der Systemkomponente bei der prozeduralen Programmierung entspricht ist stark abh ngig vom konkreten OOP Modell Der eigentliche Programmcode wird stets in den Methoden gekapselt und durch eine Nachricht an ein Objekt ausgel st Die Nachricht kann parametrisiert sein was bedeutet da die korrespondierende Methode in d
199. doc req e2 Metriken und Portierungsaufwand Seite 105 Mooney beschreibt wie der Aufwand einer Portierung zustande kommt bzw welche Einflu gr en hierbei eine Rolle spielen und zeigt welche Einflu gr en das Verh ltnisma Grad der Portabilit t zus tzlich bestimmen In Beispielen Computerspiel Compiler wird gezeigt wie der Grad der Portabilit t praktisch bestimmt wird Es werden Annahmen dar ber getroffen welche Werte die Einflu gr en haben k nnten Es fehlen jedoch konkrete Angaben dar ber wie die einzelnen Einflu gr en gemessen werden und wie sich diese im Einzelnen zusammensetzen Einen praktischeren Vorschlag liefern dagegen McCall et al McCall 77 die eine Reihe von Faktoren innerhalb eines Qualit tsmodells identifizieren die das Merkmal Portabilit t beeinflussen Ihre Einflu faktoren setzen sich zusammen aus Modularit Selbstbeschreibung Maschinenunabh ngigkeit sowie Software Systemunabh ngigkeit Zu diesen Faktoren stellen sie dann einige Ma e auf So lautet beispielsweise ein Ma des Faktors Software Systemunabh ngigkeit _ Anzahl Module mit Betriebssystemreferenzen Gesamtzahl der Module M 1 F r den Faktor Maschinenabh ngigkeit schlagen die Autoren z B das bin re Ma M benutzte Programmiersprache existiert auf anderen Maschinen vor Es wird verdeutlicht da die Portabilit t nicht direkt bestimmbar ist sondern aus verschiedenen me baren Faktoren abgeleitet
200. e Effizienz eines Software Systems zu erf llen Solche Programmteile sind in der Regel immer mit Portierungsproblemen behaftet Bei der Benutzung von Betriebssystemschnittstellen durch h here Programmiersprachen stellt sich zun chst das syntaktische Problem der unterschiedlichen Sprachdialekte Die Ursache hierf r sind Spracherweiterungen oder das Weglassen von Sprachkonstrukten bei verschiedenen Compilern Dabei treten Portierungsprobleme immer dann auf wenn die Portierung auf einen Zielrechner erfolgt dessen Compiler einen geringeren Sprachumfang realisiert als der Compiler auf dem Hostrechner Eine L sung hierzu bieten Sprachstandards die einen einheitlichen Sprachdialekt f r verschiedene Compiler einer Programmiersprache definieren Aber auch hier treten Portierungsprobleme durch unterschiedliche Repr sentation von eingebauten maschinenabh ngigen Datentypen auf die nicht vollst ndig im Sprachstandard erfa t sind Neben den Syntaxproblemen gibt es aber auch Probleme im semantischen Bereich von Programmiersprachen welche dahingehend zumeist nicht exakt genug definiert sind Dazu geh ren z B die Reihenfolge der Auswertung bei Mehrfachbedingungen die Werte von Schleifenvariablen nach dem Verlassen einer Schleife sowie Mechanismen zur Parameter bergabe Hier sollte beispielsweise berpr ft werden ob eine voreingestellte Art zur Parameter bergabe wie z B call by value oder call by refererence etc existiert Ein we
201. e m ssen bei einer bertragung in eine andere Umgebung oft zu gro en Teilen neu geschrieben werden und stellen f r die Autoren daher kein Ma objekt dar Den Schwerpunkt der Anwendung des Ma es legen sie deshalb auf Anwendungssoftware Metriken und Portierungsaufwand Seite 107 3 2 3 3 Ma faktoren Auf der Grundlage des bereits vorgestellten Portierungsmodells siehe Abbildung 4 werden verschiedene Einflu faktoren identifiziert die den Aufwand einer Portierung beeinflussen k nnen Unterschiede in den Systemumgebungen der Host und Zielrechner Komplexit t des zu portierenden Software Systems bzw von Systemkomponenten Dokumentation Portierungswerkzeuge Erfahrungen und Kenntnisse des Porteurs Hierbei wird festgestellt da die Faktoren Portierungswerkzeuge sowie Erfahrungen und Kenntnisse des Porteurs schwer zu messende Einflu gr en darstellen Die G te von Portierungswerkzeugen zeigt sich nach Ansicht der Autoren erst wenn man sich intensiv in diese eingearbeitet hat und dessen Anwendung ausreichend erprobt hat Erst dann ist nach ihrer Ansicht eine realistische Beurteilung seiner M glichkeiten denkbar Aus diesem Grund wird die G te von Portierungswerkzeugen nicht direkt gemessen sondern geht ber die Bewertung von nderungsaufw nden indirekt in das Ma ein Mit Erfahrungen und Kenntnisse des Porteurs sind sowohl allgemeine Erfahrungen wie z B Programmiererfahrung als auch spezielle Erfahrungen i
202. e Gr en oder gemeinsam benutzte Datenbereiche gibt es nicht Das Geheimnisprinzip wird eingehalten Sind diese Voraussetzungen erf llt kann man demnach die berpr fung von Prozedurkopplungen auf die Fragen Liegt eine reine Datenkopplung vor und Handelt es sich um eine schmale Schnittstelle konzentrieren Sie sind nur durch manuelle Pr fmethoden beantwortbar Es kann u U recht schwierig sein reine Daten und Steuerdaten zu unterscheiden Hilfreich ist es hierbei auf die Beschreibung der Parameter zu achten Datenparameter werden meist durch Substantive Zustandsparameter welche von Kontrolldaten Steuerdaten zu unterscheiden sind durch Adjektive und Kontrollparameter durch Verben beschrieben Ist eine Prozedur durch eine Kontrollkopplung mit anderen Prozeduren gekoppelt mu man die Systemstruktur berpr fen was dazu f hrt alle betroffenen Prozeduren auf funktionale Bindung zu untersuchen Eine besonders un bersichtliche und nderungsunfreundliche Steuerungskopplung hat man wenn verschiedenen Wertebereichen eines Parameters unterschiedliche Bedeutungen zugeordnet werden Abschlie end kann gesagt werden da jedes Software System ein Minimum an Kopplung zwischen den einzelnen Komponenten ben tigt um die ihm gestellte Aufgabe zu erf llen Ziel der Software Entwicklung mu es daher sein zus tzliche und unn tige Kopplung zu vermeiden oder ganz zu eliminieren 3 1 3 2 Analyse der Bindungsart Die Bindung ist
203. e Ma f r solche Software Systeme konzipiert ist die den Prinzipien der strukturierten prozeduralen Programmierung folgen Vorschl ge f r die Anpassung an objektorientierte Software Systeme werden im Folgenden unterbreitet 3 2 3 6 Anpassung an objektorientierte Software Systeme Das betrachtete Ma ist speziell f r die Untersuchung prozedural programmierter Software Systeme entwickelt worden Es soll nun gekl rt werden inwieweit das vorgestellte Ma f r objektorientierte Software Systeme verwendbar ist Falls notwendig werden Vorschl ge unterbreitet wie das Ma f r objektorientierte Systeme anzupassen sein k nnte In der prozeduralen Programmierung besteht ein Software System aus Funktionen bzw Prozeduren die als Systemkomponenten berwiegend sequentiell miteinander verkn pft werden Die einzelnen Systemkomponenten umfassen hierbei einen Anweisungsblock mit den darin befindlichen Systemelementen und haben genau einen Ein und Austrittspunkt Die einzelnen Systemkomponenten und Systemelemente k nnen nun in verschiedenen Wechselbeziehungen zueinander stehen und bilden damit ein komplexes Software System Solche Kontrollstrukturen werden oft als Kontrollflu graphen dargestellt Anweisungen in einem Programm werden durch entsprechende Knoten symbolisiert und der bergang der Kontrolle einer Anweisung an eine andere Anweisung wird mittels gerichteter Kanten angezeigt Kombinationsregel auf solchen Kontrollgraphen ist berwiegend
204. echanismus Der frei verf gbare Speicher ist hierbei in 64 KB gro e Segmente aufgeteilt und wird mit Hilfe von zwei 16 Bit Adressen angesprochen der Segmentadresse und der Offsetadresse f r den Speicher innerhalb dieses Segments Aufgrund der Systemarchitektur von Prozessoren der Intel Baureihe lt 80386 k nnen hierbei insgesamt 16 MB Speicher adressiert werden obwohl theoretisch 4 GB m glich w ren Das Betriebssystem und die Anwendungen k nnen Speicher au erhalb eines Segments nur unter Leistungseinbu en ansprechen Windows 9x und Portabilit t von Software Systemen Seite 59 Windows NT nutzen die 32 Bit F higkeiten des 80386 Prozessors und seiner Nachfolger deren Architektur ein flaches lineares Speichermodell f r die Funktionen eines 32 Bit Betriebssystems und seiner 32 Bit Anwendungen unterst tzt Das Modell der linearen Speicheradressierung vereinfacht die Entwicklung von Anwendungen und beseitigt die Leistungseinbu en durch segmentierten Speicher Durch dieses lineare Speichermodell erm glicht Windows jeder 32 Bit Komponente des Betriebssystems den Zugriff auf 4 Gigabyte adressierbaren Speicher wobei jede 32 Bit Anwendung bis zu 2 Gigabyte privaten Speicher anfordern kann gemeinsamer virtueller Speicher segmentiert 386 Modus System Speicher insgesamt 16 MByte K1 386 Modus sichtbar f r Anwendungen und Kernel System und K2 Speicherverwaltung Segment Segment Segment Segmen
205. echend ihrer Aufrufe in verschiedenen Pfaden in die Berechung einflie en zu lassen D h jeder Aufruf einer Systemkomponente in einem neuen Pfad erh ht die Anzahl der Knoten und Kanten Die Zahl p f r die Zusammenhangskomponenten entspricht dann der Anzahl der Komponentenaufrufe Adamov Adamov 85 schl gt in diesem Zusammengang vor f r jeden Aufruf einer Komponente au er dem ersten die zyklomatische Komplexit t um zwei zu erh hen Grund hierf r ist die Entwicklung eines Programmkontroll Graphen siehe Kapitel 3 1 3 8 zu einem streng zusammenh ngenden Graphen wenn der Endknoten des Graphen mit dessen Anfangsknoten verbunden wird und bei jedem Komponentenaufruf ein Ein und Ausgangspfeil hinzukommt Beide Ans tze erh hen jedoch die zyklomatische Komplexit t soda die urspr ngliche Interpretation als Anzahl minimaler Pfade nicht mehr g ltig ist 3 1 3 6 Segment global usage pair Metrik Die Segment global usage pair Metrik geh rt zur Gruppe der Datenstruktur Metriken welche die Zugriffe auf Daten und Datenstrukturen in einem Software System analysieren und so die Komplexit t der Struktur des Software Systems oder dessen Komponenten messen Mit dieser Metrik wird die Anzahl der Lese oder Schreibzugriffe von Komponenten auf globale Variablen gemessen Basili 80 Die Messung von Zugriffen auf globale Variablen erfolgt durch Paarbildung P R Segment global usage pair wobei P eine Komponente ist die auf die glob
206. ed out the line metioning device32 d11 because I did not have that dl remove word _export from FramewndProc declaration lines m_arscan cpp and m_scan cpp add include lt direct h gt m_arscan cpp m_scan cpp m_device cpp m_justag h and m_justag cpp remove declarations of struct date and struct time and introduce SYSTEMTIME st instead change d da_year d da_mon d da_day to int st wYear int st wMonth int st wDay somewhere datum is used instead of d and zeit instead of t change t ti_hour t ti_min ti ti_sec to int st wHour int st wMinute int st wSecond change both getdate and gettime with GetLocalTime m_mothw h remove word CALLBACK from IpfnLimitwatch declaration line m_steerng cpp remove word _export from RecallSteering declaration line change atof to atoi in line cmp P1 TCParam atof pl Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 241 4 Changes to Resources main rc ICON BITMAP CURSOR resources delete inline definitions all except the first line Open the rc file in Borland IDE and use copy to clipboard of the resource and make new temporary resource in VC with the same attributes then use export command to save it to file Delete temporary resource and put the file name in the original ICON or BITMAP or CURSOR resource definition Tine to eliminate some duplicate resource id warnings change 1 to 1 in the corresponding LTEXT lines
207. edoch darin zu sehen da dieses Ma nur f r streng hierarchische Systeme entwickelt wurde und somit in seiner Anwendung auf diese Systemarchitektur beschr nkt bleibt 3 1 4 Produkt Metriken f r objektorientierte Software Systeme Analog zu den traditionellen Produktmetriken f r die Vermessung prozeduraler Software Systeme werden in diesem Abschnitt Metriken f r objektorientierte Software Systeme betrachtet Software Metriken im objektorientierten Bereich haben zum Teil andere Eigenschaften als klassische Metriken Unabh ngig davon werden Metriken f r prozedural strukturierte Systeme teilweise unver ndert oder in Teilen modifiziert bernommen Auf der Grundlage von berlegungen zur bertragbarkeit klassischer Metriken auf den objektorientierten Bereich werden f r die praktische Verwendung vorgeschlagene System und Komponentenmetriken vorgestellt Metriken und Portierungsaufwand Seite 95 3 1 4 1 bertragbarkeit klassischer Produkt Metriken auf OO Software Systeme Eine wichtige Fragestellung ist ob die klassischen Metriken f r den objektorientierten Bereich bernommen werden k nnen oder ob neue Metriken definiert werden m ssen Bindungsmetriken und Analyse der Bindungsart in objektorientierten Software Systemen Neben den vorgestellten traditionellen Metriken f r prozedurale Systemkomponenten strukturelle Komplexit t existieren eine Reihe neuerer oder modifizierter Produktmetriken f r objektorientierte
208. edoch existieren sehr viele inkompatible Zeichens tze sowie Erweiterungen f r Sprachen mit umfangreichem Zeichensatz und Sonderzeichen Bei der Registerverwendung entstehen die Probleme infolge der unterschiedlichen Nutzung durch den Rechner Die Hauptunterschiede liegen hierbei in der Verwaltung von Zwischenergebnissen Diese Portabilit t von Software Systemen Seite 21 m ssen explizit gespeichert werden falls nur ein Arithmetikregister zur Verf gung steht Bei Rechnern mit wenigen Registern und einem Stack f r Operanden und Ergebnisse erfolgt die Speicherung automatisch Explizite Speicherung von Zwischenergebnissen z B bei Rechnern mit einer Anzahl von Allzweckregistern Operanden werden aus dem Speicher geholt oder bei Rechnern mit Registersets Operanden m ssen in den Registern stehen ist nur dann erforderlich wenn die Anzahl der gleichzeitigen Zwischenergebnisse zu gro wird Somit kann ein Software System welches Stack Instruktionen verwendet nicht so leicht auf einen Zielrechner portiert werden der ber keine Stack Instruktionen verf gt Hierbei ist eine Anpassung in Form einer Stack Simulation notwendig Weiterhin k nnen unterschiedliche Instruktionss tze ebenfalls zu Portierungsproblemen f hren Die Art der Speicherorganisation hat ebenfalls gro en Einflu auf die Portierbarkeit eines Software Systems Man unterscheidet hierbei linearen segmentiert linearen und hierarchischen Speicher Bei linea
209. edr ckt Portabilit tsanalyse am Beispiel des XCTL Systems Seite 160 DK Y DK i l mit k Anzahl der Komponenten DK Datenkopplung der i ten Komponente DK d CBO d PA d DIT mit DK Datenkopplung der i ten Komponente i 1 k d d d Gewichtungsfaktoren der Datenkopplungsart CBO Anzahl der Datenkopplungen ber Botschaftswege der i ten Komponente PA Anzahl der Zugriffe auf public oder protected Datenelemente durch andere Klassen auf die i te Komponente DIT L nge des maximalen Weges in der Klassenhierarchie von der i ten Komponente bis zur Wurzel F r das XCTL System ergeben sich hierbei folgende Me werte ermittelt mit McCabe Toolset k DK gt DK 11 95 i l Hierbei ist anzumerken da bei der Vermessung des XCTL Systems keine ausreichenden Me werte f r den Zugriff auf globale Daten ermittelt werden konnten Vergleich Anhang F Der ermittelte Me wert betr gt f r jede Systemkomponente 0 d h da man theoretisch alle momentan als global deklarierten Klassenkomponenten auch als private deklarieren k nnte da auf keines von au en zugegriffen wird Damit geht diese Art der Datenkopplung bei der Portabilit tsanalyse des XCTL Systems zun chst nicht mit ein Aggregation zum Gesamtma Schnittstellenkomplexit t Das Gesamtma besteht aus den Ma zahlen f r die Bewertung der Kopplungsmechanismen und der Datenkopplungen Es wird wie folgt durch einen 2er Tupel gebildet
210. edural modularem Aufbau in dem vorgestellten Ma im Kapitel 3 2 3 nicht ber cksichtigt Es wurde bei der Bestimmung der Schnittstellenkomplexit t der Kopplungsmechanismus und die Datenkopplung Kommunikationsart einer Komponente unterschieden Die Kopplungsst rke bzgl des Mechanismus wurde ber die Summation der Anzahl der Kopplungen aller Komponenten ermittelt Analog hierzu erfolgte die Ermittlung der Kopplungsst rke bzgl der Datenkopplung durch Aufsummierung der Datenkopplungen einer jeden Komponente Kopplungsmechanismus Schritte zur Ermittlung der Ma komponente Kopplungsmechanismus Ermittlung RFC Ermittlung WMC Berechnung VK McCabe Toolset auswerten Berechnung der Ma komponente Kopplungsmechanismus KP Bei einem Portierungsma f r objektorientierte Software Systeme kam hinzu das zus tzliche Konzepte wie z B Klassen durch Vererbungsgraphen oder Objekte durch Assoziationen und Aggregationen sowie tempor re Botschaftswege gekoppelt sein k nnen F r objektorientierte Systeme waren deshalb die vorhanden Ma e entsprechend anzupassen Um bei objektorientierten Software Systemen die Anzahl von Systemkomponenten zu bestimmen die ber die vorgestellten Kopplungsmechanismen in Verbindung stehen eignete sich die RFC Metrik welche die Anzahl der Funktionen die durch Operationen einer Klasse aufgerufen werden intern und extern mi t Um den Aspekt der Vererbung zu ber cksichtigen wurde
211. ei dem Einsatz objektorientierter Zusatzbibliotheken gibt es Verluste haupts chlich im Bereich der Flexibilit t Eine portable Zusatzbibliothek kann nur den kleinsten gemeinsamen Nenner aller unterst tzten Systeme wirklich brauchbar umsetzen Je gr er die Unterschiede d h je mehr Systeme unterst tzt werden desto kleiner wird auch der Kern der von dieser Bibliothek portabel abgedeckt wird Dar ber hinaus bezahlt man die Portabilit t seines Software Systems mit der Abh ngigkeit zu einem bestimmten Hersteller und die Einarbeitung in das entsprechende Programmiermodell erfordert zus tzlichen Zeitaufwand Insgesamt erh ht der Einsatz von Zusatzbibliotheken jedoch die Portabilit t und Wiederverwendbarkeit von Software Systemen bringt aber einen Verlust an Flexibilit t im Vergleich zur direkten Nutzung der einzelnen API s mit sich Portabilit t von Software Systemen Seite 73 Portabilit tsbibliotheken Selbst erschaffene Portabilit tsbibliotheken stellen ein weiteres Hilfsmittel f r die Portierung von Software Systemen dar Diese k nnen neben Funktionen die bestimmte Bereiche des Win32 API s portabel abdecken wie z B systemspezifische Hilfsfunktionen auch an das Zielsystem angepa te Makrodefinitionen enthalten z B f r portable Datentypdefinitionen Globale Programmier und Portabilit tsrichtlinien f r die Umsetzung bestimmter Programmierkonstrukte erleichtern zus tzlich den Erfahrungs und Informationsaustausch Hie
212. eils zwei der aufgef hrten F lle zusammen auftreten und die zyklomatische Zahl immer um einen Faktor drei erh ht wird wenn einer der genannten F lle auftritt Ist die zyklomatische Zahl einer Systemkomponente bestimmt so gibt McCabe zus tzlich eine Strategie zum Testen dieser Komponente an Ist die Differenz v ac wobei v die zyklomatische Komplexit t der Systemkomponente ist und ac die Anzahl der getesteten Pfade bezeichnet positiv so k nnen nach McCabe folgende drei Situationen gegeben sein Es m ssen weitere Tests durchgef hrt werden Die Komplexit t des Kontrollgraphen f r die Systemkomponente oder das Software System kann zu v ac reduziert werden Die Komplexit t von Teilen einer Systemkomponente oder des Software Systems kann durch das Einf gen von Code vermindert werden Ein gro er Vorteil der McCabe Metrik ist zun chst in deren einfachen Berechnung zu sehen So kann man beispielsweise die zyklomatische Zahl eines Kontrollflu graphen der nur aus einer einzigen Komponente besteht allein durch Abz hlen der Bedingungen ermitteln Die zyklomatische Zahl ist dann immer um den Wert 1 gr er als die Anzahl der Bedingungen Zudem weist sie eine hohe Korrelation zwischen der Anzahl der Entscheidungen einer Komponente der Komponenten Komplexit t und deren Fehlerh ufigkeit auf Dar ber hinaus hat sie den Vorteil da man ber die Anzahl linear unabh ngiger Programmpfade eine minimale Anzahl von Testf llen fi
213. ein qualitatives Ma f r die Kompaktheit einer Systemkomponente und spielt f r deren Produktqualit t eine entscheidende Rolle Man betrachtet hierbei die Beziehungen zwischen den Elementen einer Systemkomponente und untersucht wie eng diese miteinander verbunden sind Au erdem wird ber semantische Bindungsmetriken untersucht wie gro die Anzahl der Aufgaben ist die in einer Systemkomponente erledigt werden Nach Myers 75 werden hierbei folgende Bindungsarten unterschieden funktionale Bindung informale Bindung kommunikative Bindung prozedurale Bindung klassische Bindung logische Bindung und zuf llige Bindung Die Bindungsst rke nimmt hierbei von links nach rechts ab d h funktionale Bindung bindet st rker als informale Bindung wobei die zuf llige Bindung die schw chste Form der Bindung von Elementen einer Systemkomponente darstellt Bei der zuf lligen Bindung stehen die Elemente in keiner besonderen Beziehung zueinander D h jedes Element arbeitet autonom und ist nicht ber Beziehungen mit anderen Elementen der Systemkomponente verbunden Dies ist z B dann der Fall wenn ein Software System aus Speicherplatzgr nden in Komponenten aufgeteilt wird Eine logische Bindung einer Systemkomponente besteht wenn zwischen den Elementen eine logische Beziehung besteht So stellt beispielsweise die Zusammenfassung aller Eingabefunktionen in einer Systemkomponente eine logische Bindung dar Metriken und Portierungsaufwand Seite 87
214. einander bestimmt Sein Komplexit tsma bezieht sich in erster Linie auf Software Systeme mit streng hierarchischer Struktur d h mit einer Art Ebenen oder Schichtenarchitektur in der die Systemkomponenten Prozeduren einer Schicht nur auf Komponenten niedrigerer Schichten zugreifen k nnen Die Darstellung der Systemstruktur erfolgt mit Hilfe sogenannter Prozeduraufruf Graphen in dem aufgrund der Bedingung der strengen Hierarchie keine R ckpfeile erlaubt sind Metriken und Portierungsaufwand Seite 94 Betrachtet man zun chst die Komplexit t der Systemkomponenten so unterscheidet Adamov hier folgende vier Aspekte interne Komplexit t Positionskomplexit t nach innen orientierte Schnittstelle und nach au en orientierte Schnittstellenkomplexit t Die interne Komplexit t wird nach Adamov durch die Komplexit t des Kontrollflusses bestimmt Hierbei kann z B die Ermittlung der zyklomatischen Zahl nach McCabe ein brauchbares Ma liefern Die Postitionskomplexit t wird durch die Ebene bestimmt in der sich der Prozeduraufrufgraph befindet Hierbei legt man die Annahme zugrunde da streng hierarchische Systeme auf den oberen Ebenen wenige komplexe und auf den unteren Ebenen viele einfache Systemkomponenten besitzt Pyramidenstruktur Auch haben die Abst nde zwischen den Komponenten bzw sich aufrufenden Prozeduren Einflu auf die Komplexit t des Systems da sie die Abh ngigkeit der Komponenten von der Systemstruktur wid
215. eindeutig als notwendig zu ndernde Ausdr cke identifizieren So ist bei statischen Untersuchungen oft nicht zu erkennen auf welche Speicherstellen zugegriffen wird und ob hier nderungen berhaupt erforderlich sind Dieses darf als gewisse Eigenheit von Programmiersprachen angesehen werden und eine Aufwandsbewertung erscheint hier recht problematisch Das Portierungsma ist von den Autoren des vorgestellten Ma es im Kapitel 3 2 3 jedoch als ein erster allgemeiner Ansatz konzipiert worden der zun chst nicht auf die Besonderheiten einzelner Programmiersprachen abzielt und damit nur die Portabilit tsanalyse am Beispiel des XCTL Systems Seite 149 Aufrufe ermittelt die Aufw nde verursachen k nnen Die Ermittlung der Aufrufe die aufgrund von Maschinenabh ngigkeiten zu Portierungsproblemen f hren k nnen werden nun in einem ersten Schritt ermittelt Die Vorgehensweise entspricht dabei dem f r die System Umgebung Als erstes wird Zahl der MA Zugriffe f r das XCTL System ermittelt Hierbei wie auch bei den folgenden Ma en gelten die zuvor festgelegten Zuordnungskriterien zwischen den ermittelten Problemklassen und den Aufwandsma en MAM Anz MA Anz MA mit MA i ter unterschiedlicher MA Zugriff i n Die Zahl der identifizierten Maschinenabh ngigkeiten f r das XCTL System betr gt MAM Anz MA Anz MA 563 siehe Anhang F Da auch die Hardwareabh ngigkeiten bzw zugriffe ein Einarbeiten i
216. eine Rolle da hier noch keine entsprechenden Portierungserfahrungen einer Erstportierung vorliegen Portabilit tsanalyse am Beispiel des XCTL Systems Seite 138 Die Messungen erfolgen statisch soda hierbei Unterschiede die sich erst zur Laufzeit auswirken z B unterschiedliche Fehlerbehandlung auf Betriebssystemebene nicht erfa t werden Bei der XCTL Analyse werden die aufgezeigten Problemfelder bei Windows Portierungen von 16 nach 32 Bit wie folgt auf die Portabilit tsma e abgebildet Benutzung eines virtuellen linearen 32 Bit Adressraumes gt MAM Strikte Separation aller Prozesse bzw ihrer Adre r ume voneinander gt MAM Globale nderungen am Modell f r Benutzereingaben ber Tastatur und Maus gt BIBM Erweitertes Koordinatensystem und weitere nderungen im GDI gt BIBM Wegfall MS DOS gt BSM und 80x86 spezifischer Aufrufe gt MAM PGM Benutzung undokumentierter Win16 Eigenschaften gt BIBM Probleme bei der Nutzung von DIl s aufgrund von Architekturunterschieden gt MAM 4 2 1 System Umgebung In diesem Abschnitt werden die Codeteile des XCTL Systems ermittelt die aufgrund von Unterschieden der Host und Zielumgebung anzupassen sind Hierbei wird die System Umgebung in die Komponenten Software Umgebung Hardware Umgebung und Programmiersprachen unterteilt da sich die System Umgebung eher in den einzelnen Komponenten ndert statt vollst ndig Dadurch lassen sich
217. eiterte Datentypen beruecksichtigen LA SetClassLong fuer Werte die auf 32 Bit gewachsen sind SetCommEventMask SetCommEventMask Kein Win32 Aequivalent DOS Ersetzen durch SetCommMask SetEnvironment SetEnvironment Kein Win32 Aequivalent SEP SetFocus SetFocus GDI Lokalen Eingabestatus beruecksichtigen SetMessageQueue SetMessageQueue Unter Win32 nicht mehr erforderlich MBE Einfach loeschen SetMetaFileBits SetMetaFileBits Kein Win32 Aequivalent GDI Ersetzen durch portable SetMetaFileBitsEx SetResourceHandler SetResourceHandler Kein Win32 Aequivalent GDI SetSelectorBase SetSelectorBase Kein Win32 Aequivalent LA SetSelectorLimit SetSelectorLimit Kein Win32 Aequivalent LA SetSoundNoise SetSoundNoise Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetSwapAreaSize SetSwapAreaSize Kein Win32 Aequivalent LA SetSysModalWindow SetSysModalWindow Kein Win32 Aequivalent GDI SetViewportExt SetViewportExt Kein Win32 Aequivalent SEP Ersetzen durch portable SetViewportExtEx SetViewportOrg SetViewportOrg Kein Win32 Aequivalent SEP Ersetzen durch portable SetViewportOrgEx SetVoiceAccent SetVoiceAccent Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetVoiceEnvelope SetVoiceEnvelope Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetVoiceNote SetVoiceNote Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound supp
218. eme erbracht die sich in Polymorphismus und Vererbung voneinander unterscheiden Die Duplizierung von Programmteilen in prozeduralen Software Systemen erh hte die MeBwerte bei klassischen Metriken infolge des fehlenden Polymorphismus und der Vererbung Dies steht im Einklang mit der Forderung nach reduzierter Komplexit t durch Einf hrung objektorientierter Konzepte wie Polymorphismus oder Vererbung Somit haben sich die untersuchten klassischen Metriken als bedeutsam f r objektorientierte Programme erwiesen Trotzdem ist die Definition spezieller Metriken f r diesen Bereich notwendig In Lake 94 werden mit Hilfe von Korrelationsberechungen Aussagen zur bertragbarkeit klassischer Metriken getroffen Sie kommen zu dem Ergebnis da mit Hilfe klassischer Metriken Aussagen ber die Softwarequalit t objektorientierter Software Systeme gewonnen werden k nnen Dar ber hinaus gebe es aber weitere Einflu gr en die nur mit objektorientierten Metriken beschreibbar sind Bei Moreau 89 wird die bertragbarkeit klassischer Metriken verneint da diese nicht die Strukturelemente des objektorientierte Modells betrachten Es sei in diesem Bereich nicht m glich die Gesamtkomplexit t mit der Summe der Teilkomplexit ten zu bestimmen Werden klassische Metriken wie z B die zyklomatische Komplexit t nach McCabe auf objektorientierte Software Systeme angewandt dann haben sie nur f r Methoden in einzelnen Objekten ihre Anwendungsberechtigung
219. emente zu einer Systemkomponente zusammenzufassen die logisch zusammengeh ren und funktional gebunden sind 3 1 3 3 Programml nge Die Programml nge L P ist ein einfacher Vertreter der Umfangsmetriken und mi t die Anzahl an Programmzeilen eines Software Systems Die Idee bei der Ermittlung der Komplexit t eines Software Metriken und Portierungsaufwand Seite 88 Systems mittels Programml nge beruht im Wesentlichen auf der Annahme da eine Erh hung der Anzahl an Programmzeilen auch eine Erh hung der Komplexit t zur Folge hat Der Vorteil der Messung der Programml nge liegt in seiner einfachen Bestimmbarkeit So ist die Programml nge von Software Systemen relativ einfach zu bestimmen bzw wird von den meisten Compilern automatisch ermittelt Die Programml nge wird h ufig f r Kostenabsch tzung oder Produktivit tsuntersuchungen eingesetzt Wesentliche Nachteile entstehen aber sobald man Leer oder Kommentarzeilen mitz hlt oder Mehrfachanweisungen und mehrfache Funktionsaufrufe in einer Zeile ignoriert und somit u U unterschiedliche Arten von Software Systemen ber ein gemeinsames Programml ngenma vergleicht Auch wird hier nicht die Komplexit t der Beziehung zwischen den Programmkomponenten bewertet Somit ist die Programml nge eines Software Systems kein aussagekr ftiges Komplexit tsma um die verschiedenen Einflu faktoren der Komplexit t zu erfassen 3 1 3 4 Halstead Metriken Aufwendigere Umfangsmetriken a
220. en mittels empirischem Nachweis z B externe Validierung gegen Portierungskosten zulassen Existiert eine Funktion von der realen Welt in eine formale numerische Welt dann gibt es auch eine Skala auf der sich der Zusammenhang darstellen l t Das hier dargestellte Ma liefert zwar einen entsprechenden Me wert dieser l t sich bisher jedoch in keinen Zusammenhang mit der realen Welt bringen da bisher keine Portierungserfahrungen vorliegen welche eine entsprechende Zuordnung rechtfertigen Aus diesem Grund kann das vorliegende Ma in diesem Sinne als nicht normiert bzw standardisiert bezeichnet werden Um zwischen hnlichen Ma en w hlen zu k nnen m ssen Informationen zu den Ma en vorhanden sein aus denen hervorgeht was gemessen werden soll und inwieweit diese validiert sind Man kann diese Ma e dann miteinander vergleichen bzw in Relation zueinander setzen Da bisher keine vergleichbaren Ma e existieren und das vorhandene Ma auch nicht ausreichend validiert ist ist das G tekriterium Vergleichbarkeit ebenfalls nicht erf llt Die konomie ist ein wichtiges Kriterium f r die Akzeptanz eines Ma es Erfordert die Ermittlung der einzelnen Me werte einen hohen Aufwand kann von der Anwendung des Ma es abgesehen werden Das bedeutet die Me ergebnisse m ssen schnell und ohne gro en Vorbereitungsaufwand zustande kommen Die konomie eines Ma es h ngt stark von der Automatisierbarkeit der Me wertermittlung ab Auch hi
221. en und Objekten befindet sich noch im Forschungsstadium und ist ebenfalls noch nicht einheitlich definiert Balzert 98 Metriken f r Komponenten Auf intramodularer Ebene und dem Gebrauch von Umfangsmetriken der prozeduralen Komplexit t f r objektorientierte Systemkomponenten stellt sich prim r die Frage nach der Einbeziehung von Vererbung und Polimorphismus in die Zeilenz hlung Neben diesen Metriken sind spezielle Ma e f r die Breite und H he von Vererbungshierarchien die Anzahl der Klassen die eine spezielle Operation erben den Anteil wiederverwendeter Systemkomponenten die Anzahl der Objekt und Klassenattribute sowie die Anzahl der Objekt und Klassenoperationen notwendig Logische Strukturmetriken f r objektorientierte Komponenten wurden bisher in unver nderter Form bernommen Betrachtet man die Anwendung der zyklomatischen Komplexit t so stellt sich heraus da die Kontrollflu komplexit t objektorientierter Operationen in der Regel gering ist V G 1 und deshalb die zyklomatische Zahl als Ma zahl f r die Komplexit t einer Klasse nur bedingt geeignet ist Balzert 98 In Tegarden 92 wird die Verwendung der LOC Metrik die Halstead Metriken und die zyklomatische Komplexit t nach McCabe untersucht Hierbei wird die Ansicht vertreten da diese Metriken und Portierungsaufwand Seite 96 Metriken im objektorientierten Bereich sinnvoll angewendet werden k nnen Der Nachweis wird ber zahlreiche Beispielsyst
222. en API m glich w re Durch das Zur ckgreifen auf ausgetesteten Code sinkt die Fehlerquote in den damit entwickelten Software Systemen Die Kosten f r Pflege Wartung und Weiterentwicklung werden erheblich reduziert und sind damit ein entscheidender wirtschaftlicher Faktor Aber auch hier steigt der Komplexit tsgrad durch den immer gr er werdenden Funktionsumfang der Bibliotheken stetig an Damit w chst auch der Einarbeitungsaufwand f r den Entwickler Betrachtet man den Aspekt der Portabilit t von Windows basierten Software Systemen so sind viele der Bibliotheken auch auf anderen Plattformen erh ltlich und bieten somit eine Art von bibliotheksbedingter Plattformunabh ngigkeit die bei klassischer Programmierung ber die Windows API nicht gegeben ist Man kann jedoch zusammenfassend feststellen da die gemeinsame Basis aller Windows basierten Software Systeme sich in der dem Betriebssystem zugrunde liegenden Programmierschnittstelle widerspiegelt und der Weg zur besten Performance in der Regel ber einen C Compiler f hrt Somit soll die Windows API als unterste Abstraktionsebene des Portabilit t von Software Systemen Seite 44 Betriebssystems zusammen mit C bzw C als Programmiersprache die gemeinsame Grundlage f r weitere Betrachtungen bilden 2 2 3 Portierungsprobleme Windows basierter Software Systeme In diesem Kapitel geht es um die Klassifikation von Portierungsproblemen die auftreten k nnen wenn Software
223. en eine zentrale Aufgabe eines Betriebssystems Hierbei k nnen Probleme auftreten wenn gewisse Restriktionen in Bezug auf die Zahl von zul ssigen Betriebsmitteln bestehen oder sich die Anzahl der zur Verf gung stehenden Betriebsmittel unterscheidet Beispielsweise k nnte ein Betriebssystem eine virtuelle Speicherverwaltung wie z B Paging unterst tzen wodurch umfangreiche Speicheranforderungen erm glicht werden Bei anderen Betriebssystemen die diese Funktion nicht unterst tzen kann dies zu gr eren Portierungsproblemen f hren Die Speicherverwaltung hat die Aufgabe den freien und belegten Speicherplatz zu verwalten Hierbei treten neben den bereits angesprochenen Problemen in Bezug auf die Speicherorganisation Portierungsprobleme durch unterschiedliche Speicherverwaltungssysteme auf Man unterscheidet zwischen Verwaltungssystemen die Prozesse w hrend ihrer Ausf hrung zwischen dem Hauptspeicher und der Platte hin und her transferieren Swapping oder Paging und solchen die es nicht tun z B Systeme mit Einprogrammbetrieb Ein Portieren zwischen solchen Computersystemen kann ebenfalls Probleme verursachen Dateiverwaltung und unterschiedliche Dateisysteme verursachen bei der Portierung ebenfalls viele Schwierigkeiten Die wichtigsten Unterschiede zwischen Dateiverarbeitungssystemen sind Dateinamen d h deren zul ssige L nge sowie die g ltigen Zeichen Zugriffsmethoden auf einzelne Datens tze sequentielles Lesen oder wa
224. en und wirkt sich auf alle weiteren Metriken aus Dieser Nachteil wurde bereits bei der Betrachtung der Basismetriken angesprochen Auch werden hier ausschlie lich Implementierungsaspekte betrachtet 3 1 3 5 Zyklomatische Komplexit t nach McCabe Eine Gruppe von Metriken die auf der Anzahl der Entscheidungen in einem Software System beruhen werden u a als logische Strukturmetriken bezeichnet Das wohl bekannteste Ma dieser Gruppe ist das Komplexit tsma von McCabe McCabe 76 Von ihm wurde zur Messung der strukturellen Komplexit t von Software Systemen eine Metrik vorgeschlagen die als quantitative Basis f r die Absch tzung von Test und Wartungsaufwand eines Software Systems dient Ausgehend von gerichteten Kontrollflu graphen welche die logische Struktur eines Software Systems widerspiegeln wird die sogenannte zyklomatische Zahl ermittelt Die zyklomatische Zahl v G eines Graphen G N mit n Knoten e Kanten und p Zusammenhangskomponenten wird mit Hilfe der Formel v G e n 2p ermittelt Mit der zyklomatischen Komplexit t wird die Anzahl der Pfade bestimmt die mindestens notwendig sind um alle m glichen Pfade durch ein Modul mit Hilfe der Linearkombination zu berechnen Basispfade Graphen in denen jeder Knoten von jedem anderen Knoten aus erreicht werden kann werden als streng zusammenh ngend bezeichnet und spielen bei der Definition der zyklomatischen Komplexit t eine wichtige Rolle Eine Zusammenhangskomponente
225. endung und auch das Windows System selbst ber eine Reihe von sogenannten Initialisierungsdateien in denen Initialisierungs und sonstige Informationen abgelegt werden konfigurierbar Das Konzept der Initialisierungsdateien f hrt jedoch dazu da eine Vielzahl solcher Dateien auf einem Rechnersystem entstehen und keine zentrale Instanz f r die Registrierungs und Verwaltungsdaten der Anwendungen und des Rechnersystems zust ndig ist Das Konzept von Win32 Systemen ist die zentrale Registrierungsdatenbank In ihr werden alle Arten von benutzer und anwendungsspezifischen Informationen sowie dem Datenaustausch der Anwendungen untereinander z B OLE als auch die gesamte Hard und Software Konfiguration eines Rechnersystems festgehalten und verwaltet Hierbei treten in erster Linie dann Probleme auf wenn man direkt auf den Inhalt von INI Dateien zugreift nicht standardisierte Zugriffsmethoden sprich direkte Dateioperationen und mittels selbstdefinierter I O Funktionen auf deren Inhalt zugreift anstatt auf die daf r vorgesehenen API Funktionen zur ckzugreifen Dieses Vorgehen ist im Zusammenspiel mit der Win32 Registry nicht mehr m glich und man ben tigt f r den Umgang mit Systeminformationen die hierf r vorgesehenen API Funktionen Nichtdokumentierte Eigenschaften Die Nutzung undokumentierter Eigenschaften eines Windows Systems in Software Systemen ist meist mit gr eren Anpassungen bei der Portierung verbunden und verursacht s
226. enfalls verwaltet ber den Extended Memory Manager Weder im Real noch im Standard Modus laufen DOS Programme im Multitasking Betrieb Hierbei handelt es sich um eine einfache Umschaltm glichkeit zwischen exklusiv ablaufenden Programmen die nur dann laufen wenn der Anwender sie aktiviert Aus softwaretechnischer Sicht ist der erweiterte 386 Modus Enhanced Mode die aufwendigere aber auch leistungsf higere Windows Betriebsart im Vergleich zum Standard oder Protected Mode Sie macht starken Gebrauch von den Fertigkeiten des 80386 Prozessors insbesondere des Virtual 86 Mode einer speziellen Variante des Protected Mode Der Prozessor kann so als Task mehrere Programme die f r den 8086 konzipiert sind ausf hren Er geht ber die im Standard Modus vorhandenen Verwaltungs und Schutzmechanismen hinaus indem er die virtuelle Speicherverwaltung des 80386 nutzbar macht Im erweiterten 386 Modus besteht Windows aus virtuellen Maschinen VM und virtuellen Ger ten deren Miteinander von dem sogenannten Virtual Machine Manager VMM koordiniert wird Der Windows Funktionsvorrat residiert in einer virtuellen Maschine der System VM Die Anwendungen laufen in jeweils eigenen VM s ab die sowohl aus 8086 Code als auch aus Code im 16 Bit Protected Mode bestehen k nnen Nur im erweiterten 386er Modus laufen unter Windows mehrere DOS Tasks simultan zu Windows Anwendungen Eine Verwaltungsinstanz billigt ihnen reihum Rechenzeit zu Window
227. ent LA Evtl VirtualUnLock benutzen GlobalUnfix GlobalUnfix Unter Win32 nicht mehr erforderlich LA Einfach loeschen GlobalUnwire GlobalUnwire Unter Win32 nicht mehr erforderlich LA Einfach loeschen GlobalWire GlobalWire Unter Win32 nicht mehr erforderlich LA Einfach loeschen int86 int86 Kein Win32 Aequivalent DOS Ersetzen durch benanntes portables Win32 API intdos intdos Kein Win32 Aequivalent DOS Ersetzen durch benanntes portables Win32 API IsGDIObject IsGDIObject Kein Win32 Aequivalent GDI IsTask IsTask Kein Win32 Aequivalent SEP LibMain DllEntryPoint DLL Initialisierung geaendert SEP Anpassen an Win32 LimitEmsPages LimitEmsPages Kein Win32 Aequivalent LA LocalCompact LocalCompact Unter Win32 nicht mehr erforderlich LA Einfach loeschen Locallnit Locallnit Kein Win32 Aequivalent LA LocalNotify LocalNotify Kein Win32 Aequivalent LA LocalShrink LocalShrink Unter Win32 nicht mehr erforderlich LA Einfach loeschen LockData LockData Unter Win32 nicht mehr erforderlich LA Einfach loeschen LockSegment LockSegment Unter Win32 nicht mehr erforderlich LA Einfach loeschen MakeProcinstance MakeProcinstance Leeres Makro SEP Nicht erforderlich loeschen MoveTo MoveTo Kein Win32 Aequivalent GDI Ersetzen durch portable MoveToEx ncalloc calloc NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder calloc NetBlOSCall NetBIOSCall Kein Win32 Aequivalent DOS Ersetzen durch benan
228. entierten Modell mit Ausnahme der Methoden konstitutiv anderer Art sind Auf der Grundlage der theoretischen berlegungen zur Portabilit t und der Vermessung von Software Systemen konnte daraufhin eine erste Portabilit tsanalyse des XCTL Systems im Hinblick auf die Portierung in eine 32 Bit Windows Umgebung durchgef hrt werden Hierbei wurden die Aspekte Systemanpassung Komplexit t und Dokumentation ber cksichtigt Bei der Anpassung an die Systemumgebung ging es in erster Linie um die Ermittlung von potentiell anzupassenden Teilen des untersuchten Software Systems Somit entstehende nderungsaufw nde k nnen durch komplexe Software Systeme weiter erh ht werden wodurch auch der Einarbeitungsaufwand beeinflu t wird Zusammenfassung Anmerkungen Ausblick Seite 182 Des weiteren wird der abschlie end anfallende Systemtest deutlich aufwendiger als bei weniger komplexen Systemen Der Einarbeitungs und nderungsaufwand wird dar ber hinaus ma geblich durch die vorhandene Dokumentation des untersuchten Software Systems beeinflu t Diese wurde durch ein manuelles Code Review subjektiv bewertet Die so entstandenen Me ergebnisse liefern einen ersten Eindruck von der Beschaffenheit des XCTL Systems im betrachteten Portierungsfeld Hierbei wurde sowohl die Gesamtzahl potentieller Anpassungen als auch jeder Systemkomponente objektiv ermittelt und in Verh ltnisma en ausgedr ckt Die so ermittelten Daten geben damit einen berbl
229. er st wird anschlie end schrittweise mit Funktionalit t der leeren Funktionen gef llt wobei diese jeweils zusammen mit den bereits funktionierenden Teilen angepa t compiliert und getestet werden Der Top Down Ansatz bringt folgenden Vorteile mit sich Vereinfachtes Debugging motiviert und Portabilit t von Software Systemen Seite 72 f rdert Teamarbeit und Erfahrungsaustausch Durch die schrittweise und kontrollierte Anpassung der Quellen k nnen die einzelnen Teile des Software Systems besser getestet und Fehler leichter beseitigt werden Der Entwickler konzentriert sich immer auf einen bestimmten Teil und versucht diesen korrekt zu portieren Somit gelangt er schnell zu Erfolgserlebnissen welches auch die Motivation in positivem Ma e beeinflu t Auch k nnen nach portiertem Hauptprogrammger st und definierten Schnittstellen zur weiteren Funktionalit t alle Teile relativ unabh ngig voneinander portiert und getestet werden Hinzu kommen die im Laufe der Portierung gesammelten Erfahrungen der allerersten Anwendungsteile welche sich auf die Portierung der noch ausstehenden Teile positiv auswirken Beide Strategien stellen einen jeweils idealisierten Fall dar und bei der Portierung eines Software Systems wird man jeweils einzelne Elemente beider Strategien vereinigen m ssen Dennoch ist es vorteilhaft sich zu Beginn der Portierung f r eine grundlegende Vorgehensweise zu entscheiden Entweder in einer umfassenden Bearbei
230. er Makros in WINDOWSX H benutzen oder strtok strupr strupr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strupr GetActiveWindow GetActiveWindow Rueckgabe kann gleich 0 sein GDI Lokalen Eingabestatus beruecksichtigen GetAspectRatioFilter GetAspectRatioFilter Kein Win32 Aequivalent GDI Ersetzen durch portable GetAspectRatioFilterEx GetAtomHandle GetAtomHandle Kein Win32 Aequivalent MBE GetBitmapDimension GetBitmapDimension Kein Win32 Aequivalent GDI Ersetzen durch portable GetBitmapDimensionEx GetBrushOrg GetBrushOrg Kein Win32 Aequivalent GDI Ersetzen durch portable GetBrushOrgEx GetCapture GetCapture Rueckgabe kann gleich 0 sein MBE Lokalen Eingabestatus beruecksichtigen GetClassWord GetClassWord Verbreiterte Datentypen beruecksichtigen GDI GetClassLong fuer Werte die auf 32 Bit gewachsen sind GetCodeHandle GetCodeHandle Kein Win32 Aequivalent GDI GetCodelnfo GetCodelnfo Kein Win32 Aequivalent GDI GetCommeError GetCommeError Kein Win32 Aequivalent GDI Ersetzen durch ClearCommerror GetCurrentPDB GetCurrentPDB Kein Win32 Aequivalent MBE Evtl GetCommandLine benutzen GetCurrentPosition GetCurrentPosition Kein Win32 Aequivalent GDI Ersetzen durch portable GetCurrentPositionEx GetCurrentTask GetCurrentTask Kein Win32 Aequivalent SEP GetCurrentThread Process benutzen GetDOSEnvironment GetDOSEnvironment Kein Win32 Aequivalent DOS Evtl GetEnvironmentStrings benutzen GetEnviro
231. er Vorgehensweise nach dem Schnitt Ansatz gestaltet man seinen Code m glichst so da er auf jedem Rechnersystem ohne Anpassung funktioniert Systemabh ngigkeiten werden in einzelnen Quelltextdateien gekapselt die dann als eine Art Schnittstelle zwischen dem Software System und dem zugrunde liegenden Rechnersystem agieren Der Schnitt verwendet nur die Merkmale die auf allen Zielumgebungen vorhanden sind Nachteilig hierbei ist die Forderung nach universeller Verf gbarkeit was die m glichen Zielumgebungen oder die F higkeiten des resultierenden Software Systems reduzieren kann bzw in bestimmten Umgebungen zu Performanceverlusten f hrt Der gr te Vorteil des Schnitt Ansatzes ist jedoch die vollst ndige Vermeidung von bedingtem Code und die saubere Trennung von bestimmten Abh ngigkeiten in separaten Dateien Diese k nnen dann je nach Bedarf ausgetauscht werden f r jede Umgebung eine Datei Auch sollten innerhalb der Dateien Systemabh ngigkeiten hinter Schnittstellen verborgen bleiben und nach dem Prinzip der Abstraktion nichtportable Teile eines Software Systems kapseln Das Software System nutzt dann nur Funktionen aus dieser Schnittstelle welche wiederum alle F higkeiten des zugrunde liegenden Computersystems nutzt Das erfordert zwar recht unterschiedliche Implementierungen der einzelnen Schnittstellen aber das Software System das nur die Schnittstellen verwendet ist davon unabh ngig und sollte bei einer Portierung keine weiteren
232. er ist der Einflu faktor Dokumentation eine entscheidende St rgr e die sich nicht vollst ndig automatisiert erfassen l t und damit die konomie des Portierungsma es negativ beeinflu t Alle anderen Einflu gr en sind vollst ndig automatisiert erfa bar da hier bereits entsprechend einsetzbare Werkzeuge zur Verf gung stehen F r die Ermittlung des Gesamtma es Portabilit t fehlt jedoch ein geeignetes Werkzeug welches die einzelnen Teilma e unter einer einheitlichen Oberfl che zusammenf hrt Metriken und Portierungsaufwand Seite 124 Die N tzlichkeit eines Ma es h ngt davon ab inwiefern damit praktische Bed rfnisse befriedigt werden Es spielt also eine Rolle wie wichtig quantitative Informationen ber bestimmte Merkmale f r einen Ma anwender sind und ob gleiche oder hnliche Ma e vorhanden sind mit denen diese Informationen beschafft werden k nnen Es kann gesagt werden da der praktische Nutzen eines Portabilit tsma es welches den Anspruch erhebt den Aufwand einer Portierung vorherzusagen sicherlich gro ist und damit ein gewisser Bedarf vorhanden ist zumal eine Reihe verschiedenster Systemumgebungen existieren Dieser Bedarf k nnte sich mit der Zeit jedoch ndern da der allgemeine Trend immer mehr in Richtung Vereinheitlichung von Systemumgebungen geht Solange jedoch noch keine ausreichenden Portierungserfahrungen zur Verf gung stehen und diese in das vorgestellte Portabilit tsma einflie
233. er selben Form parametrisiert sein mu Diese k nnen Ein oder Ausgabeparameter oder beides sein Die Methode umfa t wie bei der prozeduralen Programmierung einen Anweisungsblock mit genau einem Eintritts und einem Austrittspunkt Auf dieser Abstraktionsebene im OO Modell d h auf Methodenebene kann daher das Verhalten der Methoden mit Hilfe klassischer Software Metriken untersucht werden Der Unterschied zur Modulhierarchie bei der strukturierten Programmierung liegt nun darin da die Relationen auf den Klassen nicht notwendigerweise einen zusammenh ngenden Graphen aufspannen in dem alle Klassen als Knoten enthalten w ren Vielmehr k nnen beide Relationen Vererbungs und Benutzt Relation jeweils mehrere gerichtete azyklische Einzelgraphen aufspannen Somit ist eine wesentliche Eigenschaft aller Relationen auf Klassen da nicht eine Beziehung alleine die Klassen eines objektorientierten Systems verbinden mu Insbesondere ist weder in der Vererbungsrelation noch in der Benutzt Relation eine Wurzel gefordert von der jede Klasse des Systems erben bzw benutzt w rde Bei der Entwicklung von Metriken f r objektorientierte Software Systeme unterscheidet man daher die Abstraktionsebene der Methoden der Klassen der Aggregation der Vererbungshierarchien und des Systems Hierbei ist es dann sinnvoll f r eine Metrik festzulegen auf welcher Abstraktionsebene sie mi t bzw f r welche Abstraktionsebene sie definiert wird Die Darstellung
234. erden konnten Vergleich Anhang F Der ermittelte Me wert betr gt f r jede Systemkomponente 0 d h da man theoretisch alle momentan als global deklarierten Klassenkomponenten auch als private deklarieren k nnte da auf keines von au en zugegriffen wird Damit geht diese Art der Datenkopplung bei der Portabilit tsanalyse des XCTL Systems zun chst nicht mit ein Die Ma e KPK und DKK bilden dann den jeweiligen Kopplungsgrad der Subma e KPK 0 506 und DKK 0 027 Analog zum Ma SK wird das Ma IKK aufgestellt was die Interne Komplexit t angereichert aggr aggr durch Portierungserfahrungen ausdr ckt IKK joe 1841 5 aggr Neben diesen Ma en wird auch noch die durchschnittliche zyklomatische Komplexit t DLK mit einbezogen da diese einen guten Indikator f r die Gesamtkomplexit t des Software Systems darstellt berschreitet der Me wert eine vorgeschlagene Grenze von 10 wird der Portierungsaufwand f r das Software System mit gro er Wahrscheinlichkeit so gro da vor der Portierung zun chst eine Reimplementierung u a die Zerlegung in weitere Systemkomponenten durchgef hrt werden sollte oder sogar eine Neuimplementierung sinnvoll erscheint DLK 2 87 Das Dokumentationsma f r das XCTL System liefert in der letzten Aggregation einen einzelnen Me wert der durch die sehr einheitliche Ma struktur erm glicht wird Bei jeder Aggregation tritt jedoch wieder ein gewisser Informationsverlust auf und es
235. erforderlich sind ermittelt werden So werden z B bei der Informationsermittlung P die Unterschiede zwischen Host und Zielumgebung ermittelt Dazu k nnen Werkzeuge aber auch Informationen aus der Dokumentation des Software Systems hilfreich sein Die so gewonnenen Information flie en dann in der Transformation zusammen Hier werden die erforderlichen nderungen am Quellcode des Software Systems sowie das Testen des angepa ten Software Systems durchgef hrt Diese Schritte wiederholen sich zyklisch bis das Software System unter Einhaltung der gestellten Anforderungen auf dem Zielsystem korrekt l uft 2 2 Portabilit t Windows basierter Software Systeme Dieses Kapitel beschreibt die Probleme der Portierung von Software Systemen die auf der Basis einer 16 Bit Windows Umgebung entstanden sind und in eine 32 Bit Windows Umgebung portiert werden sollen Hierbei wird zun chst auf die historische Entwicklung der einzelnen Windows Systeme eingegangen Danach werden die wichtigsten Windows Konzepte und Strategien f r die Windows Programmierung beleuchtet und somit insgesamt der Rahmen f r die Betrachtung der verschiedenen Portierungsprobleme abgesteckt Anschlie end werden ausgehend von der Programmiersprache C und C und den Architekturen der betroffenen Windows Systeme die spezifischen Portierungsprobleme behandelt und in einzelnen Problemklassen zusammengefa t Ausf hrungen ber Strategien und unterst tzende Werkzeuge u a das Werkz
236. erspiegeln So ist beispielsweise bei zunehmenden Abstand Anzahl der zwischenliegenden Schichten der beteiligten Komponenten die Abh ngigkeit der aufrufenden Komponente zur Umgebung immer gr er da nicht nur Komponenten einer direkt benachbarten Schicht aufgerufen werden Die nach innen orientierte Schnittstellenkomplexit t wird durch die Anzahl der Lesezugriffe auf die Daten der aufgerufenen Systemkomponente sowie deren R ckgabewerte bestimmt und entsprechend gewichtet Die Gewichtungsfaktoren bilden sich aus dem Abstand der Rufenden zur aufgerufenen Systemkomponente im Systemstrukturgraphen Die nach au en orientierte Schnittstellenkomplexit t ergibt sich analog zur nach innen orientierten Schnittstellenkomplexit t aus den bergebenen Parametern und den Schreibzugriffen auf Datenstrukturen anderer Systemkomponenten mit entsprechender Gewichtung Um die Schnittstellenkomplexit t bestehend aus nach innen und au en orientierter Schnittstellenkomplexit t zu bestimmen erweitert Adamov den Prozeduraufrufgraphen zum Programmaufrufgraphen da die globalen Daten und Datenstrukturen im Prozeduraufrufgraphen nicht enthalten sind Auf der untersten Ebene des Programmaufrufgraphen befinden sich die Datenstrukturen Der Vorteil des Komplexit tsma es von Adamov ist da es im Vergleich zu anderen Ma en welche jeweils nur einen Faktor beachten die entscheidenden Faktoren der Komplexit t von Systemen ber cksichtigt Ein Nachteil ist j
237. erter Entwurf Strukturierter Entwurf Sammlung von Betriebssystem Objekte wie Dateien Funktionen und Daten Prozesse Speicherbereiche etc werden vom Kernel als Objekte behandelt Volles preemptive multitasking und Kooperatives Multitasking keine multiple Threads inklusive der X multiplen Threads IPC Unterst tzung nur notwendigen IPC Mechanismen durch DDE Portable und strukturierte Ausnahmen Keinerlei Fehlerbehandlungs und Fehlerbehandlung X mechanismen vorhanden Ausnahmen und Fehler m ssen komplett manuell verfolgt Anhang A Wesentliche Systemunterschiede des betrachteten Portierungsfelds Seite 188 und bearbeitet werden Der Kernel benutzt als nativen Zeichensatz Unicode Alle wichtigen Alphabete Silben oder Symbolschriften sowie Sonderzeichen sind einheitlich verf gbar Die bersetzung in das ANSI Format wird v llig transparent vorgenommen Es wird der ANSI Zeichensatz benutzt der mit dem OEM Zeichensatz der Hardware meist IBM ASCII nicht vollst ndig kompatibel ist Konvertierungen von und nach ANSI m ssen manuell vorgenommen werden Jedem Proze wird ein Limit f r seinen Ressourcenverbrauch gesetzt das sowohl den Gebrauch von Kernel Objekten Threads Semaphoren etc als auch die Auslastung des Speichers Anwendungen k nnen was Rechenzeit und Ressourcenverbrauch angeht vom System nicht kontrolliert werden Nichtkooperative Anwendungen k nnen ande
238. erung des Software Systems ben tigt werden In der zweiten wird das Volumen als die Anzahl der geistigen Vergleiche aufgefa t die notwendig sind um das Software System zu implementieren Bei dieser Interpretation geht man von der Annahme aus da der Programmierer die Auswahl des n chsten Zeichens aus der Menge 77 Summe der Operatoren und Operanden durch bin re Suche trifft Dies entspricht jedoch nicht unbedingt der Realit t da beim Schreiben von Anweisungen meist nur bestimmte Operatoren und Operanden sinnvoll sind und nicht erst eine Anzahl von Vergleichen durchgef hrt werden um sich dann f r das passende Zeichen zu entscheiden Legt man als Hypothese zugrunde da eine minimale Implementierung eines Software Systems nur aus Funktionsaufrufen und Ein Ausgabeparametern besteht so ist diese bei Halstead durch das potentielle Volumen V definiert Hierbei steht m f r die Anzahl der Parameter wobei der zweite Summand in der Klammer aus dem Funktions bzw Prozedurnamen sowie einem Trennzeichen da zwischen dem Funktionsnamen und den Parametern steht besteht Aus dem Verh ltnis des potentiellen Volumens zum Volumen eines Software Systems bestimmt man dessen Programmebene E und beschreibt somit gewisse Effektivit tseigenschaften Die Metrik besitzt den Wert 1 wenn das Software System auf h chstm glicher Ebene geschrieben wurde d h bei gew nschter Funktionalit t minimale Gr e besitzt Ausgehend von der Annahme da
239. erung sind die durchgef hrten bzw notwendigen Anpassungen bekannt und werden in einem differenzierten Ma BIBM erfa t Hierbei wird die Annahme zugrunde gelegt da eine Bibliotheksroutine ber die keine Informationen existiert grunds tzlich entwickelt werden kann und unterscheidet sich somit von den Betriebssystem Aufrufen die zumeist nicht modifiziert oder selbst entwickelt werden k nnen bzw nicht modifiziert werden sollten Bibliotheksroutinen die im Laufe der Portierung entwickelt worden sind k nnen bei einer weiteren Portierung eingesetzt werden und m ssen im Aufwandsma deshalb nicht mehr ber cksichtigt werden Das differenzierte Ma BIBM f r Bibliotheksroutinen hat folgenden Aufbau BIBM SA BAz g mit SA pg Anz BIBR Anz BIBR Gesamtzahl der Aufrufe von Bibliotheksroutinen zu denen keine Aufw nde vorliegen BA yy Anz BIBR B Anz BIBR B Summe der bewerteten Bibliotheksroutinen f r die ein Aufwand vorliegt B Aufwand f r die Anpassung des Aufrufs der i ten Bibliotheksroutine i 1 7 Da fiir das XCTL System in dieser Phase noch keine konkreten Portierungserfahrungen zugrunde gelegt werden k nnen ist dieses Ma noch nicht realisierbar Der zweite Schritt bei der Erfassung der Bibliotheksroutinen besteht in der Ermittlung der Anzahl der anzupassenden Aufrufe Diese verursachen ebenfalls einen h heren Portierungsaufwand wenn sie in vielen Komponenten verstreut sind Desh
240. essere Stabilit t des gesamten Systems eine dynamische Konfiguration der Umgebung Vorteil seltenere Anpassung des Systems durch den Anwender n tig sowie erh hte Systemkapazit ten Vorteil verbesserte gleichzeitige Ausf hrung von Programmen Alle Funktionen werden durch einen modularen Aufbau unterst tzt und in Abbildung 7 dargestellt Anwendungen System VM Win32 Win16 DOS VM An z An Win32 Win16 Zus tze der Benutzer Am Anwendung DOS WM berfl che Netzwerk a GE umgebung etc nwendung DOS VM 32 Bit Shell e 4 Registrier N Datenbank Kontroll Elemente d ae Windows 95 Kern User GDI Kernel VMM Dateiverwaltungs Subsystem Subsystem Speicherseiten 32 Bit Fat 32 Bit CD ROMD Netzwerk verwaltung MS DOS Dateisystem ateisystem Dateisystem Konfigurations Protected Manager Mode Schnitt stelle Proze Scheduler Block 1 O Subsystem Ger tetreiber Hardware Abbildung 7 Systemarchitektur von Windows 9x Die zentrale Speicherstelle f r Systeminformationen ist die Registrierdatenbank Sie l st die Dateienvielfalt und dezentrale Speicherung von system oder anwendungspezifischen Daten durch Autoexec bat Config sys und INI Dateien aus Wi
241. essourcen Treiberbibliothek Der IBM PC war von Anfang an als ein offenes System konzipiert d h es lie en sich beliebige PC kompatible Hardwarekomponenten verschiedenster Hersteller in das Computersystem einbinden Der gr te Nachteil hierbei war das jedes Software System eine eigene Treiberbibliothek mitbringen mu te welche die eingesetzte Hardware in allen Details der Ansteuerung zu kennen und zu unterst tzen hatte Nicht selten hatten Software Systeme die nach diesem Konzept die Hardware verwalteten 80 ihres Installationsumfangs mit Treibern z B f r eine Vielzahl verschiedener Grafikkarten oder Hunderten von Druckern belegt Das Konzept der Windows Treiber und einer zentralen Treiberbibliothek f hrte ab der ersten Windows Version dazu da das Betriebssystem die Verwaltung der Hardware bernahm Software Systeme greifen hierbei nicht direkt auf die Hardware zu sondern benutzen einheitliche Treiberschnittstellen des Systems Damit ist die Verantwortung f r die Bereitstellung der Treiber von den Software Entwicklern auf die Hardware Entwickler bergegangen Diese stehen nun ihrerseits in der Pflicht die angebotene Hardware mit entsprechenden Treibern f r die einzelnen Windows Versionen auszuliefern auf die dann alle Software Systeme zentral zur ckgreifen um die jeweilige Hardware anzusprechen 2 2 2 2 Programmierung Windows basierter Software Systeme F r die Programmierung von Software Systemen unter Windows benutzt man
242. etc X standardisierte und daher wenig portable Verfahren wird eine eingeschr nkte 32 Bit Verarbeitung erm glicht Unterst tzung von Multi Keine Unterst tzung von Prozessorsystemen symmetric Multiprozessorsystemen multiprocessing SMP Portable Implementation Extrem prozessorabhangig und Schichtenmodell monolithisch implementiert Win16 setzt auf einem anderen Betriebssystem MSDOS auf 4 GB virtueller AdreBraum pro Insgesamt 4 GB Adre raum der global Applikation wobei die obere H lfte X von allen Applikationen und dem BS also 2 GB f r Betriebssystem Code und genutzt wird Daten reserviert sind Vollst ndige Trennung aller Keine sichere Trennung der Adre r ume voneinander und vom X Speicherbereiche voneinander Betriebssystem Der gesamte virtuelle Adre raum 4 Der Adre raum teilt sich auf in eine Reihe GB einer Anwendung kann durch 32 X von 64 KB Segmenten Bit Zugriffe als ein Segment behandelt werden daher keine Segmentarithmetik notwendig Das demand paging mit dem die Zwar ist der Paging Mechanismus des 386 virtuelle Speicherverwaltung arbeitet X im Enhanced Mode aktiv dieser stellt erlaubt die Kontrolle ber die Attribute einer Speicherseite jedoch nur eine vereinfachte Form der virtuellen Speicherverwaltung dar Tabelle A1 Vergleich Win16 und Win32 Prozessor und Speicherverwaltung Windows NT Windows 9x Windows 3 x Enhanced Mode Objektorienti
243. eug Porttool der Firma Microsoft bei der Portierung schlie en sich dann an diesen Teil an 2 2 1 Historie von Windows Systemen Im Herbst 1981 wurde der erste IBM PC mit zwei Betriebssystemen von der Firma IBM auf den Markt gebracht Hierbei konnte sich das Betriebssystem f r PC s und Kompatible MS DOS schlie lich am Markt behaupten Diese Variante von MS DOS stellte dem Benutzer eine Eingabeaufforderung zur Verf gung ber die er entsprechende Kommandos an das Computersystem bermitteln durfte und verschiedene Anwendungsprogramme in den Hauptspeicher laden konnte Das ganze Betriebssystem bestand f r Programmierer demnach aus einer Gruppe von Funktionen die den Datentransfer von und zu einzelnen externen Speichermedien bernahm und den Rest ber direkte Zugriffe auf die Hardware realisierte z B Textausgabe oder auch schon Grafiken Im Januar 1983 wurde von der Firma Apple der erste mi lungene Versuch unternommen textbasierten Diskettenbetriebssystemen eine grafisch orientierte Programmierumgebung gegentiberzustellen Im Jahre 1994 konnte aufgrund der jetzt zur Verf gung stehenden Portabilit t von Software Systemen Seite 37 leistungsf higeren Hardware der Macintosh mit einem grafisch orientierten Betriebssystem zur Marktreife gebracht werden Dieses Betriebssystem setzte damit den Standard f r grafisch orientierte Benutzeroberfl chen Windows erschien mit der Versionsnummer 1 01 im November 1985
244. f LPDWORD GlobalLock hCountBuf Counters cpp 1111 counts DWORD argum 300 0 rand 7 M_psd h 56 int GetData WORD WORD WORD return 0 M_psd h 99 virtual int PsdRead int int int LPVWVORD return R_OK M_psd h 119 int PsdRead int int int LPWORD KOMP TPsd Anz MAA 10 Counters cpp 1572 LONG FileSize Counters cpp 1648 DWORD counts Counters cpp 1724DWORD counts Counters cpp 1792 DWORD counts dwExposureCounts Counters cpp 1793 WORD lowthresh highthresh voltage wHighVoltage Counters cpp 1795 wDacLowerThresh min WORD 1022 max wDacLowerThresh WORD 0 Counters cpp 1796 wDacUpperThresh max WORD 1 min wDacUpperThresh WORD 1023 TPsd Initialize TPsd GetData float_ amp TPsd GetData float_ amp TPsd PsdReadOut THowReadOutPsd TPsd PsdReadOut THowReadOutPsd TPsd PsdReadOut THowReadOutPsd TPsd PsdReadOut THowReadOutPsd TPsd GetData unsigned_short_ unsigned_short unsigned_short TPsd PsdRead int int int unsigned_short_ TPsd PsdRead int int int unsigned_short_ TRadicon Initialize TRadicon MeasureStart TRadicon PollDevice TRadicon SetParameters TRadicon SetParameters TRadicon SetParameters TRadicon SetParameters Counters cpp 1811 void CALLBACK TRadicon EventHandler UINT UINT DWORD DWORD DWORD TRadicon EventHandler unsigned_int unsigned_int unsigned_lo Counters cpp 1813DWORD counts M_devhw h 70 static void CALLBACK T
245. f r die Software Umgebung einflie en lautet dieses wie folgt SU PAN su KOMP VKG mit PAN BSM BIBM UTM Anzahl der potentiellen Anpassungen von Aufrufen von Routinen der Software Umgebung KOMP BSM BIBM UTM Namen der Komponenten mit Aufrufen von Routinen der Software Umgebung und deren Anzahl VKG BSM BIBM UTM Verh ltnis der Komponentenzahl aus KOMP zur Gesamtzahl der Programmkomponenten F r das XCTL System ergibt sich damit f r die Software Umgebung das Aufwandsma siehe Anhang F SU PAN KOMP VKG 356 KOMP 0 691 KOMP BSM BIBM UTM TAbout TAdjustmentExecute TAdjustmentWindow TAm9513a TAngleControl TAquisition TAreaScan TAreaScanCmd TAreaScanParameters TBitmapSource TBraun_Psd N CA PNAMTNANANAAANNN AM TC_812 TC_812GPIB A 1 TC_832 A TCalibrate i TCalibratePsd TCmd TCommonDevParam wae wa O a aS Ss Se aS O O a a OU a aS Se SS a Portabilit tsanalyse am Beispiel des XCTL Systems Seite 147 TCounterShowParam TCounterWindow TCurve TDC_Drive TDevice TDList TEditWindow TEncoder j TExecuteCmd i TGenericDevice TMacroExecute e TMain y TMDIWindow i TMList TModalDlg y TModelessDlg TMotor TMotorParam TPlotData y Tx TPosCo
246. fe Ermittlung der Ma komponente Utility Aufrufe Zusammenfassung zur Ma komponente Software Umgebung Der Wechsel der Software Umgebung f hrt meist zu Problemen wenn das zu portierende Software System Zugriffe auf die Umgebung in Form von Systemaufrufen realisiert Dazu z hlen Betriebssystem Aufrufe beispielsweise f r die Ausgabe von Zeichen Bibliotheksroutinen Aufrufe wie z B Objektbibliotheken von Funktionen zur Ansteuerung einer grafischen Benutzeroberfl che etc Hilfsprogramm Aufrufe z B zur Berechnung math Funktionen oder Bereitstellung bestimmter Sortieralgorithmen Betriebssystem Aufrufe Schritte zur Ermittlung der Ma komponente Betriebssystem Aufrufe Ermittlung Anzahl unterschiedlicher BS Aufrufe BSM Alternativ BSM Porttool auswerten Berechnung BSM Ermittlung der Komponenten mit jew Gesamtzahl BSM Porttool auswerten Berechnung BSM Komponentenverh ltnis berechnen BSM Berechnung der Ma komponente BS bzw BS Anpassungen in diesem Bereich fallen immer dann an wenn Portabilit tsanalyse am Beispiel des XCTL Systems Seite 140 beide Betriebssysteme Host und Zielumgebung von der Funktionalit t her identische Funktionen zur Verf gung stellen diese jedoch einen anderen Funktionsnamen oder eine ver nderte Parameterliste besitzen bzw umgekehrt Funktionen mit identischem Funktionsnamen pl tzlich unters
247. ge MBINFO TScan LoadOldData int M_scan cpp 913 MessageBox GetFocus Header ist nicht korrekt Meldung MBINFO TScan SaveFile int M_scan cpp 915 MessageBox GetFocus Incorrect Header Message MBINFO TScan SaveFile int M_scan cpp 656 MessageBox GetFocus ContinuousScan wurde ausgef hrt Justagen MBINFO TScan SteeringReady long M_scan cpp 969 MessageBox GetFocus File existiert nicht Fehler MB_OK TScan UpdateFile KOMP TScan Anz BIBA 13 M_steerg cpp 212 MessageBox GetFocus buf Information MBINFO TScanCmd TScanCmd TCmdTag M_steerg cpp 216 MessageBox GetFocus buf Information MBINFO TScanCmd TScanCmd TCmdTag M_steerg cpp 220 MessageBox GetFocus buf Information MBINFO TScanCmd TScanCmd TCmdTag M_steerg cpp 539 MessageBox GetFocus Kein Scan Fenster offen Fehler MBSTOP TScanCmd TScanCmd TCmdTag M_steerg cpp 601 MessageBox GetFocus Kein AreaScan Fenster offen Fehler MBSTOP TScanCmd TScanCmd TCmdTag KOMP TScanCmd Anz BIBA 5 Counters cpp 1923 SetFocus GetDigltem GetHandle id_AngleRange TScsParameters Dlg_OnInit HWND___ HWND___ long KOMP TScsParameters Anz BIBA 1 M_steerg cpp 2973 SetFocus GetDlgltem TModalDlg GetHandle id_Level TSetAdjustmentParam Dlg_OnInit HWND___ HWND___ long KOMP TSetAdjustmentParam Anz BIBA 1 M_arscan cpp 3656 PostMessage GetHandle WM_COMMAND WPARAM cm_ParamSet 0l TSetupAreaScan CanClose
248. gebung die unter der Hostumgebung nicht existieren z B multiple Threads unter Win32 welche unter Win16 nicht existieren dort nur sehr aufwendig oder gar nicht realisierbar Dies erzwingt in den meisten F llen eine zus tzliche Aufspaltung in getrennte Quellen Schichtenarchitektur welche dann jeweils Plattform spezifisch sind und vom Rest der Quellen portable Schicht isoliert werden Nach der erfolgreichen Portabilisierung des Software Systems mu weiterhin regelm ig Aufwand f r die Aufrechterhaltung der Kompatibilit t zu beiden Zielplattformen betrieben werden Die Einweg Portierung geht von der Annahme aus da ein zu portierendes Software System nur noch in der Zielumgebung zur Verf gung steht Hierbei werden nicht portable Codeteile gestrichen und durch ad quaten Programmtext f r die Zielumgebung ersetzt Dieses Vorgehen stellt eine einmalige Anstrengung dar und ist mit der erfolgreichen Portierung beendet 2 2 4 2 Strategien zur Portierung Bei der Portierung von Software Systemen unterscheidet man grunds tzlich zwei Arten von Strategien Bottom Up vom Detail zum Ganzen und Top Down vom Ganzen Zentrum und anschlie endem schrittweisem Verfeinern zum Detail Portiert man nach der Bottom Up Strategie werden alle Quelldateien jeweils nacheinander angepa t compiliert und je nach ausgegebenen Fehlermeldungen und Warnungen solange ver ndert bis eine Objektdatei inklusive ben tigter Ressourcen erzeugt w
249. gelegt werden da diese die Anzahl der Klassen mit denen eine Klasse gekoppelt ist ausdr ckt wenn Methoden der einen Klasse Methoden oder Instanzvariablen einer anderen Klasse aufrufen bzw verwenden Das Ma ber cksichtigt keine Vererbungshierarchie deshalb soll zus tzlich die DIT Metrik in das Ma mit einflie en Sie gibt Aufschlu dar ber wie tief die Vererbungshierarchie der Klassen geht und z hlt konkret die Anzahl der Vorfahren einer Klasse im Vererbungsbaum Weiterhin sollen die Zugriffe auf globale oder gesch tzte Daten einer Klasse gemessen werden Folgendes Ma f r die Datenkopplung der Systemteile soll demnach f r das Portierungsma verwendet werden Kommunikationsart Datenkopplung mit k Anzahl der Komponenten DK Datenkopplung der i ten Komponente Zugriffe ber Botschaftswege globale und gesch tzte Daten Tiefe des Vererbungsbaums DK d CBO d PA d DIT mit DK Datenkopplung der i ten Komponente i 1 k d d d Gewichtungsfaktoren der Ma anteile mit d d d 1 CBO Anzahl der Datenkopplungen ber Botschaftswege der i ten Komponente PA Anzahl der Zugriffe auf public oder protected Datenelemente durch andere Klassen auf die i te Komponente DIT L nge des maximalen Weges in der Klassenhierarchie von der i ten Komponente bis zur Wurzel In dem vorliegenden Ma wird f r die interne Komponentenkomplexit t zum einen die Verwendung der zyklomatische Zahl nach McCabe ver
250. genannten Betriebssystemkern bilden und bei einer Portierung in andere Umgebungen angepa t werden m ssen Somit beschr nkt sich die Maschinenabh ngigkeit nur auf einige wenige Komponenten Der Rest des Unix Betriebssystems ist v llig maschinenunabh ngig implementiert und kann ohne weitere Anpassungen f r unterschiedlichste Zielumgebungen bernommen werden Ein weiteres Beispiel ist MUSS Frank 79 das Ende der 70er Jahre an der Manchaster Universit t entworfen wurde Die Portabilit t des Betriebssystems wird durch mehrere unabh ngige Komponenten Portabilit t von Software Systemen Seite 29 erreicht die als virtuelle Maschinen z B Ein Ausgabe Manager Disk Manager etc dargestellt werden Die maschinenabh ngigen Funktionen wie z B Speicherverwaltung und Interrupt Handling etc sind hnlich zu Unix in einem Betriebssystemkern zusammengef hrt Die virtuellen Maschinen greifen ausschlie lich ber Bibliotheksfunktionen des Betriebssystemkerns auf Hardwarekomponenten zu laufen jeweils unabh ngig voneinander in eigenen Prozessen und kommunizieren ber spezielle Mechanismen des Nachrichtenaustauschs Portable Betriebssysteme bieten somit nicht nur entscheidende Vorteile in Bezug auf die einheitliche Schnittstelle zum Betriebssystem sondern auch bez glich des geringeren Aufwands im Vergleich zu einer Neuimplementierung der f r die bertragung eines portablen Betriebssystems auf bestimmte Zielumgebungen notwendig ist
251. gende Ma erh lt den Wert 1 falls mehr als die H lfte aller Kontrollstatements nicht ausreichend kommentiert sind Es wird anhand von Stichproben ermittelt KS Benutzung von Kontrollstatements dokumentiert nicht dokumentiert Die Codeinspektion ergab da nur wenig Kontrollstatements dokumentiert sind und auch die restrukturierten Teile den Gesamtdurchschnitt nicht ausreichend beeinflussen Daher hier der Wert KS 0 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 171 u ere Form Die bersichtlichkeit eines Quellcodes wird durch seine u ere Form bestimmt Entscheidend hierbei ist z B die Einhaltung von Einr ckungsprinzipien welche man seiner Quellcodestruktur zugrunde legt Die Lesbarkeit bzw Strukturiertheit des Quellcodes wird anhand eines kurzen Codeinspektion durchgef hrt Die Bewertung des Ma es erfolgt mit 1 falls der Code strukturiert ist AF Quellcode strukturiert nicht strukturiert Die berpr fung der Quellen des XCTL Systems ergab zwar da diese strukturiert sind jedoch l t diese Strukturierung noch Raum f r viele Verbesserungen auch in Hinblick auf die Lesbarkeit Dieser Teil wird wie folgt bewertet AF 1 Namensgebung F r eine problemad quate Charakterisierung von Konstanten Variablen Prozeduren usw sind Bezeichner zu w hlen die deren Funktion bzw ihre Aufgabe zum Ausdruck bringen Hierbei sind kurze Bezeichner wenig aussagekr ftig und wegen der geringen Redundanz
252. genden Hardware handeln Der Aufwand f r die Einarbeitung in ein konkretes Portierungsprojekt und dessen Durchf hrung wird also ma geblich durch den Porteur und dessen Erfahrungen bestimmt Diese sind um so wichtiger je unvollst ndiger oder ungeeigneter die Portierungsdokumentation ist Portabilit t von Software Systemen Seite 35 Funktionalit t Funktionalit t Ebene 1 Komplexit t Komplexit t Quellcode Quellcode Ebene 2 Programmier Programmier sprachen sprachen Ebene 3 Software Umgebung Ebene 4 Hardware Hardware Umgebung Umgebung Host System Zielsystem Dokumentation Erfahrungen Externe Faktoren Transformation Software Umgebung gt Informationsflu gt Einflu O Ermittlung von Informationen Abbildung 4 Portierungsmodell nach Buschhorn Das Modell besteht zun chst aus den Komponenten Host und Zielsystem die zusammen mit der Software bzw der portierten Software eine Hierarchie aus vier abstrakten Maschinen bilden Auf der ersten Ebene finden sich die abstrakten Maschinen die das zu portierende Programm darstellen Die fiir eine Portierung relevanten Merkmale werden durch Quellcode Funktionalit t und Komplexit t charakterisiert Die programmimanente Komplexit t eines Programms kann sich durch eine Portierung ver ndern der Quellcode ver ndert sich in jedem Fall Finden keine nderungen am Quelltext statt so wird hier nicht von einer Portierung gesprochen U
253. gesamt findet man ca 150 Ma vorschl ge f r objektorientierte Software Systeme Fetcke 95 Zuse 98 Erste empirische Untersuchungen zeigen die Eignung einiger der vorgeschlagenen Metriken als Qualit tsindikatoren Ein Nachteil ist jedoch da die Metriken bisher unzureichend validiert sind bzw die Ziele f r die diese Metriken entwickelt wurden in der Regel nicht angegeben sind Somit fehlt der G ltigkeitsnachweis da eine Metrik auch tats chlich das Softwareattribut mi t welches es vorgibt zu messen interne Validierung bzw der empirische Nachweis eines Zusammenhanges zwischen dem Softwarema und einer externen Variablen wie z B den Entwicklungskosten externe Validierung Eine Auswahl vorgeschlagener Metriken stellt sich dabei als signifikant f r die Vermessung der Qualit t einer Klasse heraus Balzert Metriken und Portierungsaufwand Seite 97 98 Aus dieser Auswahl werden im folgenden diejenigen vorgestellt die in das Portierungsma mit eingehen sollen 3 1 4 2 DIT Depth of Inhertiance Tree Ein Ma f r die Anzahl der Vorfahren einer Klasse liefert die DIT Metrik Depth of Inheritance Tree und wird von Shyam Chidamber und Chris Kemerer Chidamber 94 wie folgt definiert DIT C L nge des maximalen Weges in der Klassenhierarchie von der Klasse C bis zur Wurzel Hierbei wird die Tiefe in der Klassenhierarchie von der Wurzel an mit 0 gez hlt und bei der Mehrfachvererbung der maximale Weg Das Ma ist
254. gsproze heraus direkt auf Hardware Komponenten zuzugreifen da Windows 9x als Update zu Windows 3 x zu betrachten ist und direkte Hardware Zugriffe aus diesem Grunde hier noch akzeptiert werden so ist diese M glichkeit unter Windows NT durch den zus tzlich eingef hrten Hardware Abstraction Layer nur noch mit speziellen Rechten versehenen Hardware Treibern gegeben Anwendungen laufen hier im sogenannten User Mode und haben keinerlei Rechte auf die zugrundeliegende Hardware direkt zuzugreifen Somit gelten die Aussagen ber diesen Problembereich in erster Linie f r Software Systeme deren Portierungsziel Windows NT darstellt Aufgrund von vorteilhaften Portabilit tsmerkmalen k nnen diese Aussagen aber auch f r Anwendungen gelten die nach Windows 9x portiert werden sollen Der Problembereich der Hardware Zugriffe l t sich in zwei Teilbereiche klassifizieren Zugriffe ber Funktionsinterrupts f r die in der Win32 API eine kompatible Funktion bereitstellt wird und solche f r die in der Win32 API keine portable Funktion implementiert werden kann Womit ansonsten eines der Ziele von Windows NT die weitgehende Quelltext Portabilit t zwischen den unterst tzten Plattformen nicht mehr gegeben w re z B direkte Zugriffe auf bestimmte 1 O Ports So steht z B im Bereich der Datei I O ein komplett kompatibles API zur Verf gung und auch der Bereich der MS DOS Funktionen ber den Interrupt 21 wird gr tenteils ber Win
255. h eee h eee h 68 BOOL _export WINAPI InitializeCountersDLL void 74 LPDList _export WINAPI GetCounterListPtr void 80 BOOL _export WINAPI diSetDevice int device 88 int _export WINAPI dMeasureStart void 93 int _export WINAPI dMeasureStop void 98 BOOL _ export WINAPI dSetExposureValues float time DWORD counts float fl 98 BOOL _ export WINAPI dSetExposureValues float time DWORD counts float fl 103 BOOL _ export WINAPI dGetExposureValues float amp time DWORD amp 103 BOOL _ export WINAPI dGetExposureValues float amp time DWORD amp 109 int _export WINAPI diGetDevice void 130 int _export WINAPI diGetlIdByName TDeviceType at 135 TDeviceType _export WINAPI diParsingDevice LPSTR devicename 152 BOOL _ export WINAPI dllsDeviceValid TDeviceType type 179 void CALLBACK _ export Inquirelntensity_SCS DWWORD DWORD DWORD 179 void CALLBACK _ export Inquirelntensity_SCS DWWORD DWORD DWORD 182 DWORD counts 1000 198 float WINAPI _ export GetIntensity_SCS void 206 void CALLBACK _ export Inquirelntensity_TDC DWWORD DWORD DWORD 206 void CALLBACK _ export Inquirelntensity_TDC DWWORD DWORD DWORD 230 BOOL WINAPI _ export InitializeTDC_Event float time HWND contolwnd 242 loat WINAPI _ export Getintensity_TDC void 250 void CALLBACK _ export Inquirelntensity_A913 DIWWVORD DWORD DWORD 250 void CALLBACK _ export Inquirelntensity_A913 DIWVORD DWORD DWORD 253 DWORD counts 1000
256. hier vorgestellten Konzepten geht es ebenfalls um die Entwicklung einheitlicher Architekturstandards oder Strategien auf der Basis generischer Architekturen Standards Ist man bestrebt die Architektur von Rechnersystemen zum Zwecke einheitlicher Maschineninstruktionen zu standardisieren bzw Teile davon erreicht man bei der Realisierung dieses Konzepts ein hohes Ma an Portabilit t Die bertragung von Software Systemen auf einzelne Zielumgebungen w re dann ohne gr ere Anpassungen m glich Eine einheitlich definierte Hardware Architektur erlaubt die gemeinsame Nutzung verschiedener Systemsoftware auf homogen Hardwaresystemen und sorgt gleichsam f r Objektcode Portabilit t dieser Software Systeme Ein weitverbreiteter De facto Standard ist der von vielen Firmen im Laufe der Zeit weiterentwickelte IBM PC Der erste Personal Computer wurde von IBM im Jahre 1981 auf dem Markt eingef hrt und definierte damit auf der Basis des weitverbreiteten Industriestandards ISA einen weltweiten offenen Standard f r sogenannte Personal Computer Dieser ist in seinen Grundz gen immer noch aktuell Der IBM PC basiert im wesentlichen auf einer CISC Prozessorarchitektur deren wesentlicher Repr sentant die Intel X86 Familie ist Hier steht die Objektcode Kompatibilit t mittels Aufw rtskompatibilit t durch Familienbildung im Vordergrund ausgehend vom 8 Bit Mikroprozessor 8080 ber den 16 Bit Mikroprozessor 8086 die 32 Bit Mikroprozessoren
257. hlfreier Zugriff Sicherungsmethoden f r Dateien d h in der Art wie Zugriffsrechte vergeben werden Operationen f r die Bearbeitung von Dateien sowie Restriktionen in Bezug auf deren Verarbeitung maximale Blockgr e oder maximal gleichzeitig ge ffneter Files Probleme bei der Portierung treten h ufig immer dann auf wenn Software Systeme nicht die allgemein verbreiteten Dateiverarbeitungsfunktionen gebrauchen Portabilit t von Software Systemen Seite 24 Sonstiges Weitere Probleme treten auch immer dann auf wenn Betriebssysteme eigene Mechanismen in Bezug auf Sonderfunktionalit t anbieten beispielsweise die Unterst tzung der Kommunikation zwischen laufenden Software Systemen Auch k nnen die Menge der Systemaufrufe sowie der verwendete Kommandointerpreter Probleme bereiten Bei den Systemaufrufen die bestimmte Funktionen des Betriebssystems zur Verf gung stellen k nnen je nach Betriebssystem z B die Abfragen von Systeminformationen auf unterschiedlichen Funktionsaufrufen basieren Kommandointerpreter k nnen sich in ihrer Syntax Semantik M chtigkeit oder in einzelnen Befehlen erheblich voneinander unterscheiden und somit Portierungsprobleme verursachen Auch die Fehlerbehandlung eines Betriebssystems spielt f r die Portierung eine Rolle und kann Probleme verursachen Einige Betriebssysteme haben spezielle Fehlerbehandlungsroutinen andere ignorieren bestimmte Fehler oder f hren zum sofortigen Programmabbru
258. hodology IEEE Standard 1061 1993 Use of Standard High Level Languages for Portability Info State of the Art Report 63 Life Cycle Management 1 amp 2 Maidenhead Berkshire Infotech 1980 p 117 121 ISO IEC Standard SO 9126 Software Product Evaluation Quality Characteristics and Guidelines for Their Use 1991 Kaindl H Portability of Software SIGPLAN Notices Vol 23 No 6 1988 Kernighan B W Pike R The Practice of Programming Boston Addison Wesley 1999 Kipping D Migrating to Windows 95 Rocklin CA Prima Pub 1995 Kithara Software GmbH Homepage URL http www kithara de Aktualisierungsdatum 01 03 2002 Lake A Cook C Use of Factor Analysis to Develop OOP Software Complexity Metrics Annual Oregon Workshop on Software Metrics Oregon USA 1994 Lauer T Porting to Win32 A Guide to making your Applications ready for the 32 Bit Future of Windows New York Springer 1996 LeCarme O Gart M P Software Portability 2nd ed McGraw Hill 1989 Leong S et al Methods for Transporting Programs Task Force Group COMPSAC 1983 McCabe T 4 Complexity Measure IEEE Transactions of Software Engingeering Vol SE 1 No 3 pp 312 327 1976 Literaturverzeichnis Seite 185 McCall 77 McCall J A Richards P K Walters G F Factors in Software Qualitity Rome Air Development Center 1977 Meyers 77 Meyers G J An Extension to the Cyclomatic Measure of Programm Complexity SIGPLAN Notices 1
259. hsel das Verhalten und die Funktionalit t nicht ndern In der Praxis reicht die Funktionalit t von Standardbibliotheken meist nicht aus soda auf zus tzliche und h ufig nichtportable Bibliotheksfunktionen au erhalb des Standards zur ckgegriffen werden mu Werkzeuge Ein Teil der Portabilit tsprobleme die durch unterschiedliche Sprachdialekte auftreten werden mit Hilfe von Werkzeugen wie Filtern die eine Einhaltung von Sprachstandards berpr fen angezeigt Brown 77 LeCarme 89 Filter arbeiten mit syntaktischer und teilweise mit semantischer Analyse Bei der syntaktischen Analyse wird der Quelltext auf bereinstimmung mit der Syntax einer zugrundeliegenden Programmiersprache berpr ft Die semantische Analyse berpr ft den inhaltlichen Teil dazu geh rt die statische Semantik z B Variablentypen oder G ltigkeitsbereiche und die dynamische Semantik z B Ausf hrungsreihenfolge und Initialisierungen Allen Filtern ist gemeinsam da sie ein Software System mit einem gegebenen Sprachstandard vergleichen wobei der Analyseumfang recht unterschiedlich sein kann In diesem Zusammenhang wird auch der Begriff Verifier gebraucht Zum einen versteht man darunter dynamische Debugging Tools f r Programme zum anderen bezeichnen sie Werkzeuge f r die entsprechenden Teile der dynamische Analyse Legt man die erstere Auffassung zugrunde so geh rt zum Analyseumfang des Filters auch die dynamische Analyse Neben dem Einsatz von F
260. ht mehr auf die gleiche Definition des Datentyps z B HWND selbst bei Aufrufen der gleichen Funktion zur ckgreifen Objektdateien welche die unterschiedlichen Namen der externen Funktionen exportieren k nnen dann nicht mehr korrekt zusammengelinkt werden Software Systeme auf der Basis von C m ssen demzufolge im Ganzen an die STRICT Option angepa t und portiert werden Die einzige Ausnahme bilden hierbei Funktionen die explizit als extern C definiert sind und sowohl aus Dateien aufgerufen werden die mit STRICT compiliert sind als auch von herk mmlichen Dateien heraus angesprochen werden Software Systeme auf C Basis k nnen im Vergleich dazu unter konsequenter Nutzung von ANSI C Prototypen zumindest die Prozedurk pfe sollten wegen der Parameterpr fungen ANSI C kompatibel formuliert sein schrittweise an die STRICT Option angepa t werden Die STRICT Kompatibilit t von Software Systemen ist keine notwendige Bedingung f r die Portierung nach Win32 Der Vorteil strikter Software Systeme liegt vor allem in der grunds tzlich besseren Typpr fung welche die zugrundeliegenden Quellen automatisch portabler machen Dagegen spricht der erh hte Zeitaufwand f r den zus tzlichen Arbeitsaufwand und die Tatsache da trotz der STRICT Option nicht alle Portabili tsprobleme erkannt werden Die Forderung nach fehlerfreier Ausf hrung des Software Systems im Protected Mode einer Winl6 Umgebung ist hingegen notwendig Somit m
261. i die zweite Menge eine Teilmenge aller Methoden der von C benutzten Klassen ist Die RFC Metrik ist somit ein Ma f r die Anzahl der eigenen Operationen einer Klasse C erweitert um die Anzahl der internen und externen Aufrufe Je gr er die Zahl der aufrufbaren Methoden einer Klasse ist desto h her ist deren Komplexit t und um so schwieriger werden das Testen und Debugging Die Metrik gibt somit auch eine obere Schranke f r die Anzahl der Testf lle an die durch die m glichen Methodenaufrufe notwendig werden Je gr er der Wert von RFC desto gr er ist die Fehlerwahrscheinlichkeit Ein Beispiel soll zeigen wie die RFC Metrik angewendet wird Klasse B Klasse C Abbildung 20 Beispiel f r das Ma RFC Metriken und Portierungsaufwand Seite 100 Klasse A Klasse C klasse B Op1 M10 Mai M2 lt M30 ra 1 I Abbildung 21 Sequenzdiagramm f r das RFC Beispiel Nimmt man an da die Methode M1 der Klasse A die Methode M5 der Klasse D aufruft und M2 die Methode M4 der Klasse C so besteht das Response Set f r die Klasse A aus RS M1 M2 M3 M4 Der Me wert bestimmt sich demnach wie folgt RFC A RS kA 3 1 4 5 WMC Weighted Methods per Class Ebenfalls in Chidamber 94 ist die Metrik WMC definiert WMC C Y g M i l wobei M _ die Methoden der Klasse C sind und g
262. ia System Vaterstetten Computer und Literaturverl 1999 Stevens W P Using Structured Design New York John Wiley amp Sons 1981 Stroustrup B Die C Programmiersprache Bonn Addison Wesley 1998 Swan T Mastering Borland C 4 5 2 ed Indianapolis Ind Sams 1995 Tegarden D P Sheetz S D Monarchi D E Effectivness of traditional Software Metrics for Object oriented Systems 25th Hawaii International Conference on System Sciences Proc HICSS 92 San Diaego 1992 VMWare Inc Homepage URL http www vmware com Aktualisierungsdatum 01 03 2002 Weiskamp K Pronk R Windows 3 1 Insider The Guide to hard to find and undocumented features New York John Wiley amp Sons Inc 1993 Sch tzler K Projekt Software Sanierung URL https www informatik hu berlin de Institut struktur softwaretechnikII lehre PROJEKT98 index html Aktualisierungsdatum 01 03 2002 Humboldt Universit t zu Berlin Zuse H Software Complexity Measures and Methods Berlin New York de Gruyter 1991 Zuse H A framework of software measurement Berlin New York de Gruyter 1998 Anhang A Wesentliche Systemunterschiede des betrachteten Portierungsfelds Seite 187 Anhang A Wesentliche Systemunterschiede des betrachteten Portierungsfelds Windows NT Windows 9x Windows 3 x Enhanced Mode Echtes 32 Bit System CPU Register 16 Bit Verarbeitung nur durch nicht lineares Speichermodell
263. ick ber die eventuell anstehende Portierungsarbeit Die Me werte der Komplexit tskomponente unterst tzen zwar diesen objektiven Eindruck lassen dar ber hinaus aber aufgrund fehlender Erfahrungsdaten eine weitergehende Interpretation der Daten nicht zu Der Me wert f r die Dokumentation hat hnlichen Charakter Um den Einflu der Dokumentation und des ermittelten Me wertes auf die H he des Portierungsaufwands bewerten zu k nnen sind auch hier eine Reihe von Portierungen mit entsprechenden Untersuchungen notwendig Das volle Potential der ermittelten Me werte erschlie t sich somit erst wenn konkrete Portierungserfahrungen vorliegen Dann k nnen die Ma zahlen mit konkreten Erfahrungsdaten aufgewertet werden und lassen mit der Zeit immer pr zisere Aufwandsaussagen zu Sie bilden dann eine solide Grundlage f r bevorstehende Portierungsentscheidungen Dieser evolution re Aspekt wird durch das Ma unterst tzt und ist in allen Ma komponenten integriert Somit ist die geplante Portierung des XCTL Systems eine gute M glichkeit konkrete Portierungserfahrungen in das Ma einflie en zu lassen Erste Portierungsversuche im Portierungsfeld Win16 Borland C nach Win32 VisualC wurden bereits durchgef hrt Bojic 02 siehe Anhang G Der geplanten Querportierung von Borland C nach Visual C sollte jedoch zun chst eine entsprechende Portabilit tsanalyse vorausgehen da diese im betrachteten Portierungsfeld noch nicht ber ck
264. id CALLBACK Inquirelntensity_SCS DWORD DWORD DWORD Inquirelntensity_SCS unsigned_int unsigned_int unsigned_long 23 void CALLBACK Inquirelntensity_TDC DWORD DWORD DWORD Inquirelntensity_TDC unsigned_int unsigned_int unsigned_long 26 void CALLBACK Inquirelntensity_TDC DWORD DWORD DWORD Inquirelntensity_SCS unsigned_int unsigned_int unsigned_long 32 LRESULT CALLBACK _export WndProc HWND UINT WPARAM LPARAM WndProc HWND___ unsigned_int unsigned_int long 32 LRESULT CALLBACK _export WndProc HWND UINT WPARAM LPARAM WndProc HWND___ unsigned_int unsigned_int long 33 LRESULT CALLBACK _export FrameWndProc HWND UINT FrameWndProc HWND___ unsigned_int unsigned_int long 33 LRESULT CALLBACK _export FrameWndProc HWND UINT FrameWndProc HWND___ unsigned_int unsigned_int long 53 riend LRESULT CALLBACK FrameWndProc HWND UINT WPARAM LPARAM FrameWndProc HWND___ unsigned_int unsigned_int long 54 riend LRESULT CALLBACK WndProc HWND UINT WPARAM LPARAM WndProc HWND___ unsigned_int unsigned_int long 282 typedef WORD HPWORD 287 typedef WORD _huge HPWORD 284 287 typedef char _huge HPSTR 16 BOOL CALLBACK _ export DialogProc HWND hDIg UINT msg 109 BOOL CALLBACK _ export ModelessProc HWND hDig UINT msg 7 BOOL CALLBACK _ export DialogProc HWND UINT WPARAM LPARAM 8 BOOL CALLBACK _ export ModelessProc HWND UINT WPARAM LPARAM 40 FARPROC dialogFunc 45 typedef int WINAPI TSend int LPSTR WORD L
265. ie bertragbarkeit des Systems auf unterschiedliche bzw neue System Umgebungen Eine detaillierte Darstellung des Gegenstandsbereiches und des Projektes finden sich in Bothe 01a Bothe 01b sowie unter Xctl 01 4 1 1 Quellcode und Programmiersprachen Ausgangspunkt f r die Betrachtung des Software Systems ist das 1998 vom Institut f r Physik bergebene und wenig kommentierte XCTL Projekt Der Quelltext des XCTL Systems besteht danach aus ann hernd 28000 Codezeilen verteilt auf mehr als 50 Quelldateien und ist auf Bin rebene in insgesamt 3 dynamischen Laufzeitbibliotheken plus der ausf hrbaren Programmdatei strukturiert In erster Linie wird als Implementierungssprache C verwendet einige Teilfunktionen des Systems sind in C implementiert Anhang D gibt eine bersicht zu den Quelldateien und deren Funktionen innerhalb des XCTL Systems Freund 01 und Sch tzler 01 Die Quellen wurden im Laufe der Software Sanierung teilweise restrukturiert und erweitert soda einige Quelldateien hinzugenommen bzw umbenannt wurden Den aktuellen Entwicklungsstand findet man unter Xctl 01 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 134 4 1 2 Software Umgebung Die Laufzeitumgebung f r das XCTL System wird durch das Betriebssystem Windows 3 1 zur Verf gung gestellt Es bildet die Grundlage f r die Implementierung des Systems und stellt somit die Hostumgebung dar Das f r die Entwicklung urspr nglich eingesetzte Software S
266. ie Maschinenarchitektur Hierbei wird das Ma MA wie folgt definiert MA MAM MAM MAM und sieht f r das XCTL System folgenderma en aus MA MAM MAM MAM 563 MAM 0 395 Peripherieger te Schritte zur Ermittlung der Ma komponente Peripherieger te Ermittlung Anzahl unterschiedlicher BS Aufrufe PGM Alternativ PGM Porttool auswerten Berechnung PGM Ermittlung der Komponenten mit jew Gesamtzahl PGM Porttool auswerten Berechnung PGM Komponentenverh ltnis berechnen PGM Berechnung der MaBkomponente PG Zugriffe auf Peripherieger te erfolgen innerhalb von Software Systemen ber Ein Ausgabebefehle wobei z B Steuerzeichen etc anzupassen sind Die Ma e f r Peripherieger te sind dem vorangegangenen Ma f r die Maschinenarchitektur vom Aufbau her gleich und die Ausf hrungen von oben gelten hier im Prinzip ebenso Die drei Ma e f r die Peripherieger te sehen wie folgt aus PGM Anz PG Anz PG mit PG i ter unterschiedlicher PG Zugriff i n Portabilit tsanalyse am Beispiel des XCTL Systems Seite 151 PGM KOMP Anz PGA KOMP Anz PGA mit KOMP i te betroffene Komponente des Programms i 1 n PGA anzupassender PG Zugriff Anzahl aller Komponenten mit PG Zugriffen PGM Anzahl der Komponenten Die Realisierung dieser Ma e ergibt sich zu siehe Anhang F PGM Anz PG Anz PG 37
267. ie Elemente aus A hei en Punkte und die reelle Zahl d a b hei t Abstand zwischen a und 5b Beispielsweise kann in einer Menge von Software Systemen S S S mit dem Merkmal m L nge des Software Systems gemessen in Lines of Code und den gemessenen Werten m S 20 m S 27 m S 100 m S 75 folgende Abstandsmatrix bzgl des Metriken und Portierungsaufwand Seite 82 Merkmals m berechnet werden d 8 8 S d 8 8 lt d 8 5 lt d 8 8 lt dE dE E lt d S S da 7 lt 25 lt 48 lt 55 lt 73 lt 80 E j 1 4 Daraus ergibt sich die Rangfolge Mit dieser Definition ist ebenfalls ein gewisser Unterschied zwischen dem Begriff Mali und Metrik erkennbar W hrend ein Ma als absoluter Wert bez glich der Objekte eines bestimmten Qualit tsmerkmals eines untersuchten Systems oder einer Komponente aufgefa t werden kann implizieren Metriken eine Art Rangordnung zwischen den Objekten eines betrachteten Merkmals Sie lassen somit keine Aussage ber die absolute Qualit t eines Objekts bzgl dieses Qualit tsmerkmals zu So kann z B die Aussage Software System A ist portabler als S wenig Aufschlu dar ber geben wie portabel S oder S wirklich ist und wie hoch der jeweilige Portierungsaufwand tats chlich sein wird Allgemein kann jedoch gesagt werden da die Begriffe Ma und Metrik synonym gebraucht werden und die dargestellte Abgrenzung der Begrifflichkeiten nur in Einzelf lle
268. ierung mu die Korrektheit eines Software Systems berpr ft werden und festgestellt werden da es der urspr nglichen Spezifikation gem funktioniert Dieser Nachweis kann ber Testprotokolle und geeigneten Testdaten erfolgen Da der Korrektheitsnachweis von Software Systemen notwendig ist und vorhandene Testdaten den Portierungsproze beeinflussen wird dieses Ma in das Gesamtma mit aufgenommen TDA Testdaten vorhanden nicht vorhanden Sind die Angaben zu den Testdaten vorhanden z B Grad der Pfad berdeckung so ist die Beurteilung relativ einfach Falls die Testdaten fehlen geht wieder eine stark subjektive Meinung des Porteurs in das Ma ein Im Verlauf der Restrukturierung des XCTL Systems wurden eine Reihe von Testdaten ermittelt und ein entsprechendes Testprotokoll angelegt Daher soll dieser Teil mit dem Wert 1 belegt werden Somit gilt f r das XCTL System TDA 1 Aggregation zum Gesamtma Portierungsdokumentation Das Ma wird aus den Subma en der Installationsdokumentation und den Testdaten zusammengesetzt Auch hier wird wie bei den Ma en zuvor eine entsprechende Gewichtung durch Faktoren vorgenommen Die Ma e mit den Gewichtungsfaktoren werden analog zu den anderen Ma en summiert und mit der Normierungsbedingung versehen Das Ma f r die Portierungsdokumentation hat folgenden Aufbau DOK p 8 INS g TDA wobei gilt g g 1 F r das XCTL System ergibt sich mit hypothetischer Gewichtung
269. iese umfa t eine Reihe von Werkzeugen zur Erstellung von hardwarenahen 32 Bit Anwendungen und Ger tetreibern Der Aufwand f r die Entwicklung von eigenen Kernel Treibern z B bei Windows NT durch dessen Architektur notwendig um Kernel Mechanismen nutzen zu k nnen bei der Portierung von 16 Bit Anwendungen in eine 32 Bit Umgebung kann somit gr tenteils entfallen Der zeitliche Aufwand f r die Portierung von Windows Anwendungen wird damit verk rzt und die Portierung vereinfacht Es ist somit m glich ohne Einarbeitung in die Kernel Treiber Programmierung hardwarenahe und 16 Bit Windows basierte Software Systeme ber eine gemeinsame Hardware Schnittstelle in eine 32 Bit Umgebung zu portieren Portabilit t von Software Systemen Seite 75 Die Driver Collection von Kithara wird ber spezielle Kernel Treiber unter Windows 9x VxD s realisiert welche die zugrundeliegenden Mechanismen des jeweiligen Windows Betriebssystemkerns und der Prozessorarchitektur nutzen Die Funktionen der einzelnen Werkzeuge werden ber DIl s verf gbar gemacht und k nnen in verschiedenen Programmiersprachen C C Pascal Java etc und Entwicklungsumgebungen Visual C Borland C Borland Delphi etc genutzt werden sofern der Zugriff auf DIl Funktionen unterst tzt wird Die Sammlung an Werkzeugen enth lt den UO Accelerator f r Zugriffe auf I O Ports physischen Speicher und PCI Daten das Hardware Toolkit f r die Behandlu
270. iken f r objektorientierte Software Systeme ssssessseseessssssesesseessseserseses 94 3 1 4 1 bertragbarkeit klassischer Produkt Metriken auf OO Software Systeme 95 3 1 4 2 DIT Depth of Inheritance Tree 97 Inhaltsverzeichnis Seite 6 3 1 4 3 CBO Coupling between Object Classes 98 3 1 4 4 RFC Response for a Class 99 3 1 4 5 WMC Weighted Methods per Class 100 3 2 Metriken zur Portabult tsanalvse nennen 101 3 2 1 Einordnung von Portabilit ts Metriken o oooncnnncnnnnnoonnoccnonnconncnnnoconoconoconn cono nennen 102 3 2 2 Metrikvorschl ge zur Portabilit tsanalyse nn 103 3 2 3 Ausgew hlte Metriken f r die Portabilit tsanalyse ssseeeseeeesesseseeeesssseseesessesesseseess 106 3 2 3 1 Ma phil s phie nee esta an ek Rn RI ah 106 e MaBbOb a se a 106 A E is tea pended dough ates a e A e E NS 107 EE e EE 108 3 2 35 RRE RAN 122 3 2 3 6 Anpassung an objektorientierte Software Bxsteme en 124 4 Portabilit tsanalyse am Beispiel des XCTL Systems scccssscsssssssccsccccscesssscersssssesseeeess 133 41 Das ACTES YM ai 133 4 1 1 Quellcode und Brogrammersprachen 133 A A E RR 134 43 Hardware Umgeb ng assenssenn een atte EERS 134 4 2 Anwendung des Portabilit tsma es auf das XCTL System enenene 135 AD As System mgebuns asus nee a data 138 4 2 1 1 Software Umgebung nenne ennnnnsnnnaen 139 4 2 1 2 Hardware Umgeb ng uresensinanen adela dd 147
271. ildung 16 Werkzeug f r die Portabilit tsanalyse PORTTOOL neeenene 74 Abbildung 17 Behandlung von Entscheidungen mit Mehrfachbedingungen sssnsesssssssssssesrsseesesee 91 Abbildung 18 Beispiel f r das Ma DUT 97 Abbildung 19 Beispiel f r das Ma CBO essen nn 98 Abbildung 20 Beispiel f r das Ma RFC ccccccccesscessceeseeeecesseesneeeseecseeesaecsaecsaeceaeseeeeeeeeeseeeaeeeseensaes 99 Abbildung 21 Sequenzdiagramm f r das RFC Beispiel useenseerseenseeesneesneesnensnnennnne nn 100 Abbildung 22 Beispiel f r das Ma WM 101 Abbildung 23 Qualit tsmodelle als Anwendungsrahmen f r Memiken 102 Abbildung 24 Me platzschema mit Arbeitsplatz PC und Peripherie sseseseeeeseeeesesesssseserssssssee 135 Abbildung 25 bersicht Ma baum f r das Qualit tsmerkmal Portabilit t eeeeeee 136 Abbildung 26 Ergebnis der Ma komponente KOMPsys ohne Komponente Tat 176 Abbildung 27 Anzahl potentieller Anpassungen bzgl der Struktur der Quelldateien 177 Tabellenverzeichnis Seite 11 Tabellenverzeichnis Tabelle Al Vergleich Win16 und Win32 Prozessor und Speicherverwaltung 187 Tabelle A2 Vergleich Win16 und Wim Swvstemkerm nennen 188 Tabelle A3 Vergleich Win16 und Win32 Ein Ausgabe und Dateiswstem 189 Tabelle C4 Die wichtigsten Datentypen von Win16 und Win32 im Vergleich 194 Tabelle DS Quellen bersicht
272. iltern gibt es Werkzeuge wie Pr prozessoren die verschiedene Sprachdialekte ineinander transformieren LeCarme 89 Diese bernehmen Aufgaben wie Makro Bearbeitung Einkopieren von Dateien Anreicherung lterer Sprachen mit modernen M glichkeiten der Kontrollflu manipulation Datenstrukturierung rationale Pr prozessoren sowie Erweiterung von existierenden Sprachen In den letzten beiden Aufgaben kommt der Portabilit tsaspekt zum Tragen Rationale Pr prozessoren erm glichen das Einbinden neuer Kontroll und Datenstrukturierungskonzepte Ein solcher Pr prozessor k nnte z B eingebaute Makros f r while oder if Anweisungen anbieten falls diese in der Programmiersprache selbst nicht existieren Pr prozessoren die den Erweiterungsaspekt in Programmiersprachen abdecken versuchen der Sprache in Form eingebauter Makros neue M glichkeiten hinzuzuf gen Die Idee von Pr prozessoren im Rahmen der Portierung von Software Systemen ist es bestehende Sprachen so auszubauen da sie den modernen Anforderungen entsprechen Mit Hilfe solcher Konzepte wurden weitverbreitete Sprachen wie FORTRAN so ausgebaut da mit ihnen ltere Software Systeme an neue Konzepte angepa t werden konnten RATFOR Auch k nnen in einigen Sprachen mit Hilfe von Pr prozessoren bestimmte Systemabh ngigkeiten durch bedingte Kompilierung effektiv behandelt werden Diese sind jedoch schwierig zu verwalten und sollten nur in Software Systemen mit geringem Umfang verwen
273. in Relation mit anderen Ma en gesetzt werden kann konomie d h da die Messung mit geringen Kosten bzw geringem Aufwand durchgef hrt werden kann und vom Automatisierungsgrad der Anzahl der Me gr en und der Anzahl der Berechnungsschritte abh ngt N tzlichkeit d h da mit einer Messung praktische Bed rfnisse erf llt werden Da durch die lange Lebensdauer des Ma es bedingt durch dessen Evolutionsaspekt eine ganze Reihe verschiedener Ma anwender auftreten spielt die Anforderung der Objektivit t eine besondere Rolle Wird den Anwendern ein zu gro er Freiraum f r Interpretationen gelassen so ist keine exakte und kontinuierliche Bewertung m glich Auch die Vergleichbarkeit von Erfahrungen verschiedener Portierungen w rde dadurch wesentlich erschwert Da die Einflu gr en Systemumgebung und Komplexit t automatisch ermittelt werden ist hierbei die Forderung nach Objektivit t im Sinne einer Ausf hrungsobjektivit t gew hrleistet Die Einflu gr e Dokumentation hat stark subjektiven Charakter da durch einen Review die Kenntnisse des Porteurs in das Ma mit eingebracht werden Metriken und Portierungsaufwand Seite 123 Die Zuverl ssigkeit eines Ma es zeigt sich wenn das Ma unter gleichen Bedingungen bei wiederholter Anwendung zu den gleichen Ergebnissen kommt Dies l t sich u a durch den Einsatz formaler Beschreibungsmethoden und entsprechend homogener Methodendarstellung erreichen Auch die Automa
274. in festgelegtes maximal 64 KB gro es Speichersegment zu realisieren Unter der 32 Bit Plattform von Windows gehen die vermeindlichen Portabilit t von Software Systemen Seite 60 Offsets direkt in einen virtuellen und linearen Adre raum von 4 GB L nge Um diesen zu adressieren wird ein 32 Bit breiter Datentyp ben tigt Ein FAR Zeiger auch unter Win16 32 Bit breit aus einer 16 Bit Umgebung verwandelt sich in einer 32 Bit Umgebung in einen einfachen NEAR Zeiger allerdings mit einer Breite von 32 Bit soda sowohl der Gr enunterschied als auch konzeptionelle Diskrepanzen zwischen einem Win16 NEAR Zeiger und einem Win16 FAR Zeiger dort aufgehoben sind d h sizeof NEAR sizeof FAR Das v llige Aufl sen von Segmentwerten und die Vergr erung des Offsets auf 32 Bit f hren auch dazu da fast alle nicht standardisierten Zeigermanipulationen unm glich werden Abbildung 11 zeigt die verschiedenen Win16 Zeigertypen und deren Gr en im Vergleich zu Win32 Zeigern Diese entspr chen einem 48 Bit Zeiger mit 16 Bit f r den Selektor plus 32 Bit Offset Ein 32 Bit Compiler f r Windows Systeme kennt jedoch keinen eingebauten Datentyp dieses Formats Dieser wird im Win32 API weder benutzt noch ben tigt da Segmente hier vom Betriebssystem einmalig initialisiert und vom Programmierer weder benutzt noch ge ndert werden k nnen NEAR Offset 2 Byte FAR 16 Bit Segment Offset 2 Byte HUGE
275. indungen PDB possible data binding Das Verh ltnis der Anzahl der existierenden Datenbindungen zu der Anzahl der m glichen Datenbindungen wird als relative Datenbindung RDB relative data binding bezeichnet und beschreibt den Informationsaustausch zwischen den Komponenten eines Software Systems ber globale Variablen RDB ADB PDB Die Segment global usage pair Metrik sowie die Datenbindungsmetrik als Vertreter der Datenstruktur Metriken ber cksichtigen jeweils nur einen bestimmten Aspekt der ein Software System beeinflussenden Komplexit t und sind daher allein nicht ausreichend um genaue Aussagen dar ber zu machen So werden z B Absch tzungen ber die Komponentengr e eines Software Systems oder den Aufrufbeziehungen zwischen diesen nicht ber cksichtigt Die Datenstruktur Metriken stellen jedoch eine sinnvolle Erg nzung zu anderen Komplexit tsma en dar wie z B der zyklomatischen Komplexit t von McCabe 3 1 3 8 Komplexit tsma nach Adamov Ausgehend von der Erkenntnis da die Komplexit t eines Software Systems nicht nur von einem Merkmal beeinflu t wird und verschiedene Aspekte bzw Einflu faktoren zu ber cksichtigen sind hat Adamov ein Komplexit tsma entwickelt welches den Versuch unternimmt eine Vielzahl der Einfl sse in das Ma einflie en zu lassen Nach Adamov wird die Gesamtkomplexit t eines Software Systems im Wesentlichen durch die Komplexit t der Komponenten und deren Beziehungen unter
276. int WINAPI _export maxi int value1 int value2 int WINAPI _export mini int value1 int value2 long WINAPI _export maxl long value1 long value2 long WINAPI _export minl long value1 long value2 double WINAPI _export maxd double value1 double value2 double WINAPI _export mind double value1 double value2 pp x LOWORD IParam pp y HIWORD IParam AppendMenu TheMenu MF_POPUP WORD hMAdd amp Psd switch HIWORD IParam sprintf buf Es ist ein Fehler aufgetreten d LOWORD IParam define _CURVECLASS _export typedef TCurve FAR LPCurve typedef TDataBase FAR LPDataBase static WORD RLdx 350 static WORD RLdy 500 define _COUNTERCLASS _export DWORD dwExposureCounts FileSave char_ char_ char_ char_ SetFPOnData int GetFileLine int char_ int UnitEnum char_ U 5 itStr TUnitType Delay long DelayTime int DelayTime int maxi int int mini int int maxl long long minl long long maxd double double mind double double MenuSelect HWND___ unsigned_int long Anhang F Daten der Quelltextanalyse Seite 222 M_devcom h 155 M_devcom h 230 M_devcom h 259 M_devcom h 260 M_devcom h 144 146 DWORD M_devhw h M_devhw h 84 86 145 M_device cpp 416 M_device cpp 417 _layer c ayer c ayer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _la
277. ird Anschlie end werden alle Objektdateien gelinkt und die Anwendung wird in ihrer Zielumgebung getestet Hierbei f hren Fehler zu erneuter Anpassung der Quellen bis die Anwendung fehlerfrei l uft womit die Portierung abgeschlossen ist Die Vorteile der Bottom Up Strategie machen sich vor allem bei Anwendungen bemerkbar deren Portierungsziel eine Mehrweg Portierung darstellt und diese z B R ckw rtskompatibel zur Host Plattform bleiben m ssen Erkennung wiederkehrender Code Muster Mechanisierung von nderungsaufgaben Master Slave Arbeitsteilung bei gro en Projekten Die Bottom Up Strategie erlaubt es wiederkehrende Code Muster die entweder in einer Portabilit tsbibliothek isoliert oder mit Hilfe bedingter Compilierung bzw Makrodefinitionen behandelt werden k nnen zu erkennen Auch kann bei gro en Projekten das einseitige ndern von hnlichen Code Sequenzen unter der Anweisung von erfahrenen Entwicklern von relativ unerfahrenen Programmieren vorgenommen werden Hierbei findet ein enges Wechselspiel zwischen Testen Entwickler und ndern Programmierer statt Verfolgt man die Top Down Strategie wird zun chst ein funktionierendes Minimalprogramm umgesetzt Hierbei wird vom Hauptprogramm ausgehend f r alle Funktionsaufrufe dies setzt eine prozedurale Struktur der Quellen voraus eine leere Funktion gesetzt und dieses soweit an die Zielumgebung angepa t bis ein funktionierendes Hauptger st entsteht Dieses G
278. ird im Speziellen die Portabilit t von Software Systemen auf der Basis des Betriebssystems Windows der Firma Microsoft behandelt Hierbei werden insbesondere Software Systeme beleuchtet die auf der Basis einer 16 Bit Windows Plattform entstanden sind und auf die 32 Bit Plattform von Windows portiert werden sollen Es besch ftigt sich mit den grundlegenden Konzepten von Windows Systemen und beschreibt ausgehend von deren Historie Strategien zur Programmierung von Software Systemen unter Windows Hiernach werden auf der Grundlage der Programmiersprachen C und C sowie den Architekturen des betrachteten Portierungsfelds Windows spezifische Portierungsprobleme identifiziert und klassifiziert Im Anschlu daran werden Strategien und Werkzeuge zur Unterst tzung des Portierungsprozesses vorgestellt Einleitung Seite 14 Im dritten Kapitel wird die Verwendung von Metriken hinsichtlicht der Portierungsanalyse untersucht Hierbei soll ein bestehender evolution rer Ansatz f r ein Portierungsma an bestehende Verh ltnisse angepa t werden Das Portierungsma wird hierbei um die Verwendung objektorientierter Metriken erweitert Der erste Teil der allgemeinen und Windows spezifischen Portabilit tsbetrachtungen sowie der zweite Teil der Untersuchung vorhandener Metriken die den Proze der Portabilit tsanalyse unterst tzen k nnen bilden die Grundlage f r die Untersuchung eines Software Systems zur Steuerung einer R ntgen Topographie Kamera X
279. irmen k nnen nun einen entsprechenden Minitreiber entwickeln der zus tzliche Funktionen unterst tzt die der Unitreiber nicht kennt In Windows 9x werden VxD s dynamisch geladen in Windows 3 1 statisch d h das System l dt immer nur diejenigen Treiber in den Speicher die gerade ben tigt werden Das virtuelle Ger t das ein jeweiliger Treiber erzeugt verwaltet den Ger tezustand f r jede Anwendung und stellt somit sicher da eine Anwendung ohne Probleme auf das Ger t zugreifen kann Um den Informationsaustausch mehrerer Ger te unterschiedlichen Typs ber ein Bussystem und auch Plug and Play zu erm glichen ist ein entsprechendes Konfigurationsmanagement erforderlich Dieser Konfigurationsproze wird mit Hilfe des Konfigurations Managers organisiert der sicherstellt da jedes Ger t einen Hardware Interrupt eine I O Adresse und andere Ressourcen ohne Konflikte mit anderen Ger ten nutzen kann Der Konfigurationsmanager berwacht au erdem Anzahl und Typ der angeschlossenen Ger te sowie die Konfiguration bei Hardware nderungen Der Virtual Machine Manager verteilt im Vergleich zum Konfigurationsmanager nicht die Ressourcen f r alle Ger te sondern f r alle Anwendungen und Systemprozesse Er erzeugt und verwaltet virtuelle Maschinen in denen die Anwendungen und Systemprozesse arbeiten Er ist ein separater Speicherbereich der aus der Perspektive einer Anwendung wie ein einzelnes Computersystem erscheint Windows 9x
280. iterer Aspekt von verwendeten Compiler auf dem Hostsystem ist das Nichtvorhandensein dieser auf dem Zielsystem Dieser Fall tritt h ufig dann ein wenn auf einem neuen Computersystem ltere Programmiersprachen nicht mehr unterst tzt werden Es ist z B nicht trivial dynamische Datenstrukturen wie z B Zeiger auf ein Zielsystem zu portieren dessen Compiler diesen Datentyp Portabilit t von Software Systemen Seite 23 nicht unterst tzt Weitere Compilerprobleme betreffen die Durchf hrung von Laufzeit Pr fungen z B die berpr fung von Array Grenzen zul ssige L nge von Bezeichnern oder auch die Fehlerbehandlung allgemein Betriebssysteminterne Sicht Bottom Up Betrachtet man ein Betriebssystem aus der Sicht der Verwaltung der Bestandteile des zugrundeliegenden Computersystems so lassen sich die Portierungsprobleme den einzelnen Aufgabenbereichen zuordnen Bei der Proze verwaltung geht es um die Organisation von in der Ausf hrung befindlichen Programmen bzw Prozessen Hierbei entscheidet ein Scheduling Algorithmus Round Robin Shortes Job First etc ber die Reihenfolge mit der die einzelnen Prozesse bearbeitet werden Dies kann bei einer Portierung wobei sich Host und Zielsystem durch unterschiedliche Zuteilungsalgorithmen auszeichnen dazu f hren da die Laufzeit eines Software Systems nicht mehr den gestellten Anforderungen entspricht Weiterhin ist die berwachung und Steuerung von Ein Ausgabeger t
281. ith ifndef _WIN32 In the else part of this guard add BOOL WINAPI D11Main HINSTANCE hModule DWORD dwFunction LPVOID 1 switch dwFunction case DLL_PROCESS_ATTACH bModulLoaded FALSE hModuleInstance hModule BwcCRegister hModule TpDList LPDList new TDList nMaxDeviceAllowed hModule hMotorD11 GetModuleHandle motors dl11 break return TRUE Anhang G Porting XCTL From Borland 16 Bit to Visual C 6 0 32 Bit Seite 240 c_layer h add __declspec dllexport in front of WINAPI and CALLBACK words counters cpp introduce local int variable _AX and insert mov _AX ax at the end of inline asm code apply to each function where AN is returned from the function braunpsd c Change FARPROC cast to FARPROC amp change struct time to SYSTEMTIME change gettime to GetLocalTime change tl ti_sec to int t1 wSecond Do the same for t2 ti_sec m_justag cpp to eliminate warning on forcing int to bool for example in some statement x y where x is of type bool and y is of type int you can rewrite the statement as x y 0 m_main cpp add include lt direct h gt comment out BWCCRegister line comment out Ctl3dcolorchange line change string Borland C compiler to Visual C compiler change __BORLANDC__ to _MSC_VER 2 introduce variable char _arg _MAX_PATH and use GetModuleFileName API function to initialize it instead of using _argv I comment
282. iv erfassen Hierzu geh ren neben den klassischen Metriken auch objektorientierte Metriken die auf jeweils unterschiedlich strukturierten Software Systemen arbeiten Die Frage nach speziellen Metriken zur Messung der Portabilit t von Software Systemen f hrte in dieser Arbeit zur Ermittlung einer Reihe von Metrikvorschl gen die diesen Bereich n her beleuchten Hierbei stellte sich heraus da die meisten Vorschl ge nur ein Verh ltnisma enthalten da den Portierungsaufwand eines Software Systems in Beziehung zum Aufwand einer Neuimplementierung setzt ohne jedoch darauf einzugehen wie der Aufwand einer Portierung gemessen werden kann Einige Vorschl ge konkretisieren die Ermittlung des Portierungsaufwands und wurden als Basis f r weitere berlegungen herangezogen Auf der Grundlage des zuvor bewerteten Metrikvorschlags zur Vermessung der Portabilit t von prozedural strukturierten Software Systemen konnte der urspr nglichen Fragestellung nach der Bestimmbarkeit des Portierungsaufwands weiter nachgegangen werden Da das zu untersuchende XCTL System zum gr ten Teil dem objektorientierten Paradigma folgt mu te eine entsprechende Anpassung des Metrikvorschlags f r objektorientierte Software Systeme vorgenommen werden Dabei entstand die Frage nach der bertragbarkeit klassischer Metriken auf objektorientierte Software Systeme wobei sich herausstellte da dies nur eingeschr nkt der Fall ist da die empirischen Objekte im objektori
283. kelt wurden hergestellt werden Ein Standard sollte eine Vielzahl von Systemabh ngigkeiten verbergen und durch eine einheitliche Definition handhabbar machen Wichtige Sprachstandards existieren f r die Sprachen FORTRAN ISO IEC 1539 Programming Language FORTRAN 1991 COBOL ANSI X3 23 Programming Language COBOL 1985 Ada ISO Portabilit t von Software Systemen Seite 25 8652 Programming Language Ada 1995 oder C ANSI X3 159 Programming Language C bzw C ISO IEC 14882 1998 09 01 International Standard Programming Languages C Einige Probleme die bei der Entwicklung eines Sprachstandards auftauchen sollen am Beispiel der Sprache FORTRAN aufgezeigt werden Hierbei wurden erste Erfahrungen bei der Entwicklung von Sprachstandards bereits in den 70er Jahren gesammelt Infotech 80 Ein lterer FORTRAN Standard ist FORTRAN ANSI 66 bzw FORTRAN IV Dieser Standard wurde aber von den meisten FORTRAN Programmen nicht eingehalten und man legte restriktivere Untermengen fest die eine h here Portabilit t von FORTRAN Programmen gew hrleisten sollten Einer dieser Standards ist Portable FORTRAN PFORT f r den ein eigener Filter implementiert wurde welcher FORTRAN Programme auf die Einhaltung des PFORT Standards berpr ft Ein anderer FORTRAN Dialekt wurde als Compatible FORTRAN CF bezeichnet Die Erfahrungen gingen dann in einen neuen Standard FORTRAN 77 ein der einige Erweiterungen gegen ber FORTRAN 66 enthielt Da a
284. konkreten Portierungserfahrungen angereichert werden LE An PAsys SAsys gt BAsys VSGsys um die Ergebnisse korrekt interpretieren zu k nnen und um zeitliche Aufwandsprognosen zu erm glichen 160 140 120 100 80 Anzahl potentieller Anpassungen 65 60 48 48 40 30 20 20 T7 11 H 2 2 gt 6 7 7 je 6 6 5 3 3 3 5 4 3 5 3 l 2 2 2 2 2 1 0 ol Up Di al aola ol Oo niottootlin ac Boob oO oO oO acc oO E BEE oo o ao cac iS HE SR SH CE SH AR a ars o2 2 TI0689 OL LI ZIZCOOLOHEZSOOVOHGALSEZHK OO LO Z GOZO 00 SEAN SR oyn BALL CG LIE DL gt SIEISSACEH5 SA IHR ISLZ gt BDSSBGLCL So LEDGES RAS 2329803530 5029883005 SEL ISSESESO XS IS SSZ ESSE 29 13 PEE Ets 75030 Ig 12s IS 0 l Is loss 23a Bee 3 zB ez 2352 a e 5 H Quelldatei Abbildung 27 Anzahl potentieller Anpassungen bzgl der Struktur der Quelldateien Bei dem darauf folgenden Komplexit tsma KPL werden keine konkreten Aufw nde gemessen Vielmehr wird ber die Vermessung der Systemstruktur versucht Aussagen zur H he des nderungsaufwands zu erm glichen Dar ber hinaus wird damit auch die Testbarkeit eines Software Systems untersucht da eine Portierung immer im abschlie enden Systemtest endet Die Vielschichtigkeit des Problems der Komplexit t von Software Systemen l t jedoch nur eine gewisse Auswahl an wichtigen Einflu faktoren zu die im Hinblick auf die Portierung von Software zwar erfa
285. ktionen und Daten die in keiner Systemkomponente untergebracht sind Solche Komponenten werden f r die Berechnung in einer zus tzlichen gedachten Systemkomponente Tx untergebracht und gehen somit in das Umgebungsma ein Die Anzahl aller Komponenten erh ht sich damit auf den Wert 81 Anzahl aller Komponenten mit BS Anpassungen _ BSM 008 81 Anzahl aller Komponenten Der vierte und letzte Schritt besteht darin die einzelnen Ma e f r die Betriebssystemaufrufe zum Gesamtma BS bzw BS zu aggregieren Dabei ist die Zusammensetzung zu einem einzigen Wert nur dann m glich wenn die Ma e gleiche Objekte messen Diese k nnten dann z B mittels Addition verkn pft werden Da aber die aufgestellten Ma e sehr unterschiedliche Objekte messen ist eine Addition in diesem Falle nicht m glich soda lediglich eine Gegen berstellung der Ma e in einem 3 Tupel sinnvoll ist BS BSM BSM BSM mit BS BS oder BS abh ngig von der gegebenen Situation F r das XCTL System hat man nun alle drei Aussagen zu den Betriebssystem Aufrufen auf einen Blick Es ist somit leicht automatisch zu erstellen da lediglich vorhandene Informationen zusammengetragen werden m ssen BS BSM BSM BSM 3 TAreaScan 1 TBitmapSource 2 0 025 Bibliotheksroutinen Aufrufe Schritte zur Ermittlung der MaBkomponente Bibliotheksroutinen Aufrufe Ermittlung Anzahl unterschiedlicher BS Aufrufe BIBM Alternativ BIBM
286. kumentation beinhaltet u a Angaben zur Software Architektur und zur Spezifikation der Systemkomponenten Bei der Implementierungsdokumentation wird in erster Linie die Verifikationsdokumentation und die externe Dokumentation der Quellen bewertet Die vier Ma e werden zu einem Ma aggregiert indem eine gewichtete Summe gebildet wird Diese sollen Erfahrungen der Relevanz bestimmter Dokumentationsteile bez glich einer Portierung auszudr cken Die Faktoren werden entsprechend normiert um die Aggregation zum Gesamtma Dokumentation durchf hren zu k nnen Die Normierung erfolgt durch Summenbildung zum Wert 1 Das Ma f r die Standarddokumentation hat folgenden Aufbau 4 DOK sp 8 DD g BD g TD g ID wobei gilt Y g 1 i l Liegen noch keine konkreten Portierungserfahrungen vor werden die Gewichtungsfaktoren mit 0 25 belegt was in einem ersten Ansatz bedeutet da alle Teile gleich wichtig sind Diese Annahme ist ggf durch Portierungserfahrungen zu best tigen F r das XCTL System lag nur sehr wenig Dokumentation vor Hierzu geh rten die Schnittstellenbeschreibungen einiger Peripherieger te und eine Dokumentation von Teilen der Initialisierungsdateien des Systems Im Laufe des Reengineering Projekts entstanden jedoch Pflichtenhefte zu bestimmten Aufgabenbereichen sowie ein entsprechender Benutzerleitfaden Auch wurden die Oberfl che und die Dialogelemente untersucht und ein Dokument f r die Beschreibung der Oberfl che en
287. le Speicherallokationen siehe Abbildung 15 m Code Segment e DII Local Descriptor Table m Daten Segment DII Code Segment e Anw 1 D Daten Segment Ana Code Segment e Anw 2 Daten Segment Anw 2 Erlaubter Zugriff Funktionsaufruf Zugriff in das eigene Datensegment gt Nicht erlaubter Zugriff in fremde Datensegmente Abbildung 15 Dll Speicherverwaltung unter Win16 Portabilit t von Software Systemen Seite 68 Ein weiteres Problem betrifft die Ausf hrung von Dll Aufrufen bei ver ndertem Multitasking Mechanismus Werden unter Win16 aufgrund des kooperativen Multitaskings Dll Aufrufe jeweils komplett ausgef hrt atomic function call so k nnen unter Win32 w hrend der Abarbeitung von DIl Aufrufen Proze umschaltungen vorkommen die entsprechende Synchronisationsmechanismen erforderlich machen Insbesondere DIl s welche mehrere Anwendungs Clients gleichzeitig bedienen und zentrale Datenstrukturen manipulieren m ssen den korrekten Zugriff geeignet synchronisieren Aus den Unterschieden zwischen den betrachteten Windows Systemen ergeben sich bei der Portierung von DIl s insbesondere Probleme bei der Nutzung globaler und dynamischer Speicherbereiche deren Initialisierung und Terminierung sowie der Verwendung globaler Windows Klassen Eine Reihe von DIl s gehe
288. le zu den diversen Windows API Funktionen sowie eine einheitliche abw rtskompatible Speicherverwaltung nutzen Portabilit t von Software Systemen Seite 51 Viele der benutzten Begriffe geh ren eindeutig in den Bereich Benutzeroberfl che so z B die Maus oder Fenstersteuerung Bereichsfremd sind aber Multitasking und virtueller Speicher denn dabei handelt es sich eher um Leistungsmerkmale eines Betriebssystems So kann man Windows keiner der beiden Kategorien eindeutig zuordnen Ein direkter Vergleich mit anderen Oberfl chensystemen wie zum Beispiel mit dem unter Unix gebr uchlichen X Window System w re folglich falsch Windows 3 1 ist nicht nur eine grafische Benutzeroberfl che sondern auch eine Erweiterung des Betriebssystems MS PC DOS System VM MM MM Anwendungen WM DOS Win16 Win16 Win16 Anwendung Anwendung Anwendung Anwendung Y ry A F y qn Y N y 3 So d Z Windows 3 1 Kern K Y e User Kernel Ereignis Manager GDI DOS Ger tetreiber Virtual Machine Manager VMM bn Virtuelle Ger tetreiber VxD s ee Hardware Abbildung 6 Systemarchitektur von Windows 3 1 Enhanced Mode Windows 9x Windows 95 und Windows 98 Windows 9x ist ein 32 Bit Betriebssystem und zeichnet sich durch h here Arbeitsgeschwi
289. lit t verwendet Hierbei werden entsprechend den Anforderungen Proze Metriken f r die Vermessung des dynamischen Verhalten eines Entwicklungsprozesses und Produkt Metriken deren Untersuchungsgegenstand das statische Produkt der Softwareentwicklung ist klassifiziert Da die allgemeine Definition von Software Qualit t nach ISO 9126 die Gesamtheit der Merkmale und Merkmalswerte eines Software Produkts die sich auf dessen Eignung beziehen festgelegte oder vorausgesetzte Erfordernisse zu erf llen f r die praktische Anwendung nicht ausreicht setzt man f r die Beschreibung der Qualit t von Software Systemen ein entsprechendes Qualit tsmodell ein Damit wird der allgemeine Qualit tsbegriff durch Ableiten von Unterbegriffen operationalisiert Hierbei wird die Software Qualit t allgemein oder bezogen auf einzelne Entwicklungen durch Qualit tsmerkmale bzw faktoren beschrieben meist aus Benutzersicht und in einem weiteren Schritt in Teilmerkmale bzw Kriterien verfeinert meist softwareorientiert und entsprechend definiert Diese Teilmerkmale werden durch Metriken in diesem Zusammenhang auch als Qualit tsindikatoren bezeichnet me und bewertbar gemacht und zu den Qualit tsmerkmalen in Beziehung gesetzt Man spricht hierbei von Software Qualit tsma en als quantitative Skala mit einer Methode zur Bestimmung des Me wertes den eine Metrik bzw ein Qualit tsindikator f r ein bestimmtes Software Produkt aufweist
290. ls solche auf einfacher Informationsbasis wie die Programml nge beruhen auf der Basis der textuellen Komplexit t So unternahm Halstead Ende der 70er Jahre erste Versuche eine Reihe von Software Metriken f r den Software Entwicklungsproze aufzustellen Die von Halstead Halstead 77 vorgeschlagenen Metriken sind ein gutes Beispiel daf r wie auf der Basis einfacher Metriken eine Vielzahl weiterer Metriken ableitbar sind Die Grundlage f r die Ableitung weiterer Metriken bilden folgende Basismetriken 1m Anzahl der unterschiedlichen Operatoren m Anzahl der unterschiedlichen Operanden N Gesamtzahl der verwendeten Operatoren N Gesamtzahl der verwendeten Operanden Operatoren sind alle Symbole und Schl sselw rter die eine Aktion kennzeichnen Dazu geh ren z B arithmetische Symbole oder Funktionsnamen Als Operanden werden alle Symbole angesehen die Daten repr sentieren z B Variablen Konstanten oder Labels Ein Nachteil ist jedoch da bei der Ermittlung der Basismetriken keine Operatoren und Operanden ber cksichtigt werden die in Deklarationen oder Ein Ausgabefunktionen vorkommen Ausgehend von diesen Basismetriken hat Halstead eine Reihe von Metriken entwickelt die unterschiedliche Eigenschaften eines Software Systems erfassen Dazu geh ren n m m Gr e des Vokabulars N N N L nge der Implementierung N n log 7 7 log 7 alternative L ngengleichung V N log 7 Volumen einer I
291. lt 9 Un 0 10 8 8 7 7 S e 4 5 ee 4 15 La E 4 34 13 2 2 2 993 2 2 11 1 1 1 1 l 1 11 IB o D I Ollon n aHan oll in mul ooo UI 0 3 ON m 09 OD 0942 0 00224 ie EN geen te COME CD UC o 0 GEET BLES BAR ES BO OES RE OR ROE RESUS BE Plo BEBO D3 ONS GOS SESA ZBL 99 387223 PS O SSO SE E e Sen be ER col oH OF a SO SFESLALSFSES oe LOS SEES EL as FLUR o FUSES SSS el RIAS zz OP Sud Sa St or See oS 69 2 Oni 02 E zuUoe 50 Hetto 99552 on HU Seet Se u He 055 O 3 970 6 ke NFO EF mossen oz Ser E of Tee goe F g as Fa Sea 5 G Es FE EE lt fsa Pn Fa End Epes F SF 5 8425559 on F lt SE de O o a NILO NN D EE Fo O CO Er O o PON ap 7 E Oe 5 Ser E E LESA 2 ES F FO DS E E E Systemkomponenten Abbildung 26 Ergebnis der Ma komponente KOMPsys ohne Komponente Tx Sobald das XCTL System portiert worden ist existieren weitergehende Informationen die dem Porteur durch das System Umgebungsma zur Verf gung gestellt werden k nnen Die konkretesten Ergebnisse liefert dabei das Ma BAs Bewertete Anderungsaufwinde aus dem Systemumgebungsma und dem Programmiersprachenma soweit sie durch fr here Portierungen in Erfahrung gebracht werden konnten werden hier aufsummiert und liefern somit einen konkreten Anhaltspunkt f r die Ermittlung einer einzuplanenden Portierungsdauer Die Elemente und Konstrukte Programmiersprachen die bereits als anpa bar identifiziert werden konnten f r die aber w hrend der Portierung keine A
292. m Hinblick auf die Portierung gemeint Abh ngig von diesen Kenntnissen kann nach Ansicht der Autoren der zeitliche Portierungsaufwand sehr unterschiedlich sein und stellt einen insgesamt subjektiven Einflu faktor dar Dieser ist kaum zu erfassen und geht daher nicht in das Portabilit tsma ein Die anderen Faktoren wie Systemumgebung Komplexit t und Dokumentation sind hierbei schon von objektiverem Charakter und weitgehend automatisch bestimmbar Zu den automatisch bestimmbaren Einflu gr en geh ren die Messung der Unterschiede in den Systemumgebungen die durch geeignete syntaktische Analyse durchgef hrt wird und die Vermessung der Komplexit t des Software Systems Der Faktor Dokumentation ist nach Meinung der Verfasser nicht automatisch bestimmbar da nicht automatisch ermittelt werden kann ob die Qualit t ausreichend ist d h ob die n tigen Informationen vorhanden bzw leicht zu finden sind Hierzu mu eine entsprechende Code Inspektion durchgef hrt werden in der das Vorhandensein bestimmter wichtiger Dokumentationskomponenten untersucht wird Diese Inspektion kann sehr umfangreich sein und trotzdem nicht gew hrleisten da die ben tigten Informationen auch wirklich vorhanden waren Dies l t sich nur nach einer erfolgreichen Portierung feststellen Auf der anderen Seite kann aber der Einflu der Dokumentation so gro sein da er als einziger Entscheidungsfaktor f r oder gegen eine Portierung dienen kann So macht es
293. m von einer Portierung eines Software Systems zu sprechen m ssen folgende Bedingungen erf llt sein Komplexit t Komplexit t A Komplexit t Komplexit t und Quellcode Quellcode Auf der zweiten Ebene befinden sich die Programmiersprachenkomponenten von Host und Zielsystem Sie repr sentieren die Schnittstellen zu den dar berliegenden Programmen und werden durch die Konstrukte realisiert die die jeweilige Programmiersprache zur Verf gung stellt Die dritte Portabilit t von Software Systemen Seite 36 Ebene der Softwareumgebung stellt sowohl die Funktionen des jeweiligen Betriebssystems als auch die anderer Komponenten dar z B zus tzliche Bibliotheken Auf der letzten Ebene befinden sich die abstrakten Maschinen der Hardwareumgebung Die Schnittstelle zur dar berliegenden Softwareumgebung wird durch die Menge der Maschinenbefehle realisiert Au erhalb der Hierarchien von Host und Zielsystem befinden sich die externen Einflu faktoren Einfl sse werden im Modell mit gestrichelten Pfeilen dargestellt Informationsfl sse mittels durchgezogener Pfeile Der fettgedruckte Pfeil repr sentiert die eigentliche bertragung des zu portierenden Programms Die Pfeile zwischen den Ebenen der abstrakten Maschinen auf Host und Zielumgebungsseite kennzeichnen den im obigen Sinn angedeuteten hierarchischen Aufbau der betroffenen Komponenten Mit den Kreisen wird ausgedr ckt da an diesen Stellen Informationen die f r die Portierung
294. ments Die 32 Bit Versionen von Windows wie Windows NT oder Windows 9x sowie deren Nachfolger verwenden den 32 Bit Modus der Prozessormodelle 80386 80486 Pentium etc Der C Datentyp mt umfa t hierbei 32 Bit und wird in einem linearen Adre raum angeordnet ohne Segment und Offset Alle Funktionen der Windows API lassen sich gr tenteils in folgende Kategorien einteilen Systemkern Oberfl che und Grafik Der als Kernel bezeichnete Systemkern enth lt Funktionen f r die Speicherverwaltung Datei Management und die Verwaltung von Prozessen Die im sogenannten User Modul zusammengefa ten Funktionen sind f r die Benutzeroberfl che und die Fensterlogik zust ndig Das Modul GDI stellt die grafische Ger teschnittstelle dar und seine Funktionen bernehmen die Darstellung von Text und Grafik sowohl auf dem Bildschirm als auch auf dem Drucker Alle anderen Funktionen k nnen den anderen zur Verf gung stehenden Subsystemen z B POSIX Console API etc zugeordnet werden GUI Graphical User Interface Alle heutzutage blichen grafisch orientierten Benutzeroberfl chen inklusive des Macintosh und Windows beruhen auf Vorarbeiten des Palo Alto Research Centers PARC der Firma Xerox Das dahinter stehende Konzept war bereits Mitte der 70er Jahre dort entwickelt worden und wurde zun chst in einer auf Smalltalk basierenden Umgebung realisiert 10 Jahre sp ter wurde es von Firmen wie Microsoft und Apple vermarktet Die zentrale Idee
295. mmen den Aufwand bei Code Reviews und das Verstehen von Programmen bei Wartungsvorg ngen ermittelt Interne Bindungsmetriken vermessen die syntaktische Bindung von Software Systemen durch Pr fung des Codes einer jeden Systemkomponente Im Vergleich zur semantischen Bindung die durch die Analyse der Bindungsart gekennzeichnet ist und bisher noch nicht direkt berechnet werden kann existieren hier beispielsweise Metriken die das Bindungsverh ltnis von Systemkomponenten aus dem Verh ltnis der Anzahl funktional gebundener Komponenten zur Anzahl aller Komponenten errechnen Auf der intermodularen Ebene von Software Systemen betrachtet man die Kopplung von Komponenten eines Systems im Vergleich zur Bindung auf intramodularer Ebene innerhalb einer Systemkomponente Die Kopplung ist hierbei ein qualitatives Ma f r die Schnittstellen zwischen den einzelnen Komponenten Man unterscheidet den Kopplungsmechanismus Aufruf Verzweigung externe Verbindung die Schnittstellenbreite Anzahl Parameter Datentyp der Parameterelemente und die Kommunikationsart ber Daten oder Steuerinformation Kopplungen zwischen den Systemkomponenten und die Bindungen jeder Systemkomponente bestimmen im Wesentlichen die Struktur eines Software Systems Diese ist um so ausgepr gter und die Modularit t um so h her je st rker die Bindungen der Systemkomponenten im Vergleich zu den Kopplungen zwischen diesen sind Je ausgepr gter die Struktur eines Software Sy
296. mplementierung V 2 m log 2 m potentielle Volumen L V V Programmebene E V L Aufwand f r die Implementierung eines Software Systems der L nge N T E Implementierungsdauer Metriken und Portierungsaufwand Seite 89 Die ersten von den Basismetriken abgeleiteten Metriken sind die Summe der Operatoren und Operanden und werden als Vokabular 7 eines Software Systems bezeichnet Die Programml nge N wird durch die Gesamtzahl aller Zeichen berechnet und bildet ebenfalls ein einfaches Komplexit tsma Eine Alternative zur einfachen Programml nge stellt die sogenannte L ngen Gleichung dar die auf der Annahme beruht da die L nge eines strukturierten Software Systems eine Funktion der Anzahl verschiedener Operatoren und Operanden ist Untersuchungen haben jedoch gezeigt da die L ngen Gleichung eine schlechte N herung f r N bei kleinen oder sehr umfangreichen Software Systemen ist Die Genauigkeit der Vorhersage von N durch N h ngt einerseits vom Programmierstil andererseits aber auch von der H ufigkeit der Verwendung einzelner Operatoren und Operanden ab Bessere N herungen f r N erhielt man mit N wenn die in Deklarationen enthaltenen Operatoren und Operanden bei der Ermittlung der Basismetriken 77 und 77 mitgez hlt wurden Die Volumen Gleichung wird in zwei Varianten interpretiert Die erste sieht das Volumen H als die minimale Anzahl an Bits die f r die Codi
297. n Eine Metrik soll in kompakter Form ber technisch oder wirtschaftlich interessierende Sachverhalte informieren und me bare Eigenschaften dieser Sachverhalte in Ziffern ausdr cken Eine Software Metrik definiert wie eine Kenngr e eines Software Produkts oder eines Software Prozesses gemessen wird Weiterhin wird gesagt Um von einem Software Ma sprechen zu k nnen mu eine Software Metrik bestimmte G tekriterien erf llen Aufgef hrt werden hierbei die G tekriterien Objektivit t Zuverl ssigkeit Validit t Normierung Vergleichbarkeit konomie und N tzlichkeit Hierbei sei das am schwierigsten nachzuweisende Kriterium das der Validit t D h der Nachweis da ein Ma auch tats chlich das mi t was es vorgibt zu messen Hierbei wird deutlich und in qualitativer Hinsicht zwischen dem Begriff Maf und Metrik unterschieden Orth Orth 74 beschreibt im Gegensatz hierzu eine Metrik als Hilfe daf r eine vollst ndige Rangordnung von Objektpaaren aufgrund ihrer hnlichkeit bzgl einzelner Merkmale aufzustellen Der Begriff Metrik wird von ihm wie folgt definiert Sei A eine nichtleere Menge und d eine reelle Funktion auf Ax A Die reelle Funktion d hei t Metrik oder Abstandsfunktion Abstandsma genau dann wenn f r alle a b c A gilt d a a 0 und wenn a b dann d a b gt 0 Positivit t d a b d b a Symmetrie d a b d b c gt d a c Dreiecksungleichung D
298. n SYS PAN ys KOMP ys VKG ys 956 KOMA 0 703 KOMP KOMP KOMP TAbout 2 TAdjustmentExecute 2 TAdjustmentWindow 4 TAm9513a 49 TAngleControl 32 TAquisition y 2 TAreaScan 8 1 1 4 TAreaScanCmd TAreaScanParameters TBitmapSource na ast TBraun_Psd 5 32 22 17 TC 812GPIB Portabilit tsanalyse am Beispiel des XCTL Systems Seite 156 TC_812ISA e TC_832 i TCalibrate TCalibratePsd f TChooseDeviceCmd TCmd TCommonDevParam TCounterShowParam _ TCounterWindow o TCurve TDC_Drive TDevice TDList a TEditWindow TEncoder TExecuteCmd TGenericDevice TMacroExecute i TMain TMDIWindow TMList TModalDig TModelessDlg Tx N N TMotor TMotorParam TOptimizeDC_812 TPlotData TPosControl TPsd TPsdRemoteSync TRadicon TScan TScanCmd TScsParameters TSetAdjustmentParam TSetupAreaScan TSetupContinuousScan TSetupScanCmd TSetupStepScan TShowValueCmd TSteering TStoe_Psd TTopographyExecute _ PH DAN OO G OO A P G A A ON d OO P A rd OM OO GO A NONGA oO P JA d OM GAMM AN A OWN OM oo Ze D D D oo oo oo or og gt E 4 2 2 Komplexit t Die notwendigen Anpassungen eines Software Systems bei einer Portierung setzen einige Kenntnisse ber dessen Aufb
299. n ber die Zielstellung der effizienten und zentralen Bereitstellung von Funktionen hinaus und ben tigen f r die Verwaltung von proze spezifischen privat globalen Datenbl cken zus tzliche Datenbereiche die nur einmal angelegt und global sichtbar sein m ssen Unter Win32 sind DIl s nach dem Laden nicht global bekannt sondern m ssen sich jeweils im Adre raum des Prozesses in den diese geladen wurden bewegen Statische Datenbereiche der Dll globale und static Variablen werden hierbei f r jeden Proze neu angelegt Sobald diese benutzt werden um einer DII die Koordination und Verwaltung mehrerer Prozesse zu erm glichen f hrt dies zu einer Reihe von Portierungsproblemen Dynamische Speicheranforderungen werden unter Win32 immer privat im Adre raum des verursachenden Prozesses ausgef hrt Konnte man unter Win16 durch die grunds tzlich globale Allokation von allen Anwendungen aus gemeinsam auf die dynamisch angeforderten Speicherbereiche zugreifen so ist dieses Vorgehen unter Win32 nicht mehr m glich Auch die unter Winl6 bestehende M glichkeit die Lebensdauer von globalen Speicherallokationen selbst zu kontrollieren ist unter Win32 wirkungslos GMEM_ DDE SHARE Flags und verursacht wie die Annahme da dynamische Speicheranforderungen innerhalb einer DI grunds tzlich global sind weitere Probleme in Bezug auf die Portierung Auch verursachen Allokationen die in den lokalen Heap einer Win16 DIl gelenkt werden um Da
300. n 16 Bit Minicomputer zu portieren Die durchschnittliche Instruktionszeit auf der SPERRY UNIVAC stand zur PDP 11 10 im Verh ltnis 120 zu 1 Dieses Verh ltnis konnte durch Ersetzung bestimmter FORTRAN Routinen durch Assemblerroutinen noch verbessert werden und man war mit der Leistung insgesamt zufrieden Neuere Emulatoren haben die Geschwindigkeitsunterschiede auf ein Verh ltnis von 2 1 verbessern k nnen Eine vom Autor durchgef hrte Vermessung eines kommerziellen softwaretechnisch realisierten Emulators f r Unix und Windows Plattformen der Firma VMWare VMWare 01 ergab beispielsweise ein Verh ltnis von 3 1 Bei der hardwaretechnischen Abbildung werden mit Hilfe von Mikroprogrammen und spezieller Hardwarekomponenten bedeutende Geschwindigkeitsvorteile gegen ber Softwarel sungen erzielt Der Nachteil von Hardware Emulatoren wird darin gesehen da sie nur dann sinnvoll einsetzbar sind wenn die beteiligten Maschinen eine hnliche Architektur aufweisen Leong 83 Portabilit t von Software Systemen Seite 30 2 1 3 3 Architekturebene Wie oben gezeigt versucht man auf Hochsprachenebene dem Prinzip der Vereinheitlichung durch einheitliche Repr sentation von Software Systemen nachzukommen Auf der Ebene der Betriebssysteme ist man bestrebt einheitliche Schnittstellen zu definieren Aber auch auf der Ebene der Maschineninstruktionen existieren Konzepte und Strategien die Portabilit t von Software Systemen zu verbessern Bei den
301. n die geplante Quer Portierung in eine andere Entwicklungsumgebung untersucht wird und somit den Gegenstand weiterer Analysen bildet Mehrere Programmiersprachen Wird bei der Implementierung eines Software Systems mehr als eine Programmiersprache eingesetzt so mu das Ma PS f r jede eingesetzte Sprache aufgestellt werden Alle nicht anpa baren Konstrukte und solche ber die sonst keine Informationen vorliegen werden getrennt aufgef hrt und k nnen zu einer Entscheidung f r oder gegen eine Portierung f hren Alle unbewerteten Konstrukte und die ermittelten Aufw nde k nnen dann zu einem Gesamtma addiert werden Die Addition f r PS macht in diesem Fall wenig Sinn da sich alle durchzuf hrenden nderungen u U nur auf eine der benutzten Programmiersprachen beschr nkt F r diese Komponenten w re dann eventuell eine Neuimplementation einer Portierung vorzuziehen wobei diese Information durch eine Addition der Ma e verloren gehen w rde Aus diesem Grund existieren f r mehrere Programmiersprachen folgende Ma e wobei die zweiten Ma e der Programmiersprachen in einem Tupel zusammengefa t werden Portabilit tsanalyse am Beispiel des XCTL Systems Seite 154 PS KAps_ ces P ps Gus lee ere B ps ces mit KA ces LE dees psn Menge der nicht anpa baren Konstrukte der einzelnen Programmiersprachen P 1 n PAps_crs Se PAps s PAps Menge der Konstrukte der einzelnen Programmiersprachen zu denen kei
302. n stattfindet z B bei der Herausstellung qualitativer Unterschiede Da in den aktuellen Lehrb chern zumeist der Begriff Metrik und nicht Ma verwendet wird um quantitative Bewertungen von Software Produkten oder Software Prozessen zu bezeichnen soll im Rahmen dieser Arbeit dem allgemeinen Kanon folgend der Begriff Metrik bzw Software Metrik verwendet werden Explizite Herausstellung qualitativer Aspekte werden mit Hilfe der Ma Definition nach Balzert ber cksichtigt Beispiele aus der Literatur werden falls sie dem begrifflichen Rahmen dieser Arbeit nicht entsprechen in der vom jeweiligen Autor gew hlten Begrifflichkeit dargestellt 3 1 3 Traditionelle Produkt Metriken f r strukturelle Komplexit t In diesem Abschnitt werden ausgehend von der obersten Ebene einer Systemumgebung zun chst die Kopplungsma e zwischen prozedural strukturierten Systemkomponenten eines Software Systems betrachtet Danach werden auf Komponentenebene die Bindungen von Prozeduren und Funktionen semantische Bindung behandelt und anschlie end verschiedene Metriken zur Messung der prozeduralen Komplexit t vorgestellt 3 1 3 1 Analyse der Kopplungsart Die Kopplung ist ein qualitatives Ma f r die Komplexit t der Beziehungen zwischen Systemkomponenten Prozeduren oder Funktionen eines Software Systems und spielt f r deren Festlegung der Produktqualit t eine entscheidende Rolle Der Grad der Kopplung dr ckt Abh ngigkeiten einzelner S
303. n 1979 Amsterdam New York Oxford North Holland Publishing Company 1980 Brown P J Software Portability An Advanced Course Cambridge England Cambridge University Press 1977 Buchheit M Windows Programmierbuch D sseldorf Sybex 1992 Buschhorn M Kuchnowski H J Entwicklung eines Portabilit tsma es und Entwurf eines Tools zur Unterst tzung der Portierung Dortmund Universit t Dipl Arb 1988 Catanzaro B J The SPARC Technical Papers Springer 1991 Chidamber S R Kemerer C F Towards a Metrics Suite for Object Oriented Design IEEE Transactions on Software Engineering Vol 20 No 6 pp 476 493 1994 Conger J L Windows API Bible Corte Madera Calif Waite Group Press 1992 Doyle J K Mandelberg K I A Portable PDP 11 In Simulator Software Practice and Expirience Vol 14 11 Nov 1984 pp 1047 1059 Fenton N Software Metrics A Rigoros Approach London Chapman Hall 1998 Fetcke T Softwaremetriken bei objektorientierter Porgrammierung Berlin Techn Univ Dipl Arb 1995 Literaturverzeichnis Seite 184 Ford 77 Frank 79 Freund 01 Gewald 79 Gilb 77 Gollnick 99 Gro wendt 98 Halstead 77 Hansen 78 Hommel 80 IEEE 93 Infotech 80 ISO 91 Kaindl 88 Kernighan 99 Kipping 95 Kithara 01 Lake 94 Lauer 96 LeCarme 89 Leong 83 McCabe 76 Ford B Preparing Conventions For Parameters For Tran
304. n Bezug auf den Portabilit tsbegriff besteht Es lassen sich jedoch Tendenzen erkennen die f r die Festlegung eines Sprachgebrauchs dieser Arbeit Verwendung finden k nnen Aus diesem Grund soll im n chsten Abschnitt der Versuch unternommen werden den begrifflichen Rahmen dieser Arbeit aus den einzelnen Definitionen und Begriffsvorstellungen abzuleiten 2 1 1 2 Festlegung des Sprachgebrauchs In diesem Abschnitt soll festgelegt werden welche Bedeutung die Begriffe Portabilit t und Portierung im Rahmen dieser Arbeit haben sollen Weiterhin soll auch gekl rt werden in welcher Beziehung die verschiedenen aufgef hrten Begrifflichkeiten zum Thema Portabilit t stehen Wichtig bei der Festlegung des Begriffs Portabilit t ist zum einen das Verh ltnis zur alternativen Neuimplementation und zum anderen die Beschr nkung auf konkrete Umgebungen in deren Rahmen eine Portierung stattfindet Unter Portabilit t eines Software Systems soll deshalb die bertragbarkeit des Systems oder Elemente des Systems von einer Umgebung in eine davon verschiedene Umgebung verstanden werden Portierung kennzeichnet den Proze des bertragens des Software Systems oder der Systemelemente Ein Software System besteht demnach aus Systemelementen bzw Systemkomponenten Ein Software System kann entweder Systemsoftware erm glicht den Betrieb und die Wartung von Hardware z B Betriebssystem Compiler etc oder Anwendungssoftware sein Anwendungssoftw
305. n Controllerkarte vom Typ C 812 und C 832 die jeweils mehrere Gleichstrommotoren steuern welche u a f r die Bewegungen des Probenhalters des Kollimators und des Detektors verantwortlich sind Der Befehlsaustausch zwischen dem Hostrechner und der Karte C 812 kann optional ber die RS232 Schnittstelle den PC Bus ISA oder der IEEE488 Schnittstelle erfolgen Die beiden letzteren Kommunikationsarten sind im XCTL System wahlweise implementiert Im Falle der Kommunikation ber den PC Bus Konfiguration ber XCTL Initialisierungsdatei wird ein gemeinsam genutzter Speicherbereich Dual Port RAM f r die Befehls bergabe eingerichtet und als Kommunikationskanal verwendet Wird die IEEE488 Schnittstelle f r Steuerbefehle eingesetzt erfolgt die Ansteuerung durch eine programmierfreundliche C Schnittstelle die in Form einer 16 Bit Laufzeitbibliothek Treiber realisiert wird win488 dll C 832 bietet im Vergleich hierzu nur den Datenaustausch ber I O AdreBbereiche mittels Port Befehlen Die Funktionen f r den Zugriff auf die Motoren Hardware werden in der Datei motor cpp definiert Bei der vom XCTL System angesteuerten Detektoren Hardware handelt es sich entweder um 0 1 oder 2 dimensionale Detektoren Diese werden jeweils ber geeignete Schnittstellenkarten des Herstellers betrieben und ber Port Befehle in I O AdreBbreichen gesteuert Folgende Detektoren werden angesteuert bzw sollen zus tzlich eingebunden werden 0O dimensionale
306. n Maschinen abstrahiert Der Hardware Abstraction Layer erlaubt beispielsweise die Entwicklung von Software Systemen ohne Kenntnis des sp teren Proze Interface sowie eine dynamisch anpassungsf hige Verkabelung Die Zuordnung der einzelnen Proze signale zu der in Software Systemen implementierten I O Funktionen ist frei konfigurierbar und somit ohne nderungen an unterschiedliche Schnittstellenkarten anpa bar Dies f hrt zu einer strikten Codetrennung zwischen Software Systemen und Proze Interface Software in diesem Fall die Karten Treiber Ein Problem bei generischen Architekturen besteht in der eindeutigen Festlegung des Abstraktionsniveaus Ist es zu hoch angesiedelt wird unter Umst nden nicht viel gewonnen Bei einem zu niedrigen Niveau leidet die Anpassung an die verschiedenen Hardware Architekturen Ein anderes Problem betrifft die Laufzeit von Software Systemen Da der bei der bersetzung entstandene Portabilit t von Software Systemen Seite 32 Objektcode ber einen Objektcode Interpreter vom Prozessor verarbeitet wird laufen solche Software Systeme in der Regel langsamer als ihre bin rkompatiblen Gegenst cke Das Ziel hierbei ist es also den Vorteil generischer Architekturen mit einem Mindestma an Geschwindigkeitseinbu en bzw bersetzungsaufwand nutzbar zu machen 2 1 4 Portierungsmodelle Modelle haben im allgemeinen die Aufgabe komplexe Zusammenh nge von Situationen oder Problemen berschaubar und somit ha
307. n Seite 61 dieser w chst von 16 Bit WORD auf 32 Bit WPARAM WPARAM ist in beiden Systemen 16 und 32 Bit als vorzeichenloser Integer Wert definiert und zusammen mit LPARAM der jedoch keiner nderungen bedarf da jeweils als 4 Byte breiter Integer Typ LONG definiert f r den Nachrichtenaustausch zust ndig Da viele Nachrichten in den beiden Parametern mehrere Informationen verpacken und diese unter einem 32 Bit Windows System mehr Platz brauchen mu te das Format der betreffenden Nachrichten angepa t werden Das f hrt dazu da die Informationen unter Windows 3 1 anders gepackt sind als unter Windows 9x oder Windows NT Somit ist eine portable und klare Formulierung von Quellen schwieriger da je nach Zielsystem unterschiedliche Zugriffe auf die Nachrichtenparameter notwendig sind Getrennte Adre r ume Die vollst ndige Trennung der Adre r ume unter Win32 sorgt daf r da jede Anwendung ihren eigenen privaten Adre raum erh lt Auf diesen Adre raum haben Prozesse anderer Anwendungen keinen Zugriff weder lesend noch schreibend Damit sind Speicherzugriffe auf die Adre r ume anderer Prozesse und somit die gemeinsame Nutzung von Speicherbereichen wie unter Win16 nicht mehr m glich Der Datenaustausch zwischen den Prozessen wird ber verschiedene IPC Mechanismen d h nur ber vom System definierte Kommunikationswege bzw Interproze Kommunikation realisiert Dazu geh ren Mechanismen wie z B Local Proced
308. n Software Systeme vor die noch unter Windows 2 x im Real Mode laufen sollten diese zun chst an den Protected Mode von Windows 3 x angepa t werden bevor diese im n chsten Schritt in eine 32 Bit Umgebung portiert werden Den besten Ausgangspunkt f r eine Portierung nach Win32 Portabilit t von Software Systemen Seite 70 bilden Software Systeme die im Protected Mode des zugrundeliegenden Prozessors Standard Mode f r 286 Prozessoren oder Enhanced Mode f r 386 Prozessoren und lter fehlerfrei arbeiten und zus tzlich mit der STRICT Option des verwendeten Compilers erstellt worden sind Die STRICT Option versetzt den Compiler in die Lage durch pr zise Definition aller verwendeten Datentypen strengere Typ und Fehlerpr fungen vorzunehmen als sonst blich bei Funktionsaufrufen Zuweisungen etc Damit kann man dem Compiler die Details der Datentyp Kompatibilit t bertragen Software Systeme die in C geschrieben sind k nnen nur bedingt auf die Vorteile der STRICT Option des Compilers zur ckgreifen Ein C Compiler h ngt an die von ihm erzeugten Funktionsnamen in den Objektdateien noch Informationen ber die Datentypen der Parameter sowie des Funktionsresultats Diese Zusatzinformationen erm glichen die Unterscheidung von berladenen Funktionen und werden zus tzlich f r das sp tere typensichere Linken ben tigt Somit werden zwei C Module wovon eines mit STRICT das andere jedoch herk mmlich compiliert wird nic
309. n Software Systemen Seite 31 Generische Architekturen Bei dem Konzept der generischen Architekturen geht es um die Realisierung einer einheitlichen Pseudo Hardware Architektur Diese setzt auf realen Hardware Architekturen auf und wird mittels Laufzeitinterpreter oder bersetzern mit ihr verbunden Hierbei bernimmt die Pseudo Architektur die Rolle einer universellen Hardware Architektur und erm glicht somit Objektcode Portabilit t unabh ngig von der zugrundeliegenden realen Architektur von Rechnersystemen Ein gutes Beispiel f r die Realisierung von generischen Architekturen bietet die zu Anfang der 90er Jahre entwickelte Programmiersprache Java Diese wurde mit dem Ziel entwickelt plattformunabh ngig zu sein Ein Java Compiler bersetzt hierbei ein Quellprogramm in sogenannten Java Byte Code Dieser Objektcode ist plattformunabh ngig und nicht direkt vom Prozessor ausf hrbar Zwischen den generierten Objektcode auch als Zwischencode bezeichnet und die reale Hardware Architektur wird ein Laufzeitinterpreter geschaltet der den Zwischencode f r eine bestimmte Rechnerarchitektur schrittweise analysiert und dann direkt auf dieser ausf hrt Der jeweilige Java Interpreter selbst wird vom Prozessor ausgef hrt und verdeckt die Eigenschaften des jeweiligen Prozessortyps in Form einer virtuellen Maschine Eine andere M glichkeit besteht darin den Zwischencode zur Laufzeit zu bersetzen Hierbei wird ber ein Zusatzprogramm z B
310. n auf ihr Vorhandensein hin berpr ft und folglich bin r bewertet vorhanden nicht vorhanden Die wesentliche Teile werden wie folgt klassifiziert Portabilit tsanalyse am Beispiel des XCTL Systems Seite 165 DOK Dokumentation Standarddokumentation Portierungsdokumentation Programminterne Dokumantation DOK DOK pp DOK y Schritte zur Ermittlung des Teilma es Dokumentation Ermittlung der Ma komponente Standarddokumentation Ermittlung der Ma komponente Portierungsdokumentation Ermittlung der Ma komponente Programminterne Dokumentation Zusammenfassung zur Ma komponente Dokumentation 4 2 3 1 Standarddokumentation DOK sm Standarddokumentation Benutzerdokumentation BD Implementierungsdokumentation Technische Dokumentation ID TD Designdokumentation DD Schritte zur Ermittlung des Teilma es Standarddokumentation Ermittlung der Ma komponente Designdokumentation Ermittlung der Ma komponente Benutzerdokumentation Ermittlung der Ma komponente Technische Dokumentation Ermittlung der Ma komponente Implementierungsdokumentation Auswertung der manuellen Inspektion Zusammenfassung zur Ma komponente Standarddokumentation Mit der Standarddokumentation ist die Dokumentation gemeint die bei der Entwicklung und dem Betrieb von Software Systemen entsteht Dazu geh ren sowohl Entwickler als auch Nutzerdokumen
311. n die Quellen erforderlich machen sind hier die Komponentenma e ebenfalls sinnvoll und lauten wie folgt MAM KOMP Anz MAA KOMP n Anz MAA mit KOMP i te betroffene Komponente des Programms 1 n MAA anzupassender MA Zugriff Ermittelt f r das XCTL System MAM KOMP Anz MAA KOMP Anz MAA TAdjustmentWindow 3 TAm9513a 39 TAreaScan j TBitmapSource 17 TBraun_Psd 1 39 TC_812 f TC_812GPIB TC_832 f TChooseDeviceCmd TCounterShowParam TCounterWindow A TDC_Drive TDevice TEditWindow t TEncoder N o E OO OO OO d PO A OO OO A PO P AAA OOD TGenericDevice TMain TMDIWindow TModalDlg TModelessDlg TMotor TMotorParam TOptimizeDC_812 j TOptimizeDC_832 f TPlotData R TPsd y TRadicon y _ YS e WS SS WS WS I TN TN NS ee wae Portabilit tsanalyse am Beispiel des XCTL Systems Seite 150 TScan 4 TScanCmd 1 TSetupContinuousScan 2 TStoe_Psd i 7 Tx 298 Der dritte Schritt die Ermittlung des Komponenentverh ltnisses MAM Anzahl aller Komponenten mit MA Zugriffen Anzahl der Komponenten ergibt f r das XCTL System Anzahl aller Komponenten mit MA Zugriffen 32 _ 0 395 I mern MAM Anzahl der Komponenten 8 Der vierte Schritt besteht dann wieder aus der Zusammenf hrung der Ma e f r d
312. n nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_REQUEST WM_DDE_REQUEST IParam fuer Informationen nicht ausreichend MBE PackDDEIParam etc benutzen WM_DDE_TERMINATE WM_DDE_TERMINATE IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_DDE_UNADVISE WM_DDE_UNADVISE IParam fuer Informationen nicht ausreichend MBE PackDDElParam etc benutzen WM_HSCROLL WM_HSCROLL Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_MDIACTIVATE WM_MDIACTIVATE Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_MDISETMENU WM_MDISETMENU Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_MENUCHAR WM_MENUCHAR Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_MENUSELECT WM_MENUSELECT Information in wParam lParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_PARENTNOTIFY WM_PARENTNOTIFY Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_QUIT WM_QUIT Falls in einem PostMessage Aufruf Fehlfunktionen unter Win32 moeglich MBE Ersetzen durch PostQuitMessage WM_VKEYTOITEM WM_VKEYTOITEM Information in wParam lParam anders verpackt MBE message cracker oder alternative Makroschale benutzen WM_VSCROLL WM_VSCROLL Information in
313. n of a software unit or a system in a new environment based on an existing version Portierung ist demnach die Erstellung eines ausf hrbaren Software Systems basierend auf einer bereits vorhandenen Version dieses Systems Unter dem Begriff Software Unit versteht er Anwendungssoftware System Software und Teile dieser Software System Software ist dann eine Sammlung von Software Units Balzert beschreibt Portabilit t mit folgenden Worten Balzert 96 Portabilit t genauer gesagt Anwendungs Portabilit t bedeutet da die Konzepte die bei der Erstellung der Anwendungssoftware benutzt werden auf unterschiedlichen Systemen verschiedener Hersteller zur Verf gung stehen Des weiteren werden hier Abstufungen zur Portabilit t unterschieden Objektcode Portabilit t bin re Portabilit t Quellcode Portabilit t und Entwurfs Portabilit t Objektcode Portabilit t bezeichnet die Ausf hrbarkeit von lauff higen Anwendungen auf verschiedenen Plattformen Quellcode Portabilit t kennzeichnet die bertragbarkeit eines Quellcodes von einer Plattform auf eine andere Plattform wobei der Quellcode auf der neuen Plattform neu bersetzt und anschlie end ausgef hrt werden kann Portabilit t von Software Systemen Seite 19 Entwurfs Portabilit t ist der Entwurf einer Anwendung basierend auf Konzepten die leicht in andere Implementierungen transformiert werden k nnen Es zeigt sich da noch kein einheitliches Verst ndnis i
314. n sind PS Ermittlung ob Annahmen ber den Zielrechner vorhanden sind AZ Ermittlung ob hardware abh ngige Komponenten dokumentiert werden HK Ermittlung ob die verwendeten Begriffe erkl rt werden VB Auswertung der manuellen Inspektion Zusammenfassung zur Ma komponente Installationsdokumentation Eine gute Installationsdokumentation sollte auf jeden Fall alle der aufgef hrten Elemente aufweisen Analog zum Ma f r die Standarddokumentation setzt sich das Ma f r die Installationsdokumentation wie folgt zusammen 4 INS g PS g AZ g HK g VB wobei gilt g 1 i 1 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 168 Hierbei wird die Hypothese aufgestellt da Angaben zu den Portierungsschritten sowie die Annahmen ber den Zielrechner st rkeren Einflu auf den Portierungsaufwand haben als die restlichen Elemente Aus diesem Grund kann hier bereits eine erste hypothetische Annahme wie folgt getroffen werden INS 0 4 PS 0 3 AZ 0 2 HK 0 1 VB Bei dem XCTL System liegen in diesem Sinne bisher keine Portierungsdokumente vor Es liegen aber Annahmen zu den Zielrechnern vor und es ist auch schon ausreichend bekannt welche Teile des Systems hardwareabh ngig sind Die verwendeten Begriffe sind bisher sehr eingeschr nkt dokumentiert F r das XCTL System ergibt sich f r die Installationsdokumentation somit folgendes INS 0 4 0 0 3 1 0 2 1 0 1 0 0 5 Testdaten Nach erfolgter Port
315. n werden Eine reine Datenkopplung liegt vor wenn der Informationsaustausch ber Parameter erfolgt die keine Kontrolldaten und keine strukturierten Daten darstellen Die bergabe von reinen Daten ist somit die einfachste Kommunikationsart und f r das Funktionieren eines Systems ausreichend Sobald ein Prozedurparameter dazu verwendet wird anderen Prozeduren mitzuteilen was zu tun ist handelt es sich schon nicht mehr um eine reine Datenkopplung sondern um eine Kontrollkopplung Dadurch werden die Verbindungen zwischen Prozeduren erh ht da die Prozedur die auf eine andere zur ckgreift ber Kenntnisse des Inneren dieser Prozedur verf gen mu Die reine Datenkopplung ist die schw chste Kopplungsart da die gegenseitige Beeinflussung der betroffenen Komponenten hierbei am geringsten ist und zus tzlich auf nur zwei Komponenten beschr nkt bleibt Somit ist die anzustrebende Kopplung zwischen zwei Systemkomponenten der Aufruf mit Parametern wobei die Parameter jeweils nur aus reinen Daten bestehen Der Aufruf wird benutzt um eine minimale Anzahl von Datenparametern auf die verst ndlichste Weise zu bertragen Folgende Voraussetzungen m ssen nach Balzert 98 erf llt sein um diese Art der Kopplung zu erreichen schmale Datenkopplung Metriken und Portierungsaufwand Seite 86 Prozedurkopplungen werden nur durch Aufruf anderer Prozeduren hergestellt Die eigentliche Kommunikation erfolgt nur ber explizite Parameter Global
316. n zu treffen Jede Metrik quantifiziert dabei einen begrenzten Bereich einer Systemkomponente intramodular oder des Systems intermodular und erlaubt nicht ein Software System als Ganzes zu erfassen In Balzert Balzert 98 findet sich deshalb auf intramodularer Ebene auch der Begriff Komponentenmetriken Auf intermodularer Ebene spricht man hier von Kopplungsmetriken Der gr te Teil der Produkt Metriken bezieht sich auf die Komplexit t der zu analysierenden Software Systeme Die Zahl der publizierten Metrikvorschl ge allein im Bereich der klassischen Komplexit tsmetriken wird mit ber 200 angegeben Zuse 91 Hierbei unterscheidet man auf intramodularer Ebene die semantische und prozedurale Komplexit t von Systemkomponenten Die semantische Komplexit t einer Systemkomponente wird durch ihre semantische Bindung Verbindung zwischen den Systemelementen und die Aufgabenvielfalt einer Systemkomponente ausgedr ckt und l t sich durch Metriken noch nicht direkt messen Man kann jedoch sagen da eine gute Bindung immer dann vorliegt wenn nur solche Elemente zu einer Einheit zusammengefa t werden die auch zusammengeh ren Es gibt daher Ans tze von qualitativen Ma en welche die Kompaktheit einer Prozedur oder Funktion in Form von Bindungsarten beschreiben funktional sequentiell kommunikativ etc Zur Messung der prozeduralen Komplexit t werden traditionell f nf Klassen unterschieden Umfangsmetriken logische St
317. naus auch das Projektmanagement und aus Portabilit tssicht ergeben sich Gr nde f r die Verwendung von Dis aus der Sprachunabh ngigkeit und der teilweisen berwindung von Plattformunterschieden Man kann z B diejenige Sprache ausw hlen die f r eine bestimmte Aufgabe am besten geeignet erscheint Das Betriebssystem erlaubt dann beispielsweise einem Visual Basic Programm eine C DIl eine Cobol DII oder eine Fortran DIl etc zu laden Aber auch einzelne Plattformunterschiede von Software Systemen zu einzelnen Windows Versionen k nnen mit Hilfe von DIl s zum Teil berwunden werden So k nnte man neue Mechanismen aktueller Windows Versionen durch spezielle Funktionen bereitstellen die vom Entwickler in einer aktuellen Version des Software Systems nutzbar gemacht Portabilit t von Software Systemen Seite 42 werden sollen Fa t man solche Funktionen in einer DU zusammen k nnen Anwendungen unter einer lteren Windows Version trotzdem ausgef hrt werden auch wenn f r die neueren Funktionen keine entsprechende Unterst tzung existiert W rde man in einem solchen Fall auf die Nutzung von DII s verzichten k nnte der Lader des Betriebssystems die Anwendung nicht ausf hren da der Quellcode einen Aufruf einer Funktion enth lt welche in der Windows Version in der die Anwendung ausgef hrt wird nicht unterst tzt wird Au erdem tragen DIl s zur sparsamen Verwendung von Speicher bei und erm glichen die gemeinsame Verwendung von R
318. nconconnocnnoconoconocos 44 2 2 3 1 Portable C und Crt Softiware Bwsteme een 44 2 2 3 2 Architekturen des betrachteten Portierungsfelds 22440204042 sense 48 2 2 3 3 Identifikation und Klassifikation Windows spezifischer Portierungsprobleme 57 2 24 Strategien und Werkzeuge zur Portierung von Win16 nach Wm 69 2 2 4 1 Ausgangspunkt und Zielsetzung 69 2 2 4 2 Strategien zur Portierung enneenseenseesseessnesnnensnensnnnnnennnnnnnnsennsennneenseennennsnense ons cra nenn 71 2 2 4 3 Hilfsmittel und Werkzeuge cc cccccccsceesseescecsseessecesecesecesecesecseeeeeeeeneceseeeseeceeesaeeaees 12 3 Metriken und Portierungsaufwand e sooescoesooesoossoessoessoesssessscsssesssesssessseessesssesssesssesssessseessosso 77 Sil Softw re Mettiken 2 2 2 li tati 77 lade e TE er ae n A A 77 34 2 Ma und Memkbeenft o E a R A 79 3 1 3 Traditionelle Produkt Metriken f r strukturelle Komplexit t 82 3 1 3 1 Analyse der Kopplungsart nennen 82 3 1 3 2 Analyse der Bmdungsart esse ens nennen 86 3 1 3 3 ProgrammMlange sn 87 34 3 4 Halstead Metriken 3 29 tunen herein 88 3 1 3 5 Zyklomatische Komplexit t nach McCabe cunnenesseeesneesneesnnnennnennn nennen 90 3 1 3 6 Segment global usage pair Metrik uueeeeesssesssnesssesnsennsennnennneennennennnenne nennen 92 3 1 3 7 Datenbind ngsmetcik un esessneirare eier meinst 93 3 1 3 8 Komplexit tsma nach Adamy 93 3 1 4 Produkt Metr
319. nd erm glicht werden Weiterhin kann anhand dieses Ma es die Entscheidung getroffen werden ob eine bestimmte Systemkomponente mit sehr vielen BS Aufrufen nicht besser neu implementiert statt angepa t werden sollte Auch ist der Einarbeitungsaufwand h her je mehr die anzupassenden Aufrufe ber die Komponenten des Software Systems verteilt sind Die Summe der nderungskandidaten ergibt sich aus den ermittelten Werten der Porttool Analyse und kann somit automatisch bestimmt werden BSM KOMP Anz BSA KOMP Anz BSA M _ arscan cpp 1 M _ data cpp 2 Der dritte Schritt besteht darin das Verh ltnis der von nderungen betroffenen Komponenten zur Gesamtkomponentenzahl zu ermitteln Damit werden weitere Informationen f r eine Entscheidung Portierung oder Neuimplementierung geliefert Je n her sich das Verh ltnis dem Wert 1 n hert desto g nstiger wird das Verh ltnis f r eine Neuimplementierung Portabilit tsanalyse am Beispiel des XCTL Systems Seite 142 BSM Anzahl aller Komponenten mit BS Anpassungen Anzahl aller Komponenten Die Anzahl aller Komponenten f r das XCTL System ergibt sich aus einer Messung mit dem McCabe Tool Gollnick 99 welches u a f r die Ermittlung von Metriken f r Software Systeme dient Die Messung ergab f r die Anzahl der Komponenten den Wert 80 Da das XCTL System nicht durchg ngig objektorientiert programmiert ist ergibt sich das Problem der Zuordnung globaler Fun
320. nden kann Neben den betrachteten Vorteilen existieren aber auch gewisse Schwachpunkte der McCabe Metrik Ein Punkt betrifft beispielsweise die Behandlung von Entscheidungen mit Mehrfachbedingungen So existieren bei der Anweisung if a 0 and b 0 then zwei M glichkeiten der graphischen Darstellung N Fall a Fall b Abbildung 17 Behandlung von Entscheidungen mit Mehrfachbedingungen Berechnet man im Fall a die zyklomatische Komplexit t so erh lt man den Wert 2 im Fall b den Wert 3 F r McCabe sind zusammengesetzte Entscheidungen komplexer als Entscheidungen mit einer einzigen Bedingung und entscheidet sich somit f r die Behandlung ber Variante b Meyers Meyers 77 f hrt in seinen Arbeiten jedoch an da die drei Entscheidungen if x 0 then else if x 0 and y lt 1 then else 1f x 0 then if y lt 1 then else else nach der Interpretation von McCabe die Werte 2 3 3 h tten und nach seiner Meinung so nicht korrekt ist da die dritte Anweisung Metriken und Portierungsaufwand Seite 92 komplexer ist als die Zweite F r die zusammengesetzte Entscheidung in der zweiten if Anweisung w rde man die Werte 2 2 3 erhalten Dies steht nach Meyers aber im Widerspruch zu der Auffassung da die zweite Entscheidung komplexer ist als die Erste Somit schl gt er vor die zyklomatische Komplexit t als Intervall anzugeben dessen Grenzen durch die Anzahl der Entscheidungen untere Grenze
321. ndhabbar zu machen Dabei wird von den unwesentlichen Faktoren der zu modellierenden Realit t abgesehen und nur die Faktoren ber cksichtigt die f r eine reale Situation oder ein reales Problem von Bedeutung sind Um ein Verst ndnis von den Zusammenh ngen und Abl ufen eines Portierungsprozesses zu bekommen ist es notwendig Modelle die diesen realen Proze beschreiben aufzustellen Ein solches Proze modell bildet eine gute Grundlage f r weitere berlegungen in Richtung Me barkeit oder Optimierung von Portierungsprozessen F r Portierungsprobleme existieren Modelle die die Portabilit t von Software Systemen zum einen ber dessen Beziehungen zur Systemumgebung beschreiben und zum anderen Modelle die den eigentlichen Proze der Portierung behandeln Im folgenden soll eine Auswahl an Modellen vorgestellt werden die f r das Verst ndnis des Portierungsprozesses von Nutzen sind Ein Modell welches die Beziehungen eines Software Systems zu seiner Systemumgebung darstellt wird von Mooney beschrieben Mooney 94 Seine Sicht konzentriert sich auf die Schnittstellen zwischen dem zu portierenden Software System und den sich ndernden Umgebungskomponenten Die Schnittstellen Sicht bezieht sich nicht auf den Proze der Portierung liefert jedoch Hinweise auf zu ber cksichtigende Abh ngigkeiten zwischen den einzelnen Komponenten Application LS Support Program Procedures Operating UO System Devices Remote Users Terminals
322. ndigkeit sowie robusteren Aufbau im Vergleich za Windows 3 1 aus Das Architekturdesign von Windows 9x basiert im Wesentlichen auf der von Windows 3 1 Es beinhaltet eine Reihe von Kompromissen die getroffen werden mu ten um als modernes Betriebssystems m glichst kompatibel zu seinen Vorg ngern zu sein Die wesentlichen nderungen betreffen die neuartige Architektur f r Ger tetreiber das Dateisystem sowie die Grafik Engine zusammen mit dem Subsystem f r Druckausgabe der Kommunikation und Multimedia Auch sind Netzwerkfunktionen jetzt direkter Bestandteil des Betriebssystems Windows 9x verf gt im Vergleich zu Windows 3 1 ber ein voll integriertes 32 Bit Betriebssystem f r den Protected Mode Vorteil Es macht die Benutzung einer separaten Kopie von MS DOS berfl ssig eine Unterst tzung von preemptiven Multitasking und Multithreading Vorteil Verringerung der Antwortzeiten des Systems und st rungsfreier Hintergrundbetrieb von Programmen Portabilit t von Software Systemen Seite 52 die M glichkeit 32 Bit Dateisysteme zu installieren wie VFAT CDFS und Netzwerk Redirector mit besserer Arbeitsgeschwindigkeit langen Dateinamen und einer offenen Architektur f r zuk nftige Erweiterungen 32 Bit Ger tetreiber Vorteil h herer Geschwindigkeit und Stabilit t sowie intelligente Ausnutzung des Hauptspeichers erh hte Stabilit t von Anwendungen und Aufr umaktionen beim Absturz eines Programms Vorteil b
323. ndows 3 1 vollst ndig ab und erscheint aus Anwendersicht als eine einzige Speicherstelle f r Systeminformationen Sie wird auf Systemebene durch zwei Dateien n mlich mit Informationen ber das Rechnersystem selbst System dat und die Anwenderdaten User dat repr sentiert Die Registrierdatenbank ist eine hierarchische Datenbank die sich aus einzelnen Registrierschl sseln zusammensetzt Sie erm glicht den Fernzugriff auf Win32 Anwendungen sowie deren Fernverwaltung ber das Netzwerk und dient als zentrale Speicherstelle f r ger tespezifische Daten die u a von den Plug and Play Komponenten ausgewertet werden Portabilit t von Software Systemen Seite 53 In Windows 9x werden einzelne Ger te wie im Enhanced Mode von Windows 3 1 ber virtuelle Ger tetreiber angesprochen Auch hier bezieht sich Val auf einen allgemeinen virtuellen Treiber Universal Treiber wobei das x f r den jeweiligen Ger tetyp steht Virtual Display Driver Virtual Timer Driver etc Die meisten virtuellen Ger tetreiber verwalten Hardware aber es gibt auch solche die Software verwalten z B DOS Ger tetreiber oder speicherresidente Programme Die neuartige Architektur der Ger tetreiber teilt sich auf in Unitreiber und Minitreiber F r die meisten Ger tetypen werden hierbei vom Betriebssystem allgemein g ltige Universaltreiber angeboten und enthalten Schnittstellen zu den jeweiligen Komponenten von Windows 9x z B Drucksubsystem etc Hardware F
324. ne Grundvoraussetzung f r den erfolgreichen Aufruf der nachfolgenden Modi ist die Verwaltung des externen Speichers gem XMS Spezifikation eXtendend Memory Specification Damit wird der Datenaustausch zwischen Erweiterungsspeicher der Speichermodule und den unteren 640 KB des DOS Speichers realisiert und erm glicht somit anders als bei der Portabilit t von Software Systemen Seite 50 Bereitstellung von Erweiterungsspeicher ber externe Expandend Memory Speicherkarten die direkte Nutzung des erweiterten Adre raum von bis zu 16 MB Der Standard Mode ist auf die speziellen Eigenschaften von Rechnersystemen mit 80286 CPU s ausgerichtet Alle Anwendungen laufen hierbei wie auch im folgenden Enhanced Mode im 16 Bit Protected Mode dieses Prozessors Wesentliche Unterschiede zum Real Mode liegen in Schutzmechanismen f r die Speicherverwaltung verbunden mit einer segmentorientierten Adressierung des Speichers ber Deskriptor Tabellen sowie grunds tzlichem Support von Task Wechseln durch spezielle Strukturen und Befehle Der segmentorientierte Adressierungsmechanismus der 80286 Prozessoren kann bis zu 16 MB an Speicher adressieren wobei das erste Megabyte f r konventionellen und hohen Speicher reserviert ist Die anderen 15 MB k nnen ber den bereits angesprochenen Extended Memory Mechanismus direkt als physisch vorhandener Speicher verwaltet oder als virtueller Speicher auf einer Festplatte ausgelagert adressiert werden Eb
325. ne Informationen existieren SAps Ges SAps SAps Summe der anpa baren Konstrukte der einzelnen Sprachen PS zu denen keine Bewertungen existieren BAps ces BAps BAps Summer der bewerteten Konstrukte der einzelnen Sprachen PS L PS PS i505 EE Aggregation zum Gesamtma Programmiersprachen Das aggregierte Programmiersprachenma f r die System Umgebung z B f r den Fall der Analyse einer Quer Portierung lautet PS PS PS mit PS PS oder PS i 1 2 abh ngig von der gegebenen Situation 4 2 1 4 Aggregation zum Gesamtma System Umgebung Der letzte Schritt bei der Ermittlung des Ma es f r die System Umgebung besteht darin die bisher aufgezeigten und ermittelten Ma e zusammenzuf hren Dabei lassen sich bei den einzelnen Faktoren eine Reihe von bereinstimmungen feststellen An diesen Positionen werden sie dann geeignet zusammengefa t So existieren z B bei dem Software Umgebungsma Betriebssystemroutinen bzw bei dem Programmiersprachenma Sprachkonstrukte die nicht an die Zielumgebung angepa t werden k nnen Dar ber hinaus enthalten z B Software und Hardware Umgebungsma das gleiche Verh ltnisma etc Bei der Aggregation werden die Ma e AUT und PS als jeweils umfassendere Ma e zugrundegelegt Zur Orientierung seien hier noch einmal kurz die entsprechenden Teilma e aufgef hrt SU PAN KOMP VKGy bzw SU LE PA L Bd s PAN y KOMP VKG su HU
326. nen TMain LoadMenuBar M_main cpp 1461 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Ausfuhren TMain LoadMenuBar M_main cpp 1475 AppendMenu hmPL1 MF_POPUP WORD hmPL2 amp Antriebe TMain LoadMenuBar M_main cpp 1488 AppendMenu hmPL1 MF_POPUP WORD hmPL2 amp Detektoren TMain LoadMenuBar M_main cpp 1494 AppendMenu hmPL1 MF_POPUP WORD hmPL2 Matro amp x TMain LoadMenuBar M_main cpp 1498 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Einstellungen TMain LoadMenuBar M_main cpp 1505 AppendMenu hTheMenu MF_POPUP WORD hmPL1 LPSTR amp Fenster TMain LoadMenuBar M_main cpp 1511 AppendMenu hTheMenu MF_POPUP WORD hmPL1 LPSTR amp Hilfe TMain LoadMenuBar M_main cpp 1533 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp File TMain LoadMenuBar M_main cpp 1538 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Edit TMain LoadMenuBar M_main cpp 1550 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Open TMain LoadMenuBar M_main cpp 1562 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Execute TMain LoadMenuBar M_main cpp 1575 AppendMenu hmPL1 MF_POPUP WORD hmPL2 amp Motors TMain LoadMenuBar M_main cpp 1583 AppendMenu hmPL1 MF_POPUP WORD hmPL2 amp Detectors TMain LoadMenuBar M_main cpp 1585 AppendMenu hTheMenu MF_POPUP WORD hmPL1 amp Settings TMain LoadMenuBar M_main cpp 1592 AppendMenu hTheMenu MF_POPUP WORD hmPL1 LPSTR amp Window TMain LoadMenuBar KOMP TMain A
327. ng Anmerkungen Ausblick Ausgehend von der Fragestellung ob der Aufwand f r die Portierung von Software Systemen im voraus bestimmbar ist sollte ein Windows basiertes Software System zur Steuerung einer R ntgen Topographie Kamera XCTL System im Rahmen eines Reengineering Projekts untersucht werden Hierbei ist sowohl die Portierung von einer 16 Bit Plattform Windows 3 1 in eine 32 Bit Windows Umgebung Windows 98 als auch ein Wechsel in eine andere Entwicklungsumgebung von Borland C nach Visual C geplant Zur Beantwortung der Fragestellung bzgl der Portierung auf die 32 Bit Windows Plattform wurden zun chst alle wichtigen Aspekte zum Thema Portabilit t systematisch zusammengetragen Hierbei hat sich gezeigt da die Probleme sehr vielschichtig sind Um die Handhabung von Portabilit tsuntersuchungen zu vereinfachen wurden bestehende Portierungsmodelle vorgestellt und diskutiert Auf der Grundlage dieser allgemeinen berlegungen wurden dann im Speziellen die Probleme bei der Portierung Windows basierter Software Systeme behandelt und entsprechend der Fragestellung klassifiziert Die systematische Darstellung der Portabilit tsprobleme Strategien Konzepte und Werkzeuge im Allgemeinen wie auch im Speziellen bildeten das Fundament f r weitere berlegungen bzgl der Aufwandsanalyse Um Software Systeme zu vermessen existieren eine Reihe von Metriken die jeweils unterschiedliche Aspekte von Software Systemen quantitat
328. ng von Hardware Interrupts innerhalb der Anwendung ein Timer Toolkit zur Programmierung von genauen Timern und hochaufl senden Ermittlung der Systemzeit das Serial Toolkit f r die Programmierung der seriellen Schnittstellen sowie den Dos Enabler f r den Betrieb von hardwarenahen 16 Bit Anwendungen unter Windows NT und Windows 2000 Folgende Funktionen werden von den Werkzeugen abgedeckt Direkter Zugriff auf beliebige I O Ports Zugriff auf physischen Speicher Genaue Zeitmessungen Pr zise Timer in hoher Aufl sung Interrupt Behandlung Serielle Kommunikation Code Ausf hrung auf der Kernel Ebene Sonstige Funktionen z B Zugriff auf Shared Memory Bereiche etc Metriken und Portierungsaufwand Seite 77 3 Metriken und Portierungsaufwand Ausgehend von allgemeinen Aspekten bez glich Software Metriken geht es in diesem Kapitel im Besonderen um die Darstellung von Metriken die zur Bestimmung des Portierungsaufwands von Software Systemen herangezogen werden k nnen Auf der Grundlage von bereits bestehenden Portabilit tsma en werden die M glichkeiten der Vermessung von Software Systemen unter dem Aspekt der Portabilit t aufgezeigt und um aktuelle Entwicklungen im Bereich der objektorientierten Programmierung erg nzt 3 1 Software Metriken In diesem Abschnitt geht es um die allgemeine Darstellung von Software Metriken und deren Nutzen in Bezug auf die Verwendung bei der Por
329. ngepa t werden Stehen mehr sprachliche Aspekte im Vordergrund wird eher der Begriff Zwischensprache anstatt abstrakte Maschine benutzt Ein anderer Ansatz Portierungsprobleme bzgl der Unterschiede der Sprachdialekte in den Griff zu bekommen besteht darin den Compiler selbst so portabel zu gestalten da er mit seinem akzeptierenden Sprachdialekt in jeder beliebigen Umgebung zur Verf gung steht z B Unix Portable C Compiler Amsterdam Compiler Kits Tanenbaum Sind Compiler in ihrer Architektur so angelegt da sie schnell an verschiedene Umgebungen angepa t werden k nnen so spricht man von portablen Compilern Der entscheidende Faktor f r die Portierung von Compilern ist die Schnittstelle zwischen Front und Back End Die Front End Komponente lexikalische syntaktische und semantische Analyse kann dabei meist maschinenunabh ngig realisiert werden und ist bei portablen Compilern der unkritischere Teil Die Back End Komponente von Compilern Zwischencode Codeoptimierung Codeerzeugung realisiert die Transformation eines Software Systems in eine lauff hige und systemabh ngige Bin rversion Dieser Teil des Compilers ist stark maschinenabh ngig und mu f r jede Umgebung entsprechend angepa t werden Hauptproblem bei der Anpassung von portablen Compilern sind die unterschiedlichen Betriebssystemaufrufe der einzelnen Umgebungen die jeweils ein hohes Ma an Einarbeitungsaufwand erfordern Somit bleibt die umfangrei
330. nment GetEnvironment Kein Win32 Aequivalent DOS GetFileResource GetFileResource Kein Win32 Aequivalent DOS GetFileResourceSize GetFileResourceSize Kein Win32 Aequivalent DOS Ge Ge Ge Ge Focus GetFocus Rueckgabe kann gleich 0 sein GD FreeSpace GetFreeSpace Kein Win32 Aequivalent InstanceData GetInstanceData Kein Win32 Aequiva Lokalen Eingabestatus beruecksichtigen LA Ersetzen durch GlobalMemoryStatus FreeSystemResources GetFreeSystemResources Kein Win32 Aequivalent LA lent SEP Ersetzen durch IPC Mechanismen GetKBCodePage GetKBCodePage Kein Win32 Aequivalent SEP GetMetaFileBits GetMetaFileBits Kein Win32 Aequivalent GDI Ersetzen durch portable GetMetaFileBitsEx GetModuleUsage GetModuleUsage Kein Win32 Aequivalent SEP GetNumTask GetNumTask Kein Win32 Aequivalent LA GetSelectorBase GetSelectorBase Kein Win32 Aequivalent LA GetSelectorLimit GetSelectorLimit Kein Win32 Aequivalent LA GetSysModalWindow GetSysModalWindow Kein Win32 Aequivalent SEP GetTempDrive GetTempDrive Kein Win32 Aequivalent LA Siehe GetTempPath GetTextExtent GetTextExtent Kein Win32 Aequivalent GDI Ersetzen durch portable GetTextExtentPoint GetTextExtentEx GetTextExtentEx Kein Win32 Aequivalent GDI Ersetzen durch portable GetTextExtentExPoint GetThresholdEvent GetThresholdEvent Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep GetThresholdStatus GetThresholdStatu
331. nn eine Eingrenzung der unterschiedlichen Begrifflichkeiten zugunsten des einheitlichen Sprachgebrauchs in dieser Arbeit vorgenommen werden Portabilit t von Software Systemen Seite 16 2 1 1 1 Was ist Portabilit t In den 60er Jahren wurden erste Projekte wie SLANG Sibley 61 oder UNCOL SHARE 68 durchgef hrt die eine bertragung von Software von einem Rechner auf einen anderen zum Thema hatten Eine erste allgemeine Pr zisierung des Portabilit tsbegriffs wurde 1968 von Alan Perlis im Zuge einer NATO Arbeitstagung zum Thema Software Engineering vorgenommen Perlis 68 Portability is the property of a system which permits it to be mapped from one environment to a different environment Danach steht Portabilit t f r die Eigenschaft von Systemen die es erlaubt diese von einer Umgebung in eine andere Umgebung zu bertragen Aus dieser Definition geht allerdings nicht hervor welche Eigenschaften ein zu bertragendes System haben mu Eine weitere Definition wurde von Poole und Waite in den 70er Jahren formuliert Poole 73 Portability is a measure of the ease with which a program can be transferred from one environment to another If the effort required to move the program is much less than that required to implement it initially then we say this is highly portable Hier wird Portabilit t als ein Ma der Einfachheit angesehen mit der ein Programm von einer Umgebung in eine andere bertragen wird Ist de
332. nnen Au erdem geht man davon aus da in einem ersten Schritt nicht alle anzupassenden Anweisungen erkannt werden soda umfangreiche Verifikationstests erforderlich sind die noch dadurch erschwert werden da keine ausreichende Dokumentation zu den Quellen vorhanden ist Die dritte Gruppe welche aus Dokumentation Tools und Erfahrungen besteht ist ebenfalls indirekt da durch sie ebenfalls der nderungsaufwand entweder erh ht oder verringert werden kann Im Unterschied zur Komplexit t sind sie aber au erhalb des zu portierenden Software Systems angesiedelt und werden als externe Faktoren bezeichnet Zur eigentlichen Dokumentation der Quellen eines Software Systems z hlt auch die Portierungsdokumentation Hierbei sollte in erster Linie eine detaillierte Beschreibung der erforderlichen Portierungsschritte und die Bereitstellung von Testdaten zur Verifizierung des Portierungsprozesses im Vordergrund stehen Mit Hilfe von Portierungstools wird der Portierungsproze teilweise automatisiert Dazu geh ren ganz allgemeine Tools wie Texteditoren aber auch Spezielle wie Pr prozessoren oder Filter Einen gewichtigen Faktor f r den Portierungsaufwand stellen die Erfahrungen und Kenntnisse eines Porteurs dar Diese k nnen in allgemeiner Form als Programmiererfahrung in fr heren Portierungsprojekten vorliegen Es kann sich aber auch um spezielle Kenntnisse bez glich der verwendeten Programmiersprache oder des Betriebssystems mit der zugrundelie
333. nsnannne 196 Anhang E Hardwareausstattung der Arbeitspl tze f r das XCTL System ssccsscsssoees 200 Inhaltsverzeichnis Seite 7 Anhang F Daten der Quelltextanalyse soussorsoonssnssonssonssonsssnnssnnssnnssnnsnnnssnnssnnnsnnnsnnnsnnnssonssnnsnnne 201 F 1 Ma komponente Software Umgebung 201 F 1 1 Ermittlung der Ma komponente Betriebssystem Aufrufe eeennensnnen 201 F 1 2 Ermittlung der Ma komponente Bibliotheksroutinen Aufrufe eeeene 201 F 1 3 Ermittlung der MaBkomponente Software Umgebung nen 212 F 2 MaBkomponente Hardware Umgebung esnssnesnsnennennnenneennnnnnnennnn essen 213 F 2 1 Ermittlung der Ma komponente Maschinenarchitektur seseeseeeseseeeesssseeesesseseseesrssesee 213 F 2 2 Ermittlung der Ma komponente Peripherieger te uessensennsenseenneennennneennen nennen 226 F 2 3 Ermittlung der Ma komponente Hardware Umgebung eesenenense 227 F 3 Ma komponente System Umgebung cesnessseneeesneennensnnnennnennennnennnennse nennen 228 F 4 Ma komponente Komplexitat ucessessesensessensennsnnsnnensonnensnennennnsnennennnnnnnnnnsennnnensenn 230 F 4 1 Ermittlung Ma komponente Schnittstellenkomplexit t seseseeeeeeeeeeeeeee eseese seseeeesessesee 233 F 4 2 Ermittlung Ma komponente Interne Komponentenkomplexitat eesene 233
334. nt long M_arscan cpp 1080 MessageBox GetFocus buf szMsgFailure MBSTOP TAreaScan InitializeTask unsigned_int long M_arscan cpp 2396 MessageBox GetFocus szMsgLine014 szMsgFailure MBINFO TAreaScan LoadMeasurementinfo int M_arscan cpp 2457 MessageBox GetFocus szMsgLine014 szMsgFailure MBINFO TAreaScan LoadOldData int M_arscan cpp 1905 MessageBox GetFocus szMsgLine014 szMsgFailure MBINFO TAreaScan SaveFile int M_arscan cpp 1792 MessageBox GetFocus buf szMsgFailure MB_OK MB_ICONSTOP TAreaScan SaveMeasurementinfo int M_arscan cpp 877 MessageBox GetFocus Kein g ltiger Darstellungstyp Meldung MBINFO TAreaScan SetRanges M_arscan cpp 929 MessageBox GetFocus Kein g ltiger Darstellungstyp Meldung MBINFO TAreaScan SetRanges M_arscan cpp 1557 MessageBox GetFocus Kein Psd verf gbar szMessage MBINFO TAreaScan ShowSensorContinuous int KOMP TAreaScan Anz BIBA 13 M_steerg cpp 641 MessageBox GetFocus Start Scan failed Steering MBSTOP TAreaScanCmd TAreaScanCmd TCmdTag KOMP TAreaScanCmd Anz BIBA 1 M_arscan cpp 187 MessageBox GetFocus szMsgLine016 szMessage MBINFO TAreaScanParameters TAreaScanParameters KOMP TAreaScanParameters Anz BIBA 1 M_data cpp 1240 MessageBox GetFocus Cannot create memory object 1 Message MBINFO TBitmapSource FormatDBaseToBitmapSource M_data cpp 1283 MessageBox GetFocus Unknown OutputType Message MBINFO TBitmapSource
335. nters cpp 1207 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp 1210 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld KOMP TStoe_Psd Anz BIBA 2 TSteering NotifyCmdReady TSteering NotifyMacroReady TSteering ParsingCmd TCmdTag_ amp char_ char_ char_ char_ TSteering StartMacroExecution TMacroTag_ HWND__ TStoe_Psd PollDevice TStoe_Psd PollDevice M_topo cpp 265 SendMessage GetHandle WM_COMMAND cm_ParamSet 0 TTopographyExecute Dlg_OnCommand HWND___ int HWND___ unsi M_topo cpp 403 SendMessage GetHandle WVM_COMMAND cm_ParamSet 0 TTopographyExecute DIg_OnCommand HWND___ int HWND___ unsi M_topo cpp 421 FORWARD_WM_COMMAND GetHandle cm_SetupPosition 0 0 PostMessage TTopographyExecute DIg_OnCommand HWND___ int HWND___ unsi M_topo cpp 479 SetFocus GetDlgltem GetHandle cm_SwitchControl TTopographyExecute Dlg_OnCommand HWND___ int HWND___ unsi M_topo cpp 570 FORWARD_WM_COMMAND GetHandle cm_SwitchControl 0 0 PostMessage TTopographyExecute DIg_OnCommand HWND___ int HWND___ unsi M_topo cpp 163 SendMessage GetHandle WM_COMMAND cm_Initialize 0 TTopographyExecute Dig_OnInit HWND___ HWND___ long M_topo cpp 164 SendMessage GetHandle WM_COMMAND cm_ParamSet 0 TTopographyExecute Dig_OnInit HWND___ HWND___ long M_topo cpp 217 FORWARD_WM_COMMAND hwnd cm_SwitchControl 0 0 PostMessage TTopographyExecute Dig_OnTimer HWND___ unsigned_int KOMP TTopographyExecute
336. ntes portables Win32 API nexpand expand NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder expand nfree free NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder free nmalloc malloc NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder malloc nmsize msize NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder msize nrealloc realloc NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder realloc nstrdup strdup NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strdup OemToAnsi OemToAnsi Makro um OemToChar MBE OemToAnsiBuff OemToAnsiBuff Makro um OemToCharBuff MBE OffsetViewportOrg OffsetViewportOrg Kein Win32 Aequivalent GDI Ersetzen durch portable OffsetViewportOrgEx OffsetWindowOrg OffsetWindowOrg Kein Win32 Aequivalent GDI Ersetzen durch portable OffsetWindowOrgEx OpenComm OpenComm COMM Funktionen auf File 1 O gemappt DOS Ersetzen durch CreateFile OpenSound OpenSound Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep PostAppMessage PostAppMessage Makro um PostThreadMessage GDI Ersetzen durch PostThreadMessage PrestoChangoSelector PrestoChangoSelector Kein Win32 Aequivalent LA Anhang B Inhalt der zentralen Problembibliothek Seite 192 Prof
337. nthalten Auch ist die allgemeine Akzeptanz bei den Compilerherstellern von entscheidender Bedeutung f r die Definition eines Standards und dessen Verbreitung Standardbibliotheken Die Idee bei Standardbibliotheken folgt ebenfalls dem Einheitlichkeitsprinzip Hierbei sollen uniforme Schnittstellen zum Betriebssystem und weiteren Funktionalit ten die Portabilit t von System Software welche mit Hilfe solcher Bibliotheken entwickelt wurden sichern Es existieren eine Reihe von standardisierten Bibliotheken C Standard Template Bibliothek NAG f r Numerische Bibliotheken CORBA Implementierungen etc die strenggenommen kein Teil der zugrunde liegenden Programmiersprache sind Sie werden jedoch meist gleichzeitig mit ihr definiert und in jeder Umgebung in der die Sprache eingesetzt wird vorausgesetzt Bibliotheken decken ein breites Spektrum an Funktionalit ten ab z B Ein Ausgabe String Operationen dynamische Speicherverwaltung Diese arbeiten aber h ufig eng mit dem Betriebssystem zusammen soda sie trotzdem nichtportable Teile beinhalten k nnen Standardbibliotheken stellen in diesem Zusammenhang die Interaktion mit dem Betriebssystem auf eine portable Basis und sichern zugleich Portabilit t von Software Systemen Seite 26 die einheitliche Funktionalit t der benutzten Bibliotheksfunktionen H lt man sich bei der Entwicklung eines Software Systems streng an vorhandene Standardbibliotheken so sollte sich bei einem Umgebungswec
338. ntrol TPsd f TPsdRemoteSync gt TRadicon TScan TScanCmd N TScsParameters TSetAdjustmentParam TSetupAreaScan 3 TSetupContinuousScan TSetupScanCmd i TSetupStepScan TShowValueCmd j TSteering TStoe_Psd TTopographyExecute wae wa aS WS Ss Ss Ss WS WS Ss YS WS WS WS WS SS WS WS WS SS TS OU WN WS SS NS aS OU OU OU OU e Se Se a OMAN OWA ANWHAHANWA PANNA HANWNAHAWAWBNWW A WANN N Da noch keine Aufw nde zu einer oder mehreren Komponenten der Software Umgebung vorliegen ist die Analyse f r die Software Umgebung des XCTL Systems damit abgeschlossen Bei vorhandenen Aufw nden wird das umfangreichere Ma SU siehe 3 2 3 4 f r die Berechnungen herangezogen 4 2 1 2 Hardware Umgebung In diesem Ma soll der Aufwand eingehen der entsteht wenn sich im Rahmen einer Portierung die Hardware Umgebung f r das zu portierende Software System ndert Dazu geh ren in erster Linie die Rechner auf denen die Software l uft aber auch die angeschlossenen Peripherieger te Beide M glichkeiten werden im Ma der Hardware Umgebung getrennt erfa t da die M glichkeit besteht da Host und Zielrechner bei einer Portierung bereinstimmen sich die Peripherieger te jedoch ndern Weiterhin kann es auch sein da sich auf dem Zielrechner die Aufrufe f r Zugriffe auf Peripherieger te ndern und somit anzupassen sind Portabilit tsanalyse am Beispiel des XCTL Systems Seite 148 HU Hardware Umgebung MA
339. ntwicklung und den Portierungsaufwand in Beziehung setzen und damit eine Entscheidungshilfe in die eine oder andere Richtung zur Verf gung stellen wurden Ans tze vorgestellt die Einflu gr en der Portabilit t von Software Systemen konkret vermessen und Metriken und Portierungsaufwand Seite 106 zu einem Gesamtma f r den Aufwand einer Portierung aggregieren Das umfassendste Ma von Buschhorn und Kuchnowski wird im folgenden n her betrachtet und bewertet 3 2 3 Ausgew hlte Metriken f r die Portabilit tsanalyse In diesem Abschnitt geht es um die Beschreibung und Bewertung eines Portabilit tsma es welches von Michael Buschhorn und Hans Joachim Kuchnowski in Buschhorn 88 vorgeschlagen wird Dieses Ma soll als Grundlage f r die Portabilit tsanalyse Windows basierter Software Systeme dienen Es werden Aussagen zur Ma philosophie den Ma objekten den Ma faktoren und dem Aufbau des Portierungsma es gemacht Eine abschlie ende Bewertung fa t die Einhaltung von Ma anforderungen zusammen 3 2 3 1 Ma philosophie Das zentrale Konzept hinter dem Portierungsma ist seine evolution re Entwicklung Das Ma soll Aussagen ber die H he des Portierungsaufwandes machen der bei der Portierung eines Software Systems von einer Umgebung in eine andere Umgebung entstehen wird Hierzu werden das Software System selbst und Unterlagen zu Unterschieden zwischen der Host und Zielumgebung analysiert Es entstehen damit erste gro
340. nz MAA 19 Anhang F Daten der Quelltextanalyse Seite 218 Comclass h 65 virtual void rButtonDown LONG Comclass h 147 WORD RegisterWnd void M_main cpp 180 wndClass coWndExtra 0 M_main cpp 1146 LRESULT CALLBACK _export WndProc HWND hWindow UINT message M_main cpp 1747 WORD TMDIWindow RegisterWnd void M_main cpp 1761 wndClass gt cbClsExtra 0 KOMP TMDIWindow Anz MAA 6 Dig_tpl cpp 61 dialogFunc MakeProcInstance FARPROC DialogProc hInstance KOMP TModalDlg Anz MAA 1 Dig_tpl cpp KOMP TModelessDlg Anz MAA 1 M_motcom h 54 DWORD GetLimit M_motcom h 60 virtual BOOL SetLimit DWORD return TRUE return OxFF TMDIWindow rButtonDown long TMDIWindow RegisterWna TMDIWindow GetWindowClass tagWNDCLASSA_ TMDIWindow GetWindowClass tagWNDCLASSA_ TMDIWindow RegisterWnd TMDIWindow GetWindowClass tagWNDCLASSA_ TModalDlg TModalDig char_ void return dwRemoveLimit M_motcom h 104 virtual WORD GetStatus void Motors cpp 1467 dwHysteresis DWORD GetPrivateProfilelnt Ident Hysteresis 0 GetCFile Motors cpp 1567 wPositionMinWidth WORD atoi buf Motors cpp 1572 wPositionMaxWidth WORD atoi buf Motors cpp 1589 wPositionWidth WORD atoi buf Motors cpp 1623 dwRemoveLimit DWORD atol buf Motors cpp 1682 dwinterval DWORD 3 0 MaxFailure dKoeff_1 KOMP TMotor Anz MAA 9 Motors cpp 1139 WORD valueW Motors cpp 114
341. och st rker zu ber cksichtigen soll dar ber hinaus die Anzahl der in einer Klasse implementierten Methoden NOM ohne eingeerbte Methoden in das Ma eingehen Spezialfall der WMC Metrik Dazu werden die Methoden nicht gewichtet Die Differenz aus den beiden zuvor gemessenen Werten ergibt die Zahl der eingeerbten bzw bernommenen Methoden Aufbau Teilma Schnittstellenkomplexitat f r objektorientierte Software Systeme SK Schnittstellenkomplexitat KP DK Kopplungsmechanismus Kommunikationsart Eigene und eingeerbte eingeerbte Methoden Zugriffe ber Zugriffe auf globale oder Tiefe Methoden VK Botschaftswege geschiitzte Daten Vererbungshierarchie RFC CBO PA DIT Formal SK KP DK Kopplungsmechanismus k KP KP i l mit k Anzahl der Komponenten KP Kopplung der i ten Komponente ber den Aufruf Kopplungsmechanismus Eigene und Eingeerbte Methoden Metriken und Portierungsaufwand Seite 128 KP m RFC m VK mit KP Kopplung der i ten Komponente i 1 k m m Gewichtungsfaktoren der Ma anteile RFC Anzahl der aufrufbaren Methoden der i ten Komponente sowie die Anzahl der internen und externen Aufrufe die sie selbst durchf hrt VK Anzahl der eingeerbten bzw bernommenen Methoden der i ten Komponente wobei VK RFC NOM mit NOM Anzahl der in der i ten Komponente implementierten und nicht eingeerbten Methoden Dar ber hinaus soll f r objektorientierte Systeme die CBO Metrik zugrunde
342. ocus Psd ist nicht kalibriert D Meldung KOMP TPsd Anz BIBA 1 M_dlg cpp 70 FORWARD_WM_COMMAND hwnd IDCANCEL hwndCtl 0 PostMessage M_dlg cpp 79 SetFocus GetDlgltem hwnd id_AddedChannels M_dlg cpp 118 MessageBox GetFocus Zur Zeit nicht unterst tzt Message MBINFO M_dlg cpp 128 FORWARD_WM_COMMAND hwnd cm_ParamSet 0 0 PostMessage KOMP TPsdRemoteSync Anz BIBA 4 Counters cpp 1835 PostMessage hEventControlWnd WM_COMMAND cm_SteeringReady 0l Counters cpp 1893 MessageBox GetFocus buf Gerate Fehler MBINFO Counters cpp 1915 MessageBox GetFocus Kein scs Fehler MBSTOP TModelessDlg Dlg_OnSetFocus HWND___ HWND___ TMotor Translate long_ amp double TMotorParam TMotorParam TPlotData IButtonDown unsigned_int long TPlotData SaveSecondCurve TPosControl TPosControl TPosControl TPosControl TPosControl Ig_OnCommand HWND___ int HWND___ unsigned_in Ig _OnCommand HWND__ int HWND___ unsigned_in lg_OnCommand HWND___ int HWND___ unsigned_in g_OnCommand HWND___ int HWND___ unsigned_in lg_OnCommand HWND___ int HWND___ unsigned_in g_Oninit HWYND___ HWND___ long lg_OnTimer HWND___ unsigned_int TPsd Initialize TPsdRemoteSync Dig_Onlnit HWND___ HWND___ long TPsdRemoteSync Dig_Onlnit HWND___ HWND___ long TPsdRemoteSync Dig_Onlnit HWND___ HWND___ long TPsdRemoteSync Dig_Onlnit HWND___ HWND___ long TRadicon EventHandler un
343. ok Veraltete Hook API erzeugt nur Thread lokale Hooks SEP Neue UnhookWindowsHookEx verwenden UnlockData UnlockData Unter Win32 nicht mehr erforderlich LA Einfach loeschen UnlockResource UnlockResource Leeres Makro LA Nicht erforderlich loeschen UnlockSegment UnlockSegment Unter Win32 nicht mehr erforderlich LA Einfach loeschen UnrealizeObject UnrealizeObject Unter Win32 nicht mehr erforderlich LA Einfach loeschen ValidateCodeSegments ValidateCodeSegments Kein Win32 Aequivalent LA ValidateFreeSpaces ValidateFreeSpaces Kein Win32 Aequivalent LA WaitSoundState WaitSoundState Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep WEP DIIEntryPoint DLL Terminierung geaendert SEP Anpassen an Win32 WindowProc WindowProc Window Prozeduren sollten portabel definiert werden SEP LRESULT CALLBACK WndProc HWND hWnd UINT uMsg WPARAM wParam LPARAM IParam WndProc WindowProc Window Prozeduren sollten portabel definiert werden SEP LRESULT CALLBACK WndProc HWND hWnd UINT uMsg WPARAM wParam LPARAM IParam WriteComm WriteComm COMM Funktionen auf File 1 O gemappt DOS Ersetzen durch WriteFile Yield Yield Kein Win32 Aequivalent SEP Ersetzen durch PeekMessage oder Sleep MESSAGES EM_GETSEL EM_GETSEL Information in wParam IParam anders verpackt MBE message cracker oder alternative Makroschale benutzen EM_LINESCROLL EM_LINESCROLL Information in wP
344. omit Probleme Hierbei unterscheidet man zwischen undokumentierten Eigenschaften in Win16 Systemen welche unter Win32 offiziell vorhanden und entsprechend dokumentiert sind z B Nachrichten wie WM GET SET JHOTKEY oder Funktionen wie keypd_event bzw Funktionen aus Bibliotheken wie Toolhelp dll oder Stress dll sowie diverse Konstanten etc oder man vertraut auf die inoffizielle bernahme der benutzten Eigenschaften Hierbei ist in erster Linie die Verwendung undokumentierter bzw interner Win16 Datenstrukturen zu nennen welche durch die Erweiterung aller grundlegenden Datentypen auf 32 Bit und die Trennung der Adre bereiche mit gro er Wahrscheinlichkeit kein Win32 quivalent aufweisen Es k nnen somit keine grundlegenden Aussagen dar ber getroffen werden welche Eigenschaften im einzelnen portierbar sind und wo Portierungsprobleme zu erwarten sind Programmierung von DI e Die Probleme in diesem Bereich ergeben sich aus der strikten Trennung der Adre r ume von Prozessen und der Verwendung von preemptivem Multitasking unter Win32 Jeder Proze mu ben tigte DIl s in seinen privaten Adre raum einblenden DII attaching um deren Daten nutzen zu k nnen Diese Daten globale und statische Variablen befinden sich im Datenbereich der entsprechenden Dll und werden f r jeden Proze separat in dessen Adre raum neu angelegt privat global Die Codebereiche einer Dll werden dagegen nur einmal in den physikalischen Spei
345. omputers ab und verbirgt auf diese Weise die physische Organisation Dadurch ist sichergestellt da ein Thread auf den Speicher seines eigenen Prozesses zugreifen kann nicht aber auf den Speicher eines anderen Prozesses Aus diesem Grund ist die Organisation des virtuellen Speichers aus der Sicht eines Threads wesentlich einfacher als die tats chliche Organisation der Seiten im physischen Speicher Virtueller Speicher Proze 1 Virtueller Speicher Proze 2 System Memory Nonpaged memory pool P d Vom System ieee Fur die Applikation nicht sichtbar adressierbarer ate 2 GByte Zugriff nur durch Code im Speicher Kernel Mode bei Windows NT insgesamt 4GByte virtueller Frei linearer Adressraum Di Code Daten Frei oe GE Von der Anwendung Sichtbar f r Applikationen adressierbarer 2 GByte und Kernel Speicher Anwendungs Code Daten Stack und Standard Heap Frei Freie Seite 1 System Seite 2 Proze 1 Seite 3 Proze 2 Seite 1 Umblenden von virtuell auf RAM Proze 1 Seite 2 System Seite 3 Proze 2 Seite 4 Proze 2 Seite 3 Freie Seite 2 System Seite 1 Proze 1 Seite 1 Proze 2 Seite 2 Physikalischer Speicher RAM Abbildung 9 Adre raum einer Win32 Anwendung und Verwaltung von Speicherseiten Um 16 Bit Betriebssysteme wie Windows 3 1 zu unterst tzen benutzen Intel Prozessoren einen sogenannten Segment M
346. on Software Systemen Seite 69 der Dil angegeben Im zweiten Parameter werden mittels bergebener Konstanten Initialisierungs oder Terminierungsroutinen innerhalb der Funktion ausgel st Je nachdem welcher Grund zum Aufruf der Funktion f hrt Hierbei k nnen nicht nur einzelne Anwendungsprozesse bei der DI an und abgemeldet werden sondern auch einzelne Threads Die Portierung von Software Systemen welche mit einer Vielzahl von DII s arbeiten erfordern somit auch in diesem Bereich gewisse Anpassungen und ist mit Problemen behaftet Bei der Verwendung anwendungsglobaler Windows Klassen welche innerhalb einer DII registriert sind und z B mittels der Funktion CreateWindow genutzt werden ergeben sich ebenfalls Portierungsprobleme aufgrund des notwendigen expliziten Ladens der Dll Entweder explizit ber die Funktion LoadLibrary oder implizit ber einen externen Lader beim Systemstart Das zweite Verfahren ber einen externen Lader funktioniert unter Win32 nicht mehr in der gew nschten Form Jeder Proze mu alle ben tigten DIl s selbst laden da hier au er den System Bibliotheken keine global bekannten DIl s mehr existieren Anwendungslokal registrierte Windows Klassen ohne CS_GLOBALCLASS Flag verursachen ebenfalls Portierungsprobleme aufgrund der unterschiedlichen Verwendung der Instance Handles 2 2 4 Strategien und Werkzeuge zur Portierung von Win16 nach Win32 Jede Portierung findet innerhalb eines festgelegten
347. on Systemabh ngigkeiten in separaten Dateien Schnitt Verstecken von Systemabh ngigkeiten hinter Schnittstellen Kapselung Namens nderungen bei Spezifikationsanpassungen Bewahren der Kompatibilit t zu vorhandenen Software Systemen und Daten ASCIH Kodierung und Landessprache nicht voraussetzen 2 2 3 2 Architekturen des betrachteten Portierungsfelds Portiert man Software Systeme von einer Hostumgebung in eine bestimmte Zielumgebung so mu festgestellt werden welche System Software Betriebssystem Programmiersprachenwerkzeuge etc aus der Software Umgebung und welche Hardware aus der Hardware Umgebung dem Portierungsproze zugrunde liegen Plattform Aus diesen Kenntnissen definiert sich dann im weiteren das spezifische Portierungsfeld des Portierungsprozesses Auf die System Software im Portabilit t von Software Systemen Seite 49 programmiersprachlichen Bereich und die zugrunde liegenden Rechnersysteme wurde bereits eingegangen Es soll nun der Teil der System Software aus der Software Umgebung betrachtet werden der als Schnittstelle zwischen Rechnersystem und Software System agiert Dies sind die jeweils dem Portierungsproze zugrunde liegenden Windows Betriebssysteme und dessen Architekturen Auf der 16 Bit Seite des Portierungsfelds Hostumgebung findet sich Windows 3 1 inklusive naher verwandter wie z B Windows for Workgroups Die 32 Bit Seite des betrachteten Portierungsfelds Zielumgebung stellen die Bet
348. onen im Sinne des Konzepts mehrerer lokaler Heaps Auch ist das sogenannte Locking von allokierten globalen und verschiebbaren Speicherbereichen ber korrespondierende Lock Aufrufe unter Win32 notwendig Ausnahme Fixed Memory hier werden keine Speicher Handles sondern direkt Zeiger zur ckgeliefert um an g ltige Adressen in Form von Speicher Handles zu kommen Hin und Hersenden von globalen Speicherbereichen durch z B globale Speicher Handles notwendig unter Windows 3 x f r lokale und als moveable gekennzeichnete Speicherallokationen und zwingend f r global genutzte Speicherbereiche oder noch drastischer von FAR Zeigern zwischen Anwendungen um Datenaustausch zu realisieren ist unter Win32 nicht mehr m glich Damit stellen alle shared Memory Ans tze die auf dem Austausch globaler Handles durch private Nachrichten beruhen potentielle Portierungsprobleme dar Bedient man sich beim Datenaustausch des standardisierten DDE Protokolls bzw der DDE Managment Library DDEML als API rund um das DDE Protokoll bersetzt das Win32 Subsystem die Handles der Nachrichten f r den Informationsaustausch von einem virtuellen Adre raum in den anderen Die DDEML selbst ist bis auf kleinere Unterschiede zwischen den betrachteten Windows Systemen v llig portabel Jedoch hat sich das Format der in den beiden DDE Nachrichten transportierten Informationen f r Win32 ge ndert So erzeugen Anwendungen die statt de
349. onenten zur Zeitscheiben und Speicherverwaltung inklusive des Kernel und des VMM Die Module laufen obwohl sie zum System geh ren nicht im Kernel Mode des Prozessors denn ein st ndiger Privilegwechsel w rde erhebliche Leistungseinbu en bei Systemaufrufen mit sich bringen Windows 9x besitzt eine 32 Bit Benutzerschnittstelle die auf dem Windows Explorer basiert und eine Reihe von Werkzeugen wie die Netzwerkumgebung als Zusatz zur Benutzeroberfl che zur Verf gung stellt Alle Anwendungen und Werkzeuge arbeiten auf demselben Systemniveau wie Win32 Winl6 und MS DOS Anwendungen k nnen die Standard Kontrollelemente der Shell benutzen z B Standarddialogfelder Symbolleisten oder Baumanzeigen Windows NT Windows NT bietet aufgrund seiner auf Portabilit t und Systemsicherheit ausgerichteten Architektur eine im Vergleich zu Windows 9x grundlegend andere Struktur Zwei wesentliche Elemente beherrschen hierbei das Architekturfeld die Subsysteme die die verschiedenen Betriebssystememulationen bereitstellen und das eigentliche Basisbetriebssystem Das NT Basissystem l uft im Kernel Modus des Prozessors und in einem von den Subsystemen und Anwendungen isolierten Adre raum Es besteht aus drei wesentlichen Funktionsgruppen Einem teilweise hardwareabh ngigen Kern der sich um das Scheduling und die Interrupt Vorverarbeitung k mmert der Hardware Abstraktionsschicht HAL die viele Systemdesign bezogene Eigenschaften wie etwa DM
350. op Down Sicht Unter diesem Blickwinkel ist es die Aufgabe des Betriebssystems dem Benutzer ein quivalent einer erweiterten Maschine bzw einer virtuellen Maschine zu pr sentieren die ber geeignete Schnittstellen leichter zu programmieren ist als die darunterliegende Hardware Zum anderen hat das Betriebssystem die Aufgabe der Verwaltung aller Bestandteile eines komplexen Computersystems Bottom Up Sicht Dazu geh ren Proze verwaltung Verwaltung der Ein Ausgabe Ger te Speicherverwaltung und Dateiverwaltung Anhand dieser beiden Sichtweisen lassen sich die Portierungsprobleme in Bezug auf die Systemsoftware in zwei Klassen aufteilen Probleme aus Programmierer bzw Benutzersicht und Probleme aus betriebssysteminterner Sicht Betriebssystem aus Sicht des Programmierers Top Down Aus Sicht des Programmierers nutzt man die Schnittstellen eines Betriebssystems gr tenteils ber bereitgestellte Schnittstellen Bibliotheken Die Nutzung erfolgt durch Einbindung in eine bestimmte von der Bibliothek unterst tzte h here Programmiersprache z B C C FORTRAN Ada Ein Compiler erzeugt aus den System Bibliotheken und dem Programm eine ausf hrbare Bin rdatei f r ein bestimmtes Computersystem In besonderen F llen nutzt man zus tzlich die Hilfe von Assemblersprachen Damit ist es m glich spezielle Zugriffe auf die Hardware zu realisieren die die Abstraktionsebene der Betriebssystem Schnittstelle umgehen um spezielle Anforderungen an di
351. orgehensweise ist z B bei integrierten Systemen notwendig da diese nur eingeschr nkte oder berhaupt keine Mechanismen f r eine Programmerstellung bereitstellen Portabilit t von Software Systemen Seite 34 Original Environment Target Environment adapt Source Source Program Program Target transport Executeable Executeable Executeable Program Program Program Abbildung 3 Alternatives Proze modell f r die Portierung Anpassung in Hostumgebung Ein weiteres Modell f r den Portierungsproze findet sich in Buschhorn 88 Hierbei werden bestimmte Faktoren bestimmt die den Portierungsaufwand beeinflussen Dazu geh ren Programmiersprachen Betriebssysteme Hardware Komplexit t Dokumentation Portierungstools sowie Erfahrungen und Kenntnisse des Porteurs Alle Faktoren werden dann in drei Gruppen eingeteilt Die erste Gruppe besteht aus den verwendeten Programmiersprachen den zugrundeliegenden Betriebssystemen und der Hardware des Computersystems Alle drei Faktoren haben direkten Einflu auf den Aufwand einer Portierung da die Anzahl an Codestatements die ge ndert werden m ssen von den Unterschieden zwischen Host und Zielrechner abh ngt Die zweite Gruppe bilden die indirekt auf den Portierungsaufwand einflu nehmenden Faktoren Dazu geh rt die Komplexit t eines Software Systems So sind z B Folge nderungen die Portierungs nderungen an wiederum anderen Programmanweisungen nach sich ziehen k nnen schwierig zu erke
352. ort oder PlaySound Beep SetVoiceQueueSize SetVoiceQueueSize Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetVoiceSound SetVoiceSound Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetVoiceThreshold SetVoiceThreshold Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SetWindowExt SetWindowExt Kein Win32 Aequivalent GDI Ersetzen durch portable SetWindowExtEx SetWindowOrg SetWindowOrg Kein Win32 Aequivalent GDI Ersetzen durch portable SetWindowOrgEx SetWindowsHook SetWindowsHook Veraltete Hook API erzeugt nur Thread lokale Hooks GDI Neue SetWindowsHookEx verwenden SetWindowWord SetWindowWord Verbreiterte Datentypen beruecksichtigen GDI SetWindowLong fuer Werte die auf 32 Bit gewachsen sind StartSound StartSound Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep StopSound StopSound Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep SwitchStackBack SwitchStackBack Kein Win32 Aequivalent LA SwitchStackTo SwitchStackTo Kein Win32 Aequivalent LA SyncAllVoices SyncAllVoices Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep Throw Throw Kein Win32 Aequivalen SEP Ersetzen durch Structured Exception Handling SEH UngetCommChar UngetCommChar Kein Win32 Aequivalent DOS UnhookWindowsHook UnhookWindowsHo
353. othw h 149 WORD wGPIBAdar m_mothw h 198 WORD wBaseAddr m_mothw h 201 WORD wSample m_mothw h 100 103WORD wTorque m_mothw h 170 173WORD wKI IntegralGain m_mothw h 272 74 DWORD old_vel old_accel m_mothw h 288 290 DWORD old_vel old_accel m_mothw h 47 50 WORD wDeathBand M_psd h 9 define _COUNTERCLASS _export M_psd h 77 DWORD dwMaxCounts dwintegratedCounts WinMain HINSTANCE__ HINSTANCE___ char_ int WinMain HINSTANCE__ HINSTANCE___ char_ int WinMain HINSTANCE___ HINSTANCE___ char_ int DoCommandsFrame HWND___ unsigned_int long DoCommandsFrame HWND___ unsigned_int long unsigned_int long DoCommandsChild TMDIWindow_ HWND___ unsigned_int long DoCommandsChild TMDIWindow_ HWND___ unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long NewWindow TMDIWindow_ WinMain HINSTANCE___ HINSTANCE___ char_ int FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long FrameWndProc HWND___ unsigned_int unsigned_int long DoCommandsFrame HWND___ unsigned_int long Anhang F Daten der Quelltextanalyse Seite 224 M_psd h M_psd h M_psd h M_psd h M_psd h 159 160 187 19
354. otwendig diese auf verschiedene Computersysteme zu portieren Hierbei entstehen ebenfalls Kosten die mit dem Aufwand f r eine Neuimplementierung verglichen werden m ssen Ist der Portierungsaufwand f r ein bestehendes Software System bekannt so wird aus Herstellersicht eine Entscheidung bez glich der Alternativen Portierung oder Neuimplementierung objektiv erleichtert Zur Kl rung des Portierungsaufwands soll im Rahmen eines Reengineering Projekts ein Software System zur Steuerung einer R ntgen Topographie Kamera mit Hilfe von Metriken n her untersucht werden Ziel der Arbeit ist die Ermittlung des Aufwands der Portierung eines 16 Bit Windows basierten Software Systems auf die 32 Bit Plattform des Betriebssystems Windows 98 Das zweite Kapitel der Arbeit soll zun chst einen berblick ber das Gebiet der Software Portabilit t geben Hierbei sollen allgemeine Aspekte zur Portabilit t von Software Systemen erl utert und die f r die Fragestellung relevanten Begriffe gekl rt werden Es werden im Anschlu daran allgemeine Strategien Konzepte und Werkzeuge zur Unterst tzung der Portierung vorgestellt Den Abschlu dieses Teils bildet die Vorstellung allgemeiner Portierungsmodelle welche als Grundlage f r die Ermittlung des Portierungsaufwands von Windows basierten Software Systemen dienen k nnen und die wesentlichen Einflu faktoren einer Portierung im betrachteten Portierungsfeld ber cksichtigen Der zweite Teil dieses Kapitels w
355. p Verbreiterung GDI Ersetzen durch GCL_HICON GCW_HMODULE GetClassLong Datentyp Verbreiterung LA Ersetzen durch GCL_HMODULE GCW_STYLE GetClassLong Datentyp Verbreiterung GDI Ersetzen durch GCL_STYLE GMEM_DDESHARE GMEM_DDESHARE Unter Win32 wirkungslos SEP shared memory ersetzen durch IPC Mechanismen GMEM_SHARE GMEM_SHARE Unter Win32 wirkungslos SEP shared memory ersetzen durch IPC Mechanismen GWW_HINSTANCE GetWindowLong Datentyp Verbreiterung LA Ersetzen durch GWL_HINSTANCE GWW_HWNDPARENT GetWindowLong Datentyp Verbreiterung LA Ersetzen durch GWL_HWNDPARENT GWW_ID GetWindowLong Datentyp Verbreiterung LA Ersetzen durch GWL_ID GWW_USERDATA GetWindowLong Datentyp Verbreiterung MBE Ersetzen durch GWL_USERDATA MACROS HIWORD HIWORD HIWORD Ziel 16 oder 32 Bit Bei Nachrichtenparametern geaenderte Informationspackung MBE Evtl message cracker verwenden LOWORD LOWORD LOWORD Ziel 16 oder 32 Bit Bei Nachrichtenparametern geaenderte Informationspackung MBE Evtl message cracker verwenden MAKELONG MAKELONG Wenn Ziel IParam geaenderte Informationspackung MBE Evtl message cracker verwenden MAKELP MAKELP Keine FAR Pointer unter Win32 LA Ersetzen durch flat memory model Code MAKELPARAM MAKELPARAM Geaenderte Informationspackung MBE Evtl message cracker verwenden MAKEPOINT MAKEPOINT sizeof POINT sizeof DWORD LA Entweder ersetzen durch MAKEPOINTS und POINTSTOPOINT oder eigene Konversionsfunktion OFFSETOF OFFSETOF
356. plungsmechanismus Kommunikationsart Eigene und eingeerbte eingeerbte Methoden Zugriffe ber Zugriffe auf globale oder Tiefe Methoden VK Botschaftswege gesch tzte Daten Vererbungshierarchie RFC CBO PA DIT Schritte zur Ermittlung des Teilma es Schnittstellenkomplexitat Ermittlung der Ma komponente Kopplungsmechanismus Ermittlung der Ma komponente Kommunikationsart bzw Datenkopplung Zusammenfassung zur Ma komponente Schnittstellenkomplexitat Bei der Betrachtung der traditionellen Metriken f r prozedural strukturierte Software Systeme stellten u a die Metriken von Myers und Stevens einen Ansatz dar um ber Kopplungsst rken die Schnittstellenkomplexit t von Software Komponenten zu bestimmen Hierbei waren mit Ausnahme der Hybrid Kopplung die nur f r Assembler Programme von Bedeutung ist alle Kopplungen in h heren Programmiersprachen realisierbar Hierbei wurde auch festgestellt da nicht jede Programmiersprache auch alle Formen der Kopplung zul t Ein wichtiger Punkt dabei ist die automatische Ermittlung der Kopplungsarten wobei dies im Fall der reinen Datenkopplung und der Portabilit tsanalyse am Beispiel des XCTL Systems Seite 158 Kopplung ber Kontrollparameter nicht immer m glich ist und dar ber hinaus auch keine automatische Unterscheidung zwischen Zustands und Kontrolldaten zu treffen ist Aus diesem Grund wurden Kontrollparameter in der Variante f r Software Systeme mit proz
357. ponente verzweigen berpr ft wurden Dieser Kopplungsmechanismus ist deshalb problematisch da Komponenten die auf diese Art verzweigen nicht so einfach aufzufinden sind Im Falle eines Fehlers kann daher jede an der Verzweigung beteiligte Komponente ein potentieller Verursacher des Fehlers sein Die Code Kopplung ist gegeben falls verschiedene Komponenten gleiche Code Segmente verwenden wie dies z B mittels Paragraphen in Cobol mehrere Einsprungspunkte der Fall sein kann Liegt beispielsweise ein Paragraph B zwischen den Paragraphen A und C und verwendet man dann eine Anweisung der Art PERFORM A TROUGH C so kann eine nderung am Paragraphen B zu einer fehlerhaften Ausf hrung dieser PERFORM Anweisung f hren Kontrollparameter haben Einflu auf die Verarbeitungsreihenfolge der aufgerufenen Komponente und setzen Kenntnisse ber deren Inhalt voraus Wird z B ber eine Systemkomponente die Steuerung mehrerer Drucker realisiert so kann die Auswahl des Druckers von anderen Komponenten mit Hilfe einer Kontrollvariablen bernommen werden und man erh lt hier eine Form der Kopplung die zumeist nicht notwendig ist So w re es denkbar da man die Druckersteuerung in mehrere Komponenten aufteilt Jeder Drucker erh lt seine eigene ihm zugeh rige Systemkomponente wobei die Auswahl des Druckers in die aufrufende Komponente verlegt wird Kontrollkopplungen ber Kontrollparameter sollten wie auch die anderen F lle m glichst vermiede
358. r Aufwand f r die bertragung geringer als eine Neuimplementierung so bezeichnet man ein Programm als portabel Hier wird der Aspekt des Aufwands hervorgehoben der in den meisten Definitionen entweder in Bezug auf die urspr ngliche Implementation oder einer Neuimplementation f r die Zielumgebung ber cksichtigt wird Allen Definitionen ist gemeinsam da der Aufwandsbegriff nicht n her pr zisiert wird Anfang der 80er Jahre definiert Hommel die Portabilit t von Programmen und benutzt dabei den Begriff der Adaptierung den er jedoch nicht konkretisiert Hommel 80 Portabilit t ist eine Eigenschaft von Software Programme und Daten die es erlaubt diese mit relativ geringem Aufwand von einem Grundsystem auf ein anderes zu bertragen Bei dieser bertragung d rfen andere Software Eigenschaften nicht Korrektheit oder nur unwesentlich Effizienz beeintr chtigt werden Es kann erforderlich sein zus tzlichen Aufwand f r die Adaptierung zu betreiben Adaptierung kann hier als zus tzlicher Aufwand verstanden werden der zus tzlich zum nderungsaufwand betrieben werden mu falls die genannten Software Eigenschaften beeintr chtigt werden In einem Portabilit tsma P wird von Hommel der Aufwandsbegriff n her pr zisiert indem er eine Beziehung zum Implementationsaufwand herstellt p AI AI AP AA wobei A der Aufwand f r die erste Implementierung eines Software Produktes ist AP der Aufwand f r die Portierung
359. r DDEML das Nachrichtenprotokoll selbst benutzen ebenfalls Probleme bei der Portierung Portabilit t von Software Systemen Seite 63 Benutzereingabe Maus und Tastatur Eingabenachrichten werden unter Windows 3 x ber Hardware Interrupts und im Zuge des Interrupts ber generierte Input Event s z B WM_KEYDOWN behandelt Diese werden in einer systemweiten Nachrichtenschlange hinterlegt und von den jeweiligen Anwendungen zu denen die Eingabenachricht geh rt ausgelesen und in die private Nachrichtenschlange kopiert Unter Win32 wird das Konzept des lokalen Eingabemodus benutzt In diesem Eingabemodell werden die Eingabenachrichten im Moment ihrer Erzeugung bereits in die private Nachrichtenschlange des Anwendungsprozesses kopiert Das neue Eingabemodell hat den wichtigen Vorteil da Anwendungen die nicht regelm ig ihre Nachrichtenschleife bedienen nicht mehr zur scheinbaren Blockade des gesamten Systems f hren Sanduhr Effekt unter Win16 Tastatur System Queue a Maus Eingaben Queue Anwendung 3 Queue Anwendung 2 Queue Anwendung 1 Windows Anwendung 1 Windows Anwendung 3 Windows Anwendung 2 Weg der Eingabenachricht unter Win16 Weg der Eingabenachricht unter Win32 Abbildung 13 Eingabenachrichten unter Win16 und Win32 Portierungsprobleme die sich aufgrund des ver nderten Eingabemodells lokales Eingabemodell ergeben finden
360. r umst ndlich in der externen Systemdokumentation nachschlagen zu m ssen um den Zweck einer Systemkomponente zu bestimmen Dar ber hinaus ist der Autor der Softwarekomponenten und deren Erstellungsdatum bzw Versionsnummer eine wichtige Information um evtl R cksprachen mit dem Entwickler halten zu k nnen und um Informationen ber den aktuellen Stand der jeweiligen Komponenten zu erhalten Zu einer guten Komponenteninformation geh rt auch die Angabe von importierten und exportierten Datenstrukturen sowie die Auflistung der aufgerufenen Systemkomponenten bzw der Verbindungen zu anderen Systemkomponenten Portabilit tsanalyse am Beispiel des XCTL Systems Seite 170 Die Einzelma e die diese Informationen aufnehmen haben folgenden Aufbau und werden schrittweise manuell ermittelt KB Beschreibung der Systemkomponenten Klassen vorhanden nicht vorhanden SB Beschreibung der Klassenkomponenten Methoden Attribute vorhanden nicht vorhanden AE Autor und Erstellungsdatum vorhanden nicht vorhanden IE Auflistung Import Export der Methoden vorhanden nicht vorhanden AS Auflistung der abh ngigen Systemkomponenten vorhanden nicht vorhanden Da die Handhabung von Komponentenk pfen nicht standardisiert ist und somit eine automatische Ermittlung des Ma es nicht m glich ist werden Stichproben durch den Porteur ermittelt und subjektiv bewertet Hierbei wird die Ma zahl durch die absolute Mehrheit festgelegt d h wenn mehr als der
361. rakterisiert Eine bertragung die keine Kosten verursacht soll nicht als Portierung verstanden werden Portabilit t von Software Systemen Seite 20 Eine Adaptierung kennzeichnet die spezifikationserhaltende nderung des Software Systems im Proze der Portierung bzgl Funktion Korrektheit oder Effizienz Eine Modifikation ndert die Spezifikation aufgrund von Benutzeranforderungen bei gleichbleibender Umgebung Unter Transport soll die physikalische bertragung des Software Systems von einer Umgebung in eine andere Umgebung verstanden werden Die Umgebung aus der das Software System portiert werden soll wird als Hostumgebung bezeichnet Ein Software System wird immer in eine Zielumgebung portiert Wird ein konkretes Software System von einer bestimmten Hostumgebung in eine konkrete Zielumgebung portiert so soll der spezifische Rahmen in dem die Portierung stattfindet als Portierungsfeld bezeichnet werden 2 1 2 Allgemeine Probleme bei der Portierung In diesem Abschnitt soll ein berblick dar ber gegeben werden welche Probleme im Rahmen einer Portierung auftreten k nnen Portierungsprobleme entstehen meist dadurch da sich Host und Zielumgebung durch die Hardware des Computersystems und der darauf aufsetzenden Systemsoftware Betriebssystem Compiler und Programmiersprachen unterscheiden 2 1 2 1 Hardware eines Computersystems Bei der Portierung spielt die Rechnerarchitektur eine wesentliche Rolle Rechnerarchitekturen
362. rameter 1 1 1 1 0 1 1 1 0 1 0 0 0 100 FALSE 0 5 0 65 TAdjustmentWindow 14 1 27 2 1 0 3 61 13 48 7 87 1 0 0 FALSE 54 5 3 35 TAm9513a 58 2 42 19 8 1 1 24 24 0 0 90 0 0 11 FALSE 12 0 3 TAngleControl 76 8 44 45 6 0 2 13 9 4 4 63 1 0 0 FALSE 8 5 2 TAquisition 11 2 2 7 7 0 2 11 5 6 0 100 1 0 0 FALSE 8 5 0 6 TAreaScan 307 8 52 45 30 0 3 72 38 34 14 90 2 0 11 FALSE 53 5 8 TAreaScanCmd 10 2 3 1 0 2 15 5 10 4 64 1 0 0 FALSE 12 5 2 TAreaScanParameters 11 5 5 10 1 1 1 2 2 0 2 51 0 0 100 FALSE 1 1 TBitmapSource 157 7 14 30 13 0 1 23 23 0 3 83 0 0 31 FALSE 11 5 1 35 TBraun_Psd 105 5 83 19 15 0 3 64 18 46 12 86 1 0 11 FALSE 55 5 1 TBurleigh 1 1 1 1 0 3 49 1 48 1 100 1 0 0 FALSE 48 5 1 25 TCalculateCmd 9 4 5 7 1 0 2 15 2 13 1 0 1 0 0 FALSE 14 0 95 TCalibrate 63 9 45 20 0 2 12 7 5 2 59 1 0 0 FALSE 8 5 1 3 TCalibratePsd 45 5 23 4 0 2 3 9 4 3 75 1 0 0 FALSE 8 5 1 65 TChooseAxisCmd 5 25 3 1 0 2 5 2 13 1 0 1 0 0 FALSE 14 0 95 TChooseDeviceCmd 8 4 5 1 0 2 15 2 13 1 0 1 0 0 FALSE 14 0 95 TChooseScan 14 2 33 7 1 0 2 6 6 10 4 56 1 0 0 FALSE 13 2 TCmd 26 1 73 7 1 16 1 5 15 0 1 86 0 0 67 FALSE 7 5 0 65 TCommonDevParam 28 5 6 17 1 0 2 11 5 6 2 40 1 0 0 FALSE 8 5 1 3 TControlFlankCmd 20 3 33 13 6 0 2 6 6 10 1 63 1 0 0 FALSE 13 0 95 TCounterShowParam 10 25 7 6 0 2 11 4 7 1 25 1 0 0 FALSE 9 0 95 TCounterWindow 36 2 4 11 1 0 2 53 15 38 2 81 1 0 25 FALSE 45 5 1 3 TCurve 149 5 73 14 12 0 1 27 27 0 0 72 0 0 9 FALSE 13 5 0 3 TCurveShowParam 27 5 4 15 1 0 2 11 5 6 3 46 1 0 0 FALSE 8 5 1 65
363. rbeiten soda dies wiederum einen h heren Einarbeitungsaufwand zur Folge hat Damit ist das Ma auch ein Indiz daf r in welchem Umfang Umgebungsabh ngigkeiten in einigen wenigen Teilen des Software Systems zusammengefa t werden und somit den Prinzipien portabler Software insbesondere der Lokalit t folgen Die sinnvolle Aufteilung in entsprechende Systemkomponenten sollte sich auch in der Quelltextstruktur widerspiegeln Aus der Analyse der Systemkomponenten kann man f r jede dieser Komponenten angeben in welcher Quelldatei sie definiert sind bzw in welcher Quelldatei potentiell die meisten nderungen vorgenommen werden m ten siehe Abbildung 27 Das dritte Ma der Systemumgebung VKG bildet das Verh ltnis von anzupassenden Systemkomponenten zur Gesamtzahl vorhandener Systemkomponenten Damit wird im Vergleich zum zweiten Ma eine allgemeinere Aussage zur Portabilit t des XCTL Systems erm glicht Dieses Ma kann ebenfalls als Grundlage f r eine Portierungsentscheidung dienen Kommen noch Unterschiede in den Programmiersprachen hinzu wie das z B bei einem Wechsel von einer Entwicklungsumgebung in eine andere der Fall ist Querportierung so kann dieser Aufwand u a durch das Ma VSG ausgedr ckt werden VKGys 0 703 Portabilit tsanalyse am Beispiel des XCTL Systems Seite 176 60 50 49 lt D 5 a 40 72 D a C lt 30 24 lt g 2 20 67 6 N 2
364. rchitekturunterschiede des Portierungsfelds welche im vorangegangenen Abschnitt betrachtet wurden ergeben f r die jeweilige Programmierschnittstelle Windows 3 1 Win16 API und Windows 9x Windows NT Win32 API gewisse Unterschiede in Bezug auf die jeweilige Nutzung und erfordern gewisse Anpassungen der Quellen sobald eine Portierung innerhalb des betrachteten Portierungsfelds als Zielstellung vorgegeben wird Die notwendigen nderungen an den Quellen lassen sich nach Lauer 93 in folgende Problembereiche unterteilen die Benutzung eines virtuellen linearen 32 Bit Adressraumes die strikte Separation aller Prozesse bzw ihrer Adre r ume voneinander globale nderungen am Modell f r Benutzereingaben ber Tastatur und Maus erweitertes Koordinatensystem und weitere nderungen im GDI der Wegfall MS DOS und 80x86 spezifischer Aufrufe die Benutzung undokumentierter Win16 Eigenschaften aus den vorangegangenen Problembereichen resultierende Probleme bei der Nutzung von DIl s Der gr te Teil ca 95 aller Portierungsprobleme l t sich einer dieser Kategorien zuordnen So lassen sich z B einzelne geringf gige nderungen bei den Parametern oder der Funktionsweise von Win16 Funktionen unter Win32 keiner grundlegenden Problemkategorie zuordnen Ein Beispiel hierf r w ren Threads die aufgrund des preemptiven Multitaskings gewisse Anpassungen notwendig machen die sich ebenfalls schlecht einer bestimmten
365. re beeintr chtigen bzw deren Ablauf ber cksichtigt v llig verhindern Tabelle A2 Vergleich Win16 und Win32 Systemkern Windows NT Windows 9x Windows 3 x Enhanced Mode Ger tetreiber und diverse Dateisysteme Treibermodell das bimodale FAT HPFS NTFS etc k nnen zur X Implementation DOS Real Mode und Laufzeit geladen und entfernt werden Windows Protected Mode erfordert und weitgehend portabel in einer Treiber m ssen als x86 Assembler Code Hochsprache implementiert werden geschrieben werden Es wird nur das FAT Dateisystem von MS DOS unterst tzt Dateien k nnen als memory mapped Kein vergleichbarer Mechanismus Der files behandelt werden indem die X gesamte globale Adre raum kann als ein gesamte Datei ber Paging in den gro er shared memory Bereich virtuellen Adrefraum der Anwendung betrachtet werden gemappt wird z B f r shared memory oder zur Performance Steigerung Integrierte Unterst tzung von CD Ger tetreiber und residente ROM Laufwerken ber ein eigenes X Hilfsprogramme simulieren ein FAT Dateisystem CDFS hnliches System Asynchrone I O Operationen sind Synchrones I O Modell bei dem der m glich Prozesse k nnen daher X Prozess bis zur Beendigung des I O effizienter arbeiten Transfers warten mu NTFS Dateien k nnen bis zu 2 64 MS DOS und damit Windows kann Bytes umfassen Damit sind auch X maximal 2 32 Byte lange Dateien extrem gro e Festplatten und wei
366. ren Speichern ist der Adre raum fortlaufend adressierbar Bei segmentiert linearem Speicher ist der Adre raum in einzelne unabh ngige Segmente aufgeteilt und jede Adressierung l uft ber Segmentadresse und Offset Der hierarchische Speicher verf gt ber mehrere Adre raumebenen mit unterschiedlichen Geschwindigkeiten wobei jede Ebene unabh ngig von den anderen adressiert wird Dabei ist ein zus tzlicher Mechanismus f r den Datentransfer zwischen den Ebenen notwendig Auch spielt neben der Organisation des Speichers die unterschiedliche Gr e der adressierbaren Speichereinheiten und der Umfang des jeweils zur Verf gung stehenden Arbeitsspeichers eine Rolle Peripherieger te Eine gro e Anzahl von Peripherieger ten kann ebenfalls ein Ma an Portierungsproblemen verursachen In der Klasse der externen Speichermedien magnetisch optisch oder hybrid stellt sich das Problem des Transports von zu portierenden Software Systemen W hrend man bei Netzwerkverbindungen mit einheitlichen Ubertragungsprotokollen im Allgemeinen keine Transportprobleme zu erwarten hat ist die Verwendung von externen Speichermedien meist mit Problemen behaftet Nicht jeder Rechner kann mit der breiten Palette der auf dem Markt befindlichen Speichermedien umgehen oder bietet hierf r physikalische Schnittstellen Hierbei entsteht auch das Problem mit unterschiedlichen Dateisystemen umzugehen siehe Abschnitt 2 1 2 2 In der Klasse der Ausgabeger te Drucker
367. rfl che von Windows 3 1 Mit Version 4 0 die im Jahr 1995 auf den Markt kam wurde die Oberfl che an Windows 95 angeglichen Als Nachfolger von Windows NT 4 0 ist Windows 2000 seit Februar 2000 auf dem Markt Es zeichnet sich vor allem durch eine im Vergleich zu seinem Vorg nger verbesserte Technik aus und bietet dar ber hinaus eine wesentlich verbesserte Bedienoberfl che Portabilit t von Software Systemen Seite 38 Windows 95 erschien im August 1995 und unterst tzt wie Windows NT das 32 Bit Programmiermodell des 80386 und seiner Nachfolger Im Vergleich zu Windows NT fehlen allerdings Vorteile wie Sicherheit Stabilit t oder Portabilit t zu anderen Hardware Plattformen Daf r sind die Hardwareanforderungen jedoch wesentlich geringer als bei Windows NT Der Nachfolger Windows 98 wurde im Juni 1998 vorgestellt und zeichnet sich im Vergleich zu Windows 95 durch h here Performance ein gr eres Spektrum unterst tzter Hardware sowie eine bessere Anbindung an das Internet aus Der n chste Nachfolger im Bereich der sogenannten Heimanwender Betriebssysteme ist Windows ME und wurde im Juli 2000 auf dem Markt eingef hrt Es liefert eine Reihe von neuen Funktionen u a f r die Bereiche Multimedia Internet und kleine Heimnetzwerke Allen Versionen dieser Windows Reihe ist gemeinsam da sie als technische Basis noch immer das Betriebssystem MS DOS nutzen Mit der aktuellen Windows Version Windows XP hat Microsoft auch das 64
368. riebssysteme Windows 9x und Windows NT mit ihren jeweiligen Architekturen dar Im folgenden sollen deshalb die Schl sselkonzepte dieser Architekturen n her beschrieben werden siehe hierzu auch Anhang A Windows 3 x Windows 3 x ist ein ereignisgesteuertes 16 Bit Betriebssystem Die Philosophie der Ereignissteuerung von Windows ist es auf bestimmte Ereignisse Tastatur oder Mausereignis etc mit entsprechenden Proze operationen zu antworten bis das Ereignis entsprechend seiner Zielstellung behandelt worden ist Die Anwendungen liegen nicht in einer Warteschleife und fragen nach ob der Benutzer irgendwelche Eingaben get tigt hat Statt dessen werden sie von Windows benachrichtigt sobald ein derartiges Ereignis eintritt z B eine Taste gedr ckt wird Dieser gegen ber herk mmlichen DOS Anwendungen ver nderte Ansatz wird daran deutlich da nicht mehr der Entwickler den Programmflu vorgibt sondern da prim r der Anwender dar ber bestimmt Die Aufgabe der Ereignisbehandlung und steuerung bernimmt der sogenannte Ereignis Manager Er ist die zentrale Instanz f r die Vermittlung zwischen der Anwendung und den Basisdiensten des Betriebssystems Betrifft ein Ereignis ein Objekt der grafischen Oberfl che so wird diese Nachricht an das GDI Graphics Device Interface weitergeleitet und dort verarbeitet Das GDI ist f r die grafische Darstellung von Objekten auf der Benutzeroberfl che zust ndig Wird ber ein Maus Ereignis z B
369. riken Metriken und Portierungsaufwand Seite 103 Qualit tsmodelle zur Beschreibung der Software Qualit t bilden somit den allgemeinen Rahmen f r die Anwendung von Metriken zur Portabilit tsanalyse Diese Metriken k nnen dann als Produkt Metriken klassifiziert werden da sie ein bestimmtes Qualit tsmerkmal eines Software Systems messen und damit quantitative Aussagen ber die Produktqualit t einer Systemkomponente in diesem Bereich erm glichen sollen 3 2 2 Metrikvorschl ge zur Portabilit tsanalyse Um die Portabilit t eines Software Systems bestimmen zu k nnen wurden bisher eine Reihe von Metriken vorgeschlagen die im folgenden n her beschrieben werden sollen In dem Portabilit tsma von Hommel Hommel 80 siehe Kapitel 2 1 1 1 tauchte bereits das Ma des Aufwands einer Portierung P auf P Al AIl AP AA mit AJ Aufwand f r die erste Implementierung AP Aufwand f r die Portierung AA Aufwand f r die Adaptierung Ein Software Produkt galt als portabel wenn die Bedingung 0 5 lt P lt 1 erf llt war Gewald et al definieren ebenfalls den Grad der Portabilit t eines Programms durch verschiedene Aufwandsma e Hierbei wird der Begriff Konvertierungs statt Portierungsaufwand verwendet D i C i m D i P i 100 mit P Portabilit tsgrad D Entwicklungsaufwand C Konvertierungsaufwand i zu bertragendes Programm m Konvertierungsmethode Ein Portabilit tsgrad von 100 bede
370. ror rol ror rol D D D D D D D D D D D D D GetBarEgde int Dig_OnTimer HWND___ unsigned_int Dlg_OnHScrollBar HWND___ HWND___ unsigned_i Dlg_OnHScrollBar HWND___ HWND___ unsigned_i Dlg_OnHScrollBar HWND___ HWND___ unsigned_i Dlg_OnHScrollBar HWND___ HWND___ unsigned_i Dlg_OnHScrollBar HWND___ HWND___ unsigned_i Dlg_OnCommand D D D ig_OnCommand HWND___ in Ig_OnCommand HWND___ in ig_OnCommand HWND___ in ig_OnCommand HWND___ in Ig_OnCommand HWND___ int HWND ig_OnCommand HWND___ in lg_OnCommand HWND___ int HWND Ig_OnCommand HWND___ in Ig_OnCommand HWND___ int HWND ig_OnCommand HWND___ in Ig_OnCommand HWND___ int HWND Ig_OnCommand HWND___ in ig_OnCommand HWND___ in Ig_OnCommand HWND___ in Ig_OnCommand HWND___ in ig_OnCommand HWND___ in HWND___ int HWND Dlg_OnHScrollBar HWND___ HWND___ unsigned_i HWND___ unsigned HWND___ unsigned HWND___ unsigned HWND___ unsigned unsigned_ HWND___ unsigned unsigned_ HWND___ unsigned unsigned_ HWND___ unsigned unsigned_ sHWND___ unsigned_ sHWND___ unsigned_ unsigned_ HWND___ unsigned HWND___ unsigned HWND___ unsigned Anhang F Daten der Quelltextanalyse Seite 203 M_dig cpp 518 FORWARD_WM_COMMAND hwnd cm_Motorlnit 0 0 SendMessage TAngleControl Dlg_OnComm
371. rozesse bzw ihrer Adressraueme MBE 46 Globale Aenderungen am Modell fuer Benutzereingaben GDI 71 Erweitertes Koordinatensystem und weitere Aenderungen im GDI DOS 21 Wegfall MS DOS und 80x86 spezifischer Aufrufe DOK 4 Benutzung undokumentierter WIN 16 Eigenschaften Aktuelle Gesamtzahl der potentiellen Aenderungen in zugeordneter Problemklasse Die erste Zeile muss zweimal erscheinen damit sie einmal geparst wird AccessResource AccessResource Kein Win32 Aequivalent LA Nicht erforderlich loeschen AccessResource AccessResource Kein Win32 Aequivalent LA Nicht erforderlich loeschen AddFontResource AddFontResource Nur Dateinamen String keine Handles verwenden GDI AllocDSToCSAlias AllocDSToCSAlias Kein Win32 Aequivalent LA AllocResource AllocResource Kein direktes Win32 Aequivalent LA Ersetzen durch Load Find LockResource AllocSelector AllocSelector Kein Win32 Aequivalent LA AnsiLower AnsiLower Makro um CharLower MBE AnsiLowerBuff AnsiLowerBuff Makro um CharLowerBuff MBE AnsiNext AnsiNext Makro um CharNext MBE AnsiPrev AnsiPrev Makro um CharPrev MBE AnsiToOem AnsiToOem Makro um CharToOem MBE AnsiToOemBuff AnsiToOemBuff Makro um CharToOemBuff MBE AnsiUpper AnsiUpper Makro um CharUpper MBE AnsiUpperBuff AnsiUpperBuff Makro um CharUpperBuff MBE Catch Catch Kein Win32 Aequivalent SEP Ersetzen durch Structured Exception Handling SEH ChangeMenu ChangeMenu Neue Funk
372. rsetzen durch benanntes portables Win32 API EnumTaskWindows EnumTaskWindows Makro um EnumThreadWindows SEP ExitWindows ExitWindows EW_ Konstanten nicht mehr unterstuetzt GDI Siehe evtl ExitWindowsEx ExitWindowsExec ExitWindowsExec Kein Win32 Aequivalent GDI Evtl ersetzen durch ExitWindowsEx ExtDeviceMode ExtDeviceMode Kein Win32 Aequivalent GDI Ersetzen durch portable ExtDeviceModeEx ffree free NEAR FAR Funktionen nicht mehr definiert SEP Entweder Makros in WINDOWSX H benutzen oder free FlushComm FlushComm Kein Win32 Aequivalent DOS Ersetzen durch PurgeComm fmalloc malloc NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder malloc fmemccpy memccpy NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memccpy fmemchr memchr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memchr fmemcmp memcmp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memcmp fmemcpy memcpy NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memcpy fmemicmp memicmp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memicmp fmemmove memmove NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder memmove fmemset memset NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benut
373. rst tzt Anhang B Inhalt der zentralen Problembibliothek Seite 190 Anhang B Inhalt der zentralen Problembibliothek Der Inhalt der zentralen Problembibliothek Port ini ist in sechs Bereiche unterteilt APIS f r alle Windows Funktionen MESSAGES behandelt Nachrichten und SRUCTURES Strukturen TYPES ist f r die einfachen Datentypen CONSTANTS f r die Konstanten und MACROS f r Makrodefinitionen zust ndig Im Bereich CUSTOM werden alle Portierungsprobleme hinterlegt die sich keinem der oberen Bereiche zuordnen lassen PORTTOOL Um zu den einzelnen Punkten aus PORTTOOL heraus Hilfe zu erhalten wird hier der Pfad eingetragen unter dem WinHelp die API Hilfedatei findet WinHelp gt z hlp api32wh hlp WinHelp16 d be bin tcwhelp hip APIS Das Format fuer die weiteren Eintraege ist wie folgt KEINE Umlaute SuchSchluessel Win32APIHilfeBegriff Grund der Aenderung Vorgeschlagene Massnahme Optionale Varianten SuchSchluessel APIHilfeBegriff Grund der Aenderung SuchSchluessel APIHilfeBegriff SuchSchluessel APIHilfeBegriff Vorgeschlagene Massnahme SuchSchluessel Grund der Aenderung Vorgeschlagene Massnahme SuchSchluessel Grund der Aenderung Vorgeschlagene Massnahme SuchSchluessel Vorgeschlagene Massnahme Abschliessende Semikola sind optional Zuordnung zu den Problemklassen LA 109 Benutzung eines virtuellen linearen 32 Bit Adressraumes SEP 34 Separation aller P
374. rukturmetriken Datenstrukturmetriken Stilmetriken und Interne Bindungsmetriken syntaktische Bindung Umfangsmetriken vermessen die Gr e von Software Systemen textuelle Komplexit t Diese haben ihren Ursprung in der zentralen Idee da die Gr e eines Software System und dessen Komponenten viel dar ber aussagt wie einfach der Umgang mit dem System ist und wie hoch das darauf bezogene allgemeine Verst ndnis sein wird Das diesbez glich erste verf gbare Ma dieser Art war der Umfang an Quellcode gemessen in LOC Lines of Code Es gibt Auskunft ber die Anzahl der Quelltextzeilen eines Software Systems und l t sich einfach durch Ausz hlung ermitteln Weitere fr he Ma e waren der Umfang der Programmdateien oder die Anzahl der Funktionen Basierend auf den Umfangsmetriken stellte Halstead eine Anzahl Metriken auf die auf der Zahl der in einem Software System verwendeten unterschiedlichen Operanden und Operatoren sowie auf deren Gesamtzahl basiert Logische Strukturmetriken oder Kontrollflu metriken setzen auf dem Kontrollflu eines Software Systems auf und basieren auf der Idee je komplizierter der Kontrollflu eines Software Systems ist desto h her ist seine Komplexit t Das am meisten verwendete Ma ist hierbei die zyklomatische Komplexit t nach McCabe Dabei wird ausgehend von aufgestellten Kontrollflu graphen die hiernach leicht zu ermittelnde zyklomatische Zahl als Ma f r die Kompliziertheit von Kontrollfl
375. rzu geh rt u a die Verwendung der ungarischen Notation als einheitliches Benennungsschema in den Quellen Informationsquellen Neben den bisher vorgestellten Hilfsmitteln die Portabilit t von Windows basierten Software Systemen zu erh hen sind nat rlich die diversen Herstellerdokumentationen und Hilfstexte als Hilfsmittel f r die Portierung zu verstehen Dazu geh rt in erster Linie die jeweils aktuellste Version der Bibliothek von Hilfetexten des zugrunde liegenden Entwicklungssystems z B Microsoft Software Development Network und somit die vollst ndige Dokumentation der entsprechenden Programmierschnittstelle der Betriebssysteme des betrachteten Portierungsfelds PORTTOOL Werkzeug Zu den wichtigsten Werkzeugen f r die Portierung Windows basierter Software Systeme neben den der Entwicklungsumgebung und Programmerstellung Compiler Editor etc geh rt das Werkzeug PORTTOOL der Firma Microsoft Dieses zusammen mit der Win32 SDK ausgelieferte Hilfsprogramm f r die Portierungsanalyse erlaubt das automatische Auffinden von Portierungsproblemen in Bezug auf das hier betrachtete Portierungsfeld Es erlaubt das Laden von Quelltexten in einen Editor und untersucht diesen auf Codeteile die entweder gar nicht portabel oder nur eingeschr nkt portabel sind Die Quellen werden hierbei sukzessiv auf bestimmte Schl sselworte hin untersucht und zusammen mit Kommentaren und nderungsvorschl gen angezeigt Die Schl sselw rter
376. s Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep GetTimerResolution GetTimerResolution Kein Win32 Aequivalent LA GetViewportExt GetViewportExt Kein Win32 Aequivalent SEP Ersetzen durch portable GetViewportExtEx GetViewportOrg GetViewportOrg Kein Win32 Aequivalent SEP Ersetzen durch portable GetViewportOrgEx GetWindowExt GetWindowExt Kein Win32 Aequivalent SEP Ersetzen durch portable GetWindowExtEx GetWindowOrg GetWindowOrg Kein Win32 Aequivalent SEP Ersetzen durch portable GetWindowOrgEx GetWindowTask GetWindowTask Makro um GetWindowThreadProcessld SEP GetWindowWord GetWindowWord Verbreiterte Datentypen beruecksichtigen SEP GetWindowLong fuer Werte die auf 32 Bit gewachsen sind GetWinFlags GetWinFlags Kein Win32 Aequivalent DOS Ersetzen durch GetSystemInfo GlobalCompact GlobalCompact Unter Win32 nicht mehr erforderlich LA Einfach loeschen GlobalDosAlloc GlobalDosAlloc Kein Win32 Aequivalent DOS GlobalDosFree GlobalDosFree Kein Win32 Aequivalent DOS GlobalFix GlobalFix Unter Win32 nicht mehr erforderlich LA Einfach loeschen GlobalLRUNewest GlobalLRUNewest Leeres Makro LA Nicht erforderlich loeschen GlobalLRUOldest GlobalLRUOldest Leeres Makro LA Nicht erforderlich loeschen GlobalNotify GlobalNotify Kein Win32 Aequivalent LA GlobalPageLock GlobalPageLock Kein Win32 Aequivalent LA Evtl VirtualLock benutzen GlobalPageUnlock GlobalPageUnlock Kein Win32 Aequival
377. s Systems konsequent abgetrennt und werden durch ein einheitliches Protokoll vom Kernel V O Manager angesprochen Treiber k nnen durch die Bildung multipler Layer aufeinander aufbauen und ein installierbares Dateisystem wie z B das New Technology File System NTFS kann damit mehrere Ger te ber die zugeh rigen Treiber gleichzeitig bedienen Weitere Ger tetreiber k nnen jederzeit dynamisch hinzugef gt bzw entfernt werden Ein laufendes NT System mu daher nicht zwangsl ufig heruntergefahren werden um neue oder verbesserte Komponenten z B weitere Dateisysteme verf gbar zu machen Eine Spezialform f r Ger tetreiber bieten die Virtuellen DOS Maschinen VDM die NT zum Ausf hren von DOS und 16 Bit Windows Programmen verwendet Um propriet rer Hardware wie Faxmodemkarten oder Hand Scanner nicht vollends den Weg zu versperren direkte Hardwarezugriffe sind unter NT nicht zul ssig lassen sich diese ber spezielle virtuelle Ger tetreiber VDD in ein NT System einbinden Ein solcher VDD kann direkte Hardwarezugriffe in einer VDM abfangen und an einen Kernel Mode Treiber weiterleiten 08 2 WIN32 WIN32 POSIX i G Anwendungen Programm Programm Programm Programm Sech Clients 9 9 9 9 Proze POSIX Subsystem CRM Executive OS 2 1 x Geschiitzte Subsystem Subsysteme Server Sicherheit Subsystem lt el o Benutzermodus Kernelmodus System Dien
378. s behandelt sich selbst einschlie lich aller laufenden Windows Anwendungen als eine Task in diesem Multitasking Gef ge Der VMM selbst l uft im Protected Mode regelt die Speicherverwaltung verteilt die Rechenzeit auf einzelne VM s und stellt den Kontakt zur Hardware mit Hilfe der virtuellen Ger te her Virtuelle Ger te dienen haupts chlich dazu gleichzeitige Zugriffe auf Peripherieger te zu serialisieren d h die Zugriffe die mehrere Tasks wechselseitig durchf hren in eine vern nftige Reihenfolge zu bringen ohne da dabei Konflikte auftreten So k nnen sich die Anwendungen beispielsweise einen Drucker konfliktfrei teilen Dies ist um so entscheidender da DOS Anwendungen aufgrund ihrer exklusiven Ausf hrung auf solch eine Unterst tzung angewiesen sind und die belegten Ressourcen den anderen Anwendungen ansonsten nicht gemeinsam zur Verf gung stehen k nnten Die Virtualisierung ist somit unerl lich wenn Windows und DOS Programme voneinander ungest rt in einer Umgebung kooperativ zusammenarbeiten sollen Die herk mmlichen Windows Treiber arbeiten eng mit den virtuellen Ger tetreibern zusammen Beispielsweise schl gt der Treiber f r die serielle Schnittstelle Alarm wenn der VCD virtuelles COM Device feststellt da eine Windows Anwendung versucht einen COM Port zu nutzen obwohl dieser bereits durch eine DOS Applikation beansprucht wird Allen drei Modi ist gemein da Windows Applikationen eine identische Schnittstel
379. se unterzogen werden k nnen Eine Metrik oder ein Software Qualit tsma gibt au erdem an wie der Wert f r einen solchen Qualit tsindikator bestimmt werden kann Software Metriken werden aufgrund verschiedener Sichtweisen unterschiedlich kategorisiert Eine allgemein anerkannte Einteilung findet man bei Fenton Fenton 92 der Software Metriken in drei Kategorien unterteilt Ressource Metriken Proze und Produkt Metriken Ressource Metriken sind demzufolge Metriken welche sich auf die zur Verf gung stehenden Hilfsmittel innerhalb der Lebenszyklen eines Software Systems Entwicklung Integration Test Support beziehen und schlie t den personellen Bereich mit ein Proze Metriken dienen der Messung von quantitativen Eigenschaften des Programmentwicklungsprozesses und der Entwicklungsumgebungen Produkt Metriken messen im Vergleich dazu bestimmte Qualit tsmerkmale von Software Systemen welche zum einen die Codeteile selber und zum anderen die Dokumentation von Software Systemen Metriken und Portierungsaufwand Seite 78 betreffen Aufgrund der Tatsache da sich Ressource und Proze Metriken auf den Entwicklungsproze von Software Metriken beziehen der Portierungsaufwand von Software System jedoch in erster Linie von deren Qualit tsmerkmalen abh ngig ist sollen im folgenden nur die Produkt Metriken n her betrachtet werden Produkt Metriken erlauben somit quantitative Aussagen ber die Produktqualit t von Systemkomponente
380. sichtigt wurde Dies betrifft den Teil der Programmiersprachen und ist im Ma entsprechend ber cksichtigt Anschlie end kann das so erweiterte Portierungsfeld mit konkreten Portierungserfahrungen angereichert werden Es existiert somit eine umfassende theoretische Grundlage den Aufwand der Portierung von Software Systemen zu bestimmen Die geplante Portierung des XCTL Systems kann hierbei wichtige Aufwandsdaten liefern die f r zuk nftige Portierungen evtl nicht nur im Windows Umfeld genutzt werden kann Ein weiterer Gedanke ist die Realisierung der Aufwandsbestimmung von Portierungen durch ein entsprechendes Metrik Werkzeug Solch ein Werkzeug h tte nicht nur den gro en Vorteil die Me werte automatisch zu ermitteln sondern k nnte dar ber hinaus auch den Proze der Datenerfassung und Berechnung standardisieren Auch k nnte man die Aufwandsbestimmung in einen umfassenderen Werkzeugverbund integrieren Damit w ren dann entscheidende Schritte auf dem Weg zur Portierung auf Knopfdruck absolviert Literaturverzeichnis Seite 183 Literaturverzeichnis Abreu 94 Adamov 85 Balzert 96 Balzert 98 Basili 80 Bojic 02 Borland 96 Bothe Ola Bothe 01b Boyle 80 Brown 77 Buchheit 92 Buschhorn 88 Catanzaro 91 Chidamber 94 Conger 92 Doyle 84 Fenton 92 Fetcke 95 Abreu F B Object Oriented Software Engineering Measuring and Controlling the Development
381. signed_int unsigned_int unsigned_lo TRadicon FailureOccured int int TRadicon FailureOccured int int Counters cpp 1851 MessageBox GetFocus Me zeit wurde zu klein gew hlt InitializeEvent MBINFO TRadicon InitializeEvent HWND___ int Counters cpp 1781 PostMessage hControlWnd WM_COMMAND wpJumpTo Getld Counters cpp 1785 PostMessage hDisplayWnd WM_COMMAND wpJumpTo Getld KOMP TRadicon Anz BIBA 6 M_scan cpp 521 SendMessage hWndChild WM_COMMAND cm_UpdateFile 0 M_scan cpp 555 SendMessage hWndChild WM_COMMAND cm_UpdateFile 0 M_scan cpp 359 if IDNO MessageBox GetFocus buf HeadLine MBASk M_scan cpp 403 _ if IDNO MessageBox GetFocus buf HeadLine MBASk TRadicon PollDevice TRadicon PollDevice TScan CounterSetRequest long TScan CounterSetRequest long TScan InitializeTask unsigned_int long TScan InitializeTask unsigned_int long Anhang F Daten der Quelltextanalyse Seite 207 M_scan cpp 440 if IDNO MessageBox GetFocus buf HeadLine MBASK TScan lnitializeTask unsigned_int long M_scan cpp 1001 FORWARD_WM_COMMAND GetHandle cm_MoveButton 0 0 PostMessage TScan LoadOldData int M_scan cpp 1016 MessageBox GetFocus File wurde nicht ge ffnet Fehler MBINFO TScan LoadOldData int M_scan cpp 1029 MessageBox GetFocus Header ist nicht korrekt Meldung MBINFO TScan LoadOldData int M_scan cpp 1031 MessageBox GetFocus Incorrect Header Messa
382. sportable Numerical Software In Cowell H Hrsg Portability of Numerical Software Workshop Oak Brook Illinois 1976 Lecture Notes in Computer Science 57 Berlin Heidelberg New York Springer 1977 Frank G R Theaker C J The Design of the MUSS Operating System SPE Vol 9 No 8 Aug 1979 pp 599 620 Freund S Hepp D Vom Reverse Engineering zur Programmerweiterung Automatische Justage f r ein R ntgentopographie Steuerprogramm Berlin Humboldt Universit t Dipl Arb 2001 Gewald K Haake G Pfadler W Software Engineering Grundlagen und Technik rationaler Programmentwicklung 2 Auflage M nchen R Oldenbourg Verlag 1979 Gilb T Software Metrics Cambridge Massachusetts Winthrop Publishers 1977 Gollnick M L tzkendorf S Softwaremetriken McCabe Report f r das XCTL System URL https www informatik hu berlin de swt lehre PROJEKT98 produktdoku mccabe_report index htm Aktualisierungsdatum 25 5 1999 Humboldt Universit t zu Berlin Grosswendt V API Programmierung mit Windows 98 Poing Franzis 1998 Halstead M H Elements of Software Science New York Elsevier North Holland 1977 Hansen W J Measurement of Program Complexity by the Pair Cyclomatic Number Operator Count SIGPLAN Notices Vol 13 1978 Hommel G Portabilit t von Software In Schneider H J Hrsg Portable Software Stuttgart Teubner 1980 IEEE Computer Society IEEE Standard for a Software Quality Metrics Met
383. ssen Software Systeme f r den Real Mode zun chst an den entsprechenden Stellen an den Protected Mode angepa t werden Der beste Ausgangspunkt f r die Portierung eines Software Systems ist somit deren ANSI C bzw C kompatibler Code und seine Fehlerfreiheit im Protected Mode von Windows 3 1 Optional hierzu ist die STRICT Kompatibilit t welche den Vorteil der h heren Sicherheit und Portabilit t der Quellen mit sich bringt jedoch aus Zeitgr nden vernachl ssigbar ist Bei der Zielsetzung steht die Win32 Plattform im Vordergrund Hierbei stellt sich die Frage ob das Software System auch weiterhin in der Host Umgebung laufen soll Mehrweg Portierung bzw portable Programmierung einer Anwendung oder ob es vollst ndig portiert und auf der Ursprungsplattform nicht weiterentwickelt wird Einweg Portierung bzw reine Portierung Bei der Mehrweg Portierung wird der Quelltext des Software Systems parallel f r die Host und die Zielumgebung erstellt und gepflegt Hierbei werden aus einem Satz von Quelltexten sowohl lauff hige Anwendungen f r die Host als auch die Zielumgebung generiert Diese Zielsetzung wird mit Methoden der bedingten Compilierung der Definition portabler Makros oder der Isolierung von portablen Codeteilen in selbst ndigen Funktionen erreicht Jedoch ist die vollst ndige Compilierung Portabilit t von Software Systemen Seite 71 trotz aller eingesetzten Methoden nicht immer zu erreichen So sind Eigenschaften der Zielum
384. sses Sie wird wie folgt definiert CBO C Anzahl der Klassen mit denen die Klasse C gekoppelt ist Zwei Klassen sind hierbei miteinander gekoppelt wenn Methoden der einen Klasse Methoden oder Instanzvariablen der anderen Klasse aufrufen bzw verwenden Die CBO Metrik dr ckt also die Anzahl der Klassen aus die in einer gegenseitigen Benutzt Beziehung zur Klasse C stehen Je mehr Klassen eines Software Systems sich gegenseitig benutzen bzw gekoppelt sind um so empfindlicher reagiert es auf nderungen wodurch der Wartungsaufwand und die Fehleranf lligkeit signifikant steigt Exzessive Kopplung zwischen Klassen verst t gegen die Prinzipien der Modularisierung und verhindert deren Wiederverwendbarkeit Auch hier soll ein kurzes Beispiel die Verwendung der CBO Metrik verdeutlichen Klasse E Abbildung 19 Beispiel f r das Ma CBO In dem Beispiel ist die Klasse C mit insgesamt vier Klassen gekoppelt Sie wird einerseits von den Klassen A und B benutzt und nutzt ihrerseits Methoden oder Instanzvariablen der Klassen D und E Danach ergibt sich f r die Klasse C der Wert Metriken und Portierungsaufwand Seite 99 CBO C 4 3 1 4 4 RFC Response for a Class Chidamber 94 definieren die RFC Metrik Response for a Class wie folgt RFC C Responce Set RS mit RS Menge aller Methoden der Klasse C vereinigt mit der Menge aller Methoden der Klassen die von den Methoden der Klasse C aufgerufen werden Wobe
385. sssssnnssnsnnesnnsssnnnnsnsnnnsnnnnsnnnssnsnnnsnsnnssnnssesnnnsssnnnnne 15 2 1 Portabilit t im Allgemeinen iii iia la anal 15 26L DerPortabihtatsbegnff u 2828 3200 ea einen super 15 2 1 1 1 Was ist Portabilit t did aia 16 2 1 1 2 Festlegung des Sprachgebrauchs oooncoioconococonoconoconnconnconnnnnnonnnnonn nono noon ccoo noon naco nnnnnnnos 19 2 1 2 Allgemeine Probleme bei der Portierung oooiocciononocononoconnconaconaconnnonnnnan oran nonnronnccan cronos 20 2 1 2 1 Hardware eines Computersystems cccccccsccssecsteceteceeceseceeeeeecseeeeeseeeeeeeseeeseecsaeeaaees 20 2 1 2 2 Systemsoltware eur Ananas sey sees uses A 21 2 1 3 Strategien Konzepte und Werkzeuge esse ense ons ens nn 24 ED e WSprachebene ET 24 213 2 Betriebssysteme beiec niren sense asaragernakikenanenskenp ek ia 27 2 1 3 3 Ehre deeg Bee Ee 30 2 14 Portperungsmodelle 32 2 2 Portabilitat Windows basierter Software Systeme sseosssseeeeseeseesesseeeseseesoeseesesnssesresseene 36 2 2 1 Historie von Windows Systemen uuesssesssessnnessnssnnsnnnnsnnnennnsnennnnnsennsennse ernennen ernennen 36 2 2 2 Windows Konzepte und Strategien zur Windows Programmierung ssessssesesese0eeee 39 2 2 2 1 Konzepte von Wimdows Hvstemen esse ens ons ennn en 39 2 2 2 2 Programmierung Windows basierter Software Systeme ssssesesseessssseserssessseseseese 42 2 2 3 Portierungsprobleme Windows basierter Software Systeme oooooococonnocnnoo
386. ste UO Manager Grafik Cache Ger te i Virtual Manager tolber Objekt Sicherheits Proze resistent Memory y Manager konstrolle Mangager Manager Dateisystem treiber Netzwerk treiber Window Systemkern Manager Ger te treiber Hardware Abstraktionsschicht HAL Hardware Hardware Zugriff Meldungs bergabe LPC 3 Systemaufrufe Traps gt Abbildung 8 Systemarchitektur Windows NT Die NT Executive stellt den aufbauenden Subsystemen alle Funktionen zur Verf gung die diese ben tigen um ihr jeweiliges API nach au en hin zu implementieren Alle h heren Funktionen des Betriebssystems wie die grafische Oberfl che werden von den Subsystemen implementiert die wie eine normale Anwendung im User Mode des Prozessors laufen und als Server ihre Clients bedienen Portabilit t von Software Systemen Seite 56 Windows NT erlaubt so ein beliebiges nebeneinander von API s und Softwareumgebungen Schnittstellen zu anderen Betriebssystemen k nnen jederzeit problemlos nachger stet werden Jede Anwendung l uft genau wie die Subsystem Server in einem separaten Adre raum Sie m ssen deshalb ber spezielle Kan le miteinander kommunizieren die als Local Procedure Calls LPC bezeichnet werden Die Abarbeitung der LPC s kann asynchron erfolgen Dies ist insbesondere bei Ein Ausgabeoperation von Vorteil da die Anwendung in ihrer Ausf hrung nicht unter
387. stems ist desto geringer ist deren Komplexit t Geringe Komplexit t bedeutet einen hohen Grad an Einfachheit gute Verst ndlichkeit und leichte Einarbeitung Dieses wird erreicht indem man die Kopplungen minimiert und die Bindungen maximiert 3 1 2 Ma und Metrikbegriff In der Literatur so hat der berblick gezeigt haben sich f r die Vermessung von Software Systemen eine Vielfalt an Begrifflichkeiten herausgebildet Auch werden die Begriffe Ma und Metrik nicht einheitlich benutzt Aus diesem Grund sollen in diesem Abschnitt die genannten Begriffe dargestellt und f r den Rahmen dieser Arbeit festgelegt werden Nach Zuse 98 finden sich f r die Vermessung von Software Systemen die Begriffe software metrics software engineering metrics software engineering measurement oder auch software Metriken und Portierungsaufwand Seite 80 metrication Im deutschen Sprachraum benutzt man hierf r Begriffe wie Softwaremetriken bzw Software Metriken Softwaremessung oder Softwaremetrie Zuse h lt den Begriff Software Metriken in diesem Bereich als f r ungeeignet und schl gt die Verwendung von software measurement vor was sich am besten mit dem Begriff Softwaremessung ins Deutsche bersetzen l t Aus diesem Grund wird in dieser Arbeit die Vermessung von Software Systemen im allgemeinen als Softwaremessung bezeichnet Die Begriffe Mall und Metrik wer
388. structures I Ignore custom port issues FF Ignore Windows macros Ignore case sensitivity Choose to ignore token throughout file Token WORD gt gt Ignore Token lt lt OK Cancel About PortTool xj Microsoft Windows P PortTool Version 2 2 Copyright O 1990 1995 Microsoft Corp lelx MessageBox GetFocus Fehler beim Zerlegen Am9513a MBINFO return TRUE DWORD TAm9513a GetTicksPerSecond void return 1000001 void TAm9513a DigitaloOut BYTE data ifndef _WIN32__ outp nBaseAddr 3 data A d Abbildung 16 Werkzeug f r die Portabilit tsanalyse PORTTOOL Kithara Werkzeuge Ein entscheidendes Kriterium f r die Portabilit t und die Portierung von hardwarenahen Software Systemen ist die Verf gbarkeit von geeigneten Treibern in den entsprechenden Betriebssystemumgebungen Die Entwicklung von Hardwaretreibern f r bestimmte Zielumgebungen ist in vielen F llen mit einem hohen Ma an Kosten und Entwicklungszeit verbunden Um hardwarenahe Software Systeme ohne den Aufwand einer Treiberentwicklung f r die Zielumgebung portieren zu k nnen existieren Werkzeuge welche eine Art Universaltreiber zur Verf gung stellen die in das Software System eingebunden weiterhin hardwarenahe Programmierung zulassen F r die Portierung von hardwarenahen Software Systemen unter Windows existiert u a eine kommerzielle L sung der Firma Kithara die Driver Collection Toolkits Kithara 01 D
389. systemkonforme Behandlung von GDI Koordinaten sicherstellen werden eine Vielzahl von Windows Nachrichten mit gepacktem Win16 Format versorgt Dieses Format liefert Koordinaten und Gr enangaben verpackt im LPARAM Nachrichtenparameter von Windows Funktionen Hierbei liefert LOWORD lparam die x Komponente und HIWORD die y Komponente Auch liefern diverse Win16 GDI Funktionen ihre Resultate so codiert zur ck Unter Win16 werden die x y Paare als zwei getrennte Integer Werte in 4 Byte breiten Integer Datentypen DWORD oder LONG verpackt an aufrufende Funktionen zur ckgeliefert Da ein DWORD Datentyp unter Win32 aber genauso breit ist wie ein Integer Datentyp und die beiden 32 Bit Werte f r die Koordinaten nicht mehr in einem DWORD untergebracht werden k nnen funktioniert das Packen der Koordinaten hier nicht mehr Somit k nnen alle Stellen an denen ein bergang von gepackten 16 Bit Koordinaten auf das neue 32 Bit Format stattfindet mit Portierungsproblemen behaftet sein DOS und CPU Spezifisches Der fast vollst ndige Verzicht auf MS DOS oder 80x86 spezifische Aufrufe unter Win32 er ffnet ein weiteres Feld an Portierungsproblemen Hierbei ist Windows NT bedingt durch seine Architektur insbesondere durch seine Hardware Abstraktionsschicht noch strikter was den direkten Zugriff auf Hardwarekomponenten angeht als Windows 9x Wird unter Win32 versucht durch eine einheitliche und konsistente Betriebssystem API alle Ressourcen des Comp
390. t K3 2 ji 4 3 K4 ki wien Ks K6 K7 nm K5 Frei Anwendungs Code Daten K6 Dil Code Daten K7 Frei K8 A d s Cod Dati ee Physikalischer Speicher RAM Stack und Standard Heap Frei Abbildung 10 Adre raum einer Win16 Anwendung und Verwaltung von Speicherseiten Die lineare Speicherarchitektur f hrt u a dazu da einige der wichtigsten Datentypen von 16 auf 32 Bit erweitert sind siehe Anhang C Wichtige Datentypen im Vergleich und somit Unterschiede in den jeweiligen API s erzwingen Dies betrifft vor allem die Benutzung folgender Datentypen vorzeichenbehaftete und vorzeichenlose Integer Werte NEAR Zeiger fast alle Handle Typen sowie die polymorphen Typen LPARAM und WPARAM Unter Windows 3 1 reicht ein vorzeichenloser Integer Wert aus um die einzelnen 16 Bit Segmente mit jeweils 64 KB byteweise zu adressieren Gr ere Speicherbereiche werden hierbei durch eine spezielle Segmentarithmetik Segment und Offset adressiert Mit dieser Adressierungsmethode ber 16 Bit Integer Werte ist es jedoch nur schwer m glich einen 4 GB gro en Adre raum effizient zu adressieren Somit werden in 32 Bit Windows Systemen alle Integer Werte von den entsprechenden Compilern mit einer Breite von 32 Bit angelegt Die gleiche Aussage kann f r NEAR Zeiger gelten welche in 16 Bit Windows Systemen dazu verwendet werden den 16 Bit breiten Offset in e
391. t Settings for motors General tab set Output files to Debug Link tab add Debug splib lib to library modules to eliminate unresolved external timeSetEvent add winmm lib to library modules C C tab add to defines Build_Motors Use_Library C C tab make sure there is option MD for release or MDd for debug eliminate MT or ML Project Settings for counters General tab set Output files to Debug Link tab add winmm lib Debug splib lib and Debug motors 1lib to library modules C C tab add to defines Build_Counters Use_Library C C tab make sure there is option MD for release or MDd for debug eliminate MT or ML Project Settings for XControl Link tab add winmm lib Debug splib lib Debug counters 1lib and Debug motors lib to library modules C C tab add defines Use_Counters Use_Motors Use_Library Use_ImageccD C C tab make sure there is option MD for release or MDd for debug Celiminate MT or ML 3 Changes to source files all files where applicable use Edit Find in files predefined macro __WIN32__ should be renamed to _WIN32 change _export to __declspec dllexport Be sure that this new string is places in front of the words WINAPI or CALLBACK In few places word _export is just deleted That is mentioned elsewhere in this document delete all words __rtti rename constants MAXDIR MAXFILE MAXPATH MAXEXT MAXDRIVE to _MAX_DIR _MAX_FNAME MAX_PATH _MAX_EX
392. t long MenuSelect HWND___ unsigned_int long MenuSelect HWND___ unsigned_int long MenuSelect HWND___ unsigned_int long WinMain HINSTANCE__ HINSTANCE___ char_ int WinMain HINSTANCE__ HINSTANCE__ char_ int WinMain HINSTANCE__ HINSTANCE___ char_ int Anhang F Daten der Quelltextanalyse Seite 210 WinMain HINSTANCE_ HINSTANCE_ char_ int WinMain HINSTANCE__ HINSTANCE__ chat nt WinMain HINSTANCE___ HINSTANCE___ char_ int WndProc HWND__ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long WndProc HWND___ unsigned_int unsigned_int long WndProc HWND__ unsigned_int unsigned_int long M_main cpp 215 MessageBox GetFocus Keine Timer verf gbar System Fehler MBST M_main cpp 217 MessageBox GetFocus No Timer available System Failure MBSTOP M_main cpp 221 FORWARD_WM_COMMAND Main hWndFrame cm_Initialization 0 0 Se M_main cpp 1189 case WM_COMMAND M_main cpp 1195 switch GET_WM_COMMAND_ID wParam IParam M_main cpp 1197 window gt TimerRequest GET_WM_COMMAND_ID wParam Param M_main cpp 1213 if 1 lt int GET_WM_COMMAND_HWND wParam IParam M_main cpp 1243 window gt SetFocus M_main cpp 24 MessageBox GetFocus Bibliothek motors dll nicht geladen Fehler MBSTOP M_scan cpp 1922 FORWARD_WM_COMMAND hwnd cm_ParamSet hwndCtl 0 SendMessage M_scan cpp 2048 PostMessage
393. t unsigned_short GetDWord unsigned_short unsigned_short PutWord int unsigned_short unsigned_short PutWPutDWord long unsigned_short unsigned_short LM628Ready unsigned_short F 2 3 Ermittlung der Ma komponente Hardware Umgebung zum Ma HU siehe Kapitel 4 2 1 2 PAN y MAM PGM 563 37 600 KOMP MAM PGM TAdjustmentWindow TAm9513a TAreaScan TBitmap Source j TBraun_Psd TC_812 TC_8121SA TC_832 TChooseDeviceCmd TCounterShowParam TCounterWindow q TC_812GPIB gt N A A A DA MOO Oz P d WwW er or u gt Anhang F Daten der Quelltextanalyse Seite 228 TDC_Drive y TDevice TEditWindow i TEncoder d TGenericDevice Y S D 3 TMDIWindow TModalDlg TModelessDlg TMotor TMotorParam A TOptimizeDC_812 TPlotData a TRadicon TScanCmd TSetupContinuousScan TStoe_Psd SM A PS OO Oh P OHA HADODHA AROA Tx VKG yyy MAM PGM 0 395 HU PAN KOMP VKG yy 600 KOMP 0 395 F 3 MaBkomponente System Umgebung zu Ma SYS siehe Kapitel 4 2 1 4 PAN ys PAN y PAN y 356 600 956 KOMP KOMP KOMP TAbout TAdjustmentExecute TAdjustmentWindow TAm9513a TAngleControl TAquisition y TAreaScan y TAreaScanCmd TAreaScanParameters TBitmap Source
394. tabilit tsanalyse von Software Systemen Zun chst wird in einer bersicht das Gebiet der Software Metriken eingegrenzt Die darauffolgende Kl rung unterschiedlicher Begriffsvorstellungen in Bezug auf Metriken soll in einem weiteren Schritt den Sprachgebrauch dieser Arbeit festlegen 3 1 1 berblick Die Zunahme der Anforderungen an Software Systeme durch enorme Leistungssteigerungen im Hardwarebereich sowie die gleichzeitige Forderung nach Fehlerfreiheit der Systeme als ein wichtiger Qualit tsaspekt erfordert eine umfangreiche Qualit tssicherung und ist somit ein wichtiger Aufgabenbereich der industriellen Software Entwicklung Auf der Grundlage von Qualit tsmodellen unternimmt man den Versuch allgemeine Qualit tsbegriffe durch Ableiten von Unterbegriffen zu operationalisieren und zu spezifizieren Hierbei wird die Qualit t eines Software Systems durch bestimmte Qualit tsmerkmale wie z B Funktionalit t Zuverl ssigkeit bertragbarkeit charakterisiert und mittels Teilmerkmalen wie beispielsweise bertragbarkeit Anpa barkeit Austauschbarkeit verfeinert Diese werden in einem n chsten Schritt durch sogenannte Qualit tsindikatoren bzw Metriken me und bewertbar gemacht und mit diesen in Beziehung gesetzt Die Aufgabe von Metriken besteht somit darin eine quantitative Beschreibung der wesentlichen Qualit tsmerkmale von Software Systemen zu erm glichen soda diese klassifiziert verglichen und einer mathematischen Analy
395. te Ohne diese Dokumente ist es f r einen Entwickler sehr schwierig ein Software System zu warten oder zu erweitern bzw f r einen Benutzer das System vern nftig einzusetzen Ein Porteur mu sich w hrend einer Portierung u a die Aufrufstruktur und bestimmte Implementierungsentscheidungen klar machen wobei ein Fehlen der entsprechenden Dokumentation einen Portierungsversuch deutlich erschwert Portabilit tsanalyse am Beispiel des XCTL Systems Seite 166 F r jedes der oben angef hrten Dokumente wird ein bin res Ma vorgeschlagen Das Ma f r die Designdokumentation lautet wie folgt DD Designdokumentation vorhanden nicht vorhanden Bei vorhandener Dokumentation erh lt das Ma den Wert 1 ansonsten den Wert 0 Die Bewertung erfolgt durch eine rein subjektive Bewertung z B Befragung des Porteurs Dies kann in Form einer Checkliste durchgef hrt werden und ist von den Erfahrungen des Porteurs abh ngig Zu den wichtigen Designdokumenten z hlen z B das Pflichtenheft ein Produkt Modell oder das Konzept f r die Benutzeroberfl che Analog hierzu wird f r die anderen Teile der Standartdokumentation ein Ma angegeben BD Benutzerdokumentation vorhanden nicht vorhanden TD Technische Dokumentation vorhanden nicht vorhanden ID Implementierungsdokumentation vorhanden nicht vorhanden Zur Benutzerdokumentation geh rt in erster ein ad quates Benutzerhandbuch oder ein entsprechender Benutzerleitfaden Die technische Do
396. te Importbibliothek die nicht den spezifischen Code dieser Funktion enth lt sondern nur einen Verweis auf eine dynamische Bibliothek die Windows bereitstellt Wird das Programm gestartet sucht das Betriebssystem die ben tigten Bibliotheken heraus l dt sie in den Speicher und setzt die tats chlichen Adressen der einzelnen Funktionen in das Programm ein S mtliche Funktionen der Windows API befinden sich in solchen dynamischen Link Bibliotheken Die drei wichtigsten Die sind die Systemkernbibliothek Kernel32 dll f r die 16 Bit Windows Systeme das Modul Kernel386 exe die Bibliothek f r die Verwaltung der Benutzeroberfl che User32 dll User exe f r 16 Bit sowie die Grafik und Textausgabebibliothek GDI32 dll GDI exe bei 16 Bit Dar ber hinaus enth lt Windows weitere Dis mit Funktionen f r speziellere Aufgaben Das Konzept der dynamische Bibliotheken ist aber nicht nur bei der Nutzung von Betriebssystemfunktionen n tzlich sondern er ffnet auch eine Vielzahl von weiteren Anwendungsm glichkeiten Die verschiedenen Anwendungsfelder ergeben sich aus den unterschiedlichen Gr nden DIl s in seinen Software Systemen einzusetzen Ein wichtiger Grund ist die anwendungserweiternde Eigenschaft von dynamischen Bibliotheken So k nnte beispielsweise ein Unternehmen ein bestimmtes Software Produkt erstellen und anderen Unternehmen erlauben dieses in Form von DIl s zu erweitern oder zu verbessern Sie vereinfachen dar ber hi
397. tektornutzung Ablaufsteuerung Repr sentation und Darstellung der Me daten Diffraktometrie Reflektrometrie Windows Ressourcen Nicht zugeordnet Detektornutzung Motorsteuerung Ablaufsteuerung Interaktion mit der Software Diffraktometrie Reflektrometrie Detektornutzung Diffraktometrie Reflektrometrie Windows Ressourcen Nicht zugeordnet Ablaufsteuerung Diffraktometrie Reflektrometrie Detektornutzung Motorsteuerung Detektornutzung Ablaufsteuerung Windows Ressourcen Nicht zugeordnet Detektornutzung Motorsteuerung Ablaufsteuerung Interaktion mit der Software Diffraktometrie Reflektrometrie Detektornutzung Motorsteuerung Interne Funktionalit t Topographie Windows Ressourcen Nicht zugeordnet Detektornutzung Anhang D Quellen bersicht des XCTL Systems Seite 199 m_device cpp m_main cpp m_dlg cpp dlg tpl cpp main rc Klasse bzw Methoden f r das Z hlerfenster Klasse TCounterWindow Hauptfunktion f r das Programm Initialisierung der Bibliotheken Nachrichtenschleife Handler Implementation verschiedener Dialogklassen unter anderem Manuelle Justage selbstdefinierte Templateklassen f r Dialogobjekte inklusive der Methoden Ressourcen f r die Dialoge Steuerprogrammes m_layer h m_steerg h m_topo h rc_def h comhead h m_devcom h rc_def h comhead h m_devcom h m_steerg h m_topo h m_xscan h m_dlg h help_def h st_layer h _layer h
398. ten zwischen mehreren Client Anwendungen auszutauschen gewisse Anpassungsprobleme Die Speicherverwaltung unter Win32 trennt nicht mehr zwischen lokalem und globalem Heap und Dis m ssen sich im Adre raum ihrer Client Anwendung mit Speicher versorgen Dieses Problem entsteht dadurch da DIl s aber auch allgemein alle Anwendungsprozesse unter Win32 kein eigenes Datensegment mehr besitzen statt dessen ein Datenbereich im Adre raum des aufrufenden Anwendungsproszesses welches unter Win16 immer mit einem eigenen lokalen Heap der entsprechenden DIl verkn pft ist Portierungsprobleme ergeben sich auch aus der Sicht der Initialisierung und Terminierung von Dis So ist unter Win16 die Initialisierungsfunktion LibMain als Haupteintrittspunkt einer DI f r das Entsperren des Datensegments und das Einrichten globaler Variablen z B bei der Registrierung globaler Windows Klassen zust ndig Der Initialisierungscode wird nur f r die erste Anwendung die eine DII benutzt ausgef hrt und dann aufgerufen wenn die Bibliothek zum ersten Mal geladen wird Falls erforderlich k nnen ber eine Terminierungsfunktion WEP eventuelle Aufr umarbeiten beim Entladen der Dll aus dem Speicher vorgenommen werden Unter Win32 existiert f r die Initialisierung und Terminierung von Dis eine gemeinsame Funktion welche beliebig benannt werden kann z B DllEntryAndExitPoint Hierbei werden im ersten Parameter die Instance Handle Portabilit t v
399. tere VEFAT bearbeiten heute nur experimentell verf gbare Massenspeicher unter NT als ein Volume einsetzbar NTFS arbeitet transaktionsbasiert und MS DOS speichert zwar die FAT zweimal speichert Systeminformationen X ab viele weitere Informationen zur redundant ab VFAT sicheren Wiederherstellung eines korrumpierten Dateisystems fehlen Anhang A Wesentliche Systemunterschiede des betrachteten Portierungsfelds Seite 189 Transaktionen sind hier unbekannt NTFS implementiert ein gewisses Ma Ein vergleichbarer Mechanismus ist nicht an Fehlertoleranz z B durch disk X vorhanden Erst durch dedizierte striping und stellt die Basis f r VFAT zum Netzwerk Software kann ein weitere Ma nahmen mirroring Teil entsprechendes Verhalten erreicht werden striping with parity zur Verf gung NTFS Dateien k nnen durch die NT MS DOS kennt nur sehr eingeschr nkte Sicherheitsmechanismen vor dem Schutzmechanismen unberechtigten Zugriff durch andere Benutzer gesch tzt werden Peer to Peer Netzwerke werden von MS DOS stellt keine NT direkt unterst tzt Die notwendigen X Netzwerkunterst tzung zur Verf gung Hilfsprogramme sind integraler Bestandteil des Systems Mit Erweiterungen wie Windows for Workgroups ist jedoch ein Peer to Peer Netzwerk m glich Tabelle A3 Vergleich Win16 und Win32 Ein Ausgabe und Dateisystem X Eigenschaft hnlich zu WindowsNT unte
400. timmt Eine Prozedurkopplung wird um so geringer je weniger Parameter vorhanden und je mehr Parameterelemente durch elementare Datentypen definiert sind Je weniger Daten eine Schnittstelle passieren desto geringer ist die Kopplungsst rke Der Umfang der Daten bezieht sich hierbei auf die Schnittstellenbreite Anzahl der Parameter Bei Prozeduraufrufen ist die Anzahl der ausgetauschten Elemente gleich der Anzahl der Parameter solange nicht weitere Zugriffe auf globale Datenbereiche hinzukommen Erfolgt eine Kopplung ber globale Speicherbereiche Common Bereich ist die maximale Anzahl der Kopplungen KO K K 1 N mit Kals Anzahl der max Komponenten und N als Anzahl der einzelnen Datenelemente im Common Bereich Meist ist die Kopplung zwischen zwei Komponenten aber geringer da nicht jede Komponente alle Datenelemente des Common Bereichs verwendet Probleme die durch den Zugriff auf gemeinsame Datenbereiche entstehen sind die nderung einer Komponente die eine nderung des Common Bereichs zur Folge hat und sich auf alle Komponenten auswirken kann die auf den Common Bereich zugreifen eine Beschr nkung der Zugriffsm glichkeiten einer Komponente auf die Daten die im Fall einer Common Kopplung nicht m glich ist da jede Common gekoppelte Systemkomponente auf jedes Datenelement des Common Bereichs zugreifen kann In FORTRAN ist eine Reduzierung dieser Kopplungsform durch die Definition von Named Common Bereichen m glich die
401. tionen verfuegbar GDI Ersetzen durch portable Funktionen ChangeSelector ChangeSelector Kein Win32 Aequivalent LA CloseComm CloseComm COMM Funktionen auf File I O gemappt DOS Ersetzen durch CloseHandle CloseSound CloseSound Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep CountVoiceNotes CountVoiceNotes Kein Win32 Aequivalent GDI Ersetzen durch multimedia sound support oder PlaySound Beep DefHookProc DefHookProc Veraltete Hook API erzeugt nur Thread lokale Hooks SEP Neue CallNextHookEx verwenden DefineHandleTable DefineHandleTable Kein Win32 Aequivalent LA Nicht erforderlich loeschen DeviceCapabilities DeviceCapabilities Kein Win32 Aequivalent DOS Ersetzen durch portable DeviceCapabilitiesEx DeviceMode DeviceMode Kein Win32 Aequivalent DOS Ersetzen durch portable DeviceModeEx DialogProc DialogProc Dialog Prozeduren sollten portabel definiert werden GDI BOOL CALLBACK WndProc HWND hWnd UINT uMsg WPARAM wParam LPARAM IParam DirectedYield DirectedYield Kein Win32 Aequivalent GDI DigDirSelect DigDirSelect Kein Win32 Aequivalent GDI Ersetzen durch portable DigDirSelectEx DigDirSelectComboBox DlgDirSelectComboBox Kein Win32 Aequivalent GDI Ersetzen durch portable DigDirSelectComboBoxEx DigProc DialogProc Dialog Prozeduren sollten portabel definiert werden GDI BOOL CALLBACK WndProc HWND hWnd UINT uMsg WPARAM wParam LPARAM IParam DOS3Call DOS3Call Kein Win32 Aequivalent DOS E
402. tisierung der einzelnen Me schritte durch entsprechende Werkzeuge spielt f r die Zuverl ssigkeit des Ma es eine ebenso starke Rolle Da f r das hier vorgestellte Aufwandsma noch keine praktischen Erfahrungen und somit konkret vergleichbare Ergebnisse vorliegen kann die Einsch tzung nur anhand der aufgef hrten Kriterien vorgenommen werden Die einzelnen Schritte die zum Gesamtma Portabilit t f hren werden umfassend formalisiert und in gro en Teilen automatisiert Der stark subjektive Charakter der Dokumentationsbewertung l t jedoch Zweifel hinsichtlich der Zuverl ssigkeit des Ma es aufkommen Auch l t sich durch den Evolutionsaspekt die Einhaltung gleicher Bedingungen schwer oder gar nicht berpr fen Ein u erst schwierig nachzuweisendes Kriterium ist der Nachweis da ein Ma auch tats chlich das mi t was es vorgibt zu messen Balzert Balzert 98 geht sogar so weit zu behaupten da ein Ma ohne Validit tsaussagen f r objektive Bewertungen unbrauchbar ist Er unterscheidet je nach Verwendungszweck unterschiedlich hohe Anforderungen in Bezug auf die Validit t eines Ma es So mu z B f r eine Ursache Wirkungs Analyse die Validit t h her sein als f r den im Portabilit tsma auftretenden Zeitvergleich Konkrete Aussagen zur Validit t des Aufwandsma es Portabilit t werden jedoch nicht gemacht da bisher keine praktischen Erfahrungen mit dem Ma vorliegen die entsprechende Validit tsaussag
403. tung zun chst alle Quellen anzupassen und danach die Anwendung zu erzeugen oder umgekehrt ein funktionierendes Grundger st zu schaffen um dieses anschlie end schrittweise mit Funktionalit t zu f llen 2 2 4 3 Hilfsmittel und Werkzeuge F r die Portierung von Windows basierten Software Systemen gibt es eine Reihe von Hilfsmitteln und Werkzeugen die diese unterst tzen k nnen Neben der Verwendung von Zusatzbibliotheken der Schaffung einer eigenen Portabilit tsbibliothek sowie der Verwendung geeigneter Informationsquellen liefert das Quellenanalyse Werkzeug PORTTOOL Hinweise auf m gliche Portierungsprobleme und unterst tzt somit die Erkennung von Portierungsproblemen innerhalb der Quellen des Software Systems Zusatzbibliotheken F r die Portabilit t von Software Systemen existieren eine Reihe von gr tenteils kommerziellen Bibliotheken welche als mehr oder weniger stark abstrahierende Zus tze zur Windows API angeboten werden Diese Zusatzbibliotheken erm glichen ein gewisses Ma an portabler Programmierung stehen aber in geeigneter Form nur dem C Entwickler zur Verf gung Eine geeignete und portable GUI Bibliothek z B f r C Entwickler ist entweder nicht vorhanden oder man kann nur wenig von ihr profitieren Somit liegt der Einsatz von Zusatzbibliotheken im Bereich der objektorientierten Programmierung und C z B Microsoft Foundation Classes von Microsoft oder Object Windows Library von Borland Aber auch b
404. tweder Makros in WINDOWSX H benutzen oder strlen strlwr strlwr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strlwr strncat strncat NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strncat strnemp strnemp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strncmp strncpy strncpy NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strncpy strnicmp strnicmp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strnicmp strnset strnset NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strnset strpbrk strpbrk NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strpbrk strrchr strrchr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strrchr strrev strrev NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strrev strset strset NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strset strspn strspn NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strspn strstr strstr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strstr strtok strtok NEAR FAR Funktionen nicht mehr definiert LA Entwed
405. twickelt Die Quelldateien wurden untersucht und jeweils mit Funktionalit t und Headerstruktur beschrieben Daraus entstand eine erste bersicht zu den Quelldateien und deren Abh ngigkeiten F r die Bewertung der Standarddokumentation ergibt sich somit folgende rein subjektive Einsch tzung Portabilit tsanalyse am Beispiel des XCTL Systems Seite 167 DOK p 0 25 1 0 25 1 0 25 0 0 25 0 0 5 4 2 3 2 Portierungsdokumentation DOK Portierungsdokumentation INS TDA Installationsdokumentation Testdaten Angabe Portierungsschritte Annahme Zielrechner Angabe hardwareabh ngiger Komponenten Begriffskl rung PS AZ HK VB Schritte zur Ermittlung des Teilma es Portierungsdokumentation Ermittlung der Ma komponente Installationsdokumentation Ermittlung der Ma komponente Testdaten Auswertung der manuellen Inspektion Zusammenfassung zur Ma komponente Portierungsdokumentation Die Teile der Dokumentation die Erl uterungen und Anweisungen zur z B physischen bertragung eines Software Systems Anpassung an die neue System Umgebung oder den Nachweis der Korrektheit der Portierung geben werden in diesem Ma zusammengefa t Hierbei wird das Ma in die Subma e f r die Installationsdokumentation und der Testdaten unterteilt Installationsdokumentation Schritte zur Ermittlung der Ma komponente Installationsdokumentation Ermittlung ob Angaben zu den Portierungsschritten vorhande
406. tzung Motorsteuerung Detektornutzung Detektornutzung Windows Ressourcen Nicht zugeordnet Detektornutzung Detektornutzung Windows Ressourcen Nicht zugeordnet Detektornutzung Detektornutzung Detektornutzung Detektornutzung Detektornutzung Detektornutzung Detektornutzung Detektornutzung Detektornutzung Interaktion mit der Software Anhang D Quellen bersicht des XCTL Systems Seite 198 counters rc develop exe m_data cpp arscan cpp m_scan cpp m_steerg cpp m_topo cpp Dialogressourcen f r die Dialoge Einstellungen f r SCS und Z hlerkonfiguration Modul f r die Pr sentation der Daten Modul f r die Ausf hrung des AreaScans mit dem PSD und SLD Klassen f r die Diffraktometrie und Dialoge f r die Scanparameter Klassen f r die Ablaufsteuerung Makros Klassen f r die Topographie rc_def h comhead h rc_def h CG deif h comhead h m_devcom h m_steerg h m_data h rc_def h comhead h m_devcom h m_layer h m_steerg h m_dlg h m_xscan h c_layer h rc_def h comhead h m_steerg h m_xscan h c_layer h m_layer h m_devcom h rc_def h comhead h m_devcom h m_layer h m_steerg h m_dlg h m_xscan h c_layer h m_layer h _layer h rc_def h comhead h m_devcom h Windows Ressourcen Nicht zugeordnet Windows Ressourcen Windows Ressourcen Repr sentation und Darstellung der Me daten Windows Ressourcen Nicht zugeordnet De
407. u dieses Kapitels bildet die Darstellung der Ergebnisse der Portabilit tsanalyse und deren Interpretation f r das betrachtete Software System 4 1 Das XCTL System Bei dem zu analysierenden Software System handelt es sich um ein am Institut f r Physik der Humboldt Universit t zu Berlin entwickeltes Programm zur Steuerung einer R ntgen Topographie Kamera Mit Hilfe des Software Systems bezeichnet als XCTL System Control mittels X Strahlung werden Me prozesse durchgef hrt die R ckschl sse auf die G te und den Aufbau eines Halbleiters zulassen Das XCTL System hat prim r die Aufgabe die Ger te eines Versuchsaufbaus zu steuern und zu koordinieren Stellmotoren Detektoren Kollimatoren sowie die Me daten der verwendeten Ger tschaften zu erfassen und auszuwerten M ngel in der Funktionalit t und fehlerhafte Ausf hrung von Programmteilen f hrten zur Herausbildung eines Software Sanierungsprojektes welches vorhandene M ngel wie z B unzureichende Dokumentation des Systems und der Quellen Fehleranf lligkeit oder schwierige Einbindung zus tzlicher Hardware Komponenten bzw Anpassung an aktuelle System Software auf der Grundlage von Prinzipien und Methoden der modernen Software Technik beseitigen soll Das Ziel der Software Sanierung des XCTL Systems besteht darin s mtliche M ngel aus Benutzer und Entwicklersicht zu beseitigen und das Software System in seinen Qualit tsmerkmalen zu optimieren Hierzu geh rt u a auch d
408. ufwand Seite 116 Es folgt nun der Aufbau f r das Teilma Komplexit t KPL Komplexit t Schnittstellenkomplexit t Interne Komponentenkomplexit t SK IKK Formal KPL KPK DKK SK DK IKK ger mit KPK Kopplungskomplexit t DKK Datenkopplungskomplexit t SK jeer aggregierte Schnittstellenkomplexit t DLK durchschnittliche logische Komplexit t IKK aggregierte interne Komplexit t aggr Anzahl der Kopplungen aller Komponenten wobei KPK KP DKK Anzahl der SE aller Komponenten SK oor 5 KP s DK mit s s als Gewichtungsfaktoren fiir die jew Kopplungsart DLK 2 k mit V P Zyklomatischen Komplexit t des Programms k Anzahl der Programmkomponenten IKK ger k V K k SCK mit S K Summe der Verschachtelungswerte aller Komponenten k k Gewichtungsfaktoren Aufbau Teilma Schnittstellenkomplexit t SK Schnittstellenkomplexitat KP DK Kopplungsmechanismus Kommunikationsart Aufruf Verzweigung Uber Parameter Uber globale Daten AK VK PK GDK Formal Metriken und Portierungsaufwand Seite 117 SK KP DK Kopplungsmechanismus KP gt KP i l mit k Anzahl der Komponenten KP Kopplung der i ten Komponente ber den Kopplungsmechanismus Kommunikationsart mit k Anzahl der Komponenten DK Datenkopplung der i ten Komponente ber Parameter und globale Daten DK d PK d GDK mit DK Datenkopplung der i ten Komponente i
409. ufwandsdaten zu ermitteln sind werden durch das Ma SA ber cksichtigt Die n chsten Ma e beinhalten die Anzahl und Namen von Betriebssystem Routinen und eine Teilmenge von Programmiersprachenkonstrukten ber die w hrend der Messung berhaupt keine Informationen vorliegen PAsys Sie werden separat ausgewiesen weil diese Elemente als fester Bestandteil eines Betriebssystems oder einer bestimmten Programmiersprache integriert sind und somit keine Anpassungen zulassen sollten KAsys PAsys Sie k nnen sich neben anderen BS Routinen und PS Konstrukten ber die solche Informationen vorliegen bei einer Portierung als nicht anpa bar erweisen KA und stellen somit einen besonderen Problembereich dar Das Fehlen solcher Informationen kann sich stark auf die Funktionalit t des Software Systems auswirken und mu daher im weiteren Verlauf der Portierungsarbeiten genauer analysiert werden soda evtl sogar von einer Portierung abzusehen ist Alle brigen BS Aufrufe und PS Konstrukte sind zwar anpa bar und gehen damit in das Ma SA ein aber es ist wie bei der Gesamtzahl potentieller nderungskandidaten PAN nicht sicher ob Anpassungen auch wirklich erforderlich werden Diese Aussagen sind somit eher als vage zu bezeichnen Das Ma f r die Systemumgebung liefert bei einer Portabilit tsanalyse am Beispiel des XCTL Systems Seite 177 ersten Analyse zwar konkrete Ergebnisse PAN ys KOMPys VKGsy mu aber trotzdem mit
410. und AA der Aufwand f r die Adaptierung Portabilit t von Software Systemen Seite 17 Ein Software Produkt gilt dann als portabel wenn die Bedingung 0 5 lt P lt 1 erf llt ist Hiermit wird verdeutlicht was mit dem relativ geringem Aufwand in der Definition gemeint ist auf den in bisherigen Definitionen nicht eingegangen worden ist Andere Definitionen bestimmen ebenfalls ein Portabilit tsma um den Aufwand n her zu beschreiben Jedoch wird nicht von einem Ma gesprochen sondern es wird der Begriff Portabilit tsgrad eingef hrt Hierbei wird zus tzlich zum Konvertierungsaufwand auch die Konvertierungsmethode ber cksichtigt Eine Definition von Boyle geht n her auf die Adaptierung von Software ein Boyle 80 Software adaption consists of making specification preserving changes to a piece of software in order to make it work or to make it work efficiently in a particular hardware and software environment F r ihn ist die Adaptierung ein spezifikationserhaltender Proze Wird eine Spezifikation ver ndert so nennt er das eine Software Modifikation Ver nderungen in Bezug auf die Adaptabilit t sind f r Poole und Waite aber gerade nicht spezifikationserhaltend Poole 73 Adaptability is a measure of the ease with which a program can be altered to fit different user images an system constraints Adaptierungs nderungen beziehen sich hierbei auf die nderung der Funktion des Programms
411. und begleitenden Anmerkungen werden in einer zentralen Problembibliothek Datei Port ini siehe Anhang B erfa t welche als Grundlage f r den Suchmechanismus verwendet wird Der Suchalgorithmus ist einfach dem eines normalen Editors und findet somit auch Stellen die keinerlei Portierungsprobleme verursachen Das Werkzeug PORTTOOL ist deshalb nur als halbautomatisches Werkzeug f r die Portierungsanalyse von Windows basierten Software Systemen einzustufen da der gr te Teil der Portierungsanalyse weiterhin manuell durchgef hrt werden mu Portabilit t von Software Systemen Seite 74 low WORD gt value return TRUE vue FRL ent 1000 whilec ent 3 fail f fl ING fl gt Ee j Il C f2 gt 0xE000 ER SES Continue Te ran break SEGEL 7124 2 f2 ahs pail ls else fl fail f E CAL S Fail F amp C f2 gt fail break LEHE ED et EC Hal E high C worD fl low WORD f2 else mE Ei SCHI TE IN high WORD f2 low WORD Fl J TFE lent 10 x Found gt WORD Issues File 22 Line 227 low value Issue WORD Variable oder Parameter pruefen Suggested fix Ggf durch UINT oder WPARAM ersetzen Ez Stop Continue Riestart Options Help Done m Search options T Ignore Windows functions T Ignore Windows constants T Ignore Windows messages I Ignore C types FF Ignore windows
412. und entwickelt standardisierte Schnittstellen f r Betriebssysteme Auf der anderen Seite versucht man das zugrunde liegende Betriebssystem so portabel zu gestalten da es Portabilit t von Software Systemen Seite 28 ohne gr eren Aufwand auf verschiedene Umgebungen bertragen werden kann Man spricht dann von portablen Betriebssystemen Standards Die Idee bei der Standardisierung von Betriebssystemschnittstellen sind vereinheitlichte Zugriffe auf Komponenten des Betriebssystem und dessen peripheren Ressourcen die eine Lauff higkeit von System Software in verschiedenen Umgebungen sicherstellen sollen Ein anerkannter Vertreter solcher Standards ist POSIX Das Portable Operating System Interface ist ein Dokument das von der IEEE erarbeitet und von der ANSI und ISO standardisiert wurde Die POSIX Familie besteht aus mehreren Teilen wobei der IEEE 1003 1 POSIX Part 1 System API den Teil der Betriebssystemschnittstelle f r die Anwendungsprogrammierung spezifiziert und somit die Portabilit t von Software Systemen auf Quellcode Niveau unterst tzt Ein zweiter Teil ISO 9945 2 Shell and Utility Application Interface definiert Schnittstellen f r die Kommandointerpretation auf Quellcode Ebene sowie Betriebssystemdienste und unterst tzungen f r System Software als Erg nzung zum ersten Teil Ein weiterer Standard f r Betriebssystemschnittstellen ist MOSI IEEE 855 Microprocessor Operating System Interfaces
413. und zu einem entsprechenden Umgebungsma zusammenfassen Hierbei ist die Systemkomponente nun nicht mehr eine bestimmte Prozedur bzw Funktion sondern eine Klasse Die Methode als Klassenkomponente kann jedoch nicht als ein Element des Systems im Sinne der Definition bezeichnet werden da sie noch weiter zerlegbar sein soll z B in Anweisungen die Aufrufe von Routinen enthalten Als Klassenkomponenten sind bei der Anwendung des Portabilit tsma es in objektorientierten Software Systemen die Methoden und Attribute einer Klasse zu verstehen Bei den Programmiersprachen werden zwei F lle unterschieden die Sprache in die das zu portierende Software System bertragen werden soll ist ein Dialekt der Sprache in der es geschrieben wurde oder sie ist eine ganz andere Sprache Die Probleme sind in beiden F llen die gleichen Es werden bestimmte Konstrukte einer Sprache als Teil des Systems oder von Systemkomponenten identifiziert und die Anzahl der Anweisungen die sich auf das entsprechende Sprachkonstrukt beziehen vermessen Diese Sichtweise erzeugt somit Unabh ngigkeit zum verwendeten Programmierparadigma des untersuchten Software Systems Komplexit t Bei der Komplexit tskomponente des Portabilit tsma es werden die Aspekte der Schnittstellenkomplexit t und der internen Komponentenkomplexit t ber cksichtigt Die Schnittstellenkomplexit t wird zum einen durch Vermessung der Kopplungsmechanismen Aufruf und Verzweigung wobei der Ver
414. ung geschieht aus der Sicht von Programmen ber die eindeutige Angabe einer 32 Bit breiten Speicheradresse Diese sind somit nicht mehr Offsets in einen begrenzten segmentierten Bereich sondern in den bis zu 4GB gro en linearen Adre raum Dynamische Bibliotheken Dynamische Link Bibliotheken DIl s stellen von Beginn an ein zentrales Konzept f r die gemeinsame Verwendung von Codeteilen dar Ausgangspunkt f r die berlegungen waren z B Probleme bei gemeinsamen Betriebssystemaufrufen unter MS DOS Nach dem Compilieren und Binden haben selbstdefinierte Funktionen oder Funktionen statischer Bibliotheken eine jeweils festgelegte Speicheradresse Bei dynamischen Aufrufen dieser Funktionen in Systembibliotheken zur Laufzeit werden die Funktionsnummern in ein Register geladen Funktionen die auf diese Systembibliotheken zugreifen brauchen somit die exakte Speicheradresse der aufzurufenden Funktion und diese mu dar ber hinaus f r alle Clients konstant gehalten werden Da Windows nun aber mehrere tausend Funktionen zur Verf gung stellt und diese nach au en hin statt Funktionsnummern selbstbeschreibende Funktionsnamen besitzen war hier ein neuer Mechanismus notwendig der als dynamisches Binden bezeichnet wird Somit erscheinen Funktionen des Betriebssystems in Windows Programmen genauso wie Aufrufe normaler Bibliotheksfunktionen Benutzt man nun eine Betriebssystemfunktion in Windows Programmen so l uft das Einbinden ber eine sogenann
415. unterscheiden sich prim r in der internen Darstellung von Daten der Registerverwendung sowie der Speicherorganisation Ein weiteres Problem sind die Vielzahl verschiedener Peripherieger te der einzelnen Computersysteme Rechnerarchitektur Die interne Darstellung von Daten unterscheidet sich in deren Wortl nge Man unterscheidet hierbei Wortl ngen von 8 16 32 oder 64 Bit Von ihr h ngt z B die Gr e der darstellbaren ganzzahligen Datentypen die Genauigkeit von Flie kommawerten oder die m gliche Anzahl von Zeichen eines Zeichensatzes pro Maschinenwort ab Es gibt verschiedene Formate f r die Repr sentation von numerischen Daten die zu speziellen Problemen f hren Dazu geh ren vorzeichenlose ganzzahlige Werte bin r bin r dezimal usw sowie negative ganzzahlige Werte im 2er oder ler Komplement Durch das 2er Komplement lassen sich z B durch bin re Shift Operationen schnelle Rechenoperationen durchf hren die beim ler Komplement jedoch nur f r positive Zahlen korrekte Werte liefern Bei den Flie kommazahlen wurden diesbez glich schon formale Standards verabschiedet welche die interne Darstellung von Flie kommazahlen mit den darauf verwendeten Operationen definieren z B IEEE 754 Binary Floating Point Arithmetic Des weiteren k nnen unterschiedliche Zeichens tze ebenfalls zu Problemen bei der Portierung f hren Der ASCII Standard hat hier zwar eine weitverbreitete gemeinsame Basis f r viele Rechner geschaffen j
416. upt keine nderungen erforderlich sein Dieser Idealfall ist bei vielen Software Systemen nicht gegeben Manche Systeme sind so plattformspezifisch und erfordern so viele Anpassungen da eine v llige Neuentwicklung einer Portierung vorgezogen wird Um solche Probleme in den Griff zu bekommen und um Neuentwicklungen m glichst plattformunabh ngig zu gestalten besch ftigt man sich mit der Portabilit t von Software Systemen 2 1 1 Der Portabilit tsbegriff Im besten Fall sind bei einer bertragung eines Software Systems in eine andere System Umgebung keine berarbeitungen der Quellen n tig Man spricht in der Praxis h ufig schon dann von einem portablen Programm wenn es bei der bertragung der Software zu keiner Neuentwicklung kommt sondern die vorhandenen Quellen angepa t werden k nnen Es ist dann um so portabler je weniger berarbeitungen erforderlich sind Diesem eher intuitiven Verst ndnis der Portabilit t von Software Systemen stehen eine Reihe von Definitionen gegen ber Die Begriffe Portabilit t und Portierung werden jedoch in der einschl gigen Literatur in unterschiedlicher Bedeutung verwendet Neben diesen Definitionen existieren noch weitere Begriffe wie Adaptivit t und Transportabilitat die entweder synonym oder erg nzend gebraucht werden Ziel dieses Abschnitts ist eine bersicht ber die einzelnen in der Literatur vorhandenen Definitionen zu geben Anhand dieser bersicht soll da
417. ure Call LPC eine f r den lokalen Betrieb optimierte Variante des Remote Procedure Call RPC Named Pipes Mechanismen wie Dynamic Data Exchange DDE Datenaustausch erfolgt ber gemeinsame Speicherbereiche oder OLE siehe Abbildung 12 z B LPC Systemspeicher Systemspeicher Kommunikation und Datenaustausch zwischen Anwendungsprozessen nur ber explizite Interproze Kommunikation Anwendungs speicher Anwendungs speicher Systemspeicher z B Named Pipes z B DDE OLE Anwendungs speicher Abbildung 12 Getrennte Adre r ume unter Win32 und Interproze Kommunikation Die Separation der Adre r ume erzeugt einen Problembereich der im wesentlichen folgende Portierungsprobleme aufwirft Zugriff auf vorhergehende Instanzen einer Anwendung Portabilit t von Software Systemen Seite 62 Speicherverwaltung lokaler und globaler Heap Abweichungen beim Windows Management DDE und Datenaustausch Verschiedene Anwendungen ben tigen Informationen ber bereits laufende Instanzen um entweder sicherzustellen da nur eine Instanz geladen werden kann z B Task Manager oder um Informationen aus schon laufenden Instanzen zu lesen bzw an diese zu bertragen Die v llige Separation der Adre r ume f hrt dazu da sich jeder Anwendungsproze als grunds tzlich erste gestartete Instanz eines Programms identifiziert und nicht wie unter Windows 3 x
418. ustauschen Man unterscheidet zwischen kooperativem und verdr ngendem Multitasking Windows Versionen der 16 Bit Generationen folgen zwar den Prinzipien der quasi parallelen Ausf hrung von Programmen arbeiten jedoch mit der Technik des kooperativem Multitasking Hierbei wird jeder Anwendung durch den Benutzer die vollst ndige Kontrolle ber das Computersystem gegeben bis diese an eine andere Anwendung bergeben wird usw Hierbei werden der bergebenden Anwendung solange jegliche Ressourcen entzogen bis diese wieder die Kontrolle erh lt Anders sieht es bei der Technik des verdr ngendem preemptiven Multitasking in 32 Bit Versionen von Windows aus Hier werden den einzelnen Prozessen vom System selbst bestimmte Rechenzeiten zugewiesen und eine entsprechende Kontrolle ber bestimmte Ressourcen gegeben Anwendungen k nnen sich hierbei in mehrere Ausf hrungsstr nge Threads unterteilen und werden dann von Windows in Einprozessorsystemen quasi parallel bzw in Mehrprozessorsystemen echt parallel ausgef hrt Dies gilt jedoch nicht f r Windows 9x bzw Windows ME da diese Betriebssysteme keine Mehrprozessorunterst tzung aufweisen Dynamische Speicherverwaltung Die Fragmentierung von Speicherplatz stellt bei allen Betriebssystemen ein Problem dar So ist z B der Hauptspeicher eines Computersystems nach kurzer Zeit so stark fragmentiert da ohne eine dynamische Reorganisation welche die unregelm ige Folge freier und belegter Spei
419. utersystems nutzbar zu machen ist es unter Winl6 notwendig ber eine Vielzahl von direkten BIOS Aufrufen MS DOS Portabilit t von Software Systemen Seite 65 Funktionsinterrupt Peripherieger te des Computersystems zu steuern bzw ber Funktionen aus der Laufzeitbibliothek von Compilerherstellern F r Software Systeme die nach Windows NT portiert werden sollen kann folgende Aussage getroffen werden Jeder direkte Hardware Zugriff au erhalb von Ger tetreibern ist hier nicht mehr m glich und erfordert entsprechende Anpassungen Unter Windows 9x ist der direkte Hardware Zugriff zwar noch m glich jedoch sollten im Sinne der Portabilit t von windows basierten Software Systemen direkte Hardware Zugriffe und somit systemabh ngig vermieden werden Weitere Problempunkte in diesem Bereich betreffen neben den Hardware Zugriffen auch das erweiterte Dateisystem und das Konzept der zentralen Registrierungsdatei unter Win32 Insgesamt ergeben sich in erster Linie folgende Problembereiche direkte Hardwarezugriffe au erhalb von Ger tetreibern Speicherung und Bearbeitung von Dateinamen Behandlung von Intitialisierungsdaten ber das Konzept der zentralen Registrierungsdatenbank Bei der Betrachtung von Portierungsproblemen im Bereich von Hardwarezugriffen spielt die unterschiedliche Architektur der beiden Win32 Systeme Windows NT und Windows 9x eine wesentliche Rolle Ist es unter Windows 9x noch m glich aus einem Anwendun
420. utet Kompatibilit t Es bleibt anzumerken da Gewald et al die ersten Autoren sind die die Konvertierungs bzw Portierungsmethode in Ihrer Definition ber cksichtigen Trotzdem sind die bisher vorgestellten Vorschl ge kaum mehr als die Umsetzung einer Definition in eine mathematische Gleichung hnliche Vorschl ge stammen von Gilb Gilb 77 der den Portierungsaufwand mit Metriken und Portierungsaufwand Seite 104 P 1 Aufwand zur bertragung von S in die Zielumgebung Gs Entwicklungsaufwand von S f r Hostumgebung mit S Software System bestimmt Hierbei sollten nach seiner Meinung eher die Entwicklungskosten in der Zielumgebung der Original Software im Nenner der Gleichung stehen Er berechnet ein Beispiel in dem er die Entwicklungskosten mit 100000 und die bertragungskosten mit 10000 angibt womit sich ein Portabilit tsaufwand von P 0 9 ergibt und eine Portabilit t von 90 Au erdem trifft er die Annahme da der Portierungsaufwand f r nicht triviale Software eine lineare Funktion ist So erfordert beispielsweise ein Programm mit 100000 Statements den 100 fachen Aufwand eines Programms mit 1000 Statements Alle bisher aufgef hrten Vorschl ge implizieren da der Aufwand einer Portierung im voraus bestimmbar ist und machen keine Angaben dar ber wie dieser Aufwand zustande kommt oder wie er gemessen werden kann Hinzu kommt die Tatsache da der Aufwand einer Portierung mit dem Aufwand der Entwicklung in Be
421. von Objekten OLE sowie die Definition von Dialogen f r Standard Prozeduren wie das Laden und Speichern von Dateien Windows 3 1 l uft im Vergleich zu seinen Vorg ngern jedoch nur noch im Protected Mode und setzt einen 80286 Prozessor sowie Hauptspeicher von mindestens 1 MB voraus Eine Unterst tzung f r Peer to Peer Netzwerke wurde mit der Version Windows f r Workgroups 3 1 ab November 1992 realisiert WfW Windows NT New Technology in der Version 3 1 wurde im April 1994 vorgestellt und ist speziell auf den Protected Mode mit 32 Bit Prozessoren dazu geh ren die Modelle 80386 80486 Pentium und alle Nachfolger zugeschnitten Es war von Anfang an als Netzwerkbetriebssystem konzipiert weshalb es in zwei Varianten erh ltlich war als Workstation oder Client Server Variante Anwendungsprogramme die f r dieses Betriebssystem geschrieben werden haben Zugriff auf einen linearen Adre raum mit 32 Bit und verwenden ausschlie lich 32 Bit Befehle Windows NT ist f r den professionellen Einsatz auf Workstations bis hin zu Client Server Umgebungen gedacht und bietet daher im Vergleich zu seinen Vorg ngern zus tzliche Sicherheitsmechanismen und hohe Stabilit t Windows NT wurde als portables Betriebssystem entwickelt und l uft sowohl auf Intel Plattformen als auch auf einer Reihe von RISC Workstations die den Alpha Prozessor der Firma DEC verwenden Es wurde zun chst in den Versionen 3 1 bis 3 5 ausgeliefert und hatte noch die Obe
422. w hrend letztere anderweitige Dienste bereitstellen z B w re hier das Sicherheits Subsystem einzuordnen Das Win32 Subsystem ist ein im User Mode ablaufendes Programm Server und stellt allen anderen Programmen Clients einen umfassenden Satz von Diensten nach dem Client Server Prinzip zur Verf gung Windows NT macht beim Aufbau sowohl Anleihen beim Schichtenmodell als auch beim Client Server Modell W hrend der Betriebssystemkern im Wesentlichen aus mehreren bereinanderliegenden Schichten aufgebaut ist wird f r die dar berliegenden Aufgaben das Client Server Prinzip verwendet Die Dienste des Betriebssystems werden dabei in einzelne Server aufgeteilt die im User Mode und im eigenen Adre raum laufen Dies bietet einige gro e Vorteile So kann ein Server ausfallen und wieder neu gestartet werden ohne das der Rest des Systems oder die laufenden Anwendungen in Mitleidenschaft gezogen werden Wenn der Betriebssystemkern fehlerfrei l uft kann das System praktisch nicht mehr blockieren Au erdem k nnen einzelne Server auch im Netzwerk verteilt auf anderen Rechnern liegen Windows NT stellt hierf r die Remote Procedure Calls RPC zur Verf gung Da NT auch multiprozessorf hig ist kann jeder Server auf einem anderen Rechnersystem ausgef hrt werden Das Win32 Subsystem enth lt folgenden Bestandteile User Modul Window Manager GDI Modul und Treiber Grafik Erzeugung und Ausgabe Kernen Modul Betriebssystemdienste z
423. wendet und zum anderen die Erweiterung der zyklomatischen Zahl um den Schachtelungswert einer jeden Komponente vorgeschlagen Bei objektorientierten Software Systemen herrscht wie bereits gezeigt wurde keine einheitliche Meinung in Bezug auf die Verwendung der zyklomatischen Zahl Es wird daher die Verwendung der zyklomatischen Zahl nach McCabe in Verbindung mit der WMC Metrik vorgeschlagen wobei die Metriken und Portierungsaufwand Seite 129 zyklomatische Zahl der Methoden einer Klasse entsprechend gewichtet in die WMC Metrik eingeht Anstelle des Schachtelungswerts wird f r jede Systemkomponente die maximale essentielle Komplexit t bestimmt da sie einen besseren Gradmesser f r die Strukturiertheit eines Software Systems bietet und zus tzliche Aussagen zu dessen Nachvollziehbarkeit gestattet Aufbau Teilma Interne Komponentenkomplexit t f r objektorientierte Software Systeme IKK Interne Komponentenkomplexit t V K S K Zyklomatische Komplexitat Strukturiertheit Formal IKK V K S K Zyklomatische Komplexitat k V K Y VWMC i l mit VWMC Komplexit t der i ten Komponente k Anzahl der Komponenten VWMC Y g M und g M v M j l mit V M Komplexit t der j ten Methode einer i ten Komponente n Anzahl der Methoden Strukturiertheit k S K EWMC i l mit EWMC Maximale essentielle Komplexit t der i ten Komponente ber alle Methoden k Anzahl der Komponenten
424. werden Organisation der Programme und Isolation Um portable Software Systeme zu erhalten bedient man sich zweier Ans tze die als Vereinigung und Schnitt bezeichnet werden Vereinigung bedeutet f r jede Zielumgebung speziellen Code zu schreiben und alles so gut wie m glich zusammenzuf gen zum Beispiel mit bedingter bersetzung Die Vereinigung benutzt die Eigenschaften eines Systems und macht die bersetzung und Installation von den lokalen Gegebenheiten des Rechnersystems abh ngig Damit wird der entstandene Quellcode mit einer Vielzahl von Umgebungen fertig und nutzt die St rken jedes Systems Der gr te Nachteil dieser Vorgehensweise liegt in der Gr e und Komplexit t des Installationsprozesses und der Komplexit t des zugrunde liegenden Quellcodes der eine Vielzahl von bedingten bersetzungen enth lt Bedingte bersetzungen sind wie Pr prozessoranweisungen meist schwierig zu verwalten und die Informationen neigen dazu sich ber den gesamten Quelltext zu verteilen Au erdem ben tigen sie f r jede Umgebung einen Strang f r bedingte bersetzung Sie k nnen sich mit Steuerungen des Ausf hrungsflusses vermischen was zu einer schlechten Lesbarkeit der Quellen f hrt und so gut wie gar nicht getestet werden Je freier ein Software System von bedingten Portabilit t von Software Systemen Seite 47 bersetzungen ist desto einfacher und zuverl ssiger ist dessen Wartung Konfiguration und Installation Bei d
425. wird eine Prozedur Weiterhin wird durch bergabe komplexer Datenstrukturen das Geheimnisprinzip unterlaufen Kommunikationsart Stevens Stevens 81 unterteilt die Kommunikationsart in drei Gruppen Hybridkopplung Kontroll und Datenkopplung reine Kontrollkopplung und einfache Datenkopplung wobei er bei der reinen Kontrollkopplung unterscheidet zwischen direkter Verzweigung Code Kopplung und Metriken und Portierungsaufwand Seite 85 Kontrollparametern Danach geschieht die Kommunikation zwischen Systemkomponenten auf zwei Arten ber Daten und oder ber Steuerinformation Kontrollinformation Hybrid Kopplung liegt immer dann vor wenn eine Komponente den Code einer anderen ver ndert und der Hybrid Begriff sich aus der Tatsache ergibt da die modifizierende Systemkomponente den Code der anderen als Daten betrachtet die ge nderte Komponente aber dadurch kontrolliert wird Diese Kommunikationsart ist in den meisten h heren Programmiersprachen nicht realisierbar soda sie in erster Linie nur bei Assemblerprogrammen auftritt Die Kontrollkopplung bezieht die rufende Prozedur in die Steuerung der gerufenen Prozedur mit ein und widerspricht somit dem Geheimnisprinzip Die Form der direkten Verzweigung tritt auf wenn von einer Komponente direkt in eine andere Komponente verzweigt wird und nderungen an einer Komponente in welche direkt verzweigt wird oft erst dann durchf hrbar sind wenn alle Komponenten die direkt in diese Kom
426. xit t noch mit einbezogen werden da diese im Allgemeinen einen guten Indikator f r die Gesamtkomplexit t des Software Systems darstellt berschreitet der Me wert eine vorgeschlagene Grenze von 10 McCabe 76 sollte das Software System entweder weiter zerlegt oder neuimplementiert werden Dieses Ma wird f r das XCTL System wie folgt automatisch durch das McCabe Toolset ermittelt DLK V K 2 87 Das zusammengesetzte Gesamtma f r die Komplexit t des XCTL Systems lautet damit KPL KPK DKK SK u DLK IKK 0 506 0 027 817 23 2 87 1841 5 aggr 4 2 3 Dokumentation Die Dokumentation eines Software Systems hat gro en Einflu auf das Verst ndnis und die schnelle Einarbeitung in ein bestehendes System Durch geeignete Dokumentation kann der Portierungsaufwand ma geblich beeinflu t werden Aufgrund der Relevanz von Dokumentationsinformationen werden diese im Portierungsma mitgef hrt Hierbei wird das Vorhandensein wichtiger Dokumentationsteile manuell berpr ft und dem Portierungsma als subjektive Bewertung zugef hrt Somit geht die Dokumentation als subjektive Ma komponente in das Gesamtma mit ein wodurch die Objektivit t des Ma es nicht vollst ndig gegeben ist Da die Dokumentation den Portierungsaufwand aber wesentlich beeinflu t wird der Nachteil der reduzierten Objektivit t des Portierungsma es hingenommen Bei dem Dokumentationsma werden die relevanten Dokumente mit brauchbaren Informatione
427. yer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c _layer c ayer c 5 8 8 SS SA Ss A AA a OS iS SS eS aS nr SS 55 Sue eine So 5 Se ayer c D D ayer cpp D D D D D D 19 33 41 49 55 92 92 95 98 103 103 136 148 157 164 189 194 217 222 227 232 237 243 257 270 287 292 297 302 307 315 323 331 336 341 352 369 378 396 402 407 420 434 439 444 449 454 DWORD dwExposureCounts float_huge lField typedef TDList FAR LPDList typedef TDevice FAR LPDevice dwElapsedTime dwStartTime BOOL WriteTag WORD WORD DWORD DWORD HFILE WORD wDacUpperThresh pp x LOWORD IParam pp y HIWORD IParam int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR LPCSTR _export WINAPI mlGetVersion void HINSTANCE _ export WINAPI mIGetInstance void int _export WINAPI mGetScanSize void void _export WINAPI mStartMoveScan int tic int LPLONG _ export WINAPI mGetMoveScan void LPLONG _ export WINAPI mGetMoveScan void return LPLONG Scan int _export WINAPI mGetMoveFinishldx void void _export CALLBACK mSavePosition DWORD DWORD DWORD void _export CALLBACK mSavePosition DWORD DWORD DWORD BOOL _
428. yer cpp 42 int WINAPI LibMain HINSTANCE inst WORD WORD LPSTR C_layer cpp 51 int CALLBACK WEP int C_layer cpp 58 LPCSTR _export WINAPI diGetVersion void C_layer cpp 63 HINSTANCE _ export WINAPI diGetInstance void TScanCmd GetShowData char_ TSetupContinuousScan TSetupContinuousScan TScan_ TSetupContinuousScan TSetupContinuousScan TScan_ TStoe_Psd PollDevice TStoe_Psd PsdReadOut THowReadOutPsd TStoe_Psd PsdReadOut THowReadOutPsd TStoe_Psd PsdReadOut THowReadOutPsd TStoe_Psd PsdReadOut THowReadOutPsd TStoe_Psd PsdRead int int int unsigned_short_ TStoe_Psd PsdRead int int int unsigned_short_ LibMain HINSTANCE___ unsigned_short unsigned_short char_ WEP int diGetVersion diGetinstance Anhang F Daten der Quelltextanalyse Seite 220 _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer cpp _layer h 0000 000000 Oo Oo OD Oo Oo Oo D D Oo Oo OD Oo Oo Oo OD Oo Oo Oo 0 0 _layer h C_layer h C_layer h C_layer h Comclass h Comclass h Comclass h Comclass h Comclass h Comclass h Comhead h Comhead h Comhead h Dig_tpl cpp Dig_tpl cpp Dig_tpl h Dig_tpl h Dig_tpl h eee h eee h eee h eee h eee h eee h eee h eee
429. yer cpp 519 M_arscan cpp 195 M_arscan cpp 196 M_arscan cpp 271 M_arscan cpp 595 M_arscan cpp 599 M_curveh 7 M_curve h 243 M_curveh 315 M_data cpp 47 M_data cpp 50 M_devcom h 21 M_devcom h 32 define transmit cmd status DWORD crnt_time BOOL DilEntryPoint HANDLE hModule DWORD dwFunction _LPVOID int FAR PASCAL LibMain HINSTANCE hinstance WORD WORD int FAR PASCAL LibMain HINSTANCE hinstance WORD WORD int FAR PASCAL LibMain HINSTANCE hinstance WORD WORD int FAR PASCAL LibMain HINSTANCE hinstance WORD WORD int CALLBACK WEP int bSystemExit LPCSTR _export WINAPI spGetVersion void HINSTANCE _ export WINAPI spGetInstance void void _export WINAPI AboutTheMaker void LPCSTR _export WINAPI GetCFile void HWND _ export WINAPI GetFrameHandle void HWND _ export WINAPI GetClientHandle void HINSTANCE _ export WINAPI GetMainInstance void LPDataBase _export WINAPI GetDataBasePtr void BOOL _export WINAPI InitializeSPLibrary TMainParameters MainParam TxScanType _export WINAPI ParsingXScanType LPSTR xst BOOL _export WINAPI CreateDefaults void void _export WINAPI SetInfo LPCSTR status_txt SendMessage MainP hWndFrame MainP wm_DrawStatus 1002 LONG hAtom void _export WINAPI SetStaticlnfo LPCSTR status_txt ieee488_transmit char far cmd OxFFFF int far status ernt_time DIlEntryPoint void_ unsigned_long void_ LibMain HINSTANCE___ unsigned_short unsigned_short char_ Lib
430. ystem war das bereits vorgestellte Borland C in der Version 4 0 Auch diese l uft in der 16 Bit Umgebung von Windows 3 1 und stellt dessen Funktionalit t optional in Form einer objektorientierten Systembibliothek OWL zur Verf gung Bei der Implementierung des XCTL Systems wurde jedoch auf dieses Abstraktionsniveau verzichtet und direkt auf der Schnittstelle des Betriebssystems aufgesetzt Windows API Im Proze der Software Sanierung des XCTL Systems wurde das Projekt in aktuelle Versionen der Entwicklungsumgebung Borland C 4 5 und 5 02 berf hrt und somit f r erweiterte Laufzeituntersuchungen zug nglich Die Version 4 5 stellt hierzu anwenderfreundliche Debugging Werkzeuge f r 16 Bit Anwendungen zur Verf gung Die Version 5 02 h lt f r 32 Bit Anwendungen zwar den gleichen Funktionsumfang bereit ist aber nicht vollst ndig abw rtskompatibel zu 16 Bit Anwendungen Ressourcen Debugging Werkzeuge etc Grundlage f r das 16 Bit XCTL System ist somit die Entwicklungsumgebung Borland C Version 4 5 4 1 3 Hardware Umgebung Die Arbeitspl tze f r das XCTL System sind mit einer Reihe von PC s ausgestattet siehe Anhang E Die Hardwareansteuerung im XCTL System erfolgt innerhalb der Laufzeitbibliotheken motors dll und counters dll Hier befindet sich zum einen die Schnittstelle zum Ansteuern der Motoren und zum anderen die Einbindung und Ansteuerung der Detektoren Jeder Me platzrechner verf gt ber eine Motore
431. ystemen Seite 43 F r die Programmierung mittels abstrakter Entwicklungsumgebungen und entsprechenden Bibliotheken bieten sich eine Vielzahl kommerzieller L sungen an Hier w re als erste Microsoft s Visual C in Kombination mit den Microsoft Foundation Classes MFC als Alternative zum reinen C und der Windows API zu nennen Diese Entwicklungsumgebung besteht aus einem C und C Compiler zusammen mit Bibliotheken und Werkzeugen die man zum bersetzen und Binden von Programmen braucht Au erdem bietet sie eine integrierte Oberfl che f r die Erstellung und Bearbeitung der Quellen und ben tigten Ressourcen Ebenfalls enthalten ist ein interaktiver Debugger f r die Testphase des Entwicklungsprozesses Die MFC Bibliothek abstrahiert von den komplexen Teilen des Windows Systems und kapselt viele Aspekte der Windows Programmierung in einer Sammlung von C Klassen Legt man weitere Programmiersprachen zugrunde so lassen sich mit Hilfe von Visual Basic Entwicklungsumgebungen z B Microsoft Visual Basic ebenfalls komplexe Software Systeme entwickeln Das gleiche gilt f r die von der Firma Sun Microsystems in Anlehnung an C erfundene prozessorunabh ngige Programmiersprache Java Microsoft Visual Java Weitere Entwicklungsumgebungen sind Borland C oder der C Builder der Firma Borland Auch hier werden eine integrierte Entwicklungsumgebung IDE und alle Werkzeuge f r die Erstellung und Entwicklung Windows basierter Software
432. ystemkomponenten zu ihrer Systemumgebung aus z B stellen Prozeduraufrufe in Prozeduren eine Kommunikation zwischen diesen dar die zu Abh ngigkeiten Verbindungen und Kopplungen f hren Hierbei spiegelt eine Zunahme der Kopplung h here Abh ngigkeit zur Systemumgebung anderen Prozeduren wieder Geringe Kopplung von Systemkomponenten erh ht deren Verst ndlichkeit und ist ein entscheidender Faktor f r reduzierte Einarbeitungszeiten Ebenso k nnen nderungen in Systemkomponenten mit geringer Kopplung einfacher durchgef hrt werden da diese meist auf entsprechende Komponenten beschr nkt bleiben Das Ziel ist Kopplungen zwischen Systemkomponenten zu minimieren In Myers 75 werden sechs Kopplungsarten unterschieden Inhaltskopplung Common Kopplung externe Kopplung Kontroll Kopplung Stamp Kopplung und Daten Kopplung Einige Kopplungsarten von Myers enthalten Metriken und Portierungsaufwand Seite 83 verschiedene Aspekte von Kopplungen die nicht explizit Erw hnung finden z B liegt bei einer Inhaltskopplung auch eine Kontrollkopplung vor wenn beispielsweise eine Komponente die Anweisung einer anderen ndert Stevens hingegen versucht in seinem Ansatz diesen Aspekt zu ber cksichtigen in dem er die Kopplung zwischen den Systemkomponenten in verschiedenen Dimensionen differenziert Nach Stevens Stevens 81 unterscheidet man folgende Dimensionen Kopplungsmechanismus type of connection Schnittstellenbreite size und Kommunik
433. zen oder memset fmsize _msize NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder _msize frealloc realloc NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder realloc FreeModule FreeModule Makro um FreeLibrary SEP Ersetzen durch FreeLibrary FreeProcInstance FreeProcInstance Leeres Makro SEP Nicht erforderlich loeschen FreeResource FreeResource Unter Win32 nicht mehr erforderlich LA Einfach loeschen FreeSelector FreeSelector Kein Win32 Aequivalent LA fstrcat strcat NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strcat fstrchr strchr NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strchr Anhang B Inhalt der zentralen Problembibliothek Seite 191 stremp stremp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strcmp strcpy strcpy NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strcpy strespn strespn NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strcspn strdup strdup NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder strdup stricmp stricmp NEAR FAR Funktionen nicht mehr definiert LA Entweder Makros in WINDOWSX H benutzen oder stricmp strlen strlen NEAR FAR Funktionen nicht mehr definiert LA En
434. ziehung gesetzt wird der im nachhinein recht pr zise ermittelt werden kann Auf der Basis eines bereits vorgestellten Proze modells siehe Abbildung 2 in Kapitel 2 1 4 f r die Portierung definiert Mooney Mooney 93 den Grad der Portierung hnlich wie Gilb DP s 1 Cport su e2 Crdev reg e2 mit DP su Grad der Portabilit t eines Software Systems oder Teilen davon Cport Aufwand bzw Kosten der Portierung eines Software Systems oder Teilen davon su in eine Umgebung e2 Crdev Aufwand bzw Kosten der Neuentwicklung eines Software Systems oder Teilen davon mit einer bestimmten Spezifikation reg in eine Umgebung e2 Er beschreibt dar ber hinaus wie die einzelnen Ma e zustande kommen indem er f r den Aufwand der Portierung eine Berechnungsvorschrift angibt welche die Einflu gr en Modifikationsaufwand Aufwand f r Testen Debugging und Dokumentation aufsummiert Cport su e2 Cmod su e2 Cptd req e2 Cpdoc req e2 Auch wird formal beschrieben aus welchen Einflu gr en sich das Ma des Aufwands f r eine Neuentwicklung zusammensetzt Hierbei geht er davon aus da die Phasen der Entwicklung eines Software Systems wie Design Implementierung Testen und Debugging sowie Dokumentation zu einem Gesamtma aufsummiert werden k nnen und dann in das oben aufgezeigte Verh ltnis den Einflu gr en des Portierungsaufwands gesetzt werden k nnen Crdev req e2 Crdes req Crcod req e2 Crtd req e2 Cr
435. zweigungsaspekt bei der strukturierten Programmierung Vermeidung von goto Anweisungen so gut wie keine Bedeutung mehr hat realisiert und zum anderen durch die Ermittlung der Datenkopplungen entweder ber Parameter oder globale Daten Bei der Untersuchung der Kopplungsmechanismen bezieht sich das Ma darauf wie eine Komponente auf Anweisungen einer anderen Komponente zugreift und ob berhaupt eine Kopplung existiert Hierbei werden jeweils die H ufigkeiten des Auftretens von Kopplungen einer entsprechenden Kopplungsart ermittelt und einer bestimmten Systemkomponente mit entsprechender Gewichtung zugeschrieben Wobei der mehrfache Aufruf der gleichen Komponente oder die mehrfache Verzweigung in eine Komponente nicht zur Erh hung der Kopplung beitragen sollten Die Kopplungsst rke ergibt sich durch Aufsummieren der Kopplungen aller betroffenen Systemkomponenten Analog hierzu wird bei der Vermessung der Datenkopplung die H ufigkeit des Auftretens eines Datenaustauschs Parameter globale Daten wobei Mehrfachzugriffe auf das gleiche Datenelement nicht zur Erh hung der Kopplung f hren zugrunde gelegt und ebenfalls zu einem Teilma Datenkopplung aufsummiert Die beiden Teilma e dr cken somit jeweils verschiedene Kopplungsst rken aus die dann zum Teilma Schnittstellenkomplexit t zusammengefa t werden Bei objektorientierten Software Systemen besteht die Kopplung von Systemkomponenten auf Klassenebene nicht nur aus der
436. zyklomatische Zahl die logische und die essentielle Komplexit t die strukturelle Komplexit t des Software Systems F r das XCTL System ergibt sich hierf r folgendes Portabilit tsanalyse am Beispiel des XCTL Systems Seite 163 IKK V K S K 3285 398 4 2 2 3 Aggregation zum Gesamtma Komplexit t Ausgehend von den bisher ermittelten Komplexit tsma en wird nun das Gesamtma zusammengesetzt Diese werden jedoch nicht einfach zusammengefa t sondern noch weiter verrechnet um detailliertere Aussagen ber die einzelnen Einflu faktoren machen zu k nnen Das Gesamtma f r die Komplexit t hat folgenden Aufbau KPL KPK DKK SK mit KPK Kopplungskomplexit t DKK Datenkopplungskomplexit t SK jeer aggregierte Schnittstellenkomplexit t DLK durchschnittliche logische Komplexit t IKK joo aggregierte interne Komplexit t ager DLK IKK joe Um Portierungserfahrungen in das Ma mit einflie en zu lassen werden die einzelnen Ma e mit Gewichtungsfaktoren versehen und anschlie end aufsummiert Somit ist es m glich den Einflu der Kopplungswerte nach erfolgter Portierung erfahrungsm ig zu gewichten Um in das Ma f r die Schnittstellkomplexit t noch Portierungserfahrungen einflie en zu lassen werden wie folgt Gewichtungsfaktoren zun chst rein hypothetisch eingef gt und zu einer Ma zahl SK f r das aggr XCTL System aufsummiert SK goer 51 E DK 0 5 1622 5 0 5 11 95 817 23

DIPLOMARBEIT - Institut für Informatik - Support Server - Hu

Contents

Download Pdf Manuals

Related Search

Related Contents

DIPLOMARBEIT - Institut f&uuml;r Informatik - Support Server - Hu

Contents

Download Pdf Manuals

Related Search

Related Contents

DIPLOMARBEIT - Institut für Informatik - Support Server - Hu