Definējiet un aprakstiet modulāro programmēšanu. Modulārā programmēšana - PIE.Wiki. Nodoto parametru skaita samazināšana līdz minimumam

Materiāls no PIE.Wiki

būtība modulārā programmēšana sastāv no sarežģītas problēmas sadalīšanas vairākos vienkāršākos apakšuzdevumos un programmu sastādīšanas to risināšanai diezgan neatkarīgi viena no otras. Modularitāte ir viens no programmatūras projektu veidošanas pamatprincipiem. Vispārīgā gadījumā modulis ir atsevišķa funkcionāli pabeigta, kaut kādā veidā identificēta un ar citiem apvienota programmas vienība, loģiski saistītas objektu kopas noteikšanas līdzeklis, to atlases un izolēšanas līdzeklis. Modulis ir līdzeklis ne tikai vadības struktūru, bet arī datu struktūru sadalīšanai. To lielā mērā veicināja jēdziena "datu tips" attīstība.

Modulis ir programmatūras projekta kompilācijas, uzglabāšanas, kā arī izstrādes un atsevišķas izstrādes vienība, ko veic izstrādātāju komanda. Tādējādi modulis tiek saprasts kā līdzeklis loģiski saistītas objektu kopas noteikšanai, to atlases un izolācijas līdzeklis.

Moduļu izveide un to objektu izmantošana programmās ir viens no trikiem ekonomiska programmēšana kas ir saistīts ar šādiem apstākļiem.

Pirmkārt, modulis parasti definē objektus, kas ir kādas "priekšmetu" jomas pamatjēdzienu nesēji, tādējādi modulis nosaka šīs priekšmeta jomas kontekstu. Tāpēc programmas, kas šajā jomā veiks dažādus apstrādes algoritmus, varēs izmantot jau gatavas un, kas ir svarīgi, vienādas pamata objektu definīcijas.

Otrkārt, tiek apkopoti gan moduļi, gan programmas, kas tos izmanto neskatoties uz(modulis ir jāapkopo pirms programmas, kas to izmanto). Sakarā ar to tiek ievērojami samazināts lielas programmas kompilācijas laiks, izmantojot gatavus moduļus, kas ir svarīgi, veicot programmu atkļūdošanu, kad tās ir jākompilē daudzas reizes.

Trešā svarīga moduļa īpašība ir tāda, ka tas slēpj, "iekapsulē" eksportējamo objektu attēlojumu un realizāciju, lai to iespējamās izmaiņas modulī (kad tas ir konfigurēts vai pielāgots jaunām aparatūras iespējām) neprasa nekādas izmaiņas. lietotāju programmām.

Visos moduļos to definētajiem objektiem (konstantes, mainīgie, tipi un apakšprogrammas) tiek izmantoti mnemoniski nosaukumi, kas atvieglo to mērķa un iegaumēšanas izpratni, atbilst prasībām. teksta redzamība programmas.

Programmēšanas valodas, kas atbalsta modulāru pieeju, apraksta moduli kā programmatūras vienību, kas sastāv no divām galvenajām daļām - specifikācijas (interfeisa) un ieviešanas. Specifikācija nodrošina tādus moduļu objektu raksturlielumus, kas ir nepieciešami un pietiekami šo objektu izmantošanai citos moduļos un programmās. Tas ļauj moduļa objektus izmantot, tikai pamatojoties uz informāciju par to saskarni (negaidot tos pilnīgs apraksts). Moduļa realizācijas daļā ir aprakstīti attēlošanas un apstrādes algoritmi, kas saistīti ar noteiktiem moduļa objektiem.

Modulis ir viens no rīkiem, kas atvieglo programmas verifikāciju. Modulis kā abstrakcijas veidošanas līdzeklis izceļ specifikāciju un lokalizē informāciju par ieviešanu.

Moduļi kalpo arī domēnam specifiska konteksta izveidei un mašīnu atkarību lokalizēšanai.

Modulārās programmēšanas jēdziens

Modulārās programmēšanas jēdzienu var formulēt vairāku jēdzienu un noteikumu veidā:

• Uzdevuma funkcionālā dekompozīcija ir liela uzdevuma sadalīšana vairākos mazākos, funkcionāli neatkarīgos apakšuzdevumos - moduļos. Moduļi ir savstarpēji savienoti tikai ar ieejas un izejas datiem.
• Modulis ir modulārās programmēšanas koncepcijas pamatā. Katrs modulis funkcionālajā sadalījumā ir "melnā kaste" ar vienu ieeju un vienu izeju. Modulārā pieeja ļauj nesāpīgi atjaunināt programmu tās darbības laikā un atvieglo tās apkopi. Turklāt modulārā pieeja ļauj izstrādāt viena projekta programmu daļas dažādās programmēšanas valodās un pēc tam izmantot montāžas rīkus, lai tās apvienotu vienā sāknēšanas modulī.
• Ieviestajiem risinājumiem jābūt vienkāršiem un skaidriem. Ja moduļa mērķis nav skaidrs, tas norāda, ka sākotnējā vai starpuzdevuma dekompozīcija nav veikta pietiekami labi. Šajā gadījumā uzdevums ir jāanalizē vēlreiz un, iespējams, jāveic papildu sadalīšana apakšuzdevumos. Ja projektā ir sarežģītas vietas, tās ir jādokumentē sīkāk, izmantojot pārdomātu komentāru sistēmu. Šis process jāturpina, līdz tiešām ir iespējams panākt skaidru izpratni par visu problēmas moduļu mērķi un to optimālo kombināciju.
• Visu moduļa mainīgo mērķis ir jāapraksta, izmantojot komentārus, kā tie ir definēti.

Literatūra

1. MM. Bezhanova, L.A. Moskvins. Praktiskā programmēšana. Paņēmieni programmu veidošanai Pascal. M.: Zinātniskā pasaule, 2000, 270 lpp.
2. Istomins E.P., Novikovs V.V., Novikova M.V. Augsta līmeņa informātikas un programmēšanas metodes: Mācību grāmata. - Sanktpēterburga. SIA "Adreevsky Publishing House", 2006 - 228 lpp.

1.3.1. Modulārās programmēšanas mērķis.

Modulārā programmēšana pamatojoties uz koncepciju modulis - loģiski savstarpēji savienots funkcionālo elementu kopums, kas veidots kā atsevišķi programmatūras moduļi.

Moduli raksturo:

1. viena ieeja un viena izeja - pie ieejas programmas modulis saņem noteiktu sākotnējo datu kopu, veic jēgpilnu apstrādi un atgriež vienu rezultātu datu kopu, t.i. tiek ieviests IPO (Input - Process - Output) standarta princips - iebraukšana-process-izeja;
2. funkcionālā pilnība - modulis veic regulēto darbību sarakstu katras atsevišķas funkcijas īstenošanai kopumā, kas ir pietiekams, lai pabeigtu uzsākto apstrādi;
3. loģiskā neatkarība - programmas moduļa darba rezultāts ir atkarīgs tikai no sākotnējiem datiem, bet nav atkarīgs no citu moduļu darba;
4. vājas informācijas saites ar citiem programmas moduļiem - pēc iespējas jāsamazina informācijas apmaiņa starp moduļiem;
5. programmas elements, kas ir paredzams pēc izmēra un sarežģītības.

Tādējādi moduļi satur apstrādei pieejamo datu definīciju, datu apstrādes operācijas, starpsavienojumu shēmas ar citiem moduļiem.

Katrs modulis sastāv no specifikācijas un korpusa. Specifikācijās ir noteikti moduļa lietošanas noteikumi, un pamattekstā ir noteikts, kā tiek īstenots apstrādes process.

Uzsākot katras FP programmas izstrādi, jāpatur prātā, ka tā parasti ir liela sistēma, tāpēc mums ir jāveic pasākumi tās vienkāršošanai. Lai to izdarītu, šāda programma tiek izstrādāta daļās, kuras sauc par programmas moduļiem. Un šo programmu izstrādes metodi sauc par modulāro programmēšanu. Programmatūras modulis- tas ir jebkurš procesa apraksta fragments, kas veidots kā neatkarīgs programmatūra, piemērots izmantošanai procesu aprakstos. Tas nozīmē, ka katrs programmas modulis tiek programmēts, kompilēts un atkļūdots atsevišķi no citiem programmas moduļiem, tādējādi fiziski atdalīts no citiem programmas moduļiem. Turklāt katru izstrādāto programmatūras moduli var iekļaut dažādās programmās, ja tiek ievēroti tā lietošanas nosacījumi, kas deklarēti šī moduļa dokumentācijā. Tādējādi programmatūras moduli var uzskatīt gan par līdzekli programmu sarežģītības apkarošanai, gan kā līdzekli programmēšanas dublēšanās apkarošanai (ti, kā programmētāju zināšanu uzkrāšanas un atkārtotas izmantošanas līdzekli).

Modulārā programmēšana ir iemiesojums abu programmu izstrādes procesā izplatītas metodes sarežģītības apkarošana un sistēmas komponentu neatkarības nodrošināšana, kā arī hierarhisku struktūru izmantošana. Lai realizētu pirmo metodi, tiek formulētas noteiktas prasības, kurām jāatbilst programmatūras modulim, t.i. tiek identificētas "labas" programmatūras moduļa galvenās īpašības. Otrās metodes realizēšanai tiek izmantotas kokam līdzīgas modulāras programmu struktūras (ieskaitot kokus ar sapludinātiem zariem).

1.3.2. Programmatūras moduļa galvenās īpašības.

Ne katrs programmas modulis veicina programmas vienkāršošanu. No šī viedokļa laba moduļa izvēle ir nopietns radošs uzdevums. Lai novērtētu izvēlētā moduļa pieņemamību, tiek izmantoti daži kritēriji. Tādējādi Holts ierosināja šādus divus vispārīgus šādus kritērijus:

• labs modulis ir vieglāk no ārpuses nekā no iekšpuses;
• labu moduli ir vieglāk lietot nekā izveidot.

Maierss iesaka izmantot vairāk programmatūras moduļa dizaina raksturlielumu, lai novērtētu tā pieņemamību: moduļa lielums; moduļa izturība; savienojums ar citiem moduļiem; moduļa rutīna (neatkarība no zvanu vēstures uz to).

Izmērs Modulis tiek mērīts pēc tajā ietverto paziņojumu (rindu) skaita. Modulis nedrīkst būt pārāk mazs vai pārāk liels. Mazie moduļi rada smagnēju moduļu programmu struktūru, un tie var nebūt vērti ar to dizainu saistītās pieskaitāmās izmaksas. Lieli moduļi ir neērti studijām un mainīšanai, tie var ievērojami palielināt kopējo programmu atkārtoto tulkojumu laiku, veicot programmas atkļūdošanu. Parasti ir ieteicami programmu moduļi, kuru lielums ir no dažiem desmitiem līdz dažiem simtiem operatoru.

Spēks modulis ir tā iekšējo savienojumu mērs. Jo augstāks ir moduļa stiprums, jo vairāk savienojumu tas var paslēpt no programmas ārējās daļas attiecībā pret to un līdz ar to, jo lielāku ieguldījumu tas var dot programmas vienkāršošanā. Lai novērtētu moduļa stiprības pakāpi, Maierss piedāvā septiņu moduļu klašu komplektu, kas sakārtots pēc stiprības pakāpes. Modulim ir vājākā stiprības pakāpe, izturīgs nejaušības dēļ. Šis ir tāds modulis, kura elementiem nav jēgpilnu savienojumu. Šādu moduli var izcelt, piemēram, kad dažādās programmas vietās tiek atrasts vienas un tās pašas izteikumu secības atkārtojums, kas tiek veidots atsevišķā modulī. Nepieciešamība mainīt šo secību kādā no kontekstiem var izraisīt izmaiņas šajā modulī, kas var padarīt tā lietošanu citos kontekstos kļūdainu. Šīs klases programmatūras moduļi nav ieteicami lietošanai. Vispārīgi runājot, Maiersa piedāvātā moduļu klašu sakārtošana pēc stiprības pakāpes nav neapstrīdama. Tomēr tas nav īpaši svarīgi, jo lietošanai ir ieteicamas tikai divas augstākās stiprības klases moduļiem. Mēs apsvērsim šīs nodarbības sīkāk.

Funkcionāli izturīgs Modulis ir modulis, kas veic (īsteno) vienu noteiktu funkciju. Ieviešot šo funkciju, šāds modulis var izmantot citus moduļus. Šīs klases programmatūras moduļi ir ieteicami lietošanai.

Informatīvi izturīgs modulis ir modulis, kas veic (realizē) vairākas operācijas (funkcijas) vienā datu struktūrā (informācijas objektā), kas ārpus šī moduļa tiek uzskatīts par nezināmu. Katrai no šīm darbībām šādam modulim ir sava ievade ar savu piekļuves veidu. Šāda klase jāuzskata par programmu moduļu klasi ar visaugstāko stiprības pakāpi. Informācijas stipruma modulis var ieviest, piemēram, abstraktu datu tipu.

AT modulārās valodas programmēšana, vismaz ir līdzekļi funkcionāli stabilu moduļu definēšanai (piemēram, FUNCTION tipa modulis FORTRAN valodā). Līdzekļi informatīvi spēcīgu moduļu noteikšanai agrīnās programmēšanas valodās trūka - tie parādījās tikai vēlākās valodās. Tātad programmēšanas valodā Ada informatīvi izturīga moduļa norādīšanas līdzeklis ir pakete.

Sajūgs Modulis ir tā datu atkarības no citiem moduļiem mērs. To raksturo datu pārraides metode. Jo vājāka ir moduļa savienošana ar citiem moduļiem, jo ​​spēcīgāka ir tā neatkarība no citiem moduļiem. Lai novērtētu kohēzijas pakāpi, Maierss piedāvā sakārtotu sešu veidu moduļu kohēzijas kopumu. Sliktākais moduļu savienojuma veids ir satura saikne. Šī ir divu moduļu savienošana, ja vienam no tiem ir tiešas atsauces uz otra moduļa saturu (piemēram, uz konstanti, kas atrodas otrā modulī). Šāda moduļu savienošana ir nepieņemama. Tāpat nav ieteicams lietot vispārējā zonas saķere- šī ir tāda moduļu salikšana, kad vairāki moduļi izmanto vienu un to pašu atmiņas apgabalu. Šāda veida moduļu saistīšana tiek realizēta, piemēram, programmējot FORTRAN valodā, izmantojot COMMON blokus. Vienīgais moduļu ķēdes veids, ko ieteicams izmantot mūsdienu programmēšanas tehnoloģijās, ir parametriskā ķēde (Myers datu ķēde) — tas notiek, ja dati tiek pārsūtīti uz moduli vai nu tad, kad tiem tiek piekļūts kā tā parametru vērtība, vai kā tās piekļuves citam modulim rezultāts kādas funkcijas aprēķināšanai. Šis moduļu ķēdes veids tiek ieviests programmēšanas valodās, izmantojot procedūru (funkciju) izsaukumus.

Moduļa rutīna ir tā neatkarība no izsaukumu vēstures uz to. Modulis tiks izsaukts rutīna, ja tā izsaukšanas rezultāts (efekts) ir atkarīgs tikai no tā parametru vērtībām (un nav atkarīgs no zvanu vēstures uz to). Modulis tiks izsaukts atkarīgs no fona, ja tā izsaukšanas rezultāts (efekts) ir atkarīgs no šī moduļa iekšējā stāvokļa, kas saglabā iepriekšējo izsaukumu pēdas uz to. Maierss neiesaka izmantot no vēstures atkarīgus (neprognozējamus) moduļus, jo tie programmās ievieš sarežģītas (nenotveramas) kļūdas. Tomēr šāds ieteikums nav konstruktīvs, jo daudzos gadījumos tieši no vēstures atkarīgais modulis ir labākā informācijas stiprā moduļa ieviešana. Tāpēc pieņemamāks ir šāds (piesardzīgāks) ieteikums:

• rutīnas modulis ir jāizmanto vienmēr, ja vien tas neizraisa sliktu (nav ieteicamu) moduļa savienojumu;
• no vēstures atkarīgie moduļi ir jāizmanto tikai tad, ja nepieciešams, lai nodrošinātu parametru ķēdi;
• no vēstures atkarīgā moduļa specifikācijā šī atkarība ir skaidri jāformulē tā, lai būtu iespējams paredzēt šī moduļa uzvedību (izpildes efektu) ar dažādiem turpmākiem tā izsaukumiem.

Saistībā ar pēdējo ieteikumu var būt lietderīgi definēt ārēju (uz cilvēku informēšanu orientētu) no vēstures atkarīgā moduļa stāvokļu attēlojumu. Šajā gadījumā katras šī moduļa realizētās funkcijas (operācijas) izpildes efekts ir jāapraksta ar šo ārējo attēlojumu, kas ievērojami vienkāršos šī moduļa darbības prognozēšanu.

1.3.3. Programmatūras produktu modulāra struktūra

Programmatūras produktu modulārās programmēšanas principi daudzējādā ziņā ir līdzīgi projektēšanas no augšas uz leju principiem. Pirmkārt, tiek noteikts funkciju sastāvs un pakļautība, bet pēc tam - programmatūras moduļu komplekts, kas realizē šīs funkcijas.

Viena veida funkcijas tiek realizētas ar tiem pašiem moduļiem. Tiek nodrošināta augstākā līmeņa funkcija galvenais modulis; tā kontrolē zemāko funkciju izpildi, kas atbilst padotajiem moduļi.

Nosakot moduļu kopu, kas īsteno noteikta algoritma funkcijas, jāņem vērā:

1. katru moduli izsauc izpildei augstāka līmeņa modulis un pēc darba pabeigšanas atgriež vadību modulim, kas to izsauca;
2. galveno lēmumu pieņemšana algoritmā tiek pacelta augstākajā iespējamajā hierarhijas līmenī;
3. lai izmantotu vienu un to pašu funkciju dažādās algoritma vietās, tiek izveidots viens modulis, kuru pēc vajadzības izsauc izpildei. Algoritma tālākas pilnveidošanas rezultātā a funkcionāls un modulārs lietojumprogrammas algoritma shēmu (FMS), kas ir programmēšanas pamatā.

Programmas moduļu sastāvu un veidu, to mērķi un lietošanas veidu programmā lielā mērā nosaka rīki. Piemēram, attiecībā uz DBVS rīkiem atsevišķi moduļi var būt:

1. ekrāna veidlapas datu bāzu informācijas ievadīšanai un/vai rediģēšanai;
2. Atskaišu ģeneratoru atskaites;
3. makro;
4. standarta informācijas apstrādes procedūras;
5. izvēlne, kas ļauj izvēlēties apstrādes funkciju utt.

1.3.4. Programmas struktūras izstrādes metodes.

Kā minēts iepriekš, kā programmas modulāro struktūru ir ierasts izmantot koka struktūru, ieskaitot kokus ar sapludinātiem zariem. Šāda koka mezglos ir programmas moduļi, un virzītās lokas (bultiņas) parāda moduļu statisko pakļautību, t.i. katrs loks parāda, ka tā moduļa tekstā, no kura tas ir cēlies, ir saite uz moduli, kurā tas ietilpst. Citiem vārdiem sakot, katrs modulis var piekļūt saviem pakārtotajiem moduļiem, t.i. izteikti šo moduļu izteiksmē. Tajā pašā laikā programmas modulārajā struktūrā galu galā jāietver arī specifikāciju kopums moduļiem, kas veido šo programmu. Specifikācija programmas modulis satur, pirmkārt, tā ievades sintaktisko specifikāciju, kas ļauj izveidot sintaktiski pareizu pievilcību tam (jebkurai tā ievadei) izmantotajā programmēšanas valodā, un, otrkārt, moduļa funkcionālo specifikāciju ( šī moduļa veikto funkciju semantikas apraksts katram no tā ievadiem). Moduļa funkcionālā specifikācija ir veidota tāpat kā PS funkcionālā specifikācija.

Programmas izstrādes gaitā tās modulāro struktūru var veidot dažādos veidos un izmantot, lai noteiktu šajā struktūrā norādīto moduļu programmēšanas un atkļūdošanas secību. Tāpēc mēs varam runāt par dažādām programmas struktūras izstrādes metodēm. Literatūrā parasti tiek aplūkotas divas metodes: augšupējas attīstības metode un augšupējās attīstības metode.

Metode augšupēja attīstība ir šāds. Pirmkārt, programmas modulārā struktūra ir veidota koka formā. Pēc tam programmas moduļi tiek programmēti pa vienam, sākot no zemākā līmeņa moduļiem (programmas moduļu struktūras koka lapām), tādā secībā, lai katram programmējamam modulim visi moduļi, kuriem tas var piekļūt ir ieprogrammēts. Pēc tam, kad visi programmas moduļi ir ieprogrammēti, tie pēc kārtas tiek pārbaudīti un atkļūdoti principā tādā pašā (augošā) secībā, kādā tie tika ieprogrammēti. No pirmā acu uzmetiena šāda programmu izstrādes secība šķiet gluži dabiska: programmējot katrs modulis tiek izteikts caur tieši ieprogrammētiem pakārtotajiem moduļiem, bet testējot izmanto jau atkļūdotus moduļus. tomēr modernās tehnoloģijas neiesaka šādu programmas izstrādes kārtību. Pirmkārt, jebkura moduļa programmēšanai tā izmantoto moduļu teksti vispār nav nepieciešami - šim nolūkam pietiek ar to, ka katrs izmantotais modulis ir tikai norādīts (tiktāl, ciktāl tas ļauj veidot pareizu pievilcību tam), un tā pārbaudei ir iespējams (un pat, kā mēs parādīsim tālāk, tas ir noderīgi) izmantotos moduļus tos aizstāt ar simulatoriem (stubs). Otrkārt, katra programma zināmā mērā ir pakļauta kaut kādiem tās iekšējiem apsvērumiem, bet globāliem saviem moduļiem (īstenošanas principiem, pieņēmumiem, datu struktūrām utt.), kas nosaka tās konceptuālo integritāti un veidojas tās izstrādes procesā. Augšupējas izstrādes laikā šī globālā informācija zemāka līmeņa moduļiem vēl nav pilnībā skaidra, tāpēc ļoti bieži ir nepieciešams tos pārprogrammēt, kad, programmējot citus moduļus, šī globālā informācija tiek būtiski precizēta (piemēram, globālā datu struktūra izmaiņas). Treškārt, testēšanas laikā no apakšas uz augšu katram modulim (izņemot galveno) ir jāizveido vadošā programma (modulis), kurai jāsagatavo testējamajam modulim nepieciešamais informācijas vides stāvoklis un jāveic nepieciešamais zvaniet uz to. Tas noved pie lielas "atkļūdošanas" programmēšanas un tajā pašā laikā nedod nekādu garantiju, ka moduļi tika pārbaudīti tieši tādos apstākļos, kādos tie tiks izpildīti darba programmā.

Metode attīstība no augšas uz leju ir šāds. Tāpat kā iepriekšējā metodē, programmas modulārā struktūra vispirms tiek veidota koka formā. Pēc tam programmas moduļi tiek programmēti pa vienam, sākot no augstākā līmeņa (galvas) moduļa, pārejot uz kāda cita moduļa programmēšanu tikai tad, ja modulis, kas tam piekļūst, jau ir ieprogrammēts. Kad visi programmas moduļi ir ieprogrammēti, tie tiek pārbaudīti un atkļūdoti pa vienam tādā pašā (dilstošā) secībā. Ar šādu programmu izstrādes kārtību visa nepieciešamā globālā informācija tiek ģenerēta savlaicīgi, t.i. ļoti nepatīkams kļūdainu aprēķinu avots, kad tiek novērsti programmēšanas moduļi. Ievērojami tiek atvieglota arī moduļu testēšana, kas tiek veikta programmas testēšanas no augšas uz leju laikā. Vispirms tiek testēts programmas galvas modulis, kas reprezentē visu testējamo programmu un tāpēc tiek testēts informācijas vides "dabiskajā" stāvoklī, kurā šī programma sāk darboties. Šajā gadījumā visi moduļi, kuriem var piekļūt ar galvu, tiek aizstāti ar to atdarinātājiem (tā sauktajiem stubiem). Katrs moduļa simulatorsšķiet ļoti vienkāršs programmas fragments, kas signalizē būtībā par piekļuvi simulētajam modulim ar tā ievades parametru vērtību apstrādi, kas nepieciešamas pareizai programmas darbībai (dažreiz ar to izdruku) un ar ja nepieciešams, iepriekš saglabāta piemērota rezultāta izdošana. Pēc galvas un jebkura nākamā moduļa testēšanas un atkļūdošanas pabeigšanas tiek veikta pāreja uz viena no moduļiem, kurus pašlaik attēlo simulatori, ja tādi ir, testēšanu. Lai to izdarītu, testēšanai izvēlētā moduļa simulators tiek aizstāts ar pašu moduli un tiek pievienoti to moduļu simulatori, kuriem var piekļūt testēšanai izvēlētais modulis. Turklāt katrs šāds modulis tiks pārbaudīts informācijas vides "dabiskajos" stāvokļos, kas rodas brīdī, kad šim modulim tiek piekļūts testējamās programmas izpildes laikā. Tādējādi liela daļa "atkļūdošanas" programmēšanas tiek aizstāta ar diezgan vienkāršu programmā izmantoto moduļu simulatoru programmēšanu. Turklāt simulatori ir noderīgi, lai spēlētu kopā ar testa atlases procesu, norādot vēlamos simulatoru radītos rezultātus.

Daži lejupējās attīstības trūkumi, kas rada zināmas grūtības tās piemērošanā, ir nepieciešamība abstrahēties pamata iespējas izmantotā programmēšanas valoda, izdomājot abstraktas darbības, kuras vēlāk būs jārealizē, izmantojot programmā izceltos moduļus. Tomēr šķiet, ka šādu abstrakciju spēja ir nepieciešams nosacījums lielu programmatūras rīku izstrādei, tāpēc tā ir jāattīsta.

Aplūkotajās augšupējās un lejupējās attīstības metodēs (kuras mēs sauksim klasika) pirms moduļu programmēšanas jāizstrādā programmas moduļu koka struktūra. Taču šāda pieeja rada virkni iebildumu: šķiet apšaubāmi, vai pirms moduļu programmēšanas būtu iespējams pietiekami precīzi un jēgpilni izstrādāt programmas struktūru. Faktiski tas nav jādara: programmatūras izstrādes konstruktīvajā un arhitektoniskajā pieejā moduļu programmēšanas procesā tiek veidota modulāra struktūra.

konstruktīva pieeja to programmu izstrāde ir lejupējas izstrādes modifikācija, kurā programmas modulārā koka struktūra tiek veidota moduļa programmēšanas laikā. Pirmkārt, galvas modulis tiek ieprogrammēts, pamatojoties uz visas programmas specifikāciju, un programmas specifikācija vienlaikus ir arī tās galvas moduļa specifikācija, jo pēdējais uzņemas pilnu atbildību par programmas funkciju izpildi. Galvas moduļa programmēšanas procesā, ja šī programma ir pietiekami liela, tiek izdalīti apakšuzdevumi (iekšējās funkcijas), kuru izteiksmē tiek programmēts galvas modulis. Tas nozīmē, ka katram izvēlētajam apakšuzdevumam (funkcijai) tiek izveidota to realizējošā programmas fragmenta specifikācija, kuru vēlāk var attēlot ar kādu moduļu apakškoku. Svarīgi atzīmēt, ka arī šeit šī apakškoka galvas (varbūt vienīgais) modulis uzņemas atbildību par iezīmētās funkcijas izpildi, tāpēc iezīmētās funkcijas specifikācija ir arī šī apakškoka galvas moduļa specifikācija. Programmas galvas modulī, lai izsauktu izvēlēto funkciju, tiek veikts izsaukums uz norādītā apakškoka galvas moduli atbilstoši tā specifikācijai. Tādējādi programmas izstrādes pirmajā solī (programmējot tā galvas moduli) tiek izveidota koka augšējā sākuma daļa, piemēram, tā, kas parādīta attēlā. 1.3.1.

Rīsi. 1.3.1. Pirmais solis programmas modulāras struktūras veidošanā ar konstruktīvu pieeju.

Līdzīgas darbības tiek veiktas, programmējot jebkuru citu moduli, kas tiek izvēlēts no programmas koka pašreizējā stāvokļa no norādītajiem, bet vēl neieprogrammētajiem moduļiem. Tā rezultātā tiek veikta nākamā programmas koka pabeigšana, piemēram, tā, kas parādīta attēlā. 1.3.2.

arhitektoniskā pieeja to programmas izstrāde ir augšupējas attīstības modifikācija, kurā programmas modulārā struktūra tiek veidota moduļa programmēšanas procesā. Bet tajā pašā laikā tiek izvirzīts ievērojami atšķirīgs attīstības mērķis: palielināt izmantotās programmēšanas valodas līmeni, nevis izstrādāt konkrētu programmu. Tas nozīmē, ka noteiktai priekšmeta jomai tiek identificētas tipiskās funkcijas, no kurām katra var tikt izmantota dažādu šīs jomas problēmu risināšanai, un tiek norādīti un pēc tam ieprogrammēti atsevišķi programmu moduļi, kas veic šīs funkcijas. Tā kā šādu funkciju izcelšanas process ir saistīts ar pieredzes uzkrāšanu un vispārināšanu problēmu risināšanā noteiktā mācību jomā, parasti vienkāršākas funkcijas vispirms tiek izdalītas un ieviestas ar atsevišķiem moduļiem, un pēc tam pakāpeniski parādās moduļi, kas izmanto iepriekš izdalītās funkcijas. Šāds moduļu komplekts tiek veidots, cerot, ka, izstrādājot konkrētas mācību priekšmetu jomas konkrētu programmu, konstruktīvas pieejas ietvaros, daži no šiem moduļiem var būt pieņemami. Tas ļauj būtiski samazināt darbaspēka izmaksas konkrētas programmas izstrādei, pieslēdzot tai iepriekš sagatavotas un praksē pārbaudītas zemāka līmeņa moduļu konstrukcijas. Tā kā šādas struktūras var atkārtoti izmantot dažādās īpašās programmās, arhitektūras pieeju var uzskatīt par veidu, kā cīnīties pret dublēšanos programmēšanā. Šajā sakarā programmatūras moduļi, kas izveidoti arhitektūras pieejā, parasti tiek parametrizēti, lai uzlabotu šādu moduļu pielietojamību, pielāgojot tos parametriem.

Rīsi. 1.3.2. Otrais solis programmas modulārās struktūras veidošanā ar konstruktīvu pieeju.

Klasiskajā lejupējās izstrādes metodē ieteicams vispirms ieprogrammēt visus izstrādājamās programmas moduļus un tikai pēc tam sākt to testēšanu no augšas uz leju. Tomēr šāds izstrādes pasūtījums nešķiet pietiekami pamatots: moduļu testēšana un atkļūdošana var izraisīt pakārtoto moduļu specifikācijas izmaiņas un pat izmaiņas programmas ļoti modulārajā struktūrā, tā ka šajā gadījumā daži moduļi var izrādīties bezjēdzīgi paveikts darbs. Mums šķiet racionālāka cita programmu izstrādes kārtība, kas literatūrā pazīstama kā lejupējas ieviešanas metode. Izmantojot šo metodi, katrs ieprogrammētais modulis tiek nekavējoties pārbaudīts, pirms pāriet uz cita moduļa programmēšanu.

Arī visām šīm metodēm ir dažādas variācijas atkarībā no secības, kādā programmas izstrādes procesā tiek šķērsoti programmas koka struktūras mezgli (moduļi). To var izdarīt, piemēram, slāņos (izstrādājot visus viena līmeņa moduļus pirms pārejas uz nākamo līmeni). Izstrādē no augšas uz leju koku var šķērsot arī leksikogrāfiskā secībā (no augšas uz leju, pa kreisi-pa labi). Ir arī citas iespējas, kā šķērsot koku. Tādējādi konstruktīvā īstenošanā programmas koka šķērsošanai ir ieteicams ievērot Fuksmana idejas, kuras viņš izmantoja savā piedāvātajā vertikālās foliācijas metodē. Šāda apvedceļa būtība ir šāda. Konstruktīvās pieejas ietvaros vispirms tiek realizēti tikai tie moduļi, kas nepieciešami programmas vienkāršākajai versijai, kuru normāli var izpildīt tikai ļoti ierobežotam ievaddatu kopu kopumam, bet šādiem datiem šis uzdevums tiks atrisināts. līdz beigām. Citu moduļu vietā, uz kuriem ir atsauce šādā programmā, šajā programmā tiek ievietoti tikai to atdarinātāji, kas galvenokārt nodrošina kontroli pār pāri šim konkrētajam gadījumam. Pēc tam šai programmai tiek pievienotas dažu citu moduļu implementācijas (jo īpaši dažu esošo simulatoru vietā), nodrošinot normālu izpildi dažām citām ievaddatu kopām. Un šis process turpinās pa posmiem līdz vajadzīgās programmas pilnīgai ieviešanai. Tādējādi tiek veikta programmu koka caurbraukšana, lai pēc iespējas īsākā veidā realizētu vienu vai otru normāli strādājošas programmas variantu (pirmo visvienkāršāko). Šajā sakarā šāda veida konstruktīvu ieviešanu sauc par metodi mērķtiecīga konstruktīva īstenošana. Šīs metodes priekšrocība ir tā, ka ar to jau ir pietiekami agrīnā stadijā tiek izveidota izstrādātās programmas darba versija. Psiholoģiski tas spēlē dopinga lomu, kas ievērojami palielina izstrādātāja efektivitāti. Tāpēc šī metode ir ļoti pievilcīga.

Rīsi. 1.3.3. Programmu struktūras izstrādes metožu klasifikācija.

Apkopojot teikto, attēlā. 1.3.3. ir sniegta vispārīga shēma aplūkoto metožu klasifikācijai programmas struktūras izstrādei.

1.3.5. Programmas struktūras kontrole.

Lai kontrolētu programmas struktūru, var izmantot trīs metodes:

• statiskā vadība,
• blakus esošā vadība,
• pilnīga kontrole.

Statiskā kontrole sastāv no programmas struktūras novērtēšanas no viedokļa, vai programma ir labi sadalīta moduļos, ņemot vērā iepriekš apskatītās moduļa galveno raksturlielumu vērtības.

Blakus esošā vadība no augšas ir PS arhitektūras un ārējā apraksta izstrādātāju kontrole. Blakus esošā vadība no apakšas ir moduļu specifikāciju kontrole, ko veic šo moduļu izstrādātāji.

Pilnīga kontrole ir programmas struktūras garīga ritināšana (pārbaude), izpildot iepriekš izstrādātus testus. Tas ir dinamiskas vadības veids, tāpat kā manuāla PS funkcionālās specifikācijas vai arhitektūras imitācija.

Jāatzīmē, ka šo kontroles metožu ieviešanas raksturs ir atkarīgs no izvēlētās programmas struktūras izstrādes metodes: klasiskajā pieejā tās tiek pielietotas pirms moduļu programmēšanas, bet konstruktīvajā un arhitektoniskajā pieejā – procesā. programmēšanas moduļus (atbilstošā laikā).