Drakentaal - zelfstudies. Wetenschappelijke grondslagen van de drakentaal

Heb je iets gehoord over de programmeertaal DRAGON? Wij zijn niet. Maar onze lezer beweert dat de DRAAK al is opgenomen in het curriculum van de opleiding informatica van het hoger onderwijs.

Heb je iets gehoord over de programmeertaal DRAGON? Wij zijn niet. Maar onze lezer beweert dat de DRAAK al is opgenomen in het curriculum van de opleiding informatica van het hoger onderwijs. De spelling en interpunctie van de auteur blijven behouden. - ca. red.

In 1976 begon in de USSR, in het strikte geheim, de ontwikkeling van het herbruikbare transportruimtevaartuig Buran in het kader van het Buran-Energia-project. Het was een enorm project. 86 ministeries en afdelingen en 1286 ondernemingen van de USSR (in totaal ongeveer 2,5 miljoen mensen) namen deel aan de oprichting ervan.

"Buran" maakte zijn eerste en enige ruimtevlucht op 15 november 1988. De orbiter werd gelanceerd vanaf het Baikonoer-kosmodrome met behulp van het Energia-draagraket. Nadat hij rond de aarde was gevlogen, landde Buran op het speciaal uitgeruste Yubileiny-vliegveld in Baikonoer. De vlucht vond plaats zonder bemanning, volledig in automatische modus. In tegenstelling tot de American Shuttle, die alleen handmatig kan landen. In verband met de ineenstorting van de USSR en de moeilijkheden van de overgangsperiode in 1990, werden de werkzaamheden aan het programma Energie-Buran opgeschort en in 1993 werd het programma definitief afgesloten.

Ontwikkeling van programmeertalen voor Buran

Tijdens de ontwikkeling van Buran werd het probleem van softwareontwikkeling en -ontwikkeling als een van de moeilijkste beschouwd. Aanvankelijk werd aangenomen dat er enkele duizenden programmeurs nodig zouden zijn om het probleem op te lossen. Opgemerkt moet worden dat onze programmeurs gewend zijn programma's in assembler te schrijven, aangezien de geheugencapaciteit van de Biser-4 boordcomputer destijds zeer beperkt was.

In de materialen van het Instituut voor Toegepaste Wiskunde. MV Keldysh Instituut van de Russische Academie van Wetenschappen over de moeilijkheden en prestaties van die periode wordt als volgt gezegd:

"In 1983 wendden de ontwikkelaars van het Buran-ruimtevaartuig zich tot het Institute [of Applied Mathematics] met een verzoek om te helpen bij de ontwikkeling van software aan boord en software voor grondtests van het ruimtevaartuig. Volgens hun schatting waren er enkele duizenden programmeurs nodig voor Na bestudering van het probleem, werd besloten om probleemgeoriënteerde talen te ontwikkelen op basis van de termen, concepten en presentatievorm van besturings- en testalgoritmen die door de scheepsontwikkelaars werden gebruikt.De implementatie van deze talen stelde het schip in staat ontwikkelaars zelf - de auteurs van de controle- en testalgoritmen die in een extreem korte tijd moeten worden betrokken bij het maken van onboard- en testsoftware. Een team van hooggekwalificeerde programmeurs van het Instituut voor Toegepaste Wiskunde. Het is het programmeer- en debugging-automatiseringssysteem SAPO PROL2 ... Om software te ontwikkelen voor de grondtests van het schip, zijn de probleemgeoriënteerde taal DIPOL en het daarop gebaseerde programmeer- en debugging-automatiseringssysteem gemaakt "...

Dus om het probleem van het gebrek aan programmeurs bij het maken van Buran op te lossen, heeft het Instituut voor Toegepaste Wiskunde van de Russische Academie van Wetenschappen op ons verzoek twee Russischtalige talen gecreëerd:

• PROL2 real-time taal voor de ontwikkeling van geïntegreerde programma's aan boord (door Viktor Kryukov)
• een probleemgeoriënteerde taal voor de ontwikkeling van grondtestprogramma's DIPOL (door Vladimir Lutsikovich)

Bovendien werd de LAX-taal voor modellering ontwikkeld in het Pilyugin Center onder leiding van Konstantin Fedorov. Zo verschenen er drie nieuwe talen: PROL2, DIPOL en LAX.

DRAGON Tongue werd geboren in de ruimtewieg

Hoewel talen erin slaagden deze problemen op te lossen, werd duidelijk dat de enge specialisatie van talen in de weg stond. Dit idee werd in 1986 uitgedrukt door het hoofd van de complexe afdeling, Yuri Trunov (later algemeen ontwerper en algemeen directeur van het Pilyuginsky Center). Trunov riep het hoofd van het laboratorium voor de geïntegreerde ontwikkeling van het Buran-computersysteem, Vladimir Parondzhanov, bijeen en gaf hem de opdracht een universele taal te creëren die de drie bovenstaande zou kunnen vervangen. Parondzhanov besloot het probleem echter anders te stellen. Hij was van mening dat de nieuwe taal niet alleen moet voldoen aan de praktische behoeften van ruimtetechnologie, maar ook een extreem breed scala aan problemen moet oplossen die veel verder gaan dan het raamwerk van traditionele programmering.

In dit verband werden bij het creëren van de DRAGON-taal humanitaire vereisten naar voren gebracht, ongebruikelijk voor programmeurs, wiskundigen en "techneuten".

1. Verbeter de werking van de menselijke geest.
2. Bied effectieve middelen om de structuur van menselijke activiteit te beschrijven.
3. Bied een persoon dergelijke taalhulpmiddelen die de perceptie van complexe procedurele problemen en communicatie met collega's drastisch vereenvoudigen, het onbegrijpelijke begrijpelijk maken en, hierdoor, de persoon letterlijk dwingen om helder, diep en productief te denken. Onder deze omstandigheden neemt de kans op wanen, misrekeningen en fouten onvermijdelijk af en neemt de productiviteit toe.
4. Om de sectoroverschrijdende en interdisciplinaire communicatie tussen vertegenwoordigers van verschillende organisaties, afdelingen, afdelingen, laboratoria, wetenschappelijke scholen en beroepen radicaal te vergemakkelijken.
5. Elimineer of verminder de barrières van wederzijds misverstand tussen werknemers van verschillende specialismen (artsen en natuurkundigen, wiskundigen en ontwerpers, biologen en economen, enz.), evenals programmeurs en degenen die allergisch zijn voor programmering.
6. Het bereiken van een radicale verbetering van de kwaliteit van software volgens het criterium "begrijpelijkheid van algoritmen en programma's".

Ontwikkeling van de DRAGON-taal en zijn software

De ontwikkeling van een nieuwe programmeertaal en systeem begon in 1986. 11 jaar later werd op basis van DRAGON een geautomatiseerde technologie voor het ontwerpen van algoritmen en programma's (CASE-technologie) genaamd "GRAPHITE-FLOX" gebouwd.

Al het werk werd voltooid in 1996. Daarna werden de DRAGON-taal en het GRAPHITE-FLOX-systeem in gebruik genomen. Met hun hulp werden algoritmen en programma's ontwikkeld voor de pre-acceleratiemodule van ruimtevaartuigen van het International Sea Launch Project. In totaal duurde het drie jaar om de software en andere elementen van het besturingssysteem te ontwikkelen en te testen. In 1999 waren alle werkzaamheden voltooid. Het systeem was klaar om te starten.

De eerste lancering van het Sea Launch-raketsysteem vond plaats op 28 maart 1999. Het gebeurde om 5 uur. 30 minuten. Moskou-tijd (27 maart 1999 om 18.30 uur Pacific-tijd) vanaf het Odyssey-lanceerplatform in de Stille Oceaan bij de Kiribati-eilanden.

Deze lancering was de vuurdoop van de DRAGON-taal en de technologie voor het maken van programma's "Graphite-Phlox". Hij heeft hun effectiviteit en betrouwbaarheid overtuigend aangetoond. Sindsdien zijn er 29 raketlanceringen uitgevoerd in het kader van het Sea Launch-programma. De laatste lancering vond plaats op 24 september 2008. De DRAGON-taal wordt met succes gebruikt in veel andere ruimteprogramma's:

• de bovenste trap van het Fregat-ruimtevaartuig;
• het verbeterde Proton-M draagraket;
• pre-versnellingsmodule van ruimtevaartuig DM-SL-B (project "Start in the Desert", of "Ground Launch"), enz.

Omdat de resultaten van het gebruik van de draak constant hoog waren, besloot de leiding van het Pilyugin Center om de drakentechnologie in alle volgende projecten te gebruiken.

Programmeren zonder programmeurs

DRAGON is een zeer lichte taal. Zo eenvoudig dat de ontwikkeling van veel computerprogramma's voor ruimteraketten in de praktijk niet wordt uitgevoerd door programmeurs, maar door ingenieurs - volgens het principe van "programmeren zonder programmeurs". De reden om programmeurs af te wijzen is simpel. Bij het oplossen van praktisch toegepaste problemen hebben ingenieurs een grondige kennis van de stof en zijn ze goed op de hoogte van de probleemstelling. In tegenstelling tot hen kennen programmeurs de "fysica van het proces" niet en worden "overbodige mensen", zonder wie het in sommige gevallen (hoewel niet altijd) heel goed mogelijk is om zonder te stellen.

Hierdoor kunt u de kosten aanzienlijk verlagen, de kosten-batenverhouding verbeteren en de voortgang van het werk versnellen. En volledig ontdoen van de "beschadigde telefoon" fouten veroorzaakt door wederzijds misverstand tussen programmeurs en ingenieurs.

Geheimen van ruimteontwikkeling - voor de nationale economie

DRAGON is veelzijdig. Het kan worden gebruikt voor visualisatie en snelle ontwikkeling van algoritmen, niet alleen in "ruimte", maar ook in "terrestrische" soorten menselijke activiteit. Het praktische nut van de DRAGON werd zeer gewaardeerd. Er mag worden aangenomen dat de DRAGON-taal wijdverbreid zal worden op verschillende gebieden, waaronder het onderwijssysteem. Niklaus Wirth, de auteur van de Pascal-taal, geloofde ooit dat Pascal de allereerste taal zou moeten zijn om te leren programmeren. Dit standpunt is bijna algemeen aanvaard geworden.

In die tijd werden programma's geschreven in de vorm van tekst. Voor op tekst gebaseerd programmeren was Pascal inderdaad de beste onderwijstaal.

Vandaag is de situatie echter veranderd. De toekomst is aan ergonomische talen. Onder deze omstandigheden verloor grootvader Pascal zijn oude glorie als uitstekend educatief hulpmiddel.

Tegenwoordig verschuift deze rol naar de beeldtaal DRAGON. Het is DRAGON die de eenvoudigste, gemakkelijkste, handigste en logisch harmonieuze taal wordt om van daaruit te beginnen met het leren van algoritmen en programmeren.

Draak in het onderwijssysteem

In 1996 nam het Staatscomité voor Hoger Onderwijs van de Russische Federatie de studie van de DRAGON-taal op in het curriculum van de cursus informatica in het hoger onderwijs. Dit feit wordt weerspiegeld in het document van het Staatscomité voor Hoger Onderwijs onder de titel:

Momenteel wordt gewerkt aan de voorbereiding van educatieve boeken voor middelbare en hogere scholen. De eerste is al verschenen - een draaiboek voor kinderen in de middelbare schoolleeftijd.

Wat is de drijvende kracht achter het programma? Wat genereert een gunstig resultaat? Natuurlijk, het algoritme. Het algoritme creëert het effect waarvoor het programma is geschreven. Het algoritme werkt niet alleen. Het werkt in combinatie met datastructuren. Maar het zijn de algoritmen die het grootste deel van het programma uitmaken.

Historisch gezien worden algoritmen in programma's geschreven als broncode. Bijna niemand twijfelt eraan dat tekst de beste manier is om algoritmen weer te geven. Een algoritme is gecodeerd binnen functies in een programmeertaal zoals C of JavaScript. Voor wie het algoritme vanuit vogelperspectief wil begrijpen, is een pseudocode voorzien. Er zijn echter ernstige problemen met de tekst. Het punt is dat een persoon niet is geoptimaliseerd voor solide tekst. De mens is geoptimaliseerd voor de perceptie van afbeeldingen. Tekst is een relatief nieuwe uitvinding, maar organismen verwerken al miljoenen jaren grafische informatie.

Op basis hiervan zou het logisch zijn om algoritmen in grafische vorm op te stellen. Kijk naar de ingenieurs. Ze gebruiken overal blauwdrukken. Waarom zijn programmeurs slechter? Ook zij konden blauwdrukken maken voor de algoritmen. Sommigen zullen hier beweren: visueel programmeren is zogenaamd inefficiënt. De UML is onhandig en stroomdiagrammen zijn gemakkelijk in de war te raken. Het is beter om op de traditionele manier te programmeren - met tekst. Bij gestructureerd programmeren is er op zijn minst een structuur, en het zorgt voor orde en consistentie. En bovendien is het tekenen van diagrammen lang en moeilijk. Typen gaat sneller dan tekenen.

Dus zijn programmeurs gedoemd om hun hele leven alleen met tekst te werken?
Het is misschien allemaal niet zo erg. Er zijn visuele talen voor het weergeven van algoritmen die ook orde en structuur hebben, zoals DRAGON, BPMN en LML Action Diagrams. Hier zullen we kijken naar de visuele algoritmische taal DRAGON.

Hoe te programmeren in DRAGON-taal

DRAGON is geen onafhankelijke programmeertaal. Het werkt samen met een op tekst gebaseerde taal zoals JavaScript, Python of C ++. Samen met de teksttaal vormt DRAGON een hybride taal: DRAGON-JavaScript, DRAGON-Python of DRAGON-C++.

Hybride programmeren gaat als volgt:

1. We tekenen een DRAAK-diagram.
2. Plaats kleine stukjes code in de bijbehorende programmeertaal binnen de pictogrammen.
3. De vertaler zet het DRAGON-schema om in een tekstbestand met de broncode.
4. Dit tekstbestand wordt op de gebruikelijke manier in het project opgenomen.
   Verschillende editors ondersteunen momenteel het genereren van code uit diagrammen. De voorbeelden in dit artikel zijn gemaakt in de DRAKON Editor.

Code genereren uit een diagram

In het diagram neemt de DRAAK de controle over de uitvoeringsstroom over. Daarom mogen stukjes broncode in pictogrammen geen trefwoorden bevatten zoals indien, anders, schakelaar, geval, voor, terwijl enzovoort.

Pictogrammen mogen alleen een eenvoudige, ondubbelzinnige code bevatten: rekenkundige uitdrukkingen, waardetoewijzingen, functieaanroepen, vergelijkingen. Maar vertakkingen en lussen worden geïmplementeerd door constructies van de DRAGON-taal.

Het genereren van codes is als volgt:

• Van elk diagram wordt een functie gemaakt.
• De naam van de grafiek wordt de naam van de functie.
• De functieparameters zijn afkomstig van het pictogram "Formele parameters", dat zich rechts van de diagramnaam bevindt.
• De hoofdtekst van de functie wordt gegenereerd op basis van de structuur van het diagram en de inhoud van de pictogrammen.

In afb. 1 toont een voorbeeld van een klein diagram in de hybride taal DRAGON-JavaScript en de gegenereerde JavaScript-code:

Rechthoek met tekst console.log (kat, hond) in afb. 1 is het actiepictogram. Hoeveel code past er in één actiepictogram? Men moet ernaar streven dat één pictogram één gedachte bevat. Soms is het één regel code, soms meerdere.
De gegenereerde code wordt geannoteerd met de pictogramnummers. In de editor kunt u snel naar elk pictogram springen door op Ctrl + I te drukken.

Figuur 1. Het DRAGON-JavaScript-diagram en de daaruit gegenereerde code.

Icoon "Vraag"

De pictogrammen "Vraag" en "Keuze" worden gebruikt voor vertakkingen.

Pictogram "Vraag" (Fig. 2) komt overeen met het ontwerp als dan anders.

Merk op dat in plaats van woorden waar en vals woorden worden gebruikt Ja en Nee(kan worden omgeschakeld naar) Ja en Nee.).

"Truth" en "false" - het klinkt spectaculair, op een wetenschappelijke manier. Een persoon is echter meer vertrouwd met het "ja" en "nee" vanaf de vroege kinderjaren.

Belettering Ja en Nee kan worden verwisseld. De locatie van de uitgangen van het pictogram "Vraag" blijft ongewijzigd. De ene uitgang gaat naar beneden en de andere gaat naar rechts. Vertakkingen in de DRAGON-taal zijn altijd naar rechts gericht, daarom is het verboden om de linkerkant van het pictogram te verlaten. Deze voorspelbaarheid maakt het diagram beter leesbaar omdat de lezer van tevoren weet waar hij naar outputs moet zoeken.

Een ander kenmerk van de DRAGON-taal is dat er geen volledige ruit wordt gebruikt voor vertakkingen, maar een afgeknotte. Dit bespaart ruimte op het diagram.

Visueel logische formules

DRAGON-taal maakt logische operatoren overbodig EN, OF en NIET evenals de niet-gelijke operator. De logische bewerkingen zelf zijn natuurlijk noodzakelijk. Maar in plaats van tekstoperatoren introduceert DRAGON visueel-logische formules.

Om een ​​visueel logische formule te krijgen, moeten verschillende "Vraag"-pictogrammen worden verbonden (zoals in Fig. 3).

Het is vooral prettig om van de ontkenning af te komen. Ontkenning is niet intuïtief; het brengt fouten en ongemak met zich mee. Negatie (logische operator NIET) wordt bereikt in de DRAGON-taal door permutatie van labels Ja en Nee.

De tekstuele notatie van logische uitdrukkingen is zeker compacter. Visuele formules zijn echter gemakkelijker te lezen. Elk van de mogelijke combinaties van operandwaarden kan met een vinger worden getraceerd.

Lus met pijl

Om de gebruikelijke volgorde van uitvoering in de DRAGON-taal aan te geven, zijn pijlen niet nodig. Het volgende icoon staat altijd onderaan. De pijl is alleen nodig als de uitvoeringsdraad omhoog moet springen in het diagram. Zo'n sprong omhoog betekent een cyclus. Daarom is een pijl in de DRAGON-taal een teken van een cyclus. Bij een vluchtige blik op het DRAGON-diagram vallen de pijlen direct op. Hierdoor zijn de cycli direct zichtbaar. Dit is een belangrijk voordeel van DRAGON ten opzichte van andere grafische talen. Je hoeft de lussen niet te vinden.

Dus als je het pictogram "Vraag" verbindt met een pijl, krijg je een cyclus. Dit is een analoog van constructies terwijl en doen terwijl... Figuur 4 toont verschillende soorten pijllussen.
Het pictogram "Vraag" in een lus met een pijl controleert de voorwaarde voor het verlaten van de lus. In plaats van één 'Vraag'-pictogram kunnen er natuurlijk meerdere zijn. Dan is de visueel logische formule verantwoordelijk voor het verlaten van de lus.

Icoon "Keuze"

Het pictogram "Vraag" bevat een logische uitdrukking, dat wil zeggen dat het twee waarden kan aannemen: Ja en Nee... Een typisch voorbeeld is het vergelijken van twee objecten. Als u een bepaalde uitdrukking met meerdere waarden moet vergelijken, wordt het pictogram "Selecteren" gebruikt (Fig. 5). Dit komt overeen met het ontwerp heksenzaak.

De waarden waarmee de uitdrukking in het pictogram "Keuze" wordt vergeleken, worden in de pictogrammen "Variant" geplaatst. Als er geen tekst in de meest rechtse versie staat, betekent dit "alle andere waarden". Zo'n lege optie is vergelijkbaar met het trefwoord standaard binnendienst schakelaar.
De meest rechtse optie kan eindigen met een pijl die naar boven leidt. In dit geval hebben we weer te maken met een pijlcyclus. In een dergelijke cyclus is het pictogram "Keuze" en niet de "Vraag" verantwoordelijk voor de uitgangstoestand.

Icoon "Cyclus VOOR"

In plaats van lussen voor en foreach DRAGON-JavaScript gebruikt het "Loop FOR"-pictogram. Het pictogram "Cyclus VOOR" (Fig. 6) kan van verschillende typen zijn.

Als na het trefwoord foreach en er is één variabele voor de puntkomma, dan wordt er code gegenereerd om over de array te itereren. De elementen van de array (maar niet hun indices) worden in de variabele geplaatst.

Als na het trefwoord foreach er twee variabelen zijn, zal DRAKON Editor begrijpen dat iteratie over objecteigenschappen (hashtabelrecords) vereist is. Alleen de eigen eigenschappen van de objecten worden in de opsomming opgenomen.

De derde versie van de lus impliceert de aanwezigheid van drie uitdrukkingen, gescheiden door puntkomma's. Dit is een traditionele cyclus voor, specifiek voor de C- en Java-talen.

Een vroegtijdige beëindiging van de cyclus onder besturing van het pictogram "Cyclus VOOR" is mogelijk met behulp van het pictogram "Vraag" of "Keuze". Deze uitvoer komt ongeveer overeen met het trefwoord pauze.

Slechts één ingang in de lus

In de DRAGON-taal wordt een beperking opgelegd aan fietsen. Elke cyclus kan slechts één ingang hebben. Het doel van deze beperking is om de leesbaarheid te waarborgen. Deze beperking houdt DRAGON binnen het kader van gestructureerd programmeren, zoals Dijkstra het omschreef.

Meerdere uitgangen van de lus zijn toegestaan, maar er mag maar één ingang zijn. In afb. 7 toont cycli met twee uitgangen. Het is toegestaan. In afb. 8 toont voorbeelden van verboden cycli. Verboden omdat je ze op verschillende manieren kunt invoeren.
Onthoud echter niet hoe deze verboden cycli verschijnen. De DRAKON Editor zal dergelijke lussen automatisch detecteren en een fout genereren.

Afb. 8. Verboden fietsen met twee ingangen

Verschillen met op tekst gebaseerde gestructureerde programmering

Zoals u kunt zien, komen de pictogrammen en macropictogrammen van de DRAGON-taal overeen met de standaardconstructies van tekstueel gestructureerd programmeren. Er zijn echter ook verschillen. Tekst, zelfs met inspringing, is een eendimensionaal object. En het diagram is tweedimensionaal. In het diagram verschijnt een extra vrijheidsgraad, wat de zeggingskracht vergroot. Probeer het bijvoorbeeld eens in een op tekst gebaseerde programmeertaal zonder herhalingen en ga naar beeld een algoritme af zoals in Fig. negen.

Ondanks de extra vrijheid in vergelijking met de tekst, laat de DRAAK zich nog steeds niet in anarchie vervallen. De regels zijn streng genoeg om verwarring te voorkomen. DRAGON biedt een redelijk compromis tussen flexibiliteit en nauwkeurigheid.

Voordelen van een grafische taal

De DRAGON-taal heeft een interessant lot. De uitgangspunten zijn door Dijkstroy zelf vastgelegd. DRAGON verwierf zijn huidige vorm in de diepten van de Russische ruimtevaartindustrie. Het is opmerkelijk dat de regels van de DRAGON-taal niet toevallig zijn ontstaan. Ze werden eerst getest in focusgroepen en vervolgens aangescherpt in echte ruimteprojecten.
Dus wat zijn precies de sterke punten van de DRAGON?

Laten we beginnen met het feit dat DRAGON een grafische taal is. En de grafische taal heeft fundamentele voordelen ten opzichte van tekst.

Ten eerste zijn gedachten niet willekeurig verspreid over lijnen, maar zijn ze ingesloten in vierkanten of pictogrammen. Eén gedachte - één vierkant. Verschillende gedachten gaan niet samen.

Ten tweede kan het pad door het algoritme worden getraceerd met een vinger (of een blik). Na indien niet nodig om te zoeken anders... Volg de lijn en u bevindt zich op het gewenste plein. U hoeft uw ogen niet door de broncode te spitten op zoek naar een antwoord op de vraag: wat gebeurde er daarna?

En grafieken hebben ook een bijna magische eigenschap. Het komt voor dat een persoon naar een diagram kijkt en plotseling komt er wat extra begrip. Voorheen onzichtbare verbanden worden zichtbaar. Dit gebeurt zelden met tekst.

Speciale ergonomische regels

Maar DRAGON zijn niet zomaar diagrammen, het zijn uitgebreide diagrammen. DRAGON-diagrammen zijn gemakkelijker te lezen dan gewone stroomdiagrammen. Dit wordt verzekerd door speciale ergonomische trucs. Hier zijn er enkele.

• Het overschrijden van lijnen is verboden. Over het algemeen. Kruispunten doen onze visuele analysator vermoeden dat de lijnen elkaar raken en daarom op de een of andere manier met elkaar verbonden zijn. Deze vermoedens zorgen voor extra mentaal werk. Onnodig werk moet worden weggegooid.
• Het begin bevat de naam van het algoritme en bevindt zich altijd in de linkerbovenhoek van het diagram. Daarom is het niet eens nodig om naar het begin te zoeken. Het is waar het meestal is.
• Het diagram heeft slechts één uiteinde. Wat er onderweg ook gebeurt (behalve uitzonderingen), we komen altijd aan het einde.
• Alleen rechte lijnen zijn toegestaan. Geen bochten, geen bochten of onnodige knikken.
• Alleen strikt verticale en strikt horizontale lijnen zijn toegestaan. Schuine lijnen zijn verboden. Uitleg voor wiskundeliefhebbers: Het DRAGON-diagram is een platte rechthoekige grafiek (Manhattan-grafiek). Het menselijke visuele apparaat grijpt onmiddellijk objecten die zijn verbonden door rechte orthogonale lijnen. Bijhouden waar de American Dream Curve toe leidt, vereist echter extra concentratie van de lezer.
• DRAGON-schema wordt van boven naar beneden uitgevoerd. Deze regel vermijdt de noodzaak om verwoed het diagram met uw ogen te scannen op zoek naar het volgende pictogram. Het volgende icoon staat altijd onderaan. De ingang is aan de bovenkant en de uitgang is aan de onderkant. Omdat we weten waar het volgende pictogram is, zijn de pijlen niet nodig. Eenvoudige lijnen zijn voldoende. De pijlen naast elk pictogram vertegenwoordigen visuele ruis. Nadat je de taak van het verbinden van pictogrammen van de pijlen hebt verwijderd, kun je ze een speciale missie toewijzen. In de DRAAK betekent een pijl een cyclus.
• Vertakking vindt alleen rechts plaats. Dit is een enorme hulp in termen van voorspelbaarheid en consistentie.
• Pictogrammen die zich op dezelfde verticale lijn bevinden, moeten dezelfde breedte hebben. Dit geeft het gevoel dat de iconen tot één geheel behoren. Wanneer iedereen dezelfde breedte heeft en er geen beginnende pictogrammen zijn, glijdt het oog gemakkelijk en vrij over het diagram.

Bovenstaande regels zijn van grote praktische waarde. Enerzijds zijn ze bedoeld om de waanzin van de kunstenaar te beteugelen. Het is moeilijker om er een verwarrend diagram mee te maken. Aan de andere kant brengen ze bewustzijn naar grafieken. Diagrammen worden niet alleen begrijpelijk voor hun auteurs.

De diagrammen in Fig. 10 en 11 demonstreren de ergonomische technieken van de DRAGON-taal aan de hand van echte voorbeelden.

Afb 11. Nog een voorbeeld van een diagram in de DRAGON-taal
Naast ergonomische technieken heeft de DRAGON-taal unieke eigenschappen die nergens anders te vinden zijn.

Hoe meer naar rechts, hoe slechter

DRAGON heeft een middel voor de afbeelding gelukkig pad, of Koninklijke weg... The Tsar's Road is de meest succesvolle weg door het algoritme. In sommige algoritmen zijn de begrippen "goed/slecht", "goed/slecht" niet van toepassing. Daarin toont de koninklijke weg het meest verwachte pad. De Royal Road loopt verticaal, aan de linkerkant van het diagram. Deze verticaal wordt een spies genoemd. Minder waarschijnlijke en minder succesvolle scenario's, evenals foutafhandeling, worden aan de rechterkant van het diagram geplaatst. Bovendien, hoe slechter de situatie, hoe meer naar rechts het zou moeten worden geplaatst. Het is een goede gewoonte om code die een uitzondering genereert of een foutcode teruggeeft aan de rechterkant van het diagram te plaatsen.

gemeenschappelijk lot

Soms gebeurt het dat het op verschillende paden door het algoritme nodig is om verschillende, maar op de een of andere manier gerelateerde acties uit te voeren. Zet bijvoorbeeld verschillende waarden in één variabele. Gedeelde bestemming is wanneer gerelateerde acties op verschillende verticale lijnen zitten, maar op dezelfde horizontale.

Rijst. 12 toont een spies met een koninklijke weg, evenals de toepassing van de "common destiny"-techniek.

Silhouet

Het silhouet is een echte DRAGON-diamant. Met Silhouette kunt u een diagram opsplitsen in logische delen. Bij het programmeren wordt hiervoor meestal decompositie met behulp van subroutines gebruikt. Subroutines zijn een krachtige methode. Maar soms wil ik de subroutine visueel dicht bij het hoofdprogramma plaatsen, en de rommel vermijden met het doorgeven van parameters en het retourneren van waarden. Een silhouet is geweldig voor deze doeleinden. Een ander gebruik van silhouet is in eindige-toestandsmachines. Maar daar zullen we het elders over hebben.
Het komt voor dat het algoritme niet kan worden ontleed in een vlak, zodat er geen snijpunt van lijnen is. In dit geval wordt, afhankelijk van de situatie, ofwel ontleding met behulp van subroutines of silhouet toegepast.

Het silhouet bestaat uit verschillende kleine diagrammen die in één integraal blok zijn verbonden. Deze kleine diagrammen worden silhouettakken genoemd. Bovenaan elke vestiging bevindt zich het pictogram "Branch Head", hieronder het pictogram "Adres". De naam van dit filiaal wordt in de kop van het filiaal geplaatst en de naam van het volgende filiaal wordt in het adres aangegeven. De namen van de takken bevinden zich op een enkele horizontale lijn bovenaan het diagram. Hierdoor kunt u de essentie van het algoritme begrijpen door alleen door de branch-headers te lopen. Het silhouet beantwoordt drie koninklijke vragen:

1. Wat is de naam van het probleem?
2. Uit hoeveel onderdelen bestaat het?
3. Hoe heten deze onderdelen?

Beschouw het voorbeeld in Fig. 13. Hier zijn de antwoorden op de vragen van de koning:

1. Wat is de naam van het probleem? Orden de gekoppelde lijst.
2. Uit hoeveel onderdelen bestaat het? Van de vier.
3. Hoe heten deze onderdelen? Bouw een matrix van links. Controleer op cycli. Doorloop de matrix van verbindingen. Vervolledigen.

Afb. 13. DRAGON-schema "silhouet"

Silhouet cyclus

De takken van het silhouet moeten van links naar rechts worden gerangschikt. In sommige gevallen moet u een vertakking of groep vertakkingen meerdere keren uitvoeren. Dit ontwerp wordt een silhouetlus genoemd. Als het pictogram "Adres" naar zijn eigen filiaal wijst, of naar een filiaal dat zich aan de linkerkant bevindt, moet dit worden gemarkeerd met een speciaal label. Dezelfde markering moet worden geplaatst op het overeenkomstige pictogram "Branch's head" (zie fig. 14). Het doel van het label is om de silhouetlus zichtbaar te maken.

Het aansluiten van silhouettakken is verboden

Verbindingen van twee takken van het silhouet (zoals in Fig. 15) zijn verboden. Elke tak binnen het silhouet moet onafhankelijk zijn.

Maattabellen

Bij het programmeren in de DRAGON-taal rijst de vraag: hoe groot moeten de diagrammen zijn? Het antwoord is: hoe minder, hoe beter. Hoe minder objecten in de visuele scène, hoe duidelijker het is. Bij tekstgebaseerd programmeren is er zo'n referentiepunt: het is goed als de hele functie op het scherm past. Soortgelijke adviezen kunnen worden gegeven voor DRAGON-regelingen. Vermijd enorme grafieken. Wanneer het hele algoritme volledig zichtbaar is, is het veel gemakkelijker te begrijpen.
Voor DRAGON-programmering is het niet beter om een ​​grote monitor te hebben. Minimaal 1080 pixels hoog. Dan hoef je de DRAGON-schema's niet kunstmatig in te korten.

DRAGON-schema silhouet moet in de hoogte op het scherm passen, maar niet noodzakelijk in de breedte. diagrammen silhouet kan behoorlijk breed zijn, veel breder dan 2000 pixels. Dit is goed. Het is niet nodig om alle takken van het silhouet tegelijk te zien. Het belangrijkste is dat de branch waarmee je werkt volledig zichtbaar is op het scherm.

Kritiek op DRAGON-programmering

Laten we eens kijken naar de belangrijkste kritieken op het programmeren op de DRAGON en proberen er een antwoord op te geven.

• "DRAGON-diagrammen nemen meer schermruimte in beslag dan tekstverwerkingsprogramma's." Dit is waar. Maar we moeten niet vergeten dat het de taak van de DRAAK is om de complexiteit te laten zien zoals die is. De lezer van het programma moet geen complexe structuren in zijn hoofd uitpakken. Ze moeten hem expliciet worden getoond.
• "Eenvoudige algoritmen zien er beter uit in tekstvorm." Misschien. Hallo wereld ziet er elegant uit in elke taal. Maar in het echte leven is niet alles eenvoudig. Zodra er minstens één verschijnt indien genest in een ander indien, DRAAK wint.
• "DRAGON heeft geen mogelijkheid om uitzonderingen weer te geven." Er is zo'n probleem. Er zijn onlangs uitzonderingen toegevoegd aan de DRAGON-taal, maar niet alle implementaties ondersteunen deze. Totdat de implementaties op tijd komen, kun je try/catch-blokken schrijven in de juiste programmeertaal.
• "DRAGON-schema's duren lang om te tekenen." Het is veel gemakkelijker om DRAGON-diagrammen te tekenen in gespecialiseerde editors dan bijvoorbeeld in Visio. En in sommige ervan is tekenen bijna net zo gemakkelijk geworden als schrijven.
• "Er zijn geen tools voor diff en merge." Dit is helaas het geval. Wanneer u met een versiebeheersysteem werkt, moet u de gegenereerde bronbestanden vergelijken.
• "Er zijn geen DRAGON-schematische debugging-tools." Dit is waar. Maar u kunt de gegenereerde code debuggen. Het heeft labels die aangeven waar in het diagram een ​​bepaald stuk code thuishoort.

Dragon-taaloverzicht

Afbeelding 16 geeft een overzicht van de DRAGON-taal.

Dragon-taalhulpmiddelen

De allereerste implementatie van de DRAGON-taal was het GRAPHITE-FLOKS-systeem (Fig. 17). GRAPHITE-FLOX werd opgericht in 1986-1996. door specialisten van FSUE NPT's AP hen. Pilyugin onder leiding van V.D. Parondzjanova. Deze omgeving was bedoeld voor het ontwerpen van besturingssystemen voor draagraketten en ruimtevaartuigen.

GRAPHITE-FLOX is een gesloten ontwikkeling, dus er is relatief weinig over bekend. De lijst met ruimtevaartuigen die met GRAFIT-FLOX zijn gemaakt, kan worden bekeken.

Begin jaren 90 werd er nog een DRAGON-editor gemaakt. De ontwikkeling vond plaats bij het Instituut voor Toegepaste Wiskunde vernoemd naar M.V. Keldysh onder leiding van L.K. Eisymont. De Eisymont-editor (Fig. 18) kan worden gedownload en uitgevoerd, maar wordt niet langer ondersteund. De editor is geschreven onder MS DOS, dus DOSBox kan nodig zijn om op moderne computers te draaien.

In 2008 werd de redacteur van IS Dragon van Gennady Tyshov vrijgelaten (Fig. 19). IS Dragon wordt actief ondersteund en ontwikkeld. IS Dragon implementeert het genereren van programmacode uit diagrammen. Een van de interessante eigenschappen van IS Dragon is de mogelijkheid om een ​​code in een programmeertaal en een beschrijving in een natuurlijke taal in één icoon te plaatsen. De absolute verdienste van IP Dragon is de zogenaamde "calculus of iconen". Icon calculus is een bewerkingsmethode die de gebruiker helpt een diagram te tekenen en ervoor zorgt dat het diagram de regels van de DRAGON-taal niet schendt. Een van de nadelen van IS Dragon is een niet-standaard gebruikersinterface en enkele ongemakken bij het genereren van code. IP Dragon is een commercieel product.

DRAKON Editor is een andere moderne DRAGON-editor (afb. 20). DRAKON Editor is ontwikkeld door een groep enthousiastelingen onder leiding van Stepan Mitkin. DRAKON Editor ondersteunt geen pictogramberekening. Dit betekent dat DRAGON-schema's er handmatig in worden samengesteld uit primitieven, zoals in vector grafische editors. Maar aan de andere kant is de gebruikersinterface in DRAKON Editor zo eenvoudig mogelijk. Het is gebouwd volgens een bekender schema dan IS Dragon. Het belangrijkste voordeel van de DRAKON Editor-omgeving is het gemak van programmeren en het genereren van code. DRAKON Editor ondersteunt meerdere programmeertalen waaronder C, C++, C#, Java, Processing, JavaScript, Lua, Erlang, Python, Tcl, Verilog, AutoHotkey, D en Go. Voor sommige talen is het mogelijk om statusmachines te genereren. De regels voor het nools expert systeem worden ondersteund. Een subset van de UTOPIST E. Tyugu-taal geïmplementeerd. DRAKON Editor is open source.

Een interessante toepassing voor de DRAGON-taal is uitgevonden door Oleg Garipov in zijn Integrator CodeView-project. Met CodeView kunt u bestaande code visualiseren als een onderling verbonden set DRAGON-schema's. De eigenaardigheid van de Integrator CodeView is dat niet individuele methoden worden gevisualiseerd, maar het hele project, inclusief de oproepgrafiek, stapel, enz. De Integrator CodeView is ook uniek omdat het niet alleen algoritmen, maar ook gegevens visueel toont. De datavisualisatie-engine in het Integrator-systeem werkt samen met DRAGON.

DRAKON Editor Web is een commerciële cloudoplossing gebaseerd op de DRAGON-taal. DRAKON Editor Web is ontworpen voor technische specificaties, bedrijfsprocedures en checklists. DRAKON Editor Web is op geen enkele manier gelieerd aan DRAKON Editor en ondersteunt het genereren van code uit diagrammen niet. Tot de voordelen van DRAKON Editor Web behoren een handige editor, samenwerking en ondersteuning voor mobiele apparaten.

Afb. 18. DRAGON Editor Eisymont

Afb 19. Programma met uitleg in IS Dragon

Afb. 20. DRAKON-editor

conclusies

Laten we samenvatten. DRAGON is een praktische taal gehard in de ruimte. Hij bracht structuur, orde en consistentie in stroomdiagrammen. De voorspelbaarheid en netheid van DRAGON-schema's leiden ertoe dat visuele programmering werken.

De ervaring van echte projecten heeft geleerd dat je niet kunt programmeren op de DRAGON. Enerzijds is DRAGON expressiever dan tekst. Anderzijds verhoogt het de leesbaarheid van programma's. En bovendien zien programma's in de vorm van DRAGON-schema's er, nou ja, net uit als van een buitenaards ruimteschip (hoewel veel afhangt van het kleurenschema). Persoonlijk schakelde ik gemakkelijk over naar DRAGON. Het is onhandig als je daarentegen soms in de traditionele tekststijl moet programmeren.

Laatst bewerkt door PBworks 12 jaar, 2 maanden geleden

VRIENDELIJK PROGRAMMEREN

DRAGON-SE HYBRIDE PROGRAMMEERTAAL

Stel dat u een visueel programmeersysteem moet bouwen in de hybride taal DRAGON-SI. Het probleem kan bijvoorbeeld worden opgelost met behulp van drie programma's: een drakeneditor, een drakenconverter en een C-taalcompiler. Met behulp van de drakeneditor tekent de gebruiker op het computerscherm een ​​programma in de DRAGON-SI-taal (Fig. 90, rechterkolom). Vervolgens zet de dragon-converter de interne weergave van de grafische codes om in de brontekst van de C-taal (Fig. 90, middelste grafiek), waarna de standaard C-compiler de brontekst omzet in objectcode.

Dus om de DRAGON-SI-taal te bouwen, is het volgens bepaalde regels noodzakelijk om de visuele syntaxis van de DRAGON te combineren met de tekstuele syntaxis van de SI-taal, waarbij alle elementen waarvan de functies worden geïmplementeerd door de SI-taal worden verwijderd. visuele DRAGON-operators. Een talenpaar SI en DRAGON-SI is equivalent in die zin dat er een converter kan worden gebouwd die zowel directe als inverse conversie uitvoert. Zo'n converter kan de broncode van een programma in de DRAGON-SI-taal (Fig. 90, rechterkolom) omzetten in een equivalent SI-programma (Fig. 90, middelste kolom), en vice versa.

De creatie van een hybride taal (bijvoorbeeld DRAGON-SI) kan nauwelijks als een originele ontwikkeling worden beschouwd, aangezien deze laatste het concept, de structuur, de gegevenstypen en andere kenmerken van de oorspronkelijke taal (SI) bijna volledig behoudt. Het is juister om te zeggen dat de constructie van een hybride taal (DRAGON-SI) een techniek is waarbij in een strikt gedefinieerd aantal gevallen de tekstuele notatie van de brontaal wordt vervangen door een visuele. Deze techniek kan echter het ergonomische uiterlijk van de oorspronkelijke taal aanzienlijk verbeteren.

HYBRIDE PROGRAMMEERTAAL

DRAAK-MODULA

Laten we eens kijken naar het bovenste voorbeeld in Fig. 91. In de middelste kolom staat een programma in de taal MODULA-2, rechts - een equivalent programma in de taal DRAGON-MODULA. De linkerkolom bevat een lijst met trefwoorden die in het moduleprogramma worden gebruikt en die "essentieel" zijn voor de MODULA-taal, maar die in het drakenprogramma volledig overbodig zijn.

Vanuit ergonomisch oogpunt zijn deze en vele andere trefwoorden die aanwezig zijn in teksttalen niets meer dan visuele stoornissen die de aandacht van de lezer trekken en zijn aandacht afleiden van de inhoudelijke kant van de zaak. Het ergonomische voordeel van de DRAGON is dat in plaats van trefwoorden een visueel beeld wordt gebruikt, dat door de lezer onbewust, op een intuïtief niveau wordt waargenomen, terwijl het kanaal van bewuste aandacht productiever werkt - voor de perceptie van de belangrijkste, betekenisvolle aspecten van de taak.

VOORBEELD ERGONOMISCHE OPTIMALISATIE

PROGRAMMA'S

In afb. 91 (onder, in de middelste kolom) is een programma geschreven in de PASKAL-taal. Naar analogie van de voorgaande voorbeelden kan het eenvoudig worden omgezet in een programma in de DRAGON-PASKAL-taal. Om dit te doen, tekent u een visuele operator met een "vork" en plaatst u een record in het pictogram "vraag"

Markeer de onderste uitgang van het "vraag"-pictogram met het woord "ja" en bevestig een schakelaar met twee "optie"-pictogrammen, en sluit de rechteruitgang (het antwoord is "nee") aan op het "uitvoer"-pictogram, in die we bovenaan SCHRIJVEN en eronder ERROR. Als resultaat krijgen we een drakenschema, wat ongetwijfeld de absoluut juiste oplossing is voor de taak die voorhanden is. (Voor de duidelijkheid raden we de lezer aan om de beschreven constructies op papier in te vullen.)

Laten we nu de toestand van het probleem veranderen. Laten we proberen een programma te maken dat niet alleen equivalent is aan het pascal-programma in Fig. 91, maar ook ergonomisch optimaal voor de Russisch sprekende lezer. Het benodigde programma, geschreven in de DRAGON-2-taal, wordt in dezelfde afbeelding rechtsonder weergegeven.

Opvallend is het structurele verschil tussen de opleidingen. Het Pascal-programma bevat twee constructies: als dan anders en sprake van... Ergonomische optimalisatie bestaat uit het feit dat het drakenprogramma slechts één visuele operator gebruikt (een schakelaar met drie opties), die toch “alleen” dezelfde functies vervult als twee tekstoperators van de PASCAL-taal. Als resultaat worden de complexe toestand K = 1 OF K = 2 en andere excessen van het Pascal-programma geëlimineerd, en het drakenschema wordt merkbaar vereenvoudigd en wordt laconiek, transparant en elegant.

DIALOOGPROGRAMMA'S

Laten we doorgaan met de presentatie van een van de mogelijke benaderingen voor de constructie van de programmeertaal DRAGON-2. Laten we u er nogmaals op wijzen: de lezer zal hier geen beschrijving van de taal vinden. Ons doel is veel bescheidener: om aan te tonen dat de formalisering van de tekstsyntaxis voor de DRAGON-taal heel goed mogelijk is, en om verschillende voorbeelden te geven die dit idee bevestigen.

Overweeg de dialoogprogramma's in Fig. 92 en 93, die didactische (pedagogische) kenmerken hebben verbeterd. Hiervoor wordt gebruik gemaakt van een uitgebreide set ergonomische hulpmiddelen. Gebruik in het bijzonder bij het invullen van het commentaarpictogram tekst zonering... Om de waarneming te vergemakkelijken, is de tekst van het commentaar ruimtelijk verdeeld in twee zones, die ten eerste duidelijk gedefinieerde en gemakkelijk te onderscheiden grenzen hebben en ten tweede verschillen ze in de achtergrondkleur (wit en grijs). Het grijze gebied bevat de tekst die op het computerscherm verschijnt, in het witte gebied - uitleg daarvoor. Door tekst op het scherm te scheiden van uitleg, worden opmerkingen gemakkelijker te lezen en te begrijpen.

De ergonomische techniek van "tekstzonering" is niet alleen nuttig in opmerkingen, maar ook in andere gevallen, bijvoorbeeld in I / O-verklaringen.

Operator "Bericht"

De operator "Message" wordt gebruikt om informatie op het computerscherm weer te geven. Het bevat een pictogram "uitvoer", op de bovenste verdieping waarvan het trefwoord "Bericht" is geplaatst, onderaan - de uitvoerinformatie. Bij het beschrijven van de laatste wordt tekstzonering gebruikt: in de grijze zone schrijven ze de namen van variabelen of uitdrukkingen (waarvan de waarden op het scherm moeten worden weergegeven), in de witte zone - permanente informatie (die wordt weergegeven op het scherm zonder wijzigingen). Een zwarte cirkel dient als teken van een nieuwe lijn. Bijvoorbeeld in afb. 92 met behulp van de operator "Message" worden de zin "De som van de getallen is gelijk" en de waarde van de uitdrukking m + n op het scherm weergegeven.

Operator "Verzoek"

De operator "Verzoek" voert de waarden van variabelen in de computer in, geeft permanente informatie, namen van variabelen en ingevoerde waarden weer. In het bovenste gedeelte van het "invoer"-pictogram schrijven ze het trefwoord "Verzoek", in het onderste gedeelte - de invoer- en uitvoerinformatie. Ook is er zonering van de tekst: in de grijze zone worden de namen van de in de computer in te voeren variabelen aangegeven, in de witte zone wordt de permanente informatie geplaatst.

Stel dat u de waarden m = 23 en n = 45 wilt invoeren (Figuur 92). Dit gaat bijvoorbeeld als volgt: verplaats de cursor naar de zone m, typ het cijfer 23 op het toetsenbord en druk op de "carriage return"-toets. In dit geval gaat de zone m op het scherm uit en in plaats daarvan brandt het getal 23. De waarde van n wordt op dezelfde manier ingevoerd. De operator "Verzoek" vraagt ​​de gebruiker dus om de waarden van de variabelen, schrijft ze in het geheugen en geeft ze tegelijkertijd op het scherm weer samen met permanente informatie (als deze laatste wordt aangegeven op de onderste verdieping van de operator "Verzoek" in de witte zone).

Beschrijving van gegevens

Het "plank"-pictogram wordt gebruikt om de gegevens te beschrijven. Op de bovenste verdieping schrijven ze het trefwoord "Data", onderaan - een beschrijving van de gegevens. Bijvoorbeeld in afb. 92, geeft het "plank"-pictogram aan dat de variabelen m en n van het "integer"-type zijn.

Een andere manier kan worden voorgesteld: de beschrijving van de gegevens wordt uit het drakenschema gehaald en in een aparte tabel geplaatst.

IDENTIFICATIES

Hier zijn de regels voor het schrijven van identifiers.

• De lengte van de identifier is 1 ... 32 tekens.
• Het is toegestaan ​​om Russische en Latijnse letters, cijfers, punten en eventueel speciale tekens te gebruiken.
• Het eerste teken moet een letter zijn (geen cijfer of punt).
• Spaties zijn niet toegestaan ​​in de identifier.
• Scheid woorden met punten om ze beter leesbaar te maken.
• Het is verboden woordafkortingen te gebruiken als de identifier minder dan 32 karakters lang is.
• Als de identifier langer is dan 32 tekens, moet u enkele woorden vervangen door afkortingen of het aantal woorden verminderen.
• Men moet ernaar streven om begrijpelijke identifiers te bedenken die het gemakkelijk maken om de betekenis van het concept te begrijpen, zodat de lezer snel de essentie van de zaak begrijpt.

Voorbeelden van correcte identifiers

Nummer van de snelle treinwagon

Aantal.wagon.passagierstrein

Prijs van een treinkaartje naar Magadan

Prijs vliegticket naar Magadan

Voorbeelden van ongeldige ID's

Een voorbeeld van het verkorten van de lengte van een complex concept

Stel dat u een identifier wilt maken voor het volgende concept: "Radiusvector van het middelpunt van de aarde in het middelpunt van de baan in het landingscoördinatensysteem." De verbale beschrijving van het concept bevat 92 symbolen. De uitdaging is om de beschrijving van 92 tekens terug te brengen tot 32 tekens en tegelijkertijd de betekenis van het concept zo duidelijk mogelijk te houden.

De reductie zal worden uitgevoerd volgens het volgende plan:

• “Radius-vector van het middelpunt van de aarde” wordt vervangen door “Radius.Earth”.
• In plaats van "In het midden van de baan" schrijven we "op de baan".
• We zullen "In het landingscoördinatensysteem" vervangen door UCS, aangezien een dergelijke afkorting vaak wordt gebruikt in het team van ontwikkelaars van dit systeem.

Als resultaat krijgen we een identificatiecode van 26 tekens

die bijna alle sleutelwoorden van het oorspronkelijke concept behoudt en een redelijk hoog begrip biedt.

Regels voor het schrijven van rekenkundige uitdrukkingen

in opdracht operators

Er moet een onderscheid worden gemaakt tussen twee gevallen. Als de uitdrukking eenvoudig is, wordt aanbevolen om identificatiecodes van 32 tekens en "verticale" notatie van wiskundige formules te gebruiken, zoals weergegeven in Fig. 94 en 95.

Als het echter gaat om complexe wiskundige berekeningen, is de beschreven methode niet geschikt, omdat "verticale" formules met identificatiecodes van 32 tekens de lezer niet in staat stellen de wiskundige structuur van berekeningen te zien, waardoor zijn aandacht wordt afgeleid naar het lezen van lange identificatiecodes, die paradoxaal genoeg veranderen van een nuttige hint in hun tegendeel en beginnen een negatieve rol van visuele interferentie te spelen. Zo ontstaat een ergonomische doodlopende weg: met korte identifiers kun je niet snel de betekenis van concepten begrijpen, en lange identifiers verdoezelen de structuur van complexe formules.

Als een van de mogelijke manieren om deze Gordiaanse knoop ongedaan te maken, kan een driepuntenplan worden voorgesteld.

• Voor elk wiskundig concept worden twee identifiers gegeven: lang (32 tekens) en kort (alias).
• In rekenkundige uitdrukkingen worden alleen aliassen gebruikt, wat de structuur van de formules transparant maakt.
•  Aan het begin van het programma is er een "commentaar"-pictogram, dat een tabel bevat met overeenkomsten tussen aliassen en lange identifiers. Deze tabel speelt de rol van een spiekbriefje, dat zich in hetzelfde gezichtsveld bevindt als de opdrachtoperators en waarmee u snel kunt onthouden wat deze of gene alias betekent.

ARRAY VERWERKING:

In afb. 94 en 95 zijn voorbeelden van programma's waarin bewerkingen met arrays plaatsvinden.

De beschrijving van de gegevens wordt op de onderste verdieping van het "plank"-pictogram geplaatst.

betekent dat er een eendimensionale array is met de naam "Konijngewicht" die 100 elementen bevat, die elk een reëel getal zijn.

Het kernelement van beide programma's is de FOR-lus. Laten we eens kijken naar de regels voor het ontwerpen van een cyclus. In het pictogram "begin van cyclus FOR" in de bovenste regel schrijven ze het woord "Cyclus" en na een spatie een alias van één teken die de cyclusvariabele aangeeft (letter k in Fig. 94, 95). De onderste regel geeft het bereik van de wijziging aan, bijvoorbeeld

Het identiteitsteken ≡ geeft aan dat het wordt gevolgd door een naamcommentaar, dat wil zeggen een opmerking die is geschreven volgens de regels voor het schrijven van identifiers.

Het ergonomische 'vet' van geformaliseerd commentaar heeft twee voordelen. Ten eerste kun je de traditionele "vergetelheid" van programmeurs elimineren en de lezer menselijk uitleggen wat de betekenis is van een abstracte identifier: zeg, k is het nummer van een konijnenkooi. Ten tweede, en belangrijker, wordt de uitleg precies daar op het tekenveld geplaatst waar het nodig is (in het icoon “het begin van de cyclus VOOR”), volgens het principe “lief ei voor Christusdag”. Dit betekent dat de lezer onmiddellijk een antwoord krijgt - op het moment dat hij de alias k voor het eerst zag en de vraag in zijn hoofd opkwam: wat is k?

In het icoon “einde cyclus VOOR” maken ze een record

De betekenis van de operators die de verwerking van arrays organiseren, is duidelijk uit Fig. 94 en 95 en spreekt voor zich.

ABSTRACTE DRAKEN SCHEMA'S

In deze sectie zullen we de transformatie van een visueel programma in de DRAGON-2 taal naar een tekstprogramma in BASIC beschouwen. Deze transformatie is op twee manieren nuttig: het stelt je in staat om een ​​dieper inzicht te krijgen in de essentie van de visualisatie en om vertrouwd te raken met het belangrijke concept van het abstracte drakenschema.

Laten we als voorbeeld een schoolcurriculum nemen met de naam "Raadspel" en dit in de DRAGON-2-taal schrijven (Fig. 96). Dan verwijderen we de tekst er volledig uit en krijgen een teken-molrat, die "abstract drakenschema" wordt genoemd (Fig. 97). Dit schema is een programma-invariant die in twee stappen kan worden omgezet in een programma in elke programmeertaal.

Laten we de BASIC-taal als ons doel kiezen en aan de slag gaan. Vul bij de eerste stap de lege pictogrammen van het abstracte schema in met BASIC-tekst. Het resultaat is een equivalent programma in de DRAGON-BASIC-taal (Fig. 98). Bij de tweede stap wenden we ons tot het gebruikelijke BASIC-programma (we kozen bewust voor de ouderwetse versie van BASIC om het gebruik van goto-statements voor verschillende doeleinden te demonstreren bij het beschrijven van het equivalent van een drakenprogramma) - zie fig. 99.

DE FILOSOFIE VAN DE DRAAKAAL

Elke imperatieve taal (SI, PASCAL, ADA, MODULA, BASIC, enz.) kan worden onderverdeeld in drie delen, drie relatief onafhankelijke talen: route, commando en declaratief.

Routeringstaal- een set van beherende operators. Bevelstaal bevat alle niet-beheersoperatoren, zoals toewijzingsoperator, regels voor het schrijven van rekenkundige en logische uitdrukkingen, identifiers, trefwoorden, enz. declaratieve taal dient om gegevens, klassen, enz. te beschrijven.

Laten we uitleggen wat er is gezegd met een voorbeeld. Het abstracte drakendiagram getoond in Fig. 97, is er een "zin" van de routeringstaal. Om het zinvol te maken, moet tekst binnen de pictogrammen worden geplaatst. Deze tekst is geschreven in commandotaal. Soms is het echter raadzaam om de beschrijvingen van gegevens en klassen buiten het drakenschema te plaatsen en ergens anders te plaatsen, bijvoorbeeld in de vorm van een apart record of een aparte tabel.

Daarom volgt het principe van het onderscheiden van drie subtalen. De routeringstaal is de taal van "afbeeldingen" (abstracte drakenschema's waarin helemaal geen tekst is). De commandotaal wordt gebruikt om tekst op te nemen binnen het drakenschema, declaratief - voor die records die erbuiten genomen kunnen worden.

Bij het construeren van de volgende taal van de drakenfamilie, kun je op elke manier de commando- en declaratieve subtalen kiezen (lenen uit andere talen of opnieuw uitvinden). Dit biedt een schat aan DRAGON-mogelijkheden en flexibele aanpassing voor verschillende toepassingen. De drakenfamilie heeft dus slechts één starre link - de routeringstaal, die niets meer is dan de visuele componenten van de DRAGON (visuele syntaxis en semantiek).

De routeringstaal is een visuele standaard voor de drakenfamilie, die wordt onderhouden door de visuele drakeneditor (zie hoofdstuk 14), die klein en gemakkelijk te onthouden is. Hij is het onveranderlijke kenmerk van de DRAAK, zijn gestandaardiseerde visuele afbeelding (afb. 97).

KENNISCLASSIFICATIE

Elk programma is een bepaalde hoeveelheid kennis die kan worden onderverdeeld in een imperatief en een declaratief deel. Bovenstaande overwegingen maken het mogelijk deze stelling te verduidelijken. Een nieuwe kijk op het probleem wordt gepresenteerd in Fig. 100 en komt hier op neer:

•  Om de kennis in de brontekst van een computerprogramma dat in een imperatieve taal is geschreven te analyseren, is het raadzaam om twee classificaties te gebruiken: basis en alternatief. / Li>
• Basisclassificatie bestaat in het feit dat alle kennis in het oorspronkelijke programma is verdeeld in imperatief en declaratief.
• Op zijn beurt wordt imperatieve kennis onderverdeeld in management- en commandokennis.
• Als criterium voor een alternatieve classificatie wordt de volgende vraag voorgesteld: welke middelen kunnen beter worden gebruikt om kennis weer te geven - afbeeldingen of tekst?
• Het antwoord is als volgt. Het is beter om afbeeldingen (routeringstaal) te gebruiken om besturingskennis weer te geven, en tekst voor commando- en declaratieve kennis.
• In een alternatieve classificatie wordt kennis dus verdeeld in visueel (controle) en tekst (commando en declaratief).

Ten slotte voegen we toe: het gebruik van tekst om complexe besturingskennis weer te geven lijkt net zo belachelijk als het proberen om een ​​geografische kaart in woorden te beschrijven. Dat er nog steeds tekst voor dit doel wordt gebruikt, kan maar door één ding worden verklaard: programmeren is veel jonger dan aardrijkskunde!

CONCLUSIES

1. Als we een formele visuele syntaxis tot onze beschikking hebben, volstaat het om een ​​formele tekstsyntaxis te bouwen om een ​​visuele programmeertaal te bouwen. We hebben ervoor gezorgd dat dit probleem volledig oplosbaar is, en wel op verschillende manieren. Als gevolg hiervan wordt een familie van programmeertalen gevormd, zowel origineel (DRAGON-2) als hybride (DRAGON-SI, DRAGON-MODULA, DRAGON-PASKAL, DRAGON-BASIC, etc.).
2. Er kan worden gesteld dat de begrijpelijkheid van beeldtalen aanzienlijk hoger is dan de begrijpelijkheid van hun tekstuele tegenhangers. Daarom, in alle gevallen waarin begrijpelijkheid wordt beschouwd als het belangrijkste criterium voor de kwaliteit van programma's (en er zijn veel van dergelijke gevallen), zijn visuele talen buiten competitie. Een waarschuwing is hier relevant: de term 'visueel' op zichzelf garandeert niets. Het succes van het bedrijf wordt bereikt door de zorgvuldige en nauwgezette toepassing van de methoden van de wetenschap van menselijke factoren (ergonomie). Meer precies, we hebben het over de synthese van methoden van informatica en ergonomie, de vorming van een nieuwe interdisciplinaire richting - infoergonomie, de herstructurering van het hele gebouw van moderne programmering op een ergonomische basis.
3. De creatie van een programmeertaal van de volgende generatie moet beginnen met een analyse van de ergonomische vereisten en eindigen met een beoordeling van de resulterende ergonomische kenmerken van de taal. Een van de belangrijkste obstakels voor de uitvoering van dit plan is de traagheid van het denken van veel specialisten, onderschatting van het belang van ergonomische methoden. Om de heersende stereotypen van denken te veranderen, is het noodzakelijk om serieuze veranderingen aan te brengen in het programma en de methoden voor het onderwijzen van informatica op scholen en universiteiten.

Wist u, Wat is de onjuistheid van het concept van "fysiek vacuüm"?

fysiek vacuüm - het concept van relativistische kwantumfysica, waaronder ze de laagste (grond)energietoestand van het gekwantiseerde veld betekenen, dat momentum nul, impulsmoment en andere kwantumgetallen heeft. Relativistische theoretici noemen een fysiek vacuüm een ​​ruimte die volledig verstoken is van materie, gevuld met een onmeetbaar en daarom slechts een denkbeeldig veld. Een dergelijke toestand is volgens relativisten geen absolute leegte, maar een ruimte gevuld met enkele spookachtige (virtuele) deeltjes. Relativistische kwantumveldentheorie stelt dat, in overeenstemming met het onzekerheidsprincipe van Heisenberg, virtueel, dat wil zeggen schijnbaar (voor wie?), Deeltjes voortdurend worden geboren en verdwijnen in het fysieke vacuüm: er treden zogenaamde nulpuntsveldoscillaties op. Virtuele deeltjes van het fysieke vacuüm, en dus zelf, hebben per definitie geen referentiekader, omdat anders het relativiteitsprincipe van Einstein, waarop de relativiteitstheorie is gebaseerd, zou worden geschonden (dat wil zeggen, een absoluut systeem van meting met referentie van deeltjes van een fysiek vacuüm zou mogelijk zijn, wat op zijn beurt ondubbelzinnig het relativiteitsprincipe zou weerleggen waarop de SRT is gebouwd). Het fysieke vacuüm en zijn deeltjes zijn dus geen elementen van de fysieke wereld, maar slechts elementen van de relativiteitstheorie die niet in de echte wereld bestaan, maar alleen in relativistische formules, in strijd met het causaliteitsbeginsel (opstaan ​​en verdwijnen zonder reden ), het principe van objectiviteit (virtuele deeltjes kunnen, afhankelijk van de wens van de theoreticus, al dan niet bestaand worden overwogen), het principe van daadwerkelijke meetbaarheid (niet waarneembaar, hebben geen eigen IRS).

Wanneer deze of gene fysicus het concept van 'fysiek vacuüm' gebruikt, begrijpt hij de absurditeit van deze term niet, of is hij oneerlijk, omdat hij een verborgen of expliciete aanhanger van relativistische ideologie is.

De gemakkelijkste manier om de absurditeit van dit concept te begrijpen, is door te verwijzen naar de oorsprong van zijn oorsprong. Het werd geboren door Paul Dirac in de jaren dertig, toen duidelijk werd dat de ontkenning van de ether in zijn pure vorm, zoals de grote wiskundige, maar de middelmatige fysicus deed, niet langer mogelijk was. Te veel feiten spreken dit tegen.

Om het relativisme te verdedigen, introduceerde Paul Dirac het afysische en onlogische concept van negatieve energie, en vervolgens het bestaan ​​van een "zee" van twee energieën die elkaar compenseren in een vacuüm - positief en negatief, evenals een "zee" van deeltjes die elkaar compenseren. andere - virtuele (dat wil zeggen, schijnbare) elektronen en positronen in een vacuüm.

Wat is de drijvende kracht achter het programma? Wat genereert een gunstig resultaat? Natuurlijk, het algoritme. Het algoritme creëert het effect waarvoor het programma is geschreven. Het algoritme werkt niet alleen. Het werkt in combinatie met datastructuren. Maar het zijn de algoritmen die het grootste deel van het programma uitmaken.

Historisch gezien worden algoritmen in programma's geschreven als broncode. Bijna niemand twijfelt eraan dat tekst de beste manier is om algoritmen weer te geven. Een algoritme is gecodeerd binnen functies in een programmeertaal zoals C of JavaScript. Voor wie het algoritme vanuit vogelperspectief wil begrijpen, is een pseudocode voorzien. Er zijn echter ernstige problemen met de tekst. Het punt is dat een persoon niet is geoptimaliseerd voor solide tekst. De mens is geoptimaliseerd voor de perceptie van afbeeldingen. Tekst is een relatief nieuwe uitvinding, maar organismen verwerken al miljoenen jaren grafische informatie.

Op basis hiervan zou het logisch zijn om algoritmen in grafische vorm op te stellen. Kijk naar de ingenieurs. Ze gebruiken overal blauwdrukken. Waarom zijn programmeurs slechter? Ook zij konden blauwdrukken maken voor de algoritmen. Sommigen zullen hier beweren: visueel programmeren is zogenaamd inefficiënt. De UML is onhandig en stroomdiagrammen zijn gemakkelijk in de war te raken. Het is beter om op de traditionele manier te programmeren - met tekst. Bij gestructureerd programmeren is er op zijn minst een structuur, en het zorgt voor orde en consistentie. En bovendien is het tekenen van diagrammen lang en moeilijk. Typen gaat sneller dan tekenen.

Dus zijn programmeurs gedoemd om hun hele leven alleen met tekst te werken?
Het is misschien allemaal niet zo erg. Er zijn visuele talen voor het weergeven van algoritmen die ook orde en structuur hebben, zoals DRAGON, BPMN en LML Action Diagrams. Hier zullen we kijken naar de visuele algoritmische taal DRAGON.

Hoe te programmeren in DRAGON-taal

DRAGON is geen onafhankelijke programmeertaal. Het werkt samen met een op tekst gebaseerde taal zoals JavaScript, Python of C ++. Samen met de teksttaal vormt DRAGON een hybride taal: DRAGON-JavaScript, DRAGON-Python of DRAGON-C++.

Hybride programmeren gaat als volgt:

1. We tekenen een DRAAK-diagram.
2. Plaats kleine stukjes code in de bijbehorende programmeertaal binnen de pictogrammen.
3. De vertaler zet het DRAGON-schema om in een tekstbestand met de broncode.
4. Dit tekstbestand wordt op de gebruikelijke manier in het project opgenomen.
   Verschillende editors ondersteunen momenteel het genereren van code uit diagrammen. De voorbeelden in dit artikel zijn gemaakt in de DRAKON Editor.

Code genereren uit een diagram

In het diagram neemt de DRAAK de controle over de uitvoeringsstroom over. Daarom mogen stukjes broncode in pictogrammen geen trefwoorden bevatten zoals indien, anders, schakelaar, geval, voor, terwijl enzovoort.

Pictogrammen mogen alleen een eenvoudige, ondubbelzinnige code bevatten: rekenkundige uitdrukkingen, waardetoewijzingen, functieaanroepen, vergelijkingen. Maar vertakkingen en lussen worden geïmplementeerd door constructies van de DRAGON-taal.

Het genereren van codes is als volgt:

• Van elk diagram wordt een functie gemaakt.
• De naam van de grafiek wordt de naam van de functie.
• De functieparameters zijn afkomstig van het pictogram "Formele parameters", dat zich rechts van de diagramnaam bevindt.
• De hoofdtekst van de functie wordt gegenereerd op basis van de structuur van het diagram en de inhoud van de pictogrammen.

In afb. 1 toont een voorbeeld van een klein diagram in de hybride taal DRAGON-JavaScript en de gegenereerde JavaScript-code:

Rechthoek met tekst console.log (kat, hond) in afb. 1 is het actiepictogram. Hoeveel code past er in één actiepictogram? Men moet ernaar streven dat één pictogram één gedachte bevat. Soms is het één regel code, soms meerdere.
De gegenereerde code wordt geannoteerd met de pictogramnummers. In de editor kunt u snel naar elk pictogram springen door op Ctrl + I te drukken.

Figuur 1. Het DRAGON-JavaScript-diagram en de daaruit gegenereerde code.

Icoon "Vraag"

De pictogrammen "Vraag" en "Keuze" worden gebruikt voor vertakkingen.

Pictogram "Vraag" (Fig. 2) komt overeen met het ontwerp als dan anders.

Merk op dat in plaats van woorden waar en vals woorden worden gebruikt Ja en Nee(kan worden omgeschakeld naar) Ja en Nee.).

"Truth" en "false" - het klinkt spectaculair, op een wetenschappelijke manier. Een persoon is echter meer vertrouwd met het "ja" en "nee" vanaf de vroege kinderjaren.

Belettering Ja en Nee kan worden verwisseld. De locatie van de uitgangen van het pictogram "Vraag" blijft ongewijzigd. De ene uitgang gaat naar beneden en de andere gaat naar rechts. Vertakkingen in de DRAGON-taal zijn altijd naar rechts gericht, daarom is het verboden om de linkerkant van het pictogram te verlaten. Deze voorspelbaarheid maakt het diagram beter leesbaar omdat de lezer van tevoren weet waar hij naar outputs moet zoeken.

Een ander kenmerk van de DRAGON-taal is dat er geen volledige ruit wordt gebruikt voor vertakkingen, maar een afgeknotte. Dit bespaart ruimte op het diagram.

Visueel logische formules

DRAGON-taal maakt logische operatoren overbodig EN, OF en NIET evenals de niet-gelijke operator. De logische bewerkingen zelf zijn natuurlijk noodzakelijk. Maar in plaats van tekstoperatoren introduceert DRAGON visueel-logische formules.

Om een ​​visueel logische formule te krijgen, moeten verschillende "Vraag"-pictogrammen worden verbonden (zoals in Fig. 3).

Het is vooral prettig om van de ontkenning af te komen. Ontkenning is niet intuïtief; het brengt fouten en ongemak met zich mee. Negatie (logische operator NIET) wordt bereikt in de DRAGON-taal door permutatie van labels Ja en Nee.

De tekstuele notatie van logische uitdrukkingen is zeker compacter. Visuele formules zijn echter gemakkelijker te lezen. Elk van de mogelijke combinaties van operandwaarden kan met een vinger worden getraceerd.

Lus met pijl

Om de gebruikelijke volgorde van uitvoering in de DRAGON-taal aan te geven, zijn pijlen niet nodig. Het volgende icoon staat altijd onderaan. De pijl is alleen nodig als de uitvoeringsdraad omhoog moet springen in het diagram. Zo'n sprong omhoog betekent een cyclus. Daarom is een pijl in de DRAGON-taal een teken van een cyclus. Bij een vluchtige blik op het DRAGON-diagram vallen de pijlen direct op. Hierdoor zijn de cycli direct zichtbaar. Dit is een belangrijk voordeel van DRAGON ten opzichte van andere grafische talen. Je hoeft de lussen niet te vinden.

Dus als je het pictogram "Vraag" verbindt met een pijl, krijg je een cyclus. Dit is een analoog van constructies terwijl en doen terwijl... Figuur 4 toont verschillende soorten pijllussen.
Het pictogram "Vraag" in een lus met een pijl controleert de voorwaarde voor het verlaten van de lus. In plaats van één 'Vraag'-pictogram kunnen er natuurlijk meerdere zijn. Dan is de visueel logische formule verantwoordelijk voor het verlaten van de lus.

Icoon "Keuze"

Het pictogram "Vraag" bevat een logische uitdrukking, dat wil zeggen dat het twee waarden kan aannemen: Ja en Nee... Een typisch voorbeeld is het vergelijken van twee objecten. Als u een bepaalde uitdrukking met meerdere waarden moet vergelijken, wordt het pictogram "Selecteren" gebruikt (Fig. 5). Dit komt overeen met het ontwerp heksenzaak.

De waarden waarmee de uitdrukking in het pictogram "Keuze" wordt vergeleken, worden in de pictogrammen "Variant" geplaatst. Als er geen tekst in de meest rechtse versie staat, betekent dit "alle andere waarden". Zo'n lege optie is vergelijkbaar met het trefwoord standaard binnendienst schakelaar.
De meest rechtse optie kan eindigen met een pijl die naar boven leidt. In dit geval hebben we weer te maken met een pijlcyclus. In een dergelijke cyclus is het pictogram "Keuze" en niet de "Vraag" verantwoordelijk voor de uitgangstoestand.

Icoon "Cyclus VOOR"

In plaats van lussen voor en foreach DRAGON-JavaScript gebruikt het "Loop FOR"-pictogram. Het pictogram "Cyclus VOOR" (Fig. 6) kan van verschillende typen zijn.

Als na het trefwoord foreach en er is één variabele voor de puntkomma, dan wordt er code gegenereerd om over de array te itereren. De elementen van de array (maar niet hun indices) worden in de variabele geplaatst.

Als na het trefwoord foreach er twee variabelen zijn, zal DRAKON Editor begrijpen dat iteratie over objecteigenschappen (hashtabelrecords) vereist is. Alleen de eigen eigenschappen van de objecten worden in de opsomming opgenomen.

De derde versie van de lus impliceert de aanwezigheid van drie uitdrukkingen, gescheiden door puntkomma's. Dit is een traditionele cyclus voor, specifiek voor de C- en Java-talen.

Een vroegtijdige beëindiging van de cyclus onder besturing van het pictogram "Cyclus VOOR" is mogelijk met behulp van het pictogram "Vraag" of "Keuze". Deze uitvoer komt ongeveer overeen met het trefwoord pauze.

Slechts één ingang in de lus

In de DRAGON-taal wordt een beperking opgelegd aan fietsen. Elke cyclus kan slechts één ingang hebben. Het doel van deze beperking is om de leesbaarheid te waarborgen. Deze beperking houdt DRAGON binnen het kader van gestructureerd programmeren, zoals Dijkstra het omschreef.

Meerdere uitgangen van de lus zijn toegestaan, maar er mag maar één ingang zijn. In afb. 7 toont cycli met twee uitgangen. Het is toegestaan. In afb. 8 toont voorbeelden van verboden cycli. Verboden omdat je ze op verschillende manieren kunt invoeren.
Onthoud echter niet hoe deze verboden cycli verschijnen. De DRAKON Editor zal dergelijke lussen automatisch detecteren en een fout genereren.

Afb. 8. Verboden fietsen met twee ingangen

Verschillen met op tekst gebaseerde gestructureerde programmering

Zoals u kunt zien, komen de pictogrammen en macropictogrammen van de DRAGON-taal overeen met de standaardconstructies van tekstueel gestructureerd programmeren. Er zijn echter ook verschillen. Tekst, zelfs met inspringing, is een eendimensionaal object. En het diagram is tweedimensionaal. In het diagram verschijnt een extra vrijheidsgraad, wat de zeggingskracht vergroot. Probeer het bijvoorbeeld eens in een op tekst gebaseerde programmeertaal zonder herhalingen en ga naar beeld een algoritme af zoals in Fig. negen.

Ondanks de extra vrijheid in vergelijking met de tekst, laat de DRAAK zich nog steeds niet in anarchie vervallen. De regels zijn streng genoeg om verwarring te voorkomen. DRAGON biedt een redelijk compromis tussen flexibiliteit en nauwkeurigheid.

Voordelen van een grafische taal

De DRAGON-taal heeft een interessant lot. De uitgangspunten zijn door Dijkstroy zelf vastgelegd. DRAGON verwierf zijn huidige vorm in de diepten van de Russische ruimtevaartindustrie. Het is opmerkelijk dat de regels van de DRAGON-taal niet toevallig zijn ontstaan. Ze werden eerst getest in focusgroepen en vervolgens aangescherpt in echte ruimteprojecten.
Dus wat zijn precies de sterke punten van de DRAGON?

Laten we beginnen met het feit dat DRAGON een grafische taal is. En de grafische taal heeft fundamentele voordelen ten opzichte van tekst.

Ten eerste zijn gedachten niet willekeurig verspreid over lijnen, maar zijn ze ingesloten in vierkanten of pictogrammen. Eén gedachte - één vierkant. Verschillende gedachten gaan niet samen.

Ten tweede kan het pad door het algoritme worden getraceerd met een vinger (of een blik). Na indien niet nodig om te zoeken anders... Volg de lijn en u bevindt zich op het gewenste plein. U hoeft uw ogen niet door de broncode te spitten op zoek naar een antwoord op de vraag: wat gebeurde er daarna?

En grafieken hebben ook een bijna magische eigenschap. Het komt voor dat een persoon naar een diagram kijkt en plotseling komt er wat extra begrip. Voorheen onzichtbare verbanden worden zichtbaar. Dit gebeurt zelden met tekst.

Speciale ergonomische regels

Maar DRAGON zijn niet zomaar diagrammen, het zijn uitgebreide diagrammen. DRAGON-diagrammen zijn gemakkelijker te lezen dan gewone stroomdiagrammen. Dit wordt verzekerd door speciale ergonomische trucs. Hier zijn er enkele.

• Het overschrijden van lijnen is verboden. Over het algemeen. Kruispunten doen onze visuele analysator vermoeden dat de lijnen elkaar raken en daarom op de een of andere manier met elkaar verbonden zijn. Deze vermoedens zorgen voor extra mentaal werk. Onnodig werk moet worden weggegooid.
• Het begin bevat de naam van het algoritme en bevindt zich altijd in de linkerbovenhoek van het diagram. Daarom is het niet eens nodig om naar het begin te zoeken. Het is waar het meestal is.
• Het diagram heeft slechts één uiteinde. Wat er onderweg ook gebeurt (behalve uitzonderingen), we komen altijd aan het einde.
• Alleen rechte lijnen zijn toegestaan. Geen bochten, geen bochten of onnodige knikken.
• Alleen strikt verticale en strikt horizontale lijnen zijn toegestaan. Schuine lijnen zijn verboden. Uitleg voor wiskundeliefhebbers: Het DRAGON-diagram is een platte rechthoekige grafiek (Manhattan-grafiek). Het menselijke visuele apparaat grijpt onmiddellijk objecten die zijn verbonden door rechte orthogonale lijnen. Bijhouden waar de American Dream Curve toe leidt, vereist echter extra concentratie van de lezer.
• DRAGON-schema wordt van boven naar beneden uitgevoerd. Deze regel vermijdt de noodzaak om verwoed het diagram met uw ogen te scannen op zoek naar het volgende pictogram. Het volgende icoon staat altijd onderaan. De ingang is aan de bovenkant en de uitgang is aan de onderkant. Omdat we weten waar het volgende pictogram is, zijn de pijlen niet nodig. Eenvoudige lijnen zijn voldoende. De pijlen naast elk pictogram vertegenwoordigen visuele ruis. Nadat je de taak van het verbinden van pictogrammen van de pijlen hebt verwijderd, kun je ze een speciale missie toewijzen. In de DRAAK betekent een pijl een cyclus.
• Vertakking vindt alleen rechts plaats. Dit is een enorme hulp in termen van voorspelbaarheid en consistentie.
• Pictogrammen die zich op dezelfde verticale lijn bevinden, moeten dezelfde breedte hebben. Dit geeft het gevoel dat de iconen tot één geheel behoren. Wanneer iedereen dezelfde breedte heeft en er geen beginnende pictogrammen zijn, glijdt het oog gemakkelijk en vrij over het diagram.

Bovenstaande regels zijn van grote praktische waarde. Enerzijds zijn ze bedoeld om de waanzin van de kunstenaar te beteugelen. Het is moeilijker om er een verwarrend diagram mee te maken. Aan de andere kant brengen ze bewustzijn naar grafieken. Diagrammen worden niet alleen begrijpelijk voor hun auteurs.

De diagrammen in Fig. 10 en 11 demonstreren de ergonomische technieken van de DRAGON-taal aan de hand van echte voorbeelden.

Afb 11. Nog een voorbeeld van een diagram in de DRAGON-taal
Naast ergonomische technieken heeft de DRAGON-taal unieke eigenschappen die nergens anders te vinden zijn.

Hoe meer naar rechts, hoe slechter

DRAGON heeft een middel voor de afbeelding gelukkig pad, of Koninklijke weg... The Tsar's Road is de meest succesvolle weg door het algoritme. In sommige algoritmen zijn de begrippen "goed/slecht", "goed/slecht" niet van toepassing. Daarin toont de koninklijke weg het meest verwachte pad. De Royal Road loopt verticaal, aan de linkerkant van het diagram. Deze verticaal wordt een spies genoemd. Minder waarschijnlijke en minder succesvolle scenario's, evenals foutafhandeling, worden aan de rechterkant van het diagram geplaatst. Bovendien, hoe slechter de situatie, hoe meer naar rechts het zou moeten worden geplaatst. Het is een goede gewoonte om code die een uitzondering genereert of een foutcode teruggeeft aan de rechterkant van het diagram te plaatsen.

gemeenschappelijk lot

Soms gebeurt het dat het op verschillende paden door het algoritme nodig is om verschillende, maar op de een of andere manier gerelateerde acties uit te voeren. Zet bijvoorbeeld verschillende waarden in één variabele. Gedeelde bestemming is wanneer gerelateerde acties op verschillende verticale lijnen zitten, maar op dezelfde horizontale.

Rijst. 12 toont een spies met een koninklijke weg, evenals de toepassing van de "common destiny"-techniek.

Silhouet

Het silhouet is een echte DRAGON-diamant. Met Silhouette kunt u een diagram opsplitsen in logische delen. Bij het programmeren wordt hiervoor meestal decompositie met behulp van subroutines gebruikt. Subroutines zijn een krachtige methode. Maar soms wil ik de subroutine visueel dicht bij het hoofdprogramma plaatsen, en de rommel vermijden met het doorgeven van parameters en het retourneren van waarden. Een silhouet is geweldig voor deze doeleinden. Een ander gebruik van silhouet is in eindige-toestandsmachines. Maar daar zullen we het elders over hebben.
Het komt voor dat het algoritme niet kan worden ontleed in een vlak, zodat er geen snijpunt van lijnen is. In dit geval wordt, afhankelijk van de situatie, ofwel ontleding met behulp van subroutines of silhouet toegepast.

Het silhouet bestaat uit verschillende kleine diagrammen die in één integraal blok zijn verbonden. Deze kleine diagrammen worden silhouettakken genoemd. Bovenaan elke vestiging bevindt zich het pictogram "Branch Head", hieronder het pictogram "Adres". De naam van dit filiaal wordt in de kop van het filiaal geplaatst en de naam van het volgende filiaal wordt in het adres aangegeven. De namen van de takken bevinden zich op een enkele horizontale lijn bovenaan het diagram. Hierdoor kunt u de essentie van het algoritme begrijpen door alleen door de branch-headers te lopen. Het silhouet beantwoordt drie koninklijke vragen:

1. Wat is de naam van het probleem?
2. Uit hoeveel onderdelen bestaat het?
3. Hoe heten deze onderdelen?

Beschouw het voorbeeld in Fig. 13. Hier zijn de antwoorden op de vragen van de koning:

1. Wat is de naam van het probleem? Orden de gekoppelde lijst.
2. Uit hoeveel onderdelen bestaat het? Van de vier.
3. Hoe heten deze onderdelen? Bouw een matrix van links. Controleer op cycli. Doorloop de matrix van verbindingen. Vervolledigen.

Afb. 13. DRAGON-schema "silhouet"

Silhouet cyclus

De takken van het silhouet moeten van links naar rechts worden gerangschikt. In sommige gevallen moet u een vertakking of groep vertakkingen meerdere keren uitvoeren. Dit ontwerp wordt een silhouetlus genoemd. Als het pictogram "Adres" naar zijn eigen filiaal wijst, of naar een filiaal dat zich aan de linkerkant bevindt, moet dit worden gemarkeerd met een speciaal label. Dezelfde markering moet worden geplaatst op het overeenkomstige pictogram "Branch's head" (zie fig. 14). Het doel van het label is om de silhouetlus zichtbaar te maken.

Het aansluiten van silhouettakken is verboden

Verbindingen van twee takken van het silhouet (zoals in Fig. 15) zijn verboden. Elke tak binnen het silhouet moet onafhankelijk zijn.

Maattabellen

Bij het programmeren in de DRAGON-taal rijst de vraag: hoe groot moeten de diagrammen zijn? Het antwoord is: hoe minder, hoe beter. Hoe minder objecten in de visuele scène, hoe duidelijker het is. Bij tekstgebaseerd programmeren is er zo'n referentiepunt: het is goed als de hele functie op het scherm past. Soortgelijke adviezen kunnen worden gegeven voor DRAGON-regelingen. Vermijd enorme grafieken. Wanneer het hele algoritme volledig zichtbaar is, is het veel gemakkelijker te begrijpen.
Voor DRAGON-programmering is het niet beter om een ​​grote monitor te hebben. Minimaal 1080 pixels hoog. Dan hoef je de DRAGON-schema's niet kunstmatig in te korten.

DRAGON-schema silhouet moet in de hoogte op het scherm passen, maar niet noodzakelijk in de breedte. diagrammen silhouet kan behoorlijk breed zijn, veel breder dan 2000 pixels. Dit is goed. Het is niet nodig om alle takken van het silhouet tegelijk te zien. Het belangrijkste is dat de branch waarmee je werkt volledig zichtbaar is op het scherm.

Kritiek op DRAGON-programmering

Laten we eens kijken naar de belangrijkste kritieken op het programmeren op de DRAGON en proberen er een antwoord op te geven.

• "DRAGON-diagrammen nemen meer schermruimte in beslag dan tekstverwerkingsprogramma's." Dit is waar. Maar we moeten niet vergeten dat het de taak van de DRAAK is om de complexiteit te laten zien zoals die is. De lezer van het programma moet geen complexe structuren in zijn hoofd uitpakken. Ze moeten hem expliciet worden getoond.
• "Eenvoudige algoritmen zien er beter uit in tekstvorm." Misschien. Hallo wereld ziet er elegant uit in elke taal. Maar in het echte leven is niet alles eenvoudig. Zodra er minstens één verschijnt indien genest in een ander indien, DRAAK wint.
• "DRAGON heeft geen mogelijkheid om uitzonderingen weer te geven." Er is zo'n probleem. Er zijn onlangs uitzonderingen toegevoegd aan de DRAGON-taal, maar niet alle implementaties ondersteunen deze. Totdat de implementaties op tijd komen, kun je try/catch-blokken schrijven in de juiste programmeertaal.
• "DRAGON-schema's duren lang om te tekenen." Het is veel gemakkelijker om DRAGON-diagrammen te tekenen in gespecialiseerde editors dan bijvoorbeeld in Visio. En in sommige ervan is tekenen bijna net zo gemakkelijk geworden als schrijven.
• "Er zijn geen tools voor diff en merge." Dit is helaas het geval. Wanneer u met een versiebeheersysteem werkt, moet u de gegenereerde bronbestanden vergelijken.
• "Er zijn geen DRAGON-schematische debugging-tools." Dit is waar. Maar u kunt de gegenereerde code debuggen. Het heeft labels die aangeven waar in het diagram een ​​bepaald stuk code thuishoort.

Dragon-taaloverzicht

Afbeelding 16 geeft een overzicht van de DRAGON-taal.

Dragon-taalhulpmiddelen

De allereerste implementatie van de DRAGON-taal was het GRAPHITE-FLOKS-systeem (Fig. 17). GRAPHITE-FLOX werd opgericht in 1986-1996. door specialisten van FSUE NPT's AP hen. Pilyugin onder leiding van V.D. Parondzjanova. Deze omgeving was bedoeld voor het ontwerpen van besturingssystemen voor draagraketten en ruimtevaartuigen.

GRAPHITE-FLOX is een gesloten ontwikkeling, dus er is relatief weinig over bekend. De lijst met ruimtevaartuigen die met GRAFIT-FLOX zijn gemaakt, kan worden bekeken.

Begin jaren 90 werd er nog een DRAGON-editor gemaakt. De ontwikkeling vond plaats bij het Instituut voor Toegepaste Wiskunde vernoemd naar M.V. Keldysh onder leiding van L.K. Eisymont. De Eisymont-editor (Fig. 18) kan worden gedownload en uitgevoerd, maar wordt niet langer ondersteund. De editor is geschreven onder MS DOS, dus DOSBox kan nodig zijn om op moderne computers te draaien.

In 2008 werd de redacteur van IS Dragon van Gennady Tyshov vrijgelaten (Fig. 19). IS Dragon wordt actief ondersteund en ontwikkeld. IS Dragon implementeert het genereren van programmacode uit diagrammen. Een van de interessante eigenschappen van IS Dragon is de mogelijkheid om een ​​code in een programmeertaal en een beschrijving in een natuurlijke taal in één icoon te plaatsen. De absolute verdienste van IP Dragon is de zogenaamde "calculus of iconen". Icon calculus is een bewerkingsmethode die de gebruiker helpt een diagram te tekenen en ervoor zorgt dat het diagram de regels van de DRAGON-taal niet schendt. Een van de nadelen van IS Dragon is een niet-standaard gebruikersinterface en enkele ongemakken bij het genereren van code. IP Dragon is een commercieel product.

DRAKON Editor is een andere moderne DRAGON-editor (afb. 20). DRAKON Editor is ontwikkeld door een groep enthousiastelingen onder leiding van Stepan Mitkin. DRAKON Editor ondersteunt geen pictogramberekening. Dit betekent dat DRAGON-schema's er handmatig in worden samengesteld uit primitieven, zoals in vector grafische editors. Maar aan de andere kant is de gebruikersinterface in DRAKON Editor zo eenvoudig mogelijk. Het is gebouwd volgens een bekender schema dan IS Dragon. Het belangrijkste voordeel van de DRAKON Editor-omgeving is het gemak van programmeren en het genereren van code. DRAKON Editor ondersteunt meerdere programmeertalen waaronder C, C++, C#, Java, Processing, JavaScript, Lua, Erlang, Python, Tcl, Verilog, AutoHotkey, D en Go. Voor sommige talen is het mogelijk om statusmachines te genereren. De regels voor het nools expert systeem worden ondersteund. Een subset van de UTOPIST E. Tyugu-taal geïmplementeerd. DRAKON Editor is open source.

Een interessante toepassing voor de DRAGON-taal is uitgevonden door Oleg Garipov in zijn Integrator CodeView-project. Met CodeView kunt u bestaande code visualiseren als een onderling verbonden set DRAGON-schema's. De eigenaardigheid van de Integrator CodeView is dat niet individuele methoden worden gevisualiseerd, maar het hele project, inclusief de oproepgrafiek, stapel, enz. De Integrator CodeView is ook uniek omdat het niet alleen algoritmen, maar ook gegevens visueel toont. De datavisualisatie-engine in het Integrator-systeem werkt samen met DRAGON.

DRAKON Editor Web is een commerciële cloudoplossing gebaseerd op de DRAGON-taal. DRAKON Editor Web is ontworpen voor technische specificaties, bedrijfsprocedures en checklists. DRAKON Editor Web is op geen enkele manier gelieerd aan DRAKON Editor en ondersteunt het genereren van code uit diagrammen niet. Tot de voordelen van DRAKON Editor Web behoren een handige editor, samenwerking en ondersteuning voor mobiele apparaten.

Afb. 18. DRAGON Editor Eisymont

Afb 19. Programma met uitleg in IS Dragon

Afb. 20. DRAKON-editor

conclusies

Laten we samenvatten. DRAGON is een praktische taal gehard in de ruimte. Hij bracht structuur, orde en consistentie in stroomdiagrammen. De voorspelbaarheid en netheid van DRAGON-schema's leiden ertoe dat visuele programmering werken.

De ervaring van echte projecten heeft geleerd dat je niet kunt programmeren op de DRAGON. Enerzijds is DRAGON expressiever dan tekst. Anderzijds verhoogt het de leesbaarheid van programma's. En bovendien zien programma's in de vorm van DRAGON-schema's er, nou ja, net uit als van een buitenaards ruimteschip (hoewel veel afhangt van het kleurenschema). Persoonlijk schakelde ik gemakkelijk over naar DRAGON. Het is onhandig als je daarentegen soms in de traditionele tekststijl moet programmeren.