Normierte Programmierung - Versionsgeschichte

VÖRBY: vorher toter Link, aktualisiert

2024-02-05T15:31:16Z

vorher toter Link, aktualisiert

← Nächstältere Version		Version vom 5. Februar 2024, 17:31 Uhr
Zeile 6:		Zeile 6:
	Zur Zeit der Entstehung der normierten Programmierung Ende der 1960er Jahre für die kommerzielle [[Datenverarbeitung]] gab es lediglich Stapelprogramme: [[Sequentieller Zugriff\|sequentielle]] Dateien, in denen je nach Aufgabenstellung unterschiedliche 'Satzarten' [[Lochkartenmischer\|gemischt/hintereinander]] auftraten, weil z. B. nur eine [[Magnetband#Datenträger in der Informationstechnik\|Magnetbandstation]] oder ein [[Lochkartenleser]] für die Eingabe verfügbar war. Ein Mischen im Programm war so nicht erforderlich und wäre bei Arbeitsspeichern von z. B. 64 KB inkl. Betriebssystem auch zu aufwändig gewesen. So las das Programm 'seine' Eingabedatei und verarbeitete einen [[Datensatz]] nach dem anderen. Über ein Datenfeld 'Satzart' wurden die Datenarten (Kunde, Bestellung …) inhaltlich unterschieden und über Ordnungsbegriffe einander zugeordnet. Das Programm 'lief' (mit [[Sprunganweisung\|GOTO]]) je nach Datenkonstellation zu bestimmten Stellen, zum Beispiel zu Rechenvorgängen, zum Drucken einer Listenzeile, um Daten nachzulesen und ebenfalls zu verarbeiten – und letztlich zum Programmende. Die Programme waren oft '[[Spaghetticode]]', folgten kaum einheitlichen Strukturvorgaben und waren deshalb intransparent, fehleranfällig und änderungsunfreundlich.		Zur Zeit der Entstehung der normierten Programmierung Ende der 1960er Jahre für die kommerzielle [[Datenverarbeitung]] gab es lediglich Stapelprogramme: [[Sequentieller Zugriff\|sequentielle]] Dateien, in denen je nach Aufgabenstellung unterschiedliche 'Satzarten' [[Lochkartenmischer\|gemischt/hintereinander]] auftraten, weil z. B. nur eine [[Magnetband#Datenträger in der Informationstechnik\|Magnetbandstation]] oder ein [[Lochkartenleser]] für die Eingabe verfügbar war. Ein Mischen im Programm war so nicht erforderlich und wäre bei Arbeitsspeichern von z. B. 64 KB inkl. Betriebssystem auch zu aufwändig gewesen. So las das Programm 'seine' Eingabedatei und verarbeitete einen [[Datensatz]] nach dem anderen. Über ein Datenfeld 'Satzart' wurden die Datenarten (Kunde, Bestellung …) inhaltlich unterschieden und über Ordnungsbegriffe einander zugeordnet. Das Programm 'lief' (mit [[Sprunganweisung\|GOTO]]) je nach Datenkonstellation zu bestimmten Stellen, zum Beispiel zu Rechenvorgängen, zum Drucken einer Listenzeile, um Daten nachzulesen und ebenfalls zu verarbeiten – und letztlich zum Programmende. Die Programme waren oft '[[Spaghetticode]]', folgten kaum einheitlichen Strukturvorgaben und waren deshalb intransparent, fehleranfällig und änderungsunfreundlich.

	Leistungsfähigere Rechner, neue Programmiersprachen, aber auch Fortschritte in den Methoden zur Softwareentwicklung führten sukzessive zu besseren Lösungen: Es entstanden Vorschläge für eine standardisierte Struktur von Stapelprogrammen. Darin war die gesamte Steuerung des Programms in eindeutig definierte 'Routinen' zergliedert, die die aufgabenspezifischen Verarbeitungsteile des Programms aufrufen – die 'Normierte Programmierung'.		Leistungsfähigere Rechner, neue Programmiersprachen, aber auch Fortschritte in den [[Softwaretechnik#Methoden zur Softwareentwicklung\|Methoden zur Softwareentwicklung]] führten sukzessive zu besseren Lösungen: Es entstanden Vorschläge für eine standardisierte Struktur von Stapelprogrammen. Darin war die gesamte Steuerung des Programms in eindeutig definierte 'Routinen' zergliedert, die die aufgabenspezifischen Verarbeitungsteile des Programms aufrufen – die 'Normierte Programmierung'.

	Allerdings werden in der Praxis der ([[Individualsoftware\|individuellen]]) [[Softwareentwicklung]] derart standardisierte Verfahren oft nicht angewendet – mit der Folge, dass das Erstellen des [[Quellcode\|Programmcodes]] zur Programmsteuerung in vielen Fällen eine besondere Herausforderung bzw. 'Problemstellung' für die Entwickler blieb, die nicht selten hohen Entwicklungsaufwand verursacht und beim [[Softwaretest]] Fehler zutage fördert.		Allerdings werden in der Praxis der ([[Individualsoftware\|individuellen]]) [[Softwareentwicklung]] derart standardisierte Verfahren oft nicht angewendet – mit der Folge, dass das Erstellen des [[Quellcode\|Programmcodes]] zur Programmsteuerung in vielen Fällen eine besondere Herausforderung bzw. 'Problemstellung' für die Entwickler blieb, die nicht selten hohen Entwicklungsaufwand verursacht und beim [[Softwaretest]] Fehler zutage fördert.

Karsten11 am 4. Februar 2024 um 11:24 Uhr

2024-02-04T11:24:23Z

← Nächstältere Version		Version vom 4. Februar 2024, 13:24 Uhr
Zeile 6:		Zeile 6:
	Zur Zeit der Entstehung der normierten Programmierung Ende der 1960er Jahre für die kommerzielle [[Datenverarbeitung]] gab es lediglich Stapelprogramme: [[Sequentieller Zugriff\|sequentielle]] Dateien, in denen je nach Aufgabenstellung unterschiedliche 'Satzarten' [[Lochkartenmischer\|gemischt/hintereinander]] auftraten, weil z. B. nur eine [[Magnetband#Datenträger in der Informationstechnik\|Magnetbandstation]] oder ein [[Lochkartenleser]] für die Eingabe verfügbar war. Ein Mischen im Programm war so nicht erforderlich und wäre bei Arbeitsspeichern von z. B. 64 KB inkl. Betriebssystem auch zu aufwändig gewesen. So las das Programm 'seine' Eingabedatei und verarbeitete einen [[Datensatz]] nach dem anderen. Über ein Datenfeld 'Satzart' wurden die Datenarten (Kunde, Bestellung …) inhaltlich unterschieden und über Ordnungsbegriffe einander zugeordnet. Das Programm 'lief' (mit [[Sprunganweisung\|GOTO]]) je nach Datenkonstellation zu bestimmten Stellen, zum Beispiel zu Rechenvorgängen, zum Drucken einer Listenzeile, um Daten nachzulesen und ebenfalls zu verarbeiten – und letztlich zum Programmende. Die Programme waren oft '[[Spaghetticode]]', folgten kaum einheitlichen Strukturvorgaben und waren deshalb intransparent, fehleranfällig und änderungsunfreundlich.		Zur Zeit der Entstehung der normierten Programmierung Ende der 1960er Jahre für die kommerzielle [[Datenverarbeitung]] gab es lediglich Stapelprogramme: [[Sequentieller Zugriff\|sequentielle]] Dateien, in denen je nach Aufgabenstellung unterschiedliche 'Satzarten' [[Lochkartenmischer\|gemischt/hintereinander]] auftraten, weil z. B. nur eine [[Magnetband#Datenträger in der Informationstechnik\|Magnetbandstation]] oder ein [[Lochkartenleser]] für die Eingabe verfügbar war. Ein Mischen im Programm war so nicht erforderlich und wäre bei Arbeitsspeichern von z. B. 64 KB inkl. Betriebssystem auch zu aufwändig gewesen. So las das Programm 'seine' Eingabedatei und verarbeitete einen [[Datensatz]] nach dem anderen. Über ein Datenfeld 'Satzart' wurden die Datenarten (Kunde, Bestellung …) inhaltlich unterschieden und über Ordnungsbegriffe einander zugeordnet. Das Programm 'lief' (mit [[Sprunganweisung\|GOTO]]) je nach Datenkonstellation zu bestimmten Stellen, zum Beispiel zu Rechenvorgängen, zum Drucken einer Listenzeile, um Daten nachzulesen und ebenfalls zu verarbeiten – und letztlich zum Programmende. Die Programme waren oft '[[Spaghetticode]]', folgten kaum einheitlichen Strukturvorgaben und waren deshalb intransparent, fehleranfällig und änderungsunfreundlich.

	Leistungsfähigere Rechner, neue Programmiersprachen, aber auch Fortschritte in den Methoden zur ~~[[Methode (Softwaretechnik)\|~~Softwareentwicklung]] führten sukzessive zu besseren Lösungen: Es entstanden Vorschläge für eine standardisierte Struktur von Stapelprogrammen. Darin war die gesamte Steuerung des Programms in eindeutig definierte 'Routinen' zergliedert, die die aufgabenspezifischen Verarbeitungsteile des Programms aufrufen – die 'Normierte Programmierung'.		Leistungsfähigere Rechner, neue Programmiersprachen, aber auch Fortschritte in den Methoden zur Softwareentwicklung führten sukzessive zu besseren Lösungen: Es entstanden Vorschläge für eine standardisierte Struktur von Stapelprogrammen. Darin war die gesamte Steuerung des Programms in eindeutig definierte 'Routinen' zergliedert, die die aufgabenspezifischen Verarbeitungsteile des Programms aufrufen – die 'Normierte Programmierung'.

	Allerdings werden in der Praxis der ([[Individualsoftware\|individuellen]]) [[Softwareentwicklung]] derart standardisierte Verfahren oft nicht angewendet – mit der Folge, dass das Erstellen des [[Quellcode\|Programmcodes]] zur Programmsteuerung in vielen Fällen eine besondere Herausforderung bzw. 'Problemstellung' für die Entwickler blieb, die nicht selten hohen Entwicklungsaufwand verursacht und beim [[Softwaretest]] Fehler zutage fördert.		Allerdings werden in der Praxis der ([[Individualsoftware\|individuellen]]) [[Softwareentwicklung]] derart standardisierte Verfahren oft nicht angewendet – mit der Folge, dass das Erstellen des [[Quellcode\|Programmcodes]] zur Programmsteuerung in vielen Fällen eine besondere Herausforderung bzw. 'Problemstellung' für die Entwickler blieb, die nicht selten hohen Entwicklungsaufwand verursacht und beim [[Softwaretest]] Fehler zutage fördert.

Neutronstar2: /* Zielsetzung */

2023-08-18T16:09:08Z

Zielsetzung

← Nächstältere Version		Version vom 18. August 2023, 18:09 Uhr
Zeile 11:		Zeile 11:

	== Zielsetzung ==		== Zielsetzung ==
			{{Belege\|Der erwähnte Buchtitel ist nirgends auffindbar}}
	Laut einem kleinen Lehrbuch eines großen [[BUNCH]]-Computerherstellers von 1971 mit dem Titel ''Logik der Programmierung, Normierte Programmierung'', mit dem damals angehende [[Programmierer]] und [[Systemanalytiker]] ausgebildet wurden, wurden ''{{"\|Vereinheitlichung und Standardisierung der Programmerstellung, Verkürzung der Programmierzeit, Ausschaltung möglicher Fehlerquellen und damit Verkürzung der Testzeit und Senkung der Kosten für die Programmierer}}'' als Ziele der normierten Programmierung bezeichnet. Dementsprechend sind diese Ziele dann von Bedeutung, wenn in einer [[Organisation]] mehrere/viele [[Softwareentwickler\|Entwickler]] Software mit [[Entwicklungswerkzeug]]en herstellen, in denen die Steuerungsfunktionen der Normierten Programmierung nicht als integrierter Bestandteil enthalten sind.		Laut einem kleinen Lehrbuch eines großen [[BUNCH]]-Computerherstellers von 1971 mit dem Titel ''Logik der Programmierung, Normierte Programmierung'', mit dem damals angehende [[Programmierer]] und [[Systemanalytiker]] ausgebildet wurden, wurden ''{{"\|Vereinheitlichung und Standardisierung der Programmerstellung, Verkürzung der Programmierzeit, Ausschaltung möglicher Fehlerquellen und damit Verkürzung der Testzeit und Senkung der Kosten für die Programmierer}}'' als Ziele der normierten Programmierung bezeichnet. Dementsprechend sind diese Ziele dann von Bedeutung, wenn in einer [[Organisation]] mehrere/viele [[Softwareentwickler\|Entwickler]] Software mit [[Entwicklungswerkzeug]]en herstellen, in denen die Steuerungsfunktionen der Normierten Programmierung nicht als integrierter Bestandteil enthalten sind.

O.Koslowski: Änderungen von 195.202.162.6 (Diskussion) auf die letzte Version von IvanP zurückgesetzt

2021-12-02T09:02:02Z

Änderungen von 195.202.162.6 (Diskussion) auf die letzte Version von IvanP zurückgesetzt

Änderungen zeigen

195.202.162.6: toll

2021-12-02T09:01:38Z

toll

Änderungen zeigen

IvanP: /* Das Schema der Programmablaufsteuerung */ Rechtschreibung

2019-09-29T13:42:07Z

Das Schema der Programmablaufsteuerung: Rechtschreibung

← Nächstältere Version		Version vom 29. September 2019, 15:42 Uhr
Zeile 23:		Zeile 23:

	*'''A''': Vorprogramm für alle einmalig durchzuführenden Programmschritte		*'''A''': Vorprogramm für alle einmalig durchzuführenden Programmschritte
	*'''B''': Eingabe; sie besteht aus ~~soviel~~ Unterblöcken wie es serielle Eingabedateien gibt. In jedem dieser Blöcke wird nicht nur die eigentliche Eingabe abgehandelt, sondern auch Plausibilitätsprüfungen und Reihenfolgekontrolle.		*'''B''': Eingabe; sie besteht aus so vielen Unterblöcken wie es serielle Eingabedateien gibt. In jedem dieser Blöcke wird nicht nur die eigentliche Eingabe abgehandelt, sondern auch Plausibilitätsprüfungen und Reihenfolgekontrolle.
	*'''C''': Satzfreigabe; aus den gelesenen Sätzen je Datei wird ausgewählt, welcher Datensatz als nächster zu verarbeiten ist – und (vorher) zur Feststellung von Gruppenwechseln verwendet wird.		*'''C''': Satzfreigabe; aus den gelesenen Sätzen je Datei wird ausgewählt, welcher Datensatz als nächster zu verarbeiten ist – und (vorher) zur Feststellung von Gruppenwechseln verwendet wird.
	*'''D''': Gruppenkontrolle und Aufruf der Gruppenwechsel-Unterprogramme für alle Gruppenstufen.		*'''D''': Gruppenkontrolle und Aufruf der Gruppenwechsel-Unterprogramme für alle Gruppenstufen.
	*'''E''': Einzelverarbeitung; sie ist wiederum entsprechend der Anzahl Eingabedateien in Unterblöcke unterteilt.		*'''E''': Einzelverarbeitung; sie ist wiederum entsprechend der Anzahl Eingabedateien in Unterblöcke unterteilt.
	*'''F''': Schlussprogramm für alle einmalig nach dem eigentlichen Programmablauf zu durchlaufenden Programmbefehle.		*'''F''': Schlussprogramm für alle einmalig nach dem eigentlichen Programmablauf zu durchlaufenden Programmbefehle.
	*'''G''': Unterprogramme der Gruppenverarbeitung; es gibt ~~soviele~~ Unterprogramme wie es Gruppenstufen gibt, jeweils für Vorläufe und Nachläufe getrennt.		*'''G''': Unterprogramme der Gruppenverarbeitung; es gibt so viele Unterprogramme wie es Gruppenstufen gibt, jeweils für Vorläufe und Nachläufe getrennt.
	*'''H''': Unterprogramme der Einzelverarbeitung; diese Unterprogramme sollten möglichst klein und übersichtlich sein.		*'''H''': Unterprogramme der Einzelverarbeitung; diese Unterprogramme sollten möglichst klein und übersichtlich sein.
	*'''J''': Unterprogramme der sequentiellen Ausgabe und der wahlfreien Ein-/Ausgabe; für jede der genannten Dateien gibt es ein Unterprogramm.		*'''J''': Unterprogramme der sequentiellen Ausgabe und der wahlfreien Ein-/Ausgabe; für jede der genannten Dateien gibt es ein Unterprogramm.

Aka: Abkürzung korrigiert

2018-01-26T11:37:16Z

Abkürzung korrigiert

← Nächstältere Version		Version vom 26. Januar 2018, 13:37 Uhr
Zeile 67:		Zeile 67:
	Wenn nicht gesichert ist, dass eine Eingabedatei immer in der richtigen ''Sortierfolge'' vorliegt, sollten in diesem Block eine Reihenfolgekontrolle oder andere Plausibilitätsprüfungen stattfinden – ggf. mit vorzeitigem Programmabbruch.		Wenn nicht gesichert ist, dass eine Eingabedatei immer in der richtigen ''Sortierfolge'' vorliegt, sollten in diesem Block eine Reihenfolgekontrolle oder andere Plausibilitätsprüfungen stattfinden – ggf. mit vorzeitigem Programmabbruch.

	Auch kann hier evtl. ein ''Filtern'', d.h. Überlesen bestimmter Datensätze stattfinden – die damit auch keine Gruppenwechsel auslösen.		Auch kann hier evtl. ein ''Filtern'', d. h. Überlesen bestimmter Datensätze stattfinden – die damit auch keine Gruppenwechsel auslösen.

	==== Block C: Satzfreigabe ====		==== Block C: Satzfreigabe ====
Zeile 136:		Zeile 136:

	* Namenskonventionen: HIER im Wesentlichen als Vorschlag für die Benennung der Funktionsblöcke beschrieben. Regeln für die Benennung von Datendefinitionen sollten ebenfalls im Detail vorgegeben sein.		* Namenskonventionen: HIER im Wesentlichen als Vorschlag für die Benennung der Funktionsblöcke beschrieben. Regeln für die Benennung von Datendefinitionen sollten ebenfalls im Detail vorgegeben sein.
	* GOTO-freie Programmierung: Abhängig von der verwendeten Programmiersprache werden hierfür Schleifenkonstrukte angeboten. Ziel hierbei ist eine übersichtliche Programmlogik. Zumindest sollten direkte Sprünge in fremde Subroutinen niemals erlaubt sein, d.h. jede Subroutine springt zu ihrem Aufrufpunkt zurück.		* GOTO-freie Programmierung: Abhängig von der verwendeten Programmiersprache werden hierfür Schleifenkonstrukte angeboten. Ziel hierbei ist eine übersichtliche Programmlogik. Zumindest sollten direkte Sprünge in fremde Subroutinen niemals erlaubt sein, d. h. jede Subroutine springt zu ihrem Aufrufpunkt zurück.
	* Standard-Funktionen: In vielen Unternehmen existieren für bestimmte Aufgaben (technisch / fachlich) vorgefertigte Routinen (Unterprogramme, Makros, Codesequenzen, …), die in individuellen Programmen zu verwenden sind. Beispiele: Open / Close, Datumsberechnung, Druckausgabe, …		* Standard-Funktionen: In vielen Unternehmen existieren für bestimmte Aufgaben (technisch / fachlich) vorgefertigte Routinen (Unterprogramme, Makros, Codesequenzen, …), die in individuellen Programmen zu verwenden sind. Beispiele: Open / Close, Datumsberechnung, Druckausgabe, …
	* Standard-Datendefinitionen: Die Struktur von Datensätzen (ihre Feldfolge, Länge, Formate, …) sollte immer in einer Form vorliegen, die in allen diese Dateien verarbeitenden Programmen verwendet wird. Hierbei sollte es z. B. möglich sein, für die Eingabe einen anderen Präfix zu verwenden als für die Ausgabe.		* Standard-Datendefinitionen: Die Struktur von Datensätzen (ihre Feldfolge, Länge, Formate, …) sollte immer in einer Form vorliegen, die in allen diese Dateien verarbeitenden Programmen verwendet wird. Hierbei sollte es z. B. möglich sein, für die Eingabe einen anderen Präfix zu verwenden als für die Ausgabe.

Schnabeltassentier: satzbau

2017-09-01T06:46:07Z

satzbau

← Nächstältere Version		Version vom 1. September 2017, 08:46 Uhr
Zeile 23:		Zeile 23:

	*'''A''': Vorprogramm für alle einmalig durchzuführenden Programmschritte		*'''A''': Vorprogramm für alle einmalig durchzuführenden Programmschritte
	*'''B''': Eingabe; sie besteht aus soviel Unterblöcken wie es serielle Eingabedateien gibt. In jedem dieser Blöcke wird nicht nur die eigentliche Eingabe abgehandelt sondern auch Plausibilitätsprüfungen und Reihenfolgekontrolle.		*'''B''': Eingabe; sie besteht aus soviel Unterblöcken wie es serielle Eingabedateien gibt. In jedem dieser Blöcke wird nicht nur die eigentliche Eingabe abgehandelt, sondern auch Plausibilitätsprüfungen und Reihenfolgekontrolle.
	*'''C''': Satzfreigabe; aus den gelesenen Sätzen je Datei wird ausgewählt, welcher Datensatz als nächster zu verarbeiten ist – und (vorher) zur Feststellung von Gruppenwechseln verwendet wird.		*'''C''': Satzfreigabe; aus den gelesenen Sätzen je Datei wird ausgewählt, welcher Datensatz als nächster zu verarbeiten ist – und (vorher) zur Feststellung von Gruppenwechseln verwendet wird.
	*'''D''': Gruppenkontrolle und Aufruf der Gruppenwechsel-Unterprogramme für alle Gruppenstufen.		*'''D''': Gruppenkontrolle und Aufruf der Gruppenwechsel-Unterprogramme für alle Gruppenstufen.

Nameless23: Formatierung

2017-04-10T16:15:58Z

Formatierung

← Nächstältere Version		Version vom 10. April 2017, 18:15 Uhr
Zeile 1:		Zeile 1:
	Die '''normierte Programmierung''' (NP) beschreibt eine standardisierte Ablaufsteuerung eines Datenverarbeitungsprogramms. Sie war in DIN 66220 genormt und wurde mit DIN 66260 in Richtung [[strukturierte Programmierung]] weiterentwickelt. Beide Ansätze unterstützten die [[modulare Programmierung]].		Die '''normierte Programmierung''' ('''NP''') beschreibt eine standardisierte Ablaufsteuerung eines Datenverarbeitungsprogramms. Sie war in DIN 66220 genormt und wurde mit DIN 66260 in Richtung [[strukturierte Programmierung]] weiterentwickelt. Beide Ansätze unterstützten die [[modulare Programmierung]].

	Normierte Programmierung ist eine verallgemeinerte Programmablaufsteuerung, die die Teilaufgaben eines [[Stapelverarbeitung\|Stapelprogrammes]] wie Dateneingabe, Gruppenkontrolle, Verarbeitung / Ausgabe in ein einheitliches, logisch klares, funktionelles Schema gliedert. Für Programme mit solchen Aufgaben lässt sich dieses Schema unabhängig von der fachinhaltlichen Aufgabenstellung und „technologieneutral“ (z. B. in jeder [[Imperative Programmierung\|imperativen]]/[[Prozedurale Programmierung\|prozeduralen]] [[Programmiersprache]]) anwenden.		Normierte Programmierung ist eine verallgemeinerte Programmablaufsteuerung, die die Teilaufgaben eines [[Stapelverarbeitung\|Stapelprogrammes]] wie Dateneingabe, Gruppenkontrolle, Verarbeitung / Ausgabe in ein einheitliches, logisch klares, funktionelles Schema gliedert. Für Programme mit solchen Aufgaben lässt sich dieses Schema unabhängig von der fachinhaltlichen Aufgabenstellung und „technologieneutral“ (z. B. in jeder [[Imperative Programmierung\|imperativen]]/[[Prozedurale Programmierung\|prozeduralen]] [[Programmiersprache]]) anwenden.

192.166.104.102 am 9. Mai 2016 um 13:24 Uhr

2016-05-09T13:24:47Z

← Nächstältere Version		Version vom 9. Mai 2016, 15:24 Uhr
Zeile 152:		Zeile 152:
	Ende der 1960er und in den 1970er Jahren waren 'Top-down-Vorgehensweise, schrittweise Verfeinerung und [[modulare Programmierung]]' Diskussionsthemen zur Softwareentwicklung. Insbesondere die Vorschläge von [[Edsger W. Dijkstra]] zur [[strukturierte Programmierung\|strukturierten Programmierung]] wirken bis heute, konnten aber schon damals innerhalb von normierten Programmen realisiert werden. Einer schrittweisen Verfeinerung vor allem der Blöcke E, H und J stand die normierte Programmierung nicht im Wege. Die elementaren Grundstrukturen waren z. B. in [[COBOL]] umsetzbar, ein „GO TO“-freies Programm mit normierter Programmierung war möglich, das Blockkonzept war also auch mit Sprachen wie COBOL und [[PL/I]], ja sogar mit [[Assemblersprache\|Assembler]] möglich. Allerdings wird die Lesbarkeit der Programme bis heute von manchen Programmierern kritisiert, im Besonderen wenn der [[Quellcode]] von NP-Generatoren erzeugt wurde und z. B. ungewohnte Feld- und Prozedurbezeichnungen, zum Teil sogar „GO TO“-Befehle enthielt.		Ende der 1960er und in den 1970er Jahren waren 'Top-down-Vorgehensweise, schrittweise Verfeinerung und [[modulare Programmierung]]' Diskussionsthemen zur Softwareentwicklung. Insbesondere die Vorschläge von [[Edsger W. Dijkstra]] zur [[strukturierte Programmierung\|strukturierten Programmierung]] wirken bis heute, konnten aber schon damals innerhalb von normierten Programmen realisiert werden. Einer schrittweisen Verfeinerung vor allem der Blöcke E, H und J stand die normierte Programmierung nicht im Wege. Die elementaren Grundstrukturen waren z. B. in [[COBOL]] umsetzbar, ein „GO TO“-freies Programm mit normierter Programmierung war möglich, das Blockkonzept war also auch mit Sprachen wie COBOL und [[PL/I]], ja sogar mit [[Assemblersprache\|Assembler]] möglich. Allerdings wird die Lesbarkeit der Programme bis heute von manchen Programmierern kritisiert, im Besonderen wenn der [[Quellcode]] von NP-Generatoren erzeugt wurde und z. B. ungewohnte Feld- und Prozedurbezeichnungen, zum Teil sogar „GO TO“-Befehle enthielt.

	~~Den~~ Ansatz der 'Normierten Programmierung' wird auch durch die Tatsache bestätigt, dass viele [[Reportgenerator]]en und Datenbank-Auswertungssprachen strukturell nahezu identische Konstrukte verwenden: Der Benutzer kennt und definiert hier z. B. ''Listenkopf und -Fuß'' (entsprechend Programmvorlauf und -Ende), ''Gruppenkopf und Gruppenfuß'' (entsprechend Gruppenvorlauf und Gruppennachlauf) für mehrere, hierarchisch definierte Gruppenstufen. Die ''Einzelzeile'' (auch Detailbereich genannt) zeigt Informationen über den einzelnen Datensatz, was der Einzelverarbeitung entspricht.		Der Ansatz der 'Normierten Programmierung' wird auch durch die Tatsache bestätigt, dass viele [[Reportgenerator]]en und Datenbank-Auswertungssprachen strukturell nahezu identische Konstrukte verwenden: Der Benutzer kennt und definiert hier z. B. ''Listenkopf und -Fuß'' (entsprechend Programmvorlauf und -Ende), ''Gruppenkopf und Gruppenfuß'' (entsprechend Gruppenvorlauf und Gruppennachlauf) für mehrere, hierarchisch definierte Gruppenstufen. Die ''Einzelzeile'' (auch Detailbereich genannt) zeigt Informationen über den einzelnen Datensatz, was der Einzelverarbeitung entspricht.

	In ihrem vollen Umfang enthält das Schema der normierten Programmierung Teilfunktionen, die unter gewissen Umständen überflüssig sein oder vereinfacht implementiert werden können. So kann z. B. im Block 'Satzfreigabe' die Auswahl des nächsten zu verarbeitenden Datensatzes entfallen, wenn nur ein Eingabebestand vorliegt.		In ihrem vollen Umfang enthält das Schema der normierten Programmierung Teilfunktionen, die unter gewissen Umständen überflüssig sein oder vereinfacht implementiert werden können. So kann z. B. im Block 'Satzfreigabe' die Auswahl des nächsten zu verarbeitenden Datensatzes entfallen, wenn nur ein Eingabebestand vorliegt.