Metode de proiectare software - stadopedia

Cele mai frecvente și aplicabile sunt: ​​metoda de dezvoltare de jos în sus și metoda de dezvoltare de sus în jos a PS.

Metoda dezvoltării de jos în sus este după cum urmează. În primul rând, structura modulară a programului este construită sub forma unui copac. Apoi programate alternativ modulele programului, începând cu modulele de nivelul cel mai scăzut (frunzele structurii arborelui unui program modular) într-o asemenea manieră încât pentru fiecare modul programabil, toate modulele au fost deja programate, la care se poate referi. După ce toate modulele de program sunt programate, acestea sunt testate la rândul lor și depanatate în principiu în aceeași ordine (ascendentă) în care au fost programate. Această ordine de dezvoltare a programului pare la prima vedere destul de naturală: fiecare modul este exprimat în programare prin intermediul unor module deja subordonate deja programate și când testarea utilizează module deja depanatate. Cu toate acestea, tehnologia modernă nu recomandă o astfel de ordine de dezvoltare a programului. În primul rând, pentru programarea unui modul nu necesită prezența unor module de text utilizate de către acesta - este suficient ca fiecare modul utilizat a fost specificat numai (în volum, ceea ce permite să construiască o referință corespunzătoare să-l), și pentru a testa este posibil (chiar și , după cum vom arăta mai jos, este util) să înlocuiți modulele folosite cu simulatoare (stuburi, drivere). În al doilea rând, fiecare program într-o anumită măsură, este supusă anumitor interne, dar modulele pentru considerente globale (principiile de punere în aplicare, ipoteze, structuri de date, și altele asemenea), care definește integritatea conceptuală și a format în cursul dezvoltării sale. La elaborarea acestor informații pe legătură în sus la nivel mondial pentru modulele de la nivelurile inferioare nu este încă pe deplin clar, astfel încât adesea este necesar să le reprograma în cazul în care rafinarea semnificativă a informațiilor globale (de exemplu, o structură de date la nivel mondial este schimbat) se realizează când programarea altor module. În al treilea rând, într-o încercare pentru fiecare modul (cu excepția creierului) trebuie să creeze un program de gazdă (modul), care este de a pregăti pentru mediul de informare de stat necesare modul de testare și de a efectua tratamentul adecvat pentru ea. Acest lucru are ca rezultat un volum mare de program de „depanare“ și, în același timp, nu oferă nicio garanție că unitate de testare se efectuează în condițiile în care acestea vor fi efectuate în programul de lucru.







Metoda dezvoltării de sus în jos este după cum urmează. Ca și în metoda precedentă, structura modulară a programului sub forma unui arbore este construită pentru prima dată. Apoi modulele de program sunt programate alternativ, începând cu modulul cel mai înalt (cap), continuând cu programarea unui alt modul numai dacă modulul care a adresat-o este deja programat. După ce toate modulele de program au fost programate, acestea sunt testate la rândul lor și depanate în aceeași ordine (în ordine descrescătoare). În acest caz, primul modul principal de program este testat, care reprezintă tot programul de testare și, prin urmare, testat cu un mediu informațional „natural“ al unui stat în cazul în care programul începe să ruleze. În același timp, modulele la care se poate adresa unitatea principală sunt înlocuite cu simulatoarele lor (așa-numitele prize). Fiecare modul simulator este un fragment foarte simplu program, care indică în mod esențial faptul de a se referi la modulul simulat produce necesare pentru funcționarea corectă a prelucrării programului a valorilor parametrilor săi de intrare (uneori cu imprimarea lor) și ieșirile, dacă este necesar, pre-aprovizionat adecvat rezultat. După ce testarea și depanarea capului și modulele ulterioare sunt finalizate, se efectuează o tranziție la testarea unuia dintre modulele reprezentate în prezent de simulatoare, dacă există. Pentru a face acest lucru, simulatorul selectat pentru testarea modulului se înlocuiește modulul și, în plus, a adăugat imitatori ai acestor module, care pot fi accesate pentru modulul de testare selectat. În același timp, fiecare astfel de modul va fi testat cu stările "naturale" ale mediului de informare care apar atunci când modulul este accesat în timpul executării programului în curs de testare. Astfel, o mare cantitate de programare "debugging" cu testare în amonte se înlocuiește cu programarea unor simulatoare destul de simple ale modulelor utilizate în program. În plus, simulatoarele sunt convenabile de utilizat pentru a juca împreună cu procesul de selectare a testelor prin stabilirea rezultatelor dorite produse de simulatoare. Cu această ordine de dezvoltare a programului, toate informațiile globale necesare se formează în timp util, adică o sursă foarte neplăcută de calcul greșit este eliminată la programarea modulelor. Unele lipsa de dezvoltare de sus în jos, ceea ce conduce la anumite dificultăți în aplicarea sa, este necesitatea de a ignora capacitățile de bază ale limbajului de programare, inventând operații abstracte, care mai târziu trebuie să fie puse în aplicare cu ajutorul modulelor de program dedicate. Cu toate acestea, capacitatea de a obține astfel de abstractizări pare să fie o condiție necesară pentru dezvoltarea unor instrumente software de mari dimensiuni, deci trebuie dezvoltată.







luând în considerare în special metodele de ascendentă și descendentă dezvoltare (pe care o numim clasic) este cerința ca structura modulară a programului a fost elaborat înainte de începerea programării (codare) module. Această cerință este în deplină conformitate cu abordarea cascada la dezvoltarea SS, deoarece dezvoltarea structurii modulare a programului și codificarea acesteia se realizează în diferite stadii de dezvoltare a SS: Primul pas este finalizarea construirii SS, iar al doilea - se deschide etapa de codificare. Cu toate acestea, aceste metode ridică o serie de obiecții: pare a fi îndoielnic că înainte de programarea modulelor ar fi posibilă dezvoltarea structurii programului cu destulă precizie și în mod semnificativ. De fapt, nu este necesar să faceți acest lucru, dacă mai multe modernizați abordarea cascadei. Mai jos, propunem abordări constructive și arhitecturale pentru dezvoltarea programelor în care se formează o structură modulară în procesul de module de programare (codare).

O abordare constructivă a dezvoltării programului este o modificare a dezvoltării de sus în jos, în care se formează structura modulară a arborilor în timpul programării modulelor. Dezvoltarea unui program cu o abordare constructivă începe cu programarea modulului cap, pe baza specificației programului în ansamblu. În acest caz, specificația programului este adoptată ca o specificare a modulului său cap, care își asumă întreaga responsabilitate pentru performanța funcțiilor programului. În procesul de programare a unității de cap, în cazul în care acest program este suficient de mare, sunt selectate sub-tastele (funcții interne), în funcție de care modulul de cap este programat. Aceasta înseamnă că pentru fiecare subtasc (funcție) care este alocat, se creează o specificație pentru fragmentul de program care îl implementează, care în viitor poate fi reprezentat de unele subdrije de module. Este important de remarcat faptul că există, de asemenea, responsabil pentru executarea funcției selectate are un cap (poate singura) a unității subtree, astfel încât specificația funcției selectate este atât o specificație a modulului de cap care subramificație. În modulul principal al programului, un apel către modulul de capăt al sub-paragrafului specificat este construit pentru a accesa funcția alocată în conformitate cu specificațiile create. Astfel, în prima etapă a dezvoltării programului (atunci când se programează modulul său de cap), se formează partea inițială superioară a arborelui, de exemplu, cea prezentată în figura 1.5.

Figura 1.5 - Primul pas în formarea unei structuri modulare de program cu o abordare constructivă

Acțiuni similare se efectuează atunci când se programează orice alt modul care este selectat din starea curentă a arborelui programului dintre modulele specificate dar care nu au fost încă programate. Ca rezultat, arborele programului este deformat, de exemplu, cel prezentat în Figura 1.6.

Abordarea arhitecturală a dezvoltării programelor este o modificare a dezvoltării ascendente, în care se formează structura modulară a programului în timpul programării modulului. Dar, în același timp, se pune un obiectiv de dezvoltare semnificativ diferit: creșterea nivelului limbajului de programare utilizat, mai degrabă decât dezvoltarea unui program specific. Aceasta înseamnă că pentru un anumit domeniu se disting funcțiile tipice, fiecare dintre acestea putând fi utilizate pentru rezolvarea diferitelor sarcini în acest domeniu, iar modulele individuale de programe care execută aceste funcții sunt specificate și apoi programate. Deoarece procesul de alocare a acestor funcții este asociat cu acumularea și generalizarea experienței de rezolvare a problemelor într-un anumit domeniu, funcțiile de obicei mai simple sunt mai întâi alocate și implementate de module individuale, iar apoi modulele care utilizează funcțiile deja alocate devin treptat. Un astfel de set de module este creat în așteptarea faptului că în dezvoltarea unui anumit program al unui anumit domeniu în cadrul unei abordări constructive, unele dintre aceste module pot fi acceptabile. Acest lucru vă permite să reduceți în mod semnificativ costurile forței de muncă pentru dezvoltarea unui anumit program prin conectarea la acesta pre-pregătit și testat în practică structuri modulare de nivel inferior. Deoarece astfel de structuri pot fi refolosite în diferite programe specifice, abordarea arhitecturală poate fi considerată o modalitate de combatere a duplicării în programare. În acest sens, modulele de program create în cadrul abordării arhitecturale sunt de obicei parametrizate pentru a consolida aplicabilitatea acestor module prin ajustarea acestora la parametri.

Figura 1.6 - A doua etapă în formarea unei structuri modulare a programului într-o abordare constructivă.

Se recomandă metoda clasică de sus în jos de dezvoltare pentru mai întâi toate modulele dezvoltate program software, și numai apoi de a începe testarea lor în jos, care din nou este în deplină conformitate cu abordarea cascada. Cu toate acestea, această ordine de dezvoltare nu este suficient de justificată: module de testare și depanare pot modifica specificațiile modulelor slave, și chiar și o schimbare în structura foarte modulară a programului, astfel încât, în acest caz, programarea unora dintre module pot fi de lucru inutil făcut. Pare rațional să avem o altă procedură de elaborare a unui program, cunoscut în literatură ca metodă de implementare de sus în jos. ceea ce reprezintă o anumită modificare a abordării cascadei.

În această metodă, fiecare modul programat este testat imediat înainte de a trece la programarea unui alt modul.

Toate aceste metode au diferite variante, în funcție de secvența în care nodurile (modulele) structurii de arbore a programului sunt ocolite în procesul de dezvoltare a acestuia. Acest lucru se poate face, de exemplu, în straturi (dezvoltarea tuturor modulelor de același nivel înainte de a trece la nivelul următor). Cu o dezvoltare de sus în jos, copacul poate fi traversat și în ordine lexicografică (de sus în jos, de la stânga la dreapta). Există și alte opțiuni pentru traversarea arborelui. Deci, în cazul implementării constructive, este recomandabil să urmați ideile lui Fuksman, pe care el a folosit-o în metoda de folie verticală propusă de el, pentru traversarea arborelui programului.

Esența unui astfel de ocol este după cum urmează. În cadrul unei abordări constructive, puse în aplicare în primul rând doar acele module care sunt necesare pentru cea mai simplă versiune a programului, care pot fi efectuate în mod normal, numai pentru un set foarte limitat de seturi de date de intrare, dar pentru astfel de date, această problemă va fi rezolvată până la sfârșitul anului. În loc de celelalte module, care sunt într-un astfel de program se face referire, doar imitatorii lor sunt introduse în program pentru a se asigura că, în principal, de semnalizare despre a merge dincolo de acest caz particular. Apoi, programul adaugă punerea în aplicare a unor alte module (de exemplu, în loc de unele dintre simulatoare disponibile), pentru a asigura performanța normală a unor alte seturi de date de intrare. Și acest proces continuă în etape până la implementarea completă a programului dorit.

Astfel, arborele programului este traversat cu scopul celui mai scurt mod de implementare a acestei sau acelei variante (la început cea mai simplă) a unui program care funcționează normal. În legătură cu aceasta, acest tip de realizare constructivă a fost numită metoda realizării constructive intenționate. Avantajul acestei metode este că o versiune deja dezvoltată a programului dezvoltat este deja creată într-o etapă destul de timpurie. Din punct de vedere psihologic, joacă rolul de dopaj, sporind dramatic eficacitatea dezvoltatorului. Prin urmare, această metodă este foarte atractivă.

Figura 1.7 prezintă o clasificare generală a metodelor luate în considerare pentru dezvoltarea structurii programului.

Figura 1.7 - Clasificarea metodelor de dezvoltare a unei structuri de program







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: