Razvoj softverskih modula za računarske sisteme. Radni program vježbeničke prakse za stručni modul "Razvoj softverskih softverskih modula za računarske sisteme" Razvoj softverskih modula

MINISTARSTVO PROSVETE I NAUKE

DONJECKA NARODNA REPUBLIKA

DRŽAVNI PROFESIONALAC

OBRAZOVNE USTANOVE

"DONJECK INDUSTRIJSKI I EKONOMSKI KOLEŽ"

RADNI PROGRAM

Vaspitno-obrazovna praksa UP.01

profesionalni modul PM.01 Razvoj softverskih modula softver Za kompjuterski sistemi

specijalnost 09.02.03 "Programiranje u računarskim sistemima"

Sastavio:

Volkov Vladimir Aleksandrovič, nastavnik računarskih disciplina kvalifikacijske kategorije "specijalista najviše kategorije", Državna obrazovna ustanova "Donjeck industrijski i ekonomski koledž"

Program je odobrio: Vovk Pavel Andreevich, direktor "Smart IT Service"


1. PASOŠ PROGRAMA PRAKSE
2. REZULTATI PRAKSE
3. STRUKTURA I SADRŽAJ PRAKSE
4. USLOVI ZA ORGANIZOVANJE I VOĐENJE PRAKSE
5. PRAĆENJE I EVALUACIJA REZULTATA PRAKSE

1 PASOŠ PROGRAMA OBRAZOVNO-VASPITNE PRAKSE UP. 01

1.1 Mjesto obuke UP.01

Program nastavne prakse UP.01 stručnog modula PM.01 "Razvoj softverskih softverskih modula za računarske sisteme" specijalnost 09.02.03 "Programiranje u računarskim sistemima » proširena grupa 09.00.00 „Računarstvo i računarska tehnika“, u smislu savladavanja glavne vrste stručne delatnosti (VPD):

Razvoj softverskih softverskih modula za računarske sisteme i srodne profesionalne kompetencije (PC):

	Izvršiti razvoj specifikacija za pojedinačne komponente.
	Izvršite razvoj koda softverski proizvod na osnovu gotovih specifikacija na nivou modula.
	Izvršiti otklanjanje grešaka u programskim modulima koristeći specijalizovane softverske alate.
	Izvršiti testiranje softverskih modula.
	Izvršite optimizaciju programski kod modul.
	Razviti komponente dizajna i tehničke dokumentacije koristeći jezike grafičke specifikacije.

Program obrazovno-vaspitne prakse UP.01 stručnog modula PM.01 „Razvoj softverskih softverskih modula za računarske sisteme“ može se koristiti u dodatnom stručnom obrazovanju i stručnom usavršavanju zaposlenih za specijalnosti 09.02.03 Programiranje u računarskim sistemima sa srednjom ( potpuno) opšte obrazovanje. Radno iskustvo nije potrebno.

1.2 Ciljevi i zadaciobrazovna praksa UP.01

Za ovladavanje navedenom vrstom profesionalne djelatnosti i odgovarajućim stručnim kompetencijama, student u okviru obrazovne prakse UP.01 mora:

imaju praktično iskustvo:

razvoj algoritma zadatka i njegova implementacija pomoću kompjuterskog projektovanja;

razvoj koda softverskog proizvoda na osnovu gotove specifikacije na nivou modula;

korištenje alata u fazi otklanjanja grešaka u softverskom proizvodu;

testiranje softverskog modula prema specifičnom scenariju;

biti u stanju:

vrši razvoj koda programskog modula na savremenim programskim jezicima;

kreirati program prema razvijenom algoritmu kao poseban modul;

otklanjanje grešaka i testiranje programa na nivou modula;

izraditi softversku dokumentaciju;

koristiti alate za automatizaciju pripreme dokumentacije;

znati:

glavne faze razvoja softvera;

osnovni principi strukturne i objektno orijentisane tehnologije programiranja;

osnovni principi otklanjanja grešaka i testiranja softverskih proizvoda;

metode i sredstva izrade tehničke dokumentacije.

1.3 Broj sedmica(sati) za razvoj programaobrazovna praksa UP.01

Samo 1,5 sedmice, 54 sata.

2 REZULTATI VJEŽBE

Rezultat obrazovne prakse UP.01 stručnog modula PM.01 „Razvoj softverskih softverskih modula za računarske sisteme“ je razvoj opštih kompetencija (OK):

	Naziv rezultata vježbe
	-
OK 2. Organizuju sopstvene aktivnosti, biraju standardne metode i metode za obavljanje stručnih poslova, procenjuju njihovu efikasnost i kvalitet.
OK 3. Donositi odluke u standardnim i nestandardnim situacijama i biti odgovoran za njih.
OK 4. Tražiti i koristiti informacije potrebne za efektivnu realizaciju profesionalnih zadataka, profesionalni i lični razvoj.
OK 5. Koristiti informacione i komunikacione tehnologije u profesionalnim aktivnostima.
OK 6. Radite u timu iu timu, efikasno komunicirajte sa kolegama, menadžmentom, potrošačima.
OK 7. Preuzmi odgovornost za rad članova tima (potčinjenih), za rezultat izvršenja zadataka.	-
	kvalifikacije
OK 9. Kretanje u uslovima česte promene tehnologija u profesionalnoj delatnosti.

profesionalne kompetencije (PC):

Vrsta profesionalne djelatnosti		Naziv rezultata vježbe
Ovladavanje glavnom vrstom profesionalne aktivnosti		korištenje resursa lokalnih i globalnih računarskih mreža; Upravljanje datotekama podataka na lokalnim, prijenosnim uređajima za pohranu, kao i na diskovima lokalne računalne mreže i na Internetu; štampanje, umnožavanje i kopiranje dokumenata na štampaču i drugoj kancelarijskoj opremi. tekuću kontrolu u vidu izvještaja o svakom praktičnom radu. modul kvalifikacioni ispit.
		pismenost i tačnost rada u aplikativnim programima: tekstualni i grafički uređivači, baze podataka, uređivač prezentacija; brzina traženja informacija u sadržaju baza podataka.
		postavke tačnosti i pismenosti Email, serverski i klijentski softver: brzina pretraživanja informacija korištenjem tehnologija i usluga interneta; tačnost i pismenost unosa i prenošenja informacija korišćenjem internet tehnologija i usluga.
		pismenost u korištenju metoda i sredstava zaštite informacija od neovlaštenog pristupa; ispravnost i tačnost Rezervna kopija i oporavak podataka;
		pismenost i tačnost rada sa sistemima datoteka, raznim formatima datoteka, programima za upravljanje datotekama;
		održavanje izvještaja i tehničke dokumentacije.

3 STRUKTURA I SADRŽAJ PROGRAMATRENING PRAKSA UP.01

3.1 Tematski plan

Šifre generiranih kompetencija

Naziv stručnog modula

Opseg vremena, raspoređen na praksu

(u sedmicama, sati)

Datumi

PC 1.1 - PC 1.6

PM.01 "Razvoj softverskih modula za računarske sisteme"

1,5 sedmice

54 sata

3.2 Vježbajte sadržaj

Aktivnosti	Vrste poslova		Naziv akademskih disciplina, interdisciplinarni kursevi koji ukazuju na teme, obezbjeđivanje obavljanja vrsta poslova	Broj sati (sedmice)
„Ovladavanje osnovnom vrstom profesionalne djelatnosti »	Tema 1. Uvod. Algoritmi za rješavanje problema. Struktura linearnog algoritma. Struktura cikličkog algoritma. Algoritam potprograma (funkcije).	Formirano znanje o osnovama izrade specijalnih objekata
	Predmet2 . Okruženje Skratch (Scratch).	Formirano znanje o osnovama alata za automatizaciju procesa Formirano znanje o osnovama efekata animacije na objekte; korištenje hiperlinkova i dugmadi; demo setup; prezentacije sačuvane u različitim formatima.	MDK.01.01 "Programiranje sistema"
	Predmet 3 . Izrada programa obuke (lekcija iz predmeta).	Formirano znanje o osnovama analize podataka korištenjem procesorskih funkcija	MDK.01.02 "Primijenjeno programiranje"
	Tema 4. Razvoj programa igre.	Formirano znanje o osnovama proračuna konačnih karakteristika	MDK.01.01 "Programiranje sistema"
	Tema 5. Jezik grafičko programiranje LabVIEW.	Formirano znanje o osnovama izrade procesorskog testa.	MDK.01.02 "Primijenjeno programiranje"
	Predmet 6. Izrada aplikacije koristeći LabVIEW.	Formirano znanje o osnovama dijaloga korisnika sa sistemom	MDK.01.02 "Primijenjeno programiranje"
	Predmet 7 Ponovno korištenje fragmenta programa.	Formirano znanje o operatorima i funkcijama sistema.	MDK.01.02 "Primijenjeno programiranje"
	Predmet 8 Radionica o LabVIEW-u. Zaštita rada pri radu sa računarom na radnom mestu korisnika.	Formira se računarsko znanje elementarne funkcije. Formirano znanje o zaštiti na radu.	MDK.01.02 "Primijenjeno programiranje". OP.18 "Zaštita na radu"
	Predmet 9 Zaključci. Sastavljanje izvještaja o praksi.	Formiraju se vještine analize kompjuterskih tehnologija, rješavanja problema.	MDK.01.01 "Programiranje sistema" MDK.01.02 "Primijenjeno programiranje" MDK.04.01 "Uredski softver"

4 USLOVI ORGANIZACIJE I IZVOĐENJA

OBRAZOVNA PRAKSA UP. 01

4.1 Zahtjevi za dokumentaciju, neophodno za praksu:

Radni program obrazovna praksa UP.01 stručnog modula PM.01. "Razvoj softverskih modula za računarske sisteme" deo je programa obuke za specijaliste srednjeg nivoa od strane Državne strukovne obrazovne ustanove "Donjeck industrijski i ekonomski koledž" u skladu sa državnim obrazovnim standardom srednjeg stručnog obrazovanja u specijalnosti 09.02.03. "Programiranje u računarskim sistemima", osnovan dne nastavni plan i program u specijalnosti, program rada u disciplinama MDK.01.01 „Sistemsko programiranje“, MDK01.02 „Primijenjeno programiranje“, metodičke preporuke za obrazovno-metodičku podršku praksi učenika u savladavanju obrazovnih programa srednjeg stručnog obrazovanja.

4.2 Uslovi za obrazovno-metodičku podršku prakse:

spisak odobrenih zadataka po vrstama poslova, uputstva za studente o obavljanju poslova, preporuke za realizaciju izveštaja sa prakse.

4.3 Logistics Requirements:

organizacija industrijske prakse zahtijeva prisustvo učionica i laboratorija.

Kancelarijska oprema i radna mesta:

sedišta prema broju učenika (sto, kompjuter, stolica);

radno mjesto nastavnika (sto, kompjuter, stolica);

kabinet za skladištenje nastavnih sredstava i nosača informacija;

zadaci za individualni pristup učenju, organizacija samostalnog rada i vježbi, učenik na računaru;

referentna i metodička literatura;

set sistemskih, aplikativnih i programa obuke za PC na optičkim i elektronskim medijima;

časopis za obuku studenata o zaštiti na radu;

set nastavnih sredstava.

Tehnička pomagala za obuku:

učionica;

osobno računalo s licenciranim softverom;

laserski štampač;

obrazovna računala;
set interaktivne opreme (projektor, platno, zvučnici);
sredstva za gašenje požara (aparat za gašenje požara).

Oprema kabineta i radnih stanica razvojnim alatima: personalni računari (monitor, sistemska jedinica, tastatura, miš), komplet nastavno-metodičke dokumentacije, softver u skladu sa sadržajem discipline (ljuske programski jezici).

Svi računari u učionici su povezani lokalna mreža, imaju pristup mrežnom skladištenju informacija i imaju pristup internetu.

Komunikacijska oprema:

mrežni adapteri;

mrežni kablovi;

WiFi bežična oprema.

Komponente za instalaciju mreža, oprema za ugradnju.

4.4 Lista obrazovnih publikacija, Internet resursi, dodatnu literaturu

Glavni izvori:

Olifer V.G. Mrežni operativni sistemi: udžbenik za univerzitete / V.G. Olifer, N.A. Olifer. - 2nd ed. - Sankt Peterburg: Petar, 2009, 2008. - 668 str.:

E. Tanenbaum. OS. Razvoj i implementacija. Sankt Peterburg: Piter, 2006. - 568 str.

Pupkov K.A. Ovladavanje operativnim sistemom Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moskva: Radio i komunikacija, 1994. - 112 str.

L. Beck Uvod u sistemsko programiranje - M.: Mir, 1988.

Grekul V.I., Denishchenko G.N., Korovkina N.L. Dizajn informacionih sistema / Moskva: Binom, 2008. - 304 str.

Lipaev, V.V. Softversko inženjerstvo. Metodološke osnove [Tekst]: Proc. / V. V. Lipaev; Država. un-t - Viša ekonomska škola. - M.: TEIS, 2006. - 608 str.

Lavrishcheva E. M., Petrukhin V. A. Metode i sredstva softverskog inženjeringa. - Udžbenik

Ian Somerville. Softversko inženjerstvo, 6. izdanje.: Per. sa engleskog. ―M. : Williams Publishing House, 2002.―624 str.

Excel 2010: profesionalno programiranje u VBA.: Per. sa engleskog. - M.: DOO “I.D. Williams”, 2012. - 944 str. : ill. - Paral. tit. engleski

Fowler M. Refaktoring: Poboljšanje postojećeg koda. S engleskog.—Sankt Peterburg: Symbol Plus, 2003.—432 str.

Dodatni izvori:

Volkov V.A. METODOLOŠKA UPUTSTVA za implementaciju praktičan rad u disciplini "Sistemsko programiranje", Donjeck: DONPEK, 2015.

Volkov V.A. Smjernice implementaciji kursa, Donjeck: DONPEC, 2015.

Internet- resursi:

Sistemsko programiranje [ elektronski resurs] / Način pristupa: http://www.umk3.utmn.ru.

Softver i Internet resursi: http://www.intuit.ru

Književnost po disciplinama - http://www.internet-technologies.ru/books/

Elektronski udžbenik "Uvod u softversko inženjerstvo" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Elektronski udžbenik "Tehnologija programiranja" - http://bourabai.kz/alg/pro.htm

4.5 Uslovi za voditelje prakse iz obrazovne ustanove i organizacije

Uslovi za voditelje prakse iz obrazovne ustanove:

inženjersko i nastavno osoblje: diplomci - nastavnici interdisciplinarnih predmeta i opštih stručnih disciplina. Obavezno je iskustvo u organizacijama odgovarajuće stručne oblasti.

Master industrijske obuke: dostupnost 5-6 kvalifikacione kategorije sa obaveznim stažiranjem u specijalizovanim organizacijama najmanje jednom u 3 godine. Obavezno je iskustvo u organizacijama odgovarajuće stručne oblasti.

5 PRAĆENJE I EVALUACIJA REZULTATA

OBRAZOVNA PRAKSA UP. 01

Obrazac izvještavanja o nastavnoj praksi UP.01 - izvještaj o praksi, sastavljen u skladu sa zahtjevima metodoloških preporuka.

rezultate (savladane stručne kompetencije)	Osnovni indikatori rezultat pripreme	Oblici i metode kontrolu
PC 1.1. Izvršiti razvoj specifikacija za pojedinačne komponente	Razvoj algoritma za zadatak i njegova implementacija pomoću kompjuterskog projektovanja	Stručno zapažanje i vrednovanje aktivnosti studenata u procesu savladavanja obrazovnog programa u praktičnoj nastavi, pri izvođenju radova na nastavnoj i industrijskoj praksi.
PC 1.2. Izvršiti razvoj koda softverskog proizvoda na osnovu gotovih specifikacija na nivou modula.	Poznavati osnovne principe strukturne i objektno orijentisane tehnologije programiranja. Izvršiti razvoj koda programskog modula na savremenim programskim jezicima.
PC 1.3. Izvršiti otklanjanje grešaka u programskim modulima koristeći specijalizovane softverske alate	Izvršite otklanjanje grešaka i testiranje programa na nivou modula.
PC 1.4. Izvršiti testiranje softverskih modula.	Kreirajte program prema razvijenom algoritmu kao poseban modul.
PC 1.5. Izvršite optimizaciju koda modula	Razvoj koda softverskog proizvoda na osnovu gotove specifikacije na nivou modula.
PC 1.6. Razviti komponente dizajna i tehničke dokumentacije koristeći jezike grafičke specifikacije	Poznavati metode i sredstva izrade tehničke dokumentacije. Pripremite softversku dokumentaciju. Koristite alate za automatizaciju dokumentacije.

Oblici i metode praćenja i vrednovanja ishoda učenja treba da omoguće studentima da provjere ne samo formiranost profesionalnih kompetencija, već i razvoj općih kompetencija i vještina koje ih obezbjeđuju.

rezultate (savladane opšte kompetencije)	Glavni indikatori za ocjenu rezultata	Oblici i metode kontrole i evaluacije
OK 1. Shvatite suštinu i društveni značaj svoje buduće profesije, pokažite postojano interesovanje za nju.	Pokazivanje stalnog interesovanja za buduću profesiju; - valjanost primjene ovladanih stručnih kompetencija;	Stručno posmatranje i ocjenjivanje na praktičnoj nastavi pri izvođenju radova na industrijskoj praksi;
OK 2. Organizuju sopstvene aktivnosti, određuju metode i načine obavljanja stručnih poslova, vrednuju njihovu efikasnost i kvalitet.	Opravdanost postavljanja ciljeva, odabira i primjene metoda i metoda za rješavanje profesionalnih problema; Provođenje samoanalize i korekcije rezultata vlastitog rada	Evaluacija na praktičnoj nastavi u obavljanju poslova; Posmatranje tokom prakse; Introspekcija
OK 3. Rešavati probleme, proceniti rizike i donositi odluke u nestandardnim situacijama.	Učinkovitost donošenja odluka standardnih i nestandardnih stručnih zadataka za određeno vrijeme; Učinkovitost plana za optimizaciju kvaliteta obavljenog posla	Interpretacija rezultata praćenja aktivnosti učenika u procesu izvršavanja zadataka
OK 4. Traži, analizira i procjenjuje informacije potrebne za postavljanje i rješavanje profesionalnih problema, profesionalni i lični razvoj.	Izbor i analiza potrebnih informacija za jasnu i brzu realizaciju profesionalnih zadataka, profesionalni i lični razvoj	Stručno ocjenjivanje u toku rada; Samokontrola u toku postavljanja i rešavanja problema
OK 5. Koristiti informacione i komunikacione tehnologije za poboljšanje profesionalnih aktivnosti.	sposobnost korištenja informacionih i komunikacionih tehnologija za rješavanje profesionalnih problema	ocjenjivanje zadataka
OK 6. Raditi u timu i timu, osigurati njegovu koheziju, efikasno komunicirati sa kolegama, menadžmentom, potrošačima.	Sposobnost interakcije sa grupom, nastavnicima, majstorom industrijske obuke
OK 7. Postavite ciljeve, motivišite aktivnosti podređenih, organizujte i kontrolišete njihov rad uz preuzimanje odgovornosti za rezultat zadataka.	- samoanaliza i korekcija rezultata sopstvenog rada i rada tima	Posmatranje toka rada u grupi u procesu proizvodne prakse
OK 8. Samostalno odrediti zadatke profesionalnog i ličnog razvoja, baviti se samoobrazovanjem, svjesno planirati usavršavanje.	Organizacija samostalnog rada na formiranju kreativnog i profesionalnog imidža; Organizacija rada na samoobrazovanju i usavršavanju kvalifikacije	Posmatranje i evaluacija u procesu industrijske prakse; Reflektivna analiza (algoritam radnji učenika); Dnevnik vježbe; Analiza studentskog portfolia
OK 9. Budite spremni na promjenu tehnologije u profesionalnim aktivnostima.	Analiza inovacija u oblasti tehnoloških procesa za razvoj i proizvodnju odjevnih predmeta	Evaluacija rješenja situacijskih problema; Poslovne i organizacijsko-obrazovne igre; Posmatranje i evaluacija na praktičnoj nastavi, u procesu proizvodne prakse

Postupak razvoja softverskog modula.

1. proučavanje i verifikacija specifikacije modula, izbor programskog jezika; (odnosno, programer, proučavajući specifikaciju, sazna da li mu je jasno ili ne, da li dovoljno opisuje modul; zatim bira programski jezik na kojem će modul biti napisan, iako programski jezik može biti isto za ceo PS)
2. izbor algoritma i strukture podataka (ovde se ispostavlja da li su poznati algoritmi za rješavanje problema i, ako jeste, koristiti ih)
3. programiranje modula (pisanje programskog koda)
4. poliranje teksta modula (uređivanje postojećih komentara, dodavanje dodatnih komentara kako bi se osigurao traženi kvalitet)
5. provjera modula (provjerava se logika modula, ispravlja se njegov rad)

Primjenjuju se sljedeće metode upravljanja programskim modulom:

- statička provjera teksta modula (tekst se čita od početka do kraja kako bi se pronašle greške u modulu. Obično, pored programera modula, za takvu provjeru je uključen jedan ili čak nekoliko programera. Preporučuje se da se greške otkrivene tokom takve provjere ne ispravljaju se odmah, već po završetku čitanja teksta modula)
- end-to-end tracing (ručno skrolovanje izvršavanja modula (operator po operator u redoslijedu koji slijedi iz logike modula) na određenom skupu testova)
6. kompilacija modula.

Strukturno programiranje.

Najpopularnija tehnika programiranja danas je strukturirano programiranje odozgo prema dolje.

Strukturno programiranje je proces razlaganja algoritma korak po korak na sve manje i manje dijelove kako bi se dobili elementi za koje se mogu lako napisati specifični recepti.

Dva principa strukturiranog programiranja:

1. uzastopni detalji "od vrha do dna"
2. ograničeni osnovni skup struktura za konstruisanje algoritama bilo kog stepena složenosti

Zahtjevi za strukturirano programiranje:

1. Program treba sastaviti u malim koracima, tako da je složen zadatak podijeljen na prilično jednostavne dijelove koji se lako uočavaju.
2. programska logika treba da se zasniva na minimalnom broju dovoljno osnovnih upravljačkih struktura (linearne, granaste i ciklične strukture)

Glavna svojstva i prednosti strukturiranog programiranja:

1. Smanjenje složenosti programa
2. mogućnost demonstriranja ispravnosti programa u različitim fazama rješavanja problema
3. vidljivost programa
4. lakoća modifikacije (promjene) programa.

Savremeni programski alati treba da pruže maksimalnu zaštitu od moguće greške developer.

Ovdje možemo povući analogiju sa razvojem metoda upravljanja vozilima. U početku se sigurnost osiguravala razvojem saobraćajnih pravila. Zatim je postojao sistem označavanja puteva i regulacije raskrsnica. I, konačno, počele su se graditi saobraćajne petlje koje, u principu, sprečavaju ukrštanje saobraćajnih tokova automobila i pješaka. Međutim, sredstva koja se koriste trebaju biti određena prirodom problema koji se rješava: za seoski put, usklađenost sa jednostavno pravilo- "Pogledaj pod noge i okolo."

Osnovna ideja strukturiranog programiranja: program bi trebao biti skup blokova, kombiniranih u hijerarhijskoj strukturi stabla, od kojih svaki ima jedan ulaz i jedan izlaz.

Bilo koji program se može napraviti koristeći samo tri osnovne vrste blokova:

1. funkcionalni blok - odvojen linearni operator ili njihov redosled;
2. blok grananja - Ako
3. generalizovana petlja - konstrukcija tipa While

Bitno je da svaka od ovih struktura ima samo jedan ulaz i jedan izlaz u smislu kontrole. Dakle, generalizirani operator također ima samo jedan ulaz i jedan izlaz.

Strukturirano programiranje se ponekad naziva "programiranje bez GO TO". Međutim, poenta ovdje nije izjava GO TO, već njena neselektivna upotreba. Vrlo često, kada se implementira strukturirano programiranje u nekim programskim jezicima, operator tranzicije (GO TO) se koristi za implementaciju strukturnih konstrukcija bez smanjenja glavnih prednosti strukturiranog programiranja. To su "nestrukturni" izrazi za skok koji zbunjuju program, posebno skok na naredbu koja se nalazi u tekstu modula iznad (ranije) naredbe skoka koja se izvršava. Međutim, pokušaj izbjegavanja naredbe jump u nekim jednostavnim slučajevima može dovesti do preglomaznih strukturiranih programa, što ne poboljšava njihovu jasnoću i sadrži opasnost od dodatnih grešaka u tekstu modula. Stoga se može preporučiti izbjegavanje korištenja jump izraza gdje god je to moguće, ali ne po cijenu jasnoće programa.

Korisni slučajevi korištenja operatora tranzicije uključuju izlazak iz petlje ili procedure pod posebnim uvjetom koji "rano" prekida rad ovaj ciklus ili datu proceduru, tj. prestanak rada neke strukturne jedinice (generalizovani operater) i time samo lokalno kršeći strukturiranje programa. Velike poteškoće (i kompliciranje strukture) uzrokuje strukturalna implementacija odgovora na izuzetne (često pogrešne) situacije, jer to zahtijeva ne samo rani izlazak iz strukturne jedinice, već i neophodnu obradu ove situacije (npr. , izdavanje odgovarajućih dijagnostičkih informacija). Rukovalac izuzetkom se može nalaziti na bilo kom nivou programske strukture i može mu se pristupiti sa različitih nižih nivoa. Sa tehnološke tačke gledišta sasvim prihvatljiva je sljedeća „nestrukturalna“ implementacija odgovora na izuzetne situacije. Obrađivači izuzetaka se postavljaju na kraj jedne ili druge strukturne jedinice, a svaki takav rukovalac je programiran na način da nakon završetka svog rada izlazi iz strukturne jedinice na čijem kraju je postavljen. Operator skoka poziva takav rukovalac iz date strukturne jedinice (uključujući bilo koju ugniježđenu strukturnu jedinicu).

Uopšteno govoreći, glavna stvar u strukturiranom programiranju je kompetentna kompilacija ispravnog logički dijagram programa, čija je implementacija jezičkim sredstvima sporedna stvar.

Prelazak iz neformalnog u formalno je u suštini neformalan.

Predavanje 8

RAZVOJ SOFTVERSKOG MODULA

Postupak razvoja softverskog modula. Strukturno programiranje i detaljna detaljna analiza korak po korak. Koncept pseudokoda. Kontrola softverskog modula.

8.1. Postupak razvoja softverskog modula.

Prilikom razvoja softverskog modula, preporučljivo je pridržavati se sljedećeg redoslijeda:

proučavanje i verifikacija specifikacija modula, izbor programskog jezika;

izbor algoritma i strukture podataka;

programiranje (kodiranje) modula;

poliranje teksta modula;

Provjera modula

kompilacija modula.

Prvi korak u razvoju softverskog modula je u velikoj mjeri neprekidna kontrola strukture programa odozdo: proučavanjem specifikacije modula, programer mora osigurati da je razumljiv i dovoljan za razvoj ovaj modul. Na kraju ovog koraka odabire se programski jezik: iako je programski jezik možda već unaprijed definiran za cijeli PS, u nekim slučajevima (ako to programski sistem dozvoljava), može se odabrati drugi jezik koji je prikladniji za implementaciju ovog modula (na primjer, asemblerski jezik).

U drugom koraku razvoja softverskog modula potrebno je utvrditi da li su već poznati algoritmi za rješavanje postavljenog problema ili mu je blizak. A ako postoji odgovarajući algoritam, onda ga je preporučljivo koristiti. Odabir odgovarajućih struktura podataka koje će se koristiti kada modul obavlja svoje funkcije u velikoj mjeri određuje logiku i pokazatelje kvaliteta modula koji se razvija, pa ga treba smatrati vrlo važnom odlukom.

U trećem koraku, tekst modula se gradi u odabranom programskom jeziku. Obilje svih vrsta detalja koji se moraju uzeti u obzir prilikom implementacije funkcija navedenih u specifikaciji modula može lako dovesti do stvaranja vrlo zbunjujućeg teksta koji sadrži puno grešaka i netočnosti. Pronalaženje grešaka u takvom modulu i unošenje potrebnih izmjena u njega može biti dugotrajan zadatak. Stoga je vrlo važno koristiti tehnološki opravdanu i praktično dokazanu programsku disciplinu za izradu teksta modula. Dijkstra je prvi put skrenuo pažnju na to, formulišući i potkrepljujući osnovne principe strukturiranog programiranja. Mnoge od programskih disciplina koje se široko koriste u praksi zasnivaju se na ovim principima. Najčešća je disciplina drill down, o kojoj se detaljno govori u odjeljcima 8.2 i 8.3.

Sljedeći korak u razvoju modula odnosi se na dovođenje teksta modula u konačni oblik u skladu sa specifikacijom kvaliteta PS. Prilikom programiranja modula, programer se fokusira na ispravnu implementaciju funkcija modula, ostavljajući komentare nedovršenim i dopuštajući neka kršenja zahtjeva za stil programa. Prilikom poliranja teksta modula treba urediti komentare u tekstu i eventualno uključiti dodatne komentare kako bi se obezbijedili potrebni kvalitetni primitivi. U istu svrhu, tekst programa se uređuje kako bi zadovoljio stilske zahtjeve.

Korak verifikacije modula je ručna provjera interne logike modula prije otklanjanja grešaka (koristeći njegovo izvršenje na računaru), implementira opći princip formuliran za razmatrane tehnologije programiranja, o potrebi kontrole odluka koje se donose u svakoj fazi razvoja PS (vidjeti predavanje 3). Metode validacije modula razmatrane su u odjeljku 8.4.

Konačno, posljednji korak razvoja modula znači završetak validacije modula (koristeći kompajler) i prelazak na proces otklanjanja grešaka modula.

8.2. Strukturno programiranje.

Prilikom programiranja modula, treba imati na umu da program mora biti razumljiv ne samo računaru, već i osobi: i programeru modula, i osobama koje provjeravaju modul, i testerima koji pripremaju testove za otklanjanje grešaka u modulu. , a PS održavaoci koji izvrše potrebne promjene u modulu su prisiljeni više puta analizirati logiku modula. U modernim programskim jezicima postoji dovoljno alata da ovu logiku zbunite koliko god želite, čineći modul teško razumljivim za osobu i, kao rezultat, čineći ga nepouzdanim ili teškim za održavanje. Stoga se mora voditi računa o odabiru odgovarajućih jezičkih alata i praćenju određene programske discipline. S tim u vezi, Dijkstra je predložio da se program izgradi kao sastav od nekoliko tipova kontrolnih struktura (struktura), koje mogu uvelike povećati razumljivost logike programa. Programiranje koje koristi samo takve konstrukcije se zove strukturalni.

Rice. 8.1. Osnovne upravljačke strukture strukturiranog programiranja.

Glavne konstrukcije strukturiranog programiranja su: praćenje, grananje i ponavljanje (vidi sliku 8.1). Komponente ovih konstrukcija su generalizovani operatori (čvorovi za obradu) S, S1, S2 i uslov (predikat) P. Kao generalizovani operator, može postojati ili jednostavan operator upotrebljenog programskog jezika (dodeljivanje, ulaz, izlaz, procedura pozivi), ili fragment programa, koji je kompozicija glavnih kontrolnih struktura strukturiranog programiranja. Bitno je da svaka od ovih struktura ima samo jedan ulaz i jedan izlaz u smislu kontrole. Dakle, generalizirani operator također ima samo jedan ulaz i jedan izlaz.

Takođe je veoma važno da su ove konstrukcije već matematički objekti (što, u suštini, objašnjava razlog uspeha strukturiranog programiranja). Dokazano je da je za svaki nestrukturirani program moguće konstruirati funkcionalno ekvivalentan (tj. rješavajući isti problem) strukturirani program. Za strukturirane programe, neka svojstva se mogu dokazati matematički, što omogućava otkrivanje nekih grešaka u programu. Ovom pitanju će biti posvećeno posebno predavanje.

Strukturirano programiranje se ponekad naziva "programiranje bez GO TO". Međutim, poenta ovdje nije izjava GO TO, već njena neselektivna upotreba. Vrlo često, kada se implementira strukturno programiranje u nekim programskim jezicima (na primjer, u FORTRAN), koristi se operator tranzicije (GO TO) za implementaciju strukturnih konstrukcija, što ne krši principe strukturnog programiranja. To su "nestrukturni" izrazi za skok koji zbunjuju program, posebno skok na naredbu koja se nalazi u tekstu modula iznad (prije) izvršavanja naredbe za skok. Međutim, pokušaj izbjegavanja naredbe jump u nekim jednostavnim slučajevima može dovesti do preglomaznih strukturiranih programa, što ne poboljšava njihovu jasnoću i sadrži opasnost od dodatnih grešaka u tekstu modula. Stoga se može preporučiti izbjegavanje upotrebe izraza za skok gdje god je to moguće, ali ne po cijenu jasnoće programa.

Korisni slučajevi korišćenja operatora tranzicije uključuju izlazak iz petlje ili procedure pod posebnim uslovom koji "rano" prekida rad ove petlje ili ove procedure, odnosno prekida rada neke strukturne jedinice (generalizovanog operatera) i time samo lokalno narušava strukturiranost programa. Velike poteškoće (i kompliciranje strukture) uzrokuje strukturalna implementacija odgovora na izuzetne (često pogrešne) situacije, jer to zahtijeva ne samo rani izlazak iz strukturne jedinice, već i potrebnu obradu (isključivanje) ove situacije. (na primjer, izdavanje odgovarajućih dijagnostičkih informacija). Rukovalac izuzetkom se može nalaziti na bilo kom nivou programske strukture i može mu se pristupiti sa različitih nižih nivoa. Sa tehnološke tačke gledišta sasvim prihvatljiva je sljedeća „nestrukturalna“ implementacija odgovora na izuzetne situacije. Obrađivači izuzetaka se postavljaju na kraj jedne ili druge strukturne jedinice, a svaki takav rukovalac je programiran na način da nakon završetka svog rada izlazi iz strukturne jedinice na čijem kraju je postavljen. Operator skoka poziva takav rukovalac iz date strukturne jedinice (uključujući bilo koju ugniježđenu strukturnu jedinicu).

8.3. Detaljne informacije korak po korak i koncept pseudokoda.

Strukturirano programiranje daje preporuke o tome kakav bi tekst modula trebao biti. Postavlja se pitanje kako programer treba da postupi da bi konstruisao takav tekst. Često programiranje modula počinje izgradnjom njegovog blok dijagrama, koji općenito opisuje logiku njegovog rada. kako god moderna tehnologija programer ne preporučuje da ovo radite bez odgovarajuće kompjuterske podrške. Iako dijagrami toka pružaju vrlo vizualnu reprezentaciju logike modula, kada su ručno kodirani u programskom jeziku, javlja se vrlo specifičan izvor grešaka: mapiranje u suštini dvodimenzionalnih struktura, kao što su dijagrami toka, na linearni tekst koji predstavlja modul, sadrži opasnost od narušavanja logike modula, pogotovo jer je psihološki prilično teško održati visok nivo pažnje prilikom ponovnog pregleda. Izuzetak može biti slučaj kada se koristi za izgradnju blok dijagrama grafički uređivač i toliko su formalizovani da se iz njih automatski generiše tekst u programskom jeziku (kao što se, na primer, radi u R-tehnologiji).

Kao glavni metod konstruisanja teksta modula preporučuje savremena tehnologija programiranja korak po korak detalj. Suština ove metode je da se proces razvoja teksta modula podijeli na nekoliko koraka. Na prvom

Korak opisuje opću shemu rada modula u vidljivom linearnom tekstualnom obliku (tj. koristeći vrlo velike koncepte), a ovaj opis nije u potpunosti formaliziran i fokusiran je na ljudsku percepciju. U svakom sljedećem koraku, jedan od koncepata je rafiniran i detaljan (nazvat ćemo ga specificirano) u bilo kojem opisu razvijenom u jednom od prethodnih koraka. Kao rezultat ovog koraka, kreira se opis odabranog koncepta koji se rafinira ili u terminima osnovni jezik programiranje (tj. modul odabran za prezentaciju), ili u istom obliku kao u prvom koraku uz korištenje novih rafiniranih koncepata. Ovaj proces se završava kada su svi navedeni koncepti ispunjeni pojašnjenja(tj. na kraju će biti izraženo u osnovnom programskom jeziku). Poslednji korak je dobijanje teksta modula u osnovnom programskom jeziku zamenom svih pojavljivanja rafiniranih koncepata njihovim specificiranim opisima i izražavanjem svih pojavljivanja strukturiranih programskih konstrukcija koristeći ovaj programski jezik.

Korak po korak usavršavanje je povezano sa upotrebom delimično formalizovanog jezika za predstavljanje navedenih opisa, koji se naziva pseudokod. Ovaj jezik dozvoljava upotrebu svih strukturiranih programskih konstrukcija koje su formalizovane, zajedno sa neformalnim fragmentima prirodnog jezika za predstavljanje generičkih izjava i uslova. Odgovarajući fragmenti u osnovnom programskom jeziku također se mogu specificirati kao generalizirani operatori i uvjeti.

· početak modula na osnovnom jeziku, odnosno prva rečenica ili naslov (specifikacija) ovog modula;

sekcija (skup) opisa na osnovnom jeziku, a umjesto opisa procedura i funkcija - samo njihov vanjski dizajn;

· neformalno označavanje niza operatora tijela modula kao jednog generaliziranog operatora (vidi dolje), kao i neformalno označavanje tijela svake procedure ili opisa funkcije kao jednog generalizovanog operatora;

· zadnja rečenica (kraj) modula na osnovnom jeziku.

Eksterni dizajn opisa procedure ili funkcije predstavljen je na sličan način. Međutim, slijedeći Dijkstru, bilo bi bolje da se dio opisa ovdje predstavi i sa neformalnom notacijom, detaljizirajući ga kao poseban opis.

Neformalna oznaka generaliziranog operatora u pseudokodu je napravljena na prirodnom jeziku proizvoljnom rečenicom koja otkriva njegov sadržaj općenito. Jedini formalni zahtjev za dizajn takve oznake je sljedeći: ova rečenica mora u cijelosti zauzimati jednu ili više grafičkih (štampanih) linija i završavati se tačkom (ili nekim drugim znakom posebno određenim za to).

Rice. 8.2. Osnovne konstrukcije strukturiranog programiranja u pseudokodu.

Za svaki neformalni generalizovani operator mora se kreirati poseban opis koji izražava logiku njegovog rada (detaljirajući njegov sadržaj) koristeći kompoziciju glavnih struktura strukturiranog programiranja i drugih generalizovanih operatora. Naslov takvog opisa treba da bude neformalna oznaka generalizovanog operatera koji se prerađuje. Osnovne konstrukcije strukturiranog programiranja mogu se predstaviti na sljedeći način (vidi sliku 8.2). Ovdje uslov može biti eksplicitno specificiran u osnovnom programskom jeziku kao logički izraz, ili neformalno predstavljen na prirodnom jeziku nekim fragmentom koji ocrtava značenje ovog uslova. U potonjem slučaju, potrebno je napraviti poseban opis koji detaljno opisuje ovo stanje, navodeći oznaku ovog stanja (fragmenta na prirodnom jeziku) kao naslova.

Izlaz iz ponavljanja (petlja):

Izlazni postupak (funkcija):

J. Hughes, J. Michtom. Strukturalni pristup programiranju. - M.: Mir, 1980. - str. 29-71.

V. Tursky. Metodologija programiranja. - M.: Mir, 1981. - str. 90-164.

E.A. Zhogolev. Tehnološke osnove modularnog programiranja // Programiranje, 1980, br. - str.44-49.

R.C. Holt. Struktura kompjuterskih programa: Pregled // Proceedings of the IEEE, 1975, 63(6). - str. 879-893.

G. Myers. Pouzdanost softvera. - M.: Mir, 1980. - str. 92-113.

I.Pyle. ADA je jezik ugrađenih sistema. M.: Finansije i statistika, 1984. - str. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Principi razvoja softvera. - M.: Mir, 1982, str. 65-71.

A.L. Fuksman. Tehnološki aspekti stvaranja softverski sistemi. M.: Statistika, 1979. - str. 79-94.

Predavanje 8. Razvoj softverskog modula
Postupak razvoja softverskog modula. Strukturno programiranje i detaljna detaljna analiza korak po korak. Koncept pseudokoda. Kontrola softverskog modula.
8.1. Postupak razvoja softverskog modula.
Prilikom razvoja softverskog modula, preporučljivo je pridržavati se sljedećeg redoslijeda:
proučavanje i verifikacija specifikacije modula, izbor jezika
programiranje;
izbor algoritma i strukture podataka;
programiranje modula;
poliranje teksta modula;
provjera modula;
kompilacija modula.
Prvi korak u razvoju softverskog modula je u velikoj mjeri neprekidna kontrola strukture programa odozdo: proučavanjem specifikacije modula, programer mora osigurati da je razumljiv i dovoljan za razvoj ovaj modul. Na kraju ovog koraka odabire se programski jezik: iako je programski jezik možda već unaprijed definiran za cijeli PS, u nekim slučajevima (ako to programski sistem dozvoljava), može se odabrati drugi jezik koji je prikladniji za implementaciju ovog modula (na primjer, asemblerski jezik).
U drugom koraku razvoja softverskog modula potrebno je utvrditi da li su već poznati algoritmi za rješavanje postavljenog problema ili mu je blizak. A ako postoji odgovarajući algoritam, onda ga je preporučljivo koristiti. Odabir odgovarajućih struktura podataka koje će se koristiti kada modul obavlja svoje funkcije u velikoj mjeri određuje logiku i pokazatelje kvaliteta modula koji se razvija, pa ga treba smatrati vrlo važnom odlukom.
U trećem koraku, tekst modula se gradi u odabranom programskom jeziku. Obilje svih vrsta detalja koji se moraju uzeti u obzir prilikom implementacije funkcija navedenih u specifikaciji modula može lako dovesti do stvaranja vrlo zbunjujućeg teksta koji sadrži puno grešaka i netočnosti. Pronalaženje grešaka u takvom modulu i unošenje potrebnih izmjena u njega može biti dugotrajan zadatak. Stoga je vrlo važno koristiti tehnološki opravdanu i praktično dokazanu programsku disciplinu za izradu teksta modula. Dijkstra je prvi put skrenuo pažnju na to, formulišući i potkrepljujući osnovne principe strukturiranog programiranja. Mnoge od programskih disciplina koje se široko koriste u praksi zasnivaju se na ovim principima. Najčešća je disciplina drill down, o kojoj se detaljno govori u odjeljcima 8.2 i 8.3.
Sljedeći korak u razvoju modula odnosi se na dovođenje teksta modula u konačni oblik u skladu sa specifikacijom kvaliteta PS. Prilikom programiranja modula, programer se fokusira na ispravnu implementaciju funkcija modula, ostavljajući komentare nedovršenim i dopuštajući neka kršenja zahtjeva za stil programa. Prilikom poliranja teksta modula treba urediti komentare u tekstu i eventualno uključiti dodatne komentare kako bi se obezbijedili potrebni kvalitetni primitivi. U istu svrhu, tekst programa se uređuje kako bi zadovoljio stilske zahtjeve.
Korak verifikacije modula je ručna provjera interne logike modula prije njegovog otklanjanja grešaka (koristeći njegovo izvršavanje na računaru), implementira opći princip formuliran za razmatranu tehnologiju programiranja, o potrebi kontrole odluka donesenih u svakoj fazi procesa. Razvoj PS (vidjeti predavanje 3). Metode validacije modula razmatrane su u Odjeljku 8.4.
Konačno, posljednji korak razvoja modula znači završetak validacije modula (koristeći kompajler) i prelazak na proces otklanjanja grešaka modula.
8.2. Strukturno programiranje.
Prilikom programiranja modula, treba imati na umu da program mora biti razumljiv ne samo računaru, već i osobi: i programeru modula, i osobama koje provjeravaju modul, i piscima teksta koji pripremaju testove za otklanjanje grešaka u modulu. modul, a održavaoci PS-a koji izvrše potrebne promjene u modulu morat će više puta analizirati logiku modula. U modernim programskim jezicima postoji dovoljno alata da ovu logiku zbunite koliko god želite, čineći modul teško razumljivim za osobu i, kao rezultat, čineći ga nepouzdanim ili teškim za održavanje. Stoga se mora voditi računa o odabiru odgovarajućih jezičkih alata i praćenju određene programske discipline. Dijkstra je po prvi put skrenuo pažnju na to i predložio da se program izgradi kao sastav od nekoliko tipova kontrolnih struktura (struktura), što može uvelike povećati razumljivost logike programa. Programiranje korištenjem samo takvih konstrukcija nazvano je strukturno programiranje.
Glavne konstrukcije strukturiranog programiranja su: praćenje, grananje i ponavljanje (vidi sliku 8.1). Komponente ovih konstrukcija su generalizovani operatori (čvorovi za obradu) S, S1, S2 i uslov (predikat) P. Kao generalizovani operator, može postojati ili jednostavan operator upotrebljenog programskog jezika (dodeljivanje, ulaz, izlaz, procedura pozivi), ili fragment programa, koji je kompozicija glavnih kontrolnih struktura strukturiranog programiranja. Bitno je da svaka od ovih struktura ima samo jedan ulaz i jedan izlaz u smislu kontrole. Dakle, generalizirani operator također ima samo jedan ulaz i jedan izlaz.
Takođe je veoma važno da su ove konstrukcije već matematički objekti (što, u suštini, objašnjava razlog uspeha strukturiranog programiranja). Dokazano je da je za svaki nestrukturirani program moguće konstruirati funkcionalno ekvivalentan (tj. rješavanje istog problema) strukturirani program. Za strukturirane programe, neka svojstva se mogu dokazati matematički, što omogućava otkrivanje nekih grešaka u programu. Ovom pitanju će biti posvećeno posebno predavanje.
Strukturirano programiranje se ponekad naziva "programiranje bez GO TO". Međutim, poenta ovdje nije izjava GO TO, već njena neselektivna upotreba. Vrlo često, kada se implementira strukturirano programiranje u nekim programskim jezicima (na primjer, u FORTRAN), operator tranzicije (GO TO) koristi se za implementaciju strukturnih struktura bez smanjenja glavnih prednosti strukturiranog programiranja. To su "nestrukturni" izrazi za skok koji zbunjuju program, posebno skok na naredbu koja se nalazi u tekstu modula iznad (ranije) naredbe skoka koja se izvršava. Međutim, pokušaj izbjegavanja naredbe jump u nekim jednostavnim slučajevima može dovesti do preglomaznih strukturiranih programa, što ne poboljšava njihovu jasnoću i sadrži opasnost od dodatnih grešaka u tekstu modula. Stoga se može preporučiti izbjegavanje upotrebe izraza za skok gdje god je to moguće, ali ne po cijenu jasnoće programa.
Korisni slučajevi korišćenja operatora tranzicije uključuju izlazak iz petlje ili procedure pod posebnim uslovom koji „rano“ prekida rad ove petlje ili ove procedure, tj. prekidanje rada neke strukturne jedinice (generalizovanog operatera) i time samo lokalno narušavanje strukturiranosti programa. Velike poteškoće (i kompliciranje strukture) uzrokuje strukturalna implementacija odgovora na izuzetne (često pogrešne) situacije, jer to zahtijeva ne samo rani izlazak iz strukturne jedinice, već i potrebnu obradu (isključivanje) ove situacije. (na primjer, izdavanje odgovarajućih dijagnostičkih informacija). Rukovalac izuzetkom se može nalaziti na bilo kom nivou programske strukture i može mu se pristupiti sa različitih nižih nivoa. Sa tehnološke tačke gledišta sasvim prihvatljiva je sljedeća „nestrukturalna“ implementacija odgovora na izuzetne situacije. Obrađivači izuzetaka se postavljaju na kraj jedne ili druge strukturne jedinice, a svaki takav rukovalac je programiran na način da nakon završetka svog rada izlazi iz strukturne jedinice na čijem kraju je postavljen. Operator skoka poziva takav rukovalac iz date strukturne jedinice (uključujući bilo koju ugniježđenu strukturnu jedinicu).
8.3. Detaljne informacije korak po korak i koncept pseudokoda.
Strukturirano programiranje daje preporuke o tome kakav bi tekst modula trebao biti. Postavlja se pitanje kako programer treba da postupi da bi konstruisao takav tekst. Ponekad programiranje modula počinje izgradnjom njegovog blok dijagrama, koji općenito opisuje logiku njegovog rada. Međutim, moderna tehnologija programiranja to ne preporučuje. Iako dijagrami toka pružaju vrlo vizualnu reprezentaciju logike modula, kada su kodirani u programskom jeziku, javlja se vrlo specifičan izvor grešaka: mapiranje u suštini dvodimenzionalnih struktura, kao što su dijagrami toka, na linearni tekst koji predstavlja modul, sadrži opasnost od narušavanja logike modula, štaviše, psihološki je prilično teško održati visok nivo pažnje prilikom ponovnog pregleda. Izuzetak može biti slučaj kada se grafički uređivač koristi za izradu dijagrama toka i oni su formalizirani tako da se iz njih automatski generira tekst u programskom jeziku (kao što se, na primjer, može učiniti u R - tehnologiji).
Kao glavni metod konstruisanja teksta modula, moderna tehnologija programiranja preporučuje detaljnu obradu detalja korak po korak. Suština ove metode je da se proces razvoja teksta modula podijeli na nekoliko koraka. U prvom koraku, opća shema rada modula je opisana u vidljivom linearnom tekstualnom obliku (tj. korištenjem vrlo velikih koncepata), a ovaj opis nije u potpunosti formaliziran i fokusiran je na ljudsku percepciju. U svakom sljedećem koraku jedan od koncepata (nazvat ćemo ga rafiniranim) se rafinira i detaljizira, koji se koristi (po pravilu, ne formaliziran) u bilo kojem opisu razvijenom u jednom od prethodnih koraka. Kao rezultat ovog koraka, kreira se opis odabranog koncepta koji se usavršava ili u smislu osnovnog programskog jezika (tj. modula odabranog za predstavljanje), ili u istom obliku kao u prvom koraku koristeći nove koncepte koji se rafiniraju . Ovaj proces se završava kada se svi koncepti koji se rafiniraju na kraju izraze u osnovnom programskom jeziku. Poslednji korak je dobijanje teksta modula u osnovnom programskom jeziku zamenom svih pojavljivanja rafiniranih koncepata njihovim specificiranim opisima i izražavanjem svih pojavljivanja strukturiranih programskih konstrukcija koristeći ovaj programski jezik.
Korak-po-korak drill-down uključuje upotrebu djelimično formaliziranog jezika za predstavljanje navedenih opisa, koji se naziva pseudokod. Ovaj jezik dozvoljava upotrebu svih strukturiranih programskih konstrukcija koje su formalizovane, zajedno sa neformalnim fragmentima prirodnog jezika za predstavljanje generičkih izjava i uslova. Odgovarajući fragmenti u osnovnom programskom jeziku također se mogu specificirati kao generalizirani operatori i uvjeti.
Opis glave u pseudokodu se može smatrati eksternim dizajnom modula u osnovnom programskom jeziku, koji
početak modula u osnovnom jeziku, tj. prva rečenica ili naslov (specifikacija) ovog modula;
dio (skup) opisa u osnovnom jeziku, a umjesto opisa procedura i funkcija - samo njihov vanjski dizajn;
neformalno označavanje niza izjava tijela modula kao jedne generalizovane izjave (vidi dolje), kao i neformalno označavanje niza izjava tijela svake procedure ili opisa funkcije kao jedne generalizovane izjave;
zadnja rečenica (kraj) modula u osnovnom jeziku.
Eksterni dizajn opisa procedure ili funkcije predstavljen je na sličan način. Međutim, slijedeći Dijkstru, bilo bi bolje da se dio opisa ovdje predstavi i sa neformalnom notacijom, detaljizirajući ga kao poseban opis.
Neformalna oznaka generaliziranog operatora u pseudokodu je napravljena na prirodnom jeziku proizvoljnom rečenicom koja otkriva njegov sadržaj općenito. Jedini formalni uslov za dizajn takve oznake je sljedeći: ova rečenica mora u cijelosti zauzimati jednu ili više grafičkih (štampanih) linija i završavati se tačkom.
Za svaki neformalni generalizovani operator mora se kreirati poseban opis koji izražava logiku njegovog rada (detaljirajući njegov sadržaj) koristeći kompoziciju glavnih struktura strukturiranog programiranja i drugih generalizovanih operatora. Naslov takvog opisa treba da bude neformalna oznaka generalizovanog operatera koji se prerađuje. Osnovne konstrukcije strukturiranog programiranja mogu se predstaviti na sljedeći način (vidi sliku 8.2). Ovdje uvjet može biti eksplicitno specificiran u osnovnom programskom jeziku kao Boolean izraz, ili neformalno predstavljen u prirodnom jeziku nekim fragmentom koji ocrtava značenje ovog uvjeta. U potonjem slučaju, potrebno je napraviti poseban opis koji detaljno opisuje ovo stanje, navodeći oznaku ovog stanja (fragmenta na prirodnom jeziku) kao naslova.
Rice. 8.2. Osnovne konstrukcije strukturiranog programiranja u pseudokodu.
Rice. 8.3. Posebni slučajevi operatora tranzicije kao generaliziranog operatora.
Kao generalizovani operator u pseudokodu, možete koristiti gornje posebne slučajeve operatora tranzicije (vidi sliku 8.3). Redoslijed rukovatelja izuzetkom (izuzeci) je specificiran na kraju opisa modula ili procedure (funkcije). Svaki takav rukovalac izgleda ovako:
EXCEPTION naziv_izuzetka
generički_operator
SVE IZUZETAK
Razlika između obrađivača izuzetka i procedure bez parametara je sljedeća: nakon što se procedura izvrši, kontrola se vraća na naredbu nakon njenog poziva, a nakon što se iznimka izvrši, kontrola se vraća na naredbu nakon poziva modula ili procedura (funkcija), na čijem se kraju (koja) stavlja ovaj izuzetak.
Preporučljivo je u svakom koraku detaljizacije napraviti dovoljno sadržajan opis, ali lako vidljiv (vizuelno), tako da se postavi na jednu stranicu teksta. To po pravilu znači da bi takav opis trebao biti sastav od pet ili šest strukturiranih programskih konstrukcija. Također se preporučuje postavljanje ugniježđenih struktura sa pomakom udesno za nekoliko pozicija (vidi sliku 8.4). Kao rezultat, možete dobiti opis logike rada u smislu vidljivosti koji je prilično konkurentan dijagramima toka, ali ima značajnu prednost - očuvana je linearnost opisa.

IZBRIŠI U DATOTEKU ZAPIS PRE PRVOG,

POGODNO ZA SET FILTER:

POSTAVITE POČETAK DATOTEKA.

AKO DRUGI REKORD ZADOVOLJAVA

FILTER TO

IZBRIŠITE JOŠ JEDAN ZAPIS IZ DATOTEKE.

SVE AKO

BYE

AKO SE ONDA NE BRIŠE ULAZ

Ukucajte "ZAPISI NIJE IZBRISAN".

ŠTAMPA "UKLONJENO n ZAPISI".

SVE AKO

Rice. 8.4. Primjer jednog koraka detaljiranja u pseudokodu.

Ideja detaljnog detaljiranja korak po korak se ponekad pripisuje Dijkstri. Međutim, Dijkstra je predložio fundamentalno drugačiji metod za konstruisanje teksta modula, koji nam se čini dubljim i obećavajućim. Prvo, zajedno sa preciziranjem operatora, predložio je da se postepeno (korak po korak) preciziraju (detalji) strukture podataka koje se koriste. Drugo, na svakom koraku, on je predložio kreiranje određene virtuelne mašine za detaljizaciju i, u njenom smislu, detaljiziranje svih rafiniranih koncepata za koje ova mašina to omogućava. Tako je Dijkstra predložio, u suštini, detaljiranje horizontalnim slojevima, što je prijenos njegove ideje slojevitih sistema (vidi predavanje 6) na nivo razvoja modula. Ovaj metod razvoja modula trenutno podržavaju ADA jezički paketi i objektno orijentisani programski alati.
8.4. Kontrola softverskog modula.
Primjenjuju se sljedeće metode upravljanja programskim modulom:
statička provjera teksta modula;
praćenje od kraja do kraja;
dokaz svojstava softverskog modula.
Tokom statičke provjere teksta modula, ovaj tekst se čita od početka do kraja kako bi se pronašle greške u modulu. Obično, pored programera modula, za takvu provjeru je uključen još jedan ili čak nekoliko programera. Preporučuje se da se greške otkrivene tokom takve provjere ne ispravljaju odmah, već po završetku čitanja teksta modula.
Praćenje od kraja do kraja jedna je od vrsta dinamičke kontrole modula. Takođe uključuje nekoliko programera koji ručno prolaze kroz izvođenje modula (izjava po naredbu u nizu koji slijedi iz logike modula) na određenom skupu testova.
Sljedeće predavanje je posvećeno dokazivanju svojstava programa. Ovdje treba samo napomenuti da se ova metoda još uvijek vrlo rijetko koristi.
Literatura za predavanje 8.
8.2. E. Dijkstra. Bilješke o strukturiranom programiranju// W. Dahl, E. Dijkstra, K. Hoor. Strukturno programiranje. - M.: Mir, 1975. - S. 24-97.
8.3. N. Wirth. Sistematsko programiranje. - M.: Mir, 1977. - S. 94-164.
Predavanje 9
Koncept programske opravdanosti. Formalizacija svojstava programa, Hoorova trijada. Pravila za postavljanje svojstava operatora dodjeljivanja, uvjetnog operatora i složenog operatora. Pravila za uspostavljanje svojstava operatora petlje, koncept invarijante petlje. Završetak izvođenja programa.
9.1. Programska opravdanja. Formalizacija svojstava programa.
Da bi se poboljšala pouzdanost softverskih alata, vrlo je korisno isporučiti programe Dodatne informacije, uz čiju upotrebu je moguće značajno povećati nivo kontrole PS. Takve informacije mogu biti date u obliku neformalnih ili formaliziranih izjava koje su vezane za različite fragmente programa. Takve tvrdnje ćemo nazvati programskim opravdanjima. Neformalizovana opravdanja programa mogu, na primer, da objasne motive za donošenje određenih odluka, što u velikoj meri može olakšati traženje i ispravljanje grešaka, kao i proučavanje programa tokom njihovog održavanja. Formalizovana opravdanja omogućavaju da se neka svojstva programa dokažu i ručno i da se kontrolišu (podese) automatski.
Jedan od trenutno korištenih koncepata formalnih opravdanja programa je korištenje takozvanih Hoorovih trijada. Neka je S neki generalizovani operator nad informacionim okruženjem IS, P i Q - neki predikati (izjave) nad ovim okruženjem. Tada se notacija (P)S(Q) naziva Hoor trijada, u kojoj se predikat P naziva preduslov, a predikat Q naziva se postuslov u odnosu na operator S. Operator (posebno program) Za S se kaže da ima svojstvo (P)S(Q), ako kad god je predikat P istinit prije nego što se S izvrši, predikat Q je istinit nakon što se S izvrši.
Jednostavni primjeri svojstava programa:
(9.1) (n=0) n:=n+1 (n=1),
(9.2) (n
(9.3) (n
(9.4) (n>0) p:=1; m:=1;
DOK m /= n DO
BYE
Da bismo dokazali svojstvo programa S, koristimo svojstva jednostavnih operatora programskog jezika (ovdje se ograničavamo na prazan operator i operator dodjeljivanja) i svojstva kontrolnih struktura (kompozicija) s kojima se program gradi od jednostavni operatori (ovdje se ograničavamo na tri glavne kompozicije strukturiranog programiranja, vidjeti predavanje 8). Ova svojstva se obično nazivaju pravilima verifikacije programa.
9.2. Svojstva jednostavnih operatora.
Za prazan operator,
Teorema 9.1. Neka je P predikat nad informacijskim okruženjem. Tada vrijedi svojstvo (P)(P).
Dokaz ove teoreme je očigledan: prazan operator ne menja stanje informacionog okruženja (u skladu sa njegovom semantikom), tako da njegov preduslov ostaje tačan nakon njegovog izvršenja.
Za operatora dodjeljivanja,
Teorema 9.2. Neka se informaciono okruženje IS sastoji od varijable X i ostatka informacionog okruženja RIS:
Zatim imovina
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,
gdje je F(X, RIS) neka jednoznačna funkcija, Q je predikat.
Dokaz. Neka je predikat Q(F(X0, RIS0), RIS0) istinit prije izvršenja operatora dodjeljivanja, gdje je (X0, RIS0) neko proizvoljno stanje informacionog okruženja IS, a zatim nakon izvršenja operatora dodjeljivanja predikat Q(X, RIS) će biti istinito, pa kako će X dobiti vrijednost F(X0, RIS0) i stanje RIS-a se ne mijenja datom naredbom dodjeljivanja, a samim tim i nakon izvršenja ove naredbe dodjeljivanja u ovom slučaju
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
Na osnovu proizvoljnosti izbora stanja informacionog okruženja, teorema je dokazana.
Primjer svojstva operatora dodjeljivanja je Primjer 9.1.
9.3. Svojstva osnovnih struktura strukturnog programiranja.
Razmotrite sada svojstva glavnih struktura strukturiranog programiranja: praćenje, grananje i ponavljanje.
Svojstva sukcesije su izražena sledećim
Teorema 9.3. Neka su P, Q i R predikati nad informacijskim okruženjem, a S1 i S2 generalizirani operatori koji imaju svojstva
(P)S(Q) i (Q)S2(R).
Zatim za složeni operator
S1; S2<.blockquote>
postoji nekretnina
(P) S1; S2(R) .
Dokaz. Neka je predikat P tačan za neko stanje informacionog okruženja pre izvršenja operatora S1. Tada će, na osnovu svojstva operatora S1, nakon njegovog izvršenja, predikat Q biti tačan izvršavanjem operatora S2. Shodno tome, nakon izvršenja operatora S2, na osnovu svog svojstva, predikat R će biti istinit, a pošto operator S2 završi izvršavanje složenog iskaza (u skladu sa njegovom semantikom), predikat R će biti istinit nakon izvršenje ove složene izjave, što je trebalo dokazati.
Na primjer, ako svojstva (9.2) i (9.3) vrijede, onda
mjesto i posjed
(n
Svojstvo grananja je izraženo sljedećim
Teorema 9.4. Neka su P, Q i R predikati nad informacijskim okruženjem, a S1 i S2 generalizirani operatori koji imaju svojstva
(P,Q)S1(R) i (`P,Q)S2(R).
Zatim za uslovni operator
AKO P ONDA S1 ELSE S2 SVE AKO
postoji nekretnina
(Q) AKO P ONDA S1 DRUGO S2 SVE AKO (R) .
Dokaz. Neka je predikat Q tačan za neko stanje informacionog okruženja pre izvršenja uslovnog operatora.Ako je i predikat P tačan, onda se izvršenje uslovnog operatora u skladu sa njegovom semantikom svodi na izvršenje operatora S1 . Na osnovu svojstva operatora S1, nakon njegovog izvršenja (i u ovom slučaju, nakon izvršenja uslovnog operatora), predikat R će biti tačan. Ako, međutim, pre izvršenja uslovnog operatora, predikat P je netačan (a Q je još uvijek istinit), onda se izvršenje uvjetnog operatora u skladu sa njegovom semantikom svodi na izvršenje operatora S2. Na osnovu svojstva operatora S2, nakon njegovog izvršenja (iu ovom slučaju, nakon izvršenja uslovnog operatora), predikat R će biti tačan. Time je teorema u potpunosti dokazana.
Prije nego što pređemo na svojstvo konstrukcije ponavljanja, treba napomenuti da je korisno za dalje
Teorema 9.5. Neka su P, Q, P1 i Q1 predikati nad informacijskim okruženjem za koje su implikacije
P1=>P i Q=>Q1,
i neka svojstvo (P)S(Q) vrijedi za operator S. Tada vrijedi svojstvo (P1)S(Q1).
Ova teorema se također naziva teorema svojstva slabljenja.
Dokaz. Neka je predikat P1 tačan za neko stanje informacionog okruženja prije izvršenja operatora S. Tada će i predikat P biti istinit (zbog implikacije P1=>P). Shodno tome, na osnovu svojstva operatora S, nakon njegovog izvršenja, predikat Q će biti tačan, a samim tim i predikat Q1 (na osnovu implikacije Q=>Q1). Tako je teorema dokazana.
Svojstvo ponavljanja izražava se sljedećim
Teorema 9.6. Neka su I, P, Q i R predikati nad informacijskim okruženjem za koje su implikacije
P=>I i (I,`Q)=>R ,
i neka je S generalizovani operator sa svojstvom (I)S(I).
Zatim za operator petlje
BYE Q DO S ALL BYE
postoji nekretnina
(P) ZBOGOM Q DO S DA SVE ZBOGOM (R) .
Predikat I se naziva invarijanta operatora petlje.
Dokaz. Da bi se dokazala ova teorema, dovoljno je dokazati svojstvo
(I) ZBOGOM Q DO S DA SVE ZBOGOM (I,`Q)
(prema teoremi 9.5 na osnovu implikacija u uslovima ove teoreme). Neka predikat I bude tačan za neko stanje informacionog okruženja pre izvršenja operatora ciklusa. Ako je u ovom slučaju predikat Q lažan, tada će operator ciklusa biti ekvivalentan praznom operatoru (u skladu sa njegovom semantikom) i, na osnovu teoreme 9.1, nakon izvršenja operatora ciklusa, iskaz (I ,`Q). Ako je predikat Q istinit prije izvršenja operatora petlje, tada se operator petlje, u skladu sa svojom semantikom, može predstaviti kao složeni operator S; BYE Q DO S ALL BYE
Na osnovu svojstva operatora S, nakon njegovog izvršenja, predikat I će biti istinit, a nastaje početna situacija za dokazivanje svojstva operatora ciklusa: predikat I je tačan pre izvršenja operatora ciklusa, ali za različito (promijenjeno) stanje informacionog okruženja (za koje predikat Q može biti istinit ili netačan). Ako se završi izvršavanje naredbe petlje, onda ćemo primjenom metode matematičke indukcije, u konačnom broju koraka, doći u situaciju da će iskaz (I,`Q) biti tačan prije njegovog izvršenja. I u ovom slučaju, kao što je gore dokazano, ova izjava će biti istinita čak i nakon izvršenja naredbe ciklusa. Teorema je dokazana.
Na primjer, za operator petlje iz primjera (9.4), svojstvo se odvija
m:= m+1; p:= p*m
JOŠ SVE (p= n.!}
Ovo slijedi iz teoreme 9.6, pošto je invarijanta ovog operatora petlje predikat p=m! i implikacije (n>0, p=1, m=1) => p=m! i (p=m!, m=n) => p=n!
9.4. Završetak izvođenja programa.
Jedno od svojstava programa koje bi nas moglo zanimati kako bismo izbjegli moguće greške u PS-u je njegov prekid, tj. odsustvo ciklusa u njemu za određene početne podatke. U strukturiranim programima koje smo razmatrali, samo konstrukcija ponavljanja može biti izvor petlje. Stoga, da bi se dokazao završetak programa, dovoljno je moći dokazati završetak operatora petlje. Za ovo je korisno sljedeće.
Teorema 9.7. Neka je F cjelobrojna funkcija koja ovisi o stanju informacionog okruženja i zadovoljava sljedeće uvjete:
(1) ako je za dato stanje informaciono okruženje, predikat Q je istinit, tada je njegova vrijednost pozitivna;
(2) smanjuje se kada se stanje informacionog okruženja promijeni kao rezultat izvršavanja operatora S.
Zatim izvršavanje naredbe petlje
WHILE Q URADI SVE DOK se završava.
Dokaz. Neka je stanje informacionog okruženja prije izvršenja naredbe ciklusa i neka je F(is)=k. Ako je predikat Q(is) netačan, tada se izvršavanje naredbe petlje završava. Ako je Q(is) istina, onda prema pretpostavci teoreme k>0. U ovom slučaju, naredba S će se izvršiti jednom ili više puta. Nakon svakog izvršenja operatora S, prema uslovu teoreme, vrijednost funkcije F opada, a budući da prije izvršenja operatora S predikat Q mora biti tačan (prema semantici operatora ciklusa) , vrijednost funkcije F u ovom trenutku mora biti pozitivna (prema uvjetu teoreme). Stoga, zbog integralnosti funkcije F, operator S u ovom ciklusu može se izvršiti više od k puta. Teorema je dokazana.
Na primjer, za primjer operatora ciklusa koji je gore razmatran, uslovi teoreme 9.7 su zadovoljeni funkcijom f(n, m)= n-m. Budući da će se prije izvršenja naredbe petlje m=1, tijelo ove petlje izvršiti (n-1) puta, tj. ovaj izraz petlje se završava.
9.5. Primjer dokaza svojstva programa.
Na osnovu dokazanih pravila za verifikaciju programa moguće je dokazati svojstva programa koji se sastoje od iskaza dodjeljivanja i praznih izraza i korištenjem tri osnovne kompozicije strukturiranog programiranja. Da biste to učinili, analizirajući strukturu programa i koristeći njegove pred- i post-uslove, potrebno je primijeniti odgovarajuće pravilo verifikacije u svakom koraku analize. U slučaju kompozicije ponavljanja, biće potrebno odabrati odgovarajuću invarijantu ciklusa.
Kao primjer, dokažemo svojstvo (9.4). Ovaj dokaz će se sastojati od sljedećih koraka.
(Korak 1). n>0 => (n>0, p - bilo koji, m - bilo koji).
(Korak 2). Javlja se
(n>0, p - bilo koji, m - bilo koji) p:=1 (n>0, p=1, m - bilo koji).
Prema teoremi 9.2.
(Korak 3). Javlja se
(n>0, p=1, m - bilo koji) m:=1 (n>0, p=1, m=1).
Prema teoremi 9.2.
(Korak 4). Javlja se
(n>0, p - bilo koji, m - bilo koji) p:=1; m:=1 (n>0, p=1, m=1).
Prema teoremi 9.3, zbog rezultata koraka 2 i 3.
Dokažimo da je predikat p=m! je ciklus invarijanta, tj. (p=m m:=m+1; p:=p*m {p=m!}.!}
(Korak 5). Održava se (p=m m:=m+1 {p=(m-1)!}.!}
Prema teoremi 9.2, ako preduslov predstavimo u obliku (p=((m+1)-1).!}
(Korak 6). Održava se (p=(m-1) p:=p*m {p=m!}.!}
Prema teoremi 9.2, ako preduslov predstavimo u obliku (p*m=m.!}
(Korak 7). Postoji invarijantni ciklus
(p=m m:=m+1; p:=p*m {p=m!}.!}
Prema teoremi 9.3, zbog rezultata koraka 5 i 6.
(Korak 8). Javlja se
(n>0, p=1, m=1) DOK m /= n DO
m:= m+1; p:= p*m
JOŠ SVE (p= n.!}
Prema teoremi 9.6, na osnovu rezultata koraka 7 i imajući u vidu da je (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(Korak 9). Javlja se
(n>0, p - bilo koji, m - bilo koji) p:=1; m:=1;
DOK m /= n DO
m:= m+1; p:= p*m
JOŠ SVE (p= n.!}
Prema teoremi 9.3, zbog rezultata koraka 3 i 8.
(Korak 10). Svojstvo (9.4) vrijedi prema teoremi 9.5 zbog rezultata koraka 1 i 9.
Literatura za predavanje 9.
9.1. S.A. Abramov. Elementi programiranja. - M.: Nauka, 1982. S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Principi razvoja softvera. - M.: Mir, 1982. S. 98-105.
Predavanje 10
Osnovni koncepti. Strategija dizajna testa. Naredbe za otklanjanje grešaka. Offline otklanjanje grešaka i testiranje softverskog modula. Sveobuhvatno otklanjanje grešaka i testiranje softvera.
10.1. Osnovni koncepti.
Otklanjanje grešaka u PS-u je aktivnost koja ima za cilj otkrivanje i ispravljanje grešaka u PS-u koristeći procese izvršavanja njegovih programa. PS testiranje je proces izvršavanja njegovih programa na određenom skupu podataka, za koji je unaprijed poznat rezultat aplikacije ili su poznata pravila ponašanja tih programa. Navedeni skup podataka naziva se test ili samo test. Dakle, otklanjanje grešaka može se predstaviti kao ponovljeno ponavljanje tri procesa: testiranje, kao rezultat kojeg se može utvrditi prisustvo greške u PS-u, traženje mesta greške u programima i dokumentaciji PS-a i uređivanje programa i dokumentacije u cilju otklanjanja otkrivene greške. Drugim riječima:
Otklanjanje grešaka = Testiranje + Pronalaženje grešaka + Uređivanje.
U stranoj literaturi debagovanje se često shvata samo kao proces pronalaženja i ispravljanja grešaka (bez testiranja), čije se prisustvo utvrđuje tokom testiranja. Ponekad se testiranje i otklanjanje grešaka smatraju sinonimima. Kod nas pojam otklanjanja grešaka obično uključuje testiranje, pa ćemo se pridržavati ustaljene tradicije. Međutim, zajedničko razmatranje ovih procesa u ovom predavanju čini naznačeno neslaganje manje značajnom. Međutim, treba napomenuti da se testiranje koristi i kao dio procesa certifikacije PS (vidjeti predavanje 14).
10.2. Principi i vrste otklanjanja grešaka.
Uspeh otklanjanja grešaka u velikoj meri je određen racionalnom organizacijom testiranja. Tokom otklanjanja grešaka, uglavnom se pronalaze i eliminišu one greške, čije se prisustvo u PS-u utvrđuje tokom testiranja. Kao što je već napomenuto, testiranje ne može dokazati ispravnost PS-a, u najboljem slučaju može pokazati prisustvo greške u njemu. Drugim rečima, ne može se garantovati da je testiranjem softvera sa praktično izvodljivim skupom testova moguće utvrditi prisustvo svake greške prisutne u softveru. Stoga se javljaju dva problema. Prvo pripremite takav skup testova i na njih primijenite PS kako biste u njemu otkrili što više grešaka. Međutim, što se proces testiranja (i otklanjanja grešaka općenito) nastavlja, cijena softvera postaje veća. Otuda drugi zadatak: odrediti trenutak kada je otklanjanje grešaka PS-a (ili njegovih pojedinačnih komponenti) završeno. Znak mogućnosti prestanka otklanjanja grešaka je potpunost pokrivenosti testovima prošlim kroz PS (tj. testovima na koje je PS primenjen) mnogo različitih situacija koje nastaju tokom izvršavanja PS programa, a relativno retka manifestacija grešaka u PS u poslednjem segmentu procesa testiranja. Potonji se utvrđuje u skladu sa potrebnim stepenom pouzdanosti PS-a, navedenim u specifikaciji njegovog kvaliteta.
Za optimizaciju testnog paketa, tj. pripremiti takav skup testova koji bi omogućio, sa zadatim brojem njih (ili sa datim vremenskim intervalom koji je dodijeljen za testiranje), da se otkrije više greške, potrebno je, prvo, unaprijed planirati ovaj skup i, drugo, koristiti racionalnu strategiju planiranja (dizajniranja) testova. Test dizajn može početi odmah nakon završetka faze eksternog opisa PS-a. Postoje različiti pristupi razvoju strategije dizajna testa, koja se uslovno može grafički postaviti (vidi sliku 9.1) između sledeća dva ekstremna pristupa. Lijevi ekstremni pristup je da su testovi dizajnirani samo na osnovu proučavanja PS specifikacija (spoljni opis, opis arhitekture i specifikacija modula). Struktura modula se ni na koji način ne uzima u obzir, tj. tretiraju se kao crne kutije. Zapravo, ovaj pristup zahtijeva kompletno nabrajanje svih ulaznih skupova podataka, jer kada se koristi samo dio ovih skupova kao testova, neki dijelovi PS programa možda neće raditi ni na jednom testu, pa stoga greške sadržane u njima neće raditi. pojaviti. Međutim, testiranje PS-a s punim skupom ulaznih skupova podataka je praktično nemoguće. Pravi ekstremni pristup je da se testovi osmišljavaju na osnovu proučavanja programskih tekstova kako bi se testirali svi načini na koje se svaki PS program izvršava. Ako uzmemo u obzir postojanje ciklusa sa promjenjivim brojem ponavljanja u programima, onda može postojati i izuzetno veliki broj različitih načina izvršavanja PS programa, tako da će i njihovo testiranje biti praktično nemoguće.
Optimalna strategija dizajna testa nalazi se unutar intervala između ovih ekstremnih pristupa, ali bliže lijevoj strani. Uključuje dizajniranje značajnog dijela testova prema specifikacijama, na osnovu principa: za svaku funkciju ili značajku koja se koristi - najmanje jedan test, za svako područje i za svaku granicu promjene bilo koje ulazne varijable - najmanje jedan test, za svaku poseban slučaj ili za svaki izuzetak naveden u specifikacijama - najmanje jedan test. Ali to također zahtijeva dizajn nekih testova i tekstova programa, na principu (najmanje): svaka komanda svakog PS programa mora raditi na najmanje jednom testu.
Optimalna strategija dizajna testa može se odrediti na osnovu sljedećeg principa: za svaki programski dokument (uključujući programski tekstovi), koji je dio PS-a, treba da osmisle vlastite testove kako bi identificirali greške u njemu. U svakom slučaju, ovaj princip se mora poštovati u skladu sa definicijom softvera i sadržajem koncepta tehnologije programiranja kao tehnologije za razvoj pouzdanog softvera (videti predavanje 1). U tom smislu, Myers čak i definiše različite vrste testiranje u zavisnosti od vrste programskog dokumenta na osnovu kojeg se grade testovi. U našoj zemlji postoje dvije glavne vrste otklanjanja grešaka (uključujući testiranje): samostalno i složeno otklanjanje grešaka. Offline debagovanje podrazumeva testiranje samo nekog dela programa koji je uključen u PS, uz pretragu i ispravljanje grešaka zabeleženih tokom testiranja. To zapravo uključuje otklanjanje grešaka svakog modula i otklanjanje grešaka uparivanja modula. Sveobuhvatno otklanjanje grešaka podrazumeva testiranje PS-a u celini sa traženjem i ispravljanjem grešaka zabeleženih tokom testiranja u svim dokumentima (uključujući tekstove PS programa) koji se odnose na PS kao celinu. Takvi dokumenti uključuju definiciju zahtjeva za PS, specifikaciju kvaliteta PS-a, funkcionalnu specifikaciju PS-a, opis arhitekture PS-a i tekstove PS programa.
10.3. Naredbe za otklanjanje grešaka.
Ovaj odjeljak pruža opće smjernice za organiziranje otklanjanja grešaka. Ali prvo treba napomenuti fenomen koji potvrđuje važnost prevencije grešaka u prethodnim fazama razvoja: kako raste broj otkrivenih i ispravljenih grešaka u softveru, tako se povećava i relativna vjerovatnoća postojanja neotkrivenih grešaka u njemu. Ovo se objašnjava činjenicom da se sa povećanjem broja grešaka otkrivenih u PS-u, poboljšava i naše razumijevanje ukupnog broja grešaka napravljenih u njemu, a time, u određenoj mjeri, i broja grešaka koje još nisu otkrivene. Ovaj fenomen potvrđuje važnost ranog otkrivanja grešaka i potrebu za pažljivom kontrolom odluka koje se donose u svakoj fazi razvoja softvera.
Zapovijed 1. Smatrajte testiranje ključnim zadatkom razvoja softvera, povjerite ga najkvalifikovanijim i najdarovitijim programerima; nepoželjno je testirati vlastiti program.
Zapovijed 2. Dobar test je onaj koji ima veliku vjerovatnoću pronalaženja greške, a ne onaj koji pokazuje ispravan rad programa.
Zapovijed 3. Pripremite testove i za tačne i za netačne podatke.
Zapovijed 4. Izbjegavajte neponovljive testove, dokumentujte njihov prolazak kroz kompjuter; detaljno proučite rezultate svakog testa.
Zapovijed 5. Povežite svaki modul sa programom samo jednom; nikada ne modificirajte program kako biste ga lakše testirali.
Zapovijed 6. Ponovo preskočite sve testove koji se odnose na provjeru rada bilo kojeg PS programa ili njegove interakcije sa drugim programima ako su u njemu napravljene promjene (na primjer, kao rezultat popravljanja greške).
10.4. Offline modul za otklanjanje grešaka.
U offline otklanjanju grešaka, svaki modul se zapravo testira u nekom programskom okruženju, osim ako se program koji se otklanja ne sastoji od samo jednog modula. Ovo okruženje se sastoji od drugih modula, od kojih su neki moduli programa koji se otklanja greške i koji su već otklonjeni, a neki od njih su moduli koji kontrolišu otklanjanje grešaka (moduli za otklanjanje grešaka, vidi dole). Dakle, tokom offline otklanjanja grešaka, neki program se uvijek testira, napravljen posebno za testiranje modula koji se otklanja. Ovaj program samo djelomično odgovara programu koji se otklanja greške, osim kada se otklanja posljednji modul programa koji se otklanja. Kako otklanjanje grešaka programa napreduje, sve veći dio okruženja sljedećeg modula koji se otklanja će biti već otklonjeni moduli ovog programa, a kada se otklanja greške u posljednjem modulu ovog programa, okruženje modula koji se otklanja će se u potpunosti sastojati od svi ostali (već otklonjeni) moduli programa koji se otklanjaju (bez ikakvih) modula za otklanjanje grešaka, moduli, tj. u ovom slučaju, sam program za uklanjanje grešaka će biti testiran. Ovaj proces izgradnje debugovanog programa sa otklonjenim i otklonjenim modulima naziva se integracija programa.
Moduli za otklanjanje grešaka uključeni u okruženje modula koji se otklanja zavise od redosleda kojim se otklanjaju greške u modulima tog programa, koji modul se otklanja i eventualno koji će test biti preskočen.
U testiranju odozdo prema gore (pogledajte Poglavlje 7), ovo okruženje će uvijek sadržavati samo jedan modul za otklanjanje grešaka (osim kada se otklanja zadnji modul programa koji se otklanja greške), koji će biti glava programa koji se testira i koji se zove majstor (ili vozač). Vodeći modul za otklanjanje grešaka priprema informacijsko okruženje za testiranje modula koji se debugira (tj. formira svoje stanje potrebno za testiranje ovog modula, posebno može uneti neke testne podatke), poziva modul koji se otklanja greške i nakon njegovog rada završen, izdaje potrebne poruke. Prilikom otklanjanja grešaka u jednom modulu, različiti glavni moduli za otklanjanje grešaka mogu se kompajlirati za različite testove.
U testiranju naniže (pogledajte Poglavlje 7), okruženje modula koji se debugira sadrži, kao module za otklanjanje grešaka, simulatore svih modula kojima može pristupiti modul koji se debugira, kao i simulatore onih modula kojima može pristupiti otklonjeni moduli programa koji se otklanjaju greške (uključeni u ovo okruženje), ali koji još nisu otklonjeni. Neki od ovih simulatora mogu se mijenjati za različite testove prilikom otklanjanja grešaka u jednom modulu.
U stvari, okruženje modula koji se otklanja može u mnogim slučajevima sadržavati oba tipa modula za otklanjanje grešaka iz sljedećih razloga. I testiranje naviše i naniže imaju svoje prednosti i nedostatke.
Prednosti testiranja odozdo prema gore uključuju
jednostavnost pripreme testova i
sposobnost da se u potpunosti implementira plan testiranja modula.
To je zbog činjenice da se testno stanje informacionog okruženja priprema neposredno prije poziva modulu koji se otklanja greške (vodeći modul za otklanjanje grešaka). Nedostaci testiranja odozdo prema gore su sljedeće karakteristike:
testni podaci se po pravilu pripremaju ne u formi koja je dizajnirana za korisnika (osim kada je debagovan poslednji, glavni modul programa koji se debuguje);
velika količina programiranja za otklanjanje grešaka (kada otklanjate greške u jednom modulu, često morate sastaviti mnogo vodećih modula za otklanjanje grešaka za različite testove);
potreba za posebnim testiranjem interfejs modula.
Prednosti testiranja odozgo prema dolje uključuju sljedeće karakteristike:
većina testova je pripremljena u obliku dizajniranom za korisnika;
u mnogim slučajevima, relativno mala količina programiranja za otklanjanje grešaka (simulatori modula su, po pravilu, vrlo jednostavni i svaki je pogodan za veliki broj, često za sve, testove);
nema potrebe testirati uparivanje modula.
Nedostatak testiranja odozgo prema dolje je u tome što se testno stanje informacionog okruženja prije pristupa modulu koji se debugira priprema indirektno – to je rezultat primjene već otklonjenih modula na testne podatke ili podatke koje izdaju simulatori. Ovo, prvo, otežava pripremu testova, zahteva visoko kvalifikovanog izvršioca testa, a drugo, otežava ili čak onemogućava implementaciju kompletnog plana testiranja za modul koji se otklanja greške. Ovaj nedostatak ponekad prisiljava programere da koriste testiranje odozdo prema gore čak iu slučaju razvoja odozgo prema dolje. Češće se, međutim, koristi neka modifikacija testiranja odozgo prema dolje ili neka kombinacija testiranja odozgo prema dolje i odozdo prema gore.
Na osnovu činjenice da je testiranje odozgo prema dolje, u principu, poželjnije, zadržimo se na tehnikama koje nam omogućavaju da u određenoj mjeri prevaziđemo ove poteškoće. Prije svega, potrebno je organizirati otklanjanje grešaka u programu na način da se moduli koji vrše unos podataka otklone što je prije moguće – tada se testni podaci mogu pripremiti u obliku dizajniranom za korisnika, što će uvelike pojednostaviti pripremu narednih testova. Ovaj unos se nikako ne izvodi uvijek u glavnom modulu, tako da prvo morate otkloniti greške u lancima modula koji vode do modula koji izvršavaju specificirani unos (uporedi s metodom svrsishodne konstruktivne implementacije u predavanju 7). Dok se ulazni moduli ne otklone, testne podatke dostavljaju neki simulatori: oni su ili uključeni u simulator kao njegov dio, ili ih unosi ovaj simulator.
U testiranju odozgo prema dolje, neka stanja informacionog okruženja pod kojima je potrebno testirati modul koji se otklanja greške možda se neće pojaviti tokom izvršavanja programa koji se otklanja za bilo koji ulaz. U ovim slučajevima bilo bi moguće uopće ne testirati modul koji se debugira, jer se greške pronađene u ovom slučaju neće pojaviti kada se program koji se debugira izvršava pod bilo kojim ulaznim podacima. Međutim, nije preporučljivo to učiniti, jer kada se program koji se otklanja greške mijenja (na primjer, prilikom održavanja PS-a), mogu se već pojaviti stanja informacionog okruženja koja nisu korištena za testiranje modula koji se debugira, što zahtijeva dodatne testiranje ovog modula (a to se, uz racionalnu organizaciju otklanjanja grešaka, ne bi moglo uraditi ako se sam modul nije promijenio). Da bi se testirao modul koji se debuguje u ovim situacijama, ponekad se koriste odgovarajući simulatori za kreiranje željenog stanja informacionog okruženja. Češće se koristi modificirana verzija testiranja odozgo prema dolje, u kojoj se moduli koji se otklanjaju grešaka prethodno testiraju zasebno prije nego što se integriraju (u ovom slučaju, vodeći modul za otklanjanje grešaka pojavljuje se u okruženju modula koji se otklanja, zajedno s modulom simulatori kojima se može pristupiti modulom koji se otklanja). Međutim, čini se da je prikladnija druga modifikacija testiranja odozgo prema dolje: nakon što se završi testiranje odozgo prema dolje modula koji je otklonjen za dostupna testna stanja informacionog okruženja, trebalo bi ga zasebno testirati za preostala potrebna stanja informacija okruženje.
Često se koristi i kombinacija testiranja odozdo prema gore i odozdo prema gore, što se naziva sendvič metoda. Suština ove metode leži u istovremenoj implementaciji testiranja naviše i naniže dok se ova dva procesa testiranja ne sretnu na nekom modulu negdje u sredini strukture programa koji se otklanja. Ova metoda omogućava, uz razuman pristup, da se iskoriste prednosti testiranja odozdo prema gore i odozgo prema dolje i u velikoj mjeri neutraliziraju njihove nedostatke. Ovaj efekat je manifestacija opšti princip: najveći tehnološki učinak može se postići kombinacijom metoda od vrha prema dolje i odozdo prema gore u razvoju OS programa. Arhitektonski pristup razvoju softvera namenjen je podršci ovoj metodi (videti predavanje 7): sloj dobro dizajniranih i pažljivo testiranih modula u velikoj meri olakšava implementaciju porodice programa u odgovarajućoj predmetnoj oblasti i njihovu kasniju modernizaciju.
Veoma važno u offline otklanjanju grešaka je testiranje uparivanja modula. Činjenica je da se specifikacija svakog programskog modula, osim glavnog, koristi u ovom programu u dvije situacije: prvo, kada se razvija tekst (ponekad kažu: tijelo) ovog modula i, drugo, kada se piše apelirajte na ovaj modul u drugim programskim modulima. U oba slučaja, kao rezultat greške, potrebna usklađenost sa datom specifikacijom modula može biti narušena. Takve greške treba otkriti i ispraviti. Ovo je svrha testiranja uparivanja modula. U testiranju odozgo prema dolje, testiranje uparivanja se provodi usput sa svakim preskočenim testom, što se smatra najjačom prednošću top-down testiranja. Tokom testiranja odozdo prema gore, modulu za otklanjanje grešaka pristupa se ne iz modula programa koji se otklanja grešaka, već iz vodećeg modula za otklanjanje grešaka. S tim u vezi, postoji opasnost da se posljednji modul prilagodi nekim "pogrešnim shvatanjima" modula koji se otklanja greške. Stoga je prilikom pokretanja (u procesu integracije programa) otklanjanja grešaka novog modula potrebno testirati svaki poziv prethodno debagovanog modula kako bi se otkrile nedosljednosti između ovog poziva i tijela odgovarajućeg modula (a moguće je da za to je kriv prethodno otklonjeni modul). Dakle, potrebno je djelomično ponoviti testiranje prethodno debagovanog modula pod novim uvjetima, a javljaju se iste poteškoće kao i u slučaju top-down testiranja.
Autonomno testiranje modula treba izvršiti u četiri uzastopna koraka.
Korak 1: Na osnovu specifikacije modula koji otklanjate greške, pripremite test za svaku mogućnost i situaciju, za svaku granicu raspona svih ulaza, za svaki raspon promjena podataka, za svaki nevažeći raspon svih ulaza i svaki nevažeće stanje.
Korak 2. Provjerite tekst modula kako biste bili sigurni da će svaki smjer bilo koje grane proći barem jedan test. Dodajte testove koji nedostaju.
Korak 3. Provjerite iz teksta modula da za svaku petlju postoji test za koji se tijelo petlje ne izvršava, test za koji se tijelo petlje izvršava jednom i test za koji se tijelo petlje izvršava maksimalni broj puta. Dodajte testove koji nedostaju.
Korak 4. Provjerite je li tekst modula osjetljiv na pojedinačne posebne ulazne vrijednosti podataka - sve takve vrijednosti treba da budu uključene u testove. Dodajte testove koji nedostaju.
10.5. Kompleksno otklanjanje grešaka u softveru.
Kao što je već spomenuto, uz složeno otklanjanje grešaka, testira se PS kao cjelina i pripremaju se testovi za svaki od PS dokumenata. Testiranje ovih dokumenata obično se vrši obrnutim redoslijedom od njihovog razvoja (jedini izuzetak je testiranje dokumentacije aplikacije koja se razvija prema vanjskom opisu paralelno sa razvojem programskih tekstova; ovo testiranje je najbolje uraditi nakon testiranja eksterni opis je završen). Testiranje u složenom otklanjanju grešaka je primjena PS-a na određene podatke koji, u principu, mogu proizaći od korisnika (posebno, svi testovi su pripremljeni u obliku dizajniranom za korisnika), ali moguće u simuliranom (a ne stvarnom) okruženje. Na primjer, neki ulazni i izlazni uređaji koji su nedostupni tokom složenog otklanjanja grešaka mogu se zamijeniti njihovim softverskim simulatorima.
Testiranje PS arhitekture. Svrha testiranja je pronaći neslaganje između opisa arhitekture i skupa programa PS-a. Dok testiranje PS arhitekture počne, autonomno otklanjanje grešaka svakog podsistema bi već trebalo biti završeno. Greške u implementaciji arhitekture mogu se prvenstveno povezati sa interakcijom ovih podsistema, posebno sa implementacijom arhitektonskih funkcija (ako ih ima). Stoga bih želio provjeriti sve načine interakcije između PS podsistema. Ali pošto ih može biti previše, bilo bi poželjno testirati barem sve izvršne lance podsistema bez ponovnog ulaska potonjeg. Ako data arhitektura predstavlja PS kao mali sistem odabranih podsistema, onda će broj takvih lanaca biti prilično vidljiv.
Testiranje vanjske funkcije. Svrha testiranja je pronalaženje neslaganja između funkcionalne specifikacije i skupa softverskih programa PS-a. Unatoč činjenici da su svi ovi programi već neovisno otklonjeni, ova neslaganja mogu biti, na primjer, zbog neusklađenosti između internih specifikacija programa i njihovih modula (na osnovu kojih je provedeno autonomno testiranje) i eksterne funkcionalne specifikacije MS. U pravilu se testiranje eksternih funkcija vrši na isti način kao i testiranje modula u prvom koraku, tj. kao crna kutija.
PS ispitivanje kvaliteta. Svrha testiranja je traženje kršenja zahtjeva kvaliteta formuliranih u specifikaciji kvaliteta PS. Ovo je najteža i najmanje proučavana vrsta testiranja. Jasno je samo da se svaki primitiv kvaliteta PS ne može testirati testiranjem (vidi sljedeće predavanje o procjeni kvaliteta PS). Kompletnost PS-a se provjerava već prilikom testiranja vanjskih funkcija. U ovoj fazi, testiranje ovog primitiva kvaliteta može se nastaviti ako je potrebno da se dobije bilo kakva probabilistička procjena stepena pouzdanosti PS-a. Međutim, metodologiju za takvo testiranje tek treba razviti. Može se testirati tačnost, robusnost, sigurnost, vremenska efikasnost, efikasnost memorije do neke mere, efikasnost uređaja, proširivost i, delimično, nezavisnost uređaja. Svaka od ovih vrsta testiranja ima svoje specifičnosti i zaslužuje posebnu pažnju. Ovdje ćemo se ograničiti na njihovo nabrajanje. Lakoća upotrebe PS-a (kriterijum kvaliteta koji uključuje nekoliko primitiva kvaliteta, vidi predavanje 4) se vrednuje prilikom testiranja dokumentacije o upotrebi PS-a.
Ispitna dokumentacija o primjeni PS. Svrha testiranja je traženje nedosljednosti između dokumentacije o aplikaciji i seta softverskih programa, kao i neugodnosti korištenja softvera. Ova faza neposredno prethodi korisnikovom povezivanju sa završetkom razvoja PS-a (testiranje zahtjeva za PS i sertifikacija PS-a), tako da je vrlo važno da programeri prvo sami iskoriste PS na način na koji će to korisnik učiniti to. Svi testovi u ovoj fazi pripremaju se isključivo na osnovu dokumentacije o primeni PS. Prije svega, potrebno je testirati mogućnosti softvera kao što je to urađeno prilikom testiranja eksternih funkcija, ali samo na osnovu dokumentacije aplikacije. Sva nejasna mjesta u dokumentaciji treba testirati, kao i sve primjere korištene u dokumentaciji. Zatim se testiraju najteži slučajevi primjene PS-a kako bi se otkrilo kršenje zahtjeva za relativnost lakoće upotrebe PS-a.
Testiranje definicije zahtjeva za PS. Svrha testiranja je da se utvrdi u kojoj mjeri softver ne odgovara predstavljenoj definiciji zahtjeva za njega. Posebnost ovog tipa testiranja je u tome što ga sprovodi nabavna organizacija ili korisnička organizacija PS kao jedan od načina za prevazilaženje barijere između programera i korisnika (videti predavanje 3). Obično se ovo testiranje provodi uz pomoć kontrolnih zadataka - tipičnih zadataka za koje je poznat rezultat rješenja. U slučajevima kada razvijeni PS treba zamijeniti drugu verziju PS-a koja rješava barem dio zadataka razvijenog PS-a, testiranje se provodi rješavanjem uobičajenih problema korištenjem starog i novog PS-a, nakon čega slijedi poređenje rezultata. dobijeno. Ponekad se kao oblik takvog testiranja koristi probni rad PS-a – ograničena primjena novog PS-a uz analizu korištenja rezultata u praksi. U suštini, ova vrsta ispitivanja ima mnogo zajedničkog sa ispitivanjem PS-a tokom njegove sertifikacije (videti predavanje 14), ali se izvodi pre sertifikacije, a ponekad i umesto sertifikacije.
Literatura za predavanje 10.
10.1. G. Myers. Pouzdanost softvera. - M.: Mir, 1980. - S. 171-262.
10.2. D. Van Tassel. Stil, razvoj, efikasnost, programi za otklanjanje grešaka i testiranje. - M.: Mir, 1985. - S. 179-295.
10.3. J. Hughes, J. Michtom. Strukturalni pristup na programiranje. - M.: Mir, 1980. - S. 254-268.
10.4. J. Fox. Softver i njegov razvoj. - M.: Mir, 1985. - S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. Principi razvoja softvera. - M.: Mir, 1982. - S. 105-116.
10.6. Yu.M. Bezborodov. Individualno otklanjanje grešaka u programima. - M.: Nauka, 1982. - S. 9-79.
10.7. V.V. Lipaev. Testiranje programa. - M.: Radio i komunikacija, 1986. - S. 15-47.
10.8. E.A. Zhogolev. Uvod u tehnologiju programiranja (napomene sa predavanja). - M.: "DIJALOG-MGU", 1994.
10.9. E. Dijkstra. Napomene o strukturiranom programiranju. //U. Dahl, E. Dijkstra, K. Hoor. Strukturno programiranje. - M.: Mir, 1975. - S. 7-13.
Predavanje 11
11.1. Funkcionalnost i pouzdanost kao obavezni kriterijumi kvaliteta softvera.
U prethodnim predavanjima razmatrali smo sve faze razvoja PS, osim njegove sertifikacije. Istovremeno, nismo se dotakli pitanja osiguranja kvaliteta PS u skladu sa njegovom specifikacijom kvaliteta (vidjeti predavanje 4). Istina, pri implementaciji funkcionalne specifikacije PS-a, razgovarali smo o glavnim pitanjima osiguranja kriterija funkcionalnosti. Proglasivši pouzdanost softvera kao njegov glavni atribut (vidjeti predavanje 1), odabrali smo prevenciju grešaka kao glavni pristup za osiguranje pouzdanosti softvera (vidjeti predavanje 3) i razgovarali o njegovoj implementaciji u različitim fazama razvoja softvera. Tako se manifestovala teza o obaveznoj funkcionalnosti i pouzdanosti PS kao kriterijuma za njen kvalitet.
Međutim, specifikacija kvaliteta softvera može sadržati dodatne karakteristike ovih kriterijuma, čije obezbeđivanje zahteva posebnu raspravu. Ova pitanja su u fokusu ovog predavanja. O osiguranju drugih kriterija kvaliteta bit će riječi u sljedećem predavanju.
Omogućavanje primitiva kvaliteta MS-a koji izražavaju kriterije za funkcionalnost i pouzdanost MS-a razmatra se u nastavku.
11.2. Osiguravanje kompletnosti softvera.
Kompletnost PS-a je opšti primitiv kvaliteta PS-a za izražavanje funkcionalnosti i pouzdanosti PS-a, a za funkcionalnost je jedini primitiv (vidi predavanje 4).
Funkcionalnost PS-a određena je njegovom funkcionalnom specifikacijom. Potpunost PS-a kao primitiva njegovog kvaliteta je mjera kako je ova specifikacija implementirana u datom PS-u. Pružanje ovog primitiva u potpunosti znači implementaciju svake od funkcija definiranih u funkcionalnoj specifikaciji, sa svim detaljima i karakteristikama koje su tamo naznačene. Svi prethodno razmotreni tehnološki procesi pokazuju kako se to može učiniti.
Međutim, u specifikaciji kvaliteta PS-a može se definirati nekoliko razina implementacije funkcionalnosti PS-a: može se definirati neka pojednostavljena (početna ili početna) verzija, koja se mora implementirati prva, a može se definirati i nekoliko međuverzija. U ovom slučaju nastaje dodatni tehnološki problem: organizacija povećanja funkcionalnosti PS. Ovdje je važno napomenuti da razvoj pojednostavljene verzije PS-a nije razvoj njegovog prototipa. Prototip se razvija kako bi se bolje razumjeli uslovi za korištenje budućeg PS-a, kako bi se razjasnio njegov vanjski opis. Dizajniran je za odabrane korisnike i stoga se može uvelike razlikovati od potrebnog PS-a ne samo po funkcijama koje se izvršavaju, već i po karakteristikama korisničkog interfejsa. Pojednostavljena verzija potrebnog PS-a treba biti dizajnirana za praktičnu upotrebu od strane svih korisnika kojima je namijenjena. Stoga je glavni princip za osiguranje funkcionalnosti takvog OS-a razvijati OS od samog početka na način kao da je potreban cijeli OS, sve dok se programeri ne pozabave tim dijelovima ili detaljima OS-a, implementacijom koji se može odgoditi prema svojoj specifikaciji kvaliteta. Dakle, i eksterni opis i opis PS arhitekture moraju biti razvijeni u potpunosti. Moguće je odgoditi samo implementaciju onih softverskih podsistema definisanih u arhitekturi razvijenog PS-a, čije funkcionisanje nije potrebno u početnoj verziji ovog PS-a. Implementaciju samih softverskih podsistema najbolje je izvršiti metodom svrsishodne konstruktivne implementacije, ostavljajući u početnoj verziji PS prikladne simulatore onih softverskih modula koji u ovoj verziji nisu potrebni. Pojednostavljena implementacija nekih softverskih modula je također prihvatljiva, izostavljajući implementaciju nekih detalja odgovarajućih funkcija. Međutim, s tehnološke točke gledišta, bolje je takve module smatrati njihovim originalnim imitatorima (iako daleko naprednim).
Zbog grešaka u razvijenom PS-u, postignuta kompletnost u obezbjeđivanju njegove funkcionalnosti (u skladu sa specifikacijom njegovog kvaliteta) zapravo možda neće biti onakva kakva se očekivala. Možemo samo reći da je ova kompletnost postignuta sa određenom vjerovatnoćom, određenom obimom i kvalitetom testiranja. Da bi se ova vjerovatnoća povećala, potrebno je nastaviti testiranje i otklanjanje grešaka na PS-u. Međutim, procjena takve vjerovatnoće je vrlo specifičan zadatak (uzimajući u obzir činjenicu da je ispoljavanje greške u PS u funkciji početnih podataka), koji još uvijek čeka odgovarajuća teorijska istraživanja.
11.3. Osiguravanje tačnosti softverskog alata.
Pružanje ovog primitiva povezano je s operacijama nad vrijednostima realnih tipova (tačnije, sa vrijednostima predstavljenim s nekom greškom). Osigurati potrebnu tačnost prilikom izračunavanja vrijednosti određene funkcije znači dobiti ovu vrijednost s greškom koja ne prelazi navedene granice. Vrste grešaka, metode za njihovu procjenu i metode za postizanje potrebne tačnosti (tzv. aproksimativni proračuni) bavi se računskom matematikom. Ovdje samo obraćamo pažnju na određenu strukturu greške: zavisi od greške izračunate vrijednosti (ukupne greške).
o grešci korištene metode proračuna (u koju uključujemo netačnost korištenog modela),
od greške u prezentaciji korišćenih podataka (od tzv. fatalne greške),
od greške zaokruživanja (netačnost u izvršavanju operacija koje se koriste u metodi).
11.4. Osiguravanje autonomije softvera.
Ovaj primitiv kvaliteta se obezbeđuje u fazi specifikacije kvaliteta donošenjem odluke da li da se koristi bilo koji odgovarajući osnovni softver u razvijenom PS ili da se u njemu ne koristi bilo koji osnovni softver. Pri tome je potrebno voditi računa i o njegovoj pouzdanosti i o resursima potrebnim za njegovo korištenje. Uz povećane zahtjeve za pouzdanošću razvijene PS, pouzdanost osnovnog softvera koji je dostupan programerima može se pokazati nezadovoljavajućom, stoga se njegova upotreba mora napustiti, a implementacija njegovih funkcija u potrebnom obimu mora biti uključena u PS. Slične odluke se moraju donositi pod strogim ograničenjima u pogledu korišćenih resursa (prema kriterijumu efikasnosti PS).
11.5. Osiguravanje održivosti softvera.
Ovaj kvalitetan primitiv je obezbeđen uz pomoć takozvanog defanzivnog programiranja. Uopšteno govoreći, defanzivno programiranje se koristi za poboljšanje pouzdanosti MS-a pri programiranju modula u širem smislu. Kao što Myers kaže, "Odbrambeno programiranje se zasniva na važnoj premisi: najgora stvar koju modul može učiniti je prihvatiti loš unos, a zatim vratiti netačan, ali uvjerljiv rezultat." Kako bi se to izbjeglo, tekst modula uključuje provjere njegovih ulaznih i izlaznih podataka na njihovu ispravnost u skladu sa specifikacijom ovog modula, posebno ispunjenje ograničenja na ulazne i izlazne podatke i međusobne odnose naveden u specifikaciji modula treba provjeriti. U slučaju negativnog rezultata provjere, podiže se odgovarajući izuzetak. S tim u vezi, na kraju ovog modula uključeni su fragmenti druge vrste - rukovaoci odgovarajućih izuzetnih situacija, koji pored izdavanja neophodnih dijagnostičkih informacija mogu preduzeti mere ili za otklanjanje grešaka u podacima (npr. zahtijevaju da se ponovo unesu) ili da se ublaži utjecaj greške (na primjer, meko zaustavljanje uređaja koje kontrolira PS kako bi se izbjegao njihov kvar u slučaju hitnog prekida izvršavanja programa).
Upotreba zaštitnog programiranja modula dovodi do smanjenja efikasnosti PS-a kako u vremenu tako iu memoriji. Stoga je neophodno razumno regulisati stepen primjene odbrambenog programiranja, u zavisnosti od zahtjeva za pouzdanost i efikasnost PS, formuliranih u specifikaciji kvaliteta razvijene PS. Ulazni podaci razvijenog modula mogu doći ili direktno od korisnika ili iz drugih modula. Najčešći slučaj korištenja defanzivnog programiranja je njegovo korištenje za prvu grupu podataka, što znači ostvarenje stabilnosti PS-a. Ovo treba učiniti kad god specifikacija kvaliteta PS-a sadrži zahtjev da se osigura stabilnost PS-a. Upotreba defanzivnog programiranja za drugu grupu ulaznih podataka znači pokušaj otkrivanja greške u drugim modulima tokom izvršavanja razvijenog modula, a za izlazne podatke razvijenog modula pokušaj otkrivanja greške u samom modulu. tokom njegovog izvođenja. U suštini, to znači djelomičnu implementaciju pristupa samootkrivanja grešaka kako bi se osigurala pouzdanost softvera, o čemu je bilo riječi u predavanju 3. Ovaj slučaj odbrambenog programiranja se koristi izuzetno rijetko – samo kada su ispunjeni zahtjevi za pouzdanost softvera. su izuzetno visoke.
11.6. Osiguravanje sigurnosti softvera.
Postoje sljedeće vrste PS zaštite od izobličenja informacija:
zaštita od hardverskih kvarova;
zaštita od uticaja "stranog" programa;
zaštita od kvarova "vlastitog" programa;
zaštita od grešaka operatera (korisnika);
zaštita od neovlaštenog pristupa;
zaštita od zaštite.
Zaštita od hardverskih kvarova trenutno nije vrlo hitan zadatak (uzimajući u obzir postignuti nivo pouzdanosti računara). Ali ipak je korisno znati njeno rješenje. To se osigurava organizacijom takozvanih "dvostrukih-trostrukih pogrešnih proračuna". Da bi se to postiglo, cijeli proces obrade podataka, koji određuje PS, vremenski se dijeli na intervale takozvanim „referentnim tačkama“. Dužina ovog intervala ne bi trebalo da prelazi polovinu prosečnog vremena rada računara. Kopija stanja memorije promijenjenog u ovom procesu za svaku referentnu tačku upisuje se u sekundarnu memoriju sa nekim kontrolnim zbrojem (broj izračunatim kao funkcija ovog stanja) u slučaju kada će se smatrati da je obrada podataka iz prethodna referentna tačka za ovu (tj. jedna "pogrešna kalkulacija") je napravljena ispravno (bez kompjuterskih kvarova). Da bi se to saznalo, prave se dvije takve "pogrešne računice". Nakon prvog "izračunavanja", izračunava se i pohranjuje navedena kontrolna suma, a zatim se vraća stanje memorije za prethodnu referentnu tačku i vrši se drugo "kalkuliranje". Nakon drugog "pogrešnog izračuna", navedena kontrolna suma se ponovo izračunava, koja se zatim upoređuje sa kontrolnom sumom prve "pogrešne kalkulacije". Ako se ova dva kontrolna zbroja poklapaju, drugi proračun se smatra ispravnim, u suprotnom se pohranjuje i kontrolni zbroj drugog "izračunavanja" i izvodi se treći "kalkulacija" (sa preliminarnim vraćanjem stanja memorije za prethodnu referentnu tačku). Ako se kontrolna suma treće "pogrešne kalkulacije" poklapa sa kontrolnom sumom jedne od prva dva "pogrešna izračunavanja", tada se treća pogrešna kalkulacija smatra ispravnom, u suprotnom je potrebna inženjerska provjera računara.
Zaštita od uticaja "stranog" programa odnosi se prvenstveno na operativne sisteme ili programe koji djelimično obavljaju svoje funkcije. Postoje dvije vrste ove zaštite:
zaštita od kvara,
zaštita od zlonamernog uticaja "stranog" programa.
Kada se pojavi multiprogramski način rada računara, u njegovoj memoriji može istovremeno biti pokrenuto više programa, koji naizmenično primaju kontrolu kao rezultat prekida (tzv. kvaziparalelno izvršavanje programa). Jedan od ovih programa (obično: operativni sistem) upravlja prekidima i upravlja multiprogramiranjem. U svakom od ovih programa može doći do kvarova (pojavljuju se greške) koje mogu utjecati na performanse funkcija drugih programa. Stoga upravljački program (operativni sistem) mora zaštititi sebe i druge programe od takvog utjecaja. Da biste to učinili, hardver računara mora implementirati sljedeće karakteristike:
zaštita memorije,
dva načina rada računara: privilegovani i radni (korisnički),
dvije vrste transakcija: privilegovane i obične,
ispravna implementacija prekida i početnog pokretanja računara,
privremeni prekid.
Zaštita memorije znači mogućnost programskog postavljanja za svaki program područja memorije koja su mu nedostupna. U privilegovanom modu mogu se izvoditi sve operacije (i obične i privilegirane), a u načinu rada samo obične. Pokušaj izvođenja privilegirane operacije, kao i pristup zaštićenoj memoriji u radnom načinu, uzrokuje odgovarajući prekid. Štaviše, privilegovane operacije uključuju operacije za promjenu zaštite memorije i načina rada, kao i pristup vanjskom informacijskom okruženju. Prvo uključivanje računara i svaki prekid bi trebalo da automatski omoguće privilegovani režim i nadjačaju zaštitu memorije. U tom slučaju upravljački program (operativni sistem) može se u potpunosti zaštititi od utjecaja drugih programa, ako sve točke prijenosa kontrole pri početnom uključivanju i prekidima pripadaju ovom programu, ako ne dozvoljava rad nijednog drugog programa u privilegovani režim (kada se kontrola prenese na bilo koji drugi program će uključiti samo radni režim) i ako u potpunosti štiti svoju memoriju (koja sadrži, posebno, sve svoje kontrolne informacije, uključujući i tzv. prekidne vektore) od drugih programa. Tada ga niko neće spriječiti da obavlja bilo kakve zaštitne funkcije implementirane u njemu za druge programe (uključujući pristup vanjskom informacijskom okruženju). Da bi se olakšalo rješavanje ovog problema, dio takvog programa se stavlja u trajnu memoriju, tj. neodvojiv od samog kompjutera. Prisustvo privremenog prekida omogućava kontrolnom programu da se zaštiti od petlje u drugim programima (bez takvog prekida, jednostavno bi mogao izgubiti sposobnost kontrole).
Zaštita od kvarova „sopstvenog“ programa obezbeđena je pouzdanošću ovog programa, koji je u fokusu celokupne tehnologije programiranja o kojoj se govori u ovom kursu predavanja.
Zaštita od korisničkih grešaka (pored grešaka u unosu podataka, vidi osiguranje stabilnosti PS-a) obezbjeđuje se izdavanjem poruka upozorenja o pokušajima promjene stanja vanjskog informacionog okruženja sa zahtjevom za potvrdom ovih radnji, kao i mogućnošću vraćanja u prethodno stanje. stanje pojedinih komponenti eksternog informacionog okruženja. Potonji se zasniva na implementaciji arhiviranja promjena u stanju eksternog informacionog okruženja.
Zaštita od neovlašćenog pristupa je obezbeđena upotrebom tajnih reči (lozinki). U ovom slučaju, svakom korisniku se obezbjeđuju određeni informacijski i proceduralni resursi (usluge), za čije korištenje je potrebno unošenje lozinke PS-u, koji je ovaj korisnik prethodno registrovao u PS-u. Drugim riječima, korisnik, takoreći, "okači bravu" na resurse koji su mu dodijeljeni, "ključ" koji ima samo ovaj korisnik. Međutim, mogu se uporni pokušaji da se takva zaštita prekine u pojedinačnim slučajevima ako su zaštićeni resursi za nekoga od izuzetne vrijednosti. U tom slučaju moraju se poduzeti dodatne mjere za zaštitu od narušavanja sigurnosti.
Zaštita od narušavanja sigurnosti povezana je sa upotrebom posebnih tehnika programiranja u PS-u koje otežavaju prevazilaženje zaštite od neovlaštenog pristupa. Upotreba običnih lozinki nije dovoljna kada je u pitanju izuzetno uporna želja (na primjer, kriminalne prirode) za pristupom vrijednim informacijama. Prvo, zato što informacije o lozinkama koje PS koristi za zaštitu od neovlaštenog pristupa može relativno lako dobiti "kreker" ove zaštite ako ima pristup samom ovom PS-u. Drugo, pomoću računara moguće je izvršiti dovoljno veliku enumeraciju mogućih lozinki kako bi se pronašla odgovarajuća za pristup informacijama od interesa. Od takvog haka možete se zaštititi na sljedeći način. Tajna riječ (lozinka) ili samo tajni cijeli broj X je poznat samo vlasniku zaštićene informacije, a za provjeru prava pristupa u računar se pohranjuje još jedan broj Y=F(X), koji je jedinstveno izračunat od strane PS svaki put kada se pokuša pristupiti ovim informacijama nakon predstavljanja tajne riječi. Istovremeno, funkcija F može biti dobro poznata svim korisnicima PS-a, ali ima takvo svojstvo da je vraćanje riječi X iz Y praktički nemoguće: s dovoljno velikom dužinom riječi X (na primjer, nekoliko stotina znakova ), za ovo je potrebno astronomsko vrijeme. Takav broj Y će se zvati elektronski (kompjuterski) potpis vlasnika tajne riječi X (a samim tim i zaštićene informacije).
Druga vrsta takve zaštite odnosi se na zaštitu poruka koje se šalju preko računarskih mreža, od namjernog (ili zlonamjernog) izobličenja. Takva poruka može biti presretnuta na "pretovarnim" tačkama računarske mreže i zamijenjena drugom porukom autora presretnute poruke. Ovakva situacija nastaje prvenstveno u realizaciji bankarskih poslova korišćenjem računarske mreže. Zamjenom takve poruke, a to je nalog vlasnika bankovnog računa za obavljanje neke bankarske operacije, novac sa njegovog računa može se prebaciti na račun "hakerske" zaštite (vrsta kompjuterske pljačke banke). Zaštita od takve povrede sigurnosti može se izvršiti na sljedeći način. Uz funkciju F, koja određuje kompjuterski potpis vlasnika tajne riječi X, koja je poznata primaocu zaštićene poruke (ako je samo njen vlasnik klijent ovog primatelja), definirana je još jedna funkcija Stamp u PS, iz kojeg pošiljalac poruke mora izračunati broj S=Stamp(X,R) koristeći tajnu riječ X i tekst poslane poruke R. Funkcija Stamp se također smatra dobro poznatom svim korisnicima MS-a i ima takve svojstvo da je praktično nemoguće povratiti broj X iz S, ili odabrati drugu poruku R sa odgovarajućim kompjuterskim potpisom. Sama poslana poruka (zajedno sa njenom zaštitom) bi trebala izgledati ovako:
štaviše, Y (kompjuterski potpis) omogućava primaocu da utvrdi istinu klijenta, a S, takoreći, vezuje zaštićenu poruku R sa kompjuterskim potpisom Y. U tom smislu, broj S ćemo nazvati elektronskim (računarski ) pečat. PS definira još jednu notarsku funkciju, prema kojoj primalac zaštićene poruke provjerava istinitost poslane poruke:
Ovo vam omogućava da nedvosmisleno utvrdite da poruka R pripada vlasniku tajne riječi X.
Zaštita od zaštite je neophodna u slučaju da je korisnik zaboravio (ili izgubio) svoju lozinku. U takvom slučaju, trebalo bi omogućiti da poseban korisnik (PS administrator) odgovoran za funkcionisanje sistema zaštite privremeno ukloni zaštitu od neovlaštenog pristupa za vlasnika zaboravljena lozinka kako bi mu se dala prilika da popravi novu lozinku.
Literatura za predavanje 11.
11.1. I.S. Berezin, N.P. Zhidkov. Metode proračuna, vol. 1 i 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bakhvalov, N.P. Židkov, G.M. Kobelkov. Numeričke metode. - M.: Nauka, 1987.
11.3. G. Myers. Pouzdanost softvera. - M.: Mir, 1980. S. 127-154.
11.4. A.N. Lebedev. Zaštita bankarskih informacija i moderna kriptografija//Pitanja informacione sigurnosti, 2(29), 1995.
Predavanje 12. Osiguranje kvaliteta softvera
12.1. Opće karakteristike procesa osiguranja kvaliteta softvera.
Kao što je već navedeno u Predavanju 4, specifikacija kvaliteta definiše glavne smjernice (ciljeve) koje u svim fazama razvoja PS na ovaj ili onaj način utiču na izbor odgovarajuće opcije pri donošenju različitih odluka. Međutim, svaki kvalitetni primitiv ima svoje karakteristike takvog uticaja, tako da obezbeđivanje njegovog prisustva u PS može zahtevati sopstvene pristupe i metode za razvoj PS ili njegovih pojedinačnih delova. Osim toga, uočena je i nekonzistentnost kriterija kvalitete PS-a i primitiva kvaliteta koji ih izražavaju: dobro obezbjeđenje jednog od primitiva kvaliteta PS-a može značajno zakomplicirati ili onemogućiti pružanje nekih drugih od ovih primitiva. Stoga se suštinski dio procesa osiguranja kvaliteta PS sastoji od pronalaženja prihvatljivih kompromisa. Ove kompromise treba djelimično definirati već u specifikaciji kvaliteta PS-a: model kvaliteta PS-a treba specificirati potreban stepen prisutnosti u PS-u svakog od njegovih primitiva kvaliteta i odrediti prioritete za postizanje ovih stupnjeva.
Osiguranje kvaliteta provodi se u svakom tehnološkom procesu: odluke koje se donose u njemu, u jednoj ili drugoj mjeri, utiču na kvalitet softvera u cjelini. Posebno zato što je značajan dio kvalitetnih primitiva povezan ne toliko sa svojstvima programa uključenih u PS, već sa svojstvima dokumentacije. Zbog uočene nedosljednosti kvalitetnih primitiva, vrlo je važno pridržavati se odabranih prioriteta u njihovom pružanju. Ali u svakom slučaju, korisno je pridržavati se dva opća principa:
prvo je potrebno osigurati potrebnu funkcionalnost i pouzdanost PS, a zatim preostale kriterijume kvaliteta dovesti na prihvatljiv nivo njihovog prisustva u PS;
nema potrebe, a može biti čak i štetno, tražiti viši nivo prisutnosti u PS-u bilo kakvog primitivnog kvaliteta od onog definiranog u specifikaciji kvaliteta PS-a.
Osiguranje funkcionalnosti i pouzdanosti PS-a razmatrano je u prethodnom predavanju. U nastavku se govori o obezbjeđivanju drugih kriterija kvaliteta OS.
12.2.. Osiguravanje jednostavnosti korištenja softverskog alata
P-dokumentacija PS-a određuje sastav korisničke dokumentacije
U prethodnom predavanju je već razmatrano obezbeđivanje dva od pet kvalitetnih primitiva (stabilnost i sigurnost) koji određuju jednostavnost korišćenja PS-a.
P-dokumentacija i informativnost određuju sastav i kvalitet korisničke dokumentacije (vidi sljedeće predavanje).
Komunikacija se osigurava stvaranjem odgovarajućeg korisnički interfejs i odgovarajuće rukovanje izuzetkom. U čemu je problem?
12.3. Osiguravanje efikasnosti softvera.
Efikasnost PS-a osigurava se donošenjem odgovarajućih odluka u različitim fazama njegovog razvoja, počevši od razvoja njegove arhitekture. Izbor strukture podataka i prezentacije posebno snažno utiče na efikasnost PS-a (posebno u smislu memorije). Ali izbor algoritama koji se koriste u određenim softverskim modulima, kao i karakteristike njihove implementacije (uključujući izbor programskog jezika) mogu značajno uticati na efikasnost PS-a. U isto vrijeme, stalno se mora rješavati kontradikcija između vremenske efikasnosti i efikasnosti iz sjećanja. Zbog toga je veoma važno da specifikacija kvaliteta eksplicitno naznači kvantitativni odnos između indikatora ovih primitiva kvaliteta, ili da barem postavi kvantitativne granice za jedan od ovih indikatora. Pa ipak, različiti softverski moduli imaju različit učinak na efikasnost PS-a u cjelini: kako u smislu njihovog doprinosa ukupnim troškovima PS-a u smislu vremena i memorije, tako i u smislu utjecaja na različite primitive kvalitete. (neki moduli mogu snažno uticati na postizanje vremenske efikasnosti i praktično ne utiču na efikasnost memorije, dok drugi mogu značajno uticati na ukupnu potrošnju memorije bez značajnog uticaja na vreme rada PS-a). Štaviše, ovaj uticaj (prvenstveno u smislu vremenske efikasnosti) unapred (pre završetka implementacije PS) ne može se uvek ispravno proceniti.
prvo morate razviti pouzdan PS, a tek onda postići njegovu potrebnu efikasnost u skladu sa specifikacijom kvaliteta ovog PS-a;
za poboljšanje efikasnosti PS-a, prije svega, koristite optimizirajući kompajler - to može osigurati potrebnu efikasnost;
ako postignuta efikasnost PS-a ne zadovoljava specifikaciju njegovog kvaliteta, onda pronaći najkritičnije module u smislu potrebne efikasnosti PS-a (u slučaju vremenske efikasnosti, to će zahtijevati dobijanje distribucije po modulima PS-a vrijeme rada odgovarajućim mjerenjima u toku izvođenja PS); ove module i pokušajte ih prvo optimizirati tako što ćete ih ručno modificirati;
nemojte optimizirati modul ako nije potreban za postizanje potrebne efikasnosti PS-a.
12.4. Osiguravanje mogućnosti održavanja.
C-dokumentacija, sadržaj informacija i razumljivost određuju sastav i kvalitet dokumentacije za održavanje (vidi sljedeće predavanje). Osim toga, mogu se dati sljedeće preporuke u vezi sa tekstovima programa (modula).
koristiti komentare u tekstu modula koji pojašnjavaju i objašnjavaju karakteristike odluka koje se donose; ako je moguće, uključite komentare (barem u kratkom obliku) u najranijoj fazi razvoja teksta modula;
koristiti smislena (mnemonička) i uporno prepoznatljiva imena (optimalna dužina imena je 4-12 slova, brojevi su na kraju), ne koristiti slična imena i ključne riječi;
budite oprezni kada koristite konstante (jedinstvena konstanta mora imati jedno pojavljivanje u tekstu modula: kada je deklarirana ili, u ekstremnim slučajevima, kada je varijabla inicijalizirana kao konstanta);
nemojte se bojati koristiti opcione zagrade (zagrade su jeftinije od grešaka;
ne stavljajte više od jedne izjave u red; da biste razjasnili strukturu modula, koristite dodatne razmake (uvlake) na početku svakog reda;
izbjegavajte trikove tj. takav tehnike programiranja, kada se kreiraju fragmenti modula čiji glavni efekat nije očigledan ili skriven (prikriven), kao što su nuspojave .
Proširivost je osigurana kreiranjem odgovarajućeg instalatera.
Strukturiranost i modularnost pojednostavljuju kako razumijevanje programskih tekstova tako i njihovu modifikaciju.
12.5. Osiguravanje mobilnosti.
Literatura za predavanje 12.
12.1. Ian Somerville. Softverski inženjering. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Stil, razvoj, efikasnost, programi za otklanjanje grešaka i testiranje. - M.: Mir, 1985. S. 8-44, 117-178.
12.4. Korisnička dokumentacija softvera/ANSI/IEEE standard 1063-1987.
Predavanje 13
13.1. Dokumentacija nastala tokom procesa razvoja softvera.
Prilikom razvoja PS-a stvara se velika količina raznovrsne dokumentacije. Neophodan je kao sredstvo za prenos informacija između programera PS-a, kao sredstvo upravljanja razvojem PS-a i kao sredstvo za prenošenje korisnicima informacija potrebnih za primenu i održavanje PS-a. Izrada ove dokumentacije čini veliki dio troškova PS-a.
Ova dokumentacija se može podijeliti u dvije grupe:
Dokumenti za upravljanje razvojem PS.
Dokumenti uključeni u PS.
Dokumenti upravljanja razvojem PS (procesna dokumentacija) bilježe procese razvoja i održavanja PS-a, obezbjeđujući komunikaciju unutar razvojnog tima i između razvojnog tima i menadžera (menadžera) - osoba koje rukovode razvojem. Ovi dokumenti mogu biti sljedećih vrsta:
Planovi, predračuni, rasporedi. Ove dokumente kreiraju menadžeri za predviđanje i upravljanje procesima razvoja i održavanja.
Izvještaji o korištenju resursa tokom razvoja. Kreirali menadžeri.
Standardi. Ovi dokumenti propisuju programerima koje principe, pravila, sporazume moraju poštovati u procesu razvoja PS-a. Ovi standardi mogu biti ili međunarodni ili nacionalni, ili posebno kreirani za organizaciju u kojoj se ovaj PS razvija.
Radna dokumenta. Ovo su glavni tehnički dokumenti koji pružaju komunikaciju između programera. Sadrže fiksiranje ideja i problema koji se javljaju tokom procesa razvoja, opis strategija i pristupa koji se koriste, kao i radne (privremene) verzije dokumenata koje treba uključiti u PS.
Bilješke i prepiska. Ovi dokumenti obuhvataju različite detalje interakcije između menadžera i programera.
Dokumenti uključeni u PS (dokumentacija proizvoda) opisuju PS programe kako sa stanovišta njihove upotrebe od strane korisnika, tako i sa stanovišta njihovih programera i održavatelja (u skladu sa svrhom PS-a). Ovdje treba napomenuti da će se ovi dokumenti koristiti ne samo u fazi rada PS-a (u fazi njegove primjene i održavanja), već iu fazi razvoja za upravljanje procesom razvoja (zajedno sa radnim dokumentima) - u bilo kojem U slučaju, treba ih provjeriti (testirati) na usklađenost sa PS programima. Ovi dokumenti čine dva seta sa različitim svrhama:
PS korisnička dokumentacija (P-dokumentacija).
Dokumentacija za podršku PS (C-dokumentacija).
13.2. Korisnička dokumentacija softvera.
Korisnička dokumentacija PS-a (korisnička dokumentacija) objašnjava korisnicima kako moraju postupiti da bi primijenili ovaj PS. Neophodan je ako PS uključuje bilo kakvu interakciju sa korisnicima. Takva dokumentacija uključuje dokumente koji usmjeravaju korisnika prilikom instaliranja PS-a (prilikom instaliranja PS-a s odgovarajućom postavkom za okruženje za korištenje PS-a), kada koristi PS za rješavanje svojih problema i kada upravlja PS-om (na primjer, kada ovaj PS u interakciji sa drugim sistemima). Ovi dokumenti djelimično pokrivaju pitanja softverske podrške, ali se ne bave pitanjima vezanim za modifikaciju programa.
U tom smislu treba razlikovati dvije kategorije korisnika PS-a: obične PS korisnike i PS administratore. Običan korisnik PS-a (krajnji korisnik) koristi PS za rješavanje svojih problema (u svojoj predmetnoj oblasti). To može biti inženjer koji dizajnira tehnički uređaj ili blagajnik koji prodaje karte za vlak koristeći PS. Možda ne zna mnogo detalja o radu računara ili principima programiranja. PS administrator (administrator sistema) upravlja korištenjem PS-a od strane običnih korisnika i pruža podršku PS-u koja nije povezana sa modifikacijom programa. Na primjer, može regulirati prava pristupa OS-u između običnih korisnika, komunicirati sa OS provajderima ili izvoditi određene radnje da bi OS održao u radnom stanju ako je uključen kao dio drugog sistema.
Sastav korisničke dokumentacije zavisi od publike korisnika kojoj je ovaj PS namenjen i od načina korišćenja dokumenata. Pod publikom se ovdje podrazumijeva kontingent korisnika PS-a, koji ima potrebu za određenom korisničkom dokumentacijom PS-a. Uspješan korisnički dokument u suštini ovisi o preciznoj definiciji publike kojoj je namijenjen. Korisnička dokumentacija treba da sadrži informacije potrebne za svaku publiku. Način upotrebe dokumenta odnosi se na način na koji se dokument koristi. Obično, korisnik dovoljno velikih softverskih sistema zahteva bilo koji dokument da bi proučio PS (upotreba u instrukcije), ili da razjasnimo neke informacije (koristite kao referencu).
U skladu s radovima, tipičnim se može smatrati sljedeći sastav korisničke dokumentacije za dovoljno velike PS:
Opšti funkcionalni opis PS. Daje kratak opis funkcionalnosti PS-a. Namijenjen je korisnicima koji moraju odlučiti koliko im je potreban ovaj PS.
PS Vodič za instalaciju. Dizajniran za sistem administratore. Trebalo bi detaljno propisati kako instalirati sisteme u određenom okruženju. Sadrži opis mašinski čitljivog medija na kojem se isporučuje MS, datoteke koje predstavljaju MS i zahtjeve za minimalnu konfiguraciju hardvera.
Uputstvo za upotrebu PS. Dizajniran za obične korisnike. Sadrži potrebne informacije o primjeni PS, organizovane u obliku pogodnom za njegovo proučavanje.
Priručnik o primjeni PS. Dizajniran za obične korisnike. Sadrži potrebne informacije o primjeni PS-a, organizirane u obliku pogodnom za selektivno pretraživanje pojedinačnih detalja.
Vodič za upravljanje PS. Dizajniran za sistem administratore. Trebalo bi opisati poruke koje se generiraju kada MS stupi u interakciju s drugim sistemima i kako odgovoriti na te poruke. Osim toga, ako MS koristi sistemski hardver, ovaj dokument može objasniti kako održavati taj hardver.
Kao što je ranije spomenuto (vidjeti predavanje 4), razvoj korisničke dokumentacije počinje odmah nakon kreiranja eksternog opisa. Kvalitet ove dokumentacije može značajno odrediti uspjeh PS-a. Trebao bi biti prilično jednostavan i prilagođen korisniku (inače, ovaj PS, općenito, nije vrijedio kreirati). Stoga, iako nacrte (nacrte) korisničkih dokumenata kreiraju glavni programeri PS-a, profesionalni tehnički pisci često su uključeni u kreiranje njihovih konačnih verzija. Osim toga, kako bi se osigurala kvaliteta korisničke dokumentacije, razvijen je niz standarda (vidi npr.), koji propisuju proceduru izrade ove dokumentacije, formulišu zahtjeve za svaku vrstu korisničkih dokumenata i određuju njihovu strukturu i sadržaj. .
13.3. Dokumentacija za softversku podršku.
Dokumentacija za održavanje PS (sistemska dokumentacija) opisuje PS sa stanovišta njegovog razvoja. Ova dokumentacija je neophodna ako PS uključuje proučavanje načina na koji je uređen (dizajniran) i modernizaciju njegovih programa. Kao što je navedeno, održavanje je u toku. Stoga, ukoliko je potrebno nadograditi PS, u ovaj posao se uključuje poseban tim pratećih programera. Ovaj tim će morati da se bavi istom dokumentacijom koja je određivala aktivnosti tima početnih (glavnih) programera PS-a, s tom razlikom što će ta dokumentacija po pravilu biti tuđa za razvojni tim održavaoca ( kreirao ga je drugi tim). Tim za održavanje će morati proučiti ovu dokumentaciju kako bi razumio strukturu i razvojni proces nadograđene PS, te izvršio potrebne izmjene u ovoj dokumentaciji, ponavljajući u velikoj mjeri tehnološke procese po kojima je originalna PS nastala.
Dokumentacija o podršci PS može se podijeliti u dvije grupe:
(1) dokumentaciju koja definiše strukturu programa i strukture podataka PS i tehnologiju za njihov razvoj;
(2) dokumentaciju koja pomaže u izmjenama PS-a.
Dokumentacija prve grupe sadrži završne dokumente svake tehnološke faze razvoja PS. Uključuje sljedeće dokumente:
Eksterni opis PS (dokument sa zahtjevima).
Opis sistemske arhitekture PS-a, uključujući eksternu specifikaciju svakog od njegovih programa.
Za svaki PS program, opis njegove modularne strukture, uključujući eksternu specifikaciju za svaki modul uključen u njega.
Za svaki modul - njegova specifikacija i opis njegove strukture (opis dizajna).
Tekstovi modula u odabranom programskom jeziku (listine izvornog koda programa).
Dokumenti za validaciju OS koji opisuju kako je ustanovljena valjanost svakog OS programa i kako su informacije o validaciji povezane sa zahtjevima za OS.
Dokumenti za verifikaciju softvera prvenstveno uključuju dokumentaciju o testiranju (dizajn testa i opis kompleta testova), ali mogu uključivati i rezultate drugih vrsta provjere valjanosti softvera, kao što su dokazi svojstava programa.
Dokumentacija druge grupe sadrži
Vodič za održavanje sistema, koji opisuje poznate probleme zajedno sa softverom, opisuje koji dijelovi sistema zavise od hardvera i softvera i kako se razvoj softvera uzima u obzir u njegovoj strukturi (dizajnu).
Uobičajeni problem održavanja za PS je osigurati da sve njegove reprezentacije drže korak (ostaju dosljedne) kada se PS promijeni. Da bi se to pomoglo, odnosi i zavisnosti između dokumenata i njihovih dijelova moraju biti zarobljeni u bazi podataka upravljanja konfiguracijom.
Literatura za predavanje 13.
13.1. Ian Somerville. Softverski inženjering. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE Standard za softversku korisničku dokumentaciju.
13.3. ANSI/IEEE Std 830-1984, IEEE vodič za specifikaciju softverskih zahtjeva.
13.4. ANSI/IEEE Std 1016-1987, IEEE preporučena praksa za opis dizajna softvera.
13.5. ANSI/IEEE Std 1008-1987, IEEE standard za testiranje jedinica softvera.
13.6. ANSI/IEEE Std 1012-1986, IEEE standard za planove za verifikaciju i validaciju softvera.
13.7. ANSI/IEEE Std 983-1986, IEEE Vodič za planiranje osiguranja kvaliteta softvera.
13.8. ANSI/IEEE Std 829-1983, IEEE standard za dokumentaciju o testiranju softvera.
Predavanje 14
Imenovanje sertifikacije softvera. Testiranje i evaluacija kvaliteta softvera. Vrste testova i metode za procjenu kvaliteta softvera.
14.1. Imenovanje sertifikacije softvera.
PS certifikat je mjerodavna potvrda kvaliteta PS. Obično se za sertifikaciju softverskog sistema formira predstavnička (atestaciona) komisija koju čine stručnjaci, predstavnici kupca i predstavnici programera. Ova komisija vrši ispitivanja PS-a kako bi dobila potrebne informacije za procjenu njegovog kvaliteta. Pod testom PS podrazumevamo proces sprovođenja skupa mera kojima se ispituje podobnost PS za njegov uspešan rad (primenu i održavanje) u skladu sa zahtevima kupca. Ovaj kompleks uključuje provjeru kompletnosti i tačnosti softverske dokumentacije, proučavanje i razmatranje njegovih ostalih svojstava, kao i neophodno testiranje programa uključenih u softverski paket, a posebno usklađenost ovih programa sa dostupnom dokumentacijom.
Na osnovu informacija dobijenih tokom testiranja PS-a, prije svega, mora se utvrditi da PS obavlja deklarirane funkcije, a takođe se mora utvrditi u kojoj mjeri PS ima deklarirane primitive i kriterije kvaliteta. Stoga je procjena kvaliteta PS glavni sadržaj procesa sertifikacije. Ocjena kvaliteta PS evidentira se u odgovarajućoj odluci atestacione komisije.
14.2. Vrste testiranja softvera.
Poznate su sljedeće vrste PS testova koji se sprovode u svrhu certifikacije PS:
Ispitivanje PS komponenti;
sistemski testovi;
testovi prihvatanja;
terenska ispitivanja;
industrijska ispitivanja.
Testiranje komponenti PS-a je provjera (testiranje) operativnosti pojedinih podsistema PS-a. Održavaju se samo u izuzetnim slučajevima posebnom odlukom atestacione komisije.
Sistemsko testiranje PS-a je provjera (testiranje) operativnosti PS-a u cjelini. Može uključivati iste vrste testiranja kao u složenom otklanjanju grešaka PS-a (vidi predavanje 10). Izvodi se odlukom komisije za atestiranje, ako postoje sumnje u kvalitet otklanjanja grešaka od strane programera PS-a.
Prijemni testovi su glavna vrsta testova za sertifikaciju PS. Ovim testovima počinje rad certifikacijske komisije. Ovi testovi počinju proučavanjem dostavljene dokumentacije, uključujući dokumentaciju o testiranju i otklanjanju grešaka PS-a. Ukoliko dokumentacija ne sadrži dovoljno potpune rezultate testiranja softvera, komisija za sertifikaciju može odlučiti da sprovede sistemsko testiranje softvera ili da prekine proces sertifikacije uz preporuku programeru da sprovede dodatno (potpunije) testiranje softvera. Osim toga, tokom ovih testova mogu se selektivno preskočiti testovi programera, kao i zadaci korisničke kontrole (vidjeti predavanje 10) i dodatni testovi koje priprema komisija za procjenu kvaliteta certificiranog PS.
Terensko testiranje PS je demonstracija PS zajedno sa tehničkim sistemom koji kontroliše ovaj PS uskom krugu kupaca u realnim uslovima, a ponašanje PS se pažljivo prati. Kupcima treba dati mogućnost da sami postavljaju svoje testne slučajeve, posebno od izlaza do kritičnih režima rada tehničkog sistema, kao i sa pozivom za vanredne situacije u njemu. Radi se o dodatnim ispitivanjima koja se po odluci atestacione komisije vrše samo za neke BM koje kontrolišu određene tehničke sisteme.
Industrijsko ispitivanje PS je proces prenošenja PS u stalni rad korisnicima. To je period probnog rada PS (vidjeti predavanje 10) od strane korisnika uz prikupljanje informacija o ponašanju PS i njegovim operativnim karakteristikama. Ovo su završna ispitivanja PS koja se sprovode odlukom atestacione komisije, ukoliko su tokom prethodnih ispitivanja dobijene nedovoljno potpune ili pouzdane informacije za ocjenu kvaliteta certificiranog PS.
14.3. Metode za procjenu kvaliteta softvera.
Procjena kvaliteta PS za svaki od kriterija svodi se na ocjenu svakog od primitiva povezanih sa ovim kriterijem kvaliteta PS, u skladu sa njihovom specifikacijom, sačinjenom u specifikaciji kvaliteta ovog PS. Metode za procjenu primitiva kvalitete PS-a mogu se podijeliti u četiri grupe:
direktno mjerenje primitivnih indikatora kvaliteta;
obrada programa i dokumentacije PS posebnim softverskim alatima (procesorima);
testiranje PS programa;
stručna ocjena na osnovu studija programa i dokumentacije PS.
Direktno mjerenje primitivnih pokazatelja kvaliteta vrši se prebrojavanjem broja pojavljivanja u pojedinom programskom dokumentu karakterističnih jedinica, objekata, konstrukcija itd., kao i mjerenjem vremena rada razni uređaji i količinu zauzete računarske memorije tokom izvršavanja test slučajeva. Na primjer, neka mjera efikasnosti memorije može biti broj redova programa u programskom jeziku, a neka mjera vremenske efikasnosti može biti vrijeme odgovora na upit. Upotreba bilo kojeg indikatora za primitive kvaliteta može se definirati u specifikaciji kvaliteta MS. Metoda direktnog mjerenja primitivnih indikatora kvaliteta može se kombinirati sa korištenjem programskog testiranja.
Određeni softverski alati se mogu koristiti da se utvrdi da li MS ima određene primitive kvaliteta. Takvi softverski alati obrađuju programske tekstove ili softversku dokumentaciju kako bi kontrolisali sve primitive kvaliteta ili dobili neke indikatore ovih primitiva kvaliteta. Za procjenu strukturiranosti PS programa, ako su programirani na odgovarajućem strukturnom dijalektu osnovnog programskog jezika, bilo bi dovoljno proći ih kroz strukturirani programski pretvarač koji vrši sintaksičku i određenu semantičku kontrolu ovog dijalekta i prevodi tekstove ove programe na ulazni jezik osnovnog prevodioca. Međutim, samo mali broj kvalitetnih primitiva trenutno se može kontrolirati na ovaj način, i to u rijetkim slučajevima. U nekim slučajevima, umjesto softverskih alata koji kontroliraju kvalitetu softvera, korisnije je koristiti alate koji transformiraju prezentaciju programa ili programske dokumentacije. Takav je, na primjer, program za formatiranje koji tekstove programa dovodi u čitljivu formu - obrada tekstova PS programa takvim alatom može automatski osigurati da PS ima odgovarajući kvalitetan primitiv.
Testiranje se koristi za procjenu nekih primitiva PS kvaliteta. Takvi primitivi prvenstveno uključuju kompletnost PS-a, kao i njegovu tačnost, stabilnost, sigurnost i druge kvalitetne primitive. U nekim slučajevima, testiranje se koristi u kombinaciji s drugim metodama za procjenu pojedinačnih primitiva PS kvaliteta. Dakle, za procjenu kvaliteta dokumentacije o korištenju PS (P-dokumentacija), testiranje se koristi u kombinaciji sa stručnom ocjenom ove dokumentacije. Ako je tokom složenog otklanjanja grešaka PS-a obavljeno dovoljno kompletno testiranje, tada se isti testovi mogu koristiti i prilikom certifikacije PS-a. U ovom slučaju, komisija za sertifikaciju može koristiti protokole testiranja koji se obavljaju tokom složenog otklanjanja grešaka. Međutim, čak iu ovom slučaju potrebno je izvršiti neke nove testove ili barem ponovno pokrenuti neke od starih. Ako se utvrdi da testiranje tokom složenog otklanjanja grešaka nije dovoljno kompletno, tada je potrebno provesti potpunije testiranje. U tom slučaju može se donijeti odluka da se sprovedu testovi komponenti ili sistemski testovi PS-a, kao i da se PS vrati programerima na reviziju. Vrlo je važno da se za procjenu PS-a prema kriteriju jednostavnosti korištenja (tokom otklanjanja grešaka i certificiranja PS-a) izvrši potpuno testiranje na testovima pripremljenim na osnovu dokumentacije za aplikaciju, a prema na kriterij održivosti - na testovima pripremljenim za svaki od dokumenata predloženih za održavanje PS.
Za procjenu većine primitiva kvaliteta PS trenutno se može koristiti samo metoda ekspertske procjene. Ova metoda se sastoji u sledećem: imenuje se grupa veštaka, svaki od ovih veštaka, kao rezultat proučavanja dostavljene dokumentacije, sačinjava mišljenje o posedovanju PS zahtevanog primitivnog kvaliteta, a zatim vrši procenu zahtevanog kvaliteta. kvalitetan primitiv PS-a utvrđuje se glasanjem članova ove grupe. Ova procena se može izvršiti i po sistemu od dve tačke ("poseduje" - "nema"), i uzeti u obzir stepen posedovanja PS od strane ovog kvalitetnog primitiva (na primer, može se izvršiti na pet -bod sistem). Istovremeno, ekspertska grupa treba da se rukovodi specifikacijom ovog primitiva i naznakom metode za njegovu procenu, formulisanu u specifikaciji kvaliteta sertifikovanog PS.
Literatura za predavanje 14.
14.2. V.V. Lipaev. Testiranje programa. - M.: Radio i komunikacija, 1986. - S. 231-245.
14.3. D. Van Tassel. Stil, razvoj, efikasnost, programi za otklanjanje grešaka i testiranje. - M.: Mir, 1985. - S. 281-283.
14.4. B. Schneiderman. Psihologija programiranja. - M.: Radio i komunikacija, 1984. - S. 99-127.
Predavanje 15. Objektni pristup razvoju softvera
15.1. Objekti i odnosi u programiranju. Suština objektnog pristupa razvoju softvera.
Svijet oko nas sastoji se od objekata i odnosa među njima. Objekt utjelovljuje neki entitet i ima neko stanje koje se može promijeniti tokom vremena kao rezultat utjecaja drugih objekata koji su na neki način s podacima. Može imati unutrašnju strukturu: može se sastojati od drugih objekata koji su također u nekom međusobnom odnosu. Polazeći od toga, moguće je izgraditi hijerarhijsku strukturu svijeta od objekata. Međutim, za svako konkretno razmatranje svijeta oko nas neki objekti se smatraju nedjeljivim („tačka“), a ovisno o ciljevima razmatranja, takvi (nedjeljivi) objekti različitih nivoa hijerarhije mogu biti prihvaćeni. Relacija povezuje neke objekte: možemo smatrati da unija ovih objekata ima neko svojstvo. Ako relacija povezuje n objekata, onda se takva relacija naziva n-mjesto (n-arno). Na svakom mjestu asocijacije objekata koji se mogu povezati bilo kojim specifičnim odnosom mogu biti različiti objekti, ali sasvim određeni (u ovom slučaju kažu: objekti određene klase). Relacija jednog mjesta naziva se svojstvom objekta (odgovarajuće klase). Stanje objekta može se proučavati kroz vrijednost svojstava ovog objekta ili implicitno kroz vrijednost svojstava unija objekata povezanih zajedno sa datom jednom ili drugom relacijom.
U procesu upoznavanja ili mijenjanja svijeta oko sebe uvijek uzimamo u obzir jedan ili drugi pojednostavljeni model svijeta (model svijeta), u koji uključujemo neke od objekata i neke od odnosa svijeta oko nas i, po pravilu, jedan nivo hijerarhije. Svaki objekat koji ima unutrašnju strukturu može predstavljati svoj svet modela, uključujući objekte ove strukture i odnose koji ih povezuju. Stoga se svijet oko nas može smatrati (u određenoj aproksimaciji) hijerarhijskom strukturom modelnih svjetova.
Trenutno, u procesu učenja ili mijenjanja svijeta oko nas, kompjuterska tehnologija se široko koristi za obradu različitih vrsta informacija. U tom smislu se koristi kompjuterska (informaciona) reprezentacija objekata i relacija. Svaki objekat može biti informativno predstavljen nekom strukturom podataka koja prikazuje njegovo stanje. Svojstva ovog objekta mogu se postaviti direktno kao zasebne komponente ove strukture, ili pomoću posebnih funkcija na ovoj strukturi podataka. N-arne relacije za N>1 mogu biti predstavljene u aktivnom ili pasivnom obliku. U svom aktivnom obliku, relacija N-mjesta je predstavljena nekim programskim fragmentom koji implementira ili funkciju N-mjesta (određivanje vrijednosti svojstva odgovarajuće unije objekata) ili proceduru koja mijenja stanja nekih od njih na osnovu o stanju reprezentacija objekata povezanih predstavljenom relacijom. U pasivnom obliku, takva relacija može biti predstavljena određenom strukturom podataka (koja može uključivati reprezentacije objekata povezanih ovom relacijom), interpretiranom na osnovu prihvaćenih sporazuma o općim procedurama koje su neovisne o specifičnim odnosima (npr. relacione baze podataka). U oba slučaja, predstavljanje odnosa definira neke aktivnosti obrade podataka.
Kada istražuje svijet modela, korisnik može primati (ili želi primati) informacije od računara na različite načine. U jednom pristupu, on može biti zainteresiran za dobivanje informacija o pojedinačnim svojstvima objekata koji ga zanimaju ili o rezultatima bilo kakve interakcije između nekih objekata. Da bi to uradio, on naređuje razvoj jednog ili drugog PS-a koji obavlja funkcije od interesa za njega, ili nekog informacionog sistema koji može da izda informacije o odnosima od interesa za njega, koristeći odgovarajuću bazu podataka. U početnom periodu razvoja računarske tehnologije (sa nedovoljno velikom snagom računara) ovakav pristup upotrebi računara bio je sasvim prirodan. On je bio taj koji je izazvao funkcionalni (relacijski) pristup razvoju PS-a, o čemu je detaljno bilo riječi u prethodnim predavanjima. Suština ovog pristupa je sistematska upotreba dekompozicije funkcija (relacija) za izgradnju strukture PS-a i programskih tekstova koji su u njega uključeni. Istovremeno, sami objekti, na koje su primijenjene naručene i implementirane funkcije, predstavljeni su fragmentarno (u mjeri potrebnoj za obavljanje ovih funkcija) i u obliku pogodnom za realizaciju ovih funkcija. Dakle, nije pružena potpuna i adekvatna kompjuterska reprezentacija svijeta modela od interesa za korisnika: njegovo prikazivanje na korištenom PS-u moglo bi se pokazati kao prilično naporan zadatak za korisnika, pokušaj da se malo proširi volumen i priroda informacije o svijetu modela od interesa za korisnika. dobijene od takve trafostanice mogle bi dovesti do njihove ozbiljne modernizacije. Ovaj pristup razvoju PS-a podržava većina korišćenih programskih jezika, počevši od asemblerskih jezika i proceduralni jezici(Fortran, Pascal) na funkcionalne jezike (LISP) i logičke programske jezike (PROLOG).
Sa drugim pristupom proučavanju svijeta modela korištenjem kompjutera, korisnik može biti zainteresiran da promatra promjenu stanja objekata kao rezultat njihove interakcije. Ovo zahteva prilično solidnu reprezentaciju u računaru objekta od interesa za korisnika, a softverske komponente koje implementiraju odnose u kojima ovaj objekat učestvuje su eksplicitno povezane sa njim. Za implementaciju ovog pristupa bilo je potrebno izgraditi softverske alate koji simuliraju procese interakcije između objekata (svijet modela). Uz pomoć tradicionalnih razvojnih alata, pokazalo se da je to prilično naporan zadatak. Istina, pojavili su se programski jezici koji su posebno fokusirani na takvo modeliranje, ali to je samo djelomično pojednostavilo zadatak razvoja potrebnog PS-a. Najpotpunije rješenje ovog problema je objektni pristup razvoju PS-a. Njegova suština je u sistematskoj upotrebi dekompozicije objekata u konstrukciji strukture PS-a i tekstova programa koji su u njega uključeni. Istovremeno, funkcije (relacije) koje obavlja takav PS izražavale su se kroz odnose objekata različitih nivoa, odnosno njihova je dekompozicija značajno zavisila od dekompozicije objekata.
Govoreći o objektnom pristupu, treba jasno razumjeti o kakvim se objektima radi: o objektima svijeta modela korisnika, njihovoj informacijskoj reprezentaciji, programskim objektima sa kojima je izgrađen PS. Osim toga, treba razlikovati stvarne objekte ("pasivni" objekti) i subjekte ("aktivni" objekti).
15.2. Objekti i subjekti u programiranju.
15.3. Objektivni i subjektivni pristupi razvoju softvera.
Descartes je primijetio da ljudi obično imaju objektno orijentisan pogled na svijet (c).
Oni vjeruju da se objektno orijentirani dizajn zasniva na principima:
isticanje apstrakcija,
Ograničenje pristupa,
modularnost,
hijerarhija,
kucanje,
paralelizam,
održivost.
Ali sve se to može primijeniti u funkcionalnom pristupu.
Neophodno je razlikovati prednosti i nedostatke opšteg objektnog pristupa i njegovog posebnog slučaja - predmetno orijentisanog pristupa.
Prednosti pristupa opšteg cilja:
Prirodno mapiranje stvarnog svijeta na strukturi PS (prirodna ljudska percepcija sposobnosti PS-a, nema potrebe za "izmišljanjem" PS strukture, već se koriste prirodne analogije).
Upotreba dovoljno smislenih strukturnih jedinica PS-a (objekat kao integritet neredundantnih asocijacija, informacijski jaki moduli).
Smanjenje složenosti razvoja softvera korištenjem novog nivoa apstrakcija (koristeći hijerarhiju „neprogramskih“ apstrakcija u razvoju softvera: klasifikacija objekata stvarnog svijeta, metoda analogija u prirodi) kao novi nivo nasleđe.
15.4. Objektni pristup razvoju eksternog opisa i softverske arhitekture.
Objektno orijentirani dizajn je metoda koja koristi dekompoziciju objekata; objektno orijentisani pristup ima svoj sistem simboli i nudi bogat skup logičkih i fizičkih modela za dizajn sistema visok stepen teškoće. .
Objektno orijentirana analiza (OOA) prikazala je objektni pristup. OOA ima za cilj stvaranje modela koji su bliži stvarnosti koristeći objektno orijentirani pristup; to je metodologija u kojoj se zahtjevi formiraju na osnovu koncepata klasa i objekata koji čine vokabular predmetne oblasti. .
Karakteristike objektno orijentisanog programiranja.
Objekti, klase, ponašanje objekta, svojstva, događaji.
Literatura za predavanje 15.
15.1. K. Futi, N. Suzuki. Programski jezici i VLSI kola. - M.: Mir, 1988. S. 85-98.
15.2. Ian Somerville. Softverski inženjering. - Addison-Wesley Publishing Company, 1992. P. ?-?
15.3. G. Butch. Objektno orijentirani dizajn s primjerima primjene: per. sa engleskog. - M.: Konkord, 1992.
15.4. V.Sh.Kaufman. Programski jezici. Koncepti i principi. Moskva: Radio i komunikacija, 1993.

Predavanje 8. Razvoj softverskog modula

8.1. Postupak razvoja softverskog modula.

8.2. Strukturno programiranje.

8.3. Detaljne informacije korak po korak i koncept pseudokoda.

8.4. Kontrola softverskog modula.

Literatura za predavanje 8.

Predavanje 9

9.1. Programska opravdanja. Formalizacija svojstava programa.

9.2. Svojstva jednostavnih operatora.

9.3. Svojstva osnovnih struktura strukturnog programiranja.

9.4. Završetak izvođenja programa.

9.5. Primjer dokaza svojstva programa.

Literatura za predavanje 9.

Predavanje 10

10.1. Osnovni koncepti.

10.2. Principi i vrste otklanjanja grešaka.

10.3. Naredbe za otklanjanje grešaka.

10.4. Offline modul za otklanjanje grešaka.

10.5. Kompleksno otklanjanje grešaka u softveru.

Literatura za predavanje 10.

Predavanje 11

11.1. Funkcionalnost i pouzdanost kao obavezni kriterijumi kvaliteta softvera.

11.2. Osiguravanje kompletnosti softvera.

11.3. Osiguravanje tačnosti softverskog alata.

11.4. Osiguravanje autonomije softvera.

11.5. Osiguravanje održivosti softvera.

11.6. Osiguravanje sigurnosti softvera.

Literatura za predavanje 11.

Predavanje 12. Osiguranje kvaliteta softvera

12.1. Opće karakteristike procesa osiguranja kvaliteta softvera.

12.3. Osiguravanje efikasnosti softvera.

Literatura za predavanje 12.

Predavanje 13

13.1. Dokumentacija nastala tokom procesa razvoja softvera.

13.2. Korisnička dokumentacija softvera.

Literatura za predavanje 13.

Predavanje 14

14.1. Imenovanje sertifikacije softvera.

14.2. Vrste testiranja softvera.

14.3. Metode za procjenu kvaliteta softvera.

Predavanje 15. Objektni pristup razvoju softvera

15.1. Objekti i odnosi u programiranju. Suština objektnog pristupa razvoju softvera.

15.2. Objekti i subjekti u programiranju.

15.3. Objektivni i subjektivni pristupi razvoju softvera.

15.4. Objektni pristup razvoju eksternog opisa i softverske arhitekture.

Literatura za predavanje 15.