Zhvillimi i moduleve softuerike për sistemet kompjuterike. Programi i punës së praktikës së trajnimit për modulin profesional "zhvillimi i moduleve softuerike për sistemet kompjuterike" Zhvillimi i moduleve softuerike

MINISTRIA E ARSIMIT DHE SHKENCËS

REPUBLIKA POPULLORE DONETSK

PROFESIONAL I SHTETIT

INSTITUCION ARSIMOR

"KOLEGJI INDUSTRIALE DHE EKONOMIK DONETSK"

PROGRAMI I PUNËS

Praktika arsimore UP.01

moduli profesional PM.01 Zhvillimi i moduleve softuerike software për sistemet kompjuterike

specialiteti 09.02.03 "Programimi në sistemet kompjuterike"

Përpiluar nga:

Volkov Vladimir Aleksandrovich, mësues i disiplinave kompjuterike të kategorisë së kualifikimit "specialist i kategorisë më të lartë", Institucioni Arsimor Shtetëror "Kolegji Industrial dhe Ekonomik Donetsk"

Programi është miratuar nga: Vovk Pavel Andreevich, Drejtor i "Smart IT Service"


1. PASAPORTA E PROGRAMIT TË PRAKTIKËS
2. REZULTATET E PRAKTIKËS
3. STRUKTURA DHE PËRMBAJTJA E PRAKTIKËS
4. KUSHTET PËR ORGANIZIM DHE KRYERJE PRAKTIKE
5. MONITORIMI DHE VLERËSIMI I REZULTATEVE TË PRAKTIKËS

1 PASAPORTË E PROGRAMIT TË PRAKTIKËS ARSIMORE LARTË. 01

1.1 Vendi i praktikës së trajnimit UP.01

Programi i praktikës arsimore UP.01 i modulit profesional PM.01 "Zhvillimi i moduleve softuerike për sistemet kompjuterike" specialiteti 09.02.03 "Programimi në sistemet kompjuterike » grupi i zgjeruar 09.00.00 "Shkenca kompjuterike dhe teknologjia kompjuterike", në drejtim të zotërimit të llojit kryesor të veprimtarisë profesionale (VPD):

Zhvillimi i moduleve softuerike për sistemet kompjuterike dhe kompetencat profesionale përkatëse (PC):

	Kryeni zhvillimin e specifikimeve për komponentët individualë.
	Kryeni zhvillimin e kodit produkt software bazuar në specifikimet e gatshme në nivel moduli.
	Kryeni korrigjimin e moduleve të programit duke përdorur mjete të specializuara softuerike.
	Kryerja e testimit të moduleve të softuerit.
	Kryeni optimizimin kodi i programit modul.
	Zhvillimi i komponentëve të projektimit dhe dokumentacionit teknik duke përdorur gjuhët e specifikimeve grafike.

Programi i praktikës arsimore UP.01 i modulit profesional PM.01 "Zhvillimi i moduleve softuerike për sistemet kompjuterike" mund të përdoret në edukimin profesional shtesë dhe aftësimin profesional të punonjësve për specialitete 09.02.03 Programimi në sistemet kompjuterike me një të mesme (të plotë ) arsimi i përgjithshëm. Eksperienca e punës nuk kërkohet.

1.2 Qëllimet dhe objektivatpraktika arsimore UP.01

Për të zotëruar llojin e caktuar të veprimtarisë profesionale dhe kompetencat përkatëse profesionale, studenti gjatë praktikës arsimore UP.01 duhet:

të ketë përvojë praktike:

zhvillimi i algoritmit të detyrës dhe zbatimi i tij me anë të projektimit me kompjuter;

zhvillimi i një kodi produkti të softuerit bazuar në një specifikim të përfunduar në nivelin e modulit;

përdorimi i mjeteve në fazën e korrigjimit të një produkti softuer;

testimi i një moduli softueri sipas një skenari specifik;

te jesh i afte te:

të kryejë zhvillimin e kodit të modulit të programit në gjuhët moderne të programimit;

krijoni një program sipas algoritmit të zhvilluar si një modul i veçantë;

korrigjimi dhe testimi i programit në nivelin e modulit;

hartoni dokumentacionin e softuerit;

përdorni mjete për të automatizuar përgatitjen e dokumentacionit;

di:

fazat kryesore të zhvillimit të softuerit;

parimet bazë të teknologjisë së programimit strukturor dhe të orientuar nga objekti;

parimet bazë të korrigjimit dhe testimit të produkteve softuerike;

metodat dhe mjetet e zhvillimit të dokumentacionit teknik.

1.3 Numri i javëve(orë) për zhvillimin e programitpraktika arsimore UP.01

Vetëm 1.5 javë, 54 orë.

2 REZULTATET E PRAKTIKËS

Rezultati i praktikës arsimore UP.01 të modulit profesional PM.01 “Zhvillimi i moduleve softuerike për sistemet kompjuterike” është zhvillimi i kompetencave të përgjithshme (OK):

	Emri i rezultatit të praktikës
	-
OK 2. Organizojnë aktivitetet e tyre, zgjedhin metoda dhe metoda standarde për kryerjen e detyrave profesionale, vlerësojnë efektivitetin dhe cilësinë e tyre.
OK 3. Merrni vendime në situata standarde dhe jo standarde dhe jini përgjegjës për to.
OK 4. Kërkoni dhe përdorni informacionin e nevojshëm për zbatimin efektiv të detyrave profesionale, zhvillimin profesional dhe personal.
OK 5. Përdorni teknologjitë e informacionit dhe komunikimit në aktivitetet profesionale.
OK 6. Punoni në ekip dhe në ekip, komunikoni në mënyrë efektive me kolegët, menaxhmentin, konsumatorët.
OK 7. Merrni përgjegjësi për punën e anëtarëve të ekipit (vartësve), për rezultatin e kryerjes së detyrave.	-
	kualifikimet
OK 9. Lundroni në kushtet e ndryshimit të shpeshtë të teknologjive në veprimtarinë profesionale.

kompetencat profesionale (PC):

Lloji i veprimtarisë profesionale		Emri i rezultateve të praktikës
Zotërimi i llojit kryesor të veprimtarisë profesionale		përdorimi i burimeve të rrjeteve kompjuterike lokale dhe globale; administrimi i skedarëve të të dhënave në pajisjet e ruajtjes lokale, të lëvizshme, si dhe në disqet e një rrjeti kompjuterik lokal dhe në internet; printimi, përsëritja dhe kopjimi i dokumenteve në një printer dhe pajisje të tjera zyre. kontrollin aktual në formën e një raporti për çdo punë praktike. provimi kualifikues i modulit.
		shkrim-leximi dhe saktësia e punës në programet aplikative: redaktorët e tekstit dhe grafika, bazat e të dhënave, redaktor i prezantimit; shpejtësia e kërkimit të informacionit në përmbajtjen e bazave të të dhënave.
		saktësinë dhe cilësimet e shkrim-leximit Email, softueri i serverit dhe klientit: shpejtësia e kërkimit të informacionit duke përdorur teknologjitë dhe shërbimet e internetit; saktësinë dhe shkrim-leximin e futjes dhe transmetimit të informacionit duke përdorur teknologjitë dhe shërbimet e internetit.
		shkrim e këndim në përdorimin e metodave dhe mjeteve për mbrojtjen e informacionit nga aksesi i paautorizuar; korrektësinë dhe saktësinë Rezervo kopje dhe rikuperimi i të dhënave;
		shkrim-leximi dhe saktësia e punës me sistemet e skedarëve, formatet e ndryshme të skedarëve, programet e menaxhimit të skedarëve;
		mirëmbajtjen e raporteve dhe dokumentacionit teknik.

3 STRUKTURA DHE PËRMBAJTJA E PROGRAMITPRAKTIKA TRAJNIMORE UP.01

3.1 Plani tematik

Kodet e kompetencave të krijuara

Emri i modulit profesional

Shtrirja kohore, caktuar për praktikë

(në javë, orë)

Datat

PC 1.1 - PC 1.6

PM.01 "Zhvillimi i moduleve softuerike për sistemet kompjuterike"

1.5 javë

54 orë

3.2 Përmbajtja praktike

Aktivitetet	Llojet e punëve		Emri i disiplinave akademike, kurse ndërdisiplinore që tregojnë tema, sigurimin e kryerjes së llojeve të punës	Numri i orëve (javë)
“Përvetësimi i llojit kryesor të veprimtarisë profesionale »	Tema 1. Prezantimi. Algoritme për zgjidhjen e problemeve. Struktura e algoritmit linear. Struktura e algoritmit ciklik. Algoritmi i një nënprogrami (funksioni).	Formuar njohuri mbi bazat e krijimit të objekteve të veçanta
	Tema2 . Mjedisi Skratch (Gërvishtje).	Njohuri të formuara mbi bazat e mjeteve të automatizimit të procesit Njohuri të formuara mbi bazat e efekteve të animimit tek objektet; përdorimi i lidhjeve dhe butonave; konfigurim demo; prezantime të ruajtura në formate të ndryshme.	MDK.01.01 "Programimi i sistemit"
	Tema 3 . Krijimi i një programi trajnimi (mësim nga lënda).	Njohuri të formuara mbi bazat e analizës së të dhënave duke përdorur funksionet e procesorit	MDK.01.02 "Programimi i aplikuar"
	Tema 4. Zhvillimi i programit të lojës.	Njohuri të formuara mbi bazat e llogaritjes së karakteristikave përfundimtare	MDK.01.01 "Programimi i sistemit"
	Tema 5. Gjuhe programimi grafik LabVIEW.	Njohuri të formuara mbi bazat e krijimit të një testi të procesorit.	MDK.01.02 "Programimi i aplikuar"
	Tema 6. Ndërtimi i një aplikacioni duke përdorur LabVIEW.	Njohuri të formuara për bazat e dialogut të përdoruesit me sistemin	MDK.01.02 "Programimi i aplikuar"
	Tema 7 Ripërdorimi i një fragmenti të programit.	Njohuri të formuara për operatorët dhe funksionet e sistemit.	MDK.01.02 "Programimi i aplikuar"
	Tema 8 Punëtori në LabVIEW. Mbrojtja e punës kur punoni me kompjuter në vendin e punës së përdoruesit.	Formohen njohuritë kompjuterike funksionet elementare. Njohuri të formuara për mbrojtjen e punës.	MDK.01.02 “Programimi i aplikuar”. OP.18 "Mbrojtja e punës"
	Tema 9 konkluzione. Përpilimi i një raporti praktik.	Formohen shkathtësitë e analizës së teknologjive kompjuterike, zgjidhja e problemeve.Formohen aftësitë.	MDK.01.01 "Programimi i sistemit" MDK.01.02 "Programimi i aplikuar" MDK.04.01 "Software zyre"

4 KUSHTET E ORGANIZIMIT DHE KRYERJES

PRAKTIKA ARSIMORE LARTË. 01

4.1 Kërkesat për Dokumentacion, të nevojshme për praktikë:

Programi i punës praktika arsimore UP.01 e modulit profesional PM.01. "Zhvillimi i moduleve softuerike për sistemet kompjuterike" është pjesë e programit të trajnimit për specialistë të nivelit të mesëm nga Institucioni Arsimor Profesional Shtetëror "Kolegji Industrial dhe Ekonomik Donetsk" në përputhje me standardin arsimor shtetëror të arsimit të mesëm profesional në specialitetin 09.02.03 "Programimi në sistemet kompjuterike", i themeluar në kurrikula në specialitet, programi i punës në disiplinat MDK.01.01 "Programimi i sistemit", MDK01.02 "Programimi i aplikuar", rekomandimet metodologjike për mbështetjen edukative dhe metodologjike për praktikën e nxënësve që përvetësojnë programet arsimore të arsimit të mesëm profesional.

4.2 Kërkesat për mbështetjen edukative dhe metodologjike të praktikës:

një listë e detyrave të miratuara sipas llojit të punës, udhëzime për studentët për kryerjen e punës, rekomandime për zbatimin e raporteve të praktikës.

4.3 Kërkesat e Logjistikës:

organizimi i praktikës industriale kërkon praninë e klasave dhe laboratorëve.

Pajisjet e zyrës dhe vendet e punës:

vendet sipas numrit të nxënësve (tavolinë, kompjuter, karrige);

vendi i punës së mësuesit (tavolinë, kompjuter, karrige);

kabinet për ruajtjen e mjeteve mësimore dhe bartësve të informacionit;

detyra për një qasje individuale ndaj të mësuarit, organizimi i punës dhe ushtrimeve të pavarura, një student në kompjuter;

literaturë referuese dhe metodike;

një grup sistemesh, aplikacionesh dhe programesh trajnimi për PC në media optike dhe elektronike;

ditar i udhëzimit të studentëve për mbrojtjen e punës;

një grup mjetesh mësimore.

Mjetet e trajnimit teknik:

bordi i klasës;

kompjuter personal me softuer të licencuar;

printer lazer;

PC arsimore;
grup i pajisjeve interaktive (projektor, ekran, altoparlantë);
Mjete për shuarjen e zjarrit (fikse zjarri).

Pajisjet e kabinetit dhe stacionet e punës së mjeteve të zhvillimit: kompjuterë personalë (monitor, njësi sistemi, tastierë, miu), një grup dokumentacioni arsimor dhe metodologjik, softuer në përputhje me përmbajtjen e disiplinës (predha gjuhë programimi).

Të gjithë kompjuterët në klasë janë të lidhur me rrjet lokal, keni akses në ruajtjen e informacionit në rrjet dhe keni akses në internet.

Pajisjet e komunikimit:

adaptorë rrjeti;

kabllot e rrjetit;

Pajisjet me valë WiFi.

Komponentët për instalimin e rrjeteve, pajisjet për instalim.

4.4 Lista e botimeve edukative, Burimet e internetit, literaturë shtesë

Burimet kryesore:

Olifer V.G. Sistemet operative të rrjetit: një libër shkollor për universitetet / V.G. Olifer, N.A. Olifer. - Botimi i 2-të. - Shën Petersburg: Peter, 2009,2008. - 668 f.:

E. Tanenbaum. Sistemet Operative. Zhvillimi dhe zbatimi. Shën Petersburg: Piter, 2006. - 568 f.

Pupkov K.A. Zotërimi i sistemit operativ Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moskë: Radio dhe komunikim, 1994. - 112 f.

L. Beck Hyrje në programimin e sistemit - M.: Mir, 1988.

Grekul V.I., Denishchenko G.N., Korovkina N.L. Dizajni i sistemeve të informacionit / Moskë: Binom, 2008. - 304 f.

Lipaev, V.V. Inxhinieri softuerike. Bazat metodologjike [Teksti]: Proc. / V. V. Lipaev; shteti. un-t - Shkolla e Lartë Ekonomike. - M.: TEIS, 2006. - 608 f.

Lavrishcheva E. M., Petrukhin V. A. Metodat dhe mjetet e inxhinierisë softuerike. - Libër mësuesi

Ian Somerville. Inxhinieri softuerike, botimi i 6-të.: Per. nga anglishtja. - M. : Shtëpia Botuese Williams, 2002.―624 f.

Excel 2010: programim profesional në VBA.: Per. nga anglishtja. - M.: SH.PK “I.D. Williams”, 2012. - 944 f. : i sëmurë. - Paral. cicë. anglisht

Fowler M. Rifaktorimi: Përmirësimi i Kodit ekzistues. Nga anglishtja.-Shën Petersburg: Symbol Plus, 2003.-432 f.

Burime shtesë:

Volkov V.A. UDHËZIME METODOLOGJIKE për zbatimin e punës praktike në disiplinën "Programimi i sistemit", Donetsk: DONPEK, 2015.

Volkov V.A. Udhëzime për zbatimin e projektit të kursit, Donetsk: DONPEC, 2015.

internet- burimet:

Programimi i sistemit [burimi elektronik] / Mënyra e hyrjes: http://www.umk3.utmn.ru.

Softueri dhe burimet e internetit: http://www.intuit.ru

Letërsia sipas disiplinës - http://www.internet-technologies.ru/books/

Libër shkollor elektronik "Hyrje në inxhinierinë softuerike" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Teksti elektronik "Teknologjia e programimit" - http://bourabai.kz/alg/pro.htm

4.5 Kërkesat për drejtuesit e praktikës nga një institucion dhe organizatë arsimore

Kërkesat për drejtuesit e praktikës nga një institucion arsimor:

personeli inxhinierik dhe mësimdhënës: të diplomuar - mësues të kurseve ndërdisiplinore dhe disiplinave të përgjithshme profesionale. Përvoja në organizata të fushës përkatëse profesionale është e detyrueshme.

Master i trajnimit industrial: disponueshmëria e kategorive të kualifikimit 5-6 me praktikë të detyrueshme në organizata të specializuara të paktën një herë në 3 vjet. Përvoja në organizata të fushës përkatëse profesionale është e detyrueshme.

5 MONITORIMI DHE VLERËSIMI I REZULTATEVE

PRAKTIKA ARSIMORE LARTË. 01

Forma e raportimit për praktikën arsimore UP.01 - raport mbi praktikën, i hartuar në përputhje me kërkesat e rekomandimeve metodologjike.

rezultatet (kompetenca profesionale të zotëruara)	Karakteristikat kryesore rezultat i përgatitjes	Format dhe Metodat kontrollin
PC 1.1. Kryeni zhvillimin e specifikimeve për komponentët individualë	Zhvillimi i një algoritmi për detyrën dhe zbatimi i tij me anë të projektimit me ndihmën e kompjuterit	Vëzhgimi dhe vlerësimi ekspert i veprimtarive të studentit në procesin e përvetësimit të programit arsimor në orët praktike, gjatë kryerjes së punës në praktikën arsimore dhe industriale.
PC 1.2. Kryerja e zhvillimit të kodit të produktit softuerik bazuar në specifikimet e gatshme në nivel moduli.	Të njohë parimet bazë të teknologjisë së programimit strukturor dhe të orientuar nga objekti. Për të kryer zhvillimin e kodit të modulit të programit në gjuhët moderne të programimit.
PC 1.3. Kryeni korrigjimin e moduleve të programit duke përdorur mjete të specializuara softuerike	Kryeni korrigjimin dhe testimin e programit në nivelin e modulit.
PC 1.4. Kryerja e testimit të moduleve të softuerit.	Krijo një program sipas algoritmit të zhvilluar si një modul i veçantë.
PC 1.5. Kryeni optimizimin e kodit të modulit	Zhvillimi i një kodi produkti të softuerit bazuar në një specifikim të përfunduar në nivelin e modulit.
PC 1.6. Zhvillimi i komponentëve të projektimit dhe dokumentacionit teknik duke përdorur gjuhët e specifikimeve grafike	Njihni metodat dhe mjetet e zhvillimit të dokumentacionit teknik. Përgatitni dokumentacionin e softuerit. Përdorni mjete për të automatizuar dokumentacionin.

Format dhe metodat e monitorimit dhe vlerësimit të rezultateve të të nxënit duhet t'i lejojnë studentët të kontrollojnë jo vetëm formimin e kompetencave profesionale, por edhe zhvillimin e kompetencave të përgjithshme dhe aftësitë që i ofrojnë ato.

rezultatet (kompetenca të përgjithshme të zotëruara)	Treguesit kryesorë për vlerësimin e rezultatit	Format dhe metodat e kontrollit dhe vlerësimit
OK 1. Kuptoni thelbin dhe rëndësinë shoqërore të profesionit tuaj të ardhshëm, tregoni një interes të qëndrueshëm për të.	Demonstrimi i interesit të vazhdueshëm për profesionin e ardhshëm; - vlefshmërinë e aplikimit të kompetencave të zotëruara profesionale;	Vëzhgimi dhe vlerësimi i ekspertëve në orët praktike gjatë kryerjes së punës në praktikën industriale;
OK 2. Organizojnë aktivitetet e tyre, përcaktojnë metodat dhe mënyrat e kryerjes së detyrave profesionale, vlerësojnë efektivitetin dhe cilësinë e tyre.	Arsyetimi i përcaktimit të qëllimeve, përzgjedhjes dhe aplikimit të metodave dhe metodave për zgjidhjen e problemeve profesionale; Kryerja e vetë-analizës dhe korrigjimi i rezultateve të punës së tyre	Vlerësimi në orët praktike në kryerjen e punës; Vëzhgimi gjatë praktikës; Introspeksioni
OK 3. Zgjidh problemet, vlerëso rreziqet dhe merr vendime në situata jo standarde.	Efektiviteti i vendimmarrjes së detyrave profesionale standarde dhe jo standarde për kohë të caktuar; Efektiviteti i planit për të optimizuar cilësinë e punës së kryer	Interpretimi i rezultateve të monitorimit të aktiviteteve të studentit në procesin e përfundimit të detyrave
OK 4. Kërkoni, analizoni dhe vlerësoni informacionin e nevojshëm për vendosjen dhe zgjidhjen e problemeve profesionale, zhvillimin profesional dhe personal.	Përzgjedhja dhe analiza e informacionit të nevojshëm për zbatimin e qartë dhe të shpejtë të detyrave profesionale, zhvillimit profesional dhe personal	Vlerësimi i ekspertit gjatë punës; Vetëkontroll gjatë shtrimit dhe zgjidhjes së problemeve
OK 5. Përdorni teknologjitë e informacionit dhe komunikimit për të përmirësuar aktivitetet profesionale.	aftësia për të përdorur teknologjitë e informacionit dhe komunikimit për të zgjidhur problemet profesionale	vlerësimi i detyrave
OK 6. Punoni në një ekip dhe ekip, siguroni kohezionin e tij, komunikoni në mënyrë efektive me kolegët, menaxhmentin, konsumatorët.	Aftësia për të bashkëvepruar me një grup, mësues, master të trajnimit industrial
OK 7. Vendosni qëllime, motivoni aktivitetet e vartësve, organizoni dhe kontrolloni punën e tyre duke marrë përsipër përgjegjësinë për rezultatin e detyrave.	- vetë-analizë dhe korrigjim të rezultateve të punës së tyre dhe punës së ekipit	Vëzhgimi i ecurisë së punës në grup në procesin e praktikës së prodhimit
OK 8. Përcaktoni në mënyrë të pavarur detyrat e zhvillimit profesional dhe personal, angazhohuni në vetë-edukim, planifikoni me vetëdije trajnime të avancuara.	Organizimi i punës së pavarur për formimin e një imazhi krijues dhe profesional; Organizimi i punës për vetë-edukim dhe përmirësim kualifikimet	Vëzhgimi dhe vlerësimi në procesin e praktikës industriale; Analiza reflektive (algoritmi i veprimeve të nxënësve); Ditari i praktikës; Analiza e portofolit të studentëve
OK 9. Jini të përgatitur për të ndryshuar teknologjitë në aktivitetet profesionale.	Analiza e inovacioneve në fushën e proceseve teknologjike për zhvillimin dhe prodhimin e veshjeve	Vlerësimi i zgjidhjeve të problemeve të situatës; Lojëra afariste dhe organizative-edukative; Vëzhgimi dhe vlerësimi në orët praktike, në procesin e praktikës së prodhimit

Procedura për zhvillimin e një moduli softuerësh.

1. studimi dhe verifikimi i specifikimit të modulit, zgjedhja e gjuhës programuese; (dmth, zhvilluesi, duke studiuar specifikimin, zbulon nëse është e qartë për të apo jo, nëse ai e përshkruan mjaftueshëm modulin; më pas ai zgjedh gjuhën e programimit në të cilën do të shkruhet moduli, megjithëse gjuha e programimit mund të jetë e njëjtë për të gjithë PS)
2. Zgjedhja e algoritmit dhe strukturës së të dhënave (këtu rezulton nëse ndonjë algoritëm njihet për zgjidhjen e problemit dhe, nëse po, përdorni atë)
3. Programimi i modulit (shkrimi i kodit të programit)
4. lustrimi i tekstit të modulit (redaktimi i komenteve ekzistuese, shtimi i komenteve shtesë për të siguruar cilësinë e kërkuar)
5. kontrollimi i modulit (logjika e modulit kontrollohet, puna e tij është debuguar)

Zbatohen metodat e mëposhtme të kontrollit të modulit të programit:

- kontrolli statik i tekstit të modulit (teksti lexohet nga fillimi në fund për të gjetur gabime në modul. Zakonisht, përveç zhvilluesit të modulit, për një kontroll të tillë përfshihen edhe një apo edhe disa programues të tjerë. Rekomandohet që gabimet e zbuluara gjatë një kontrolli të tillë të korrigjohen jo menjëherë, por pas përfundimit të leximit të tekstit të modulit)
- gjurmimi nga fundi në fund (lëvizja manuale e ekzekutimit të modulit (operator nga operatori në sekuencën që rrjedh nga logjika e modulit) në një grup të caktuar testesh)
6. përpilimi i modulit.

Programimi strukturor.

Deri më sot, teknika më e njohur e programimit është programimi i strukturuar nga lart-poshtë.

Programimi strukturor është procesi i zbërthimit të një algoritmi hap pas hapi në pjesë gjithnjë e më të vogla në mënyrë që të përftohen elementë për të cilët mund të shkruhen lehtësisht receta specifike.

Dy parime të programimit të strukturuar:

1. detajime të njëpasnjëshme "nga lart poshtë"
2. grup bazë i kufizuar strukturash për ndërtimin e algoritmeve të çdo shkalle kompleksiteti

Kërkesat e programimit të strukturuar:

1. Programi duhet të hartohet me hapa të vegjël, kështu që detyra komplekse ndahet në pjesë mjaft të thjeshta, lehtësisht të perceptueshme.
2. Logjika e programit duhet të bazohet në një numër minimal strukturash kontrolli mjaftueshëm bazë (struktura lineare, degëzuese dhe ciklike)

Karakteristikat dhe avantazhet kryesore të programimit të strukturuar:

1. Reduktimi i kompleksitetit të programeve
2. mundësia e demonstrimit të korrektësisë së programeve në faza të ndryshme të zgjidhjes së problemit
3. dukshmëria e programeve
4. lehtësia e modifikimit (ndryshimit) të programeve.

Mjetet moderne të programimit duhet të ofrojnë mbrojtje maksimale kundër gabimet e mundshme zhvilluesi.

Këtu mund të nxjerrim një analogji me zhvillimin e metodave të drejtimit të automjeteve. Në fillim, siguria u garantua përmes zhvillimit të rregullave të trafikut. Më pas kishte një sistem të shënjimeve rrugore dhe rregullimin e kryqëzimeve. Dhe, më në fund, filluan të ndërtohen kryqëzimet e trafikut, të cilat, në parim, parandalojnë kryqëzimin e flukseve të trafikut të makinave dhe këmbësorëve. Sidoqoftë, mjetet e përdorura duhet të përcaktohen nga natyra e problemit që zgjidhet: për një rrugë fshati, mjafton të respektoni një rregull të thjeshtë - "shikoni nën këmbët tuaja dhe përreth".

Ideja bazë e programimit të strukturuar: programi duhet të jetë një grup blloqesh, të kombinuara në një strukturë peme hierarkike, secila prej të cilave ka një hyrje dhe një dalje.

Çdo program mund të ndërtohet duke përdorur vetëm tre lloje bazë të blloqeve:

1. bllok funksional - i ndarë operator linear ose sekuenca e tyre;
Blloku i dytë i degëzimit - Nëse
3. lak i përgjithësuar - ndërtim i tipit Ndërsa

Është thelbësore që secila prej këtyre strukturave të ketë vetëm një hyrje dhe një dalje për sa i përket kontrollit. Kështu, operatori i përgjithësuar gjithashtu ka vetëm një hyrje dhe një dalje.

Programimi i strukturuar nganjëherë referohet si "programim pa SHKO TO". Megjithatë, çështja këtu nuk është deklarata SHKO TO, por përdorimi i saj pa dallim. Shumë shpesh, kur zbatohet programimi i strukturuar në disa gjuhë programimi, operatori i tranzicionit (GO TO) përdoret për të zbatuar konstruksione strukturore pa reduktuar avantazhet kryesore të programimit të strukturuar. Janë deklaratat e kërcimit "jo-strukturor" që ngatërrojnë programin, veçanërisht kërcimi në një deklaratë të vendosur në tekstin e modulit sipër (përpara) deklaratës së kërcimit të ekzekutuar. Megjithatë, përpjekja për të shmangur deklaratën e kërcimit në disa raste të thjeshta mund të çojë në programe të strukturuara që janë shumë të rënda, gjë që nuk përmirëson qartësinë e tyre dhe përmban rrezikun e gabimeve shtesë në tekstin e modulit. Prandaj, mund të rekomandohet të shmangni përdorimin e deklaratës së kërcimit kudo që të jetë e mundur, por jo me koston e qartësisë së programit.

Rastet e dobishme të përdorimit të operatorit të tranzicionit përfshijnë daljen nga një lak ose procedurë me një kusht të veçantë që përfundon "herë" punën. këtë cikël ose një procedurë të caktuar, d.m.th. ndërprerja e punës së një njësie strukturore (operatori i gjeneralizuar) dhe si rrjedhim vetëm shkelja lokale e strukturimit të programit. Vështirësi të mëdha (dhe ndërlikime të strukturës) shkaktohen nga zbatimi strukturor i reagimit ndaj situatave të jashtëzakonshme (shpesh të gabuara) të shfaqura, pasi kjo kërkon jo vetëm një dalje të hershme nga njësia strukturore, por edhe përpunimin e nevojshëm të kësaj situate (për për shembull, lëshimi i informacionit të duhur diagnostik). Trajtuesi i përjashtimeve mund të vendoset në çdo nivel të strukturës së programit dhe mund të aksesohet nga nivele të ndryshme më të ulëta. Mjaft i pranueshëm nga pikëpamja teknologjike është zbatimi "jo strukturor" i mëposhtëm i përgjigjes ndaj situatave të jashtëzakonshme. Trajtuesit e përjashtimit vendosen në fund të një ose një njësie tjetër strukturore dhe çdo mbajtës i tillë programohet në atë mënyrë që pas përfundimit të punës të dalë nga njësia strukturore në fund të së cilës është vendosur. Një mbajtës i tillë thirret nga operatori i kërcimit nga njësia e caktuar strukturore (duke përfshirë çdo njësi strukturore të mbivendosur).

Në përgjithësi, gjëja kryesore në programimin e strukturuar është përpilimi kompetent i skemës së saktë logjike të programit, zbatimi i të cilit me mjete gjuhësore është një çështje dytësore.

Kalimi nga joformalja në formale është në thelb joformale.

Leksioni 8

ZHVILLIMI I MODULIT SOFTUERIK

Procedura për zhvillimin e një moduli softuerësh. Programimi strukturor dhe detajimi hap pas hapi. Koncepti i pseudokodit. Kontrolli i modulit të softuerit.

8.1. Procedura për zhvillimin e një moduli softuerësh.

Kur zhvilloni një modul softuerësh, këshillohet t'i përmbaheni rendit të mëposhtëm:

studimi dhe verifikimi i specifikimeve të modulit, zgjedhja e gjuhës programuese;

zgjedhja e algoritmit dhe strukturës së të dhënave;

programimi (kodimi) i modulit;

lustrimi i tekstit të modulit;

Kontrollimi i modulit

përpilimi i modulit.

Hapi i parë në zhvillimin e një moduli softuerësh është në një masë të madhe një kontroll i vazhdueshëm i strukturës së programit nga poshtë: duke studiuar specifikimet e modulit, zhvilluesi duhet të sigurohet që ai është i qartë dhe i mjaftueshëm që ai të zhvillojë. këtë modul. Në fund të këtij hapi, zgjidhet një gjuhë programimi: megjithëse gjuha e programimit mund të jetë tashmë e paracaktuar për të gjithë PS, në disa raste (nëse sistemi i programimit e lejon), mund të zgjidhet një gjuhë tjetër që është më e përshtatshme për zbatim. të këtij moduli (për shembull, gjuha e asamblesë).

Në hapin e dytë të zhvillimit të një moduli softuerësh, është e nevojshme të zbulohet nëse ndonjë algoritëm njihet tashmë për zgjidhjen e problemit të paraqitur ose afër tij. Dhe nëse ekziston një algoritëm i përshtatshëm, atëherë këshillohet ta përdorni atë. Zgjedhja e strukturave të përshtatshme të të dhënave që do të përdoren kur moduli të kryejë funksionet e tij përcakton në masë të madhe logjikën dhe treguesit e cilësisë së modulit që po zhvillohet, ndaj duhet të konsiderohet një vendim shumë i rëndësishëm.

Në hapin e tretë, teksti i modulit ndërtohet në gjuhën e programimit të zgjedhur. Bollëku i të gjitha llojeve të detajeve që duhet të merren parasysh gjatë zbatimit të funksioneve të specifikuara në specifikimin e modulit mund të çojë lehtësisht në krijimin e një teksti shumë konfuz që përmban shumë gabime dhe pasaktësi. Gjetja e gabimeve në një modul të tillë dhe bërja e ndryshimeve të kërkuara në të mund të jetë një detyrë që kërkon shumë kohë. Prandaj, është shumë e rëndësishme të përdoret një disiplinë programimi e justifikuar teknologjikisht dhe praktikisht e provuar për të ndërtuar tekstin e modulit. Për herë të parë, Dijkstra tërhoqi vëmendjen për këtë, duke formuluar dhe vërtetuar parimet bazë të programimit të strukturuar. Shumë nga disiplinat e programimit që përdoren gjerësisht në praktikë bazohen në këto parime. Më e zakonshme është disiplina e stërvitjes, e cila diskutohet në detaje në seksionet 8.2 dhe 8.3.

Hapi tjetër në zhvillimin e modulit lidhet me sjelljen e tekstit të modulit në formën përfundimtare në përputhje me specifikimet e cilësisë së PS. Kur programon një modul, zhvilluesi fokusohet në zbatimin e saktë të funksioneve të modulit, duke lënë komente të papërfunduara dhe duke lejuar disa shkelje të kërkesave të stilit të programit. Gjatë lustrimit të tekstit të një moduli, ai duhet të modifikojë komentet në tekst dhe mundësisht të përfshijë komente shtesë në mënyrë që të sigurojë primitivet e cilësisë së kërkuar. Për të njëjtin qëllim, teksti i programit redaktohet për të përmbushur kërkesat stilistike.

Hapi i verifikimit të modulit është një kontroll manual i logjikës së brendshme të modulit përpara se ta korrigjojë atë (duke përdorur ekzekutimin e tij në kompjuter), zbaton parimin e përgjithshëm të formuluar për të diskutuar teknologjitë e programimit, për nevojën për të kontrolluar vendimet e marra në çdo fazë të zhvillimit të SP (shih leksionin 3). Metodat e vlefshmërisë së modulit diskutohen në seksionin 8.4.

Së fundi, hapi i fundit i zhvillimit të një moduli nënkupton përfundimin e vlefshmërisë së modulit (duke përdorur përpiluesin) dhe kalimin në procesin e korrigjimit të modulit.

8.2. Programimi strukturor.

Kur programoni një modul, duhet të kihet parasysh se programi duhet të jetë i kuptueshëm jo vetëm për një kompjuter, por edhe për një person: si zhvilluesi i modulit, ashtu edhe personat që kontrollojnë modulin, dhe testuesit që përgatisin teste për korrigjimin e modulit. , dhe mirëmbajtësit e PS që bëjnë ndryshimet e kërkuara në modul detyrohen të analizojnë në mënyrë të përsëritur logjikën e modulit. Në gjuhët moderne të programimit, ka mjete të mjaftueshme për të ngatërruar këtë logjikë sa të doni, duke e bërë modulin të vështirë për t'u kuptuar për një person dhe, si rezultat, duke e bërë atë të pabesueshëm ose të vështirë për t'u mirëmbajtur. Prandaj, duhet pasur kujdes për të zgjedhur mjetet e duhura gjuhësore dhe për të ndjekur një disiplinë të caktuar programimi. Në këtë drejtim, Dijkstra propozoi të ndërtohej një program si një përbërje e disa llojeve të strukturave të kontrollit (strukturave), të cilat mund të rrisin shumë kuptueshmërinë e logjikës së programit. Programimi duke përdorur vetëm konstruksione të tilla quhet strukturore.

Oriz. 8.1. Strukturat bazë të kontrollit të programimit të strukturuar.

Konstruktet kryesore të programimit të strukturuar janë: ndjekja, degëzimi dhe përsëritja (shih Figurën 8.1). Komponentët e këtyre konstruksioneve janë operatorë të përgjithësuar (nyjet e përpunimit) S, S1, S2 dhe kushti (kallëzues) P. Si operator i përgjithësuar, ose një operator i thjeshtë i gjuhës së programimit të përdorur (caktimi, hyrje, dalje, operatorët e thirrjes së procedurës) ose një fragment programi, i cili është një përbërje e strukturave kryesore të kontrollit të programimit të strukturuar. Është thelbësore që secila prej këtyre strukturave të ketë vetëm një hyrje dhe një dalje për sa i përket kontrollit. Kështu, operatori i përgjithësuar gjithashtu ka vetëm një hyrje dhe një dalje.

Është gjithashtu shumë e rëndësishme që këto ndërtime janë tashmë objekte matematikore (që në thelb shpjegon arsyen e suksesit të programimit të strukturuar). Është vërtetuar se për çdo program të pastrukturuar është e mundur të ndërtohet një program i strukturuar funksionalisht ekuivalent (dmth., zgjidhja e të njëjtit problem). Për programet e strukturuara, disa veti mund të vërtetohen matematikisht, gjë që bën të mundur zbulimin e disa gabimeve në program. Një leksion i veçantë do t'i kushtohet kësaj çështjeje.

Programimi i strukturuar nganjëherë referohet si "programim pa SHKO TO". Megjithatë, çështja këtu nuk është deklarata SHKO TO, por përdorimi i saj pa dallim. Shumë shpesh, kur zbatoni programim strukturor në disa gjuhë programimi (për shembull, në FORTRAN), operatori i tranzicionit (GO TO) përdoret për të zbatuar ndërtime strukturore, të cilat nuk shkelin parimet e programimit strukturor. Janë deklaratat e kërcimit "jo-strukturor" që ngatërrojnë programin, veçanërisht kërcimi në një deklaratë të vendosur në tekstin e modulit sipër (përpara) ekzekutimit të deklaratës së kërcimit. Megjithatë, përpjekja për të shmangur deklaratën e kërcimit në disa raste të thjeshta mund të çojë në programe të strukturuara që janë shumë të rënda, gjë që nuk përmirëson qartësinë e tyre dhe përmban rrezikun e gabimeve shtesë në tekstin e modulit. Prandaj, mund të rekomandohet të shmanget përdorimi i deklaratës së kërcimit kudo që është e mundur, por jo me koston e qartësisë së programit.

Rastet e dobishme të përdorimit të operatorit të tranzicionit përfshijnë daljen nga një lak ose procedurë me një kusht të veçantë që përfundon "herë" punën e këtij cikli ose të kësaj procedure, dmth., ndërprerja e punës së një njësie strukturore (operatori i përgjithësuar) dhe në këtë mënyrë shkelja vetëm në nivel lokal strukturimi i programit. Vështirësi të mëdha (dhe ndërlikime të strukturës) shkaktohen nga zbatimi strukturor i përgjigjes ndaj situatave të jashtëzakonshme (shpesh të gabuara), pasi kjo kërkon jo vetëm një dalje të hershme nga njësia strukturore, por edhe përpunimin (përjashtimin) e nevojshëm të kësaj situate. (për shembull, lëshimi i një informacioni të përshtatshëm diagnostikues). Trajtuesi i përjashtimeve mund të vendoset në çdo nivel të strukturës së programit dhe mund të aksesohet nga nivele të ndryshme më të ulëta. Mjaft i pranueshëm nga pikëpamja teknologjike është zbatimi "jo strukturor" i mëposhtëm i përgjigjes ndaj situatave të jashtëzakonshme. Trajtuesit e përjashtimit vendosen në fund të një ose një njësie tjetër strukturore dhe çdo mbajtës i tillë programohet në atë mënyrë që pas përfundimit të punës të dalë nga njësia strukturore në fund të së cilës është vendosur. Një mbajtës i tillë thirret nga operatori i kërcimit nga njësia e caktuar strukturore (duke përfshirë çdo njësi strukturore të mbivendosur).

8.3. Detajimi hap pas hapi dhe koncepti i pseudokodit.

Programimi i strukturuar jep rekomandime se cili duhet të jetë teksti i një moduli. Shtrohet pyetja se si duhet të veprojë një programues për të ndërtuar një tekst të tillë. Shpesh programimi i një moduli fillon me ndërtimin e bllok-diagramit të tij, i cili përshkruan në terma të përgjithshëm logjikën e funksionimit të tij. por Teknologji moderne programuesi nuk rekomandon ta bëni këtë pa mbështetje të përshtatshme kompjuterike. Megjithëse diagramet e rrjedhës ofrojnë një paraqitje shumë vizuale të logjikës së një moduli, kur ato kodohen manualisht në një gjuhë programimi, lind një burim shumë specifik gabimesh: hartimi i strukturave në thelb dy-dimensionale, të tilla si diagramet e rrjedhës, në tekstin linear që përfaqëson një modul. përmban rrezikun e shtrembërimit të logjikës së modulit, veçanërisht pasi psikologjikisht është mjaft e vështirë të ruash një nivel të lartë vëmendjeje kur e rishikon atë. Një përjashtim mund të jetë rasti kur përdoret për të ndërtuar diagrame bllok redaktori grafik dhe ato janë aq të formalizuara saqë teksti gjenerohet automatikisht prej tyre në një gjuhë programimi (si, për shembull, bëhet në teknologjinë R).

Si metodë kryesore e ndërtimit të tekstit të modulit, rekomandohet teknologjia moderne e programimit detaje hap pas hapi. Thelbi i kësaj metode është të ndajë procesin e zhvillimit të tekstit të modulit në një numër hapash. Në të parën

Hapi përshkruan skemën e përgjithshme të funksionimit të modulit në një formë të dukshme tekstuale lineare (d.m.th., duke përdorur koncepte shumë të mëdha), dhe ky përshkrim nuk është plotësisht i formalizuar dhe fokusohet në perceptimin njerëzor. Në çdo hap tjetër, një nga konceptet rafinohet dhe detajohet (ne do ta quajmë atë specifikuar) në çdo përshkrim të zhvilluar në një nga hapat e mëparshëm. Si rezultat i këtij hapi, krijohet një përshkrim i konceptit të përzgjedhur që po rafinohet ose në terma të gjuha bazë programimi (d.m.th., moduli i zgjedhur për prezantim), ose në të njëjtën formë si në hapin e parë duke përdorur koncepte të reja të rafinuara. Ky proces përfundon kur të gjitha konceptet e specifikuara janë sqarime(d.m.th. përfundimisht do të shprehet në gjuhën e programimit bazë). Hapi i fundit është marrja e tekstit të modulit në gjuhën bazë të programimit duke zëvendësuar të gjitha dukuritë e koncepteve të rafinuara me përshkrimet e tyre të specifikuara dhe për të shprehur të gjitha dukuritë e konstrukteve të programimit të strukturuar duke përdorur këtë gjuhë programimi.

Përsosja hap pas hapi shoqërohet me përdorimin e një gjuhe të formalizuar pjesërisht për përfaqësimin e përshkrimeve të specifikuara, e cila quhet pseudokod. Kjo gjuhë lejon përdorimin e të gjitha konstrukteve të strukturuara të programimit që janë formalizuar, së bashku me fragmente joformale të gjuhës natyrore për të përfaqësuar deklarata dhe kushte të përgjithshme. Fragmentet përkatëse në gjuhën e programimit bazë mund të specifikohen gjithashtu si operatorë dhe kushte të përgjithësuara.

· fillimi i modulit në gjuhën bazë, pra fjalia ose titulli (specifikimi) i parë i këtij moduli;

seksioni (bashkësia) e përshkrimeve në gjuhën bazë, dhe në vend të përshkrimeve të procedurave dhe funksioneve - vetëm dizajni i tyre i jashtëm;

· përcaktimi jozyrtar i sekuencës së operatorëve të trupit të modulit si një operator i përgjithësuar (shih më poshtë), si dhe përcaktimi jozyrtar i trupit të secilës procedurë ose përshkrim funksioni si një operator i përgjithësuar;

· fjalia e fundit (fundi) e modulit në gjuhën bazë.

Dizajni i jashtëm i përshkrimit të një procedure ose funksioni paraqitet në mënyrë të ngjashme. Megjithatë, duke ndjekur Dijkstra-n, do të ishte më mirë që pjesa e përshkrimeve të paraqitet këtu edhe me një shënim joformal, duke e detajuar atë si një përshkrim më vete.

Një përcaktim jozyrtar i një operatori të përgjithësuar në pseudokod bëhet në gjuhën natyrore nga një fjali arbitrare që zbulon përmbajtjen e tij në terma të përgjithshëm. E vetmja kërkesë formale për hartimin e një emërtimi të tillë është si vijon: kjo fjali duhet të zërë një ose më shumë rreshta grafikë (të printuar) në tërësinë e saj dhe të përfundojë me një pikë (ose ndonjë karakter tjetër të caktuar posaçërisht për këtë).

Oriz. 8.2. Ndërtimet bazë të programimit të strukturuar në pseudokod.

Për çdo operator të përgjithësuar informal, duhet të krijohet një përshkrim i veçantë që shpreh logjikën e punës së tij (duke detajuar përmbajtjen e tij) duke përdorur përbërjen e strukturave kryesore të programimit të strukturuar dhe operatorëve të tjerë të përgjithësuar. Titulli i një përshkrimi të tillë duhet të jetë përcaktimi jozyrtar i operatorit të përgjithësuar që po rafinohet. Konstruktet bazë të programimit të strukturuar mund të paraqiten si më poshtë (shih Figurën 8.2). Këtu, kushti ose mund të specifikohet në mënyrë eksplicite në gjuhën e programimit bazë si një shprehje boolean, ose të përfaqësohet joformalisht në gjuhën natyrore nga një fragment që përshkruan kuptimin e kësaj gjendjeje. Në rastin e fundit, duhet të krijohet një përshkrim i veçantë duke detajuar këtë gjendje, duke treguar emërtimin e këtij kushti (fragment në gjuhën natyrore) si titull.

Dalja nga përsëritja (lak):

Procedura e daljes (funksioni):

J. Hughes, J. Michtom. Qasje strukturore ndaj programimit. - M.: Mir, 1980. - f. 29-71.

V. Tursky. Metodologjia e programimit. - M.: Mir, 1981. - fq 90-164.

E.A. Zhogolev. Bazat teknologjike të programimit modular // Programimi, 1980, nr. 2. - f.44-49.

R.C. Holt. Struktura e programeve kompjuterike: Një studim // Proceedings of the IEEE, 1975, 63(6). - fq. 879-893.

G. Myers. Besueshmëria e softuerit. - M.: Mir, 1980. - f. 92-113.

I.Pyle. ADA është një gjuhë e integruar e sistemeve. M.: Financa dhe statistika, 1984. - f. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Parimet e zhvillimit të softuerit. - M.: Mir, 1982, f. 65-71.

A.L. Fuksman. Aspektet teknologjike të krijimit sistemet softuerike. M.: Statistika, 1979. - f. 79-94.

Leksioni 8. Zhvillimi i një moduli softuerik
Procedura për zhvillimin e një moduli softuerësh. Programimi strukturor dhe detajimi hap pas hapi. Koncepti i pseudokodit. Kontrolli i modulit të softuerit.
8.1. Procedura për zhvillimin e një moduli softuerësh.
Kur zhvilloni një modul softuerësh, këshillohet t'i përmbaheni rendit të mëposhtëm:
studimi dhe verifikimi i specifikimit të modulit, përzgjedhja e gjuhës
programim;
zgjedhja e algoritmit dhe strukturës së të dhënave;
programimi i moduleve;
lustrimi i tekstit të modulit;
kontrolli i modulit;
përpilimi i modulit.
Hapi i parë në zhvillimin e një moduli softuerësh është në një masë të madhe një kontroll i vazhdueshëm i strukturës së programit nga poshtë: duke studiuar specifikimet e modulit, zhvilluesi duhet të sigurohet që ai është i qartë dhe i mjaftueshëm që ai të zhvillojë. këtë modul. Në fund të këtij hapi, zgjidhet një gjuhë programimi: megjithëse gjuha e programimit mund të jetë tashmë e paracaktuar për të gjithë PS, në disa raste (nëse sistemi i programimit e lejon), mund të zgjidhet një gjuhë tjetër që është më e përshtatshme për zbatim. të këtij moduli (për shembull, gjuha e asamblesë).
Në hapin e dytë të zhvillimit të një moduli softuerësh, është e nevojshme të zbulohet nëse ndonjë algoritëm njihet tashmë për zgjidhjen e problemit të paraqitur ose afër tij. Dhe nëse ekziston një algoritëm i përshtatshëm, atëherë këshillohet ta përdorni atë. Zgjedhja e strukturave të përshtatshme të të dhënave që do të përdoren kur moduli të kryejë funksionet e tij përcakton në masë të madhe logjikën dhe treguesit e cilësisë së modulit që po zhvillohet, ndaj duhet të konsiderohet një vendim shumë i rëndësishëm.
Në hapin e tretë, teksti i modulit ndërtohet në gjuhën e programimit të zgjedhur. Bollëku i të gjitha llojeve të detajeve që duhet të merren parasysh gjatë zbatimit të funksioneve të specifikuara në specifikimin e modulit mund të çojë lehtësisht në krijimin e një teksti shumë konfuz që përmban shumë gabime dhe pasaktësi. Gjetja e gabimeve në një modul të tillë dhe bërja e ndryshimeve të kërkuara në të mund të jetë një detyrë që kërkon shumë kohë. Prandaj, është shumë e rëndësishme të përdoret një disiplinë programimi e justifikuar teknologjikisht dhe praktikisht e provuar për të ndërtuar tekstin e modulit. Për herë të parë, Dijkstra tërhoqi vëmendjen për këtë, duke formuluar dhe vërtetuar parimet bazë të programimit të strukturuar. Shumë nga disiplinat e programimit që përdoren gjerësisht në praktikë bazohen në këto parime. Më e zakonshme është disiplina e stërvitjes, e cila diskutohet në detaje në seksionet 8.2 dhe 8.3.
Hapi tjetër në zhvillimin e modulit lidhet me sjelljen e tekstit të modulit në formën përfundimtare në përputhje me specifikimet e cilësisë së PS. Kur programon një modul, zhvilluesi fokusohet në zbatimin e saktë të funksioneve të modulit, duke lënë komente të papërfunduara dhe duke lejuar disa shkelje të kërkesave të stilit të programit. Gjatë lustrimit të tekstit të një moduli, ai duhet të modifikojë komentet në tekst dhe mundësisht të përfshijë komente shtesë në mënyrë që të sigurojë primitivet e cilësisë së kërkuar. Për të njëjtin qëllim, teksti i programit redaktohet për të përmbushur kërkesat stilistike.
Hapi i verifikimit të modulit është një kontroll manual i logjikës së brendshme të modulit përpara korrigjimit (duke përdorur ekzekutimin e tij në një kompjuter), zbaton parimin e përgjithshëm të formuluar për teknologjinë e diskutuar të programimit, në lidhje me nevojën për të kontrolluar vendimet e marra në çdo fazë të zhvillimi i SP (shih leksionin 3). Metodat e vlefshmërisë së modulit diskutohen në seksionin 8.4.
Së fundi, hapi i fundit i zhvillimit të një moduli nënkupton përfundimin e vlefshmërisë së modulit (duke përdorur përpiluesin) dhe kalimin në procesin e korrigjimit të modulit.
8.2. Programimi strukturor.
Kur programoni një modul, duhet të kihet parasysh se programi duhet të jetë i kuptueshëm jo vetëm për një kompjuter, por edhe për një person: si zhvilluesi i modulit, ashtu edhe njerëzit që kontrollojnë modulin, dhe shkrimtarët e tekstit që përgatisin teste për korrigjimin e gabimeve. moduli, dhe mirëmbajtësit e PS që bëjnë ndryshimet e kërkuara në modul do të duhet të analizojnë në mënyrë të përsëritur logjikën e modulit. Në gjuhët moderne të programimit, ka mjete të mjaftueshme për të ngatërruar këtë logjikë sa të doni, duke e bërë modulin të vështirë për t'u kuptuar për një person dhe, si rezultat, duke e bërë atë të pabesueshëm ose të vështirë për t'u mirëmbajtur. Prandaj, duhet pasur kujdes për të zgjedhur mjetet e duhura gjuhësore dhe për të ndjekur një disiplinë të caktuar programimi. Për herë të parë, Dijkstra tërhoqi vëmendjen për këtë dhe propozoi ndërtimin e një programi si një përbërje e disa llojeve të strukturave të kontrollit (strukturave), të cilat mund të rrisin shumë kuptueshmërinë e logjikës së programit. Programimi duke përdorur vetëm konstruksione të tilla quhej programim strukturor.
Konstruktet kryesore të programimit të strukturuar janë: ndjekja, degëzimi dhe përsëritja (shih Figurën 8.1). Komponentët e këtyre konstruksioneve janë operatorë të përgjithësuar (nyjet e përpunimit) S, S1, S2 dhe kushti (kallëzues) P. Si operator i përgjithësuar, ose një operator i thjeshtë i gjuhës së programimit të përdorur (caktimi, hyrje, dalje, operatorët e thirrjes së procedurës) ose një fragment programi, i cili është një përbërje e strukturave kryesore të kontrollit të programimit të strukturuar. Është thelbësore që secila prej këtyre strukturave të ketë vetëm një hyrje dhe një dalje për sa i përket kontrollit. Kështu, operatori i përgjithësuar gjithashtu ka vetëm një hyrje dhe një dalje.
Është gjithashtu shumë e rëndësishme që këto ndërtime janë tashmë objekte matematikore (që në thelb shpjegon arsyen e suksesit të programimit të strukturuar). Është vërtetuar se për çdo program të pastrukturuar është e mundur të ndërtohet një program i strukturuar funksionalisht ekuivalent (d.m.th., zgjidhja e të njëjtit problem). Për programet e strukturuara, disa veti mund të vërtetohen matematikisht, gjë që bën të mundur zbulimin e disa gabimeve në program. Një leksion i veçantë do t'i kushtohet kësaj çështjeje.
Programimi i strukturuar nganjëherë referohet si "programim pa SHKO TO". Megjithatë, çështja këtu nuk është deklarata SHKO TO, por përdorimi i saj pa dallim. Shumë shpesh, kur zbatoni programim të strukturuar në disa gjuhë programimi (për shembull, në FORTRAN), operatori i tranzicionit (GO TO) përdoret për të zbatuar strukturat strukturore pa reduktuar avantazhet kryesore të programimit të strukturuar. Janë deklaratat e kërcimit "jo-strukturor" që e ngatërrojnë programin, veçanërisht kërcimi në një deklaratë të vendosur në tekstin e modulit sipër (më parë) deklaratës së kërcimit që po ekzekutohet. Megjithatë, përpjekja për të shmangur deklaratën e kërcimit në disa raste të thjeshta mund të çojë në programe të strukturuara që janë shumë të rënda, gjë që nuk përmirëson qartësinë e tyre dhe përmban rrezikun e gabimeve shtesë në tekstin e modulit. Prandaj, mund të rekomandohet shmangia e përdorimit të deklaratës së kërcimit kudo që të jetë e mundur, por jo me koston e qartësisë së programit.
Rastet e dobishme të përdorimit të operatorit të tranzicionit përfshijnë daljen nga një lak ose procedurë me një kusht të veçantë që përfundon "herë" punën e këtij cikli ose kësaj procedure, d.m.th. ndërprerja e punës së një njësie strukturore (operatori i gjeneralizuar) dhe si rrjedhim vetëm shkelja lokale e strukturimit të programit. Vështirësi të mëdha (dhe ndërlikime të strukturës) shkaktohen nga zbatimi strukturor i përgjigjes ndaj situatave të jashtëzakonshme (shpesh të gabuara), pasi kjo kërkon jo vetëm një dalje të hershme nga njësia strukturore, por edhe përpunimin (përjashtimin) e nevojshëm të kësaj situate. (për shembull, lëshimi i një informacioni të përshtatshëm diagnostikues). Trajtuesi i përjashtimeve mund të vendoset në çdo nivel të strukturës së programit dhe mund të aksesohet nga nivele të ndryshme më të ulëta. Mjaft i pranueshëm nga pikëpamja teknologjike është zbatimi "jo strukturor" i mëposhtëm i përgjigjes ndaj situatave të jashtëzakonshme. Trajtuesit e përjashtimit vendosen në fund të një ose një njësie tjetër strukturore dhe çdo mbajtës i tillë programohet në atë mënyrë që pas përfundimit të punës të dalë nga njësia strukturore në fund të së cilës është vendosur. Një mbajtës i tillë thirret nga një operator kërcimi nga njësia e caktuar strukturore (duke përfshirë çdo njësi strukturore të mbivendosur).
8.3. Detajimi hap pas hapi dhe koncepti i pseudokodit.
Programimi i strukturuar jep rekomandime se cili duhet të jetë teksti i një moduli. Shtrohet pyetja se si duhet të veprojë një programues për të ndërtuar një tekst të tillë. Ndonjëherë programimi i një moduli fillon me ndërtimin e bllok-diagramit të tij, i cili përshkruan në terma të përgjithshëm logjikën e funksionimit të tij. Sidoqoftë, teknologjia moderne e programimit nuk e rekomandon këtë. Megjithëse diagramet e rrjedhës ofrojnë një paraqitje shumë vizuale të logjikës së një moduli, kur ato janë të koduara në një gjuhë programimi, lind një burim shumë specifik gabimesh: hartimi i strukturave në thelb dy-dimensionale, të tilla si diagramet e rrjedhës, në tekstin linear që përfaqëson një modul, përmban rreziku i shtrembërimit të logjikës së modulit, për më tepër, psikologjikisht është mjaft e vështirë të mbash një nivel të lartë vëmendjeje kur e rishikon atë. Një përjashtim mund të jetë rasti kur një redaktues grafik përdoret për të ndërtuar grafikët e rrjedhës dhe ato formalizohen në mënyrë që teksti në një gjuhë programimi të gjenerohet automatikisht prej tyre (si, për shembull, kjo mund të bëhet në teknologjinë R).
Si metoda kryesore e ndërtimit të tekstit të modulit, teknologjia moderne e programimit rekomandon detajimin hap pas hapi. Thelbi i kësaj metode është të ndajë procesin e zhvillimit të tekstit të modulit në një numër hapash. Në hapin e parë, skema e përgjithshme e funksionimit të modulit përshkruhet në një formë tekstuale të dukshme lineare (d.m.th., duke përdorur koncepte shumë të mëdha), dhe ky përshkrim nuk është plotësisht i formalizuar dhe fokusohet në perceptimin njerëzor. Në çdo hap tjetër, një nga konceptet (ne do ta quajmë të rafinuar) rafinohet dhe detajohet, i cili përdoret (si rregull, jo i zyrtarizuar) në çdo përshkrim të zhvilluar në një nga hapat e mëparshëm. Si rezultat i këtij hapi, krijohet një përshkrim i konceptit të përzgjedhur që po rafinohet ose në kuptimin e gjuhës së programimit bazë (dmth. modulit të zgjedhur për përfaqësim), ose në të njëjtën formë si në hapin e parë duke përdorur koncepte të reja që po rafinohen. . Ky proces përfundon kur të gjitha konceptet që rafinohen përfundimisht shprehen në gjuhën e programimit bazë. Hapi i fundit është marrja e tekstit të modulit në gjuhën bazë të programimit duke zëvendësuar të gjitha dukuritë e koncepteve të rafinuara me përshkrimet e tyre të specifikuara dhe për të shprehur të gjitha dukuritë e konstrukteve të programimit të strukturuar duke përdorur këtë gjuhë programimi.
Stërvitja hap pas hapi përfshin përdorimin e një gjuhe të zyrtarizuar pjesërisht për të përfaqësuar përshkrimet e përmendura, e cila quhet pseudokod. Kjo gjuhë lejon përdorimin e të gjitha konstrukteve të strukturuara të programimit që janë formalizuar, së bashku me fragmente joformale të gjuhës natyrore për të përfaqësuar deklarata dhe kushte të përgjithshme. Fragmentet përkatëse në gjuhën e programimit bazë mund të specifikohen gjithashtu si operatorë dhe kushte të përgjithësuara.
Përshkrimi i kokës në pseudokod mund të konsiderohet dizajni i jashtëm i modulit në gjuhën e programimit bazë, e cila
fillimi i modulit në gjuhën bazë, d.m.th. fjalia ose titulli (specifikimi) i parë i këtij moduli;
një seksion (grup) përshkrimesh në gjuhën bazë, dhe në vend të përshkrimeve të procedurave dhe funksioneve - vetëm dizajni i tyre i jashtëm;
përcaktimi joformal i sekuencës së operatorëve të trupit të modulit si një operator i përgjithësuar (shih më poshtë), si dhe përcaktimi jozyrtar i sekuencës së operatorëve të trupit të secilës procedurë ose përshkrim funksioni si një operator i përgjithësuar;
fjalia e fundit (fundi) e modulit në gjuhën bazë.
Dizajni i jashtëm i përshkrimit të një procedure ose funksioni paraqitet në mënyrë të ngjashme. Megjithatë, duke ndjekur Dijkstra-n, do të ishte më mirë që pjesa e përshkrimeve të paraqitet këtu edhe me një shënim joformal, duke e detajuar atë si një përshkrim më vete.
Një përcaktim jozyrtar i një operatori të përgjithësuar në pseudokod bëhet në gjuhën natyrore nga një fjali arbitrare që zbulon përmbajtjen e tij në terma të përgjithshëm. E vetmja kërkesë formale për hartimin e një emërtimi të tillë është si vijon: kjo fjali duhet të zërë një ose më shumë rreshta grafikë (të printuar) në tërësinë e saj dhe të përfundojë me një pikë.
Për çdo operator të përgjithësuar informal, duhet të krijohet një përshkrim i veçantë që shpreh logjikën e punës së tij (duke detajuar përmbajtjen e tij) duke përdorur përbërjen e strukturave kryesore të programimit të strukturuar dhe operatorëve të tjerë të përgjithësuar. Titulli i një përshkrimi të tillë duhet të jetë përcaktimi jozyrtar i operatorit të përgjithësuar që po rafinohet. Konstruktet bazë të programimit të strukturuar mund të paraqiten si më poshtë (shih Figurën 8.2). Këtu, kushti ose mund të specifikohet në mënyrë eksplicite në gjuhën e programimit bazë si një shprehje boolean, ose të përfaqësohet joformalisht në gjuhën natyrore nga një fragment që përshkruan kuptimin e kësaj gjendjeje. Në rastin e fundit, duhet të krijohet një përshkrim i veçantë duke detajuar këtë gjendje, duke treguar emërtimin e këtij kushti (fragment në gjuhën natyrore) si titull.
Oriz. 8.2. Ndërtimet bazë të programimit të strukturuar në pseudokod.
Oriz. 8.3. Raste të veçanta të operatorit të tranzicionit si operator i përgjithësuar.
Si operator i përgjithësuar në pseudokod, mund të përdorni rastet e veçanta të mësipërme të operatorit të tranzicionit (shih Fig. 8.3). Sekuenca e trajtuesve të përjashtimeve (përjashtimeve) specifikohet në fund të përshkrimit të një moduli ose një procedure (funksioni). Çdo mbajtës i tillë duket si:
PËRJASHTIMI, emri i përjashtimit
gjenerik_operator
GJITHA PËRJASHTIM
Dallimi midis një trajtuesi përjashtimi dhe një procedure pa parametra është si më poshtë: pas ekzekutimit të procedurës, kontrolli kthehet në deklaratën pas thirrjes ndaj tij, dhe pasi të ekzekutohet përjashtimi, kontrolli kthehet në deklaratën pas thirrjes në modul ose procedurë (funksion), në fund të së cilës (të cilit) vendoset ky përjashtim.
Rekomandohet të krijohet një përshkrim mjaft kuptimplotë në çdo hap të detajimit, por lehtësisht i dukshëm (vizual), në mënyrë që të vendoset në një faqe teksti. Si rregull, kjo do të thotë që një përshkrim i tillë duhet të jetë një përbërje prej pesë ose gjashtë konstrukteve të strukturuara programore. Rekomandohet gjithashtu vendosja e strukturave të mbivendosura me një zhvendosje djathtas me disa pozicione (shih Fig. 8.4). Si rezultat, mund të merrni një përshkrim të logjikës së punës për sa i përket dukshmërisë që është mjaft konkurrues me diagramet e rrjedhës, por ka një avantazh të rëndësishëm - lineariteti i përshkrimit ruhet.

FSHINI TË REGJISTRIMET NË SAKEL PARA TË PARËS,

I PËRSHTATSHËM PËR SETIN FILTER:

VENDOSI FILLIMIN E SOSJEVE.

NËSE KËNAQEN NJË REKORD TJETËR

FILTER TE

FSHINI NJË REGJISTRI TJETËR NGA SOSJETA.

TË GJITHA NËSE

BYE

NËSE HYRJA NUK FSHIHET ATHERE

LLOJ "REGJISTRIMET NUK FSHIHEN".

PRINTO "REMOVED n RECORDS".

TË GJITHA NËSE

Oriz. 8.4. Një shembull i një hapi të detajimit në pseudokod.

Ideja e detajimit hap pas hapi ndonjëherë i atribuohet Dijkstra. Megjithatë, Dijkstra propozoi një metodë thelbësisht të ndryshme për ndërtimin e tekstit të një moduli, e cila na duket të jetë më e thellë dhe më premtuese. Së pari, së bashku me përsosjen e operatorëve, ai propozoi që gradualisht (hap pas hapi) të përsosin (detajojnë) strukturat e të dhënave të përdorura. Së dyti, në çdo hap ai propozoi krijimin e një makine virtuale për detajimin dhe, në termat e saj, për të përmirësuar të gjitha konceptet e rafinuara për të cilat kjo makinë lejon ta bëjë këtë. Kështu, Dijkstra propozoi, në thelb, detajimin sipas shtresave horizontale, që është transferimi i idesë së tij për sistemet me shtresa (shih Leksionin 6) në nivelin e zhvillimit të modulit. Kjo metodë e zhvillimit të modulit aktualisht mbështetet nga paketat e gjuhës ADA dhe mjetet e programimit të orientuara nga objekti.
8.4. Kontrolli i modulit të softuerit.
Zbatohen metodat e mëposhtme të kontrollit të modulit të programit:
kontroll statik i tekstit të modulit;
gjurmimi nga fundi në fund;
dëshmi e vetive të modulit të softuerit.
Gjatë kontrollit statik të tekstit të një moduli, ky tekst lexohet nga fillimi në fund për të gjetur gabime në modul. Zakonisht, përveç zhvilluesit të modulit, një më shumë apo edhe disa programues përfshihen për një kontroll të tillë. Rekomandohet që gabimet e zbuluara gjatë një kontrolli të tillë të korrigjohen jo menjëherë, por pas përfundimit të leximit të tekstit të modulit.
Ndjekja nga fundi në fund është një nga llojet e kontrollit dinamik të modulit. Ai gjithashtu përfshin disa programues që qarkullojnë manualisht në ekzekutimin e modulit (deklaratë sipas deklaratës në sekuencën që rrjedh nga logjika e modulit) në një grup të caktuar testesh.
Leksioni tjetër i kushtohet vërtetimit të vetive të programeve. Këtu duhet të theksohet vetëm se kjo metodë përdoret ende shumë rrallë.
Literatura për leksionin 8.
8.2. E. Dijkstra. Shënime mbi programimin e strukturuar// W. Dahl, E. Dijkstra, K. Hoor. Programimi strukturor. - M.: Mir, 1975. - S. 24-97.
8.3. N. Wirth. Programimi sistematik. - M.: Mir, 1977. - S. 94-164.
Leksioni 9
Koncepti i justifikimit të programit. Formalizimi i vetive të programit, triada e Hoor-it. Rregullat për vendosjen e vetive të një operatori caktimi, operatori të kushtëzuar dhe operatori i përbërë. Rregullat për vendosjen e vetive të një operatori cikli, koncepti i një laku të pandryshueshëm. Përfundimi i ekzekutimit të programit.
9.1. Arsyetimet e programit. Formalizimi i vetive të programit.
Për të përmirësuar besueshmërinë e mjeteve softuerike, është shumë e dobishme të furnizohen programe informacion shtese, me përdorimin e të cilave është e mundur të rritet ndjeshëm niveli i kontrollit të SP. Një informacion i tillë mund të jepet në formën e deklaratave joformale ose formale që janë të lidhura me fragmente të ndryshme të programit. Pohime të tilla do t'i quajmë justifikime programore. Substancat joformalizuese të programeve, për shembull, mund të shpjegojnë motivet e marrjes së vendimeve të caktuara, të cilat mund të lehtësojnë shumë kërkimin dhe korrigjimin e gabimeve, si dhe studimin e programeve gjatë mirëmbajtjes së tyre. Justifikimet e formalizuara bëjnë të mundur vërtetimin e disa vetive të programeve si manualisht ashtu edhe kontrollimin (vendosjen) e tyre automatikisht.
Një nga konceptet e përdorura aktualisht të justifikimeve formale për programet është përdorimi i të ashtuquajturave treshe të Hoorit. Le të jetë S një operator i përgjithësuar mbi mjedisin e informacionit IS, P dhe Q - disa kallëzues (deklarata) mbi këtë mjedis. Atëherë shënimi (P)S(Q) quhet treshe Hoor, në të cilën kallëzuesi P quhet parakusht, dhe kallëzuesi Q quhet kushti pas në lidhje me operatorin S. Operatori (në veçanti, programi) S thuhet se ka vetinë (P)S(Q), nëse sa herë që kallëzuesi P është i vërtetë përpara se të ekzekutohet S, kallëzuesi Q është i vërtetë pasi të ekzekutohet S.
Shembuj të thjeshtë të vetive të programit:
(9.1) (n=0) n:=n+1 (n=1),
(9.2) (n
(9.3) (n
(9.4) (n>0) p:=1; m:=1;
NDERSA m /= n BËJ
BYE
Për të vërtetuar vetinë e programit S, ne përdorim vetitë e operatorëve të thjeshtë të gjuhës së programimit (këtu kufizohemi në operatorin bosh dhe operatorin e caktimit) dhe vetitë e strukturave të kontrollit (kompozimeve) me të cilat është ndërtuar programi. operatorë të thjeshtë (ne kufizojmë veten këtu në tre kompozime kryesore të programimit të strukturuar, shih Leksionin 8). Këto veti zakonisht quhen rregulla të verifikimit të programit.
9.2. Vetitë e operatorëve të thjeshtë.
Për një operator bosh,
Teorema 9.1. Le të jetë P një kallëzues mbi mjedisin e informacionit. Atëherë vetia (P)(P) qëndron.
Vërtetimi i kësaj teoreme është i qartë: operatori bosh nuk e ndryshon gjendjen e mjedisit të informacionit (në përputhje me semantikën e tij), kështu që parakushti i tij mbetet i vërtetë pas ekzekutimit të tij.
Për operatorin e caktimit,
Teorema 9.2. Lëreni mjedisin e informacionit IS të përbëhet nga ndryshorja X dhe pjesa tjetër e mjedisit të informacionit RIS:
Pastaj prona
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,
ku F(X, RIS) është një funksion me një vlerë të vetme, Q është një kallëzues.
Dëshmi. Le të jetë i vërtetë predikati Q(F(X0, RIS0), RIS0) përpara ekzekutimit të operatorit të caktimit, ku (X0, RIS0) është një gjendje arbitrare e mjedisit të informacionit IS, pastaj pas ekzekutimit të operatorit të caktimit kallëzuesi Q(X, RIS) do të jetë e vërtetë, kështu që mënyra se si X do të marrë vlerën F(X0, RIS0) dhe gjendja e RIS nuk ndryshohet nga deklarata e caktuar e caktimit, dhe kështu pas ekzekutimit të kësaj deklarate të caktimit në këtë rast
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
Për shkak të arbitraritetit të zgjedhjes së gjendjes së mjedisit të informacionit, teorema vërtetohet.
Një shembull i një vetie të një operatori caktimi është Shembulli 9.1.
9.3. Vetitë e strukturave bazë të programimit strukturor.
Konsideroni tani vetitë e strukturave kryesore të programimit të strukturuar: ndjekja, degëzimi dhe përsëritja.
Vetitë e vazhdimësisë shprehen me sa vijon
Teorema 9.3. Le të jenë P, Q dhe R kallëzues mbi mjedisin e informacionit dhe S1 dhe S2 të jenë operatorë të përgjithësuar që kanë, përkatësisht, vetitë
(P)S(Q) dhe (Q)S2(R).
Pastaj për operatorin e përbërë
S1; S2<.blockquote>
ka një pronë
(P) S1; S2(R) .
Dëshmi. Le të jetë e vërtetë kallëzuesi P për disa gjendje të mjedisit të informacionit përpara ekzekutimit të operatorit S1. Pastaj, në bazë të vetive të operatorit S1, pas ekzekutimit të tij, kallëzuesi Q do të jetë i vërtetë duke ekzekutuar operatorin S2. Rrjedhimisht, pas ekzekutimit të operatorit S2, për shkak të vetive të tij, kallëzuesi R do të jetë i vërtetë dhe meqenëse operatori S2 përfundon ekzekutimin e deklaratës së përbërë (në përputhje me semantikën e tij), kallëzuesi R do të jetë i vërtetë pas ekzekutimi i kësaj deklarate të përbërë, që kërkohej të vërtetohej.
Për shembull, nëse vetitë (9.2) dhe (9.3) qëndrojnë, atëherë
vendin dhe pronën
(n
Vetia e degëzimit shprehet si më poshtë
Teorema 9.4. Le të jenë P, Q dhe R kallëzues mbi mjedisin e informacionit dhe S1 dhe S2 të jenë operatorë të përgjithësuar që kanë, përkatësisht, vetitë
(P,Q)S1(R) dhe (`P,Q)S2(R).
Pastaj për operatorin e kushtëzuar
NESE P ATHESH S1 TJETER S2 TE GJITHA NESE
ka një pronë
(Q) NËSE P ATHESH S1 TJETËR S2 TË GJITHA NËSE (R) .
Dëshmi. Le të jetë i vërtetë kallëzuesi Q për disa gjendje të mjedisit të informacionit përpara ekzekutimit të operatorit të kushtëzuar. Nëse kallëzuesi P është gjithashtu i vërtetë, atëherë ekzekutimi i operatorit të kushtëzuar në përputhje me semantikën e tij reduktohet në ekzekutimin e operatorit S1. . Në bazë të vetive të operatorit S1, pas ekzekutimit të tij (dhe në këtë rast, pas ekzekutimit të operatorit të kushtëzuar), kallëzuesi R do të jetë i vërtetë. Nëse, para ekzekutimit të operatorit të kushtëzuar, kallëzuesi P është i rremë. (dhe Q është ende e vërtetë), atëherë ekzekutimi i operatorit të kushtëzuar në përputhje me semantikën e tij reduktohet në ekzekutimin e operatorit S2. Në bazë të vetive të operatorit S2, pas ekzekutimit të tij (dhe në këtë rast, pas ekzekutimit të operatorit të kushtëzuar), kallëzuesi R do të jetë i vërtetë. Kështu, teorema vërtetohet plotësisht.
Para se të vazhdohet me vetinë e konstruksionit të përsëritjes, duhet të theksohet se është i dobishëm për më tej
Teorema 9.5. Le të jenë P, Q, P1 dhe Q1 kallëzues mbi mjedisin e informacionit për të cilin implikimet
P1=>P dhe Q=>Q1,
dhe le të mbahet vetia (P)S(Q) për operatorin S. Më pas vlen vetia (P1)S(Q1).
Kjo teoremë quhet edhe teorema e vetive të dobësimit.
Dëshmi. Le të jetë i vërtetë kallëzuesi P1 për disa gjendje të mjedisit të informacionit përpara ekzekutimit të operatorit S. Atëherë kallëzuesi P do të jetë gjithashtu i vërtetë (për shkak të nënkuptimit P1=>P). Prandaj, në bazë të vetive të operatorit S, pas ekzekutimit të tij, kallëzuesi Q do të jetë i vërtetë, dhe rrjedhimisht kallëzuesi Q1 (në bazë të nënkuptimit Q=>Q1). Kështu vërtetohet teorema.
Vetia e përsëritjes shprehet me sa vijon
Teorema 9.6. Le të jenë I, P, Q dhe R kallëzues mbi mjedisin e informacionit për të cilin implikimet
P=>I dhe (I,`Q)=>R,
dhe le të jetë S një operator i përgjithësuar me vetinë (I)S(I).
Pastaj për operatorin e ciklit
BYE Q DO S TË GJITHA BYE
ka një pronë
(P) BYE Q BY TË GJITHA BYE (R) .
Kallëzuesi I quhet invariant i operatorit të ciklit.
Dëshmi. Për të vërtetuar këtë teoremë, mjafton të vërtetohet vetia
(I) BYE Q BY TË GJITHA BYE (I,`Q)
(nga Teorema 9.5 në bazë të implikimeve në kushtet e kësaj teoreme). Le të jetë i vërtetë kallëzuesi I për disa gjendje të mjedisit të informacionit përpara ekzekutimit të operatorit të ciklit. Nëse, në këtë rast, kallëzuesi Q është i gabuar, atëherë operatori i ciklit do të jetë i barabartë me një operator bosh (në përputhje me semantikën e tij ) dhe, në bazë të teoremës 9.1, pas ekzekutimit të operatorit të ciklit, deklaratën (I ,`Q). Nëse, megjithatë, kallëzuesi Q është i vërtetë përpara ekzekutimit të operatorit të ciklit, atëherë operatori i ciklit, në përputhje me semantikën e tij, mund të përfaqësohet si një operator i përbërë S; BYE Q DO S TË GJITHA BYE
Në bazë të vetive të operatorit S, pas ekzekutimit të tij, kallëzuesi I do të jetë i vërtetë dhe lind situata fillestare për të vërtetuar vetinë e operatorit të ciklit: kallëzuesi I është i vërtetë përpara ekzekutimit të operatorit të ciklit, por për një gjendje e ndryshme (e ndryshuar) e mjedisit të informacionit (për të cilën kallëzuesi Q mund të jetë i vërtetë ose i gabuar). Nëse ekzekutimi i deklaratës së ciklit përfundon, atëherë duke aplikuar metodën e induksionit matematik, në një numër të kufizuar hapash do të arrijmë në një situatë ku pohimi (I,`Q) do të jetë i vërtetë përpara ekzekutimit të tij. Dhe në këtë rast, siç u vërtetua më lart, kjo deklaratë do të jetë e vërtetë edhe pas ekzekutimit të deklaratës së ciklit. Teorema është vërtetuar.
Për shembull, për operatorin e ciklit nga shembulli (9.4), vetia zë vend
m:= m+1; p:= p*m
TË GJITHA ENDESH (p= n.!}
Kjo rrjedh nga teorema 9.6, pasi invarianti i këtij operatori të ciklit është kallëzuesi p=m! dhe implikimet (n>0, p=1, m=1) => p=m! dhe (p=m!, m=n) => p=n!
9.4. Përfundimi i ekzekutimit të programit.
Një nga vetitë e programit që mund të na interesojë për të shmangur gabimet e mundshme në PS është përfundimi i tij, d.m.th. mungesa e çiklizmit në të për të dhëna fillestare të caktuara. Në programet e strukturuara që kemi shqyrtuar, vetëm konstrukti i përsëritjes mund të jetë burimi i ciklit. Prandaj, për të vërtetuar përfundimin e një programi, mjafton të jemi në gjendje të vërtetojmë përfundimin e një operatori cikli. Më poshtë është e dobishme për këtë.
Teorema 9.7. Le të jetë F një funksion numër i plotë që varet nga gjendja e mjedisit të informacionit dhe që plotëson kushtet e mëposhtme:
(1) nëse për gjendjen e dhënë mjedisi informativ, kallëzuesi Q është i vërtetë, atëherë vlera e tij është pozitive;
(2) zvogëlohet kur gjendja e mjedisit të informacionit ndryshon si rezultat i ekzekutimit të operatorit S.
Pastaj ekzekutimi i deklaratës loop
NDERSA QE BËNI GJITHÇKA NDËRSA përfundon.
Dëshmi. Le të jetë gjendja e mjedisit të informacionit përpara ekzekutimit të deklaratës së ciklit dhe le të jetë F(is)=k. Nëse kallëzuesi Q(is) është false, atëherë ekzekutimi i deklaratës së ciklit përfundon. Nëse Q(është) është e vërtetë, atëherë me supozimin e teoremës k>0. Në këtë rast, deklarata S do të ekzekutohet një ose më shumë herë. Pas çdo ekzekutimi të operatorit S, sipas kushtit të teoremës, vlera e funksionit F zvogëlohet, dhe meqenëse para ekzekutimit të operatorit S, kallëzuesi Q duhet të jetë i vërtetë (sipas semantikës së operatorit të ciklit) , vlera e funksionit F në këtë moment duhet të jetë pozitive (sipas kushtit të teoremës). Prandaj, për shkak të integritetit të funksionit F, operatori S në këtë cikël mund të ekzekutohet më shumë se k herë. Teorema është vërtetuar.
Për shembull, për shembullin e operatorit të ciklit të konsideruar më sipër, kushtet e teoremës 9.7 plotësohen nga funksioni f(n, m)= n-m. Pasi që para ekzekutimit të deklaratës së ciklit m=1, trupi i këtij cikli do të ekzekutohet (n-1) herë, d.m.th. kjo deklaratë e ciklit përfundon.
9.5. Një shembull i vërtetimit të vetive të programit.
Bazuar në rregullat e provuara për verifikimin e programit, është e mundur të vërtetohen vetitë e programeve që përbëhen nga deklarata të detyrave dhe deklarata boshe dhe duke përdorur tre kompozime bazë të programimit të strukturuar. Për ta bërë këtë, duke analizuar strukturën e programit dhe duke përdorur kushtet e tij para dhe pas, është e nevojshme të zbatohet një rregull i përshtatshëm verifikimi në çdo hap të analizës. Në rastin e përbërjes së përsëritjes, do të jetë e nevojshme të zgjidhni një invariant të përshtatshëm të ciklit.
Si shembull, le të provojmë pronësinë (9.4). Kjo provë do të përbëhet nga hapat e mëposhtëm.
(Hapi 1). n>0 => (n>0, p - çdo, m - çdo).
(Hapi 2). Ndodh
(n>0, p - çdo, m - çdo) p:=1 (n>0, p=1, m - çdo).
Nga teorema 9.2.
(Hapi 3). Ndodh
(n>0, p=1, m - çdo) m:=1 (n>0, p=1, m=1).
Nga teorema 9.2.
(Hapi 4). Ndodh
(n>0, p - çdo, m - çdo) p:=1; m:=1 (n>0, p=1, m=1).
Nga teorema 9.3, për shkak të rezultateve të hapave 2 dhe 3.
Le të vërtetojmë se kallëzuesi p=m! është një cikli invariant, d.m.th. (p=m m:=m+1; p:=p*m {p=m!}.!}
(Hapi 5). Zhvillohet (p=m m:=m+1 {p=(m-1)!}.!}
Nga teorema 9.2, nëse parakushtin e paraqesim në formën (p=((m+1)-1).!}
(Hapi 6). Zhvillohet (p=(m-1) p:=p*m {p=m!}.!}
Nga teorema 9.2, nëse parakushtin e paraqesim në formën (p*m=m.!}
(Hapi 7). Ekziston një cikël invariant
(p=m m:=m+1; p:=p*m {p=m!}.!}
Nga teorema 9.3, për shkak të rezultateve të hapave 5 dhe 6.
(Hapi 8). Ndodh
(n>0, p=1, m=1) NDERSA m /= n DO
m:= m+1; p:= p*m
TË GJITHA ENDESH (p= n.!}
Nga teorema 9.6, në bazë të rezultatit të hapit 7 dhe duke pasur parasysh se (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(Hapi 9). Ndodh
(n>0, p - çdo, m - çdo) p:=1; m:=1;
NDERSA m /= n BËJ
m:= m+1; p:= p*m
TË GJITHA ENDESH (p= n.!}
Nga teorema 9.3, për shkak të rezultateve të hapave 3 dhe 8.
(Hapi 10). Vetia (9.4) mbahet nga teorema 9.5 për shkak të rezultateve të hapave 1 dhe 9.
Literatura për leksionin 9.
9.1. S.A. Abramov. Elementet e programimit. - M.: Nauka, 1982. S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Parimet e zhvillimit të softuerit. - M.: Mir, 1982. S. 98-105.
Leksioni 10
Konceptet bazë. Strategjia e projektimit të testit. Urdhërimet e korrigjimit. Korrigjimi jashtë linje dhe testimi i një moduli softueri. Korrigjimi dhe testimi gjithëpërfshirës i softuerit.
10.1. Konceptet bazë.
Korrigjimi i PS-së është një aktivitet që synon zbulimin dhe korrigjimin e gabimeve në PS duke përdorur proceset e ekzekutimit të programeve të tij. Testimi PS është procesi i ekzekutimit të programeve të tij në një grup të caktuar të dhënash, për të cilin rezultati i aplikimit dihet paraprakisht ose dihen rregullat për sjelljen e këtyre programeve. Grupi i specifikuar i të dhënave quhet test ose thjesht test. Kështu, korrigjimi mund të përfaqësohet si një përsëritje e përsëritur e tre proceseve: testimi, si rezultat i të cilit mund të konstatohet prania e një gabimi në PS, kërkimi i vendit të një gabimi në programet dhe dokumentacionin e PS, dhe redaktimi i programeve dhe dokumentacionit në mënyrë që të eliminohet gabimi i zbuluar. Me fjale te tjera:
Korrigjimi = Testim + Gjetja e gabimeve + Redaktimi.
Në literaturën e huaj, korrigjimi shpesh kuptohet vetëm si një proces i gjetjes dhe korrigjimit të gabimeve (pa testim), prania e të cilave vërtetohet gjatë testimit. Ndonjëherë testimi dhe korrigjimi konsiderohen sinonime. Në vendin tonë, koncepti i korrigjimit zakonisht përfshin testimin, ndaj ne do të ndjekim traditën e vendosur. Megjithatë, shqyrtimi i përbashkët i këtyre proceseve në këtë leksion e bën mospërputhjen e treguar jo aq të rëndësishme. Megjithatë, duhet theksuar se testimi përdoret gjithashtu si pjesë e procesit të certifikimit të PS (shih leksionin 14).
10.2. Parimet dhe llojet e korrigjimit.
Suksesi i korrigjimit përcaktohet kryesisht nga organizimi racional i testimit. Gjatë korrigjimit, kryesisht gjenden dhe eliminohen ato gabime, prania e të cilave në PS konstatohet gjatë testimit. Siç është përmendur tashmë, testimi nuk mund të vërtetojë korrektësinë e PS, në rastin më të mirë mund të tregojë praninë e një gabimi në të. Me fjalë të tjera, nuk mund të garantohet që duke testuar softuerin me një grup testesh praktikisht të realizueshme, është e mundur të përcaktohet prania e çdo gabimi të pranishëm në softuer. Prandaj lindin dy probleme. Së pari, përgatitni një grup të tillë testesh dhe aplikoni PS për to në mënyrë që të zbuloni sa më shumë gabime në të. Megjithatë, sa më gjatë të vazhdojë procesi i testimit (dhe korrigjimi në përgjithësi), aq më e madhe bëhet kostoja e softuerit. Prandaj detyra e dytë: të përcaktohet momenti kur ka përfunduar korrigjimi i PS (ose përbërësve të tij individualë). Shenjë e mundësisë së përfundimit të korrigjimit është plotësia e mbulimit nga testet e kaluara përmes PS (d.m.th., testet në të cilat aplikohet PS) e shumë situatave të ndryshme që lindin gjatë ekzekutimit të programeve PS, dhe manifestim relativisht i rrallë i gabimeve në PS në segmentin e fundit të procesit të testimit. Kjo e fundit përcaktohet në përputhje me shkallën e kërkuar të besueshmërisë së PS, të specifikuar në specifikimin e cilësisë së tij.
Për të optimizuar grupin e testimit, d.m.th. për të përgatitur një grup të tillë testesh që do të lejonte, me një numër të caktuar të tyre (ose me një interval të caktuar kohor të caktuar për testim), të zbulonte më shumë gabimet, është e nevojshme, së pari, të planifikohet paraprakisht ky grup dhe, së dyti, të përdoret një strategji racionale për planifikimin (projektimin) e testeve. Dizajni i testit mund të fillojë menjëherë pas përfundimit të fazës së përshkrimit të jashtëm të PS. Ekzistojnë qasje të ndryshme për zhvillimin e një strategjie të projektimit të testit, e cila mund të vendoset me kusht në mënyrë grafike (shih Figurën 9.1) midis dy qasjeve ekstreme të mëposhtme. Qasja e majtë ekstreme është që testet janë krijuar vetëm në bazë të studimit të specifikimeve të PS (përshkrimi i jashtëm, përshkrimi i arkitekturës dhe specifikimi i modulit). Struktura e moduleve nuk merret parasysh në asnjë mënyrë, d.m.th. ato trajtohen si kuti të zeza. Në fakt, kjo qasje kërkon një numërim të plotë të të gjitha grupeve të të dhënave hyrëse, pasi kur përdoret vetëm një pjesë e këtyre grupeve si teste, disa pjesë të programeve PS mund të mos funksionojnë në asnjë provë dhe, për rrjedhojë, gabimet e përfshira në to nuk do të funksionojnë. shfaqen. Sidoqoftë, testimi i PS me një grup të plotë të të dhënave hyrëse është praktikisht i pamundur. Qasja e drejtë ekstreme është se testet janë krijuar bazuar në studimin e teksteve të programit në mënyrë që të testohen të gjitha mënyrat në të cilat ekzekutohet çdo program PS. Nëse marrim parasysh praninë e cikleve me një numër të ndryshueshëm përsëritjesh në programe, atëherë mund të ketë gjithashtu një numër jashtëzakonisht të madh mënyrash të ndryshme të ekzekutimit të programeve PS, kështu që testimi i tyre gjithashtu do të jetë praktikisht i pamundur.
Strategjia optimale e projektimit të testit ndodhet brenda intervalit midis këtyre qasjeve ekstreme, por më afër majtas. Ai përfshin hartimin e një pjese të madhe të testeve sipas specifikimeve, bazuar në parimet: për çdo funksion ose veçori të përdorur - të paktën një test, për secilën zonë dhe për çdo kufi ndryshimi në çdo variabël hyrës - të paktën një test, për secilën rast i veçantë ose për çdo përjashtim të specifikuar në specifikime - të paktën një test. Por kërkon gjithashtu hartimin e disa testeve dhe teksteve të programeve, bazuar në parimin (në minimum): çdo komandë e çdo programi PS duhet të punojë në të paktën një test.
Strategjia optimale e projektimit të testit mund të specifikohet bazuar në parimin e mëposhtëm: për çdo dokument programi (përfshirë tekstet e programit), që është pjesë e SP-së, duhet të hartojnë testet e tyre për të identifikuar gabimet në të. Në çdo rast, ky parim duhet të respektohet në përputhje me përkufizimin e softuerit dhe përmbajtjen e konceptit të teknologjisë së programimit si një teknologji për zhvillimin e softuerit të besueshëm (shih leksionin 1). Në këtë drejtim, Myers madje përcakton lloje të ndryshme të testimit, varësisht nga lloji i dokumentit të programit në bazë të të cilit janë ndërtuar testet. Në vendin tonë, ekzistojnë dy lloje kryesore të korrigjimit (përfshirë testimin): korrigjimi i pavarur dhe korrigjimi kompleks. Korrigjimi offline nënkupton testimin e vetëm një pjese të programit të përfshirë në PS, me kërkimin dhe korrigjimin e gabimeve të regjistruara gjatë testimit. Në fakt përfshin korrigjimin e çdo moduli dhe korrigjimin e çiftimit të modulit. Korrigjimi gjithëpërfshirës nënkupton testimin e PS në tërësi me kërkimin dhe korrigjimin e gabimeve të regjistruara gjatë testimit në të gjitha dokumentet (duke përfshirë tekstet e programeve PS) që lidhen me PS në tërësi. Dokumentet e tilla përfshijnë përcaktimin e kërkesave për PS, specifikimin e cilësisë së PS, specifikimin funksional të PS, përshkrimin e arkitekturës së PS dhe tekstet e programeve të PS.
10.3. Urdhërimet e korrigjimit.
Ky seksion ofron udhëzime të përgjithshme për organizimin e korrigjimit. Por së pari, duhet theksuar një fenomen që konfirmon rëndësinë e parandalimit të gabimeve në fazat e mëparshme të zhvillimit: me rritjen e numrit të gabimeve të zbuluara dhe korrigjuara në softuer, rritet edhe probabiliteti relativ i ekzistencës së gabimeve të pazbuluara në të. Kjo shpjegohet me faktin se me një rritje të numrit të gabimeve të gjetura në PS, të kuptuarit tonë për numrin e përgjithshëm të gabimeve të bëra në të, dhe për rrjedhojë, në një farë mase, edhe numri i gabimeve të pazbuluara ende përsoset. Ky fenomen konfirmon rëndësinë e zbulimit të hershëm të gabimeve dhe nevojën për kontroll të kujdesshëm të vendimeve të marra në çdo fazë të zhvillimit të softuerit.
Urdhërimi 1. Konsideroni testimin si një detyrë kyçe të zhvillimit të softuerit, besojini programuesve më të kualifikuar dhe të talentuar; është e padëshirueshme të testoni programin tuaj.
Urdhërimi 2. Një test i mirë është ai që ka një probabilitet të lartë për të gjetur një gabim, jo ai që demonstron funksionimin e saktë të programit.
Urdhërimi 3. Përgatitni teste për të dhëna të sakta dhe të pasakta.
Urdhërimi 4. Shmangni testet e pa riprodhueshme, dokumentoni kalimin e tyre nëpër kompjuter; studioni në detaje rezultatet e secilit test.
Urdhërimi 5. Lidhni çdo modul me programin vetëm një herë; kurrë mos modifikoni një program për ta bërë më të lehtë testimin.
Urdhri 6. Kapërceni përsëri të gjitha testet që lidhen me kontrollin e funksionimit të çdo programi PS ose ndërveprimin e tij me programe të tjera, nëse janë bërë ndryshime në të (për shembull, si rezultat i rregullimit të një gabimi).
10.4. Korrigjimi i modulit jashtë linje.
Në korrigjimin jashtë linje, çdo modul testohet në të vërtetë në një mjedis programimi, përveç nëse programi që korrigjohet përbëhet nga vetëm një modul. Ky mjedis përbëhet nga module të tjera, disa prej të cilave janë module të programit të debuguar që tashmë janë korrigjuar, dhe disa prej të cilave janë module që kontrollojnë korrigjimin (modulet e korrigjimit, shih më poshtë). Kështu, gjatë korrigjimit jashtë linje, një program është gjithmonë duke u testuar, i ndërtuar posaçërisht për testimin e modulit që debugohet. Ky program përputhet vetëm pjesërisht me programin që korrigjohet, përveç rasteve kur moduli i fundit i programit që korrigjohet është duke u debuguar. Ndërsa korrigjimi i programit përparon, një pjesë në rritje e mjedisit të modulit tjetër që korrigjohet do të jenë tashmë module të korrigjuara të këtij programi dhe kur korrigjoni modulin e fundit të këtij programi, mjedisi i modulit që korrigjohet do të përbëhet tërësisht nga të gjitha modulet e tjera (tashmë të debuguara) të programit që po korrigjohen (pa asnjë) module korrigjimi. modulet, d.m.th. në këtë rast, vetë programi i debuguar do të testohet. Ky proces i ndërtimit të një programi të korrigjuar me module të korrigjuara dhe të korrigjuara quhet integrim i programit.
Modulet e korrigjimit të përfshirë në mjedisin e modulit që korrigjohet varen nga radha në të cilën korrigjohen modulet e atij programi, cili modul po korrigjohet dhe ndoshta cili test do të anashkalohet.
Në testimin nga poshtë-lart (shih Kapitullin 7), ky mjedis do të përmbajë gjithmonë vetëm një modul korrigjimi (përveç rasteve kur moduli i fundit i programit që debugohet është duke u debuguar), i cili do të jetë kreu i programit nën testim dhe i cili quhet mjeshtri (ose shoferi). Moduli kryesor i korrigjimit përgatit mjedisin e informacionit për testimin e modulit që korrigjohet (d.m.th., formon gjendjen e tij të kërkuar për testimin e këtij moduli; në veçanti, ai mund të fusë disa të dhëna testimi), thërret modulin që po korrigjohet dhe, pasi të jetë kryer puna e tij. përfunduar, lëshon mesazhet e nevojshme. Kur korrigjoni një modul, module të ndryshme kryesore të korrigjimit mund të përpilohen për teste të ndryshme.
Në testimin në rënie (shih Kapitullin 7), mjedisi i modulit që korrigjohet përmban, si module korrigjimi, simulatorë të të gjitha moduleve që mund të aksesohen nga moduli që po korrigjohet, si dhe simulatorë të atyre moduleve që mund të aksesohen nga të korrigjuarit. modulet e programit që po korrigjohen (të përfshira në këtë mjedis), por që ende nuk janë debuguar. Disa nga këta simulatorë mund të ndryshojnë për teste të ndryshme kur korrigjoni një modul.
Në fakt, mjedisi i modulit që korrigjohet në shumë raste mund të përmbajë të dy llojet e moduleve të korrigjimit për arsyet e mëposhtme. Si testimi në rritje ashtu edhe në rënie kanë avantazhet dhe disavantazhet e tyre.
Përfitimet e testimit nga poshtë-lart përfshijnë
lehtësinë e përgatitjes së testeve dhe
aftësia për të zbatuar plotësisht planin e testimit të modulit.
Kjo për faktin se gjendja e testimit të mjedisit të informacionit përgatitet menjëherë përpara thirrjes për modulin që po korrigjohet (moduli kryesor i korrigjimit). Disavantazhet e testimit nga poshtë-lart janë karakteristikat e mëposhtme:
të dhënat e testit përgatiten, si rregull, jo në formën që është krijuar për përdoruesin (përveç rastit kur moduli i fundit, kreu, i programit që debugohet është debuguar);
një sasi e madhe programimi korrigjimi (kur korrigjoni një modul, shpesh duhet të kompozoni shumë module kryesore korrigjimi për teste të ndryshme);
nevoja për testim special të moduleve të ndërfaqes.
Përparësitë e testimit nga lart-poshtë përfshijnë karakteristikat e mëposhtme:
shumica e testeve përgatiten në një formë të krijuar për përdoruesit;
në shumë raste, një sasi relativisht e vogël e programimit të korrigjimit (simuluesit e moduleve, si rregull, janë shumë të thjeshtë dhe secili është i përshtatshëm për një numër të madh, shpesh për të gjithë, teste);
nuk ka nevojë të testoni çiftimin e moduleve.
Disavantazhi i testimit nga lart-poshtë është se gjendja e testimit të mjedisit të informacionit përpara se të qaseni në modulin që debugohet përgatitet në mënyrë indirekte - është rezultat i aplikimit të moduleve tashmë të korrigjuara për të testuar të dhënat ose të dhënat e lëshuara nga simuluesit. Kjo, së pari, e bën të vështirë përgatitjen e testeve, kërkon ekzekutues shumë të kualifikuar të testit dhe së dyti, e bën të vështirë apo edhe të pamundur zbatimin e një plani të plotë testimi për modulin që po debugohet. Kjo mangësi ndonjëherë i detyron zhvilluesit të përdorin testimin nga poshtë-lart edhe në rastin e zhvillimit nga lart-poshtë. Megjithatë, më shpesh, përdoren disa modifikime të testimit nga lart-poshtë, ose një kombinim i testimit nga lart-poshtë dhe nga poshtë-lart.
Duke u bazuar në faktin se testimi nga lart-poshtë është, në parim, i preferueshëm, le të ndalemi te teknikat që na lejojnë t'i kapërcejmë deri diku këto vështirësi. Para së gjithash, është e nevojshme të organizohet korrigjimi i programit në atë mënyrë që modulet që kryejnë futjen e të dhënave të korrigjohen sa më shpejt të jetë e mundur - atëherë të dhënat e testimit mund të përgatiten në një formë të krijuar për përdoruesin, gjë që do të thjeshtojnë përgatitjen e testeve të mëpasshme. Kjo hyrje nuk kryhet në asnjë mënyrë gjithmonë në modulin e kokës, kështu që së pari duhet të korrigjoni zinxhirët e moduleve që të çojnë në modulet që kryejnë hyrjen e specifikuar (krh. me metodën e zbatimit të qëllimshëm konstruktiv në Leksionin 7). Ndërkohë që modulet hyrëse nuk janë korrigjuar, të dhënat e testimit sigurohen nga disa simulatorë: ato ose përfshihen në simulator si pjesë e tij, ose futen nga ky simulator.
Në testimin nga lart-poshtë, disa gjendje të mjedisit të informacionit sipas të cilave kërkohet të testohet moduli që korrigjohet mund të mos ndodhin gjatë ekzekutimit të programit që korrigjohet për ndonjë hyrje. Në këto raste, do të ishte e mundur të mos testohej fare moduli që po korrigjohet, pasi gabimet e zbuluara në këtë rast nuk do të shfaqen kur programi që debugohet të ekzekutohet nën ndonjë të dhënë hyrëse. Sidoqoftë, nuk rekomandohet ta bëni këtë, pasi kur programi që korrigjohet ndryshon (për shembull, kur mirëmbahet PS), mund të shfaqen tashmë gjendjet e mjedisit të informacionit që nuk janë përdorur për testimin e modulit që po korrigjohet, gjë që kërkon shtesë testimi i këtij moduli (dhe kjo, me një organizim racional të korrigjimit, nuk mund të bëhej nëse vetë moduli nuk ka ndryshuar). Për të testuar modulin që korrigjohet në këto situata, ndonjëherë përdoren simulatorë të përshtatshëm për të krijuar gjendjen e kërkuar të mjedisit të informacionit. Më shpesh, përdoret një version i modifikuar i testimit nga lart-poshtë, në të cilin modulet që korrigjohen para-testohen veçmas përpara se të integrohen (në këtë rast, një modul kryesor korrigjimi shfaqet në mjedisin e modulit që korrigjohet, së bashku me modulin simulatorët që mund të aksesohen nga moduli që po debugohet). Megjithatë, një modifikim tjetër i testimit nga lart-poshtë duket të jetë më i përshtatshëm: pasi të përfundojë testimi nga lart-poshtë i modulit që po korrigjohet për gjendjet e testimit të arritshëm të mjedisit të informacionit, ai duhet të testohet veçmas për gjendjet e mbetura të kërkuara të informacionit. mjedisi.
Shpesh përdoret edhe një kombinim i testimit nga poshtë-lart dhe nga poshtë-lart, i cili quhet metoda sanduiç. Thelbi i kësaj metode qëndron në zbatimin e njëkohshëm të testimit si lart ashtu edhe në rënie derisa këto dy procese testimi të takohen në një modul diku në mes të strukturës së programit që debugohet. Kjo metodë lejon, me një qasje të arsyeshme, të përfitojë nga avantazhet e testimit nga poshtë-lart dhe nga lart-poshtë dhe në një masë të madhe të neutralizojë mangësitë e tyre. Ky efekt është një manifestim i parim i përgjithshëm: efekti më i madh teknologjik mund të arrihet duke kombinuar metodat nga lart-poshtë dhe nga poshtë-lart për zhvillimin e programeve OS. Është për të mbështetur këtë metodë që është projektuar qasja arkitekturore ndaj zhvillimit të softuerit (shih Leksionin 7): një shtresë modulesh të mirë-projektuara dhe të testuara me kujdes lehtëson shumë zbatimin e një familjeje programesh në fushën përkatëse lëndore dhe modernizimin e tyre pasues.
Shumë e rëndësishme në korrigjimin jashtë linje është testimi i çiftimit të moduleve. Fakti është se specifikimi i secilit modul programi, përveç atij kryesor, përdoret në këtë program në dy situata: së pari, kur zhvillohet teksti (nganjëherë thonë: trupi) i këtij moduli dhe, së dyti, kur shkruani një apeloni për këtë modul në modulet e tjera të programit. Në të dyja rastet, si rezultat i një gabimi, përputhshmëria e kërkuar me një specifikim të caktuar të modulit mund të shkelet. Gabime të tilla duhet të zbulohen dhe korrigjohen. Ky është qëllimi i testimit të çiftimit të moduleve. Në testimin nga lart-poshtë, testimi i çiftëzimit kryhet gjatë rrugës me çdo test të anashkaluar, i cili konsiderohet si avantazhi më i fortë i testimit nga lart-poshtë. Gjatë testimit nga poshtë-lart, moduli i korrigjuar aksesohet jo nga modulet e programit që korrigjohet, por nga moduli kryesor i korrigjimit. Në këtë drejtim, ekziston rreziku që moduli i fundit të përshtatet me disa "koncepte të gabuara" të modulit që po debugohet. Prandaj, kur filloni (në procesin e integrimit të programit) korrigjimi i një moduli të ri, është e nevojshme të testoni çdo thirrje në një modul të korrigjuar më parë në mënyrë që të zbulohen mospërputhjet midis kësaj thirrjeje dhe trupit të modulit përkatës (dhe është e mundur që Moduli i debuguar më parë është fajtor për këtë). Kështu, është e nevojshme të përsëritet pjesërisht testimi i një moduli të korrigjuar më parë në kushte të reja dhe lindin të njëjtat vështirësi si në rastin e testimit nga lart-poshtë.
Testimi autonom i modulit duhet të kryhet në katër hapa të njëpasnjëshëm.
Hapi 1. Bazuar në specifikimin e modulit që po korrigjoni, përgatitni një test për çdo mundësi dhe situatë, për çdo kufi të diapazoneve të vlerave të vlefshme të të gjitha hyrjeve, për çdo varg ndryshimesh të dhënash, për çdo varg të pavlefshëm të të gjitha hyrjet dhe çdo kusht i pavlefshëm.
Hapi 2. Kontrolloni tekstin e modulit për t'u siguruar që çdo drejtim i çdo dege do të kalojë në të paktën një test. Shtoni testet që mungojnë.
Hapi 3. Verifikoni nga teksti i modulit që për çdo lak ka një test për të cilin trupi i lakut nuk është ekzekutuar, një test për të cilin trupi i ciklit ekzekutohet një herë dhe një test për të cilin trupi i ciklit ekzekutohet numri maksimal i herë. Shtoni testet që mungojnë.
Hapi 4. Kontrolloni tekstin e modulit për ndjeshmërinë e tij ndaj vlerave të veçanta të të dhënave të hyrjes - të gjitha vlerat e tilla duhet të përfshihen në teste. Shtoni testet që mungojnë.
10.5. Korrigjimi kompleks i softuerit.
Siç u përmend më lart, me korrigjimin kompleks, PS në tërësi testohet, dhe testet përgatiten për secilin nga dokumentet PS. Testimi i këtyre dokumenteve kryhet, si rregull, në rendin e kundërt të zhvillimit të tyre (përjashtimi i vetëm është testimi i dokumentacionit të aplikacionit, i cili zhvillohet sipas përshkrimit të jashtëm paralelisht me zhvillimin e teksteve të programit; ky testim është më i miri bëhet pasi të ketë përfunduar testimi i përshkrimit të jashtëm). Testimi në korrigjimin kompleks është aplikimi i PS në të dhëna specifike që, në parim, mund të lindin nga përdoruesi (në veçanti, të gjitha testet përgatiten në një formë të krijuar për përdoruesin), por ndoshta në një formë të simuluar (dhe jo reale) mjedisi. Për shembull, disa pajisje hyrëse dhe dalëse që janë të paarritshme gjatë korrigjimit kompleks mund të zëvendësohen nga simuluesit e tyre softuerësh.
Testimi i arkitekturës PS. Qëllimi i testimit është të gjejë një mospërputhje midis përshkrimit të arkitekturës dhe grupit të programeve të PS. Në kohën kur fillon testimi i arkitekturës PS, korrigjimi autonom i çdo nënsistemi duhet të përfundojë tashmë. Gabimet e zbatimit të arkitekturës mund të shoqërohen kryesisht me ndërveprimin e këtyre nënsistemeve, në veçanti, me zbatimin e funksioneve arkitekturore (nëse ka). Prandaj, do të doja të kontrolloja të gjitha mënyrat e ndërveprimit midis nënsistemeve PS. Por meqenëse mund të ketë shumë prej tyre, do të ishte e dëshirueshme të testoheshin të paktën të gjithë zinxhirët e ekzekutimit të nënsistemeve pa rihyrjen e këtyre të fundit. Nëse arkitektura e dhënë përfaqëson PS-në si një sistem të vogël nënsistemesh të zgjedhura, atëherë numri i zinxhirëve të tillë do të jetë mjaft i dukshëm.
Testimi i funksioneve të jashtme. Qëllimi i testimit është gjetja e mospërputhjeve midis specifikimit funksional dhe grupit të programeve softuerike të PS. Përkundër faktit se të gjitha këto programe tashmë janë korrigjuar në mënyrë të pavarur, këto mospërputhje mund të jenë, për shembull, për shkak të mospërputhjes midis specifikimeve të brendshme të programeve dhe moduleve të tyre (në bazë të të cilave u krye testimi autonom) me atë të jashtëm. specifikimet funksionale të MS. Si rregull, testimi i funksioneve të jashtme bëhet në të njëjtën mënyrë si testimi i moduleve në hapin e parë, d.m.th. si një kuti e zezë.
Testimi i cilësisë së PS. Qëllimi i testimit është kërkimi i shkeljeve të kërkesave të cilësisë të formuluara në specifikimin e cilësisë së PS. Ky është lloji më i vështirë dhe më pak i studiuar i testimit. Është e qartë vetëm se jo çdo primitiv i cilësisë së PS mund të testohet me anë të testimit (shih leksionin tjetër mbi vlerësimin e cilësisë së PS). Plotësia e PS kontrollohet tashmë gjatë testimit të funksioneve të jashtme. Në këtë fazë, testimi i këtij primitiv të cilësisë mund të vazhdohet nëse kërkohet të merret ndonjë vlerësim probabilistik i shkallës së besueshmërisë së PS. Megjithatë, metodologjia për një testim të tillë ende duhet të zhvillohet. Saktësia, qëndrueshmëria, siguria, efikasiteti i përkohshëm, efikasiteti i kujtesës deri në një farë mase, efikasiteti i pajisjes, shtrirja dhe pjesërisht pavarësia e pajisjes mund të testohen. Secili prej këtyre llojeve të testimit ka specifikat e veta dhe meriton shqyrtim të veçantë. Ne do të kufizohemi këtu në renditjen e tyre. Lehtësia e përdorimit të PS (një kriter cilësie që përfshin disa primitivë të cilësisë, shih Leksionin 4) vlerësohet gjatë testimit të dokumentacionit mbi përdorimin e PS.
Dokumentacioni i testimit për aplikimin e SP. Qëllimi i testimit është kërkimi i mospërputhjeve midis dokumentacionit në aplikacion dhe grupit të programeve softuerike, si dhe shqetësimet e përdorimit të softuerit. Kjo fazë i paraprin menjëherë lidhjes së përdoruesit me përfundimin e zhvillimit të PS (testimi i kërkesave për PS dhe certifikimi i PS), kështu që është shumë e rëndësishme që zhvilluesit të përdorin fillimisht vetë PS në mënyrën se si do të bëjë përdoruesi. atë. Të gjitha testet në këtë fazë përgatiten vetëm në bazë të dokumentacionit për aplikimin e PS. Para së gjithash, aftësitë e softuerit duhet të testohen siç është bërë gjatë testimit të funksioneve të jashtme, por vetëm në bazë të dokumentacionit të aplikacionit. Të gjitha vendet e paqarta në dokumentacion duhet të testohen, si dhe të gjithë shembujt e përdorur në dokumentacion. Tjetra, testohen rastet më të vështira të aplikimit të PS për të zbuluar një shkelje të kërkesave për relativitetin e lehtësisë së përdorimit të PS.
Testimi i përcaktimit të kërkesave për SP. Qëllimi i testimit është të zbulohet se në çfarë mase softueri nuk korrespondon me përkufizimin e paraqitur të kërkesave për të. E veçanta e këtij lloji të testimit është se ai kryhet nga organizata blerëse ose organizata e përdoruesit të PS-së si një nga mënyrat për të kapërcyer pengesën midis zhvilluesit dhe përdoruesit (shih leksionin 3). Zakonisht ky testim kryhet me ndihmën e detyrave të kontrollit - detyra tipike për të cilat dihet rezultati i zgjidhjes. Në rastet kur SP-ja e zhvilluar duhet të zëvendësojë një version tjetër të SP-së që zgjidh të paktën një pjesë të detyrave të SP-së së zhvilluar, testimi kryhet duke zgjidhur problemet e zakonshme duke përdorur si SP-në e vjetër ashtu edhe atë të re, e ndjekur nga një krahasim i rezultateve. fituar. Ndonjëherë, si një formë e një testimi të tillë, përdoret funksionimi provë i PS - një aplikim i kufizuar i një PS të re me një analizë të përdorimit të rezultateve në praktikë. Në thelb, ky lloj testimi ka shumë të përbashkëta me testimin e SP-së gjatë certifikimit të tij (shih leksionin 14), por kryhet para certifikimit dhe ndonjëherë në vend të certifikimit.
Literatura për leksionin 10.
10.1. G. Myers. Besueshmëria e softuerit. - M.: Mir, 1980. - S. 171-262.
10.2. D. Van Tassel. Stili, zhvillimi, efikasiteti, programet e korrigjimit dhe testimit. - M.: Mir, 1985. - S. 179-295.
10.3. J. Hughes, J. Michtom. Qasja strukturore te programimi. - M.: Mir, 1980. - S. 254-268.
10.4. J. Fox. Softueri dhe zhvillimi i tij. - M.: Mir, 1985. - S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. Parimet e zhvillimit të softuerit. - M.: Mir, 1982. - S. 105-116.
10.6. Yu.M. Bezborodov. Debugimi individual i programeve. - M.: Nauka, 1982. - S. 9-79.
10.7. V.V. Lipaev. Testimi i programit. - M.: Radio dhe komunikim, 1986. - S. 15-47.
10.8. E.A. Zhogolev. Hyrje në teknologjinë e programimit (shënime leksionesh). - M.: "DIALOG-MGU", 1994.
10.9. E. Dijkstra. Shënime mbi programimin e strukturuar. //U. Dahl, E. Dijkstra, K. Hoor. Programimi strukturor. - M.: Mir, 1975. - S. 7-13.
Leksioni 11
11.1. Funksionaliteti dhe besueshmëria si kritere të detyrueshme për cilësinë e softuerit.
Në leksionet e mëparshme kemi shqyrtuar të gjitha fazat e zhvillimit të SP-së, përveç certifikimit të tij. Në të njëjtën kohë, ne nuk kemi prekur çështjet e sigurimit të cilësisë së SP në përputhje me specifikimet e tij të cilësisë (shih leksionin 4). Vërtetë, gjatë zbatimit të specifikimit funksional të PS, ne diskutuam në këtë mënyrë çështjet kryesore të sigurimit të kriterit të funksionalitetit. Duke deklaruar besueshmërinë e softuerit si atributin e tij kryesor (shih leksionin 1), ne kemi zgjedhur parandalimin e gabimeve si qasjen kryesore për të siguruar besueshmërinë e softuerit (shih leksionin 3) dhe kemi diskutuar zbatimin e tij në faza të ndryshme të zhvillimit të softuerit. Kështu, u shfaq teza për funksionalitetin dhe besueshmërinë e detyrueshme të SP-së si kriter për cilësinë e tij.
Megjithatë, specifikimi i cilësisë së softuerit mund të përmbajë karakteristika shtesë të këtyre kritereve, parashikimi i të cilave kërkon diskutim të veçantë. Këto pyetje janë fokusi i kësaj ligjërate. Sigurimi i kritereve të tjera të cilësisë do të diskutohet në leksionin e ardhshëm.
Sigurimi i primitivëve të cilësisë MS që shprehin kriteret për funksionalitetin dhe besueshmërinë e MS diskutohen më poshtë.
11.2. Sigurimi i plotësisë së softuerit.
Plotësia e PS është një primitiv i përgjithshëm i cilësisë së PS për të shprehur si funksionalitetin ashtu edhe besueshmërinë e PS, dhe për funksionalitetin është i vetmi primitiv (shih Leksionin 4).
Funksionaliteti i PS përcaktohet nga specifikimi i tij funksional. Plotësia e një SP si një primitiv i cilësisë së tij është një masë se si zbatohet ky specifikim në një SP të caktuar. Sigurimi i plotë i këtij primitiv nënkupton zbatimin e secilit prej funksioneve të përcaktuara në specifikimin funksional, me të gjitha detajet dhe veçoritë e treguara aty. Të gjitha proceset teknologjike të diskutuara më parë tregojnë se si mund të bëhet kjo.
Sidoqoftë, disa nivele të zbatimit të funksionalitetit të PS mund të përcaktohen në specifikimin e cilësisë së PS: mund të përcaktohen disa versione të thjeshtuara (fillestare ose fillestare), të cilat duhet të zbatohen së pari, dhe mund të përcaktohen edhe disa versione të ndërmjetme. Në këtë rast, lind një problem shtesë teknologjik: organizimi i rritjes së funksionalitetit të PS. Është e rëndësishme të theksohet këtu se zhvillimi i një versioni të thjeshtuar të PS nuk është zhvillimi i prototipit të tij. Prototipi po zhvillohet për të kuptuar më mirë kushtet për përdorimin e PS-së së ardhshme, për të sqaruar përshkrimin e tij të jashtëm. Është krijuar për përdorues të përzgjedhur dhe për këtë arsye mund të ndryshojë shumë nga PS e kërkuar jo vetëm në funksionet e kryera, por edhe në veçoritë e ndërfaqes së përdoruesit. Një version i thjeshtuar i PS-së së kërkuar duhet të dizajnohet për përdorim praktik nga çdo përdorues për të cilin është menduar. Prandaj, parimi kryesor për sigurimin e funksionalitetit të një OS të tillë është zhvillimi i sistemit operativ që nga fillimi në atë mënyrë sikur të kërkohet i gjithë OS, derisa zhvilluesit të merren me ato pjesë ose detaje të OS, zbatimin e i cili mund të shtyhet sipas specifikimit të tij të cilësisë. Kështu, si përshkrimi i jashtëm ashtu edhe përshkrimi i arkitekturës së PS duhet të zhvillohen plotësisht. Është e mundur të shtyhet vetëm zbatimi i atyre nënsistemeve softuerike të përcaktuara në arkitekturën e SP-së së zhvilluar, funksionimi i të cilave nuk kërkohet në versionin fillestar të kësaj SP. Zbatimi i vetë nënsistemeve softuerike bëhet më së miri me metodën e zbatimit konstruktiv të qëllimshëm, duke lënë në versionin fillestar të PS simulatorët e përshtatshëm të atyre moduleve softuerike që nuk kërkohen në këtë version. Një zbatim i thjeshtuar i disa moduleve softuerike është gjithashtu i pranueshëm, duke lënë mënjanë zbatimin e disa detajeve të funksioneve përkatëse. Sidoqoftë, nga pikëpamja teknologjike, është më mirë të konsiderohen module të tilla si imituesit e tyre origjinalë (megjithëse shumë të avancuara).
Për shkak të gabimeve në PS të zhvilluar, plotësia e arritur në sigurimin e funksionalitetit të saj (në përputhje me specifikimet e cilësisë së saj) në të vërtetë mund të mos jetë siç pritej. Mund të themi vetëm se kjo plotësi është arritur me një probabilitet të caktuar, të përcaktuar nga vëllimi dhe cilësia e testimit. Për të rritur këtë probabilitet, është e nevojshme të vazhdohet testimi dhe korrigjimi i PS. Megjithatë, vlerësimi i një probabiliteti të tillë është një detyrë shumë specifike (duke marrë parasysh faktin se shfaqja e gabimit në PS është në funksion të të dhënave fillestare), e cila ende pret studimet e duhura teorike.
11.3. Sigurimi i saktësisë së mjetit softuerik.
Sigurimi i këtij primitiv është i lidhur me operacione mbi vlerat e llojeve reale (më saktë, me vlera të përfaqësuara me ndonjë gabim). Për të siguruar saktësinë e kërkuar gjatë llogaritjes së vlerës së një funksioni të caktuar do të thotë të merret kjo vlerë me një gabim që nuk shkon përtej kufijve të specifikuar. Llojet e gabimeve, metodat për vlerësimin e tyre dhe metodat për arritjen e saktësisë së kërkuar (të ashtuquajturat llogaritjet e përafërta) trajtohen nga matematika llogaritëse. Këtu i kushtojmë vëmendje vetëm një strukture të caktuar të gabimit: gabimi i vlerës së llogaritur (gabim total) varet
mbi gabimin e metodës së llogaritjes së përdorur (në të cilën përfshijmë pasaktësinë e modelit të përdorur),
nga gabimi në paraqitjen e të dhënave të përdorura (nga i ashtuquajturi gabim fatal),
nga gabimi i rrumbullakimit (pasaktësia në ekzekutimin e operacioneve të përdorura në metodë).
11.4. Sigurimi i autonomisë së softuerit.
Ky primitiv i cilësisë sigurohet në fazën e specifikimit të cilësisë duke marrë një vendim nëse do të përdoret ndonjë softuer themelor i përshtatshëm në PS-në e zhvilluar ose jo për të përdorur ndonjë softuer themelor në të. Në të njëjtën kohë, është e nevojshme të merren parasysh si besueshmëria e tij ashtu edhe burimet e nevojshme për përdorimin e tij. Me kërkesat e rritura për besueshmërinë e PS të zhvilluar, besueshmëria e softuerit bazë në dispozicion të zhvilluesve mund të rezultojë e pakënaqshme, prandaj, përdorimi i tij duhet të braktiset dhe zbatimi i funksioneve të tij në vëllimin e kërkuar duhet të përfshihet në PS. Vendime të ngjashme duhet të merren nën kufizime të rënda në burimet e përdorura (sipas kriterit të efikasitetit të PS).
11.5. Sigurimi i qëndrueshmërisë së softuerit.
Ky primitiv cilësor sigurohet me ndihmën e të ashtuquajturit programim mbrojtës. Në përgjithësi, programimi mbrojtës përdoret për të përmirësuar besueshmërinë e MS gjatë programimit të modulit në një kuptim më të gjerë. Siç thotë Myers, "Programimi mbrojtës bazohet në një premisë të rëndësishme: gjëja më e keqe që mund të bëjë një modul është të pranojë të dhëna të këqija dhe më pas të kthejë një rezultat të pasaktë, por të besueshëm." Për të shmangur këtë, teksti i modulit përfshin kontrolle të të dhënave të tij hyrëse dhe dalëse për korrektësinë e tyre në përputhje me specifikimet e këtij moduli, në veçanti, përmbushjen e kufizimeve në të dhënat hyrëse dhe dalëse dhe marrëdhëniet ndërmjet tyre. të specifikuara në specifikimet e modulit duhet të kontrollohen. Në rast të një rezultati negativ të kontrollit, ngrihet përjashtimi përkatës. Në këtë drejtim, fragmente të llojit të dytë përfshihen në fund të këtij moduli - trajtues të situatave përkatëse të jashtëzakonshme, të cilët, përveç lëshimit të informacionit të nevojshëm diagnostikues, mund të marrin masa ose për të eliminuar gabimet në të dhëna (për shembull, kërkojnë që ato të rifuten) ose për të zbutur ndikimin e gabimit (për shembull, ndalimi i butë i pajisjeve të kontrolluara nga PS për të shmangur prishjen e tyre në rast të një ndërprerje urgjente të ekzekutimit të programit).
Përdorimi i programimit mbrojtës të moduleve çon në një ulje të efikasitetit të PS si në kohë ashtu edhe në kujtesë. Prandaj, është e nevojshme të rregullohet në mënyrë të arsyeshme shkalla e aplikimit të programimit mbrojtës, në varësi të kërkesave për besueshmërinë dhe efikasitetin e PS, të formuluara në specifikimin e cilësisë së PS-së së zhvilluar. Të dhënat hyrëse të modulit të zhvilluar mund të vijnë ose drejtpërdrejt nga përdoruesi ose nga module të tjera. Rasti më i zakonshëm i përdorimit të programimit mbrojtës është përdorimi i tij për grupin e parë të të dhënave, që nënkupton realizimin e qëndrueshmërisë së PS. Kjo duhet të bëhet sa herë që specifikimi i cilësisë së PS përmban një kërkesë për të siguruar stabilitetin e PS. Përdorimi i programimit mbrojtës për grupin e dytë të të dhënave hyrëse nënkupton një përpjekje për të zbuluar një gabim në modulet e tjera gjatë ekzekutimit të modulit të zhvilluar, dhe për të dhënat dalëse të modulit të zhvilluar, një përpjekje për të zbuluar një gabim në vetë modulin. gjatë ekzekutimit të tij. Në thelb, kjo nënkupton një zbatim të pjesshëm të qasjes së vetëzbulimit të gabimeve për të siguruar besueshmërinë e softuerit, e cila u diskutua në leksionin 3. Ky rast i programimit mbrojtës përdoret jashtëzakonisht rrallë - vetëm kur kërkesat për besueshmërinë e softuerit janë jashtëzakonisht të larta.
11.6. Sigurimi i sigurisë së softuerit.
Ekzistojnë llojet e mëposhtme të mbrojtjes së PS kundër shtrembërimit të informacionit:
mbrojtje kundër dështimeve të harduerit;
mbrojtja nga ndikimi i një programi "të huaj";
mbrojtje kundër dështimeve të programit "vet";
mbrojtje kundër gabimeve të operatorit (përdoruesit);
mbrojtje nga aksesi i paautorizuar;
mbrojtje kundër mbrojtjes.
Mbrojtja kundër dështimeve të harduerit aktualisht nuk është një detyrë shumë urgjente (duke marrë parasysh nivelin e besueshmërisë së kompjuterit të arritur). Por është ende e dobishme të dimë zgjidhjen e saj. Kjo sigurohet nga organizimi i të ashtuquajturave "llogaritje të gabuara të dyfishta". Për ta bërë këtë, i gjithë procesi i përpunimit të të dhënave, i përcaktuar nga PS, ndahet në kohë në intervale nga të ashtuquajturat "pika referimi". Gjatësia e këtij intervali nuk duhet të kalojë gjysmën e kohës mesatare të përdorimit të kompjuterit. Një kopje e gjendjes së memories së ndryshuar në këtë proces për çdo pikë referimi shkruhet në memorien dytësore me një sasi kontrolli (një numër i llogaritur në funksion të kësaj gjendjeje) në rastin kur do të konsiderohet se përpunimi i të dhënave nga pika e mëparshme e referencës për këtë (dmth. një "llogaritje e gabuar") është bërë saktë (pa dështime kompjuterike). Për ta zbuluar, bëhen dy “llogaritje të gabuara”. Pas "llogaritjes" së parë, llogaritet dhe ruhet shuma e caktuar e kontrollit, dhe më pas rikthehet gjendja e memories për pikën e mëparshme të referencës dhe bëhet "llogaritja" e dytë. Pas "llogaritjes së gabuar" të dytë, përsëri llogaritet shuma kontrolluese e specifikuar, e cila më pas krahasohet me shumën e kontrollit të "llogaritjes së gabuar" të parë. Nëse këto dy shuma kontrolli përputhen, llogaritja e dytë konsiderohet e saktë, në të kundërt ruhet edhe shuma e kontrollit të "llogaritjes" së dytë dhe kryhet "llogaritja" e tretë (me një rivendosje paraprake të gjendjes së memories për pikën e mëparshme të referencës). Nëse shuma e kontrollit të "llogaritjes së gabuar" të tretë përputhet me shumën e kontrollit të njërit nga dy "llogaritjet e gabuara" të para, atëherë llogaritja e gabuar e tretë konsiderohet e saktë, përndryshe kërkohet një kontroll inxhinierik i kompjuterit.
Mbrojtja nga ndikimi i një programi "të huaj" i referohet kryesisht sistemeve operative ose programeve që kryejnë pjesërisht funksionet e tyre. Ekzistojnë dy lloje të kësaj mbrojtjeje:
mbrojtje nga dështimi,
mbrojtje kundër ndikimit keqdashës të një programi "të huaj".
Kur në memorien e tij shfaqet një mënyrë shumëprogramimi i funksionimit të një kompjuteri, disa programe mund të jenë njëkohësisht në fazën e ekzekutimit, duke marrë në mënyrë alternative kontrollin si rezultat i ndërprerjeve (i ashtuquajturi ekzekutim kuazi-paralel i programeve). Një nga këto programe (zakonisht: sistemi operativ) trajton ndërprerjet dhe menaxhon multiprogramimin. Në secilin prej këtyre programeve, mund të ndodhin dështime (shfaqen gabime) që mund të ndikojnë në performancën e funksioneve nga programet e tjera. Prandaj, programi i kontrollit (sistemi operativ) duhet të mbrojë veten dhe programet e tjera nga një ndikim i tillë. Për ta bërë këtë, pajisja e kompjuterit duhet të zbatojë veçoritë e mëposhtme:
mbrojtjen e memories,
dy mënyra të funksionimit të kompjuterit: i privilegjuar dhe i punës (përdorues),
dy lloje transaksionesh: të privilegjuara dhe të zakonshme,
zbatimin e saktë të ndërprerjeve dhe fillimin e fillimit të kompjuterit,
ndërprerje e përkohshme.
Mbrojtja e memories nënkupton aftësinë për të vendosur në mënyrë programore për secilin program zona të memories që janë të paarritshme për të. Në modalitetin e privilegjuar, çdo operacion (si i zakonshëm ashtu edhe i privilegjuar) mund të kryhet, dhe në modalitetin e ekzekutimit, vetëm ato të zakonshme. Një përpjekje për të kryer një operacion të privilegjuar, si dhe për të hyrë në kujtesën e mbrojtur në modalitetin e funksionimit, shkakton ndërprerjen përkatëse. Për më tepër, operacionet e privilegjuara përfshijnë operacione për të ndryshuar mbrojtjen e kujtesës dhe mënyrën e funksionimit, si dhe aksesin në mjedisin e informacionit të jashtëm. Ndezja fillestare e kompjuterit dhe çdo ndërprerje duhet të mundësojë automatikisht modalitetin e privilegjuar dhe të anashkalojë mbrojtjen e kujtesës. Në këtë rast, programi i kontrollit (sistemi operativ) mund të mbrohet plotësisht nga ndikimi i programeve të tjera, nëse të gjitha pikat e transferimit të kontrollit në ndezjen fillestare dhe ndërprerjet i përkasin këtij programi, nëse nuk lejon asnjë program tjetër të funksionojë në modaliteti i privilegjuar (kur kontrolli transferohet në ndonjë tjetër, programi do të aktivizojë vetëm mënyrën e funksionimit) dhe nëse mbron plotësisht memorien e tij (që përmban, në veçanti, të gjithë informacionin e tij të kontrollit, duke përfshirë të ashtuquajturit vektorë të ndërprerjes) nga programet e tjera. Atëherë askush nuk do ta pengojë atë të kryejë ndonjë funksion mbrojtës të zbatuar në të për programe të tjera (përfshirë aksesin në mjedisin e informacionit të jashtëm). Për të lehtësuar zgjidhjen e këtij problemi, një pjesë e një programi të tillë vendoset në memorien e përhershme, d.m.th. të pandashme nga vetë kompjuteri. Prania e një ndërprerjeje të përkohshme lejon programin e kontrollit të mbrohet nga looping në programe të tjera (pa një ndërprerje të tillë, ai thjesht mund të humbasë aftësinë për të kontrolluar).
Mbrojtja nga dështimet e programit "të vetin" sigurohet nga besueshmëria e këtij programi, e cila është fokusi i të gjithë teknologjisë së programimit të diskutuar në këtë kurs leksionesh.
Mbrojtja kundër gabimeve të përdoruesit (përveç gabimeve të të dhënave të hyrjes, shih sigurimin e stabilitetit të PS) sigurohet duke lëshuar mesazhe paralajmëruese në lidhje me përpjekjet për të ndryshuar gjendjen e mjedisit të informacionit të jashtëm me kërkesën për të konfirmuar këto veprime, si dhe aftësinë për të rivendosur gjendja e përbërësve individualë të mjedisit të jashtëm të informacionit. Kjo e fundit bazohet në zbatimin e ndryshimeve arkivuese në gjendjen e mjedisit të jashtëm të informacionit.
Mbrojtja nga aksesi i paautorizuar sigurohet me përdorimin e fjalëve sekrete (fjalëkalimet). Në këtë rast, çdo përdorues pajiset me informacione dhe burime (shërbime) të caktuara procedurale, përdorimi i të cilave kërkon paraqitjen e një fjalëkalimi në SP, të regjistruar më parë në SP nga ky përdorues. Me fjalë të tjera, përdoruesi, si të thuash, "varet një bravë" në burimet e alokuara për të, "çelësin" në të cilin ka vetëm ky përdorues. Megjithatë, mund të bëhen përpjekje të vazhdueshme për të thyer një mbrojtje të tillë në raste individuale nëse burimet e mbrojtura kanë vlerë ekstreme për dikë. Në një rast të tillë, duhet të merren masa shtesë për të mbrojtur kundër shkeljeve të sigurisë.
Mbrojtja kundër shkeljeve të sigurisë shoqërohet me përdorimin e teknikave të veçanta të programimit në PS që e bëjnë të vështirë tejkalimin e mbrojtjes nga aksesi i paautorizuar. Përdorimi i fjalëkalimeve të zakonshme nuk mjafton kur bëhet fjalë për një dëshirë jashtëzakonisht të vazhdueshme (për shembull, të një natyre kriminale) për të pasur akses në informacione të vlefshme. Së pari, sepse informacioni për fjalëkalimet që PS përdor për t'u mbrojtur nga aksesi i paautorizuar mund të merret relativisht lehtë nga një "cracker" i kësaj mbrojtjeje nëse ai ka akses në vetë këtë PS. Së dyti, duke përdorur një kompjuter, është e mundur të kryhet një numërim mjaft i madh i fjalëkalimeve të mundshme në mënyrë që të gjendet një i përshtatshëm për të aksesuar informacionin me interes. Ju mund të mbroheni nga një hak i tillë në mënyrën e mëposhtme. Fjala sekrete (fjalëkalimi) ose vetëm numri i plotë sekret X është i njohur vetëm për pronarin e informacionit të mbrojtur dhe për të kontrolluar të drejtat e aksesit, në kompjuter ruhet një numër tjetër Y=F(X), i cili llogaritet në mënyrë unike nga PS për çdo përpjekje për të hyrë në këtë informacion me paraqitjen e fjalës sekrete. Në të njëjtën kohë, funksioni F mund të jetë i njohur mirë për të gjithë përdoruesit e PS, por ai ka një veti të tillë që rivendosja e fjalës X nga Y është praktikisht e pamundur: me një gjatësi mjaft të madhe të fjalës X (për shembull, disa qindra karaktere ), kjo kërkon kohë astronomike. Një numër i tillë Y do të quhet nënshkrimi elektronik (kompjuterik) i pronarit të fjalës sekrete X (dhe rrjedhimisht informacioni i mbrojtur).
Një lloj tjetër i një mbrojtjeje të tillë lidhet me mbrojtjen e mesazheve të dërguara përmes rrjeteve kompjuterike, shtrembërimin e qëllimshëm (ose me qëllim të keq). Një mesazh i tillë mund të përgjohet në pikat "transshipment" të rrjetit kompjuterik dhe të zëvendësohet nga një mesazh tjetër nga autori i mesazhit të përgjuar. Kjo situatë lind kryesisht në zbatimin e operacioneve bankare duke përdorur një rrjet kompjuterik. Duke zëvendësuar një mesazh të tillë, që është urdhri i pronarit të një llogarie bankare për të kryer disa operacione bankare, paratë nga llogaria e tij mund të transferohen në llogarinë e një mbrojtjeje "hakeri" (një lloj grabitjeje bankare kompjuterike). Mbrojtja nga një shkelje e tillë e sigurisë mund të bëhet si më poshtë. Së bashku me funksionin F, i cili përcakton nënshkrimin kompjuterik të pronarit të fjalës sekrete X, e cila është e njohur për adresuesin e mesazhit të mbrojtur (nëse vetëm pronari i tij është klient i këtij adresuesi), një funksion tjetër Stamp përcaktohet në PS, nga e cila dërguesi i mesazhit duhet të llogarisë numrin S=Stamp(X,R ) duke përdorur fjalën sekrete X dhe tekstin e mesazhit të transmetuar R. Funksioni Stamp konsiderohet gjithashtu i njohur për të gjithë përdoruesit e PS dhe ka një veti të tillë që është praktikisht e pamundur të rikuperohet numri X nga S, ose të zgjidhet një mesazh tjetër R me nënshkrimin përkatës kompjuterik. Vetë mesazhi i transmetuar (së bashku me mbrojtjen e tij) duhet të duket si:
për më tepër, Y (nënshkrimi kompjuterik) i lejon adresuesit të përcaktojë të vërtetën e klientit, dhe S, si të thuash, fikson mesazhin e mbrojtur R me nënshkrimin kompjuterik Y. Në lidhje me këtë, ne do ta quajmë numrin S një elektronik (kompjuter ) vulë. PS përcakton një funksion tjetër noterial, sipas të cilit marrësi i mesazhit të mbrojtur kontrollon vërtetësinë e mesazhit të transmetuar:
Kjo ju lejon të përcaktoni pa mëdyshje se mesazhi R i përket pronarit të fjalës sekrete X.
Mbrojtja nga mbrojtja është e nevojshme në rast se përdoruesi ka harruar (ose ka humbur) fjalëkalimin e tij. Për një rast të tillë, duhet të jetë e mundur që një përdorues i posaçëm (administratori i PS) përgjegjës për funksionimin e sistemit të mbrojtjes të heqë përkohësisht mbrojtjen nga aksesi i paautorizuar për pronarin e fjalëkalimit të harruar në mënyrë që t'i mundësojë atij të rregullojë një fjalëkalim të ri.
Literatura për leksionin 11.
11.1. I.S. Berezin, N.P. Zhidkov. Metodat e llogaritjes, vëll. 1 dhe 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bakhvalov, N.P. Zhidkov, G.M. Kobelkov. Metodat numerike. - M.: Nauka, 1987.
11.3. G. Myers. Besueshmëria e softuerit. - M.: Mir, 1980. S. 127-154.
11.4. A.N. Lebedev. Mbrojtja e informacionit bankar dhe kriptografia moderne//Çështje të sigurisë së informacionit, 2(29), 1995.
Leksioni 12. Sigurimi i cilësisë së softuerit
12.1. Karakteristikat e përgjithshme të procesit të sigurimit të cilësisë së softuerit.
Siç është vërejtur tashmë në Leksionin 4, specifikimi i cilësisë përcakton udhëzimet (qëllimet) kryesore që në të gjitha fazat e zhvillimit të PS në një mënyrë ose në një tjetër ndikojnë në zgjedhjen e opsionit të duhur kur merren vendime të ndryshme. Sidoqoftë, çdo primitiv i cilësisë ka karakteristikat e veta të një ndikimi të tillë, kështu që sigurimi i pranisë së tij në PS mund të kërkojë qasjet dhe metodat e veta për zhvillimin e PS ose pjesëve të tij individuale. Gjithashtu, u vu re edhe mospërputhja e kritereve të cilësisë së PS dhe primitivëve të cilësisë që i shprehin ato: ofrimi i mirë i njërit prej primitivëve të cilësisë së PS mund të komplikojë ndjeshëm ose të bëjë të pamundur sigurimin e disa prej këtyre primitivëve të tjerë. Prandaj, një pjesë thelbësore e procesit të sigurimit të cilësisë së PS konsiston në gjetjen e kompromiseve të pranueshme. Këto kompensime duhet të përcaktohen pjesërisht tashmë në specifikimin e cilësisë së PS: modeli i cilësisë së PS duhet të specifikojë shkallën e kërkuar të pranisë në PS të secilit prej primitivëve të tij të cilësisë dhe të përcaktojë prioritetet për arritjen e këtyre gradave.
Sigurimi i cilësisë kryhet në çdo proces teknologjik: vendimet e marra në të, në një shkallë ose në një tjetër, ndikojnë në cilësinë e softuerit në tërësi. Në veçanti, sepse një pjesë e konsiderueshme e primitivëve të cilësisë lidhet jo aq me vetitë e programeve të përfshira në PS, por me vetitë e dokumentacionit. Për shkak të mospërputhjes së theksuar të primitivëve të cilësisë, është shumë e rëndësishme t'i përmbahen prioriteteve të zgjedhura në ofrimin e tyre. Por në çdo rast, është e dobishme t'i përmbahen dy parimeve të përgjithshme:
së pari, është e nevojshme të sigurohet funksionaliteti dhe besueshmëria e kërkuar e SP, dhe më pas të sillen kriteret e mbetura të cilësisë në një nivel të pranueshëm të pranisë së tyre në SP;
nuk ka nevojë, madje mund të jetë e dëmshme, të kërkohet një nivel më i lartë i pranisë në PS të çdo primitivi cilësor sesa ai i përcaktuar në specifikimin e cilësisë së PS.
Sigurimi i funksionalitetit dhe besueshmërisë së PS-së u konsiderua në leksionin e mëparshëm. Sigurimi i kritereve të tjera të cilësisë së OS diskutohet më poshtë.
12.2.. Sigurimi i lehtësisë së përdorimit të mjetit softuerik
P-dokumentacioni i PS-së përcakton përbërjen e dokumentacionit të përdoruesit
Në leksionin e mëparshëm, tashmë është marrë në konsideratë sigurimi i dy prej pesë primitiveve cilësore (stabiliteti dhe siguria) që përcaktojnë lehtësinë e përdorimit të PS.
P-dokumentacioni dhe informativiteti përcaktojnë përbërjen dhe cilësinë e dokumentacionit të përdoruesit (shih leksionin tjetër).
Komunikimi sigurohet nga krijimi i një të përshtatshme ndërfaqja e përdoruesit dhe trajtimin përkatës të përjashtimit. Cili është problemi këtu?
12.3. Sigurimi i efektivitetit të softuerit.
Efektiviteti i PS-së sigurohet duke marrë vendime të përshtatshme në faza të ndryshme të zhvillimit të tij, duke filluar me zhvillimin e arkitekturës së tij. Zgjedhja e strukturës dhe prezantimit të të dhënave ndikon veçanërisht fuqishëm në efikasitetin e PS (veçanërisht në aspektin e memories). Por zgjedhja e algoritmeve të përdorura në module të caktuara softuerësh, si dhe veçoritë e zbatimit të tyre (përfshirë zgjedhjen e gjuhës së programimit) mund të ndikojnë ndjeshëm në efektivitetin e PS. Në të njëjtën kohë, duhet të zgjidhet vazhdimisht kontradikta midis efikasitetit të përkohshëm dhe efikasitetit nga kujtesa. Prandaj, është shumë e rëndësishme që specifikimi i cilësisë të tregojë në mënyrë eksplicite lidhjen sasiore midis treguesve të këtyre primitivëve të cilësisë, ose të paktën të vendosë kufij sasiorë për një nga këta tregues. E megjithatë, module të ndryshme softuerësh kanë një efekt të ndryshëm në efikasitetin e PS në tërësi: si në aspektin e kontributit të tyre në kostot totale të PS për sa i përket kohës dhe kujtesës, ashtu edhe për sa i përket ndikimit të tyre në primitivët e cilësisë së ndryshme. (disa module mund të ndikojnë shumë në arritjen e efikasitetit të kohës dhe praktikisht nuk ndikojnë në efikasitetin e kujtesës, ndërsa të tjerët mund të ndikojnë ndjeshëm në konsumin e përgjithshëm të memories pa ndikuar ndjeshëm në kohën e funksionimit të PS). Për më tepër, ky ndikim (kryesisht për sa i përket efiçencës kohore) paraprakisht (para përfundimit të zbatimit të PS) nuk mund të vlerësohet gjithmonë saktë.
së pari ju duhet të zhvilloni një PS të besueshme dhe vetëm atëherë të arrini efikasitetin e kërkuar në përputhje me specifikimet e cilësisë së kësaj PS;
për të përmirësuar efikasitetin e PS, para së gjithash, përdorni një përpilues optimizues - kjo mund të sigurojë efikasitetin e kërkuar;
nëse efikasiteti i arritur i PS nuk plotëson specifikimin e cilësisë së tij, atëherë gjeni modulet më kritike për sa i përket efikasitetit të kërkuar të PS (në rastin e efikasitetit të përkohshëm, kjo do të kërkojë marrjen e shpërndarjes sipas moduleve të PS koha e funksionimit me matjet e duhura gjatë ekzekutimit të PS); këto module dhe përpiquni t'i optimizoni ato së pari duke i modifikuar manualisht;
mos e optimizoni modulin nëse nuk kërkohet për të arritur efikasitetin e kërkuar të PS.
12.4. Sigurimi i mirëmbajtjes.
C-dokumentacioni, përmbajtja e informacionit dhe kuptueshmëria përcaktojnë përbërjen dhe cilësinë e dokumentacionit të mirëmbajtjes (shih leksionin tjetër). Gjithashtu, rekomandimet e mëposhtme mund të bëhen në lidhje me tekstet e programeve (module).
të përdorë komente në tekstin e modulit që qartësojnë dhe shpjegojnë veçoritë e vendimeve që merren; nëse është e mundur, përfshini komente (të paktën në një formë të shkurtër) në fazën më të hershme të zhvillimit të tekstit të modulit;
përdorni emra kuptimplotë (mnemonikë) dhe vazhdimisht të dallueshëm (gjatësia optimale e emrit është 4-12 shkronja, numrat janë në fund), mos përdorni emra dhe fjalë kyçe të ngjashme;
kini kujdes kur përdorni konstante (një konstante unike duhet të ketë një dukuri të vetme në tekstin e modulit: kur deklarohet ose, në raste ekstreme, kur ndryshorja inicializohet si konstante);
mos kini frikë të përdorni kllapa opsionale (kllapat janë më të lira se gabimet;
vendosni jo më shumë se një deklaratë për rresht; për të sqaruar strukturën e modulit, përdorni hapësira shtesë (indentacione) në fillim të çdo rreshti;
shmangni truket d.m.th. të tilla teknikat e programimit, kur krijohen fragmente të një moduli, efekti kryesor i të cilit nuk është i dukshëm ose i fshehur (i mbuluar), si p.sh. efektet anësore të .
Zgjerimi sigurohet duke krijuar një instalues të përshtatshëm.
Strukturimi dhe modulariteti thjeshtojnë të kuptuarit e teksteve të programit dhe modifikimin e tyre.
12.5. Sigurimi i lëvizshmërisë.
Literatura për leksionin 12.
12.1. Ian Somerville. Inxhinieri softuerike. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Stili, zhvillimi, efikasiteti, programet e korrigjimit dhe testimit. - M.: Mir, 1985. S. 8-44, 117-178.
12.4. Dokumentacioni i Përdoruesit të Softuerit/Standardi ANSI/IEEE 1063-1987.
Leksioni 13
13.1. Dokumentacioni i krijuar gjatë procesit të zhvillimit të softuerit.
Kur zhvilloni një PS, krijohet një sasi e madhe e dokumentacionit të ndryshëm. Është e nevojshme si një mjet për të transferuar informacionin midis zhvilluesve të PS, si një mjet për të menaxhuar zhvillimin e PS dhe si një mjet për t'u transmetuar përdoruesve informacionin e nevojshëm për aplikimin dhe mirëmbajtjen e PS. Krijimi i këtij dokumentacioni zë një pjesë të madhe të kostos së PS.
Ky dokumentacion mund të ndahet në dy grupe:
Dokumentet e menaxhimit të zhvillimit të PS.
Dokumentet e përfshira në PS.
Dokumentet e menaxhimit të zhvillimit të PS (dokumentacioni i procesit) regjistrojnë proceset e zhvillimit dhe mirëmbajtjes së PS, duke ofruar komunikim brenda ekipit të zhvillimit dhe midis ekipit të zhvillimit dhe menaxherëve (menaxherëve) - personave që menaxhojnë zhvillimin. Këto dokumente mund të jenë të llojeve të mëposhtme:
Plane, vlerësime, orare. Këto dokumente krijohen nga menaxherët për të parashikuar dhe menaxhuar proceset e zhvillimit dhe mirëmbajtjes.
Raporte mbi përdorimin e burimeve gjatë zhvillimit. Krijuar nga menaxherët.
Standardet. Këto dokumente u përshkruajnë zhvilluesve se cilat parime, rregulla, marrëveshje duhet të ndjekin në procesin e zhvillimit të PS. Këto standarde mund të jenë ose ndërkombëtare ose kombëtare, ose të krijuara posaçërisht për organizatën në të cilën po zhvillohet kjo SP.
Dokumentet e punës. Këto janë dokumentet kryesore teknike që ofrojnë komunikim midis zhvilluesve. Ato përmbajnë një fiksim të ideve dhe problemeve që lindin gjatë procesit të zhvillimit, një përshkrim të strategjive dhe qasjeve të përdorura, si dhe versione pune (të përkohshme) të dokumenteve që duhet të përfshihen në PS.
Shënime dhe korrespondencë. Këto dokumente kapin detaje të ndryshme të ndërveprimit midis menaxherëve dhe zhvilluesve.
Dokumentet e përfshira në PS (dokumentacioni i produktit) përshkruajnë programet PS si nga këndvështrimi i përdorimit të tyre nga përdoruesit, ashtu edhe nga këndvështrimi i zhvilluesve dhe mirëmbajtësve të tyre (në përputhje me qëllimin e PS). Këtu duhet theksuar se këto dokumente do të përdoren jo vetëm në fazën e funksionimit të SP (në fazat e aplikimit dhe mirëmbajtjes së tij), por edhe në fazën e zhvillimit për të menaxhuar procesin e zhvillimit (së bashku me dokumentet e punës) - në çdo rast, ato duhet të kontrollohen (testohen) për pajtueshmërinë me programet e PS. Këto dokumente formojnë dy grupe me qëllime të ndryshme:
Dokumentacioni i përdoruesit të PS (P-documentation).
Dokumentacioni për mbështetjen e SP (C-documentation).
13.2. Dokumentacioni i përdoruesit të softuerit.
Dokumentacioni i përdoruesit të PS (dokumentacioni i përdoruesit) u shpjegon përdoruesve se si duhet të veprojnë për të aplikuar këtë PS. Është e nevojshme nëse PS përfshin ndonjë ndërveprim me përdoruesit. Ky dokumentacion përfshin dokumente që udhëzojnë përdoruesin kur instalon PS (kur instalon PS me cilësimet e duhura për mjedisin për përdorimin e PS), kur përdoret PS për të zgjidhur problemet e tij dhe kur menaxhon PS (për shembull, kur kjo PS ndërvepron me sisteme të tjera). Këto dokumente mbulojnë pjesërisht çështjet e mbështetjes së softuerit, por nuk trajtojnë çështje që lidhen me modifikimin e programeve.
Në këtë drejtim, duhen dalluar dy kategori të përdoruesve të PS: përdoruesit e zakonshëm të PS dhe administratorët e PS. Një përdorues i zakonshëm i PS (përdoruesi i fundit) përdor PS për të zgjidhur problemet e tij (në fushën e tij lëndore). Ky mund të jetë një inxhinier që projekton një pajisje teknike, ose një arkëtar që shet bileta treni duke përdorur një PS. Ai mund të mos dijë shumë detaje të funksionimit të kompjuterit ose parimeve të programimit. Administratori i PS (administratori i sistemit) menaxhon përdorimin e PS nga përdoruesit e zakonshëm dhe ofron mbështetje për PS që nuk ka lidhje me modifikimin e programeve. Për shembull, ai mund të rregullojë të drejtat e aksesit në OS midis përdoruesve të zakonshëm, të komunikojë me ofruesit e OS ose të kryejë veprime të caktuara për ta mbajtur sistemin operativ në gjendje pune nëse ai përfshihet si pjesë e një sistemi tjetër.
Përbërja e dokumentacionit të përdoruesit varet nga audienca e përdoruesve që synon ky PS, dhe nga mënyra e përdorimit të dokumenteve. Audienca këtu kuptohet si kontigjenti i përdoruesve të SP-së, i cili ka nevojë për dokumentacion të caktuar përdoruesi të SP-së. Një dokument i suksesshëm përdoruesi në thelb varet nga përkufizimi i saktë i audiencës për të cilën është menduar. Dokumentacioni i përdoruesit duhet të përmbajë informacionin e kërkuar për çdo audiencë. Mënyra e përdorimit të një dokumenti i referohet mënyrës në të cilën përdoret dokumenti. Zakonisht, përdoruesi i sistemeve softuerike mjaft të mëdha kërkon që secili nga dokumentet të studiojë PS-në (përdorimi në udhëzimet), ose për të sqaruar disa informacione (përdorni si referencë).
Në përputhje me punimet, përbërja e mëposhtme e dokumentacionit të përdoruesit për PS mjaft të mëdha mund të konsiderohet tipike:
Përshkrimi i përgjithshëm funksional i SP. Jep një përshkrim të shkurtër të funksionalitetit të PS. Ai është i destinuar për përdoruesit të cilët duhet të vendosin se sa kanë nevojë për këtë PS.
Udhëzuesi i instalimit të PS. Projektuar për administratorët e sistemit. Ai duhet të përshkruajë në detaje se si të instaloni sistemet në një mjedis të caktuar. Ai duhet të përmbajë një përshkrim të mediumit të lexueshëm nga makineritë në të cilin furnizohet MS, skedarët që përfaqësojnë MS dhe kërkesat për konfigurimin minimal të harduerit.
Udhëzime për përdorimin e PS. Projektuar për përdoruesit e zakonshëm. Përmban informacionin e nevojshëm për aplikimin e PS, të organizuar në një formë të përshtatshme për studimin e tij.
Libër referimi mbi aplikimin e PS. Projektuar për përdoruesit e zakonshëm. Përmban informacionin e nevojshëm për aplikimin e PS, të organizuar në një formë të përshtatshme për kërkimin selektiv të detajeve individuale.
Udhëzues për menaxhimin e PS. Projektuar për administratorët e sistemit. Ai duhet të përshkruajë mesazhet e krijuara kur MS ndërvepron me sisteme të tjera dhe si t'u përgjigjet këtyre mesazheve. Përveç kësaj, nëse MS përdor harduerin e sistemit, ky dokument mund të shpjegojë se si të mirëmbahet ai pajisje.
Siç u përmend më herët (shih Leksionin 4), zhvillimi i dokumentacionit të përdoruesit fillon menjëherë pas krijimit të një përshkrimi të jashtëm. Cilësia e këtij dokumentacioni mund të përcaktojë ndjeshëm suksesin e një SP. Duhet të jetë mjaft e thjeshtë dhe miqësore për përdoruesit (përndryshe, kjo PS, në përgjithësi, nuk ia vlente të krijohej). Prandaj, megjithëse draft versionet (draftet) e dokumenteve të përdoruesve krijohen nga zhvilluesit kryesorë të PS, shkrimtarët teknikë profesionistë shpesh përfshihen në krijimin e versioneve të tyre përfundimtare. Përveç kësaj, për të siguruar cilësinë e dokumentacionit të përdoruesit, janë zhvilluar një sërë standardesh (shih, për shembull,), të cilat përshkruajnë procedurën për zhvillimin e këtij dokumentacioni, formulojnë kërkesat për secilin lloj dokumentesh të përdoruesit dhe përcaktojnë strukturën dhe përmbajtjen e tyre .
13.3. Dokumentacioni i mbështetjes së softuerit.
Dokumentacioni për mirëmbajtjen e SP (dokumentacioni i sistemit) përshkruan SP-në nga pikëpamja e zhvillimit të tij. Ky dokumentacion është i nevojshëm nëse SP përfshin studimin se si është rregulluar (dizajnuar) dhe modernizimin e programeve të tij. Siç u përmend, mirëmbajtja është një zhvillim i vazhdueshëm. Prandaj, nëse është e nevojshme të përmirësohet PS, një ekip i veçantë zhvilluesish shoqërues është i përfshirë në këtë punë. Ky ekip do të duhet të merret me të njëjtin dokumentacion që përcaktoi aktivitetet e ekipit të zhvilluesve fillestarë (kryesorë) të PS, me ndryshimin e vetëm që ky dokumentacion, si rregull, do të jetë i dikujt tjetër për ekipin e zhvillimit të mirëmbajtjes ( është krijuar nga një ekip tjetër). Ekipi i mirëmbajtjes do të duhet të studiojë këtë dokumentacion për të kuptuar strukturën dhe procesin e zhvillimit të PS-së së përmirësuar dhe të bëjë ndryshimet e nevojshme në këtë dokumentacion, duke përsëritur në një masë të madhe proceset teknologjike me të cilat është krijuar PS origjinale.
Dokumentacioni për mbështetjen e PS mund të ndahet në dy grupe:
(1) dokumentacioni që përcakton strukturën e programeve dhe strukturat e të dhënave të SP-së dhe teknologjinë e zhvillimit të tyre;
(2) dokumentacion për të ndihmuar në ndryshimet në PS.
Dokumentacioni i grupit të parë përmban dokumentet përfundimtare të çdo faze teknologjike të zhvillimit të SP. Ai përfshin dokumentet e mëposhtme:
Përshkrimi i jashtëm i PS (Dokumenti i kërkesave).
Përshkrimi i arkitekturës së sistemit të PS, duke përfshirë specifikimin e jashtëm të secilit prej programeve të tij.
Për çdo program PS, një përshkrim i strukturës së tij modulare, duke përfshirë një specifikim të jashtëm për çdo modul të përfshirë në të.
Për secilin modul - specifikimi i tij dhe përshkrimi i strukturës së tij (përshkrimi i dizajnit).
Modulo tekstet në gjuhën e zgjedhur të programimit (lista e kodeve burimore të programit).
Dokumentet e vlefshmërisë së OS që përshkruajnë se si u krijua vlefshmëria e secilit program OS dhe si u shoqërua informacioni i vlefshmërisë me kërkesat për OS.
Dokumentet e vërtetimit të softuerit përfshijnë kryesisht dokumentacionin e testimit (dizajni i testit dhe përshkrimi i paketës së provës), por mund të përfshijnë gjithashtu rezultatet e llojeve të tjera të vërtetimit të softuerit, të tilla si provat e vetive të softuerit.
Dokumentacioni i grupit të dytë përmban
Udhëzuesi i mirëmbajtjes së sistemit, i cili përshkruan çështjet e njohura së bashku me softuerin, përshkruan se cilat pjesë të sistemit varen nga hardueri dhe softueri dhe si merret parasysh zhvillimi i softuerit në strukturën (projektimin) e tij.
Një problem i zakonshëm i mirëmbajtjes për një PS është të sigurohet që të gjitha paraqitjet e tij të mbajnë ritmin (të mbeten të qëndrueshme) kur PS ndryshon. Për ta ndihmuar këtë, marrëdhëniet dhe varësitë midis dokumenteve dhe pjesëve të tyre duhet të regjistrohen në bazën e të dhënave të menaxhimit të konfigurimit.
Literatura për leksionin 13.
13.1. Ian Somerville. Inxhinieri softuerike. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.
13.3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI/IEEE Std 1016-1987, Praktika e rekomanduar e IEEE për Përshkrimin e dizajnit të softuerit.
13.5. ANSI/IEEE Std 1008-1987, Standardi IEEE për testimin e njësisë softuerike.
13.6. ANSI/IEEE Std 1012-1986, Standardi IEEE për Verifikimin e Softuerit dhe Planet e Validimit.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.
Leksioni 14
Caktimi i certifikimit të softuerit. Testimi dhe vlerësimi i cilësisë së softuerit. Llojet e testeve dhe metodat për vlerësimin e cilësisë së softuerit.
14.1. Caktimi i certifikimit të softuerit.
Certifikimi i PS është një konfirmim autoritar i cilësisë së PS. Zakonisht, për certifikimin e një sistemi softuerik krijohet një komision përfaqësues (testimi), i përbërë nga ekspertë, përfaqësues të klientit dhe përfaqësues të zhvilluesit. Ky komision kryen teste të SP-së për të marrë informacionin e nevojshëm për vlerësimin e cilësisë së tij. Nën testin e PS nënkuptojmë procesin e kryerjes së një sërë masash që shqyrtojnë përshtatshmërinë e PS për funksionimin e suksesshëm të tij (aplikimin dhe mirëmbajtjen) në përputhje me kërkesat e klientit. Ky kompleks përfshin kontrollin e plotësisë dhe saktësisë së dokumentacionit të softuerit, studimin dhe diskutimin e veçorive të tjera të tij, si dhe testimin e nevojshëm të programeve të përfshira në PS, dhe në veçanti përputhshmërinë e këtyre programeve me dokumentacionin në dispozicion.
Në bazë të informacionit të marrë gjatë testimit të SP-së, para së gjithash duhet vërtetuar se SP-ja kryen funksionet e deklaruara, si dhe duhet vërtetuar se në çfarë mase SV-ja i ka primitivet dhe kriteret e cilësisë së deklaruar. Pra, vlerësimi i cilësisë së SP-së është përmbajtja kryesore e procesit të certifikimit. Vlerësimi i cilësisë së PS-së shënohet në vendimin përkatës të komisionit të certifikimit.
14.2. Llojet e testimit të softuerit.
Janë të njohura llojet e mëposhtme të testeve PS, të kryera me qëllim të certifikimit të PS:
Testimi i komponentëve PS;
testet e sistemit;
testet e pranimit;
prova në terren;
testet industriale.
Testimi i komponentit PS është një verifikim (testim) i funksionimit të nënsistemeve individuale të PS. Ato mbahen vetëm në raste të jashtëzakonshme me vendim të veçantë të komisionit të certifikimit.
Testimi i sistemit të PS është një kontroll (testim) i funksionimit të PS në tërësi. Mund të përfshijë të njëjtat lloje testimi si në korrigjimin kompleks të PS (shih leksionin 10). Ajo kryhet me vendim të komisionit të certifikimit, nëse ka dyshime për cilësinë e korrigjimit nga zhvilluesit e PS.
Testet e pranimit janë lloji kryesor i testeve për certifikimin e PS. Pikërisht me këto teste nis punën komisioni i certifikimit. Këto teste fillojnë me studimin e dokumentacionit të paraqitur, duke përfshirë dokumentacionin për testimin dhe korrigjimin e PS. Nëse dokumentacioni nuk përmban rezultate mjaftueshëm të plota të testimit të PS, komiteti i certifikimit mund të vendosë të kryejë teste të sistemit të PS ose të përfundojë procesin e certifikimit me një rekomandim për zhvilluesin për të kryer testime shtesë (më të plota) të PS. Përveç kësaj, gjatë këtyre testeve, testet e zhvilluesve mund të anashkalohen në mënyrë selektive, si dhe detyrat e kontrollit të përdoruesit (shih leksionin 10) dhe testet shtesë të përgatitura nga komisioni për të vlerësuar cilësinë e PS-së së certifikuar.
Testimi në terren i PS-së është një demonstrim i PS-së së bashku me sistemin teknik të kontrolluar nga kjo PS në një rreth të ngushtë klientësh në kushte reale dhe sjellja e PS-së monitorohet me kujdes. Klientëve duhet t'u jepet mundësia të vendosin rastet e tyre të testimit, në veçanti, nga daljet në mënyrat kritike të funksionimit të sistemit teknik, si dhe me thirrjen e situatave emergjente në të. Këto janë teste shtesë të kryera me vendim të komisionit të certifikimit vetëm për disa SP që kontrollojnë sisteme të caktuara teknike.
Testimi industrial i PS është procesi i transferimit të PS në funksionim të përhershëm tek përdoruesit. Është një periudhë e provës së funksionimit të SP (shih leksionin 10) nga përdoruesit me mbledhjen e informacionit për sjelljen e SP dhe karakteristikat e tij funksionale. Këto janë testet përfundimtare të SP-së, të cilat kryhen me vendim të komisionit të certifikimit, nëse gjatë testimeve të mëparshme është marrë informacion i pamjaftueshëm ose i besueshëm për të vlerësuar cilësinë e SP-së së certifikuar.
14.3. Metodat për vlerësimin e cilësisë së softuerit.
Vlerësimi i cilësisë së SP-së për secilin nga kriteret reduktohet në vlerësimin e secilit prej primitivëve që lidhen me këtë kriter të cilësisë së SP-së, në përputhje me specifikimin e tyre, të bërë në specifikimin e cilësisë së këtij SP. Metodat për vlerësimin e primitivëve të cilësisë së PS mund të ndahen në katër grupe:
matja e drejtpërdrejtë e treguesve primitivë të cilësisë;
programet e përpunimit dhe dokumentacioni i SP me mjete të posaçme softuerike (përpunues);
testimi i programeve të PS;
vlerësimi i ekspertit bazuar në studimin e programeve dhe dokumentacionit të SP.
Matja e drejtpërdrejtë e treguesve të cilësisë primitive kryhet duke numëruar numrin e dukurive në një dokument të caktuar programor të njësive karakteristike, objekteve, strukturave, etj., Si dhe duke matur kohën e funksionimit. pajisje të ndryshme dhe sasinë e memories së zënë kompjuterike gjatë ekzekutimit të rasteve të testimit. Për shembull, një masë e efikasitetit të kujtesës mund të jetë numri i rreshtave të një programi në një gjuhë programimi dhe një masë e efikasitetit kohor mund të jetë koha e përgjigjes ndaj një pyetjeje. Përdorimi i çdo treguesi për primitivët e cilësisë mund të përcaktohet në specifikimin e cilësisë së MS. Metoda e matjes direkte të treguesve primitivë të cilësisë mund të kombinohet me përdorimin e testimit të programit.
Disa mjete softuerike mund të përdoren për të përcaktuar nëse një MS ka primitivë të caktuar të cilësisë. Mjete të tilla softuerike përpunojnë tekste programore ose dokumentacion softuerësh me qëllim që të kontrollojnë çdo primitiv të cilësisë ose të marrin disa tregues të këtyre primitivëve të cilësisë. Për të vlerësuar strukturimin e programeve PS, nëse ato do të programoheshin në një dialekt të përshtatshëm strukturor të gjuhës së programimit bazë, do të mjaftonte kalimi i tyre përmes një konverteri të strukturuar programi që kryen kontroll sintaksor dhe semantik të këtij dialekti dhe përkthen tekstet e këto programe në gjuhën hyrëse të përkthyesit bazë. Megjithatë, vetëm një numër i vogël i primitivëve cilësorë aktualisht mund të kontrollohen në këtë mënyrë, madje edhe atëherë në raste të rralla. Në disa raste, në vend të mjeteve softuerike që kontrollojnë cilësinë e softuerit, është më e dobishme të përdoren mjete që transformojnë prezantimin e programeve ose dokumentacionin e programit. I tillë, për shembull, është një formatues programi që sjell tekstet e programit në një formë të lexueshme - përpunimi i teksteve të programeve PS me një mjet të tillë mund të sigurojë automatikisht praninë e një primitiv të cilësisë së duhur për PS.
Testimi përdoret për të vlerësuar disa primitivë të cilësisë së PS. Primitivë të tillë përfshijnë kryesisht tërësinë e PS, si dhe saktësinë, stabilitetin, sigurinë dhe primitivë të tjerë cilësorë. Në disa raste, testimi përdoret në kombinim me metoda të tjera për të vlerësuar primitivët individualë të cilësisë së PS. Pra, për të vlerësuar cilësinë e dokumentacionit për përdorimin e PS (P-dokumentacioni), testimi përdoret në kombinim me një vlerësim ekspert të këtij dokumentacioni. Nëse gjatë korrigjimit kompleks të PS është kryer një testim mjaft i plotë, atëherë të njëjtat teste mund të përdoren gjatë certifikimit të PS. Në këtë rast, komiteti i certifikimit mund të përdorë protokollet e testimit të kryera gjatë korrigjimit kompleks. Megjithatë, edhe në këtë rast, është e nevojshme të kryhen disa teste të reja ose të paktën të ridrejtohen disa nga ato të vjetrat. Nëse testimi gjatë korrigjimit kompleks rezulton të jetë i pamjaftueshëm i plotë, atëherë është e nevojshme të kryhet testim më i plotë. Në këtë rast, mund të merret një vendim për të kryer teste përbërëse ose teste të sistemit të PS, si dhe për t'u kthyer PS zhvilluesve për rishikim. Është shumë e rëndësishme që për të vlerësuar SP-në sipas kriterit të lehtësisë së përdorimit (gjatë korrigjimit dhe certifikimit të SP-së), testimi i plotë është kryer në testet e përgatitura në bazë të dokumentacionit për aplikim, dhe sipas për kriterin e mirëmbajtjes - në testet e përgatitura për secilin nga dokumentet e propozuara për mirëmbajtje PS.
Për të vlerësuar shumicën e primitivëve të cilësisë së PS, aktualisht mund të përdoret vetëm metoda e vlerësimeve të ekspertëve. Kjo metodë konsiston në sa vijon: caktohet një grup ekspertësh, secili prej këtyre ekspertëve, si rezultat i studimit të dokumentacionit të paraqitur, formon mendimin e tij për zotërimin e SP-së nga primitivi i cilësisë së kërkuar dhe më pas vlerësimi i cilësisë së kërkuar. primitivi cilësor i PS-së krijohet me votim të anëtarëve të këtij grupi. Ky vlerësim mund të bëhet si në një sistem me dy pika ("posedon" - "nuk ka"), dhe të marrë parasysh shkallën e zotërimit të PS nga ky primitiv cilësor (për shembull, mund të bëhet në një pesë -sistemi i pikëve). Në të njëjtën kohë, grupi i ekspertëve duhet të udhëhiqet nga specifikimi i këtij primitiv dhe një tregues i metodës së vlerësimit të tij, të formuluar në specifikimin e cilësisë së PS-së së certifikuar.
Literatura për leksionin 14.
14.2. V.V. Lipaev. Testimi i programit. - M.: Radio dhe komunikim, 1986. - S. 231-245.
14.3. D. Van Tassel. Stili, zhvillimi, efikasiteti, programet e korrigjimit dhe testimit. - M.: Mir, 1985. - S. 281-283.
14.4. B. Schneiderman. Psikologjia e programimit. - M.: Radio dhe komunikim, 1984. - S. 99-127.
Leksioni 15. Qasja e objektit në zhvillimin e softuerit
15.1. Objektet dhe marrëdhëniet në programim. Thelbi i qasjes së objektit ndaj zhvillimit të softuerit.
Bota rreth nesh përbëhet nga objekte dhe marrëdhënie midis tyre. Një objekt mishëron një entitet dhe ka një gjendje që mund të ndryshojë me kalimin e kohës si rezultat i ndikimit të objekteve të tjera që janë në një farë mënyre me të dhënat. Mund të ketë një strukturë të brendshme: mund të përbëhet nga objekte të tjera që janë gjithashtu në njëfarë marrëdhënieje me njëri-tjetrin. Duke u nisur nga kjo, është e mundur të ndërtohet një strukturë hierarkike e botës nga objektet. Sidoqoftë, për çdo konsideratë specifike të botës përreth nesh, disa objekte konsiderohen të pandashme ("pika") dhe, në varësi të objektivave të shqyrtimit, objekte të tilla (të pandashme) të niveleve të ndryshme të hierarkisë mund të pranohen. Një relacion lidh disa objekte: mund të konsiderojmë se bashkimi i këtyre objekteve ka disa veti. Nëse një relacion lidh n objekte, atëherë një lidhje e tillë quhet n-vend (n-ary). Në çdo vend të bashkimit të objekteve që mund të lidhen me ndonjë marrëdhënie specifike, mund të ketë objekte të ndryshme, por mjaft të përcaktuara (në këtë rast thonë: objekte të një klase të caktuar). Një lidhje me një vend quhet veti e një objekti (klasa përkatëse). Gjendja e një objekti mund të studiohet nga vlera e vetive të këtij objekti ose në mënyrë implicite nga vlera e vetive të bashkimeve të objekteve të lidhura së bashku me një lidhje të caktuar.
Në procesin e njohjes ose ndryshimit të botës që na rrethon, ne gjithmonë marrim parasysh një ose një tjetër model të thjeshtuar të botës (bota model), në të cilin përfshijmë disa nga objektet dhe disa nga marrëdhëniet e botës përreth nesh dhe si rregull, një nivel hierarkie. Çdo objekt që ka një strukturë të brendshme mund të përfaqësojë botën e tij model, duke përfshirë objektet e kësaj strukture dhe marrëdhëniet që i lidhin ato. Kështu, bota rreth nesh mund të konsiderohet (në një farë përafrimi) si një strukturë hierarkike e botëve model.
Aktualisht, në procesin e të mësuarit ose ndryshimit të botës përreth nesh, teknologjia kompjuterike përdoret gjerësisht për të përpunuar lloje të ndryshme informacioni. Në këtë drejtim, përdoret një paraqitje kompjuterike (informative) e objekteve dhe marrëdhënieve. Çdo objekt mund të përfaqësohet në mënyrë informative nga një strukturë e të dhënave që shfaq gjendjen e tij. Vetitë e këtij objekti mund të vendosen drejtpërdrejt si përbërës të veçantë të kësaj strukture, ose me funksione të veçanta në këtë strukturë të dhënash. Marrëdhëniet N-arike për N>1 mund të paraqiten ose në formë aktive ose në formë pasive. Në formën e tij aktive, një lidhje me vend N përfaqësohet nga një fragment programi që zbaton ose një funksion me vend N (që përcakton vlerën e vetive të lidhjes përkatëse të objekteve) ose një procedurë që ndryshon gjendjet e disa prej tyre. bazuar në gjendjen e paraqitjeve të objekteve të lidhura me relacionin e paraqitur. Në një formë pasive, një lidhje e tillë mund të përfaqësohet nga një strukturë e caktuar e të dhënave (e cila mund të përfshijë paraqitje të objekteve të lidhura nga kjo marrëdhënie), të interpretuara në bazë të marrëveshjeve të pranuara mbi procedurat e përgjithshme që janë të pavarura nga marrëdhëniet specifike (për shembull, një baza e të dhënave relacionale). Në secilin rast, përfaqësimi i marrëdhënies përcakton disa aktivitete të përpunimit të të dhënave.
Kur eksploron botën e modelit, përdoruesi mund të marrë (ose dëshiron të marrë) informacion nga kompjuteri në mënyra të ndryshme. Në një qasje, ai mund të jetë i interesuar të marrë informacion në lidhje me vetitë individuale të objekteve me interes për të ose rezultatet e ndonjë ndërveprimi midis disa objekteve. Për ta bërë këtë, ai urdhëron zhvillimin e një ose një tjetër PS që kryen funksionet me interes për të, ose një sistem informacioni të aftë për të lëshuar informacion në lidhje me marrëdhëniet me interes për të, duke përdorur bazën e të dhënave përkatëse. Në periudhën fillestare të zhvillimit të teknologjisë kompjuterike (me fuqi jo të mjaftueshme të kompjuterëve), një qasje e tillë ndaj përdorimit të kompjuterëve ishte mjaft e natyrshme. Ishte ai që provokoi qasjen funksionale (relacionale) ndaj zhvillimit të PS, e cila u diskutua në detaje në leksionet e mëparshme. Thelbi i kësaj qasjeje është përdorimi sistematik i zbërthimit të funksioneve (marrëdhënieve) për të ndërtuar strukturën e PS dhe tekstet e programit të përfshira në të. Në të njëjtën kohë, vetë objektet, tek të cilat u zbatuan funksionet e porositura dhe të zbatuara, u prezantuan në mënyrë fragmentare (në masën e nevojshme për të kryer këto funksione) dhe në një formë të përshtatshme për zbatimin e këtyre funksioneve. Kështu, një përfaqësim i plotë dhe adekuat kompjuterik i botës së modelit me interes për përdoruesin nuk u sigurua: shfaqja e tij në PS-në e përdorur mund të rezultonte të ishte një detyrë mjaft e mundimshme për përdoruesin, një përpjekje për të zgjeruar paksa vëllimin dhe natyrën e informacion në lidhje me botën e modelit me interes për përdoruesit. të marra nga një nënstacion i tillë mund të çojë në modernizimin serioz të tyre. Kjo qasje për zhvillimin e PS mbështetet nga shumica e gjuhëve programuese të përdorura, duke filluar nga gjuhët e asamblesë dhe gjuhët procedurale(Fortran, Pascal) në gjuhët funksionale (LISP) dhe gjuhët e programimit logjik (PROLOGUE).
Me një qasje tjetër për studimin e botës së modelit duke përdorur një kompjuter, përdoruesi mund të jetë i interesuar të vëzhgojë ndryshimin në gjendjen e objekteve si rezultat i ndërveprimeve të tyre. Kjo kërkon një përfaqësim mjaft të fortë në kompjuter të objektit me interes për përdoruesin, dhe komponentët e softuerit që zbatojnë marrëdhëniet në të cilat ky objekt merr pjesë janë të lidhura në mënyrë eksplicite me të. Për të zbatuar këtë qasje, ishte e nevojshme të ndërtoheshin mjete softuerike që simulojnë proceset e ndërveprimit midis objekteve (bota e modelit). Me ndihmën e mjeteve tradicionale të zhvillimit, kjo doli të ishte një detyrë mjaft e mundimshme. Vërtetë, janë shfaqur gjuhë programimi që përqendrohen posaçërisht në një modelim të tillë, por kjo thjeshtoi pjesërisht detyrën e zhvillimit të PS-së së kërkuar. Zgjidhja më e plotë e këtij problemi është qasja objekt për zhvillimin e PS. Thelbi i tij qëndron në përdorimin sistematik të dekompozimit të objekteve në ndërtimin e strukturës së PS dhe teksteve të programeve të përfshira në të. Në të njëjtën kohë, funksionet (marrëdhëniet) e kryera nga një PS e tillë u shprehën përmes marrëdhënieve të objekteve të niveleve të ndryshme, d.m.th. zbërthimi i tyre varej ndjeshëm nga zbërthimi i objekteve.
Duke folur për qasjen e objektit, duhet gjithashtu të kuptohet qartë se çfarë lloj objektesh përfshihen: objektet e botës model të përdoruesit, përfaqësimi i tyre i informacionit, objektet e programit me të cilët është ndërtuar PS. Për më tepër, duhet bërë dallimi midis objekteve aktuale (objekte "pasive") dhe subjekteve (objekte "aktive").
15.2. Objektet dhe lëndët në programim.
15.3. Qasje objektive dhe subjektive për zhvillimin e softuerit.
Dekarti vuri në dukje se njerëzit zakonisht kanë një pamje të orientuar nga objekti i botës (c).
Ata besojnë se dizajni i orientuar nga objekti bazohet në parimet e:
duke theksuar abstraksionet,
Kufizimi i aksesit,
modulariteti,
hierarki,
duke shtypur,
paralelizmi,
qëndrueshmëri.
Por e gjithë kjo mund të zbatohet në një qasje funksionale.
Është e nevojshme të bëhet dallimi midis avantazheve dhe disavantazheve të qasjes së përgjithshme të objektit dhe rastit të saj të veçantë - qasjes së orientuar nga subjekti.
Përparësitë e qasjes së përgjithshme objektive:
Harta natyrore e botës reale në strukturën e PS (perceptimi natyror i njeriut për aftësitë e PS, nuk ka nevojë të "shpik" strukturën e PS, por të përdorë analogji natyrore).
Përdorimi i njësive strukturore mjaft domethënëse të PS (një objekt si integriteti i shoqatave jo të tepërta, module të forta informacioni).
Reduktimi i kompleksitetit të zhvillimit të softuerit përmes përdorimit të një niveli të ri abstraksionesh (duke përdorur një hierarki të abstraksioneve "jo programore" në zhvillimin e softuerit: klasifikimi i objekteve të botës reale, metoda e analogjive në natyrë) si një nivel i ri i trashëgimisë.
15.4. Një qasje objekti për zhvillimin e një përshkrimi të jashtëm dhe arkitekturës së softuerit.
Dizajni i orientuar nga objekti është një metodë që përdor zbërthimin e objektit; Qasja e orientuar nga objekti ka sistemin e vet simbolet dhe ofron një grup të pasur modelesh logjike dhe fizike për dizajnimin e sistemit shkallë të lartë vështirësitë. .
Analiza e orientuar nga objekti (OOA) ka dhënë qasjen e objektit. OOA synon të krijojë modele që janë më afër realitetit duke përdorur një qasje të orientuar nga objekti; është një metodologji në të cilën kërkesat formohen mbi bazën e koncepteve të klasave dhe objekteve që përbëjnë fjalorin e fushës lëndore. .
Karakteristikat e programimit të orientuar drejt objektit.
Objektet, klasat, sjellja e objektit, vetitë, ngjarjet.
Literatura për leksionin 15.
15.1. K. Futi, N. Suzuki. Gjuhët e programimit dhe qarku VLSI. - M.: Mir, 1988. S. 85-98.
15.2. Ian Somerville. Inxhinieri softuerike. - Addison-Wesley Publishing Company, 1992. P. ?-?
15.3. G. Butch. Dizajni i orientuar nga objekti me shembuj aplikimi: per. nga anglishtja. - M.: Concord, 1992.
15.4. V.Sh.Kaufman. Gjuhët e programimit. Konceptet dhe parimet. Moskë: Radio dhe komunikim, 1993.

Leksioni 8. Zhvillimi i një moduli softuerik

8.1. Procedura për zhvillimin e një moduli softuerësh.

8.2. Programimi strukturor.

8.3. Detajimi hap pas hapi dhe koncepti i pseudokodit.

8.4. Kontrolli i modulit të softuerit.

Literatura për leksionin 8.

Leksioni 9

9.1. Arsyetimet e programit. Formalizimi i vetive të programit.

9.2. Vetitë e operatorëve të thjeshtë.

9.3. Vetitë e strukturave bazë të programimit strukturor.

9.4. Përfundimi i ekzekutimit të programit.

9.5. Një shembull i vërtetimit të vetive të programit.

Literatura për leksionin 9.

Leksioni 10

10.1. Konceptet bazë.

10.2. Parimet dhe llojet e korrigjimit.

10.3. Urdhërimet e korrigjimit.

10.4. Korrigjimi i modulit jashtë linje.

10.5. Korrigjimi kompleks i softuerit.

Literatura për leksionin 10.

Leksioni 11

11.1. Funksionaliteti dhe besueshmëria si kritere të detyrueshme për cilësinë e softuerit.

11.2. Sigurimi i plotësisë së softuerit.

11.3. Sigurimi i saktësisë së mjetit softuerik.

11.4. Sigurimi i autonomisë së softuerit.

11.5. Sigurimi i qëndrueshmërisë së softuerit.

11.6. Sigurimi i sigurisë së softuerit.

Literatura për leksionin 11.

Leksioni 12. Sigurimi i cilësisë së softuerit

12.1. Karakteristikat e përgjithshme të procesit të sigurimit të cilësisë së softuerit.

12.3. Sigurimi i efektivitetit të softuerit.

Literatura për leksionin 12.

Leksioni 13

13.1. Dokumentacioni i krijuar gjatë procesit të zhvillimit të softuerit.

13.2. Dokumentacioni i përdoruesit të softuerit.

Literatura për leksionin 13.

Leksioni 14

14.1. Caktimi i certifikimit të softuerit.

14.2. Llojet e testimit të softuerit.

14.3. Metodat për vlerësimin e cilësisë së softuerit.

Leksioni 15. Qasja e objektit në zhvillimin e softuerit

15.1. Objektet dhe marrëdhëniet në programim. Thelbi i qasjes së objektit ndaj zhvillimit të softuerit.

15.2. Objektet dhe lëndët në programim.

15.3. Qasje objektive dhe subjektive për zhvillimin e softuerit.

15.4. Një qasje objekti për zhvillimin e një përshkrimi të jashtëm dhe arkitekturës së softuerit.

Literatura për leksionin 15.