Konzeption und Implementierung portabler Anwendungssoftware zur grafischen Kapazitätsdisposition im Rahmen der Produktionsplanung

Inhaltsverzeichnis

1. Einleitung

2. Kapazitätsdisposition im Rahmen der Produktionsplanung

3. Konzeption einer manuellen Kapazitäts- disposition mit Hilfe grafischer Inter- aktionsformen
3.1 Qualitätskriterien

4. Ausführungen zur Portierbarkeit im Hinblick auf die gestellte Aufgabe
4.1 Portabilität und andere Entwicklungsziele

5. Entwicklungsumgebungen für grafische Inter- aktionsformen und ihre Eignung für die spezifizierten Aufgaben
5.1 Grafische Bibliotheken
5.1.1 MS-Windows
5.1.2 X Windows
5.2 Window-Systeme
5.2.1 MS-Windows
5.2.2 X Windows
5.3 Resümee

6. Beschreibung der Implementierung
6.1 Auswahl der Umgebung
6.2 Modularisierung
6.3 Vorgehensweise

7. Dokumentation des erstellten Programms
7.1 Beschreibung der Module
7.1.1 Das Hauptprogramm KAP_PLAN
7.1.1.1 Fensterverwaltung in KAP_PLAN
7.1.1.2 Zeichenfunktionen in PAINT.INC
7.1.2 Der Modul DB_SQL
7.1.3 Der Modul DATEN
7.2 Beschreibung der Aufrufstruktur in WINDOWS
7.3 Beschreibung der Datenstrukturen
7.3.1 BLOCK
7.3.2 FA_DATEN
7.3.3 FAG
7.3.4 KAPDAT
7.4 Beschreibung der Testausgaben
7.5 Beschreibung der Funktionen
7.5.1 KAP_PLAN
7.5.1.1 ErrorMsg
7.5.1.2 ClearMsgQueue
7.5.1.3 AboutKapPlan
7.5.1.4 DebugCmd
7.5.1.5 DebugInfo
7.5.1.6 MarkDlg
7.5.1.7 HelpDlg
7.5.1.8 LegendeDlg
7.5.1.9 BMAuswahlCmd
7.5.1.10 BMAuswahlDlg
7.5.1.11 DatenDlg
7.5.1.12 LoginDlg
7.5.1.13 InitKapDat
7.5.1.14 KapPlanInit
7.5.1.15 WinMain
7.5.1.16 process_scroll_cmds
7.5.1.17 KapPlanWndProc
7.5.1.18 TestEnde
7.5.1.19 Menu
7.5.2 PAINT
7.5.2.1 SelectBlockObjects
7.5.2.2 SkalaZeichnen
7.5.2.3 KapBestZeichnen
7.5.2.4 KapBedZeichnen
7.5.2.5 StatFormZeichnen
7.5.2.6 StatRepZeichnen
7.5.2.7 StatBMNRZeichnen
7.5.2.8 KapPlanPaint
7.5.2.9 IdentifyBlock
7.5.2.10 ZeichneBlock
7.5.2.11 ZeichneFag
7.5.2.12 BlockVerschieben
7.5.2.13 BlockSchieben
7.5.2.14 TrackMousePosition
7.5.3 DATEN
7.5.3.1 UpdateFAG
7.5.3.2 umplanen
7.5.3.3 read_fags
7.5.3.4 read_kap_best
7.5.3.5 darstellung_berechnen
7.5.4 DB_SQL
7.5.4.1 GetUID
7.5.4.2 InitBMGList
7.5.4.3 EndBMGList
7.5.4.4 NextBMGList
7.5.4.5 InitFAGList
7.5.4.6 EndFAGList
7.5.4.7 NextFAGList
7.5.4.8 InitBestList
7.5.4.9 EndBestList
7.5.4.10 NextBestList
7.5.4.11 Login
7.5.4.12 Logout
7.5.4.13 Rollback
7.5.4.14 Commit
7.5.4.15 FADaten
7.5.4.16 ErrorText
7.5.4.17 datetostd
7.5.4.18 stdtodate
7.5.4.19 stdtowoche
7.6 Aufrufstruktur der Funktionen
7.6.1 AboutKapPlan
7.6.2 BMAuswahlDlg
7.6.3 DatenDlg
7.6.4 DebugInfo
7.6.5 HelpDlg
7.6.6 LegendeDlg
7.6.7 LoginDlg
7.6.8 MarkDlg
7.6.9 KapPlanWndProc
7.6.9.1 WinMain
7.7 Benutzte Relationen der Datenbank
7.8 Liste der zugehörigen Dateien

8. Anhang
8.1 Windows - Definitionsdateien
8.1.1 KAP_PLAN.DEF
8.1.2 KAP_PLAN.RC
8.2 Programmtext
8.2.1 KAP_PLAN.H
8.2.2 KPL_DEF.H
8.2.3 DCL_VAR.INC
8.2.4 KAP_PLAN.C
8.2.5 PAINT.INC
8.2.6 DATEN.H
8.2.7 DATEN.C
8.2.8 DB_SQL.PC
8.3 Literaturverzeichnis

1. Einleitung

Diese Arbeit beschäftigt sich mit der Konzeption und Implementierung portabler Anwendungssoftware zur grafischen Kapazitätsdisposition im Rahmen der Produktionsplanung.

Ziel der Arbeit ist die Konzeption eines Software- systems für die Kapazitätsdisposition bei der Produktions- planung mit Hilfe grafischer Interaktionsformen. Bela- stungsdiagramme, die die Auslastung von Maschinengruppen periodisch darstellen, sollen auf Bildschirmgrafiken abge- bildet und mit einem Pointing-Device direkt manipuliert werden. Diese Manipulationen stoßen unmittelbar Funktionen der Produktionsplanung an.

Die Tragfähigkeit der Konzepte soll durch eine exem- plarische Implementierung unter Beweis gestellt werden. Der dialogorientierte Charakter dieser Funktionen impliziert hohe Anforderungen an die Performance des Systems. Dafür müssen Lösungen entwickelt werden, wie die darzustellenden Daten am günstigsten zu organisieren sind und wie die Grafikfunktionen effizient implementiert werden können. Für die Grafikfunktionen sollen existierende Funktionsbiblio- theken auf ihre Eignung für diese Aufgabe untersucht werden.

Ein besonderer Schwerpunkt liegt auf der Anforderung, daß das Programmsystem mit möglichst geringem Aufwand auf unterschiedliche Rechnersysteme portierbar sein soll. Dies ist sowohl im Hinblick auf das zugrundeliegende Betriebs- system (UNIX, MS-DOS,...), wie auch auf die unterschied- liche Hardwareausstattung der einzelnen Rechnersysteme zu berücksichtigen. Dieser Aspekt grenzt die Kandidaten für geeignete Grafikbibliotheken weiter ein (GKS, X-WINDOWS, -..). Dabei sollen die Window-Systeme X-WINDOWS der UNIX- Welt und das Microsoft-Produkt MS-WINDOWS bezüglich der Konzepte und Leistungen miteinander verglichen werden.

In Kapitel zwei wird die Einordnung der Kapazitätsdis- position innerhalb eines Modells der gesamten Produktions- planung kurz dargestellt. Das Kapitel drei enthält grund- legende Überlegungen zur Konzeption der manuellen Kapazi- tätsplanung. Dabei finden moderne grafische Interaktions- formen besondere Berücksichtigung. In Kapitel vier werden Aspekte der Portabilität und ihre Umsetzung bei der Imple- mentierung behandelt. In Kapitel fünf werden Entwicklungs- umgebungen und Bibliotheken untersucht, die grafische In- teraktionen unterstützen. In Kapitel sechs schließlich wird die konkrete Implementation der grafischen Kapazitätsdispo- sition beschrieben. Die Dokumentation des erstellten Pro- gramms schließt in Kapitel sieben an. Den Anhang bilden dann die Quelltexte und das Literaturverzeichnis.

2. Kapazitätsdisposition im Rahmen der Produktionsplanung

Der Begriff der Produktionsplanung umfaßt viele unter- schiedliche Planungsaktivitäten für verschiedene Zeithori- zonte. Innerhalb der gesamten Unternehmensplanung beinhal- tet die Produktionsplanung "die Festlegung des Produktions- geschehens für einen zukünftigen Zeitraum"¹. In der Li- teratur gibt es unterschiedliche Ansätze, die Produktions- planung zu gliedern. Eine gute Zusammenfassung ist von Kurbel (1983) erschienen.

Für die computergestützte Planung wird eine Gliederung nach Funktion und Zeitbezug gewählt. Die Produktionsplanung gliedert sich danach in die strategische, die taktische und die operative Produktionsplanung.

Die strategische Planung hat einen langfristigen Pla- nungshorizont. Hier fallen Entscheidungen über die generel- len Produktfelder und die Organisation der Produktion. Die Auswahl der Fertigungsverfahren und die Entscheidung über die grundsätzliche Auslegung der Fertigungskapazitäten gehören ebenfalls zur strategischen Planung.

Im mittelfristigen Planungshorizont liegt die takti- sche Produktionsplanung. Hier werden Produktionsprogramm und Produkte konkretisiert und die Ausstattung mit Personal und Produktionsanlagen festgelegt.

Die operative Produktionsplanung schließlich plant die Durchführung des Produktionsprozesses auf kurzfristige Sicht. Hier wird im Produktionsprogramm festgelegt, welche Mengen von welchem Produkt gefertigt werden. Der Bedarf an Einzelteilen sowie Baugruppen und Zwischenerzeugnissen etc. wird in der Bedarfsplanung festgelegt. Das Termingerüst, welches von Durchlaufzeiten und Maschinenkapazitäten mitbe- stimmt wird und letztlich die Maschinenbelegungsplanung, d.h. die genaue Planung, wann welche Maschine welches Pro- dukt fertigt, gehören ebenfalls in den Rahmen der operati- ven Produktionsplanung.

Die Erstellung des Termingerüstes wird auch mit dem Begriff Kapazitätsdisposition bezeichnet. Die Kapazitäts- disposition soll für eine gleichmäßige Auslastung der Kapa- zitäten sorgen und sowohl Überbelastung als auch Unterbela- stung vermeiden. Da die Entscheidung über die verfügbare Maschinenkapazität aber bereits innerhalb der taktischen Produktionsplanung für einen längeren Zeitraum fällt, muß die Kapazitätsdisposition mit den gegebenen Kapazitäten auskommen.

Im Wesentlichen handelt es sich also um eine Glättung der Kapazitätsanforderungen. Diese Glättung soll durch Ver- schiebung von einzelnen Arbeitsaufträgen erreicht werden.

Diese Arbeitsaufträge befinden sich aber innerhalb eines Auftragsnetzes, dessen hinterer Eckpunkt der Liefertermin und dessen vorderer Eckpunkt der Zeitpunkt ist, an dem frü- hestens alle benötigten Teile für diesen Arbeitsgang be- reitgestellt sein können. Während der hintere Ecktermin (Liefertermin) ungern überschritten wird, da Termintreue heute in vielen Branchen den Kunden gegenüber ein wichtiges Qualitätsmerkmal ist, ist es beim vorderen Ecktermin physi- kalisch unmöglich, ihn zu unterschreiten.

Innerhalb dieser vorgegebenen Grenzen (und notfalls auch über den Liefertermin hinaus) besteht aber oft ein großer Dispositionsspielraum. Um diesen Spielraum auszunut- zen bedarf es sowohl des Sachverstandes des im speziellen Betrieb und in dessen Betriebsabläufen eingearbeiteten Sachbearbeiters, als auch ausgefeilter Computerprogramme, um dem Sachbearbeiter Routineaufgaben, langwierige Berech- nungen und auch umständliche Terminierungen und Umterminie- rungen abzunehmen. Die Aufgaben dieses Computerprogramms werden im Rahmen dieser Arbeit eingegrenzt und beispielhaft implementiert.

3. Konzeption einer manuellen Kapazitätsdisposition mit Hilfe grafischer Interaktionsformen

Herkömmliche Kapazitätsdisposition ist immer ein Ar- beiten mit langen Zahlenkolonnen. Wenn der Sachbearbeiter mit Computerunterstützung arbeitet, so war bisher entweder eine aufwendige Optimierung vom Computer oder wieder der Umgang mit den einzelnen Belastungszahlen vorgesehen. Der Nachteil der Optimierungsverfahren ist vor allem der hohe Aufwand, der für sie notwendig ist, und komplexe Randbedin- gungen der Produktion, die sich nicht immer mit vertret- barem Aufwand im Rechnermodell erfassen lassen. Dies gilt vor allem für kleine und mittlere Unternehmen. Hier soll nun versucht werden, die Problemlösungskompetenz des ein- zelnen Sachbearbeiters durch geeignete Computerunter- stützung wieder in den Vordergrund zu stellen².

Ausgangspunkt für eine manuelle Kapazitätsdisposition mit grafischen Interaktionsformen ist die grafische Dar- stellung der Kapazitätsbedarfe und des Kapazitätsangebotes: das Kapazitätsgebirge. In dieser Grafik kann der Sachbear- beiter Überlast und Überkapazität direkt sehen. So ist schon auf den ersten Blick die Entscheidung möglich, ob ein Ausgleich herbeigeführt werden muß und ob dieser Ausgleich durch Verschieben errreicht werden kann, oder ob andere Maßnahmen ergriffen werden müssen (z.B. "verlängerte Werk- bank" od. Überstunden).

Die Darstellung der Kapazitäten als Kapazitätsgebirge ist nicht neu. Bisher allerdings waren diese Grafiken nur darstellendes Medium, und direkte Manipulationen mit Aus- wirkungen auf die Betriebsplanung waren nicht möglich. Hier liegt nun der Ansatzpunkt für einen effizienten Mensch-Ma- schine Dialog. Die Grafik wird vom Sachbearbeiter mit ge- eigneten Mitteln direkt so umgestaltet, daß die gewünschte Glättung der Kapazitätsanforderungen erreicht wird und we- der Über- noch Unterbelastung auftritt.

Dabei werden direkt in der Kapazitätsgrafik Arbeits- gänge erkannt, die Überlastungen auslösen. Sie können mit der Maus "angefaßt", und dann an Stellen geschoben werden, an denen die Kapazität noch nicht ausgelastet ist.

Soll ein solches Verschieben durch direkte Manipula- tion an der Grafik möglich sein, so muß das Programm fol- genden Funktionsumfang haben :

1. Die im Betrieb vorhandenen Betriebsmittel müssen ein- zeln bzw. als Betriebsmittelgruppe für die grafische Dar- stellung ausgewählt werden können.
2. Die für die Darstellung notwendigen Daten sollen mög- lichst direkt aus einer vorhandenen Datenbank gelesen und die Änderung wieder in diese Datenbank geschrieben werden. Wenn für die grafische Kapazitätsdisposition eine eigene Datenbank angelegt würde, so wäre die Konsistenz der Daten innerhalb des Betriebes gefährdet. Die Kapazitätsdisposi- tion muß also an vorhandene Datenbanken angepaßt werden können.
3. Einzelne Aufträge müssen in der Grafik identifiziert und angewählt werden können. Dies geschieht im Idealfall mittels eines pointing device, z.B. Maus oder Lichtgriffel. Wichtige Informationen über den Auftrag, wie zum Beispiel Auftragsnummer, Status des Auftrages oder die Ecktermine, müssen entweder direkt erkennbar sein, oder auf Abruf am Bildschirm erscheinen.
4. Das Verschieben selber muß ebenfalls mit dem pointing device direkt in der Grafik ausgeführt werden können. Die entsprechenden Änderungen sollen in der Grafik anschließend sichtbar sein.
5. Da eine neue Terminierung sehr zeitaufwendig sein kann, wird sie bei Bedarf vom Benutzer explizit angestoßen. Die Terminierung selber ist nicht Bestandteil dieses Pro- gramms zur grafischen Kapazitätsdisposition, sondern eine externe Funktion.

Aus diesen Überlegungen ergeben sich die einzelnen Funktionen für das Programm: Für den Zugriffschutz der Da- tenbank können Benutzername und ein Password angegeben wer- den (LOGIN). Mit einem Kommando Betriebsmittelauswahl wer- den Betriebsmittelgruppen (oder evtl. Einzelbetriebsmit- tel), die in der Datenbank vorhanden sind, zur Auswahl am Bildschirm angezeigt. Nach der Wahl einer Betriebsmittel- gruppe wird das Kapazitätsgebirge auf dem Bildschirm ange- zeigt.

Die Darstellung am Bildschirm kann mit zwei Funktionen geändert werden. Zunächst kann die Zeitachse so eingestellt werden, daß jeweils ein Tag, eine Woche oder ein Monat als Basiseinheit verwendet, und die Grafik entsprechend darge- stellt wird. Außerdem kann zwischen unterschiedlichen Zeit- grenzen³für Beginn und Ende, die in der Datenbank vorhan- den sind, umgeschaltet werden.

Die Arbeitsgänge werden jeweils als horizontale Folge übereinander gestapelter Blöcke dargestellt. Die Höhe ent- spricht dabei der voraussichtlichen zeitlichen Belastung des angezeigten Betriebsmittels für den ausgewählten Basis- zeitraum (Tag, Woche oder Monat); die Farbe soll den Status darstellen. Die verfügbare Kapazität wird als eine Linie in der entsprechenden Höhe gezeichnet.

Mit Hilfe der Maus kann ein Block angewählt werden; die Arbeitsgangnummer und die zugrundeliegenden Zeiten wer- den dann angezeigt und alle zu diesem Arbeitsgang gehören- den Blöcke entsprechend schraffiert. Bei Bedarf können aus der Datenbank zusätzliche Informationen zu diesem Arbeits- gang angefordert und angezeigt werden.

Die Umplanung von Arbeitsgängen geschieht ebenfalls mit der Maus durch Anwählen, Festhalten und Verschieben von Blöcken. Auf der Grafik kann die Auswirkung der Verschie- bung auf die Auslastung direkt beobachtet werden. Erst wenn dieses Ergebnis zufriedenstellend ist, soll die möglicher- weise zeitaufwendige Neuplanung erfolgen.

Eine Neuplanung der verschobenen Arbeitsgänge (mit den Auswirkungen auf das gesamte Auftragsnetz) mit den vom Sachberbeiter durch das Verschieben vorgegebenen Zeiten kann nach unterschiedlichen Terminierungsalgorithmen ange- stoßen werden.

Die im Programm verfügbare Hilfe besteht aus einer Le- gende der grafischen Symbole und der Farben und Schraffu- ren, sowie aus der Anzeige von Texten zur Erläuterung der wichtigsten Funktionen.

Als letzte Funktion muß schließlich auch noch das Be- enden des Programms möglich sein. Der Sachbearbeiter wird vorher noch darauf hingewiesen, daß seit der letzten Neu- planung keine Änderungen in die Datenbank übernommen sind.

3.1 Qualitätskriterien

Wichtige Qualitätskriterien bei diesem Programm sind gute Performance und eine möglichst hohe Portabilität. Die- sen Kriterien ist schon bei der Konzeption des Programms Beachtung zu schenken.

Aufgrund des interaktiven Charakters der gestellten Aufgabe sind akzeptable Antwortzeiten unabdingbar, wie dies auch schon in der Aufgabenbeschreibung ausgeführt ist. Die- sem Ziel müssen sich gegebenenfalls andere Ziele unterord- nen. Wenn das Programm aufgrund nicht akzeptabler Antwort- zeiten nicht eingesetzt werden kann, sind alle anderen Ent- wicklungsziele obsolet.

Darüberhinaus ist die Arbeitsgeschwindigkeit des Pro- gramms auch ein Kostenfaktor. In gewissem Rahmen läßt sich ein langsames Programm durch besonders schnelle Hardware kompensieren, so daß die Akzeptanz durch den Anwender wie- der gegeben ist. Diese höhere Geschwindigkeit der Hardware wird aber in der Regel durch überproportional höhere An- schaffungskosten der Hardware erkauft. Einige Programme er- leben erst dann ihren Durchbruch am Markt, wenn die dafür nötige Hardware erschwinglich wird.

Die Forderung nach hoher Portabilität ergibt sich aus der Entwicklungsumgebung und den möglichen Einsatzrechnern. Entwickelt wird das Programm auf einem IBM-AT kompatiblen Rechner unter MS-DOS. Der mögliche Einsatz auf UNIX-Work- stations und auf PS/2 - Rechnern soll aber so leicht wie möglich gemacht werden. Darüberhinaus stellt die Kapazi- tätsdisposition einen Teil eines elektronischen Fertigungs- leitstandes dar, der gemäß seiner Konzeption jeweils an schon bestehende, unterschiedliche PPS-Systeme angepaßt werden soll.

Neben diesen vorrangingen Anforderungen dürfen aber auch weitere Qualitätsmerkmale nicht vernachlässigt werden. Dazu zählen besonders die Adaptibilität und die Wartbarkeit des Programms. Diese beiden Anforderungen ergeben sich vor allem aus dem prototypenhaften Charakter dieses Programms. Auf Wünsche möglicher Benutzer bezüglich der Oberfläche oder der realisierten Funktionen sollte schnell und ohne großen Aufwand reagiert werden können. Da diese möglichen Änderungen mit großer Wahrscheinlichkeit zunächst mit neuen Fehlern im Programm verbunden sind, ist auch eine gute Wartbarkeit vonnöten.

Die Forderung nach Universalität braucht für dieses Programm hingegen nicht erhoben zu werden. Es geht in er- ster Linie um das Aufzeigen der Möglichkeiten, mittels gra- fischer Interaktionen die Kapazitätsplanung für den Sachbe- arbeiter einfacher und übersichtlicher zu gestalten. Durch die Forderung nach Adaptibilität besteht anschließend auch die Möglichkeit, fehlende Funktionen schnell und einfach zu realisieren. Der Nachteil schlechterer Effizienz durch Uni- versalität, wenn nicht benötigte Funktionen das Programm verlangsamen, soll schließlich vermieden werden.

4. Ausführungen zur Portierbarkeit im Hinblick auf die gestellte Aufgabe

Unter Portieren versteht man im Allgemeinen das Über- tragen eines Programms von einer Umgebung (Hardware, Be- triebssystem, Softwarebibliotheken etc.) in eine andere Um- gebung⁴. Je höher der Aufwand für eine derartige Übertra- gung ist, desto geringer ist die Portabilität eines Pro- gramms.

Diesen Übertragungsaufwand muß man insbesondere unter Kostengesichtspunkten betrachten. Spätestens dann, wenn es billiger ist, das Programm komplett neu zu schreiben, wird man an Portierung nicht mehr denken. Während bei gegebener Problemstellung die Kosten einer Neuimplentierung durch vorhergehende Implementierungen nicht beeinflußt werden, kann man die Kosten einer Portierung durch geeignete Maß- nahmen durchaus senken.

Der Aufwand für eine Portierung ist auch direkt abhän- gig von der Zielumgebung. Ein Programm kann z.B. innerhalb eines Betriebssystems oder einer Betriebssystemgruppe leicht portierbar sein, die Umstellung auf ein ganz anderes Betriebssystem kann dagegen einen unvertretbar hohen Auf- wand erforderlich machen.

Die Übertragung eines Programms von einer Programmier- sprache in eine andere wird naturgemäß dem Aufwand für eine Neuimplementierung nahekommen. Aus diesem Grund wird für die folgenden Überlegungen davon ausgegangen, daß die Pro- grammiersprache auch in der Zielkonfiguration verfügbar ist. Diese Voraussetzung schränkt den Kreis der verwendba- ren Programmiersprachen schon ein. Maschinensprache und Assemblerprogrammierung fallen hier aus, da sie nur auf je- weils einem Maschinentyp verfügbar sind.

Bei der Auswahl der Programmiersprache ist ferner darauf zu achten, daß sie eine hinreichend hohe Verbreitung hat und auch in Zukunft von den Herstellern unterstützt wird.

Der Aufwand, der für eine Portierung nötig ist, ergibt sich aus der Abhängigkeit eines Programms von bestimmten Komponenten der konkreten Umgebung. Das können sowohl Hard- warekomponenten als auch Betriebssystem und ergänzende Sy- stemsoftware sein.

Jede einzelne Quelle der Abhängigkeit ist bei der Un- tersuchung der Portierbarkeit zunächst getrennt zu betrach- ten. Man kann für fertiggestellte Programme einen Abhängig- keitsgrafen zeichnen, aus dem der Portierungsaufwand sowohl insgesamt als auch für einzelne Bereiche ersichtlich wird (Abb. 1). Jede einzelne Achse steht dabei für eine Quelle der Abhängigkeit des Programms bzw. für eine Kostenquelle bei einer möglichen Portierung. Je weiter außen der Graf die Achse schneidet, desto höher sind die entsprechenden Kosten. Die vom Graf beschriebene Fläche entspricht also den Portierungskosten auf eine komplett neue und andere Um- gebung.

Abb. 1

Entsprechend diesem Diagramm kann man jetzt auch ein Anforderungsprofil zeichnen, in dem festgehalten wird, wie wichtig für jeden einzelnen Aspekt die Unabhängigkeit bzw. Portierbarkeit ist.

Bei dem Entwurf eines Programms ist den unterschiedli- chen Aspekten der Portabilität von vornherein genügend Auf- merksamkeit zu schenken. Folgende Fragen müssen geklärt werden :

1. Auf welche möglichen Zielsysteme / Zielkonfigura- tionen soll das Programm später portiert werden ?
2. Von welchen Umgebungskomponenten soll das Pro- gramm unabhängig sein bzw. von welchen Komponen- ten darf ggf. eine Abhängigkeit bestehen ?
3. Welche verfügbaren Module sollen für das Programm benutzt werden und welche Funktionsbereiche wer- den selber programmiert ?

Frage 1 :

Wenn die Zielsysteme einer möglichen Portierung be- kannt sind, kann die spätere Portierung schon bei der Pro- grammerstellung gezielt vorbereitet werden. Dazu werden zunächst die Unterschiede der Zielsysteme untersucht und festgehalten. Anschließend ist bei der Programmierung sorg- sam darauf zu achten, daß die Unterschiede entweder gar nicht tangiert werden, oder mindestens softwaretechnisch abgekapselt werden.

Diese Kapselung wäre im Idealfall ein Modul; denkbar ist aber auch das Konzentrieren der betroffenen Anweisungen an einer eingegrenzten Stelle im Quelltext, oder die textu- elle Auslagerung in eine Include-Datei.

Frage 2 :

Die Frage nach den Komponenten ist eng verbunden mit der ersten Frage nach den möglichen Zielsystemen. Von einer Komponente, die auf allen Zielsystemen vorhanden ist, kann man sich abhängig machen, ohne Portabilität in Richtung auf die Zielsysteme zu verlieren. Es ist aber dennoch eine ei- genständige Entscheidung, sich auf Dauer an eine bestimmte Komponente - sei sie auch noch so verbreitet - zu binden, oder sich auch hier unabhängig zu halten.

Frage 3 :

Einer der scheinbar einfachsten Wege, herstellerunab- hängig zu sein, ist die Eigenprogrammierung der benötigten Module. Aber in Wirklichkeit macht man sich dadurch nur von sich selbst abhängig, da die Erstellung und Portierung des Moduls einen erheblichen eigenständigen Aufwand erfordern kann.

Hier ist eine Abschätzung erforderlich zwischen den Kosten der Module (und deren Verbreitung) einerseits und den Kosten einer Eigenimplementierung andererseits. Als Ko- sten treten dabei sowohl Kauf-/Implementierungskosten als auch die Kosten einer etwaigen Portierung auf.

4.1 Portabilität und andere Entwicklungsziele

Die Bestrebungen nach Portabilität tangieren auch an- dere Entwicklungsziele und Qualitätsmerkmale⁵. So steht eine hohe Portabilität im Widerspruch zu einer optimalen Performance, da auf der einen Seite Systemunterschiede be- wußt nicht benutzt werden, zur Erzielung optimaler Laufzei- ten aber das Ausnutzen von diesen Unterschieden wichtig ist. Ein möglicher Ansatzpunkt, hier einen Kompromiß zu finden, wird im Folgenden aufgezeigt.

Größere Programme benutzen in der Regel nicht nur die Hardware als extern hergestelltes "Teil", sondern auch un- terschiedliche Bibliotheken von Standardsoftware. Dazu ge- hören im vorliegenden Fall Grafik- und Datenbanksoftware. In dieser Standardsoftware liegt der Schlüssel zu Effizienz und Portabilität. Da diese Bibliotheken eine wesentlich hö- herere Verbreitung erzielen als spezielle Anwendungs- programme, lohnt es sich für die Hersteller dieser Software eher, speziell angepaßte Versionen für die optimale Aus- nutzung unterschiedlicher Hardware zu entwickeln. Auf der Ebene des Anwendungsprogramms muß zur Erhaltung der Porta- bilität nur noch sichergestellt werden, daß die benutzte Software auf hinreichend vielen Rechnersystemem verfügbar ist, bzw. daß das Programm bezüglich dieser benutzten Soft- ware leicht änderbar ist.

Andere Ansätze zur Erreichung hoher Portabilität ver- nachlässigen die Erfordernisse guter Effizienz teilweise erheblich. So ist auch der Versuch zu verstehen, einen ei- genen allgemeinen Modul zur Erledigung der nötigen Aufgaben zu schreiben, welcher seinerseits dann Standardsoftware be- nutzt. Die Vorteile liegen auf der Hand: dieser Modul kann in mehreren Programmen verwendet werden und bei Portierun- gen genügen Änderungen im entsprechenden Modul.

Dieses Verfahren birgt allerdings beträchtliche Nach- teile. So erfordert schon die Entwicklung dieses allgemei- nen Moduls mehr Aufwand als eine einfache aufgabenspezifi- sche Schnittstelle. Dieser Aufwand rentiert sich nur dann, wenn der Modul wirklich in mehreren unterschiedlichen Pro- grammen zum Einsatz kommt. Aufgrund des beträchtlichen Overheads durch die Allgemeinheit des Moduls wird sich die Effizienz deutlich verschlechtern und bei Portierungen muß der gesamte Umfang des Moduls portiert werden, obwohl nur jeweils ein Teil davon überhaupt benötigt wird.

Verbesserungen anderer Qualitätsmerkmale gehen zum Teil mit einer hohen Portabilität Hand in Hand. So erhöhen sich durch die klare Abgrenzung und Gliederung die Adapti- bilität⁶und die Wartbarkeit⁷.

5. Entwicklungsumgebungen für grafische Inter- aktionsformen und ihre Eignung für die spezifi- zierten Aufgaben

Im Folgenden werden beispielhaft zwei Produkte (Micro- soft Windows und X Windows) auf ihre Eignung für die spezi- fizierten Aufgaben untersucht. Obwohl beide Produkte sowohl grafische Funktionen als auch ein Fensterkonzept beinhal- ten, werden diese Bereiche hier getrennt behandelt, da es sich um völlig unterschiedliche Funktionsbereiche handelt. Es gibt Grafikbibliotheken, die keinerlei Fensterfunktionen beinhalten (z.B. Grafik aus No Limit⁸) und es sind fenster- orientierte Systeme denkbar, die nur mit zeichenorientier- ter Grafik arbeiten, also ohne Grafik im eigentlichen Sinne auskommen. Darüberhinaus sollten unterschiedliche Funk- tionsbereiche auch aus Gründen für eine Verbesserung der Portierbarkeit durch eine übersichtliche Modularisierung hier getrennt untersucht werden.

5.1 Grafische Bibliotheken

Der grafische Teil von MS-Windows bzw. X Windows ist eine Programmbibliothek im klassischen Sinn, d.h. eine Sammlung von Unterprogrammen, welche grafische Ausgaben auf Bildschirm und anderen Medien unterstützen. An dieser Stelle werden zum einen beide Produkte auf ihre Eignung für die grafischen Aufgaben des zu behandelnden Problems unter- sucht, zum anderen werden hier auch schon Erkenntnisse ge- sammelt für die portable Implementation. Funktionen, die sich als spezielle Eigenheiten eines Produktes heraus- stellen, sollten dabei für die Implementation nicht genutzt werden, da sich daraus bei späteren Portierungen Probleme bzw. zusätzlicher vermeidbarer Aufwand ergeben.

Die grafischen Anforderungen, die eine Kapazitätsdis- position stellt, sind im Vergleich zu anderen grafischen Programmen (z.B. CAD) gering. Für ein Kapazitätsgebirge müssen Blöcke unterschiedlicher Farbe bzw. Schraffur, ein Skalenkreuz mit Beschriftung und die Linie der verfügbaren Kapazität dargestellt werden. Für die Manipulation der Dar- stellung muß ein pointing device wie z.B. eine Maus unter- stützt werden. Diese Anforderungen sollten von jeder Gra- fikbibliothek abgedeckt werden können.

Weitere Aspekte für die Eignung ergeben sich aus dem interaktiven Charakter des Programms und der Absicht, mög- lichst leicht portierbar zu sein. Die Geschwindigkeit der grafischen Operationen sollte hinreichend groß sein, um die Akzeptanz beim Anwender zu erhöhen, bzw. überhaupt erst zu ermöglichen. Wenn der Anwender die Enstehung der Grafik be- quem mit dem Auge verfolgen kann, so wird schnell beim Ar- beiten ein schädliches Ungeduldsgefühl entstehen. Das wird dazu führen, daß in hektischen Situationen eher ohne den Computer und am Computer vorbei geplant wird. Das aber würde den Einsatz des Programms konterkarieren, da es ja gerade die Produktivität eines Sachbearbeiters quantitativ erhöhen und qualitativ verbessern soll.

Um das Ziel der guten Portierbarkeit zu erreichen, kann man insbesondere auch auf eine hohe Verbreitung der benutzten Bibliothek achten. Wenn für die neue Zielmaschine die benutzte Grafikbibliothek existiert, liegt es auf der Hand, daß es einfacher ist, für die neue Zielmaschine die identische Grafiksoftware zu beschaffen, als das Programm an eine andere Grafiksoftware anzupassen. Daher muß in eine Beurteilung der Eignung auch die derzeitige Verbreitung und eine Einschätzung über die zukünftige Verbreitung - auch auf neuer Hardware - eingehen.

5.1.1 MS-Windows

Der oben erwähnte geringe benötigte Funktionsumfang ist in der Grafikbibliothek von MS-Windows vollständig ent- halten⁹.

MS-Windows stellt zum Zeichnen unterschiedliche Abstraktionsebenen zur Verfügung. Auf der einfachsten Ebene wird in Pixeln auf Basis der realen Bildschirmgröße ge- zeichnet. Der Ursprung des Koordinatensystems befindet sich dabei in der linken oberen Fensterecke. Es kann auch eine Zeichenfläche definiert werden, aus der ein kleiner, ver- schiebbarer Ausschnitt auf dem Bildschirm dargestellt wird. Zusätzlich kann auch ein beliebiger Maßstab statt der Pixel benutzt werden.

Farben und Schraffierungen können frei gewählt, die Schraffierungen auch vom Benutzerprogramm frei definiert werden. Sie werden für einen bestimmten Zeichenbereich aus- gewählt und gelten dann für alle folgenden Zeichenoperatio- nen.

Die Zeichengeschwindigkeit von MS-Windows wurde mit einfachen Beispielprogrammen getestet und kann als durchaus zufriedenstellend angesehen werden. Insbesondere das Füllen von Flächen, welches sich bei anderen PC-Grafikprogrammen als unangenehm langsam erwiesen hat (z.B. die Füllfunktion aus der No Limit¹⁰Bibliothek), ergibt hier keine merklichen Verzögerungen mehr.

MS-Windows läuft unter MS-DOS auf allen IBM-kompati- blen Personalcomputern. Zumindest für den kommerziellen Be- reich bedeutet das, daß MS-Windows für fast alle instal- lierten Personalcomputer erhältlich ist. Dadurch bräuchte man nur für die PC-Welt keinerlei Überlegungen bezüglich Portierung anstellen. Auch die Zukunft von MS-Windows er- scheint sicher, da Microsoft eng mit IBM zusammenarbeitet und daher als Marktführer auf dem PC-Softwaremarkt einzu- stufen ist. MS-Windows wird ständig weiterentwickelt und auch für neue Prozessoren für eine optimale Leistungs- fähigkeit angepaßt¹¹. Auch das neue Betriebssystem für die IBM PS/2 Serie (BS/2 bzw. OS/2) enthält eine von Microsoft entwickelte Window-Software (Presentation Manager), die sehr eng an MS-Windows angelehnt ist.

5.1.2 X Windows

Der oben erwähnte geringe benötigte Funktionsumfang ist auch in der Grafikbibliothek von X Windows vollständig enthalten¹².

In X Windows werden alle Maße ausschließlich in Pixel angegeben. Der Ursprung des Koordinatensystems liegt in der linken oberen Ecke des definierten Fensters. Andere ge- wünschte Koordinatensysteme müssen in X Windows vom Anwen- dungsprogramm realisiert werden.

Wie in MS-Windows so können auch in X Windows Farben und Schraffierungen definiert und für einen bestimmten Zei- chenbereich ausgewählt werden. Die Vorgehensweise dafür ist in X Windows etwas komplizierter aber dennoch prinzipiell gleich.

Die Arbeitsgeschwindigkeit der Grafik in X Windows konnte nicht eingehend untersucht werden, da keine Version des Programms zur Verfügung stand. Da aber zum Beispiel die Grafiksoftware der SUN Workstations - unter anderem für den CAD Einsatz - auf X Windows basiert, besteht ein berech- tigter Grund für die Annahme, daß die Geschwindigkeit für die hier geforderten Zwecke zumindest ausreichend ist.

X Windows ist ein Fenstersystem, das extra als Stan- dard herstellerunabhängig konzipiert worden ist. Alle nam- haften Rechnerhersteller im UNIX-Bereich (HP, DEC, SUN, Apollo, etc.) arbeiten inzwischen an der Weiterentwicklung von X Windows mit. Damit erscheint die Zukunft zumindest im UNIX-Bereich sicher. Auch PC-Implementationen von X Windows sind inzwischen erhältlich, so daß man davon ausgehen kann, daß eine Implementation auf Basis von X Windows bezüglich möglicher Portierungen keine falsche Entscheidung ist.

5.2 Window-Systeme

Das Fenstersystem von MS-Windows bzw. X/Windows kann man nicht nur als Programmbibliothek begreifen. Zum einen werden hier Funktionen angeboten, mit deren Hilfe sich die Fenster anzeigen, verschieben oder löschen lassen, zum an- deren wird aber für das Fensterkonzept eine neue Kontroll- flußphilosophie benutzt.

Die Betrachtungen hinsichtlich der Verbreitung und ab- sehbaren Zukunft der beiden Produkte wurden schon im vori- gen Kapitel angestellt und werden hier nicht wiederholt.

Sie sind selbstverständlich auch für die hier besprochenen Fensterkomponenten von X Windows und MS-Windows gültig.

5.2.1 MS-Windows

Programme in MS-Windows besitzen eine Kontrollfluß- strategie, die von MS-Windows vorgegeben wird. Der Pro- grammablauf wird auf der oberen Ebene durch Ereignisse ge- steuert, die entweder von außen kommen (beispielsweise Ta- statureingaben oder Mausbewegungen) oder vom Programm sel- ber generiert werden. Dies geschieht in einer Warteschlei- fe, in der das Hauptprogramm auf Ereignisse wartet. Bei Eintreten eines beliebigen Ereignisses wird es vom Haupt- programm aus auf Unterprogramme verteilt, die für jedes Fenster einzeln definiert diese Ereignisse behandeln. Die Reaktionen auf diese Ereignisse werden dann in her- kömmlicher Art und Weise prozedural formuliert.

Benutzereingaben erfolgen innerhalb von MS-Windows über Maus oder Tastatur und sind immer einem bestimmten Fenster zugeordnet. Eine besondere Möglichkeit, Benut- zereingaben zu machen, bieten die Menüs. Sie werden vom Programmierer definiert und erzeugen spezielle Ereignisse, wenn sie vom Benutzer angewählt werden. Auf diese Art und Weise läßt sich einfach eine komfortable Benutzeroberfläche programmieren.

Zusätzlich zum üblichen Quellcode benötigt MS-Windows noch eine Datei in der die Fensterarten und -größen und die Menüs definiert werden. Die hierin enthaltenen Informatio- nen werden von einem speziellen Ressourcecompiler übersetzt und beim Linken zum eigentlichen Programm hinzugefügt.

5.2.2 X Windows

Auch X Windows besitzt wie MS-Windows eine ereignisge- steuerte Kontrollflußphilosophie. Die Verarbeitung der Er- eignisse erfolgt wie beim Microsoft Produkt im Hauptpro- gramm in einer Ereigniswarteschlange, die die Ereignisse dann weitergibt an die bearbeitenden Funktionen.

Alle Eingaben von Tastatur und Maus sind diesem Kon- zept zufolge Ereignisse. Etwas komplizierter ist in

X Windows die Behandlung von Menüs. Die Menüs sind bewußt aus X Windows ausgeklammert worden und bilden eine Aufgabe für den sogenannten Window Manager. Dieser Window Manager kann sich bei verschiedenen Implementationen von X Windows unterscheiden und so Ursache für notwendige Änderungen bei Portierungen sein. Allerdings wird ein einfacher Beispiel- Window Manager mitgeliefert (uwm¹³).

5.3 Resümee

Beide Produkte sind für die beabsichtigten Zwecke offensichtlich gut geeignet. Auf Personalcomputern besitzt MS-Windows mindestens zur Zeit noch Vorteile durch die hö- here Verbreitung und die Erfahrungen, die mit dieser Soft- ware schon gemacht wurden.

Dies kann in Zukunft anders aussehen, wenn die Mög- lichkeiten der erheblich einfacheren Portierung vom PC auf UNIX-Systeme und umgekehrt durch Benutzung von X Windows an Bedeutung zunimmt und X Windows dadurch auf PC-Ebene eine höhere Verbreitung erfährt.

Ein Nachteil von X Windows bezüglich hoher Portabili- tät ist sicherlich das Fehlen eines standardisierten Window Managers. Dies kann nur durch sorgfältige Programmierung abgefangen werden, in dem man das Programm auf den Einsatz mit beliebigen Window Managern vorbereitet.

6. Beschreibung der Implementierung

6.1 Auswahl der Umgebung

Das Programm wurde auf einem MCI-AT04 und einem IBM PS/2 Modell 80 implementiert. Die zugrundeliegende Soft- wareumgebung besteht aus dem Betriebssystem MS-DOS 3.3, dem Datenbanksystem ORACLE, dem Fenstersystem MS-Windows und der Programmiersprache C (Compiler von Microsoft, Version 5.1).

Die Hardware ergibt sich aus der Ausstattung des Lehr- stuhls für Wirtschaftsinformatik. Die Entscheidung für MS- Windows und MS-DOS fiel aus praktischen Gründen der Verfüg- barkeit. Zu Beginn dieser Arbeit war X Windows noch nicht am Lehrstuhl verfügbar. Durch die Entscheidung für MS-Win- dows ist dann auch die Entscheidung für MS-DOS vorgezeich- net, da andere Implementationen von MS-Windows nicht vor- liegen und auch nicht angekündigt sind.

Die Entscheidung für das Datenbanksystem ORACLE hat im Wesentlichen zwei Gründe. Erstens ist ORACLE mit der glei- chen Schnittstelle (bei steigendem Leistungsumfang) vom PC bis zum Mainframe erhältlich. Zudem erfolgen die ORACLE- Aufrufe in der standardisierten Abfragesprache SQL. Für eine spätere Portierbarkeit bietet diese Eigenschaft beste Vorraussetzungen. Zweitens ist das Datenbanksystem ORACLE Grundlage für das am Lehrstuhl für Wirtschaftsinformatik entwickelte PPS-System, dessen Datenbank die erste Arbeits- grundlage für die Kapazitätsdisposition darstellt.

Die Wahl der Programmiersprache C begründet sich in vielen unterschiedlichen Aspekten. Zunächst spielen wieder Überlegungen zur Portabilität eine Rolle. Die Sprache C ist heute auf fast allen Rechnern verfügbar und wird das in ab- sehbarer Zukunft vermutlich auch bleiben. C ist Implemen- tierungssprache für das Betriebssystem UNIX und partizi- piert aus diesem Grund an dem Aufschwung von UNIX. Zudem ist C wegen des geringen Sprachumfangs sowohl leicht zu lernen als auch leicht zu implementieren. Einzig Mängel in der Klarheit des Quellcodes und im Modularisierungskonzept sprechen gegen C; diese sind aber durch disziplinierte Programmierung in den Griff zu bekommen.

Weitere Gründe für die Verwendung von C liegen in den Schnittstellen zu verschiedenen Softwarebibliotheken. Für keine Sprache gibt es im PC- und UNIX-Bereich eine derart große Auswahl an Bibliotheken. Das verwendete Datenbanksy- stem ORACLE und auch beide Windowsysteme haben C-Schnitt- stellen, so daß die logische Wahl auf diese Programmier- sprache fällt.

6.2 Modularisierung

Die vollständige Aufgabe muß zu Beginn in Teilaufgaben zur vernünftigen Modularisierung zerlegt werden. Dabei spielen einerseits die Überlegungen zur Portabilität eine Rolle, d.h. Berührungspunkte zu benutzten Softwarebiblio- theken sollten möglichst lokal innerhalbs eines Moduls auf- treten. Das bedeutet für die Modularisierung eine Modulein- teilung nach benutzter Software. Andererseits sollte sich die Modularisierung auch immer nach den Aufgaben richten, die innerhalb eines Moduls bearbeitet werden. Das wäre eine Moduleinteilung nach der Leistung der Software.

Glücklicherweise widersprechen sich diese beiden Kon- zepte zur Moduleinteilung nicht, sondern sie ergänzen sich gegenseitig. Wichtig ist, in diesem Zusammenhang noch ein- mal an die grundsätzliche Zweiteilung der Aufgaben von MS- Windows zu erinnern: auf der einen Seite sind die grafi- schen Funktionen zu sehen, und auf der anderen Seite, ge- trennt von der Grafik, die Fensterverwaltung und Ereignis- steuerung.

Aufgrund der oben angeführten Überlegungen wird die Gesamtaufgabe auf folgende Module verteilt :

- KAP_PLAN Hauptprogramm
- PAINT Zeichenfunktionen
- DB_SQL Datenbankaufrufe
- DATEN Aufbereitung der Datenbankwerte

Die Module KAP_PLAN, DB_SQL und DATEN werden als ge- trennt zu übersetzende C-Module realisiert. Bei dem Modul PAINT wird beispielhaft aufgezeigt, wie eine Modularisie- rung auch durch Aufteilung in Include-Dateien erfolgen kann. Durch die Einschachtelung von PAINT in das Hauptpro- gramm KAP_PLAN wird gleichzeitig erreicht, daß sich das ge- samte Windowsystem inclusive Grafik aus der Sicht des Com- pilers auf einen Modul beschränkt.

Extern benutzte Software ist einmal das Datenbanksy- stem ORACLE und das Fenstersystem MS-Windows. Ein weiterer externer Modul ist die Terminierung. Die Funktionen zur Terminierung gehören nicht in den Rahmen dieser Diplomar- beit.

Bei den Modulschnittstellen muß auf eine aufgabenad- äquate Definition geachtet werden. Das bedeutet z.B. für die Datenbankfunktionen, daß nicht nur um jeden Daten- bankaufruf eine neue Prozedurkapsel geschrieben wird, um für andere Programmteile unabhängig von der speziellen Da- tenbanksoftware zu werden. Vielmehr wird mit den Prozeduren und Datenstrukturen der Schnittstelle eine neue, ganz spe- ziell auf die Aufgabe zugeschnittene Sicht auf die Daten- bank definiert. Durch die reduzierte Anzahl der Pro- zeduraufrufe wegen des speziellen Zuschnitts der Modul- schnittstelle erhält man eine bessere Effizienz. Denn ge- rade Prozeduraufrufe kosten in der Regel viel Prozessorzeit (Kontextwechsel etc.). Die Vorteile der Modularisierung be- züglich der Portabilität bleiben dennoch erhalten.

6.3 Vorgehensweise

Zunächst wurde die grafische Darstellung des Kapazi- tätsgebirges implementiert. Dafür wurde eine Dummyversion des Datenbankzugriffsmoduls geschrieben, um die grafische Darstellung unabhängig von eventuellen Fehlern in der Da- tenbank schreiben und testen zu können.

Für die Daten, die in der Darstellung des Kapazitäts- gebirges benötigt werden, wurde eine umfassende Datenstruk- tur implementiert¹⁴. Durch Übergabe von einem einzelnen Zeiger auf diese Struktur werden die Funktionsaufrufe für die Grafikfunktionen optimiert.

Noch ohne die Datenbank wurde die Geschwindigkeit der einzelnen zeichnenden Funktionen getestet. Wo es notwendig war, wurden Datenstrukturen verbessert und Algorithmen um- gestellt oder verändert, bis die Performance der Grafik zu- friedenstellend war. Anschließend wurden auch die Daten- bankfunktionen aus dem Modul DB_SQL eingebunden und das Ge- samtsystem getestet.

Um während der Implementierung bei auftretenden Feh- lern die im Programm durchlaufenen Pfade an kritischen Stellen feststellen zu können, wurden Testhilfeausgaben auf die logische Datei stddbg eingefügt. Die Übersetzung dieser Testhilfen kann durch Anweisungen an den C-Preprozessor ge- steuert werden, so daß diese Testhilfen das fertige Pro- gramm später nicht belasten.

Die Arbeit mit MS-Windows und ORACLE hat bis an die Grenzen der Belastbarkeit des Betriebssystems geführt. Nach Reduktion des Platzbedarfes für das Datensegment durch Aus- lagern von größeren Variablen in eigene Segmente mit Hilfe einer Option im C-Compiler und der Einführung der neuesten Version des Windows-Development-Toolkits (Version 2.1) wa- ren die Speicherprobleme aber behoben.

[...]

---

¹ s. Kurbel 1983, S.12

² vgl. Kurbel 1983, S.82,83

³ Im vorhandenen PPS-System handelt es sich um den frühesten und spätesten Start- und Endtermin

⁴ vgl. Balzert 1982, S.12 u. Kurbel 1983 S.112

⁵ vgl. Kurbel 1983, S.132,141

⁶ vgl. Kurbel 1983, S.134

⁷ vgl. Kurbel 1983, S.141

⁸ vgl. MEF Environmental 1986, S.12-25

⁹ vgl. Microsoft 1985

¹⁰ MEF Environmental 1986

¹¹ vgl. Duncan 1988

¹² vgl. Nye 1988

¹³ vgl. Nye 1988, S.5 u. Gancarz 1986

¹⁴ s. Quelltext (KAP_PLAN.H, Zl.137 ff.)