Definirati i opisati modularno programiranje. Modularno programiranje - PIE.Wiki. Minimiziranje broja proslijeđenih parametara

Materijal sa PIE.Wiki

esencija modularno programiranje sastoji se u podjeli složenog problema na niz jednostavnijih podzadataka i kompajliranju programa za njihovo rješavanje sasvim nezavisno jedan od drugog. Modularnost je jedan od osnovnih principa izgradnje softverskih projekata. U opštem slučaju, modul je zasebna funkcionalno zaokružena programska jedinica, na neki način identifikovana i kombinovana sa drugima, sredstvo za određivanje logički povezanog skupa objekata, sredstvo za njihov odabir i izolaciju. Modul je sredstvo za dekompoziciju ne samo kontrolnih struktura, već i struktura podataka. Ovo je u velikoj mjeri olakšano razvojem koncepta "tip podataka".

Modul je jedinica kompilacije, skladištenja, kao i jedinica dizajna i odvojenog razvoja softverskog projekta od strane tima programera. Dakle, modul se shvata kao sredstvo za definisanje logički povezanog skupa objekata, kao sredstvo za njihov odabir i izolaciju.

Kreiranje modula i korištenje njihovih objekata u programima je jedan od trikova ekonomično programiranješto je zbog sljedećih okolnosti.

Prvo, modul obično definiše objekte koji su nosioci osnovnih pojmova neke "predmetne" oblasti, tako da modul postavlja kontekst ove predmetne oblasti. Stoga će programi koji će izvoditi različite algoritme obrade u ovoj oblasti moći koristiti gotove i, što je najvažnije, iste definicije osnovnih objekata.

Drugo, kompajliraju se i moduli i programi koji ih koriste bez obzira(modul mora biti preveden prije programa koji ga koristi). Zbog toga je značajno smanjeno vrijeme kompilacije velikog programa koji koristi gotove module, što je važno pri otklanjanju grešaka u programima kada ih morate više puta kompajlirati.

Treće važno svojstvo modula je da skriva, "inkapsulira" reprezentaciju i implementaciju objekata koje izvozi, tako da njihove moguće promjene u modulu (kada je konfiguriran ili prilagođen novim hardverskim mogućnostima) ne zahtijevaju nikakve izmjene korisničkih programa.

Svi moduli koriste mnemonička imena za objekte koje definiraju (konstante, varijable, tipovi i podprogrami), što olakšava razumijevanje njihove svrhe i pamćenje, zadovoljava zahtjev vidljivost teksta programe.

Programski jezici koji podržavaju modularni pristup opisuju modul kao softversku jedinicu koja se sastoji od dva glavna dijela – specifikacije (interfejsa) i implementacije. Specifikacija pruža takve karakteristike objekata modula koje su neophodne i dovoljne za upotrebu ovih objekata u drugim modulima i programima. Ovo omogućava da se objekti modula koriste samo na osnovu informacija o njihovom interfejsu (bez čekanja na njih kompletan opis). Implementacijski dio modula opisuje algoritme predstavljanja i obrade koji su povezani sa određenim objektima modula.

Modul je jedan od alata koji olakšavaju verifikaciju programa. Modul, kao sredstvo za kreiranje apstrakcije, ističe specifikaciju i lokalizuje informacije o implementaciji.

Moduli također služe za stvaranje konteksta specifičnog za domenu i lokaliziranje ovisnosti stroja.

Koncept modularnog programiranja

Koncept modularnog programiranja može se formulirati u obliku nekoliko koncepata i odredbi:

• Funkcionalna dekompozicija zadatka je podjela velikog zadatka na veći broj manjih, funkcionalno nezavisnih podzadataka – modula. Moduli su međusobno povezani samo ulaznim i izlaznim podacima.
• Modul je osnova koncepta modularnog programiranja. Svaki modul u funkcionalnoj dekompoziciji je "crna kutija" sa jednim ulazom i jednim izlazom. Modularni pristup omogućava bezbolnu nadogradnju programa tokom njegovog rada i olakšava njegovo održavanje. Dodatno, modularni pristup vam omogućava da razvijete dijelove programa jednog projekta na različitim programskim jezicima, a zatim koristite alate za sklapanje kako biste ih kombinirali u jedan modul za pokretanje.
• Implementirana rješenja trebaju biti jednostavna i jasna. Ako svrha modula nije jasna, onda to ukazuje na to da dekompozicija početnog ili srednjeg zadatka nije urađena dovoljno dobro. U tom slučaju potrebno je ponovo analizirati zadatak i, eventualno, izvršiti dodatnu podjelu na podzadatke. Ako postoje teška mjesta u projektu, potrebno ih je detaljnije dokumentirati koristeći dobro osmišljen sistem komentara. Ovaj proces treba nastaviti sve dok zaista nije moguće postići jasno razumijevanje svrhe svih modula problema i njihovu optimalnu kombinaciju.
• Svrha svih varijabli modula treba biti opisana korištenjem komentara kako su definirane.

Književnost

1. MM. Bežanova, L.A. Moskvin. Praktično programiranje. Tehnike kreiranja programa u Pascal-u. M.: Naučni svet, 2000, 270 str.
2. Istomin E.P., Novikov V.V., Novikova M.V. Metode informatike i programiranja visokog nivoa: Udžbenik. - St. Petersburg. LLC "Adreevsky Publishing House", 2006 - 228 str.

1.3.1. Svrha modularnog programiranja.

Modularno programiranje na osnovu koncepta modul - logički međusobno povezani skup funkcionalnih elemenata, dizajniranih kao zasebni softverski moduli.

Modul karakteriše:

1. jedan ulaz i jedan izlaz - na ulazu programski modul prima određeni skup početnih podataka, vrši smislenu obradu i vraća jedan skup podataka o rezultatu, tj. implementiran je standardni princip IPO (Input - Process - Output) - ulaz-proces-izlaz;
2. funkcionalna kompletnost - modul vrši listu regulisanih operacija za realizaciju svake pojedinačne funkcije u celini, dovoljnu za završetak započete obrade;
3. logička nezavisnost - rezultat rada programskog modula zavisi samo od početnih podataka, ali ne zavisi od rada drugih modula;
4. slabe informacione veze sa drugim programskim modulima - razmjenu informacija između modula treba minimizirati ako je moguće;
5. programski element koji je predvidljiv po veličini i složenosti.

Dakle, moduli sadrže definiciju podataka dostupnih za obradu, operacije obrade podataka, šeme međusobnog povezivanja sa drugim modulima.

Svaki modul se sastoji od specifikacije i tijela. Specifikacije definiraju pravila za korištenje modula, a tijelo definira kako se proces obrade implementira.

Kada počinjemo da razvijamo svaki FP program, treba imati na umu da se obično radi o velikom sistemu, pa moramo preduzeti korake da ga pojednostavimo. Da bi se to postiglo, takav program se razvija u dijelovima, koji se nazivaju programski moduli. A ovaj metod razvoja programa naziva se modularno programiranje. Softverski modul- ovo je bilo koji fragment opisa procesa, osmišljen kao nezavisan softver, pogodan za upotrebu u opisima procesa. To znači da se svaki programski modul programira, kompajlira i debagira odvojeno od ostalih programskih modula, i na taj način fizički odvojen od ostalih programskih modula. Štaviše, svaki razvijeni softverski modul može biti uključen u različite programe ako su ispunjeni uslovi za njegovu upotrebu, deklarisani u dokumentaciji za ovaj modul. Dakle, softverski modul se može posmatrati i kao sredstvo za borbu protiv složenosti programa, i kao sredstvo za borbu protiv dupliranja u programiranju (tj. kao sredstvo za akumulaciju i ponovnu upotrebu znanja programera).

Modularno programiranje je oličenje u procesu razvoja programa i jednog i drugog uobičajene metode borba protiv složenosti i osiguranje nezavisnosti komponenti sistema, te korištenje hijerarhijskih struktura. Za implementaciju prve metode formulišu se određeni zahtjevi koje softverski modul mora zadovoljiti, tj. identifikuju se glavne karakteristike "dobrog" softverskog modula. Za implementaciju druge metode koriste se modularne programske strukture nalik stablu (uključujući stabla sa spojenim granama).

1.3.2. Glavne karakteristike softverskog modula.

Ne doprinosi svaki programski modul pojednostavljenju programa. Odabir dobrog modula sa ove tačke gledišta je ozbiljan kreativni zadatak. Neki kriteriji se koriste za procjenu prihvatljivosti odabranog modula. Stoga je Holt predložio sljedeća dva opšta takva kriterija:

• dobar modul je lakši spolja nego iznutra;
• dobar modul je lakši za korišćenje nego za izgradnju.

Myers predlaže korištenje više karakteristika dizajna softverskog modula za procjenu njegove prihvatljivosti: veličina modula; snaga modula; povezivanje sa drugim modulima; modul rutina (nezavisnost od istorije poziva prema njemu).

Veličina Modul se mjeri brojem iskaza (redova) koje sadrži. Modul ne smije biti premali ili prevelik. Mali moduli dovode do glomazne modularne strukture programa i možda nisu vrijedni troškova povezanih s njihovim dizajnom. Veliki moduli su nezgodni za proučavanje i mijenjanje, mogu značajno povećati ukupno vrijeme ponovnog prevođenja programa prilikom otklanjanja grešaka u programu. Tipično se preporučuju programski moduli veličine od nekoliko desetina do nekoliko stotina operatera.

Snaga modul je mjera njegovih unutrašnjih veza. Što je veća snaga modula, to više veza može sakriti od vanjskog dijela programa u odnosu na njega i samim tim veći doprinos pojednostavljivanju programa može dati. Za procjenu stepena snage modula, Myers predlaže set od sedam klasa modula poredanih po stepenu snage. Modul ima najslabiji stepen čvrstoće, sticajem okolnosti. Ovo je takav modul, između čijih elemenata nema smislenih veza. Takav modul se može izdvojiti, na primjer, kada se na različitim mjestima programa nađe ponavljanje istog niza iskaza, koji se formira u poseban modul. Potreba za promjenom ovog niza u jednom od konteksta može dovesti do promjene u ovom modulu, što može učiniti njegovu upotrebu u drugim kontekstima pogrešnom. Ova klasa softverskih modula se ne preporučuje za upotrebu. Uopšteno govoreći, poredak prema stepenu jačine klasa modula koji je predložio Myers nije neosporan. Međutim, to nije od velike važnosti, jer se za upotrebu preporučuju samo dvije najveće klase čvrstoće modula. Detaljnije ćemo razmotriti ove klase.

Funkcionalno izdržljiv Modul je modul koji izvodi (implementira) jednu specifičnu funkciju. Prilikom implementacije ove funkcije, takav modul može koristiti druge module. Ova klasa softverskih modula se preporučuje za upotrebu.

Informativno izdržljiv modul je modul koji izvodi (realizuje) nekoliko operacija (funkcija) na istoj strukturi podataka (informacioni objekt), koja se smatra nepoznatom izvan ovog modula. Za svaku od ovih operacija, takav modul ima svoj ulaz sa vlastitim oblikom pristupa. Takvu klasu treba smatrati klasom programskih modula sa najvišim stepenom jačine. Modul jačine informacija može implementirati, na primjer, apstraktni tip podataka.

AT modularni jezici programiranje, barem postoje sredstva za definiranje funkcionalno stabilnih modula (na primjer, modul tipa FUNCTION u jeziku FORTRAN). Sredstva za specifikaciju informaciono jakih modula u ranim programskim jezicima su izostala - pojavila su se samo u kasnijim jezicima. Dakle, u programskom jeziku Ada, sredstvo za specifikaciju informacijski izdržljivog modula je paket.

Kvačilo Modul je mjera njegove ovisnosti o podacima o drugim modulima. Karakteriše ga način prenosa podataka. Što je slabija povezanost modula sa drugim modulima, to je jača njegova nezavisnost od drugih modula. Za procjenu stepena kohezije, Myers predlaže uređeni skup od šest tipova kohezije modula. Najgora vrsta spajanja modula je povezanost sadržaja. Ovo je spajanje dva modula kada jedan od njih ima direktne reference na sadržaj drugog modula (na primjer, na konstantu sadržanu u drugom modulu). Takvo spajanje modula je neprihvatljivo. Takođe se ne preporučuje upotreba opšta adhezija područja- ovo je takva konkatenacija modula, kada nekoliko modula koristi isto memorijsko područje. Ova vrsta povezivanja modula se implementira, na primjer, kod programiranja na FORTRAN jeziku korištenjem COMMON blokova. Jedini tip ulančavanja modula koji se preporučuje za korištenje modernom tehnologijom programiranja je parametarsko ulančavanje (Myers data chaining) - to je slučaj kada se podaci prenose u modul ili kada im se pristupa kao vrijednost njegovih parametara, ili kao rezultat njegovog pristupa drugom modulu za izračunavanje neke funkcije. Ova vrsta ulančavanja modula implementirana je u programskim jezicima koristeći pozive procedurama (funkcijama).

Rutinost modula je njegova nezavisnost od istorije poziva na njega. Modul će biti pozvan rutina, ako rezultat (efekt) njegovog poziva ovisi samo o vrijednostima njegovih parametara (i ne ovisi o povijesti poziva prema njemu). Modul će biti pozvan zavisno od pozadine, ako rezultat (efekat) njegovog poziva zavisi od internog stanja ovog modula, koji čuva tragove prethodnih poziva prema njemu. Myers ne preporučuje upotrebu (nepredvidivih) modula zavisnih od istorije, jer oni unose lukave (neuhvatljive) greške u programe. Međutim, takva preporuka nije konstruktivna, budući da je u mnogim slučajevima modul ovisan o istoriji najbolja implementacija modula sa jakim informacijama. Stoga je prihvatljivija sljedeća (opreznija) preporuka:

• rutinski modul treba uvijek koristiti osim ako to rezultira lošim (ne preporučuje se) spajanje modula;
• moduli zavisni od istorije treba da se koriste samo kada je to neophodno da bi se obezbedilo parametarsko povezivanje;
• u specifikaciji modula koji zavisi od istorije, ova zavisnost mora biti jasno formulisana na takav način da je moguće predvideti ponašanje (efekat izvršenja) ovog modula sa različitim kasnijim pozivima na njega.

U vezi sa posljednjom preporukom, može biti korisno definirati eksternu (usmjerenu na čovjeka) reprezentaciju stanja modula ovisnog o povijesti. U ovom slučaju, efekat izvršavanja svake funkcije (operacije) koju implementira ovaj modul treba opisati u terminima ove eksterne reprezentacije, što će u velikoj meri pojednostaviti predviđanje ponašanja ovog modula.

1.3.3. Modularna struktura softverskih proizvoda

Principi modularnog programiranja softverskih proizvoda su na mnogo načina slični principima top-down dizajna. Prvo se utvrđuje sastav i podređenost funkcija, a zatim - set softverskih modula koji implementiraju ove funkcije.

Funkcije istog tipa implementiraju isti moduli. Omogućena je funkcija najvišeg nivoa main modul; kontroliše izvršavanje nižih funkcija, koje odgovaraju podređeni moduli.

Prilikom određivanja skupa modula koji implementiraju funkcije određenog algoritma, treba uzeti u obzir sljedeće:

1. svaki modul se poziva na izvršenje od strane modula višeg nivoa i, nakon što završi svoj rad, vraća kontrolu modulu koji ga je pozvao;
2. donošenje glavnih odluka u algoritmu se podiže na najviši mogući nivo u hijerarhiji;
3. za korištenje iste funkcije na različitim mjestima algoritma, kreira se jedan modul koji se poziva na izvršenje po potrebi. Kao rezultat daljeg usavršavanja algoritma, a funkcionalna i modularna shema (FMS) aplikativnog algoritma, koja je osnova za programiranje.

Sastav i tip programskih modula, njihova namjena i priroda upotrebe u programu u velikoj mjeri određuju alati. Na primjer, u odnosu na DBMS alate, pojedinačni moduli mogu biti:

1. ekranski obrasci za unos i/ili uređivanje informacija baze podataka;
2. izvještaji generatora izvještaja;
3. makroi;
4. standardne procedure obrade informacija;
5. meni koji vam omogućava da odaberete funkciju obrade itd.

1.3.4. Metode razvoja strukture programa.

Kao što je gore navedeno, uobičajeno je koristiti strukturu stabla kao modularnu strukturu programa, uključujući stabla sa spojenim granama. Čvorovi takvog stabla sadrže programske module, a usmjereni lukovi (strelice) pokazuju statičku podređenost modula, tj. svaki luk pokazuje da u tekstu modula iz kojeg potiče postoji veza do modula kojem pripada. Drugim riječima, svaki modul može pristupiti svojim podređenim modulima, tj. izraženo u terminima ovih modula. Istovremeno, modularna struktura programa, u krajnjoj liniji, treba da sadrži i skup specifikacija za module koji čine ovaj program. Specifikacija programski modul sadrži, prvo, sintaksičku specifikaciju svojih ulaza, što omogućava konstruiranje sintaksički ispravne žalbe na njega (bilo koji od njegovih ulaza) u korištenom programskom jeziku, i, drugo, funkcionalnu specifikaciju modula ( opis semantike funkcija koje obavlja ovaj modul za svaku od svojih ulaza). Funkcionalna specifikacija modula je izgrađena na isti način kao i funkcionalna specifikacija PS-a.

Tokom razvoja programa, njegova modularna struktura se može formirati na različite načine i koristiti za određivanje redosleda programiranja i otklanjanja grešaka modula navedenih u ovoj strukturi. Stoga se može govoriti o različitim metodama razvoja strukture programa. U literaturi se obično razmatraju dvije metode: razvojna metoda odozdo prema gore i metoda razvoja od vrha prema dolje.

Metoda razvoj odozdo prema gore je kako slijedi. Prvo, modularna struktura programa je izgrađena u obliku stabla. Zatim se programski moduli programiraju jedan po jedan, počevši od modula najnižeg nivoa (listova stabla strukture modula programa), tako da za svaki programabilni modul već imaju svi moduli kojima može pristupiti. programirano. Nakon što su svi programski moduli programirani, oni se redom testiraju i otklanjaju greške, u principu, istim (uzlaznim) redoslijedom u kojem su programirani. Na prvi pogled, ovakav redoslijed razvoja programa izgleda sasvim prirodan: pri programiranju se svaki modul izražava kroz direktno programirane podređene module, a prilikom testiranja koristi već debagovane module. Kako god, moderna tehnologija ne preporučuje takav redosled razvoja programa. Prvo, za programiranje bilo kojeg modula, tekstovi modula koje on koristi uopće nisu potrebni - za to je dovoljno da je svaki korišteni modul samo specificiran (u mjeri u kojoj se može izgraditi ispravna privlačnost za njega), i za testiranje je moguće (pa čak, kao što ćemo pokazati u nastavku, korisno) koristiti module da ih zamijene simulatorima (stubovima). Drugo, svaki program je u određenoj mjeri podložan nekim internim razmatranjima, ali globalnim za svoje module (principi implementacije, pretpostavke, strukture podataka, itd.), koji određuju njegov konceptualni integritet i formiraju se u procesu njegovog razvoja. Tokom razvoja odozdo prema gore, ove globalne informacije za module nižeg nivoa još nisu potpuno jasne, pa ih je vrlo često potrebno reprogramirati kada se, prilikom programiranja drugih modula, ove globalne informacije značajno rafiniraju (na primjer, globalna struktura podataka promjene). Treće, tokom testiranja odozdo prema gore, za svaki modul (osim glavnog) potrebno je kreirati vodeći program (modul), koji mora pripremiti potrebno stanje informacionog okruženja za modul koji se testira i napraviti traženo pozovite to. Ovo dovodi do mnogo "debagovanja" programiranja i istovremeno ne daje nikakvu garanciju da su moduli testirani upravo pod uslovima u kojima će se izvršavati u radnom programu.

Metoda razvoj odozgo prema dolje je kako slijedi. Kao iu prethodnoj metodi, modularna struktura programa se prvo gradi u obliku stabla. Zatim se moduli programa programiraju jedan po jedan, počevši od modula najvišeg nivoa (glava), prelazeći na programiranje nekog drugog modula samo ako je modul koji mu pristupa već programiran. Nakon što su svi programski moduli programirani, oni se testiraju i otklanjaju greške jedan po jedan u istom (opadajućem) redoslijedu. Ovakvim redosledom razvoja programa, sve potrebne globalne informacije se generišu blagovremeno, tj. vrlo neugodan izvor pogrešnih proračuna kada se eliminišu programski moduli. Umnogome je olakšano i testiranje modula koje se sprovodi tokom top-down testiranja programa. Najprije se testira glavni modul programa koji predstavlja cijeli program koji se testira i samim tim se testira u "prirodnom" stanju informacionog okruženja u kojem ovaj program počinje da radi. U tom slučaju svi moduli kojima glava može pristupiti zamjenjuju se njihovim imitatorima (tzv. stubovi). Svaki simulator modulačini se vrlo jednostavnim programskim fragmentom koji signalizira, u osnovi, samu činjenicu pristupa simuliranom modulu uz obradu vrijednosti njegovih ulaznih parametara neophodnih za ispravan rad programa (ponekad i njihovim ispisom) i sa izdavanje, ako je potrebno, prethodno pohranjenog odgovarajućeg rezultata. Nakon završetka testiranja i otklanjanja grešaka glave i bilo kojeg narednog modula, vrši se prijelaz na testiranje jednog od modula koji su trenutno predstavljeni simulatorima, ako ih ima. Da biste to učinili, simulator modula odabranog za testiranje zamjenjuje se samim ovim modulom, a dodaju se simulatori onih modula kojima može pristupiti modul odabran za testiranje. Štaviše, svaki takav modul će biti testiran pod "prirodnim" stanjima informacionog okruženja koja se javljaju u trenutku kada se ovom modulu pristupi tokom izvršavanja programa koji se testira. Tako je velika količina programiranja za "debagovanje" zamijenjena programiranjem prilično jednostavnih simulatora modula koji se koriste u programu. Osim toga, simulatori su korisni za igranje zajedno s procesom odabira testa specificiranjem željenih rezultata koje simulatori proizvode.

Neki nedostatak razvoja odozgo prema dolje, koji dovodi do određenih poteškoća u njegovoj primjeni, je potreba da se apstrahuje od osnovne sposobnosti programski jezik koji se koristi, izmišljanje apstraktnih operacija koje će kasnije morati da se implementiraju pomoću modula istaknutih u programu. Međutim, čini se da je sposobnost za takve apstrakcije neophodan uslov za razvoj velikih softverskih alata, pa je treba razvijati.

U razmatranim metodama razvoja odozdo prema gore i odozgo prema dolje (koje ćemo nazvati klasična) modularnu strukturu stabla programa treba razviti prije programiranja modula. Međutim, ovaj pristup izaziva niz zamjerki: čini se sumnjivim da bi prije programiranja modula bilo moguće razviti strukturu programa dovoljno precizno i ​​smisleno. U stvari, nije potrebno to učiniti: u konstruktivnom i arhitektonskom pristupu razvoju softvera, modularna struktura se formira u procesu programiranja modula.

konstruktivni pristup razvoj programa je modifikacija top-down razvoja, u kojoj se modularna struktura stabla programa formira tokom programiranja modula. Prvo, glavni modul se programira na osnovu specifikacije programa u cjelini, a specifikacija programa je istovremeno i specifikacija njegovog glavnog modula, budući da potonji preuzima punu odgovornost za izvršavanje programskih funkcija. U procesu programiranja glavnog modula, ako je ovaj program dovoljno velik, dodjeljuju se podzadaci (interne funkcije) u smislu kojih se programira glavni modul. To znači da se za svaki odabrani podzadatak (funkciju) kreira specifikacija programskog fragmenta koji ga implementira, a koji kasnije može biti predstavljen nekim podstablom modula. Važno je napomenuti da i ovdje glavni (možda jedini) modul ovog podstabla preuzima odgovornost za izvršavanje označene funkcije, pa je specifikacija istaknute funkcije ujedno i specifikacija glavnog modula ovog podstabla. U glavnom modulu programa, za pozivanje odabrane funkcije, poziva se glavni modul navedenog podstabla u skladu sa njegovom specifikacijom. Tako se u prvom koraku razvoja programa (pri programiranju njegovog glavnog modula) formira gornji početni dio stabla, na primjer, onaj prikazan na sl. 1.3.1.

Rice. 1.3.1. Prvi korak u formiranju modularne strukture programa sa konstruktivnim pristupom.

Slične radnje se izvode i kod programiranja bilo kojeg drugog modula, koji je izabran iz trenutnog stanja programskog stabla između navedenih, ali još ne programiranih modula. Kao rezultat toga, izvršava se sljedeći završetak programskog stabla, na primjer, onaj prikazan na sl. 1.3.2.

arhitektonski pristup razvoj programa je modifikacija razvoja odozdo prema gore, u kojoj se modularna struktura programa formira u procesu programiranja modula. Ali istovremeno se postavlja bitno drugačiji razvojni cilj: povećanje nivoa korišćenog programskog jezika, a ne razvoj određenog programa. To znači da se identifikuju tipične funkcije za dato predmetno područje, od kojih se svaka može koristiti za rješavanje različitih problema u ovoj oblasti, a posebni programski moduli koji obavljaju ove funkcije se specificiraju i potom programiraju. Budući da je proces isticanja ovakvih funkcija povezan sa akumulacijom i generalizacijom iskustva u rješavanju problema u datoj predmetnoj oblasti, obično se jednostavnije funkcije prvo izdvajaju i implementiraju posebnim modulima, a zatim se postepeno pojavljuju moduli koji koriste prethodno istaknute funkcije. Takav skup modula kreiran je u očekivanju da prilikom izrade određenog programa date predmetne oblasti, u okviru konstruktivnog pristupa, neki od ovih modula mogu biti prihvatljivi. To vam omogućava da značajno smanjite troškove rada za razvoj određenog programa tako što ćete na njega povezati unaprijed pripremljene i u praksi dokazane modularne strukture nižeg nivoa. Pošto se takve strukture mogu ponovo koristiti u različitim specifičnim programima, arhitektonski pristup se može posmatrati kao način za borbu protiv dupliranja u programiranju. U tom smislu, softverski moduli kreirani u okviru arhitektonskog pristupa se obično parametrizuju kako bi se poboljšala primenljivost takvih modula prilagođavajući ih parametrima.

Rice. 1.3.2. Drugi korak u formiranju modularne strukture programa sa konstruktivnim pristupom.

U klasičnoj metodi top-down razvoja preporučuje se prvo programirati sve module programa koji se razvija, a tek onda započeti njihovo top-down testiranje. Međutim, čini se da takav razvojni redoslijed nije dovoljno opravdan: testiranje i otklanjanje grešaka modula može dovesti do promjene u specifikaciji podređenih modula, pa čak i do promjene same modularne strukture programa, tako da u ovom slučaju programiranje neki moduli se mogu pokazati kao beskorisno obavljen posao. Čini nam se racionalnijim drugi redosled razvoja programa, poznat u literaturi kao metod implementacije odozgo prema dole. U ovoj metodi, svaki programirani modul se odmah testira prije nego što se pređe na programiranje drugog modula.

Sve ove metode takođe imaju različite varijante, u zavisnosti od redosleda kojim se prelaze čvorovi (moduli) strukture stabla programa u procesu njegovog razvoja. To se može učiniti, na primjer, u slojevima (razvijanjem svih modula jednog nivoa prije prelaska na sljedeći nivo). U razvoju odozgo prema dolje, drvo se također može preći leksikografskim redoslijedom (od vrha prema dolje, lijevo-desno). Postoje i druge opcije za prelazak stabla. Stoga je u konstruktivnoj implementaciji za obilazak programskog stabla preporučljivo slijediti Fuchsmanove ideje koje je on koristio u svom predloženom metodu vertikalnog foliranja. Suština takve zaobilaznice je sljedeća. U okviru konstruktivnog pristupa prvo se implementiraju samo oni moduli koji su neophodni za najjednostavniju verziju programa, koja se normalno može izvršiti samo za vrlo ograničen skup ulaznih skupova podataka, ali za takve podatke će ovaj zadatak biti riješen. do kraja. Umjesto ostalih modula koji su referencirani u takvom programu, u ovaj program se ubacuju samo njihovi imitatori, koji uglavnom pružaju kontrolu nad izlaskom iz ovog konkretnog slučaja. Zatim se ovom programu dodaju implementacije nekih drugih modula (posebno umjesto nekih od postojećih simulatora), čime se obezbjeđuje normalno izvršavanje za neke druge skupove ulaznih podataka. I ovaj proces se nastavlja u fazama do potpune implementacije potrebnog programa. Dakle, obilazak programskog stabla se vrši kako bi se na najkraći način implementirala jedna ili druga varijanta (prva najjednostavnija) normalno operativnog programa. U tom smislu, ova vrsta konstruktivne implementacije se naziva metodom svrsishodna konstruktivna implementacija. Prednost ove metode je što je već dovoljno rana faza kreira se radna verzija razvijenog programa. Psihološki, ovo igra ulogu dopinga, što dramatično povećava efikasnost programera. Stoga je ova metoda vrlo atraktivna.

Rice. 1.3.3. Klasifikacija metoda za razvoj strukture programa.

Sumirajući ono što je rečeno, na sl. 1.3.3. prikazana je opšta šema za klasifikaciju razmatranih metoda za razvoj strukture programa.

1.3.5. Kontrola strukture programa.

Za kontrolu strukture programa mogu se koristiti tri metode:

• statička kontrola,
• susjedna kontrola,
• kontrola od kraja do kraja.

Statička kontrola se sastoji u procjeni strukture programa s gledišta da li je program dobro podijeljen na module, uzimajući u obzir vrijednosti glavnih karakteristika modula o kojima smo gore govorili.

Kontinualna kontrola odozgo je kontrola od strane programera arhitekture i eksternog opisa PS-a. Kontinuirana kontrola odozdo je kontrola nad specifikacijom modula od strane programera tih modula.

End-to-end kontrola je mentalno pomicanje (provjera) strukture programa dok se izvršavaju unaprijed dizajnirani testovi. To je vrsta dinamičke kontrole na isti način kao i ručna imitacija funkcionalne specifikacije ili arhitekture PS-a.

Treba napomenuti da priroda implementacije ovih metoda upravljanja zavisi od izabranog metoda razvoja programske strukture: u klasičnom pristupu primenjuju se pre programiranja modula, a kod konstruktivnog i arhitektonskog pristupa, u procesu. programskih modula (u odgovarajuće vrijeme).