Strukturované programování

Strukturální programování  je programovací paradigma založené na reprezentaci programu ve formě hierarchické blokové struktury . Konceptualizován byl koncem 60. a začátkem 70. let na základě Boehm-Jacopiniho teorému , který matematicky dokládá možnost strukturální organizace programů, a práce Edsgera Dijkstra „O nebezpečích operátora goto“ ( angl.  Goto považováno za škodlivé ).

V souladu s paradigmatem se každý program, který je sestaven bez použití příkazu goto, skládá ze tří základních řídicích struktur: sekvence, větev , smyčka ; navíc se používají podprogramy . Současně se vývoj programu provádí krok za krokem metodou „shora dolů“.

Metodika strukturovaného programování se objevila v důsledku zvyšující se složitosti úloh řešených na počítačích, a tedy i složitosti softwaru. V 70. letech dosáhl objem a komplexnost programů takové úrovně, že tradiční (nestrukturovaný) vývoj programů již nevyhovuje potřebám praxe. Programy se staly příliš složitými na to, aby je bylo možné řádně udržovat. Proto byla nutná systematizace procesu vývoje a struktury programů.

Metodika strukturálního vývoje softwaru byla uznána jako „nejsilnější formalizace 70. let“.

Podle Bertranda Meyera „Revoluce programování zahájená Dijkstrou vedla k hnutí známému jako strukturované programování, které navrhlo systematický, racionální přístup k navrhování programů. Strukturované programování se stalo základem všeho, co se dělá v metodologii programování, včetně objektového programování “ [1] .

Historie

Zpočátku se myšlenka strukturovaného programování zrodila v souvislosti s operátorem goto a pochybnostmi o vhodnosti jeho použití. Takové pochybnosti poprvé vyjádřil Heinz Zemanek na setkání o algolštině počátkem roku 1959 v Kodani. Tento projev však nevzbudil pozornost a neměl žádné následky. Edsger Dijkstra vzpomíná: „Do jisté míry si vyčítám, že jsem tehdy nedokázal ocenit význam této myšlenky“ [2] [3] [4] .

Situace se dramaticky změnila o deset let později, když Dijkstra v březnu 1968 zveřejnil svůj slavný dopis Go To Statement Považovaný za škodlivý . Jedná se o skutečně historický dokument, který výrazně ovlivnil další vývoj programování.

Osud samotného dokumentu je velmi zajímavý. Faktem je, že Dijkstra dal článku úplně jiný název: „Argumenty proti prohlášení GO TO“ (Případ proti prohlášení GO TO).

V době zveřejnění se však stalo něco nepochopitelného – článek se z nějakého důvodu záhadně proměnil v „Dopis redaktorovi“ a bývalý titul stejně záhadně zmizel. co se vlastně stalo? Dijkstra záhadnou přeměnu článku na dopis vysvětlil až o mnoho let později, v roce 2001, rok před svou smrtí.

Komunikace ACM zveřejnila můj text s názvem "Prohlášení GOTO je považováno za škodlivé. " V pozdějších letech byl často citován. Bohužel to často dělali lidé, kteří v tom neviděli nic víc, než říká nadpis. Tento titul se stal základním kamenem mé slávy...

Jak se to všechno stalo? Odeslal jsem článek s názvem „Případ proti prohlášení GO TO“. Pro urychlení publikování editor přeměnil můj článek na Dopis redaktorovi. Zároveň vymyslel nový název článku, který sám vymyslel. Editorem byl Niklaus Wirth [5] [6] .

Účel

Účelem strukturovaného programování je zvýšit produktivitu programátorů, a to i při vývoji velkých a složitých softwarových systémů, snížit počet chyb, zjednodušit ladění, úpravy a údržbu softwaru.

Tento cíl byl stanoven v souvislosti se zvyšující se složitostí programů a neschopností vývojářů a manažerů velkých softwarových projektů vyrovnat se s problémy, které vznikly v letech 1960-1970 v souvislosti s vývojem softwarových nástrojů [7] .

Kód špaget

Strukturované programování je navrženo zejména k odstranění nepořádku a chyb v programech způsobených obtížemi při čtení kódu, nesystematizovaným, nepohodlným pro vnímání a analýzu zdrojového kódu programu. Takový text je často charakterizován jako „ kód špaget “.

Špagetový kód  je špatně navržený, špatně strukturovaný, matoucí a těžko pochopitelný program , který obsahuje spoustu příkazů goto (zejména zpětných skoků), výjimek a dalších konstrukcí, které degradují strukturu [8] . Jeden z nejznámějších programovacích anti -vzorů .

Kód špaget je tak pojmenován, protože tok programu je jako mísa špaget , tedy klikatý a spletitý. Někdy se nazývá „klokaní kód“ kvůli mnoha instrukcím pro skok .

V dnešní době se tento termín používá nejen pro případy zneužití goto, ale také pro jakýkoli "multi-linked" kód, ve kterém je stejný malý fragment vykonáván ve velkém množství různých situací a plní mnoho různých logických funkcí [8] .

Kód špaget lze odladit a spustit správně a s vysokým výkonem, ale je extrémně obtížné jej udržovat a vyvíjet [8] . Zdokonalení kódu špaget pro přidání nových funkcí někdy s sebou nese významný potenciál pro zavádění nových chyb. Z tohoto důvodu je téměř nevyhnutelné, že refaktorizace  je hlavním lékem na špagety.

příkaz goto

Počínaje 70. lety byl operátor bezpodmínečného skoku goto středem systematické a rostoucí kritiky. Nesprávné a bezmyšlenkovité použití příkazu goto ve zdrojovém kódu programu vede k matoucímu, nečitelnému „ kódu špaget “. Z textu takového kódu je téměř nemožné pochopit pořadí provádění a vzájemnou závislost fragmentů.

Tento úhel pohledu se poprvé odrazil v článku Edsgera Dijkstra „ Operátor Go To je považován za škodlivý“ [3] [9] . Dijkstra si všiml, že kvalita kódu je nepřímo úměrná počtu příkazů goto v něm. Článek získal širokou publicitu, v důsledku čehož byly výrazně přepracovány názory na použití operátoru goto. V Notes on Structured Programming [10] Dijkstra tvrdil, že je mnohem snazší zkontrolovat formální správnost kódu bez goto .

Kód s goto je obtížné formátovat, protože může narušit hierarchii provádění (paradigma strukturovaného programování), a proto nemusí být odsazení, navržené tak, aby odráželo strukturu programu, vždy správně nastaveno. Příkaz goto navíc brání kompilátorům v optimalizaci řídicích struktur [11] .

Některá použití goto mohou způsobit problémy s logikou provádění programu:

Argumenty proti prohlášení goto se ukázaly být natolik závažné, že ve strukturovaném programování začaly být považovány za vysoce nežádoucí. To se odrazilo v návrhu nových programovacích jazyků. Například goto je nelegální v Javě a Ruby . V řadě moderních jazyků je stále ponechán z důvodů účinnosti v těch vzácných případech, kdy je použití goto oprávněné. Například goto přežilo v Ada  , jednom z architektonicky nejsofistikovanějších jazyků v historii [12] .

V jazycích na vysoké úrovni, kde byl tento operátor zachován, však jeho použití zpravidla podléhá přísným omezením, která brání použití nejnebezpečnějších způsobů jeho použití: například je zakázáno předávat kontrolu z vnějšku smyčka, procedura nebo funkce uvnitř. Jazykový standard C++ zakazuje obejít inicializaci proměnné pomocí goto.

Věta o strukturovaném programování

Větu formulovali a dokázali italští matematici Corrado Böhm a Giuseppe Jacopini. Vydali ji v roce 1965 v italštině a v roce 1966 v angličtině [13] . Spolu s teorémem článek Boehma a Jacopiniho popsal metody pro převod nestrukturálních algoritmů na strukturální algoritmy pomocí programovacího jazyka P′′ vytvořeného Bohmem jako příklad . Jazyk P′′ je prvním Turingovým úplným programovacím jazykem bez operátoru goto .

Böhm-Jacopiniho věta je napsána složitým jazykem a v neobvyklé notaci. Pokud použijeme moderní terminologii a notaci, bude mít podobu:

Jakýkoli program ve formě vývojového diagramu lze reprezentovat pomocí tří řídicích struktur:

kde f, g jsou bloková schémata s jedním vstupem a jedním výstupem,

p - podmínka, THEN, IF, ELSE, WHILE, DO jsou klíčová slova [14] .

Vysvětlení. Vzorec f THEN g znamená následující: nejprve se provede program f, potom se provede program g.

Jak poznamenává Harlan Mills , tento teorém ostře kontrastuje s obvyklou ( v  60.–70. letech) programátorskou praxí, kdy se masivně používaly operátory goto skoku [14] .

Boehm a Jacopini nepoužili termín „strukturované programování“. Nicméně jimi dokázaná věta (a její následné variace různými autory) se následně začala nazývat „teorém strukturního programování“, „strukturální teorém“ [14] , „strukturovací teorém“ [15] .

Principy strukturovaného programování

Vznik a rozvoj strukturovaného programování je spojen se jménem Edsger Dijkstra [10] [16] .

Princip 1. Měli byste přestat používat operátor nepodmíněného skoku goto.

Princip 2. Každý program se skládá ze tří základních řídicích struktur: sekvence, větvení, cyklus.

Princip 3. V programu mohou být základní řídicí struktury vnořeny do sebe libovolným způsobem. Nejsou k dispozici žádné jiné prostředky pro řízení sledu operací.

Princip 4. Opakující se části programu mohou být uspořádány ve formě podprogramů (procedur a funkcí ). Stejným způsobem (ve formě podprogramů) lze uspořádat logicky celistvé fragmenty programu, i když se neopakují.

Zásada 5. Každá logicky úplná skupina instrukcí by měla být uspořádána jako blok . Bloky jsou základem strukturovaného programování.

Blok je logicky seskupená část zdrojového kódu, jako je sada instrukcí zapsaných v řadě ve zdrojovém kódu programu. Koncept bloku znamená, že s blokem instrukcí by se mělo zacházet jako s jedinou instrukcí. Bloky slouží k omezení rozsahu proměnných a funkcí. Bloky mohou být prázdné nebo vnořené do sebe. Hranice bloku jsou přesně definovány. Například v příkazu if je blok ohraničen kódem BEGIN..END(v Pascalu) nebo složenými závorkami {...} (v C) nebo odsazením (v Pythonu).

Princip 6. Všechny uvedené struktury musí mít jeden vstup a jeden výstup.

Libovolné řídicí struktury (jako například v misce na špagety) mohou mít libovolný počet vstupů a výstupů. Tím, že se omezíme na řídicí struktury s jedním vstupem a jedním výstupem, získáme schopnost vytvářet libovolné algoritmy libovolné složitosti pomocí jednoduchých a spolehlivých mechanismů [17] .

Zásada 7. Vývoj programu se provádí krok za krokem metodou „shora dolů“ (metoda shora dolů) [18] .

Metoda shora dolů

Nejprve se zapíše text hlavního programu, do kterého se místo každého připojeného logického fragmentu textu vloží volání podprogramu, který tento fragment provede. Místo skutečných fungujících podprogramů jsou do programu vkládány fiktivní části - pahýly , které zjednodušeně řečeno nic nedělají.

Přesněji řečeno, stub splňuje požadavky rozhraní nahrazovaného fragmentu (modulu), ale neplní své funkce nebo je plní částečně. Pahýly jsou pak nahrazeny nebo upgradovány na skutečné plnohodnotné fragmenty (moduly) podle programového plánu. V každé fázi implementačního procesu musí již vytvořený program správně fungovat ve vztahu k nižší úrovni. Výsledný program je zkontrolován a odladěn [19] .

Poté, co se programátor přesvědčí, že podprogramy jsou volány ve správném pořadí (to znamená, že obecná struktura programu je správná), jsou stub rutiny postupně nahrazeny skutečnými a vývoj každého podprogramu se provádí ve stejném pořadí. způsobem jako hlavní program. Vývoj končí, když nezůstanou žádné pahýly.

Taková sekvence zajišťuje, že v každé fázi vývoje se programátor současně zabývá viditelnou a srozumitelnou sadou fragmentů a může si být jistý, že obecná struktura všech vyšších úrovní programu je správná.

Při údržbě a provádění změn programu se ukazuje, které postupy je potřeba změnit. Jsou zavedeny, aniž by ovlivnily části programu, které s nimi přímo nesouvisí. Tím je zajištěno, že při provádění změn a opravách chyb nedojde k selhání některé části programu, která je aktuálně mimo oblast pozornosti programátora [18] [20] [21] [22] [23] [24 ] .

Je třeba také poznamenat, že v "Předmluvě" ke knize "Structured Programming" [25] Tony Hoare poznamenává, že principy strukturovaného programování lze stejně aplikovat na vývoj programů jak "shora dolů", tak "zdola nahoru" [26] .

Podprogram

Podprogramy nebyly nezbytnou podmínkou pro možnost implementace strukturovaného programování [27] . Zpočátku se podprogramy objevovaly jako prostředek k optimalizaci programů z hlediska množství zabrané paměti – umožňovaly neopakovat stejné bloky kódu v programu, ale jednou je popsat a volat podle potřeby. Zatím[ kdy? ] se tato funkce podprogramů stala pomocnou, jejich hlavním účelem je strukturování programu za účelem jeho snadnějšího pochopení a údržby.

Oddělení sady akcí do podprogramu a jeho volání podle potřeby umožňuje logicky vybrat integrální dílčí úkol, který má typické řešení. Taková akce má oproti opakování stejného typu akcí ještě jednu (kromě úspory paměti) výhodu. Jakákoli změna (oprava chyb, optimalizace, rozšíření funkčnosti) provedená v podprogramu se automaticky projeví ve všech jeho voláních, zatímco při duplikaci musí být každá změna provedena při každém výskytu měněného kódu.

I v případech, kdy je podprogramu přidělena jednorázová sada akcí, je to oprávněné, protože to umožňuje snížit velikost integrálních bloků kódu, které tvoří program, to znamená, aby byl program srozumitelnější. a viditelné.

Výhody strukturovaného programování

Dodržováním principů strukturovaného programování byly texty programů, a to i poměrně rozsáhlé, běžně čitelné. Pochopení programů se výrazně zjednodušilo, umožnilo se vyvíjet programy v běžném průmyslovém režimu, kdy programu bez větších potíží rozumí nejen jeho autor, ale i ostatní programátoři. To umožnilo silami vývojových týmů vyvíjet na tehdejší dobu poměrně velké softwarové systémy a udržovat tyto komplexy po mnoho let i při nevyhnutelných změnách ve složení personálu.

  1. Strukturální programování umožňuje výrazně snížit počet možností pro sestavení programu podle stejné specifikace, což výrazně snižuje složitost programu a co je důležitější, usnadňuje to ostatním vývojářům jeho pochopení.
  2. Ve strukturovaných programech jsou logicky související operátory vizuálně blíže a volně související operátory jsou vzdálenější, což umožňuje obejít se bez vývojových diagramů a jiných grafických forem zobrazování algoritmů (ve skutečnosti je program sám svým vlastním vývojovým diagramem).
  3. Proces testování a ladění strukturovaných programů je značně zjednodušen .

Přehlednost a čitelnost programů

Strukturované programování výrazně zlepšuje přehlednost a čitelnost programů [28] . Edward Jordan vysvětluje:

Chování mnoha nestrukturálních programů je často bližší Brownovu pohybu než jakémukoli organizovanému procesu. Jakýkoli pokus o přečtení výpisu přivádí člověka k zoufalství, protože takový program obvykle provede několik příkazů, po kterých se řízení přenese o několik stránek níže. Provede se tam několik dalších příkazů a řízení se opět přenese do nějakého náhodného bodu. Zde jsou provedeny další operátory atd. Po několika takových přenosech čtenář zapomene, jak to všechno začalo. A ztrácí svůj myšlenkový pochod.

Strukturální programy na druhé straně bývají organizovány a prováděny postupně [29] .

Zlepšení čitelnosti strukturovaných programů je způsobeno tím, že absence příkazu goto umožňuje čtení programu shora dolů bez přerušení způsobených řídicími přenosy. Díky tomu můžete okamžitě (na první pohled) zjistit podmínky nutné pro úpravu té či oné části programu [30] .

2D strukturované programování

P-technologie pro výrobu programů neboli „technologie dvourozměrného programování“ [31] vznikla v Ústavu kybernetiky V. M. Glushkova [32] . Grafický systém technologie R-programování je zakotven v normách GOST 19.005-85 [33] , GOST R ISO/IEC 8631-94 [34] a mezinárodní normě ISO 8631Н.

Autor technologie R-programování, doktor fyzikálních a matematických věd, profesor Igor Velbitsky, navrhl přehodnotit samotný koncept „programové struktury“. Podle něj „struktura je multidimenzionální koncept. Proto zobrazení tohoto konceptu pomocí lineárních textů (sekvencí operátorů) téměř na nic redukuje výhody strukturálního přístupu. Obrovské asociativní možnosti zrakového aparátu a aparátu lidského myšlení jsou prakticky marně využívány – k rozpoznávání strukturálních obrazů v podobě jednotné sekvence symbolů“ [35] .

Metodika dvourozměrného strukturovaného programování se výrazně liší od klasického jednorozměrného (textového) strukturovaného programování [36] [37] .

Myšlenky strukturovaného programování byly vyvinuty, když počítačová grafika ve skutečnosti ještě neexistovala a hlavním nástrojem pro algoritmisty a programátory byl jednorozměrný (lineární nebo stupňovitý ) text. Před nástupem počítačové grafiky byla nejlepším řešením metodika klasického strukturovaného programování [10] .

S příchodem počítačové grafiky se situace změnila. Pomocí výrazových prostředků grafiky bylo možné upravovat, rozvíjet a doplňovat tři typy základních (textových) řídících strukturních struktur a také zcela opustit klíčová slova if , then, else, case , switch, break, while , do, opakujte, dokud, pro , foreach, continue, loop, exit, when, last atd. a nahraďte je řídicí grafikou, tedy použijte dvourozměrné strukturované programování [33] [36] .

Viz také

Poznámky

  1. ↑ Meyer B. Cítit třídu. Naučit se dobře programovat s objekty a smlouvami. — Per. z angličtiny. - M .: Národní otevřená univerzita INTUIT: BINOM. Vědomostní laboratoř, 2011. - 775s. - S. 208. - ISBN 978-5-9963-0573-5
  2. ↑ E. Dijkstra. Příkaz goto je považován za škodlivý . Získáno 2. listopadu 2014. Archivováno z originálu 23. února 2007.
  3. ↑ 1 2 Dijkstra E. Přejít na prohlášení považované za škodlivé // Communications of the ACM, Volume 11, No. 3, březen 1968, str. 147-148. — Association for Computing Machinery, Inc. . Získáno 3. listopadu 2014. Archivováno z originálu 2. ledna 2015.
  4. ↑ Viz také materiály z archivu Dijkstra. Archiv EW Dijkstra. Rukopisy Edsgera W. Dijkstra. — Katedra informatiky Texaská univerzita v Austinu Archivováno 20. dubna 2005 na Wayback Machine
  5. ↑ Rukopis EWD1308 z archivu Dijkstra. Co vedlo k "Poznámkám o strukturovaném programování" - Nuenen, 10. června 2001. - Katedra počítačových věd. Texaská univerzita v Austinu, USA Archivováno 21. března 2015 na Wayback Machine
  6. ↑ Přepis rukopisu EWD1308 z archivu Dijkstra. Co vedlo k "Poznámkám o strukturovaném programování" - Nuenen, 10. června 2001. - Katedra počítačových věd. Texaská univerzita v Austinu, USA Archivováno 19. listopadu 2014 na Wayback Machine
  7. ↑ Linger R., Mills H., Witt B. Teorie a praxe strukturovaného programování. — Per. z angličtiny. - M .: Mir, 1982. - 406 s. - str. 7.
  8. ↑ 1 2 3 John Vlissides, Kyle Brown, Gerard Meszaros AntiPatterns: The Survival Guide. Kód špaget Archivováno 27. ledna 2021 na Wayback Machine .
  9. ↑ E. Dijkstra. Příkaz Přejít na je považován za škodlivý . Získáno 2. listopadu 2014. Archivováno z originálu 23. února 2007.
  10. ↑ 1 2 3 Dijkstra E. Poznámky ke strukturovanému programování. // Dahl W., Dijkstra E., Hoor K. Strukturální programování. — M .: Mir, 1975. — S. 7–97.
  11. ↑ Donald Knuth. Structured Programming with go to Statements Archived from original on 19 May 2013. 1974
  12. ↑ Kompletní kód: Praktická příručka pro konstrukci softwaru Archivováno 2. června 2017 na Wayback Machine Redmond: Microsoft Press, 1993. 880 s.
  13. ↑ Bohm, Corrado; a Giuseppe Jacopini. Vývojové diagramy, Turingovy stroje a jazyky pouze se dvěma formačními pravidly  (anglicky)  // Communications of the ACM  : journal. - 1966. - Květen ( roč. 9 , č. 5 ). - str. 366-371 . - doi : 10.1145/355592.365646 . Archivováno z originálu 5. března 2016.
  14. ↑ 1 2 3 Harlan D. Mills Matematické základy pro strukturované programování. - únor 1972. - Federal Systems Division. IBM Corporation. Gaithersburg, Maryland. p. 4 . Získáno 10. listopadu 2014. Archivováno z originálu 10. listopadu 2014.
  15. ↑ Butakov E. A. Metody tvorby vysoce kvalitního počítačového softwaru. — M.: Energoatomizdat, 1984. — 232s. - S. 114.
  16. ↑ Poznámky ke strukturovanému programování. Od prof. Dr. Edsger W. Dijkstra - TH Report 70-WSK-03 Druhé vydání duben 1970. . Získáno 3. listopadu 2014. Archivováno z originálu 17. března 2019.
  17. ↑ 1 2 3 Meyer B. Cítit třídu. Naučit se dobře programovat s objekty a smlouvami. — Per. z angličtiny. - M .: Národní otevřená univerzita INTUIT: BINOM. Vědomostní laboratoř, 2011. - 775s. - S. 209. - ISBN 978-5-9963-0573-5
  18. ↑ 1 2 Wirth N. Program Development by Stepwise Refinement // Communications of the ACM, Volume 14, No. 4, duben 1971, str. 221-227. — Association for Computing Machinery, Inc.
  19. ↑ Glass R. Průvodce spolehlivým programováním. - M .: Finance a statistika, 1982. - 256 s. - S. 84.
  20. ↑ Hughes J., Michtom J. Strukturální přístup k programování. - M .: Mir, 1980. - 278c. - S. 29-71. (Viz „Kapitola 2 Návrh programu rozvoje shora dolů“ a „Kapitola 3 Plánování a implementace rozvoje shora dolů“).
  21. ↑ Wirth N. Systematické programování. Úvod. - M .: Mir, 1977. - 184 s. - S. 139-168. (Viz „Kapitola 15. Programování krok za krokem“) .
  22. ↑ Glass R. Průvodce spolehlivým programováním. - M .: Finance a statistika, 1982. - 256 s. — S. 83-87. (Viz část "3.3.1. Programování shora dolů a zdola nahoru").
  23. ↑ Linger R., Mills H., Witt B. Teorie a praxe strukturovaného programování. - M .: Mir, 1982. - 406 s. - S. 324-327. (Viz část "7.3.3. Strukturované programování shora dolů" a "Oddíl 7.3.4. Programování pomocí principu přírůstkové reorganizace").
  24. ↑ Ivanova G. S., Nichushkina T. N. Návrh softwaru. Učebnice pro realizaci a návrh semestrálních, diplomových a kvalifikačních prací. - M .: Moskevská státní technická univerzita. N. E. Bauman. Fakulta informatiky a řídicích systémů, 2002. - 74s. — S. 28-31. . Datum přístupu: 4. listopadu 2014. Archivováno z originálu 2. prosince 2014.
  25. ↑ Dahl W., Dijkstra E., Hoor K. Strukturální programování. - M .: Mir, 1975. - 247c.
  26. ↑ Khoor K. Předmluva. // Dal W., Dijkstra E., Hoor K. - M .: Mir, 1975. - 247c. - str. 6.
  27. ↑ Avacheva T. G., Prutskov A. V. Moderní pohled na koncept strukturovaného programování  (ruština)  // Cloud of Science: Journal. - 2019. - T. 6 , č. 4 . — S. 646–665 . Archivováno z originálu 7. listopadu 2019.
  28. ↑ Yodan E. Strukturální návrh a návrh programu. — Per. z angličtiny. — M.: Mir, 1979. — 415s. - S. 174.
  29. ↑ Yodan E. Strukturální návrh a návrh programu. — Per. z angličtiny. — M.: Mir, 1979. — 415s. - S. 174, 175.
  30. ↑ Yodan E. Strukturální návrh a návrh programu. — Per. z angličtiny. — M.: Mir, 1979. — 415s. - S. 175.
  31. ↑ Velbitsky I. V., Khodakovsky V. N., Sholmov L. I. Technologický komplex pro výrobu programů na počítačích ES a strojích BESM-6. - M .: Statistika, 1980. - 263 s. - str. 5.
  32. ↑ Stogniy A. A. Předmluva. // Velbitsky I. V., Khodakovsky V. N., Sholmov L. I. Technologický komplex pro výrobu programů na počítačích ES a strojích BESM-6. - M .: Statistika, 1980. - 263 s. - str. 3.
  33. ↑ 1 2 Mezistátní norma GOST 19.005-85. Jednotný systém programové dokumentace. P-schémata algoritmů a programů. Podmíněná grafická označení a pravidla provádění. Jednotný systém pro dokumentaci programu. R grafy. Grafické symboly a konvence pro mapování. 1985.
  34. ↑ GOST R ISO / IEC 8631-94 Informační technologie. Softwarové konstrukce a symboly pro jejich reprezentaci. informační technologie. Programové konstrukce a konvence pro jejich reprezentaci. Gosstandart Ruska. - Nakladatelství Standardy, 1995. . Získáno 30. října 2014. Archivováno z originálu 30. října 2014.
  35. ↑ Seznamte se s R-technologií // NTR: problémy a řešení. - 1987, č. 13, 7.-20. července. - S. 4, 5.
  36. ↑ 1 2 Ermakov I. E., Zhigunenko N. A. Dvourozměrné strukturované programování; třída orientovaných grafů. (Teoretický výzkum ze zkušenosti jazyka „DRAK“) . - M . : MGU im. M. V. Lomonosov, 2010. - S. 452-461. — (Sborník příspěvků V. mezinárodní konference "Inovativní informační a pedagogické technologie v systému IT vzdělávání").  (nedostupný odkaz)
  37. ↑ Shamardina E. I., Manyunin P. A. Jazyk algoritmických kreseb „DRAKON“, jeho matematický model a editor // Nové informační technologie. Abstrakty XVII. mezinárodní studentské konference-škola-seminář. — M.: MIEM, 2009. — 399s. - S. 279, 280. - ISBN 978-5-94506-223-8 . Získáno 30. října 2014. Archivováno z originálu 20. května 2012.


  Přejděte na položku Wikidata