Tehnologije za kreiranje softvera. Postoje samo strukturne i objektne paradigme programiranja. Opišite strukturni pristup programiranju

Programiranje- relativno mlada grana nauke i tehnologije koja se brzo razvija. Iskustvo sprovođenja realnog razvoja i poboljšanja postojećeg softvera i hardvera stalno se preispituje, zbog čega se pojavljuju nove metode, metodologije i tehnologije, koje zauzvrat služe kao osnova za modernije alate za razvoj softvera. Preporučljivo je proučavati procese stvaranja novih tehnologija i odrediti njihove glavne trendove upoređujući ove tehnologije sa stepenom razvoja programiranja i karakteristikama softvera i hardvera koji su dostupni programerima.

tehnologija programiranja nazivaju skup metoda i alata koji se koriste u procesu razvoja softvera. Kao i svaka druga tehnologija, tehnologija programiranja je skup tehnoloških uputstava, uključujući:

• indikacija redosleda tehnoloških operacija;
• nabrajanje uslova pod kojima se izvodi ova ili ona operacija;
• opisi samih operacija, pri čemu se za svaku operaciju definišu početni podaci, rezultati, kao i uputstva, propisi, standardi, kriterijumi i metode vrednovanja itd.

Osim skupa operacija i njihovog redoslijeda, tehnologija određuje i način opisa sistema koji se projektuje, odnosno modela koji se koristi u određenoj fazi razvoja.

Objektno orijentirano programiranje (OOP) definira se kao tehnologija za kreiranje složenog softvera zasnovanog na predstavljanju programa kao skupa objekata, od kojih je svaki instanca određenog tipa (klase), a klase formiraju hijerarhiju sa nasljeđivanjem svojstava. Interakcija softverskih objekata u takvom sistemu se vrši prenošenjem poruka.

Glavna prednost objektno orijentisanog programiranja u odnosu na modularno je "prirodnija" dekompozicija softvera, što uvelike olakšava njegov razvoj. To dovodi do potpunije lokalizacije podataka i njihove integracije sa potprogramima za obradu, što omogućava gotovo samostalan razvoj pojedinih dijelova (objekata) programa. Osim toga, objektni pristup nudi nove načine organiziranja programa na osnovu mehanizama nasljeđivanja, polimorfizma, kompozicije i sadržaja. Ovi mehanizmi omogućavaju konstruisanje složenih objekata od relativno jednostavnih. Kao rezultat toga, stopa ponovne upotrebe koda značajno se povećava i postaje moguće kreirati biblioteke klasa za različite aplikacije.

Brzi razvoj programskih tehnologija zasnovanih na objektnom pristupu omogućio je rješavanje mnogih problema. Tako su nastala okruženja koja podržavaju vizuelno programiranje, na primer Delphi, C++ Builder, Visual C++ itd. Kada koristi vizuelno okruženje, programer ima mogućnost da dizajnira neki deo, na primer interfejse budućeg proizvoda, itd. korištenje vizualnih alata za dodavanje i konfiguriranje posebnih komponenti biblioteke. Rezultat vizualnog dizajna je priprema budućeg programa u koji su već uneseni odgovarajući kodovi.

Može se dati opšta definicija: OOP objekat je zbirka varijabli stanja i pridruženih metoda (operacija). Ove metode definiraju kako objekt stupa u interakciju sa okolinom.

Ispod objektne metode razumiju procedure i funkcije čija je deklaracija uključena u deklaraciju objekta i koje izvode akcije. Sposobnost kontrole stanja objekta pozivanjem metoda u konačnici određuje ponašanje objekta. Ovaj skup metoda se često naziva interfejsom objekta.

Strukturirano programiranje (SP) se pojavilo kao rješenje problema smanjenja SLOŽENOSTI razvoja softvera.

Na početku ere programiranja, rad programera nije bio ničim regulisan. Zadaci koje je trebalo rješavati nisu se razlikovali po obimu i skali, uglavnom su se koristili mašinski orijentirani jezici i njima bliski jezici kao što je Assembly, razvijeni programi rijetko su dostizali značajne veličine i nije bilo strogih ograničenja u vremenu njihovog razvoja.

Kako se programiranje razvijalo, pojavili su se zadaci za koje su određivani ograničeni vremenski okviri za sve složenije zadatke uz uključivanje grupa programera. I kao rezultat toga, programeri su suočeni s činjenicom da se metode prikladne za razvoj malih zadataka ne mogu koristiti u razvoju velikih projekata zbog složenosti potonjih.

Dakle, cilj strukturiranog programiranja je povećati pouzdanost programa, osigurati održavanje i modifikacije, olakšavajući i ubrzavajući razvoj.

Metodologija strukturiranog imperativnog programiranja - pristup koji se sastoji u postavljanju dobre topologije imperativnih programa, uključujući odbijanje upotrebe globalnih podataka i bezuslovnog operatera skoka, razvoj modula sa jakom vezom i osiguranje njihove nezavisnosti od drugih modula.

Pristup se zasniva na dva glavna principa:

· Sekvencijalna dekompozicija algoritma za rješavanje problema od vrha do dna.

Upotreba strukturnog kodiranja.

Podsjetimo da je ova metodologija najvažniji razvoj imperativne metodologije.

Poreklo, istorija i evolucija. Edsger Dijkstra se smatra tvorcem strukturalnog pristupa. Posjeduje i pokušaj (nažalost, potpuno neprimjenjiv na masovno programiranje) kombiniranja strukturiranog programiranja sa metodama za dokazivanje ispravnosti kreiranih programa. Takvi poznati naučnici kao što su H. Mills, D.E. Knuth, S. Hoor.

Metode i koncepti koji su u osnovi strukturiranog programiranja. Ima ih tri

Metoda algoritamska dekompozicija odozgo prema dolje- sastoji se od detaljnog opisivanja problema korak po korak, počevši od najopštijeg problema. Ova metoda daje dobru strukturu. Metoda je podržana konceptom algoritma.

Metoda modularna organizacija programskih dijelova- sastoji se u razbijanju programa na posebne komponente koje se nazivaju moduli. Metoda je podržana konceptom modula.

Metoda strukturno kodiranje- sastoji se u korištenju tri glavne kontrolne strukture prilikom kodiranja. Oznake i operator bezuslovnog skoka su veze koje je teško pratiti bez kojih želimo. Metoda je podržana konceptom upravljanja

Strukturni programski jezici. Glavna razlika od klasične metodologije imperativnog programiranja leži u neuspjehu (tačnije, ovaj ili onaj stepen neuspjeha) od operatora bezuslovnog skoka .

„Važno svojstvo sintakse za programera je sposobnost da odražavaju u strukturi programa strukturu osnovnog algoritma. Kada koristite metod poznat kao strukturirano programiranje, program je konstruisan hijerarhijski - od vrha do dna (od glavnog programa do podprograma najnižeg nivoa), koristeći samo ograničen skup kontrolnih struktura na svakom nivou: jednostavne sekvence instrukcija, petlje i neke vrste uslovnih grana. Uz dosljednu implementaciju ove metode, strukturu rezultirajućih algoritama je lako razumjeti, otkloniti greške i modificirati. U idealnom slučaju, trebali bismo biti u mogućnosti da prevedemo programsku šemu konstruisanu na ovaj način direktno u odgovarajuće programske instrukcije koje odražavaju strukturu algoritma.

Teorema o strukturiranju (Boem-Jacopini): Svaki ispravan program (tj. program s jednim ulazom i jednim izlazom bez petlji i nedostižnih grana) može se napisati korištenjem sljedećih logičkih struktura - niz, odabir i ponavljanje petlje

Korol 1: Svaki program se može svesti na formu bez naredbe goto.

Korol 2: Bilo koji algoritam se može implementirati na jeziku zasnovanom na tri kontrolne strukture - sekvenca, ciklus, ponavljanje.

Korol 3: Složenost strukturiranih programa je ograničena, čak i ako je njihova veličina neograničena.

Strukturirano programiranje nije cilj samo po sebi. Njegova glavna svrha je da dobije dobar ("ispravan") program, ali čak iu najboljem programu ponekad su potrebni goto naredbe: na primjer, za izlazak iz mnogih ugniježđenih petlji.

Praktično na svim jezicima koji podržavaju imperativnu metodologiju moguće je razvijati programe koristeći ovu metodologiju. Brojni jezici su uveli posebne zamjene za naredbu goto kako bi se olakšalo upravljanje petljama (na primjer, Break and Continue u C).

Klasa zadataka. Klasa zadataka za ovu metodologiju odgovara klasi problema za imperativnu metodologiju. Imajte na umu da je u ovom slučaju moguće razviti složenije programe, jer ih je lako uočiti i analizirati.

Strukturno programiranjenie je prva kompletna metodologija programiranja. Strukturirano programiranje je imalo ogroman uticaj na razvoj programiranja. Ova metoda se vrlo široko koristila u praktičnom programiranju i do danas nije izgubila na značaju za određenu klasu problema.

Strukturalni pristup zasniva se na dva osnovna principa:

1 je upotreba proceduralnih programskih jezika (Algol, Pascal, SI);

2 je sekvencijalna dekompozicija algoritma za rješavanje problema od vrha do dna.

Problem se rješava primjenom niza radnji. Zadatak se u početku formuliše u smislu input-output. To znači da se neki podaci daju kao ulaz u program. Program se pokreće i daje odgovor.

Nakon toga počinje sekvencijalna dekompozicija cijelog zadatka na jednostavnije radnje.

Na primjer, ako treba da napišemo program za provjeru ispravnosti adrese, prvo ćemo ga napisati na sljedeći način:

Provjerite adresu s bazom dostupnih adresa

Ako je rezultat testa pozitivan,print Da,

inače štampaj br.

Očigledno, takav zapis se prikazuje jedan na jedan u programu na jeziku visokog nivoa, na primjer, u Pascalu.

program check_address (ulaz, izlaz); varan_address: Adresa; započeti read_address(an_address);

if (check_database(an_address)) then

writeInTMIa") ; ostalo

Ovaj program koristi proceduru čitaj_ adresa da pročitate adresu i proceduru provjeriti_ baza podataka za provjeru pročitane adrese s informacijama u bazi podataka. Sada možemo nastaviti proces programiranja za procedure sljedećeg nivoa: čitanje adrese i provjeru u bazi podataka.

Vrlo je važno da se u bilo kojoj fazi program može provjeriti. Da biste to učinili, morate napisati stubove - procedure koje simuliraju ulazak i izlazak iz procedura nižeg nivoa. (U gornjem programu možete koristiti proceduru čitanja adrese koja jednostavno zamjenjuje neku fiksnu adresu umjesto terminalnog ulaza i proceduru provjere baze podataka koja ne radi ništa, ali jednostavno uvijek vraća true.)

Program je povezan sa stubovima i može se pokrenuti. Stubovi vam omogućavaju da testirate logiku najvišeg nivoa prije implementacije sljedećeg nivoa.

Strukturirano programiranje je jasno definisano važnost modularnog programiranja kada razvijate velike projekte, ali programski jezici još uvijek slabo podržavaju modularnost. Jedini način da se strukturiraju programi bilo je njihovo sastavljanje od potprograma ili funkcija. Kontrola ispravnosti poziva funkcija, uključujući korespondenciju broja i tipova stvarnih argumenata sa očekivanim formalnim parametrima, vršena je samo u fazi izvršavanja (koncept prototipa funkcije pojavio se kasnije).

1.4. Osnove i istorijat objektno orijentisanog pristupa programiranju

Objektno orijentirano programiranje se pojavilo i postalo široko rasprostranjeno zbog prepoznavanja tri glavna problema programiranja.

1 - razvoj programskih jezika i metoda nije išao u korak sa rastućim potrebama za programima. Jedini pravi način da se zadovolje ove potrebe bio je metod ponovne upotrebe već razvijenog, testiranog i otklonjenog softvera.

2 - potreba da se pojednostavi održavanje i modifikacija razvijenih sistema. (Činjenica stalne promjene sistemskih zahtjeva prepoznata je kao normalan uslov za razvoj sistema, a ne kao nemogućnost ili nedovoljno jasna organizacija rada programera.) Bilo je potrebno promijeniti način na koji su softverski sistemi građeni tako da se da lokalne modifikacije ne bi poremetile operativnost cijelog sistema i da bi bilo lakše napraviti promjene u ponašanju sistema.

3 je olakšavanje dizajna sistema. Nisu svi zadaci podložni algoritamskom opisu i još više algoritamskoj dekompoziciji, kako to zahtijeva strukturirano programiranje. Trebalo je strukturu programa približiti strukturi zadataka koji se rješavaju i smanjiti tzv. semantička praznina između strukture problema koji se rješava i strukture programa. Semantička praznina nastaje kada su koncepti koji su u osnovi jezika problema i sredstva za njegovo rješavanje različiti. Stoga je, uz potrebu da se zapiše samo rješenje, potrebno i neke pojmove prevesti u druge. (Uporedite ovo sa prevođenjem s jednog prirodnog jezika na drugi. Upravo zato što u ruskom jeziku ranije nije bilo takvih pojmova, riječi poput broker, offshore ili investitor. Nažalost, u programiranju nije moguće posuđivanje riječi.)

Dakle, pojednostavljenje dizajna, brzina razvoja zbog ponovne upotrebe gotovih modula i lakoća modifikacije su tri glavne prednosti objektno orijentisanog programiranja, koje su promovisale njegove pristalice.

Objektno orijentirano programiranje pretpostavlja jedinstven pristup dizajnu, izgradnji i razvoju sistema.

Pojava objektno orijentisane metode nastala je na osnovu sveg dosadašnjeg razvoja metoda razvoja softvera, kao i mnogih drugih grana nauke.

Sljedeći napredak u tehnologiji doprinio je nastanku objektno orijentisanog pristupa dizajnu sistema:

1 - Razvoj računarske tehnologije, posebno hardverske podrške za osnovne koncepte operativnih sistema i izgradnju funkcionalno orijentisanih sistema.

2 - Napredak u metodologiji programiranja, posebno modularnih sistema i enkapsulacije informacija.

3 - Teorija izgradnje i modeliranja sistema upravljanja bazama podataka uvela je u programiranje objekata ideje izgradnje odnosa između objekata.

4 - Istraživanja u oblasti veštačke inteligencije omogućila su bolje razumevanje mehanizama apstrakcije. Teorija okvira, koju je Minsky predložio za predstavljanje stvarnih objekata u sistemima za prepoznavanje uzoraka, dala je snažan poticaj ne samo sistemima umjetne inteligencije, već i mehanizmima apstrakcije u programskim jezicima.

5 - Razvoj filozofije i teorije znanja. Na mnogo načina, objektno orijentirana izgradnja sistema je određeni način gledanja na stvarni svijet koji se modelira. Upravo u tom aspektu filozofija i teorija znanja su imale snažan uticaj na objektni model. Čak su i stari Grci smatrali svijet u obliku predmeta ili procesa. Descartes je iznio pretpostavku da se objektno orijentirano razmatranje svijeta oko nas čini prirodnim za osobu. Minsky je sugerirao da se um manifestira kao interakcija agenata koji ne mogu razmišljati odvojeno.

Objektno orijentisani pristup programiranju podržavaju programski jezici kao što su Smalltalk, C++, Java, itd. Jezici su glavni alati objektno orijentiranog programiranja, tijekom njihovog razvoja pojavila se većina ideja koje čine osnovu objektno orijentirane metode.

Prvi korak ka stvaranju objektnog modela treba smatrati pojavom apstraktnih tipova podataka. Vjeruje se da je prva potpuna implementacija apstraktnih tipova podataka u programskim jezicima jezik Simula.

Zatim su došli (i nastavljaju se pojavljivati) drugi objektno orijentirani jezici koji definiraju trenutno stanje programiranja. Najčešći od njih su C++, CLOS, Eiffel, Java.

Šablon: softver koji se zasniva na predstavljanju programa u obliku hijerarhijske strukture blokova. Predložio ga je 70-ih godina XX vijeka E. Dijkstroy, a razvio i dopunio N. Wirth.

Prema ovoj metodologiji

1. Svaki program je struktura izgrađena od tri tipa osnovnih struktura:
   • sekvencijalno izvršenje- jednokratno izvršavanje operacija onim redosledom kojim su napisane u tekstu programa;
   • grananje- jedno izvođenje jedne od dvije ili više operacija, u zavisnosti od ispunjenja nekog datog uslova;
   • ciklus- ponavljano izvođenje iste operacije dok se ne ispuni neki zadati uslov (uslov za nastavak ciklusa).
   U programu se osnovne strukture mogu proizvoljno ugniježditi jedna u drugu, ali nisu predviđeni drugi načini kontrole redoslijeda operacija.
2. Ponavljajući fragmenti programa (ili ne ponavljajući, ali predstavljaju logički integralne računske blokove) mogu se napraviti u obliku tzv. potprogrami (procedure ili funkcije). U ovom slučaju, u tekst glavnog programa, umjesto fragmenta smještenog u potprogram, ubacuje se instrukcija poziv podprograma. Kada se takva instrukcija izvrši, izvršava se pozvani potprogram, nakon čega se izvršavanje programa nastavlja instrukcijom koja slijedi nakon instrukcije za pozivanje potprograma.
3. Razvoj programa se odvija korak po korak, metodom „odozgo prema dolje“.

Prvo se upisuje tekst glavnog programa u koji se umjesto svakog povezanog logičkog fragmenta teksta ubacuje poziv potprograma koji će izvršiti ovaj fragment. Umjesto pravih, radnih potprograma, u program se ubacuju "stubovi" koji ne rade ništa. Rezultirajući program se provjerava i otklanja greške. Nakon što se programer uvjeri da su potprogrami pozvani u ispravnom redoslijedu (odnosno da je opća struktura programa ispravna), stubne rutine se uzastopno zamjenjuju stvarnim, a razvoj svakog potprograma se odvija u istom način kao glavni program. Razvoj se završava kada ne preostane niti jedan "gag" koji nije uklonjen. Takav slijed osigurava da u svakoj fazi razvoja programer istovremeno radi sa vidljivim i razumljivim skupom fragmenata i može biti siguran da je opća struktura svih viših nivoa programa ispravna. Prilikom održavanja i izmjena programa postaje jasno koje procedure treba promijeniti, a one se rade bez utjecaja na dijelove programa koji nisu direktno povezani s njima. Ovo osigurava da prilikom unošenja izmjena i ispravljanja grešaka neki dio programa koji je trenutno izvan područja pažnje programera neće propasti.

Teorema o strukturiranom programiranju:

Glavni članak: Bohm-Jacopini teorema

Bilo koja algoritamska šema može biti predstavljena kao kompozicija ugniježđenih početnih i završnih blokova, if, then, else uvjetnih izjava, petlji s preduvjetom (while) i mogu postojati dodatne logičke varijable (zastavice).
Ovu teoremu su formulisali italijanski matematičari C. Bohm i G. Jacopini 1966. godine i govori nam kako da izbegnemo korišćenje goto operatora.

istorija

Metodologija strukturiranog programiranja nastala je kao rezultat sve veće složenosti zadataka koji se rješavaju na računarima, te odgovarajuće komplikacije softvera. Sedamdesetih godina prošlog vijeka obim i složenost programa dostigli su takav nivo da je „intuitivni“ (nestrukturirani ili „refleksni“) razvoj programa, koji je u ranijem vremenu bio norma, prestao da zadovoljava potrebe prakse. Programi su postajali previše složeni da bi se pravilno održavali, pa je bila potrebna određena sistematizacija procesa razvoja i strukture programa.

Najjača kritika od strane programera strukturalnog pristupa programiranju bila je GOTO operator (operator bezuslovnog skoka), koji je tada bio dostupan u gotovo svim programskim jezicima. Nepravilna i nepromišljena upotreba proizvoljnih prijelaza u tekstu programa dovodi do zbunjujućih, loše strukturiranih programa (tzv. špageti kod), iz čijeg teksta je gotovo nemoguće razumjeti redoslijed izvršavanja i međuzavisnost fragmenata.

Praćenje principa strukturiranog programiranja učinilo je da tekstovi programa, čak i prilično veliki, budu normalno čitljivi. Razumijevanje programa je postalo mnogo lakše, postalo je moguće razvijati programe u normalnom industrijskom modu, kada program bez većih poteškoća može razumjeti ne samo njegov autor, već i drugi programeri. To je omogućilo da se snagama razvojnih timova razviju softverski sistemi koji su za to vrijeme bili prilično veliki, te da se ovi kompleksi održavaju dugi niz godina, čak i pred neizbježnim promjenama u sastavu osoblja.

Metodologija strukturalnog razvoja softvera prepoznata je kao "najjača formalizacija 70-ih godina". Nakon toga, riječ "strukturalni" postala je moderna u industriji i počela se koristiti svuda gdje je bilo potrebno i gdje nije bilo potrebno. Bilo je radova na "projektu konstrukcija", "konstrukcijskom ispitivanju", "projektu konstrukcija" i tako dalje. Generalno, dogodilo se otprilike isto što se dešavalo 90-ih i trenutno se dešava sa terminima "objekt", "objektno orijentisan" i "elektronski".

Evo nekih od prednosti strukturiranog programiranja:

1. Strukturno programiranje vam omogućava da značajno smanjite broj opcija za pravljenje programa prema istoj specifikaciji, što značajno smanjuje složenost programa i, što je još važnije, olakšava drugim programerima da ga razumiju.
2. U strukturiranim programima, logički povezani operatori su vizualno bliži, a labavo povezani operatori dalje, što omogućava bez dijagrama toka i drugih grafičkih oblika algoritama za prikazivanje (u stvari, sam program je vlastiti dijagram toka).
3. Proces testiranja i otklanjanja grešaka strukturiranih programa uvelike je pojednostavljen.

vidi takođe

Linkovi

Wikimedia fondacija. 2010 .

• Mahajanapada
• kamila

Pogledajte šta je "Strukturirano programiranje" u drugim rječnicima:

Strukturirano programiranje- metodologija i tehnologija razvoja softverskih sistema, zasnovana na principima: top-down programiranja; modularno programiranje. U ovom slučaju, logika algoritma i programa moraju koristiti tri glavne strukture: sekvencijalnu ... ... Finansijski vokabular

strukturirano programiranje- struktūrinis programavimas statusas T sritis automatika atitikmenys: engl. strukturirano kodiranje; strukturirano programiranje vok. strukturelle Programmierung, f rus. strukturirano programiranje, n; strukturirano programiranje, n pranc.… … Automatikos terminų žodynas

Strukturirano programiranje- 46. Strukturirano programiranje Strukturirano programiranje Izvor: GOST 19781 90: Softversko obezbjeđenje sistema za obradu informacija. Uslovi i definicije… Rječnik-priručnik pojmova normativne i tehničke dokumentacije

Programiranje- Ovaj članak treba u potpunosti prepisati. Možda ima objašnjenja na stranici za razgovor. Ovaj izraz ima druga značenja, pogledajte Programi ... Wikipedia

PROGRAMIRANJE- 1) proces izrade programa, akcionog plana. 2) Sekcija informatike koja proučava metode i tehnike programiranja. Sa određenim stepenom konvencionalnosti, P. se kao disciplina deli na: teorijsku, studij matematike. apstrakcije programa (kao objekata sa ... ... Physical Encyclopedia

Programiranje zasnovano na prototipu- Programiranje prototipa je stil objektno orijentisanog programiranja u kojem ne postoji koncept klase, a ponovna upotreba (nasljeđivanje) se vrši kloniranjem postojeće instance objekta prototipa. ... ... Wikipedia.

paradigma (programiranje)- Paradigma programiranja je skup ideja i koncepata koji definira stil pisanja programa. Paradigmu, prije svega, određuje osnovna programska jedinica i sam princip postizanja programske modularnosti. Kao ova jedinica ... Wikipedia

Kompjutersko programiranje- Razvoj softvera Analiza koraka procesa razvoja softvera | Dizajn | Implementacija | Testiranje | Implementacija | Modeli održavanja / metode Agile | čista soba | Iterativno | Scrum | RUP | MSF | Spiral | ... Wikipedia

Nestrukturirano programiranje- Metodologija strukturnog programiranja razvoja softvera, koja se zasniva na predstavljanju programa u obliku hijerarhijske strukture blokova. Predložio ga je 70-ih godina XX vijeka E. Dijkstroy, a razvio i dopunio N. Wirth. U... Wikipediji

Komponentno orijentirano programiranje- Programske paradigme Orijentisane na agente Orijentirane na komponente Konkatenativno Deklarativne (u suprotnosti sa imperativom) Ograničenja Funkcionalni tok podataka Orijentisano na tablice (tabele) Reaktivno ... Wikipedia

Knjige

• Programska disciplina, Dijkstra E.

Strukturirano programiranje predstavlja najveće dostignuće u ovoj oblasti do sada. Iako skoro svi imaju opšti pojam o tome, gotovo niko ne može dati konkretnu i jasnu definiciju ovog pojma. Strukturirano programiranje ima za glavni cilj pisanje programa najmanje složenosti, prisiljavajući programera da jasno razmišlja, čineći program lakšim za razumijevanje. Njegov tekst mora biti napravljen tako da bude čitljiv od vrha do dna. Ovaj uslov se krši ako u programskom kodu postoje naredbe go to, jer one narušavaju strukturu cijelog programskog segmenta. Iako se ovaj indikator ne može smatrati najprikladnijim, ipak se može reći da je prisustvo ovog operatora u programskom kodu najuočljivija vrsta kršenja strukture. Tijela modula i primijenjene osnovne strukture moraju biti otporne na hardverske kvarove, greške u programima i izobličenja izvornih podataka.

Osnovni principi strukturiranog programiranja su sljedeći. Bilo koji program može se lako sintetizirati na osnovu elementarnih konstrukcija tri glavna tipa:

Jednostavan niz;

uslovi ili alternative;

Ponavljanja, odnosno ciklusi i iteracije.

Jedna ili dvije bilo koje vrste mogu se koristiti u isto vrijeme. Svaka struktura ima jednu osobinu - jedinu tačku prenosa kontrole na strukturu i jedinu ulaznu tačku u strukturu. Ova vrsta gradnje ima disciplinovanu i sistematizirajuću vrijednost.

Jednostavnost početnih konstrukcija u strukturiranom programiranju sprečava pojavu informacionih veza, kao i zbunjujuće transfere kontrole. Složenost programa primjetno se smanjuje povećanjem strukture modula, povećava se njihova vidljivost, a to pomaže u smanjenju broja grešaka. Međutim, strukturiranje ima i nedostatak - za ljepotu i jasnoću programskog koda morate platiti dodatnom memorijom, kao i vremenom potrebnim za njihovu implementaciju na računaru.

Strukturno programiranje, odnosno struktura samih programskih tekstova, u potpunosti ovisi o tome koji se jezik za to koristi. Naravno, postavlja se pitanje koji je najprikladniji. Moderni alati za razvoj softvera smatraju se najboljim jezicima koji implementiraju strukturirani pristup programiranju. Među najčešćim su Basic, Pascal i FoxBASE. Na primjer, praktično je nemoguće implementirati principe sadržane u konceptu strukturiranog programiranja. Ovaj jezik je fokusiran na pisanje koda na niskom nivou.

Strukturno programiranje je u osnovi razgovor s ljudima, a ne s mašinama, tako da potiče pisanje programa koji pružaju jasno i jednostavno rješenje za dati problem. Programer mora razmišljati u smislu osnovnih strukturnih konstrukcija.

Što se tiče stava o prethodno navedenoj izjavi, treba je izbjegavati gdje god je to moguće, ali to ni na koji način ne bi trebalo utjecati na jasnoću programa. Ponekad se ispostavi da je upotreba ovog operatora jednostavno neophodna za izlazak iz nekog segmenta programa ili ciklusa, ali i kako bi se izbjegla pojava previše dubokih račva, pogotovo jer je prijelaz povezan s nižim nivoima programa. U isto vrijeme, struktura programa ostaje laka za čitanje od vrha do dna. Najgore od ovog operatora je povezano s prijelazom odozdo prema gore.

Da bi se programi lakše čitali, između sekcija se često dodaju prazni redovi. Vrijedi napisati tekst programa sa pomacima tako da možete pročitati redoslijed radnji i broj priloga.

softver

Strukturalni pristup programiranju je i metodologija i tehnologija za kreiranje programa. Svojevremeno je njegova implementacija osiguravala povećanje produktivnosti programera prilikom pisanja i otklanjanja grešaka u programima; dobijanje programa koji se sastoje od modula i koji su pogodni za održavanje; kreiranje programa od strane tima programera; završetak kreiranja programa u navedenom roku.

Strukturirano programiranje je pristup koji koristi konstrukcije za prijenos kontrole u programu koji omogućavaju sekvencijalni, uslovni i iterativni prijenos kontrole. Zabranjen je bezuslovni prenos kontrole preko naredbe goto. Kao rezultat, svaka složena naredba u programu, koja je kombinacija sekvencijalnih, uslovnih i cikličkih izraza, ima samo jednu ulaznu i izlaznu tačku, što osigurava da se program podijeli na relativno nezavisne fragmente.

Strukturirano programiranje je rezultat primjene aplikativnih metoda na imperativne programe. Za to se koriste proceduralno orijentirani jezici u kojima je moguće opisati program kao skup procedura. Procedure se mogu pozivati ​​jedna drugu, a svaku može pozvati glavni program, što se također može smatrati procedurom.

Struktura programa su dijelovi programa koji su u interakciji umjetno odabrani od strane programera. Upotreba racionalne strukture eliminiše problem složenosti razvoja, čini program razumljivim korisnicima, povećava pouzdanost programa uz smanjenje vremena njegovog testiranja i razvoja.

Vrlo često, određeni niz instrukcija treba ponoviti na različitim mjestima u programu. Kako bi spriječili programera da troši vrijeme i trud na kopiranje ovih uputstava, mnogi programski jezici pružaju mogućnost organiziranja potprograma. Programer može nizu instrukcija dati proizvoljan naziv i koristiti ovo ime kao skraćenicu na onim mjestima gdje se javlja odgovarajući niz instrukcija. Dakle, potprogram je neka sekvenca instrukcija koja se može pozvati na nekoliko mjesta u programu. Potprogrami se zovu procedure i funkcije.

Opis potprograma sastoji se od dva dijela: zaglavlja i tijela. Zaglavlje sadrži identifikator potprograma i varijable koje se koriste u njemu. Tijelo se sastoji od jedne ili više instrukcija. Identifikator potprograma se koristi kao skraćenica na onim mjestima u programu gdje se javlja odgovarajući niz instrukcija.

Procedure i funkcije, zvane potprogrami, jedan su od onih nekoliko osnovnih alata u umjetnosti programiranja koji imaju odlučujući utjecaj na stil i kvalitet rada programera.

Procedura nije samo način da se reducira programski tekst, već i sredstvo za dekomponovanje programa na logički povezane, zatvorene elemente koji određuju njegovu strukturu. Rastavljanje programa na dijelove je bitno za razumijevanje programa, posebno ako je program složen i teško ga je vidjeti zbog velike dužine teksta. Dekompozicija na potprograme je neophodna i za dokumentovanje i za verifikaciju programa. Zbog toga je poželjno da se redosled instrukcija uredi kao potprogram, čak i ako se program koristi jednom, pa stoga nema motiva koji je povezan sa smanjenjem teksta programa.

Informacije o varijablama ili uslovima koje argumenti moraju zadovoljiti su date u zaglavlju procedure. Korisnost postupka, posebno njegove uloge u strukturiranju programa, neosporno je dokazana još dva koncepta u programiranju. Pomoćne ili lokalne varijable koje se koriste unutar procedure nemaju značenje izvan procedure. Program stvorenja je lakše razumjeti ako su opseg takvih varijabli eksplicitno specificiran. Procedura djeluje kao prirodna tekstualna jedinica, uz pomoć koje je ograničen opseg postojanja lokalnih varijabli.

Najčešća taktika programiranja je razlaganje procesa u zasebne korake:

• - funkcionalni opis podfunkcija;
• - odgovarajući programi pojedinačnim uputstvima.

U svakom takvom koraku dekompozicije potrebno je osigurati da rješenja pojedinih problema dovedu do rješenja općeg problema, da je odabrani slijed pojedinačnih radnji razuman i da omogućava dobijanje instrukcija koje su u nekom smislu bliže jeziku na kojem program će biti implementiran. Ovaj zahtjev isključuje mogućnost direktnog napretka od početne formulacije problema do konačnog programa, koji bi na kraju trebao biti dobijen. Svaka faza dekompozicije je praćena formulacijom određenih potprograma. U toku ovog rada može se ispostaviti da je odabrana dekompozicija neuspješna u smislu da je nepogodno izražavati potprograme korištenjem raspoloživih sredstava. U ovom slučaju, jedan ili više prethodnih koraka dekompozicije treba ponovo razmotriti.

Ako u faznoj dekompoziciji i istovremenom razvoju i detaljiziranju programa vidimo postepeno napredovanje u dubinu, onda se ovaj metod u rješavanju problema može okarakterisati kao top-down (top-down). I obrnuto, moguć je takav pristup rješavanju problema, kada programer prvo prouči kompjuter ili programski jezik koji mu je na raspolaganju, a zatim sklopi neke nizove instrukcija u elementarne procedure tipične za problem koji se rješava. Elementarne procedure se zatim koriste na sljedećem nivou hijerarhije procedura. Ova metoda prijelaza sa primitivnih strojnih instrukcija na potrebnu implementaciju programa naziva se odozdo prema gore (bottom-up).

U praksi se razvoj programa nikada ne može odvijati striktno u jednom smjeru - odozgo prema dolje ili odozdo prema gore. Međutim, kod konstruisanja novih algoritama obično dominira metoda odozgo prema dolje. S druge strane, kada se program prilagođava malo izmijenjenim zahtjevima, često se preferira metoda odozdo prema gore.

Obje metode omogućavaju razvoj programa koji imaju strukturu, osobinu koja ih razlikuje od amorfnih linearnih sekvenci strojnih instrukcija ili naredbi. Važno je da jezik koji se koristi u potpunosti odražava ovu strukturu. Tek tada će nam konačni oblik rezultirajućeg programa omogućiti primjenu sistematskih metoda verifikacije.

Ako je program razbijen na potprograme, često je potrebno uvesti nove varijable koje predstavljaju rezultate i argumente i tako uspostaviti vezu između potprograma. Takve varijable treba uvesti i opisati u fazi razvoja u kojoj su potrebne. Štaviše, detaljnost opisa procesa može biti popraćena detaljima opisa strukture korištenih varijabli. Stoga jezik mora imati sredstva da odražava hijerarhijsku strukturu podataka. Ovo pokazuje koliko je važan koncept procedure, lokalnost procedura i podataka i strukturiranje podataka u razvoju programa korak po korak.

Dizajn počinje fiksiranjem vanjskih specifikacija. Na osnovu eksternih specifikacija sastavlja se opis internog algoritma programa, obavezno sa strukturom internih podataka. Dalje, velike funkcije se raščlanjuju na podfunkcije dok se ne dostigne podfunkcija veličine modula - potprogrami programskog jezika koji imaju posebne dodatne zahtjeve.

Osnovni koncept i funkcionalni element tehnologije strukturiranog programiranja je modul.

Modul je potprogram, ali je formatiran prema sljedećim pravilima:

• 1. modul mora imati jedan ulaz i jedan izlaz i obavljati striktno nedvosmislenu funkciju, koja se opisuje jednostavnom uobičajenom rečenicom prirodnog (ruskog) jezika ili čak rečenicom bez predikata;
• 2. modul mora da obezbedi kompilaciju nezavisno od drugih modula, uz „zaboravljanje“ svih internih vrednosti modula;
• 3. modul može pozvati druge module njihovim imenima;
• 4. Dobar modul ne koristi globalne varijable za komunikaciju sa drugim modulom, jer je tada teško pronaći modul koji kvari podatke. Kada koristite globalne varijable, morate jasno komentirati one module koji samo čitaju i one module koji mogu mijenjati podatke;
• 5. Modul je kodiran samo sa standardnim strukturama i pažljivo je komentarisan.

Koncept strukture programa uključuje sastav i opis veza svih modula koji implementiraju nezavisne funkcije programa i opis nosilaca podataka uključenih u razmjenu, kako između pojedinačnih potprograma, tako i ulaza i izlaza sa vanjskih uređaja.

U slučaju složenog, velikog programa potrebno je ovladati posebnim tehnikama za dobijanje racionalne programske strukture. Racionalna struktura programa omogućava skoro dvostruko smanjenje količine programiranja i višestruko smanjenje obima i vremena testiranja, stoga suštinski smanjuje troškove razvoja.

Podređenost modula je prikladno predstavljena hijerarhijskim dijagramom. Hijerarhijski dijagram odražava samo potprograme, ali ne i redosled kojim se pozivaju ili rad programa.

Prije izrade hijerarhijskog dijagrama preporučljivo je izraditi eksterne programske specifikacije i izraditi funkcionalne opise programa, zajedno sa opisom varijabli - nosača podataka. Posebnu pažnju treba posvetiti hijerarhiji strukturiranih tipova podataka i njihovom komentarisanju. Dekompozicija programa na potprograme vrši se po principu od opšteg ka detaljnijem. Proces pisanja funkcionalnog opisa i izrade hijerarhijskog dijagrama je iterativan. Izbor najbolje opcije je višekriterijumski.

• - modularnost programa;
• - strukturno kodiranje programskih modula;
• - top-down dizajn racionalne hijerarhije programskih modula;
• - silazna implementacija programa pomoću stubova;
• - implementacija planiranja u svim fazama projekta;
• - end-to-end strukturna kontrola softverskih sistema uopšte i njihovih sastavnih modula.

Modularnost programa karakteriše činjenica da se cijeli program sastoji od modula. Neke semantičke grupe modula su koncentrisane u odvojenim datotekama. Na primjer, moduli uređivača teksta i hijerarhijski moduli menija mogu biti koncentrisani u odvojenim datotekama (Jedinica).

Strukturno kodiranje programskih modula sastoji se u posebnom dizajnu njihovih tekstova. Modul treba da ima lako prepoznatljiv naslov sa komentarom koji objašnjava funkcionalnost modula. Imena varijabli moraju biti mnemonička. Suštinu varijabli i redoslijed po kojem se informacije stavljaju u njih treba objasniti komentarima, kod modula je kodiran pomoću tipičnih algoritamskih struktura pomoću uvlaka.

Odozgo prema dolje dizajn racionalne hijerarhije programskih modula sastoji se u dodjeli početnih modula najvišeg nivoa hijerarhije, a zatim i podređenih modula.

Implementacija programa odozgo prema dolje sastoji se u primarnoj implementaciji grupe modula viših nivoa, koji se nazivaju jezgro programa, a zatim se postepeno, u skladu sa planom, implementiraju moduli nižih nivoa. . Neophodni za povezivanje programa, moduli koji nedostaju se imitiraju stubovima.

Implementacija planiranja u svim fazama projekta omogućava vam da u početku planirate kako sastav faza tako i trajanje svih faza rada. Takvo planiranje vam omogućava da završite razvoj u datom vremenu uz datu cijenu razvoja.

Kontrola konstrukcije od kraja do kraja sastoji se u pridržavanju unaprijed određenog plana ispitivanja, koji pokriva period od razvoja eksternih specifikacija, zatim internih specifikacija i njihovog prilagođavanja tokom perioda implementacije do testova prihvata. Moduli koji čine program testiraju se kako u trenutku pisanja njihovog koda, tako i tokom samostalnog testiranja, pregleda njihovog izvornog koda, prilikom testiranja neposredno nakon povezivanja na kernel.

U strukturiranom programiranju, program se uglavnom implementira (sastavlja i testira) od vrha prema dolje. Prvo, kernel je napisan od 20-30 modula. Za početak testiranja, nedostajući moduli nižeg nivoa se zamjenjuju stubovima. Na kraju testiranja kernela, stubovi se zamjenjuju novim gotovim modulima, ali ako program još nije završen, tada će biti potrebni svi novi stubovi modula koji nedostaju za uspješno povezivanje. Zatim se testira sastavljeni dio itd.

Stub je raspored modula. Najjednostavniji stub je rutina ili funkcija bez akcije. Složeniji stub može prikazati poruku u kojoj se navodi da je taj i takav modul završen. Čak i složeniji stubovi mogu izvesti ulaz u neku datoteku za otklanjanje grešaka. Konačno, još složeniji stubovi daju informacije o testu potrebne za testiranje već implementiranih modula. Pisanje stubova je suvišan posao, ali je potrebna vještina dizajnera da što više stubova bude što jednostavnijim i da temeljno testira već izgrađeni dio programa.

Dizajniranju strukture programa prethodi razvoj eksternih funkcionalnih opisa. Funkcionalni opisi (algoritmi za izvršavanje programa) da bi se postigla njihova percepcija moraju se dekomponovati od opšteg do posebnog. Takođe treba da sadrže opise oblika prezentacije i količine internih podataka.

Za početak, postoji prva verzija hijerarhijske sheme, dobijena jednostavnim podjelom programskih funkcija na podfunkcije, što ukazuje na varijable potrebne za postavljanje podataka u različite korake obrade. Umjesto toga, ova opcija nije optimalna i potrebne su iteracije dizajna kako bi se poboljšala topologija kola.

Svaka nova varijanta se poredi sa prethodnom varijantom prema ovde opisanim kriterijumima. Generisanje varijanti se zaustavlja kada daljnja poboljšanja nisu moguća.

Fond kriterijuma za optimalnost hijerarhijskih šema je neophodna pomoć u optimizaciji hijerarhijskih šema i sastoji se od sledećih kriterijuma:

• - potpunost obavljanja navedenih funkcija;
• - mogućnost brzog i jeftinog dopunjavanja novim, prethodno nespecificiranim funkcijama;
• - preglednost za dizajnera sastavnih dijelova programa;
• - maksimalna samostalnost prema podacima pojedinih dijelova programa;
• - mogućnost povezivanja programa sa opsežnom hijerarhijskom šemom na više nivoa sa određenim uređivačem linkova (linker). Ako počne rad na novom programu, onda je vrlo korisno izvršiti njegov model na računaru u obliku praznih stubova modula koji ne sadrže nikakve radnje;
• - dovoljnost radne memorije. Ovdje se razmatraju opcije sa opisom posebno strukturiranih statičkih i dinamičkih varijabli na različitim nivoima hijerarhijskog dijagrama. Provjera ispunjenosti ovog kriterija vrši se proračunima uz neke kompjuterske eksperimente;
• - procena uticaja topologije hijerarhijske šeme na brzinu izvršavanja programa pri korišćenju preklapanja (dinamičko učitavanje programa) i mehanizma straničenja pri razvoju programa koji se ne može u potpunosti smestiti u RAM;
• - nepostojanje različitih modula koji obavljaju slične radnje. U idealnom slučaju, isti modul se poziva na različitim nivoima hijerarhijske šeme;
• - postizanje u toku realizacije programa ovakvog mrežnog rasporeda za rad tima programera koji obezbjeđuje ujednačeno opterećenje tima na ključne datume projekta;
• - na svaki mogući način da se smanji trošak testiranja već montiranog jezgra programa prema ključnim datumima plana implementacije mreže. Odlikuje se jednostavnošću korištenih stubova i kvalitetom testiranja duž svih računskih ruta modula. Postiže se primarnom implementacijom od vrha do dna ulaznih i izlaznih modula programa sa kašnjenjem u implementaciji preostalih grana hijerarhijske šeme. Tipično, trošak testiranja iznosi oko 60% cijene cijelog projekta. Dobra hijerarhijska shema smanjuje troškove testiranja za 2-5 puta ili više u odnosu na originalnu verziju;
• - korištenje u ovom projektu što više modula i biblioteka razvijenih u prethodnim projektima sa minimalnom količinom prerađenih dijelova;
• - uspješna distribucija modula po kompajliranim programskim datotekama i bibliotekama;
• - akumulacija gotovih modula i biblioteka modula za upotrebu u svim novim razvojima.

U zaključku se može napomenuti da je strukturni pristup programiranju usvojio i koristi mnoge metode iz oblasti projektovanja složenih tehničkih sistema. Među njima su blok-hijerarhijski pristup dizajnu složenih sistema, scensko kreiranje programa, dizajn odozgo prema dolje, metode evaluacije i planiranja.