> SSE
> Anhang
> Historisches
|
> SSE
> Anhang
> Historisches
|
|
||
|
"There is no reason anyone would want a computer in their home." Historisches
1970 1971 1972 1973
1974
1975
1976
1977
1978
1979
|
|
Die meisten Softwareentwickler haben genug Stress mit ihren heutigen Problemen und Projekten und vor allem mit der raschen Weiterentwicklung der IT. Daher ist das Interesse an der Historie der IT allgemein recht gering, erst Recht das Interesse an der Historie der systematischen Softwareentwicklung. Deshalb habe ich mich entschlossen, diesen Teil nur kurz und nur im Anhang darzustellen. |
|
Außerdem will ich mich auf die Softwareentwicklung mit PCs konzentrieren, zum einen weil heutzutage wohl mindestens 90% der Software mit PCs entwickelt wird, zum anderen weil ich in dieser Abhandlung ja die Praxis aus meiner Erfahrung heraus schildern will und ich nur die Softwareentwicklung mit PCs von Anfang an kennen gelernt habe. Es gibt aber im Internet genug Berichte über die wirklich alten Zeiten der EDV mit Zuse, Nixdorf, IBM, DEC, etc. Die Suchmaschinen bringen Sie über diese Stichwörter schnell weiter. 1974 entwickelten Kernighan und Ritchie die Programmiersprache "C", die dem PC zum Siegeszug verhelfen sollte - aber zu der Zeit gab es noch keinen PC! 1975 kam mit dem Bausatz des Altair 8800 das erste Ding, was man PC nennen könnte. Dafür entwickelten ja auch Bill Gates und Paul Allen das BASIC - aber da hieß die Firma noch Traf-O-Data. Das zu der Zeit mit einem Computer prinzipiell auch schon viel mehr möglich war, zeigte XEROX im PARC mit einem graphischen Texteditor, der über eine Maus gesteuert wurde! 1976 bauen Steve Wozniak und Steve Jobs den Apple I. HP und Atari interessierten sich auch schon irgendwie für das neue Zeugs. Wo wir mit den PCs 1977 aber realistisch standen, können Sie ganz gut an dem Spruch oben auf dieser Seite erkennen.
Die einzige Alternative auf Mikrocomputern war zu der Zeit Assembler für Prozessoren wie den Motorola 6502 (Apple und Commodore), die Intel 8008, 8080, 8085 oder den Zilog Z80. Dazu brauchte man aber Informationen über die Hardware, die vom Hersteller super geheim gehalten wurde. Ich erinnere mich, dass ich von meinem ersten selbst verdienten Geld einem Mitarbeiter des Computerherstellers sein Systemhandbuch abgekauft habe, auf dem dick so witzige Sprüche wie "nur zum internen Gebrauch" aufgestempelt waren.
|
Die damals im normalen Buchhandel in deutsch verfügbaren Bücher für Mikrocomputer bestanden aus schrecklichen Listings noch schrecklicherer Programme und enthielten wenig wirklich spannende Infos. Aber es war halt eine Zeit, wo man sogar noch den gesamten Markt überschauen konnte und eigentlich alles gegriffen hat, was irgendwie verfügbar war - ich zumindest. Alles, was nicht für Mikrocomputer geschrieben wurde, war sofort super wissenschaftlich aufgezogen, sehr kompliziert und teuer und obendrein auf dem Mikrocomputer kaum verwendbar - also out! Es gab damals halt zwei Welten: Profis an UNIX-Maschinen und Freaks an Mikrocomputern! |
|
In der ersten Arbeitsgruppe "Informatik" auf unserem Gymnasium half uns die Frau eines Mathematikprofessors der Uni Bochum auf die Beine und erklärte uns das IF ... THEN ... ELSE und vor allem das GOTO! Denn besonders strukturiert wurde damals noch nicht programmiert. Die Auszüge links und rechts stammen aus Büchern von 1983 und 1984 und sehen immer noch nicht besonders strukturiert aus. Aber wie viele Leute nennen sich heute noch Softwareentwickler und hauen einfach den Code in die Büchse! |
|
|
Ich sah zu der Zeit in einigen Büchern Diagramme, und zwar Flussdiagramme (s. links) und Struktogramme (s. rechts) und eiferte dem nach. So hatte ich etliche einzelne Diagramme erstellt, die ich zu einem Gesamt-Flussdiagramm zusammensetzte. Ein Photo von mir vor diesem Gesamt-Flussdiagramm bei der Vorstellung meiner Forschungsarbeit Anfang 1981 finden Sie ganz am Ende meiner Projektreferenz auf meiner Homepage. |
|
|
Die Darstellung oben aus einem CP/M-Buch ist die Einleitung zur Programmierung. Es sieht so aus, als müsste man nur wissen, wie man den ASM aufruft, und schon kann man programmieren. Als Hauptproblem war hier die Speicheradressierung genannt. Der Ausschnitt rechts zeigt das nächste Kapitel, in dem immerhin darauf hingewiesen wird, wie wichtig doch die Fehlerbehebung ist. Mich erinnert das etwas an den Spruch: "Wenn Debugging der Vorgang ist, Fehler auszubauen, dann ist Programmieren wohl der Vorgang, Fehler einzubauen." |
|
"The role that an operating system may play in managing a multitasking execution environment depends on the nature of the application. Applications can be classified according to the volatility of tasks executing over a period of time. Applications in which tasks frequently begin and end are called dynamic systems. Applications in which the mix of tasks does not change are called static systems." (dt.: Die Rolle, die ein Betriebssystem in der Verwaltung einer Multitasking-Umgebung spielt, hängt von der Natur der Applikation ab. Applikationen können nach der Sprunghaftigkeit der Ausführung der Tasks über einen gewissen Zeitraum unterschieden werden. Applikationen, in denen die Tasks oft beginnen und enden werden dynamische Systeme genannt. Applikationen, in denen sich die Zusammensetzung der Tasks nicht verändert, werden statische Systeme genannt.) Durch die massive Segmentierung der Programme und die Berücksichtigung des Multitaskings kamen völlig neue Aspekte auf die Softwareentwicklung zu, die eine viel planerische Vorgehensweise benötigte und uns mehrere Jahre auf Trab gehalten hat. Insbesondere brauchten wir nun Ablaufdiagramme, in denen die simultanen Abläufe der Tasks darstellbar war. Selbst in der UML wurden erst 2004 mit der Version 2.0 die Aktivitätendiagramme so weit geklärt, dass sie für einen praktikablen und eindeutigen Einsatz in Multitasking- bzw. Multithreading-Umgebungen sauber einsetzbar sind.
Nachdem die hardwarenahe Programmierung mit intensivem Speichermanagement und Multitasking in Assembler kein großes Problem mehr war, kam 1985 (Mitte 84 bis Mitte 86) ein Betriebssystem für eine Speicherschreibmaschine auf mich zu, das ich mit einem Kollegen komplett in 8080 Assembler geschrieben habe. Dazu mussten wir Speicheraufteilungen, Ländervarianten-Mappings, Zustandsdiagramme, Flussdiagramme und Prozessabläufe ohne Ende entwerfen. Wir haben damals nur leider keine Tool-Unterstützung gehabt und mussten alle Diagramme von Hand auf Papier zeichnen. Selbst die Spezifikationen wurden meistens auf Papier vorgeschrieben. Das war eine Katastrophe bei den andauernden massiven Änderungen durch neue Ideen. Außerdem steckte ein riesiges Unternehmen hinter der Entwicklung, das parallel die Hardware zuende entwickelte und richtig Ahnung von Testen hatte. Es gab da tatsächlich eine Hydrostößel-Apparatur, die softwaregesteuert die ganze Nacht durch getippt hat und so regressiv alle Funktionen mit allen vorher schon einmal dagewesenen Fehlersituationen getestet hat. Das war das erste Mal, dass ich Testfälle schreiben musste (die wir damals "Featuretests" nannten). Entwickelt haben wir auf den original Intel-Entwicklungsmaschinen ISIS II und III mit ICE (In-Circuit-Emulator) zum Debuggen der EPROMs direkt in der Hardware. Das reine Code-Listing brauchte schließlich über 1000 Seiten von diesem tollen grün-linierten Endlospapier. Ohne eine gewisse Systematik hätten wir da keine Chance gehabt - aber ohne die 110-Stunden-Wochen auch nicht. Ich glaube, das war mein erstes echtes Heldenprojekt ;-)
tbc ...
|
