Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.11.1981 - 

CSE-CW-Symposium diskutiert aktuelle Fragen zur Software-Produktion:

Tooldefizit und Systemkrise der Software

MÜNCHEN (hh) - Über eine Steigerung der Programmiereffektivität durch den Einsatz einer "High Level Language" und Probleme des Einsatzes von Tools und Methoden informierten sich die Teilnehmer des Symposiums Software '81 in München. In der Ausgabe 45/81 Seite 8 berichtete die COMPUTERWOCHE über den ersten Teil der Veranstaltung, der sich mit dem Software-Markt und der Ausbildung befaßte. In dieser Folge nun stehen Programmiersprachen und die Software-Produktionsumgebung zur Diskussion. Die Erhöhung der Programmierproduktivität im Systembereich erfordert eine effiziente Programmiersprache, die verschiedenen Anforderungen genügen muß - so lautete die Begründung von Kurt Harders zur Entscheidung, in seinem Hause Pascal bei der Systemprogrammierung einzusetzen. Die Anforderungen, die die Dietz Computer Systeme, Mühlheim/Ruhr, an eine Programmiersprache stellt, sind: - Problemlose Darstellung der benötigten Datenstrukturen und Algorithmen

- Überschaubarkeit des erzeugten Codes, - Generierung effektiven Codes, ohne die erste Bedingung zu verletzen.

Zu diesen Punkten addieren sich jedoch noch einige pragmatische Aspekte wie die Verfügbarkeit eines lauffähigen Compilers, die einfache Wartung und Veränderung des Compilers und die Lauffähigkeit auf eigenen Systemen, meint der Redner.

Obwohl bis heute im Systembereich Assembler dominiere, habe sich das Haus Dietz für den Einsatz von Pascal entschieden. Wesentliche Spracheigenschaften dieser "High Level Language" seien die sehr flexiblen Datentypen, die Verfügbarkeit der Pointenvariablen, die sprachimmanente Anpassung der Darstellung an die Maschinenstruktur und die maschinenunabhängige, formal klare Bitverarbeitung, erläuterte Harders. Dazu summiere sich die Abbildbarkeit der Entwurfsstufen durch Prozeduren und die problemlose Verwendung rekursiver Algorithmen. Die Summe dieser Eigenschaften habe trotz der Beibehaltung eines in Assembler implementierten Betriebssystems zur fast vollständigen Verdrängung dieser Sprache geführt.

Auch traten, so Harders, bei Einsatz beider Sprachen auf Grund bestehender Systemkonventionen keine sprachbedingten Schnittstellenprobleme auf. Nach kurzem Überblick über die Eigenschaften des Übersetzers zieht Harders Bilanz: Die Erfahrungen aus der Anwendung von Pascal zeigten Auswirkungen auf den Lebenszyklus in Form einer kurzen Implementierungszeit, hoher Produktqualität und geringerem Pflegeaufwand.

Systemkorsett

Auf die Frage, ob die Programmiersprache ein Systemkorsett darstelle, ging George Brooke, Direktor der Pentacom Computer Systeme GmbH, München, ein. Nach einem Überblick über die Entwicklung der verschiedenen Programmiersprachen kam Brooke auf die Vorzüge einer "High Level Language" (HLL) zu sprechen. Diese liegen in der Zuverlässigkeit, der Entwicklungsfähigkeit, der Produktivität und der Portabilität. Warum nun, fragte Brooke, ist Assembler noch in Gebrauch, liegen doch die Nachteile wie geringe Effektivität oder Schnittstellenprobleme auf der Hand?

Für ihn gibt es zwei Gründe: technische Probleme, die sich bei dem Einsatz einer HLL ergeben und psychologische Gründe, die auf ein Festhalten an Bewährtem beharren.

Frühzeitiges Training

Um dieses Problem zu überwinden bedarf es nach Meinung des Vortragenden eines möglichst umfassenden, frühzeitigen Trainings der High Level Languages. Unterstützung,

technische Dokumentation und der Einsatz von Tools sind genauso wichtig wie Tuning-Hilfen. Dennoch möchte Brooke den Einsatz von Assembler nicht verdammen. Für ihn ist immer noch die spezielle Problemstellung der Angelpunkt für die Entscheidung, jedoch, so meint er, solle man auch bei dem Einsatz von Assembler parallel den Einsatz von High Level Languages vorbereiten.

Auf ein überall diskutiertes Thema ging Robert L. Glass, Präsident der Boeing Computer Services aus Seattle, USA, ein: Ada. Kernfrage ist ob Ada-Programmierer bessere Software produzieren werden. Seine Antwort lautet: "Ja", aber nach einem schweren Start. Die Sprache wurde Mitte der siebziger Jahre vom amerikanischen Department

of Defense (DoD) ins Leben gerufen war beabsichtigt, den Sprachen-Wirrwarr innerhalb der

Streitkräfte aufzulösen. So hat die Luftwaffe verschiedene Versionen von "Jovial" eingesetzt,

die Marine "CMS-2" und "SPL/1" und die Armee "Tacpol".

Obwohl einige Unternehmen bemühen, liegt die Schwierigkeit momentan noch bei der Entwicklung eines leistungsfähigen Compilers. Die Zukunft dieser Sprache wird nicht zuletzt von diesem technischen Problem beeinflußt. Nach Meinung von Glass bestimmt auch die Qualität der Dokumentation und des Lehrmaterials die zukünftige Akzeptanz von Ada und die Frage, ob der weltweite Enthusiasmus erhalten bleibt. Sicher ist ihm, daß diese Sprache Cobol und Fortran nicht ersetzen wird.

Die Computerunterstützte Systementwicklung und Dokumentation (CDS) stellte Wolfgang Hinze, Abteilungsleiter Organisation der Datev Nürnberg vor. Die Datenverarbeitungsorganisation der steuerberatenden Berufe hat sich als Ziel gesetzt, effiziente, transparente und personenunabhängige Systeme zu entwickeln. Als primäre Qualitätsmerkmale sieht Hinze den Funktionsumfang, die Benutzerfreundlichkeit, die Effizienz, Portabilität und Zuverlässigkeit an. Sekundär stuft er die Schulung, die Beratung und Unterstützung, Konvertierungshilfen und eine Gewähr für Wartung und Weiterentwicklung ein. Diese Merkmale möchte der Redner in der Organisation der Systementwicklung verwirklicht sehen. Dazu trägt in der Organisation der Sachmittel , von dem folgende Komponenten zur Verfügung stehen oder in Arbeit sind:

- eine Methodendatei mit Informationen für die Systementwickler

- Service-Funktionen zur projektbegleitenden Dokumentation,

- ein Tool-Verbund der bei der Datev zur Verfügung stehenden Hilfsmittel,

- ein Auftrags- und Projektsteuerungssystem mit der Bereitstellung von Informationen über Termine, Zeiten und Kosten.

Die Erfahrung zeige, so Hinze, daß nur das aufeinander abgestimmte Zusammenspiel aller organisatorischen Komponenten zum wirksamen , Einsatz eines CSD-Systems führe und damit eine höhere Effizienz gewährleistet sei.

"Sind Software-Tools Werkzeuge für mehr Produktivität oder unnötiger Ballast", fragt Dr. Reinhold Thurner, Geschäftsführer der Sodecon AG, Schwerzenbach/Schweiz. Eine Software-Lücke wird seiner Meinung nach durch die zunehmenden Anforderungen des Anwenders einerseits, durch die wachsende Komplexität bestehender Systeme andererseits hervorgerufen.

Hier seien Tools eine Möglichkeit, dieses Gap zu schließen, jedoch müssen sie vier Anforderungen genügen:

- die Tools sollen sich für die zu erstellenden Produkte eignen,

- sie sollen für den Anwender beherrschbar sein,

- sie sollen den Produktionsprozeß verbessern und

- das Produktionsverfahren effizienter gestalten.

Wichtigste Aufgabe eines Tools ist es, Methoden zur Software-Entwicklung zu unterstützen. Dabei machte Thurner die Erfahrung, daß mit Tools entwickelte Systeme leichter zu warten und stabiler seien.

Die abschließende Frage lautet seiner Meinung nach nicht "Tools - ja oder nein, sondern welches Tool für welches Projekt erforderlich sei.

Der technologische Stand eines Tools müsse dem Stand des Produktes entsprechen. Das bedeute, so Thurner, daß integrierte umfangreiche Systeme auch stärker integrierte Tools erfordern.

"Weg vom Methodenberg - unter diesem Thema stellte Dr. Herbert Neumaier, Abteilungsleiter der Softlab AG, München, das Produkt S/E/ TEC vor. Das System von Methoden Verfahren und Werkzeugen. setzt sich aus sieben Komponenten zusammen, die streng zusammenarbeiten und den Software-Entwickler durch die verschiedenen Projektphasen leiten.

Gründe für die Entstehung des Methodenberges der durch das Produkt abgebaut werden soll, sieht Neumaier in der Unzulänglichkeit der angewandten Methoden, die nach immer neuen Methoden riefen und einem grundsätzlichen Bedarf. Die Methoden fesselten, so Neumaier, die Funktionen, die Software biete, an deren datentechnische Konstruktion.

Die Entrümpelung des Methodenberges bestehe nur darin, allen Methoden zu entsagen, die sich in der Bereitstellung der Funktionen nicht losreißen können von den zugrundeliegenden Datenstrukturen. Ein Kleben an diesen Strukturen führe, meint Neumaier, zum Chaos in den Dateizugriffen. Dieses Chaos versuche man mit neuen Verfahren zu bewältigen, wodurch man letztendlich zu einem Methodenberg gelange. Er plädiert dafür, die Daten von ihrer Repräsentation zu abstrahieren und die Funktionen um im Gebrauch verwandte Daten zu gruppieren.

Informationen über die umfassende Dokumentation: CSE-CW Sekretariat Suse Weber, Friedrichstr. 31, 8000 München 40, Telefon: 0 89/34 90 61.