Vývoj softvérových modulov pre počítačové systémy. Pracovný program tréningovej praxe pre odborný modul „vývoj softvérových softvérových modulov pre počítačové systémy“ Vývoj softvérových modulov

MINISTERSTVO ŠKOLSTVA A VEDY

DONECKÁ ĽUDOVÁ REPUBLIKA

ŠTÁTNY PROFESIONÁL

VZDELÁVACIA INŠTITÚCIA

"DONETSKÚ PRIEMYSELNÁ A HOSPODÁRSKA KOLEMCIA"

PRACOVNÝ PROGRAM

Vzdelávacia prax UP.01

profesionálny modul PM.01 Vývoj softvérových modulov softvér Pre počítačové systémy

špecialita 09.02.03 "Programovanie v počítačových systémoch"

Skomplikovaný:

Volkov Vladimir Aleksandrovich, učiteľ počítačových disciplín kvalifikačnej kategórie "špecialista najvyššej kategórie", Štátna vzdelávacia inštitúcia "Doneck Industrial and Economic College"

Program schvaľuje: Vovk Pavel Andreevich, riaditeľ „Smart IT Service“


1. PAS PRAKTICKÉHO PROGRAMU
2. VÝSLEDKY PRAXE
3. ŠTRUKTÚRA A OBSAH PRAXE
4. PODMIENKY ORGANIZÁCIE A VEDENIA PRAXE
5. MONITOROVANIE A HODNOTENIE VÝSLEDKOV PRAXE

1 PASPORT PROGRAMU VZDELÁVACIEHO PRAXE UP. 01

1.1 Miesto tréningovej praxe UP.01

Program vzdelávacej praxe UP.01 odborného modulu PM.01 "Vývoj softvérových softvérových modulov pre počítačové systémy" odbor 09.02.03 "Programovanie v počítačových systémoch" » rozšírená skupina 09.00.00 "Informatika a výpočtová technika", z hľadiska zvládnutia hlavného druhu odbornej činnosti (VPD):

Vývoj softvérových softvérových modulov pre počítačové systémy a súvisiace odborné kompetencie (PC):

	Vykonajte vývoj špecifikácií pre jednotlivé komponenty.
	Vykonajte vývoj kódu softvérový produkt na základe hotových špecifikácií na úrovni modulu.
	Vykonajte ladenie programových modulov pomocou špecializovaných softvérových nástrojov.
	Vykonajte testovanie softvérových modulov.
	Vykonajte optimalizáciu programový kód modul.
	Vyvíjajte komponenty dizajnu a technickej dokumentácie pomocou jazykov grafických špecifikácií.

Program vzdelávacej praxe UP.01 odborného modulu PM.01 "Vývoj softvérových softvérových modulov pre počítačové systémy" možno využiť v doplnkovom odbornom vzdelávaní a odbornej príprave zamestnancov pre odbornosti 09.02.03 Programovanie v počítačových systémoch so stredoškolským ( úplné) všeobecné vzdelanie. Nevyžadujú sa pracovné skúsenosti.

1.2 Ciele a cielevzdelávacia prax UP.01

Na zvládnutie určeného druhu odbornej činnosti a príslušných odborných kompetencií musí študent v priebehu vzdelávacej praxe UP.01:

majú praktické skúsenosti:

vývoj algoritmu úlohy a jej implementácia pomocou počítačom podporovaného návrhu;

vývoj kódu softvérového produktu na základe hotovej špecifikácie na úrovni modulu;

používanie nástrojov vo fáze ladenia softvérového produktu;

testovanie softvérového modulu podľa špecifického scenára;

byť schopný:

vykonávať vývoj kódu programového modulu v moderných programovacích jazykoch;

vytvoriť program podľa vyvinutého algoritmu ako samostatný modul;

ladenie a testovanie programu na úrovni modulu;

vypracovať softvérovú dokumentáciu;

používať nástroje na automatizáciu prípravy dokumentácie;

vedieť:

hlavné fázy vývoja softvéru;

základné princípy štrukturálnej a objektovo orientovanej programovacej technológie;

základné princípy ladenia a testovania softvérových produktov;

metódy a prostriedky tvorby technickej dokumentácie.

1.3 Počet týždňov(hodiny) na vývoj programuvzdelávacia prax UP.01

Len 1,5 týždňa, 54 hodín.

2 VÝSLEDKY PRAXE

Výsledkom vzdelávacej praxe UP.01 odborného modulu PM.01 „Vývoj softvérových softvérových modulov pre počítačové systémy“ je rozvoj všeobecných kompetencií (OK):

	Názov výsledku cvičenia
	-
OK 2. Organizovať vlastné aktivity, voliť štandardné metódy a metódy plnenia odborných úloh, hodnotiť ich efektívnosť a kvalitu.
OK 3. Rozhodovať sa v štandardných a neštandardných situáciách a byť za ne zodpovedný.
OK 4. Vyhľadávať a využívať informácie potrebné na efektívnu realizáciu odborných úloh, profesijný a osobnostný rozvoj.
OK 5. Využívať informačné a komunikačné technológie v odborných činnostiach.
OK 6. Pracovať v tíme a v tíme, efektívne komunikovať s kolegami, vedením, spotrebiteľmi.
OK 7. Prevezmite zodpovednosť za prácu členov tímu (podriadených), za výsledok plnenia úloh.	-
	kvalifikácie
OK 9. Orientovať sa v podmienkach častých zmien technológií v profesionálnej činnosti.

odborné kompetencie (PC):

Druh odbornej činnosti		Názov výsledkov praxe
Zvládnutie hlavného typu profesionálnej činnosti		využívanie zdrojov lokálnych a globálnych počítačových sietí; Správa dátových súborov na lokálnych, vymeniteľných pamäťových zariadeniach, ako aj na diskoch lokálnej počítačovej siete a na internete; tlač, replikácia a kopírovanie dokumentov na tlačiarni a inom kancelárskom vybavení. priebežná kontrola vo forme správy o každej praktickej práci. modulová kvalifikačná skúška.
		gramotnosť a presnosť práce v aplikačných programoch: textové a grafické editory, databázy, editor prezentácií; rýchlosť vyhľadávania informácií v obsahu databáz.
		nastavenia presnosti a gramotnosti Email, serverový a klientsky softvér: rýchlosť vyhľadávania informácií pomocou technológií a služieb internetu; presnosť a gramotnosť zadávania a prenosu informácií pomocou internetových technológií a služieb.
		gramotnosť v používaní metód a prostriedkov na ochranu informácií pred neoprávneným prístupom; správnosť a presnosť Rezervovať kópiu a obnova dát;
		gramotnosť a presnosť práce so súborovými systémami, rôznymi formátmi súborov, programami na správu súborov;
		vedenie správ a technickej dokumentácie.

3 ŠTRUKTÚRA A OBSAH PROGRAMUTRÉNINGOVÁ PRAX UP.01

3.1 Tematický plán

Kódexy generovaných kompetencií

Názov profesionálneho modulu

Rozsah času, zaradený do praxe

(v týždňoch, hodiny)

Termíny

PC 1.1 - PC 1.6

PM.01 "Vývoj softvérových modulov pre počítačové systémy"

1,5 týždňa

54 hodín

3.2 Obsah precvičovania

Aktivity	Typy pracovných miest		Názov akademických disciplín, interdisciplinárne kurzy s uvedením tém, zabezpečenie výkonu druhov prác	Počet hodín (týždňov)
„Zvládnutie hlavného druhu odbornej činnosti »	Téma 1.Úvod. Algoritmy na riešenie problémov. Štruktúra lineárneho algoritmu. Štruktúra cyklického algoritmu. Algoritmus podprogramu (funkcie).	Formované vedomosti o základoch vytvárania špeciálnych predmetov
	Predmet2 . Prostredie Skratch (Scratch).	Získané znalosti o základoch nástrojov automatizácie procesov Získané vedomosti o základoch animačných efektov na objekty; používanie hypertextových odkazov a tlačidiel; demo nastavenie; prezentácie uložené v rôznych formátoch.	MDK.01.01 "Programovanie systému"
	Predmet 3 . Vytvorenie tréningového programu (poučenie z predmetu).	Získané poznatky o základoch analýzy dát pomocou procesorových funkcií	MDK.01.02 "Aplikované programovanie"
	Téma 4. Vývoj herného programu.	Sformované poznatky o základoch výpočtu výsledných charakteristík	MDK.01.01 "Programovanie systému"
	Téma 5. Jazyk grafické programovanie LabVIEW.	Sformované vedomosti o základoch tvorby procesorového testu.	MDK.01.02 "Aplikované programovanie"
	Predmet 6. Vytvorenie aplikácie pomocou LabVIEW.	Formovaná znalosť základov dialógu používateľa so systémom	MDK.01.02 "Aplikované programovanie"
	Predmet 7 Opätovné použitie fragmentu programu.	Získané znalosti o operátoroch a funkciách systému.	MDK.01.02 "Aplikované programovanie"
	Predmet 8 Workshop o LabVIEW. Ochrana práce pri práci s počítačom na pracovisku užívateľa.	Formujú sa počítačové znalosti elementárne funkcie. Získané poznatky o ochrane práce.	MDK.01.02 "Aplikované programovanie". OP.18 "Ochrana práce"
	Predmet 9 Závery. Zostavenie správy z praxe.	Formujú sa schopnosti analýzy počítačových technológií, riešenie problémov.	MDK.01.01 "Programovanie systému" MDK.01.02 "Aplikované programovanie" MDK.04.01 "Kancelársky softvér"

4 PODMIENKY ORGANIZÁCIE A VYKONÁVANIA

VZDELÁVACIA PRAX UP. 01

4.1 Požiadavky na dokumentáciu, potrebné pre prax:

Pracovný program vzdelávacej praxe UP.01 odborného modulu PM.01. „Vývoj softvérových modulov pre počítačové systémy“ je súčasťou vzdelávacieho programu pre stredoškolákov Štátnou odbornou vzdelávacou inštitúciou „Doneck Industrial and Economic College“ v súlade so štátnym vzdelávacím štandardom stredného odborného vzdelávania v odbore 09.02.03 "Programovanie v počítačových systémoch", založené na učebných osnov v odbore pracovný program v odboroch MDK.01.01 "Systémové programovanie", MDK01.02 "Aplikované programovanie", metodické odporúčania pre výchovno-vzdelávaciu a metodickú podporu praxe žiakov ovládajúcich vzdelávacie programy stredného odborného vzdelávania.

4.2 Požiadavky na edukačnú a metodickú podporu praxe:

zoznam schválených úloh podľa druhu práce, usmernenia pre študentov na výkon práce, odporúčania na realizáciu správ z praxe.

4.3 Požiadavky na logistiku:

organizácia priemyselnej praxe si vyžaduje prítomnosť učební a laboratórií.

Kancelárske vybavenie a pracoviská:

miesta podľa počtu žiakov (stôl, počítač, stolička);

pracovisko učiteľa (stôl, počítač, stolička);

skrinka na uloženie učebných pomôcok a informačných nosičov;

úlohy pre individuálny prístup k učeniu, organizácia samostatnej práce a cvičení, žiak na počítači;

referenčná a metodická literatúra;

súbor systémových, aplikačných a školiacich programov pre PC na optických a elektronických médiách;

časopis s výučbou študentov o ochrane práce;

súbor učebných pomôcok.

Technické tréningové pomôcky:

triedna tabuľa;

Osobný počítač s licencovaným softvérom;

laserova tlačiareň;

vzdelávacie počítače;
sada interaktívnych zariadení (projektor, plátno, reproduktory);
hasiace prostriedky (hasiaci prístroj).

Vybavenie kabinetu a pracovísk vývojových nástrojov: osobné počítače (monitor, systémová jednotka, klávesnica, myš), súbor edukačnej a metodickej dokumentácie, softvér v súlade s obsahom disciplíny (mušle programovacie jazyky).

Všetky počítače v triede sú pripojené lokálna sieť, majú prístup k sieťovému úložisku informácií a majú prístup na internet.

Komunikačné vybavenie:

sieťové adaptéry;

sieťové káble;

Bezdrôtové vybavenie WiFi.

Komponenty na inštaláciu sietí, zariadenia na inštaláciu.

4.4 Zoznam vzdelávacích publikácií, Internetové zdroje, doplnková literatúra

Hlavné zdroje:

Oliver V.G. Sieťové operačné systémy: učebnica pre univerzity / V.G. Olifer, N.A. Olifer. - 2. vyd. - Petrohrad: Peter, 2009,2008. - 668 s.:

E. Tanenbaum. OS. Vývoj a implementácia. Petrohrad: Piter, 2006. - 568 s.

Pupkov K.A. Zvládnutie operačného systému Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moskva: Rádio a komunikácia, 1994. - 112 s.

L. Beck Úvod do programovania systémov - M.: Mir, 1988.

Grekul V.I., Denishchenko G.N., Korovkina N.L. Dizajn informačných systémov / Moskva: Binom, 2008. - 304 s.

Lipaev, V.V. Softvérové inžinierstvo. Metodické základy [Text]: Proc. / V. V. Lipajev; Štát. un-t - Vyššia ekonomická škola. - M.: TEIS, 2006. - 608 s.

Lavrishcheva E. M., Petrukhin V. A. Metódy a prostriedky softvérového inžinierstva. - Učebnica

Ian Somerville. Softvérové inžinierstvo, 6. vydanie.: Per. z angličtiny. – M. : Williams Publishing House, 2002.―624 s.

Excel 2010: profesionálne programovanie vo VBA.: Per. z angličtiny. - M.: LLC „I.D. Williams“, 2012. - 944 s. : chorý. - Paral. sýkorka. Angličtina

Fowler M. Refaktoring: Zlepšenie existujúceho kódu. Z angličtiny.—St. Petersburg: Symbol Plus, 2003.—432 s.

Ďalšie zdroje:

Volkov V.A. METODICKÉ POKYNY na realizáciu praktická práca v disciplíne „Programovanie systému“, Doneck: DONPEK, 2015.

Volkov V.A. Smernice k realizácii projektu kurzu, Doneck: DONPEC, 2015.

internet- zdroje:

Systémové programovanie [ elektronický zdroj] / Režim prístupu: http://www.umk3.utmn.ru.

Softvér a internetové zdroje: http://www.intuit.ru

Literatúra podľa disciplíny - http://www.internet-technologies.ru/books/

Elektronická učebnica "Úvod do softvérového inžinierstva" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Elektronická učebnica "Technológia programovania" - http://bourabai.kz/alg/pro.htm

4.5 Požiadavky na vedúcich praxe zo vzdelávacej inštitúcie a organizácie

Požiadavky na vedúcich praxe zo vzdelávacej inštitúcie:

inžinierski a pedagogickí pracovníci: absolventi - učitelia medziodborových kurzov a všeobecných odborných disciplín. Prax v organizáciách príslušnej profesijnej oblasti je povinná.

Majster priemyselného výcviku: dostupnosť kvalifikačnej kategórie 5-6 s povinnou praxou v špecializovaných organizáciách aspoň raz za 3 roky. Prax v organizáciách príslušnej profesijnej oblasti je povinná.

5 MONITOROVANIE A HODNOTENIE VÝSLEDKOV

VZDELÁVACIA PRAX UP. 01

Forma výkazu o vzdelávacej praxi UP.01 - výkaz o praxi, vypracovaný v súlade s požiadavkami metodických odporúčaní.

výsledky (ovládnuté odborné kompetencie)	Základné ukazovatele výsledok prípravy	Formy a metódy ovládanie
PC 1.1. Vykonajte vývoj špecifikácií pre jednotlivé komponenty	Vývoj algoritmu úlohy a jej implementácia pomocou počítačom podporovaného návrhu	Odborné pozorovanie a hodnotenie činnosti žiaka v procese osvojovania si vzdelávacieho programu na praktických hodinách, pri výkone prác na výchovnej a priemyselnej praxi.
PC 1.2. Vykonajte vývoj kódu softvérového produktu na základe hotových špecifikácií na úrovni modulu.	Poznať základné princípy technológie štrukturálneho a objektovo orientovaného programovania. Uskutočniť vývoj kódu programového modulu v moderných programovacích jazykoch.
PC 1.3. Vykonajte ladenie programových modulov pomocou špecializovaných softvérových nástrojov	Vykonajte ladenie a testovanie programu na úrovni modulu.
PC 1.4. Vykonajte testovanie softvérových modulov.	Vytvorte program podľa vyvinutého algoritmu ako samostatný modul.
PC 1.5. Vykonajte optimalizáciu kódu modulu	Vývoj kódu softvérového produktu na základe hotovej špecifikácie na úrovni modulu.
PC 1.6. Vyvíjajte komponenty dizajnu a technickej dokumentácie pomocou jazykov grafických špecifikácií	Poznať metódy a prostriedky tvorby technickej dokumentácie. Pripravte softvérovú dokumentáciu. Použite nástroje na automatizáciu dokumentácie.

Formy a metódy sledovania a hodnotenia výsledkov vzdelávania by mali žiakom umožniť preveriť si nielen formovanie profesijných kompetencií, ale aj rozvoj všeobecných kompetencií a zručností, ktoré ich poskytujú.

výsledky (ovládol všeobecné kompetencie)	Hlavné ukazovatele na vyhodnotenie výsledku	Formy a metódy kontroly a hodnotenia
OK 1. Pochopte podstatu a spoločenský význam svojho budúceho povolania, prejavujte oň stály záujem.	Preukázanie trvalého záujmu o budúce povolanie; - opodstatnenosť uplatnenia osvojených odborných kompetencií;	Odborné pozorovanie a hodnotenie na praktických hodinách pri výkone prác na priemyselnej praxi;
OK 2. Organizovať vlastnú činnosť, určovať metódy a spôsoby plnenia odborných úloh, hodnotiť ich efektivitu a kvalitu.	Zdôvodnenie stanovenia cieľov, výberu a aplikácie metód a metód riešenia odborných problémov; Vykonávanie sebaanalýzy a korekcie výsledkov vlastnej práce	Hodnotenie na praktických hodinách pri výkone práce; Pozorovanie počas praxe; Introspekcia
OK 3. Riešiť problémy, posudzovať riziká a rozhodovať sa v neštandardných situáciách.	Efektívnosť rozhodovania štandardných a neštandardných odborných úloh pre určitý čas; Efektívnosť plánu optimalizovať kvalitu vykonanej práce	Interpretácia výsledkov sledovania činnosti žiaka v procese plnenia úloh
OK 4. Vyhľadávať, analyzovať a vyhodnocovať informácie potrebné pre nastavenie a riešenie profesionálnych problémov, profesionálny a osobný rozvoj.	Výber a analýza potrebných informácií pre prehľadnú a rýchlu realizáciu odborných úloh, profesionálny a osobný rozvoj	Odborné posúdenie v priebehu práce; Sebakontrola pri kladení a riešení problémov
OK 5. Využívať informačné a komunikačné technológie na zlepšenie odborných činností.	schopnosť využívať informačné a komunikačné technológie pri riešení odborných problémov	hodnotenie úloh
OK 6. Pracovať v tíme a tíme, zabezpečiť jeho súdržnosť, efektívne komunikovať s kolegami, vedením, spotrebiteľmi.	Schopnosť interakcie so skupinou, učiteľmi, majstrom priemyselného výcviku
OK 7. Stanoviť ciele, motivovať činnosť podriadených, organizovať a kontrolovať ich prácu s prevzatím zodpovednosti za výsledok úloh.	- sebaanalýzu a korekciu výsledkov vlastnej práce a práce tímu	Pozorovanie postupu práce v skupine v procese výrobnej praxe
OK 8. Samostatne si určovať úlohy profesionálneho a osobného rozvoja, venovať sa sebavzdelávaniu, vedome plánovať pokročilý tréning.	Organizácia samostatnej práce na formovaní kreatívneho a profesionálneho obrazu; Organizácia práce na sebavzdelávaní a zdokonaľovaní kvalifikácie	Pozorovanie a hodnotenie v procese priemyselnej praxe; Reflexná analýza (algoritmus akcií študentov); Praktický denník; Analýza portfólia študentov
OK 9. Buďte pripravení na zmenu technológií v odborných činnostiach.	Analýza inovácií v oblasti technologických procesov vývoja a výroby odevov	Hodnotenie riešení situačných problémov; Obchodné a organizačno-vzdelávacie hry; Pozorovanie a hodnotenie na praktických hodinách, v procese výrobnej praxe

Postup pri vývoji softvérového modulu.

1. štúdium a overenie špecifikácie modulu, výber programovacieho jazyka; (to znamená, že vývojár naštudovaním špecifikácie zistí, či je mu to jasné alebo nie, či dostatočne popisuje modul; potom si vyberie programovací jazyk, v ktorom bude modul napísaný, hoci programovacím jazykom môže byť napr. to isté pre celý PS)
2. výber algoritmu a dátovej štruktúry (tu sa ukáže, či sú známe nejaké algoritmy na riešenie problému a ak áno, použijú sa)
3. programovanie modulu (zápis programového kódu)
4. dolaďovanie textu modulu (úprava existujúcich komentárov, pridávanie ďalších komentárov pre zabezpečenie požadovanej kvality)
5. kontrola modulu (skontroluje sa logika modulu, odladí sa jeho práca)

Používajú sa nasledujúce metódy riadenia programového modulu:

- statická kontrola textu modulu (text sa číta od začiatku do konca, aby sa našli chyby v module. Na takejto kontrole sa zvyčajne okrem vývojára modulu podieľa jeden alebo aj niekoľko programátorov. Odporúča sa, aby chyby zistené počas takejto kontroly sa opravia nie okamžite, ale po dokončení čítania textu modulu)
- end-to-end sledovanie (manuálne rolovanie vykonávania modulu (operátor po operátorovi v poradí, ktoré vyplýva z logiky modulu) na určitej sade testov)
6. zostavenie modulu.

Štrukturálne programovanie.

Najpopulárnejšia programovacia technika súčasnosti je štruktúrované programovanie zhora nadol.

Štrukturálne programovanie je proces rozkladu algoritmu krok za krokom na menšie a menšie časti s cieľom získať prvky, pre ktoré sa dajú ľahko napísať špecifické predpisy.

Dva princípy štruktúrovaného programovania:

1. sekvenčné detaily „zhora nadol“
2. obmedzený základný súbor štruktúr na vytváranie algoritmov akéhokoľvek stupňa zložitosti

Požiadavky na štruktúrované programovanie:

1. Program by mal byť zostavený v malých krokoch, takže komplexná úloha je rozdelená na pomerne jednoduché, ľahko vnímateľné časti.
2. programová logika by mala byť založená na minimálnom počte dostatočne základných riadiacich štruktúr (lineárne, vetviace a cyklické štruktúry)

Hlavné vlastnosti a výhody štruktúrovaného programovania:

1. Zníženie zložitosti programov
2. možnosť predvedenia správnosti programov v rôznych štádiách riešenia problému
3. viditeľnosť programov
4. jednoduchosť úpravy (zmeny) programov.

Moderné programovacie nástroje by mali poskytovať maximálnu ochranu proti možné chyby vývojár.

Tu môžeme nakresliť analógiu s vývojom metód riadenia vozidiel. Bezpečnosť bola spočiatku zaistená prostredníctvom vývoja pravidiel cestnej premávky. Potom tu bol systém dopravného značenia a regulácia križovatiek. A napokon sa začali stavať dopravné križovatky, ktoré v zásade bránia križovaniu dopravných prúdov áut a chodcov. Použité prostriedky by však mali byť určené povahou riešeného problému: pre poľnú cestu dodržiavanie jednoduché pravidlo- "Pozri sa pod nohy a okolo."

Základná myšlienka štruktúrovaného programovania: program by mal byť súbor blokov kombinovaných v hierarchickej stromovej štruktúre, z ktorých každý má jeden vstup a jeden výstup.

Každý program môže byť zostavený iba pomocou troch základných typov blokov:

1. funkčný blok - samostatný lineárny operátor alebo ich poradie;
2. vetviaci blok - Ak
3. zovšeobecnená slučka - konštrukcia typu While

Je nevyhnutné, aby každá z týchto štruktúr mala z hľadiska riadenia len jeden vstup a jeden výstup. Zovšeobecnený operátor má teda tiež len jeden vstup a jeden výstup.

Štruktúrované programovanie sa niekedy označuje ako „programovanie bez GO TO“. Tu však nejde o vyhlásenie GO TO, ale o jeho nerozlišujúce používanie. Veľmi často sa pri implementácii štruktúrovaného programovania v niektorých programovacích jazykoch používa operátor prechodu (GO TO) na implementáciu štruktúrnych konštruktov bez toho, aby sa znížili hlavné výhody štruktúrovaného programovania. Sú to "neštrukturálne" príkazy skoku, ktoré mätú program, najmä skok na príkaz umiestnený v texte modulu nad (skôr) vykonávaným príkazom skoku. Snaha vyhnúť sa príkazu jump v niektorých jednoduchých prípadoch však môže viesť k príliš ťažkopádnym štruktúrovaným programom, čo nezlepšuje ich prehľadnosť a obsahuje nebezpečenstvo dodatočných chýb v texte modulu. Preto možno odporučiť vyhnúť sa používaniu príkazu skok všade, kde je to možné, ale nie na úkor prehľadnosti programu.

Užitočné prípady použitia operátora prechodu zahŕňajú opustenie slučky alebo procedúry za špeciálnej podmienky, ktorá „predčasne“ ukončí prácu tento cyklus alebo daný postup, t.j. ukončenie práce nejakej štruktúrnej jednotky (generalizovaný operátor) a tým len lokálne porušujúce štrukturalizáciu programu. Veľké ťažkosti (a komplikácie štruktúry) spôsobuje štrukturálna realizácia reakcie na výnimočné (často chybné) situácie, keďže si to vyžaduje nielen skorý výstup zo štruktúrneho celku, ale aj nevyhnutné spracovanie tejto situácie (napr. , vydávanie príslušných diagnostických informácií). Obslužný program výnimiek sa môže nachádzať na ktorejkoľvek úrovni štruktúry programu a možno k nemu pristupovať z rôznych nižších úrovní. Z technologického hľadiska je celkom prijateľné nasledovné „neštrukturálne“ vykonávanie reakcie na výnimočné situácie. Ovládače výnimiek sa umiestňujú na koniec toho či onoho konštrukčného celku a každý takýto ovládač je naprogramovaný tak, aby po dokončení svojej práce vyšiel z konštrukčného celku, na konci ktorého je umiestnený. Takýto handler je vyvolaný operátorom skoku z danej štruktúrnej jednotky (vrátane akejkoľvek vnorenej štruktúrnej jednotky).

Všeobecne povedané, hlavnou vecou v štruktúrovanom programovaní je kompetentná kompilácia toho správneho logický diagram program, ktorého realizácia jazykovými prostriedkami je druhoradá záležitosť.

Prechod od neformálneho k formálnemu je v podstate neformálny.

Prednáška 8

VÝVOJ SOFTWARE MODULU

Postup pri vývoji softvérového modulu. Štrukturálne programovanie a podrobný popis krok za krokom. Koncept pseudokódu. Ovládanie softvérového modulu.

8.1. Postup pri vývoji softvérového modulu.

Pri vývoji softvérového modulu je vhodné dodržať nasledovné poradie:

štúdium a overenie špecifikácií modulu, výber programovacieho jazyka;

výber algoritmu a štruktúry údajov;

programovanie (kódovanie) modulu;

leštenie textu modulu;

Kontrola modulu

kompilácia modulov.

Prvým krokom pri vývoji softvérového modulu je do značnej miery súvislá kontrola štruktúry programu zdola: preštudovaním špecifikácie modulu sa vývojár musí uistiť, že je pre neho zrozumiteľný a dostatočný na vývoj. tento modul. Na konci tohto kroku sa vyberie programovací jazyk: hoci programovací jazyk môže byť už preddefinovaný pre celý PS, v niektorých prípadoch (ak to programovací systém umožňuje) možno zvoliť iný jazyk, ktorý je pre implementáciu vhodnejší. tohto modulu (napríklad jazyk symbolických inštancií).

V druhom kroku vývoja softvérového modulu je potrebné zistiť, či už nie sú známe nejaké algoritmy na riešenie nastoleného alebo blízkeho problému. A ak existuje vhodný algoritmus, je vhodné ho použiť. Voľba vhodných dátových štruktúr, ktoré sa použijú, keď modul plní svoje funkcie, do značnej miery určuje logiku a ukazovatele kvality vyvíjaného modulu, preto ho treba považovať za veľmi dôležité rozhodnutie.

V treťom kroku sa vytvorí text modulu vo zvolenom programovacom jazyku. Množstvo najrôznejších detailov, ktoré treba brať do úvahy pri implementácii funkcií špecifikovaných v špecifikácii modulu, môže ľahko viesť k vytvoreniu veľmi neprehľadného textu obsahujúceho množstvo chýb a nepresností. Hľadanie chýb v takomto module a vykonanie požadovaných zmien môže byť časovo veľmi náročná úloha. Preto je veľmi dôležité použiť na zostavenie textu modulu technologicky opodstatnenú a prakticky overenú programátorskú disciplínu. Prvýkrát na to upozornil Dijkstra, ktorý sformuloval a zdôvodnil základné princípy štruktúrovaného programovania. Mnohé z programovacích disciplín, ktoré sú v praxi široko používané, sú založené na týchto princípoch. Najbežnejšia je disciplína „drill down“, o ktorej sa podrobne hovorí v častiach 8.2 a 8.3.

Ďalší krok vo vývoji modulu súvisí s dovedením textu modulu do finálnej podoby v súlade so špecifikáciou kvality PS. Pri programovaní modulu sa vývojár zameriava na správnu implementáciu funkcií modulu, pričom komentáre necháva nedokončené a umožňuje niektoré porušenia požiadaviek na štýl programu. Pri úprave textu modulu by mal upraviť komentáre v texte a prípadne pridať ďalšie komentáre, aby sa zabezpečili požadované kvalitatívne primitívy. Na ten istý účel je text programu upravený tak, aby spĺňal štylistické požiadavky.

Krok overenia modulu je manuálna kontrola vnútornej logiky modulu pred jeho ladením (pomocou jeho vykonania na počítači), implementuje všeobecný princíp formulovaný pre diskutované programovacie technológie, o potrebe kontrolovať prijímané rozhodnutia v jednotlivých etapách vývoja PS (pozri prednášku 3). Metódy validácie modulu sú uvedené v časti 8.4.

Nakoniec posledný krok vývoja modulu znamená dokončenie overenia modulu (pomocou kompilátora) a prechod na proces ladenia modulu.

8.2. Štrukturálne programovanie.

Pri programovaní modulu je potrebné mať na pamäti, že program musí byť zrozumiteľný nielen počítaču, ale aj osobe: vývojárovi modulu, osobám kontrolujúcim modul a testerom pripravujúcim testy na ladenie modulu. a správcovia PS, ktorí vykonajú požadované zmeny v module, sú nútení opakovane analyzovať logiku modulu. V moderných programovacích jazykoch existuje dostatok nástrojov na to, aby ste túto logiku zmiatli, ako chcete, čím sa modul stáva pre človeka ťažko zrozumiteľným a v dôsledku toho je nespoľahlivý alebo náročný na údržbu. Preto treba dbať na výber vhodných jazykových nástrojov a dodržiavať určitú programátorskú disciplínu. V tejto súvislosti Dijkstra navrhol postaviť program ako skladbu niekoľkých typov riadiacich štruktúr (štruktúr), čo môže výrazne zvýšiť zrozumiteľnosť logiky programu. Programovanie používajúce iba takéto konštrukcie sa nazýva štrukturálne.

Ryža. 8.1. Základné riadiace štruktúry štruktúrovaného programovania.

Hlavné konštrukcie štruktúrovaného programovania sú: nasledovať, vetviť a opakovať (pozri obrázok 8.1). Zložkami týchto konštrukcií sú zovšeobecnené operátory (spracovacie uzly) S, S1, S2 a podmienka (predikát) P. Ako zovšeobecnený operátor môže existovať buď jednoduchý operátor použitého programovacieho jazyka (priradenie, vstup, výstup, procedúra). volania), alebo fragment programu, ktorý je zložením hlavných riadiacich štruktúr štruktúrovaného programovania. Je nevyhnutné, aby každá z týchto štruktúr mala z hľadiska riadenia len jeden vstup a jeden výstup. Zovšeobecnený operátor má teda tiež len jeden vstup a jeden výstup.

Je tiež veľmi dôležité, že tieto konštrukcie sú už matematickými objektmi (čo v podstate vysvetľuje dôvod úspechu štruktúrovaného programovania). Je dokázané, že pre každý neštruktúrovaný program je možné zostaviť funkčne ekvivalentný (tj riešiaci rovnaký problém) štruktúrovaný program. Pri štruktúrovaných programoch je možné niektoré vlastnosti dokázať matematicky, čo umožňuje odhaliť niektoré chyby v programe. Tejto problematike bude venovaná samostatná prednáška.

Štruktúrované programovanie sa niekedy označuje ako „programovanie bez GO TO“. Tu však nejde o vyhlásenie GO TO, ale o jeho nerozlišujúce používanie. Veľmi často sa pri implementácii štrukturálneho programovania v niektorých programovacích jazykoch (napríklad vo FORTRAN) používa na implementáciu štrukturálnych konštrukcií operátor prechodu (GO TO), ktorý neporušuje princípy štrukturálneho programovania. Sú to "neštrukturálne" skokové príkazy, ktoré mätú program, najmä skok na príkaz umiestnený v texte modulu nad (pred) vykonávaným príkazom skoku. Snaha vyhnúť sa príkazu jump v niektorých jednoduchých prípadoch však môže viesť k príliš ťažkopádnym štruktúrovaným programom, čo nezlepšuje ich prehľadnosť a obsahuje nebezpečenstvo dodatočných chýb v texte modulu. Preto možno odporučiť vyhnúť sa používaniu príkazu skok všade, kde je to možné, ale nie na úkor prehľadnosti programu.

Užitočné prípady použitia operátora prechodu zahŕňajú opustenie slučky alebo procedúry za špeciálnej podmienky, ktorá „predčasne“ ukončí prácu tejto slučky alebo tejto procedúry, t. j. ukončí prácu niektorej štrukturálnej jednotky (generalizovaný operátor), a tým len lokálne poruší štruktúrovanosť programu. Veľké ťažkosti (a komplikácie štruktúry) spôsobuje štrukturálna realizácia reakcie na výnimočné (často chybné) situácie, keďže si to vyžaduje nielen skorý odchod zo štruktúrneho celku, ale aj nevyhnutné spracovanie (vylúčenie) tejto situácie. (napríklad vydanie vhodnej diagnostickej informácie). Obslužný program výnimiek sa môže nachádzať na ktorejkoľvek úrovni štruktúry programu a možno k nemu pristupovať z rôznych nižších úrovní. Z technologického hľadiska je celkom prijateľné nasledovné „neštrukturálne“ vykonávanie reakcie na výnimočné situácie. Ovládače výnimiek sa umiestňujú na koniec toho či onoho konštrukčného celku a každý takýto ovládač je naprogramovaný tak, aby po dokončení svojej práce vyšiel z konštrukčného celku, na konci ktorého je umiestnený. Takýto handler je vyvolaný operátorom skoku z danej štruktúrnej jednotky (vrátane akejkoľvek vnorenej štruktúrnej jednotky).

8.3. Podrobný popis a koncept pseudokódu.

Štruktúrované programovanie poskytuje odporúčania o tom, aký by mal byť text modulu. Vynára sa otázka, ako by mal programátor postupovať, aby takýto text skonštruoval. Programovanie modulu často začína konštrukciou jeho blokovej schémy, ktorá vo všeobecnosti popisuje logiku jeho činnosti. Avšak moderná technológia programátor neodporúča robiť to bez vhodnej počítačovej podpory. Hoci vývojové diagramy poskytujú veľmi vizuálnu reprezentáciu logiky modulu, keď sú manuálne kódované v programovacom jazyku, vzniká veľmi špecifický zdroj chýb: mapovanie v podstate dvojrozmerných štruktúr, ako sú vývojové diagramy, na lineárny text reprezentujúci modul, obsahuje nebezpečenstvo narušenia logiky modulu, najmä preto, že je psychologicky dosť ťažké udržať si vysokú úroveň pozornosti pri jeho opätovnom prezeraní. Výnimkou môže byť prípad, keď sa použije zostavenie blokových diagramov grafický editor a sú natoľko formalizované, že sa z nich automaticky generuje text v programovacom jazyku (ako sa to robí napríklad v R-technológii).

Ako hlavnú metódu konštrukcie textu modulu odporúča moderná programovacia technológia krok za krokom detail. Podstatou tejto metódy je rozdeliť proces tvorby textu modulu do niekoľkých krokov. Na prvom

Krok popisuje všeobecnú schému fungovania modulu vo viditeľnej lineárnej textovej forme (teda pomocou veľmi rozsiahlych konceptov), pričom tento popis nie je úplne formalizovaný a je zameraný na ľudské vnímanie. V každom ďalšom kroku je jeden z konceptov spresnený a podrobný (nazveme ho špecifikované) v akomkoľvek popise vyvinutom v jednom z predchádzajúcich krokov. Výsledkom tohto kroku je vytvorenie popisu vybraného upresňovaného konceptu buď z hľadiska základný jazyk programovanie (t. j. modul vybraný na prezentáciu), alebo v rovnakej forme ako v prvom kroku s využitím nových prepracovaných konceptov. Tento proces končí, keď sú všetky špecifikované pojmy objasnenia(t. j. budú prípadne vyjadrené v základnom programovacom jazyku). Posledným krokom je získanie textu modulu v základnom programovacom jazyku nahradením všetkých výskytov spresnených pojmov ich špecifikovanými popismi a vyjadrením všetkých výskytov štruktúrovaných programovacích konštrukcií pomocou tohto programovacieho jazyka.

Postupné zdokonaľovanie je spojené s použitím čiastočne formalizovaného jazyka na reprezentáciu špecifikovaných popisov, tzv. pseudokód. Tento jazyk umožňuje použitie všetkých štruktúrovaných programovacích konštrukcií, ktoré sú formalizované, spolu s neformálnymi fragmentmi prirodzeného jazyka na reprezentáciu všeobecných vyhlásení a podmienok. Zodpovedajúce fragmenty v základnom programovacom jazyku môžu byť tiež špecifikované ako zovšeobecnené operátory a podmienky.

· začiatok modulu v základnom jazyku, t. j. prvá veta alebo nadpis (špecifikácia) tohto modulu;

časť (súbor) popisov v základnom jazyku a namiesto popisov procedúr a funkcií len ich vonkajší dizajn;

· neformálne označenie poradia operátorov hlavného modulu ako jedného zovšeobecneného operátora (pozri nižšie), ako aj neformálne označenie hlavného orgánu každého popisu postupu alebo funkcie ako jedného všeobecného operátora;

· posledná veta (koniec) modulu v základnom jazyku.

Vonkajší návrh popisu postupu alebo funkcie je prezentovaný podobným spôsobom. V nadväznosti na Dijkstru by však bolo lepšie tu časť opisov prezentovať aj s neformálnym zápisom, pričom by sme ju uviedli ako samostatný opis.

Neformálne označenie zovšeobecneného operátora v pseudokóde sa robí v prirodzenom jazyku ľubovoľnou vetou, ktorá odhaľuje jeho obsah vo všeobecných pojmoch. Jediná formálna požiadavka na dizajn takéhoto označenia je nasledovná: táto veta musí zaberať jeden alebo viac grafických (tlačených) riadkov ako celok a končiť bodkou (alebo iným špeciálne určeným znakom).

Ryža. 8.2. Základné konštrukcie štruktúrovaného programovania v pseudokóde.

Pre každý neformálny zovšeobecnený operátor musí byť vytvorený samostatný popis, ktorý vyjadruje logiku jeho práce (spresňuje jeho obsah) pomocou zloženia hlavných štruktúr štruktúrovaného programovania a iných zovšeobecnených operátorov. Nadpis takéhoto opisu by mal byť neformálnym označením všeobecného prevádzkovateľa, ktorý sa spresňuje. Základné konštrukcie štruktúrovaného programovania možno znázorniť nasledovne (pozri obrázok 8.2). Tu môže byť podmienka buď explicitne špecifikovaná v základnom programovacom jazyku ako booleovský výraz, alebo neformálne reprezentovaná v prirodzenom jazyku nejakým fragmentom, ktorý načrtáva význam tejto podmienky. V druhom prípade by sa mal vytvoriť samostatný popis s podrobným popisom tejto podmienky s uvedením označenia tejto podmienky (fragment v prirodzenom jazyku) ako názvu.

Výstup z opakovania (slučka):

Postup ukončenia (funkcia):

J. Hughes, J. Michtom. Štrukturálny prístup k programovaniu. - M.: Mir, 1980. - s. 29-71.

V. Turský. Metodika programovania. - M.: Mir, 1981. - s. 90-164.

E.A. Zhogolev. Technologické základy modulárneho programovania // Programovanie, 1980, č.2. - str. 44-49.

R.C. Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6). - p. 879-893.

G. Myers. Spoľahlivosť softvéru. - M.: Mir, 1980. - s. 92-113.

I.Pyle. ADA je jazyk vstavaných systémov. M.: Financie a štatistika, 1984. - s. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Princípy vývoja softvéru. - M.: Mir, 1982, s. 65-71.

A.L. Fuksman. Technologické aspekty tvorby softvérové systémy. M.: Štatistika, 1979. - s. 79-94.

Prednáška 8. Vývoj softvérového modulu
Postup pri vývoji softvérového modulu. Štrukturálne programovanie a podrobný popis krok za krokom. Koncept pseudokódu. Ovládanie softvérového modulu.
8.1. Postup pri vývoji softvérového modulu.
Pri vývoji softvérového modulu je vhodné dodržať nasledovné poradie:
štúdium a overenie špecifikácie modulu, výber jazyka
programovanie;
výber algoritmu a štruktúry údajov;
programovanie modulov;
leštenie textu modulu;
kontrola modulu;
kompilácia modulov.
Prvým krokom pri vývoji softvérového modulu je do značnej miery súvislá kontrola štruktúry programu zdola: preštudovaním špecifikácie modulu sa vývojár musí uistiť, že je pre neho zrozumiteľný a dostatočný na vývoj. tento modul. Na konci tohto kroku sa vyberie programovací jazyk: hoci programovací jazyk môže byť už preddefinovaný pre celý PS, v niektorých prípadoch (ak to programovací systém umožňuje) možno zvoliť iný jazyk, ktorý je pre implementáciu vhodnejší. tohto modulu (napríklad jazyk symbolických inštancií).
V druhom kroku vývoja softvérového modulu je potrebné zistiť, či už nie sú známe nejaké algoritmy na riešenie nastoleného alebo blízkeho problému. A ak existuje vhodný algoritmus, je vhodné ho použiť. Voľba vhodných dátových štruktúr, ktoré sa použijú, keď modul plní svoje funkcie, do značnej miery určuje logiku a ukazovatele kvality vyvíjaného modulu, preto ho treba považovať za veľmi dôležité rozhodnutie.
V treťom kroku sa vytvorí text modulu vo zvolenom programovacom jazyku. Množstvo najrôznejších detailov, ktoré treba brať do úvahy pri implementácii funkcií špecifikovaných v špecifikácii modulu, môže ľahko viesť k vytvoreniu veľmi neprehľadného textu obsahujúceho množstvo chýb a nepresností. Hľadanie chýb v takomto module a vykonanie požadovaných zmien môže byť časovo veľmi náročná úloha. Preto je veľmi dôležité použiť na zostavenie textu modulu technologicky opodstatnenú a prakticky overenú programátorskú disciplínu. Prvýkrát na to upozornil Dijkstra, ktorý sformuloval a zdôvodnil základné princípy štruktúrovaného programovania. Mnohé z programovacích disciplín, ktoré sú v praxi široko používané, sú založené na týchto princípoch. Najbežnejšia je disciplína „drill down“, o ktorej sa podrobne hovorí v častiach 8.2 a 8.3.
Ďalší krok vo vývoji modulu súvisí s dovedením textu modulu do finálnej podoby v súlade so špecifikáciou kvality PS. Pri programovaní modulu sa vývojár zameriava na správnu implementáciu funkcií modulu, pričom komentáre necháva nedokončené a umožňuje niektoré porušenia požiadaviek na štýl programu. Pri úprave textu modulu by mal upraviť komentáre v texte a prípadne pridať ďalšie komentáre, aby sa zabezpečili požadované kvalitatívne primitívy. Na ten istý účel je text programu upravený tak, aby spĺňal štylistické požiadavky.
Krok overenia modulu je manuálna kontrola vnútornej logiky modulu pred jeho ladením (pomocou jeho vykonania na počítači), implementuje všeobecný princíp formulovaný pre diskutovanú programovaciu technológiu, o potrebe kontrolovať rozhodnutia prijaté v každej fáze Rozvoj PS (pozri prednášku 3). Metódy validácie modulu sú uvedené v časti 8.4.
Nakoniec posledný krok vývoja modulu znamená dokončenie overenia modulu (pomocou kompilátora) a prechod na proces ladenia modulu.
8.2. Štrukturálne programovanie.
Pri programovaní modulu je potrebné mať na pamäti, že program musí byť zrozumiteľný nielen počítaču, ale aj osobe: vývojárovi modulu a osobám, ktoré modul kontrolujú, ako aj textárom pripravujúcim testy na ladenie a správcovia PS, ktorí vykonajú požadované zmeny v module, budú musieť opakovane analyzovať logiku modulu. V moderných programovacích jazykoch existuje dostatok nástrojov na to, aby ste túto logiku zmiatli, ako chcete, čím sa modul stáva pre človeka ťažko zrozumiteľným a v dôsledku toho je nespoľahlivý alebo náročný na údržbu. Preto treba dbať na výber vhodných jazykových nástrojov a dodržiavať určitú programátorskú disciplínu. Prvýkrát na to upozornil Dijkstra a navrhol postaviť program ako skladbu niekoľkých typov riadiacich štruktúr (štruktúr), čo môže značne zvýšiť zrozumiteľnosť logiky programu. Programovanie využívajúce len takéto konštrukty sa nazývalo štrukturálne programovanie.
Hlavné konštrukcie štruktúrovaného programovania sú: nasledovať, vetviť a opakovať (pozri obrázok 8.1). Zložkami týchto konštrukcií sú zovšeobecnené operátory (spracovacie uzly) S, S1, S2 a podmienka (predikát) P. Ako zovšeobecnený operátor môže existovať buď jednoduchý operátor použitého programovacieho jazyka (priradenie, vstup, výstup, procedúra). volania), alebo fragment programu, ktorý je zložením hlavných riadiacich štruktúr štruktúrovaného programovania. Je nevyhnutné, aby každá z týchto štruktúr mala z hľadiska riadenia len jeden vstup a jeden výstup. Zovšeobecnený operátor má teda tiež len jeden vstup a jeden výstup.
Je tiež veľmi dôležité, že tieto konštrukcie sú už matematickými objektmi (čo v podstate vysvetľuje dôvod úspechu štruktúrovaného programovania). Je dokázané, že pre každý neštruktúrovaný program je možné zostaviť funkčne ekvivalentný (teda riešiaci rovnaký problém) štruktúrovaný program. Pri štruktúrovaných programoch je možné niektoré vlastnosti dokázať matematicky, čo umožňuje odhaliť niektoré chyby v programe. Tejto problematike bude venovaná samostatná prednáška.
Štruktúrované programovanie sa niekedy označuje ako „programovanie bez GO TO“. Tu však nejde o vyhlásenie GO TO, ale o jeho nerozlišujúce používanie. Veľmi často sa pri implementácii štruktúrovaného programovania v niektorých programovacích jazykoch (napríklad vo FORTRAN) používa operátor prechodu (GO TO) na implementáciu štruktúrnych štruktúr bez zníženia hlavných výhod štruktúrovaného programovania. Sú to "neštrukturálne" príkazy skoku, ktoré mätú program, najmä skok na príkaz umiestnený v texte modulu nad (skôr) vykonávaným príkazom skoku. Snaha vyhnúť sa príkazu jump v niektorých jednoduchých prípadoch však môže viesť k príliš ťažkopádnym štruktúrovaným programom, čo nezlepšuje ich prehľadnosť a obsahuje nebezpečenstvo dodatočných chýb v texte modulu. Preto možno odporučiť vyhnúť sa používaniu príkazu skok všade, kde je to možné, ale nie na úkor prehľadnosti programu.
Užitočné prípady použitia operátora prechodu zahŕňajú opustenie slučky alebo procedúry za špeciálnej podmienky, ktorá "predčasne" ukončí prácu tejto slučky alebo tejto procedúry, t.j. ukončenie práce nejakého štruktúrneho celku (generalizovaného operátora) a tým len lokálne narušenie štruktúrovanosti programu. Veľké ťažkosti (a komplikácie štruktúry) spôsobuje štrukturálna realizácia reakcie na výnimočné (často chybné) situácie, keďže si to vyžaduje nielen skorý odchod zo štruktúrneho celku, ale aj nevyhnutné spracovanie (vylúčenie) tejto situácie. (napríklad vydanie vhodnej diagnostickej informácie). Obslužný program výnimiek sa môže nachádzať na ktorejkoľvek úrovni štruktúry programu a možno k nemu pristupovať z rôznych nižších úrovní. Z technologického hľadiska je celkom prijateľné nasledovné „neštrukturálne“ vykonávanie reakcie na výnimočné situácie. Ovládače výnimiek sa umiestňujú na koniec toho či onoho konštrukčného celku a každý takýto ovládač je naprogramovaný tak, aby po dokončení svojej práce vyšiel z konštrukčného celku, na konci ktorého je umiestnený. Takýto handler je vyvolaný operátorom skoku z danej štruktúrnej jednotky (vrátane akejkoľvek vnorenej štruktúrnej jednotky).
8.3. Podrobný popis a koncept pseudokódu.
Štruktúrované programovanie poskytuje odporúčania o tom, aký by mal byť text modulu. Vynára sa otázka, ako by mal programátor postupovať, aby takýto text skonštruoval. Niekedy sa programovanie modulu začína konštrukciou jeho blokovej schémy, ktorá vo všeobecnosti popisuje logiku jeho činnosti. Moderné programovacie technológie to však neodporúčajú. Hoci vývojové diagramy poskytujú veľmi vizuálnu reprezentáciu logiky modulu, keď sú zakódované v programovacom jazyku, vzniká veľmi špecifický zdroj chýb: mapovanie v podstate dvojrozmerných štruktúr, ako sú vývojové diagramy, na lineárny text reprezentujúci modul, obsahuje nebezpečenstvo narušenia logiky modulu, navyše je psychologicky dosť náročné udržať si vysokú mieru pozornosti pri jeho opätovnom prezeraní. Výnimkou môže byť prípad, keď sa na zostavenie vývojových diagramov použije grafický editor a tie sú formalizované tak, že sa z nich automaticky generuje text v programovacom jazyku (ako je to napríklad možné v R - technológii).
Moderná programovacia technológia ako hlavnú metódu vytvárania textu modulu odporúča detailnú úpravu krok za krokom. Podstatou tejto metódy je rozdeliť proces tvorby textu modulu do niekoľkých krokov. V prvom kroku je popísaná všeobecná schéma fungovania modulu vo viditeľnej lineárnej textovej forme (teda pomocou veľmi rozsiahlych konceptov), pričom tento popis nie je úplne formalizovaný a je zameraný na ľudské vnímanie. V každom ďalšom kroku sa jeden z konceptov (nazveme ho spresnený) spresní a spresní, ktorý sa používa (spravidla nie formalizovaný) v každom popise vyvinutom v jednom z predchádzajúcich krokov. Výsledkom tohto kroku je vytvorenie popisu vybraného konceptu, ktorý sa spresňuje, buď v zmysle základného programovacieho jazyka (t. j. modulu zvoleného na reprezentáciu), alebo v rovnakej forme ako v prvom kroku s použitím nových konceptov, ktoré sa spresňujú. . Tento proces končí, keď sú všetky vylepšované koncepty nakoniec vyjadrené v základnom programovacom jazyku. Posledným krokom je získanie textu modulu v základnom programovacom jazyku nahradením všetkých výskytov spresnených pojmov ich špecifikovanými popismi a vyjadrením všetkých výskytov štruktúrovaných programovacích konštrukcií pomocou tohto programovacieho jazyka.
Podrobná podrobná analýza zahŕňa použitie čiastočne formalizovaného jazyka na reprezentáciu uvedených popisov, ktorý sa nazýva pseudokód. Tento jazyk umožňuje použitie všetkých štruktúrovaných programovacích konštrukcií, ktoré sú formalizované, spolu s neformálnymi fragmentmi prirodzeného jazyka na reprezentáciu všeobecných vyhlásení a podmienok. Zodpovedajúce fragmenty v základnom programovacom jazyku môžu byť tiež špecifikované ako zovšeobecnené operátory a podmienky.
Za popis hlavy v pseudokóde možno považovať externý návrh modulu v základnom programovacom jazyku, ktorý
začiatok modulu v základnom jazyku, t.j. prvá veta alebo nadpis (špecifikácia) tohto modulu;
časť (súbor) popisov v základnom jazyku a namiesto popisov procedúr a funkcií len ich vonkajší dizajn;
neformálne označenie postupnosti príkazov tela modulu ako jeden zovšeobecnený príkaz (pozri nižšie), ako aj neformálne označenie postupnosti príkazov tela každého popisu procedúry alebo funkcie ako jeden zovšeobecnený príkaz;
posledná veta (koniec) modulu v základnom jazyku.
Vonkajší návrh popisu postupu alebo funkcie je prezentovaný podobným spôsobom. V nadväznosti na Dijkstru by však bolo lepšie tu časť opisov prezentovať aj s neformálnym zápisom, pričom by sme ju uviedli ako samostatný opis.
Neformálne označenie zovšeobecneného operátora v pseudokóde sa robí v prirodzenom jazyku ľubovoľnou vetou, ktorá odhaľuje jeho obsah vo všeobecných pojmoch. Jediná formálna požiadavka na dizajn takéhoto označenia je nasledovná: táto veta musí zaberať jeden alebo viac grafických (tlačených) riadkov v celom rozsahu a končiť bodkou.
Pre každý neformálny zovšeobecnený operátor musí byť vytvorený samostatný popis, ktorý vyjadruje logiku jeho práce (spresňuje jeho obsah) pomocou zloženia hlavných štruktúr štruktúrovaného programovania a iných zovšeobecnených operátorov. Nadpis takéhoto opisu by mal byť neformálnym označením všeobecného prevádzkovateľa, ktorý sa spresňuje. Základné konštrukcie štruktúrovaného programovania možno znázorniť nasledovne (pozri obrázok 8.2). Tu môže byť podmienka buď explicitne špecifikovaná v základnom programovacom jazyku ako booleovský výraz, alebo neformálne reprezentovaná v prirodzenom jazyku nejakým fragmentom, ktorý načrtáva význam tejto podmienky. V druhom prípade by sa mal vytvoriť samostatný popis s podrobným popisom tejto podmienky s uvedením označenia tejto podmienky (fragment v prirodzenom jazyku) ako názvu.
Ryža. 8.2. Základné konštrukcie štruktúrovaného programovania v pseudokóde.
Ryža. 8.3. Konkrétne prípady operátora prechodu ako všeobecného operátora.
Ako zovšeobecnený operátor v pseudokóde môžete použiť vyššie uvedené špeciálne prípady operátora prechodu (pozri obr. 8.3). Postupnosť obsluhy výnimiek (výnimiek) je špecifikovaná na konci popisu modulu alebo procedúry (funkcie). Každý takýto handler vyzerá takto:
EXCEPTION názov_výnimky
generic_operator
VŠETKY VÝNIMKY
Rozdiel medzi obsluhou výnimky a procedúrou bez parametrov je nasledovný: po vykonaní procedúry sa riadenie vráti k príkazu nasledujúcemu po jej volaní a po vykonaní výnimky sa riadenie vráti k príkazu nasledujúcemu po volaní modulu. alebo procedúra (funkcia), na konci ktorej (ktorej) je táto výnimka umiestnená.
Odporúča sa v každom kroku detailovania vytvoriť dostatočne zmysluplný popis, ale dobre viditeľný (vizuálny), aby bol umiestnený na jednu stranu textu. Spravidla to znamená, že takýto popis by mal byť zložením piatich alebo šiestich štruktúrovaných programovacích konštruktov. Odporúča sa aj umiestnenie vnorených štruktúr s posunom doprava o niekoľko polôh (viď obr. 8.4). Výsledkom je, že môžete získať popis logiky práce z hľadiska viditeľnosti, ktorý je celkom konkurencieschopný vývojovým diagramom, ale má významnú výhodu - lineárnosť popisu je zachovaná.

VYMAZAJTE ZÁZNAMY SÚBORU PRED PRVÝM,

VHODNÉ PRE SET FILTER:

NASTAVTE ZAČIATOK SÚBORU.

AK VYHOVUJE INÝ REKORD

FILTROVAŤ DO

VYMAZAJTE ZO SÚBORU ĎALŠÍ ZÁZNAM.

VŠETKO AK

ZBOHOM

AK ZÁPIS NEBUDE VYMAZANÝ

TYP „ZÁZNAMY NEVYMAZANÉ“.

VYTLAČTE „ODSTRANENÉ n ZÁZNAMY“.

VŠETKO AK

Ryža. 8.4. Príklad jedného kroku detailovania v pseudokóde.

Myšlienka podrobných detailov krok za krokom sa niekedy pripisuje Dijkstrovi. Dijkstra však navrhol zásadne odlišnú metódu konštrukcie textu modulu, ktorá sa nám zdá hlbšia a perspektívnejšia. Najprv spolu so spresňovaním operátorov navrhol postupne (krok za krokom) spresňovať (detailovať) používané dátové štruktúry. Po druhé, v každom kroku navrhol vytvorenie určitého virtuálneho stroja na detailovanie a v jeho zmysle podrobne opísať všetky rafinované koncepty, ktorým to tento stroj umožňuje. Dijkstra teda v podstate navrhol detailovanie horizontálnymi vrstvami, čo je prenesenie jeho predstavy o vrstvených systémoch (pozri prednášku 6) na úroveň vývoja modulov. Tento spôsob vývoja modulov je v súčasnosti podporovaný jazykovými balíkmi ADA a objektovo orientovanými programovacími nástrojmi.
8.4. Ovládanie softvérového modulu.
Používajú sa nasledujúce metódy riadenia programového modulu:
statická kontrola textu modulu;
end-to-end sledovanie;
dôkaz o vlastnostiach softvérového modulu.
Počas statickej kontroly textu modulu sa tento text číta od začiatku do konca, aby sa našli chyby v module. Zvyčajne sa na takejto kontrole okrem vývojára modulu podieľa ešte jeden alebo dokonca niekoľko programátorov. Chyby zistené pri takejto kontrole sa odporúča opraviť nie okamžite, ale až po dokončení čítania textu modulu.
End-to-end sledovanie je jedným z typov dynamického riadenia modulu. Zahŕňa tiež niekoľko programátorov, ktorí manuálne prechádzajú vykonávaním modulu (príkaz po príkaze v poradí, ktoré vyplýva z logiky modulu) na určitej sade testov.
Ďalšia prednáška je venovaná dokazovaniu vlastností programov. Tu treba len poznamenať, že táto metóda je stále veľmi zriedka používaná.
Literatúra na prednášku 8.
8.2. E. Dijkstra. Poznámky k štruktúrovanému programovaniu// W. Dahl, E. Dijkstra, K. Hoor. Štrukturálne programovanie. - M.: Mir, 1975. - S. 24-97.
8.3. N. Wirth. Systematické programovanie. - M.: Mir, 1977. - S. 94-164.
Prednáška 9
Pojem odôvodnenia programu. Formalizácia vlastností programu, Hoorova triáda. Pravidlá pre nastavenie vlastností priraďovacieho operátora, podmieneného operátora a zloženého operátora. Pravidlá pre stanovenie vlastností operátora slučky, koncept invariantu slučky. Ukončenie vykonávania programu.
9.1. Programové odôvodnenia. Formalizácia vlastností programu.
Na zlepšenie spoľahlivosti softvérových nástrojov je veľmi užitočné dodať programy Ďalšie informácie, s použitím ktorých je možné výrazne zvýšiť úroveň kontroly PS. Takéto informácie môžu byť poskytnuté vo forme neformálnych alebo formalizovaných vyhlásení, ktoré sú viazané na rôzne fragmenty programu. Takéto tvrdenia budeme nazývať programové zdôvodnenia. Neformalizované zdôvodnenia programov môžu napríklad vysvetliť motívy prijímania určitých rozhodnutí, čo môže výrazne uľahčiť vyhľadávanie a nápravu chýb, ako aj štúdium programov pri ich udržiavaní. Formalizované zdôvodnenia umožňujú dokazovať niektoré vlastnosti programov ako ručne, tak aj automaticky ovládať (nastavovať).
Jedným z v súčasnosti používaných konceptov formálneho zdôvodnenia programov je používanie takzvaných Hoorových triád. Nech S je nejaký zovšeobecnený operátor nad informačným prostredím IS, P a Q - nejaké predikáty (príkazy) nad týmto prostredím. Potom sa zápis (P)S(Q) nazýva Hoorova triáda, v ktorej sa predikát P nazýva predpodmienka a predikát Q sa nazýva postpodmienka vzhľadom na operátor S. Operátor (najmä program) Hovorí sa, že S má vlastnosť (P)S(Q) , ak je predikát P pravdivý pred vykonaním S, predikát Q je pravdivý po vykonaní S.
Jednoduché príklady vlastností programu:
(9,1) (n=0) n:=n+1 (n=1),
(9.2) (č
(9.3) (č
(9,4) (n>0) p:=1; m:=1;
KEĎ m /= n DO
ZBOHOM
Na preukázanie vlastnosti programu S využívame vlastnosti jednoduchých operátorov programovacieho jazyka (tu sa obmedzíme na prázdny operátor a operátor priradenia) a vlastnosti riadiacich štruktúr (kompozícií), z ktorých je program zostavený. jednoduché operátory (tu sa obmedzíme na tri hlavné kompozície štruktúrovaného programovania, pozri prednášku 8). Tieto vlastnosti sa zvyčajne nazývajú pravidlá overovania programu.
9.2. Vlastnosti jednoduchých operátorov.
Pre prázdny operátor,
Veta 9.1. Nech P je predikát nad informačným prostredím. Potom platí vlastnosť (P)(P).
Dôkaz tejto vety je zrejmý: prázdny operátor nemení stav informačného prostredia (v súlade so svojou sémantikou), takže jeho predpoklad zostáva pravdivý aj po jeho vykonaní.
Pre operátora priradenia
Veta 9.2. Nech informačné prostredie IS pozostáva z premennej X a zvyšok informačného prostredia RIS:
Potom majetok
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)),
kde F(X, RIS) je nejaká jednohodnotová funkcia, Q je predikát.
Dôkaz. Pred vykonaním operátora priradenia nech je pravdivý predikát Q(F(X0, RIS0), RIS0), kde (X0, RIS0) je nejaký ľubovoľný stav informačného prostredia IS, potom po vykonaní operátora priradenia predikát Q(X, RIS) bude pravdivé, teda to, ako X dostane hodnotu F(X0, RIS0) a stav RIS sa daným priraďovacím príkazom nemení, a teda po vykonaní tohto priraďovacieho príkazu v tomto prípade
Q(X, RIS0) = Q(F(Xo, RIS0), RIS0).
Na základe svojvoľnosti výberu stavu informačného prostredia je teorém dokázaný.
Príkladom vlastnosti operátora priradenia je príklad 9.1.
9.3. Vlastnosti základných štruktúr štruktúrneho programovania.
Zvážte teraz vlastnosti hlavných štruktúr štruktúrovaného programovania: sledovanie, vetvenie a opakovanie.
Vlastnosti postupnosti sú vyjadrené nasledovne
Veta 9.3. Nech P, Q a R sú predikáty nad informačným prostredím a S1 a S2 sú zovšeobecnené operátory, ktoré majú vlastnosti
(P)S(Q) a (Q)S2(R).
Potom pre zložený operátor
S1; S2<.blockquote>
existuje nehnuteľnosť
(P) S1; S2(R).
Dôkaz. Nech je predikát P pravdivý pre nejaký stav informačného prostredia pred vykonaním operátora S1, potom na základe vlastnosti operátora S1 po jeho vykonaní bude pravdivý predikát Q vykonaním operátora S2. Následne po vykonaní operátora S2 na základe svojej vlastnosti bude predikát R pravdivý a keďže operátor S2 vykoná vykonanie zloženého príkazu (v súlade s jeho sémantikou), predikát R bude pravdivý po vykonanie tohto zloženého vyhlásenia, ktoré bolo potrebné preukázať.
Napríklad, ak platia vlastnosti (9.2) a (9.3), potom
miesto a majetok
(n
Vlastnosť vetvenia je vyjadrená nasledovne
Veta 9.4. Nech P, Q a R sú predikáty nad informačným prostredím a S1 a S2 sú zovšeobecnené operátory, ktoré majú vlastnosti
(P,Q)S1(R) a ("P,Q)S2(R).
Potom pre podmienený operátor
AK P TAK S1 ELSE S2 VŠETKO AK
existuje nehnuteľnosť
(Q) AK P THEN S1 ELSE S2 VŠETKY IF (R) .
Dôkaz. Pred vykonaním podmieneného operátora nech je pre nejaký stav informačného prostredia pravdivý predikát Q. Ak je pravdivý aj predikát P, potom sa vykonanie podmieneného operátora v súlade s jeho sémantikou redukuje na vykonanie operátora S1. . Na základe vlastnosti operátora S1 bude po jeho vykonaní (a v tomto prípade po vykonaní podmieneného operátora) pravdivý predikát R. Ak však pred vykonaním podmieneného operátora predikát P je nepravda (a Q je stále pravdivé), potom sa vykonanie podmieneného operátora v súlade s jeho sémantikou redukuje na vykonanie operátora S2. Na základe vlastnosti operátora S2 bude po jeho vykonaní (a v tomto prípade po vykonaní podmieneného operátora) pravdivý predikát R. Tým je veta úplne dokázaná.
Predtým, ako pristúpime k vlastnosti opakujúcej sa konštrukcie, treba poznamenať, že je užitočná pre ďalšie
Veta 9.5. Nech P, Q, P1 a Q1 sú predikáty nad informačným prostredím, pre ktoré to má dôsledky
P1=>P a Q=>Q1,
a nech platí vlastnosť (P)S(Q) pre operátor S. Potom platí vlastnosť (P1)S(Q1).
Táto veta sa tiež nazýva veta o vlastnostiach oslabenia.
Dôkaz. Nech je predikát P1 pravdivý pre nejaký stav informačného prostredia pred vykonaním operátora S. Potom bude pravdivý aj predikát P (kvôli implikácii P1=>P). V dôsledku vlastnosti operátora S bude po jeho vykonaní predikát Q pravdivý, a teda predikát Q1 (v dôsledku implikácie Q=>Q1). Tým je veta dokázaná.
Vlastnosť opakovania je vyjadrená nasledujúcim spôsobom
Veta 9.6. Nech I, P, Q a R sú predikáty nad informačným prostredím, pre ktoré to má dôsledky
P=>I a (I,`Q)=>R ,
a nech S je zovšeobecnený operátor s vlastnosťou (I)S(I).
Potom pre operátora slučky
BYE Q DO S ALL BYE
existuje nehnuteľnosť
(P) BYE Q DO S ALL BYE (R) .
Predikát I sa nazýva invariant operátora slučky.
Dôkaz. Na dokázanie tejto vety stačí dokázať vlastnosť
(I) BYE Q ROBÍM VŠETKO BYE (I,`Q)
(podľa vety 9.5 na základe dôsledkov v podmienkach tejto vety). Nech je predikát I pravdivý pre nejaký stav informačného prostredia pred vykonaním operátora cyklu Ak je v tomto prípade predikát Q nepravdivý, potom operátor cyklu bude ekvivalentný prázdnemu operátoru (v súlade s jeho sémantikou) a na základe vety 9.1 po vykonaní operátora cyklu príkaz (I ,`Q). Ak je predikát Q pravdivý pred vykonaním operátora slučky, potom operátor slučky v súlade s jeho sémantikou môže byť reprezentovaný ako zložený operátor S; BYE Q DO S ALL BYE
Na základe vlastnosti operátora S po jeho vykonaní bude predikát I pravdivý a nastáva východisková situácia na preukázanie vlastnosti operátora cyklu: predikát I je pravdivý pred vykonaním operátora cyklu, ale pre iný (zmenený) stav informačného prostredia (pre ktorý môže byť predikát Q pravdivý alebo nepravdivý). Ak sa vykonávanie príkazu cyklu skončí, potom aplikovaním metódy matematickej indukcie v konečnom počte krokov dospejeme k situácii, že príkaz (I,`Q) bude pred jeho vykonaním pravdivý. A v tomto prípade, ako bolo dokázané vyššie, bude toto tvrdenie pravdivé aj po vykonaní príkazu cyklu. Veta bola dokázaná.
Napríklad pre operátor slučky z príkladu (9.4) sa vykoná vlastnosť
m:= m+l; p:= p*m
ZATIAĽ VŠETKO (p= n.!}
Vyplýva to z vety 9.6, keďže invariantom tohto operátora slučky je predikát p=m! a implikácie (n>0, p=1, m=1) => p=m! a (p=m!, m=n) => p=n!
9.4. Ukončenie vykonávania programu.
Jednou z vlastností programu, ktorá nás môže zaujímať, aby sme sa vyhli prípadným chybám v PS, je jeho ukončenie, t.j. absencia cyklovania v ňom pre určité počiatočné údaje. V štruktúrovaných programoch, ktoré sme uvažovali, môže byť zdrojom zacyklenia iba opakovanie. Preto na preukázanie ukončenia programu stačí dokázať ukončenie slučkového operátora. Na to je užitočné nasledujúce.
Veta 9.7. Nech F je celočíselná funkcia, ktorá závisí od stavu informačného prostredia a spĺňa nasledujúce podmienky:
(1) ak pre daný stav informačného prostredia, predikát Q je pravdivý, potom je jeho hodnota kladná;
(2) znižuje sa pri zmene stavu informačného prostredia v dôsledku vykonania operátora S.
Potom sa vykoná príkaz cyklu
KÝM Q ROBÍ VŠETKO, kým sa dokončí.
Dôkaz. Nech je stav informačného prostredia pred vykonaním príkazu cyklu a nech F(je)=k. Ak je predikát Q(is) nepravdivý, vykonávanie príkazu cyklu sa skončí. Ak je Q(je) pravdivé, potom za predpokladu vety k>0. V tomto prípade sa príkaz S vykoná raz alebo viackrát. Po každom vykonaní operátora S podľa podmienky vety hodnota funkcie F klesá a keďže pred vykonaním operátora S musí byť predikát Q pravdivý (podľa sémantiky operátora cyklu) , hodnota funkcie F v tomto momente musí byť kladná (podľa podmienky vety). Preto vďaka integrite funkcie F môže byť operátor S v tomto cykle vykonaný viac ako k-krát. Veta bola dokázaná.
Napríklad pre príklad operátora cyklu uvažovaného vyššie sú podmienky vety 9.7 splnené funkciou f(n, m)= n-m. Keďže pred vykonaním príkazu cyklu m=1 sa telo tohto cyklu vykoná (n-1) krát, t.j. tento príkaz cyklu sa ukončí.
9.5. Príklad dôkazu vlastnosti programu.
Na základe overených pravidiel pre verifikáciu programu je možné preukázať vlastnosti programov pozostávajúcich z priraďovacích príkazov a prázdnych príkazov a pomocou troch základných zložení štruktúrovaného programovania. Na tento účel je potrebné pri analýze štruktúry programu a pri použití jeho predbežných a následných podmienok použiť v každom kroku analýzy vhodné overovacie pravidlo. V prípade zloženia opakovania bude potrebné zvoliť vhodný invariant cyklu.
Ako príklad dokážme vlastnosť (9.4). Tento dôkaz bude pozostávať z nasledujúcich krokov.
(Krok 1). n>0 => (n>0, p - ľubovoľné, m - ľubovoľné).
(Krok 2). Vyskytuje
(n>0, p - ľubovoľné, m - ľubovoľné) p:=1 (n>0, p=1, m - ľubovoľné).
Podľa vety 9.2.
(Krok 3). Vyskytuje
(n>0, p=1, m - ľubovoľné) m:=1 (n>0, p=1, m=1).
Podľa vety 9.2.
(Krok 4). Vyskytuje
(n>0, p - ľubovoľné, m - ľubovoľné) p:=1; m:=1 (n>0, p=1, m=1).
Podľa vety 9.3, kvôli výsledkom krokov 2 a 3.
Dokážme, že predikát p=m! je cyklus invariantný, t.j. (p = m m:=m+1; p:=p*m {p=m!}.!}
(Krok 5). Uskutoční sa (p=m m:=m+1 {p=(m-1)!}.!}
Podľa vety 9.2, ak zadáme predpoklad v tvare (p=((m+1)-1).!}
(Krok 6). Uskutoční sa (p=(m-1) p:=p*m {p=m!}.!}
Podľa vety 9.2, ak zadáme predpoklad v tvare (p*m=m.!}
(Krok 7). Existuje invariantný cyklus
(p = m m:=m+1; p:=p*m {p=m!}.!}
Podľa vety 9.3, kvôli výsledkom krokov 5 a 6.
(Krok 8). Vyskytuje
(n>0, p=1, m=1) KÝM m/= n DO
m:= m+l; p:= p*m
ZATIAĽ VŠETKO (p= n.!}
Podľa vety 9.6, na základe výsledku kroku 7 a majúc na pamäti, že (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(Krok 9). Vyskytuje
(n>0, p - ľubovoľné, m - ľubovoľné) p:=1; m:=1;
KEĎ m /= n DO
m:= m+l; p:= p*m
ZATIAĽ VŠETKO (p= n.!}
Podľa vety 9.3, kvôli výsledkom krokov 3 a 8.
(Krok 10). Vlastnosť (9.4) platí veta 9.5 kvôli výsledkom krokov 1 a 9.
Literatúra na prednášku 9.
9.1. S.A. Abramov. Prvky programovania. - M.: Nauka, 1982. S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Princípy vývoja softvéru. - M.: Mir, 1982. S. 98-105.
Prednáška 10
Základné pojmy. Stratégia návrhu testu. Ladiace príkazy. Offline ladenie a testovanie softvérového modulu. Komplexné ladenie a testovanie softvéru.
10.1. Základné pojmy.
Ladenie PS je činnosť zameraná na zisťovanie a opravu chýb v PS pomocou procesov vykonávania jeho programov. PS testovanie je proces vykonávania svojich programov na určitom súbore údajov, pre ktorý je vopred známy výsledok aplikácie alebo sú známe pravidlá správania sa týchto programov. Zadaný súbor údajov sa nazýva test alebo len test. Ladenie teda možno reprezentovať ako opakované opakovanie troch procesov: testovanie, v dôsledku ktorého je možné zistiť prítomnosť chyby v PS, hľadanie miesta chyby v programoch a dokumentácii PS a úpravy programov a dokumentácie za účelom odstránenia zistenej chyby. Inými slovami:
Ladenie = Testovanie + Hľadanie chýb + Úpravy.
V zahraničnej literatúre sa ladenie často chápe len ako proces hľadania a opravy chýb (bez testovania), ktorých prítomnosť sa zisťuje počas testovania. Niekedy sa testovanie a ladenie považujú za synonymá. U nás pod pojem ladenie väčšinou patrí testovanie, preto sa budeme držať zavedenej tradície. Spoločné zváženie týchto procesov v tejto prednáške však spôsobuje, že naznačený nesúlad nie je taký významný. Treba však poznamenať, že testovanie sa používa aj ako súčasť procesu certifikácie PS (pozri prednášku 14).
10.2. Princípy a typy ladenia.
Úspešnosť ladenia je do značnej miery určená racionálnou organizáciou testovania. Pri ladení sa zisťujú a odstraňujú najmä tie chyby, ktorých prítomnosť v PS sa zistí pri testovaní. Ako už bolo uvedené, testovanie nemôže preukázať správnosť PS, v najlepšom prípade môže preukázať prítomnosť chyby v ňom. Inými slovami, nie je možné zaručiť, že testovaním softvéru pomocou prakticky uskutočniteľného súboru testov je možné zistiť prítomnosť každej chyby prítomnej v softvéri. Preto vznikajú dva problémy. Najprv si pripravte takúto sadu testov a aplikujte na ne PS, aby ste v nej odhalili čo najviac chýb. Čím dlhšie však proces testovania (a ladenie vo všeobecnosti) pokračuje, tým sú náklady na softvér vyššie. Z toho vyplýva druhá úloha: určiť moment, kedy je ukončené ladenie PS (alebo jeho jednotlivých komponentov). Znakom možnosti ukončenia ladenia je úplnosť pokrytia testami prechádzajúcimi cez PS (t. j. testami, na ktoré sa PS aplikuje) mnohých rôznych situácií, ktoré vznikajú pri vykonávaní programov PS, resp. pomerne zriedkavý prejav chýb v PS v poslednom segmente testovacieho procesu. Ten sa určuje v súlade s požadovaným stupňom spoľahlivosti PS, špecifikovaným v špecifikácii jeho kvality.
Na optimalizáciu testovacej súpravy, t.j. pripraviť taký súbor testov, ktorý by pri danom počte testov (alebo pri danom časovom intervale na testovanie) umožnil odhaliť viac chyby, je potrebné po prvé túto množinu vopred naplánovať a po druhé použiť racionálnu stratégiu plánovania (navrhovania) testov. Návrh testu môže začať ihneď po ukončení etapy externého popisu PS. Existujú rôzne prístupy k vývoju stratégie návrhu testov, ktoré môžu byť podmienene graficky umiestnené (pozri obrázok 9.1) medzi nasledujúce dva extrémne prístupy. Ľavý extrémny prístup spočíva v tom, že testy sú navrhnuté len na základe preštudovania špecifikácií PS (externý popis, popis architektúry a špecifikácia modulu). Nie je nijako zohľadnená štruktúra modulov, t.j. zaobchádza sa s nimi ako s čiernymi skrinkami. V skutočnosti si tento prístup vyžaduje úplné vymenovanie všetkých súborov vstupných údajov, pretože pri použití iba časti týchto súborov ako testov nemusia niektoré časti programov PS fungovať na žiadnom teste, a preto chyby v nich obsiahnuté nebudú fungovať. objaviť. Testovanie PS s úplným súborom vstupných dát je však prakticky nemožné. Správny extrémny prístup je, že testy sú navrhnuté na základe štúdia textov programov, aby sa otestovali všetky spôsoby, akými sa každý program PS vykonáva. Ak vezmeme do úvahy prítomnosť cyklov s premenlivým počtom opakovaní v programoch, potom môže existovať aj extrémne veľké množstvo rôznych spôsobov vykonávania PS programov, takže ich testovanie bude tiež prakticky nemožné.
Optimálna stratégia návrhu testu sa nachádza v intervale medzi týmito extrémnymi prístupmi, ale bližšie k ľavej strane. Zahŕňa navrhnutie významnej časti testov podľa špecifikácií na základe princípov: pre každú použitú funkciu alebo vlastnosť - aspoň jeden test, pre každú oblasť a pre každú hranicu zmeny akejkoľvek vstupnej premennej - aspoň jeden test, pre každú špeciálny prípad alebo pre každú výnimku špecifikovanú v špecifikáciách - aspoň jeden test. Vyžaduje si to však aj návrh niektorých testov a textov programov na princípe (minimálne): každý príkaz každého programu PS musí fungovať aspoň na jednom teste.
Optimálna stratégia návrhu testu môže byť špecifikovaná na základe nasledujúceho princípu: pre každý programový dokument (vrátane programové texty), ktorý je súčasťou PS, by si mali navrhnúť vlastné testy s cieľom identifikovať chyby v ňom. V každom prípade je potrebné túto zásadu dodržať v súlade s definíciou softvéru a obsahom pojmu programovacia technika ako technológia na vývoj spoľahlivého softvéru (pozri prednášku 1). V tomto smere Myers dokonca definuje odlišné typy testovanie v závislosti od typu programového dokumentu, na základe ktorého sú testy postavené. V našej krajine existujú dva hlavné typy ladenia (vrátane testovania): samostatné a komplexné ladenie. Offline ladenie znamená testovanie len niektorej časti programu obsiahnutej v PS, pričom pri testovaní je zaznamenané vyhľadávanie a oprava chýb. V skutočnosti zahŕňa ladenie každého modulu a párovanie modulov ladenia. Komplexné ladenie znamená testovanie PS ako celku s vyhľadávaním a opravou chýb zaznamenaných pri testovaní vo všetkých dokumentoch (vrátane textov programov PS) týkajúcich sa PS ako celku. Medzi takéto dokumenty patrí definícia požiadaviek na PS, špecifikácia kvality PS, funkčná špecifikácia PS, popis architektúry PS a texty programov PS.
10.3. Ladiace príkazy.
Táto časť poskytuje všeobecné pokyny na organizáciu ladenia. Najprv si však treba uvedomiť fenomén, ktorý potvrdzuje dôležitosť predchádzania chybám v predchádzajúcich fázach vývoja: s narastajúcim počtom zistených a opravených chýb v softvéri sa zvyšuje aj relatívna pravdepodobnosť existencie nezistených chýb v ňom. Vysvetľuje to skutočnosť, že s nárastom počtu chýb zistených v PS sa spresňuje aj naše chápanie celkového počtu chýb, ktoré sa v ňom vyskytli, a teda do určitej miery aj počtu chýb, ktoré ešte neboli zistené. Tento jav potvrdzuje dôležitosť včasnej detekcie chýb a potrebu starostlivej kontroly rozhodnutí v každej fáze vývoja softvéru.
Prikázanie 1. Považujte testovanie za kľúčovú úlohu vývoja softvéru, zverte ho tým najkvalifikovanejším a najnadanejším programátorom; je nežiaduce testovať vlastný program.
Prikázanie 2. Dobrý test je taký, ktorý má vysokú pravdepodobnosť nájdenia chyby, nie taký, ktorý demonštruje správnu činnosť programu.
Prikázanie 3. Pripravte testy na správne aj nesprávne údaje.
Prikázanie 4. Vyhýbať sa nereprodukovateľným testom, dokumentovať ich prechod cez počítač; podrobne si preštudujte výsledky každého testu.
Prikázanie 5. Pripojte každý modul k programu iba raz; nikdy neupravujte program, aby sa uľahčilo testovanie.
Prikázanie 6. Znova preskočte všetky testy súvisiace s kontrolou činnosti akéhokoľvek programu PS alebo jeho interakcie s inými programami, ak v ňom boli vykonané zmeny (napríklad v dôsledku opravy chyby).
10.4. Offline ladenie modulu.
Pri offline ladení je každý modul skutočne testovaný v nejakom programovacom prostredí, pokiaľ ladený program pozostáva len z jedného modulu. Toto prostredie pozostáva z ďalších modulov, z ktorých niektoré sú moduly ladeného programu, ktoré sú už odladené, a niektoré sú moduly, ktoré riadia ladenie (moduly ladenia, pozri nižšie). Počas offline ladenia sa teda vždy testuje nejaký program, vytvorený špeciálne na testovanie ladeného modulu. Tento program sa len čiastočne zhoduje s ladeným programom, okrem prípadu, keď sa ladí posledný modul ladeného programu. Ako bude prebiehať ladenie programu, stále väčšia časť prostredia ďalšieho ladeného modulu budú už ladené moduly tohto programu a pri ladení posledného modulu tohto programu bude prostredie ladeného modulu pozostávať výlučne z všetky ostatné (už ladené) moduly ladeného programu (bez akýchkoľvek) ladiacich modulov moduly, t.j. v tomto prípade bude testovaný samotný ladený program. Tento proces vytvárania ladeného programu s ladenými a ladenými modulmi sa nazýva integrácia programu.
Ladiace moduly zahrnuté v prostredí ladeného modulu závisia od poradia, v ktorom sú moduly daného programu ladené, ktorý modul sa ladí a prípadne ktorý test bude preskočený.
Pri testovaní zdola nahor (pozri kapitolu 7) bude toto prostredie obsahovať vždy iba jeden ladiaci modul (okrem prípadu, keď sa ladí posledný modul ladeného programu), ktorý bude hlavou testovaného programu a ktorý sa nazýva majster (alebo vodič). Vedúci ladiaci modul pripraví informačné prostredie na testovanie ladeného modulu (t.j. vytvorí jeho stav potrebný na testovanie tohto modulu, najmä môže zadávať testovacie dáta), zavolá ladený modul a po jeho práci dokončené, vydá potrebné správy. Pri ladení jedného modulu je možné skompilovať rôzne hlavné ladiace moduly pre rôzne testy.
Pri zostupnom testovaní (pozri kapitolu 7) obsahuje prostredie ladeného modulu ako ladiace moduly simulátory všetkých modulov, ku ktorým má ladený modul prístup, ako aj simulátory tých modulov, ku ktorým má prístup ladený modul. moduly ladeného programu (zahrnuté v tomto prostredí), ktoré však ešte neboli odladené. Niektoré z týchto simulátorov sa môžu zmeniť pre rôzne testy pri ladení jedného modulu.
V skutočnosti môže prostredie ladeného modulu v mnohých prípadoch obsahovať oba typy ladiacich modulov z nasledujúcich dôvodov. Testovanie smerom nahor aj nadol má svoje výhody a nevýhody.
Medzi výhody testovania zdola nahor patrí
jednoduchosť prípravy testov a
schopnosť plne implementovať plán testovania modulu.
Je to spôsobené tým, že testovací stav informačného prostredia sa pripravuje bezprostredne pred volaním do ladeného modulu (vedúci ladiaci modul). Nevýhody testovania zdola nahor sú nasledujúce vlastnosti:
testovacie údaje sa spravidla nepripravujú vo forme, ktorá je navrhnutá pre používateľa (okrem prípadu, keď sa ladí posledný, hlavný modul ladeného programu);
veľké množstvo ladiaceho programovania (pri ladení jedného modulu často musíte zostaviť veľa popredných ladiacich modulov pre rôzne testy);
potreba špeciálneho testovania modulov rozhrania.
Medzi výhody testovania zhora nadol patria nasledujúce funkcie:
väčšina testov je pripravená vo forme určenej pre používateľa;
v mnohých prípadoch relatívne malé množstvo ladiaceho programovania (modulové simulátory sú spravidla veľmi jednoduché a každý je vhodný pre veľké množstvo, často pre všetky testy);
nie je potrebné testovať párovanie modulov.
Nevýhodou testovania zhora nadol je, že testovací stav informačného prostredia pred prístupom k ladenému modulu sa pripravuje nepriamo – je výsledkom aplikácie už odladených modulov na testovacie dáta alebo dáta vydávané simulátormi. To po prvé sťažuje prípravu testov, vyžaduje vysokokvalifikovaného vykonávateľa testov a po druhé sťažuje alebo dokonca znemožňuje implementáciu kompletného plánu testovania pre ladený modul. Tento nedostatok niekedy núti vývojárov používať testovanie zdola nahor aj v prípade vývoja zhora nadol. Častejšie sa však používa nejaká modifikácia testovania zhora nadol, alebo nejaká kombinácia testovania zhora nadol a zdola nahor.
Na základe skutočnosti, že testovanie zhora nadol je v zásade vhodnejšie, zastavme sa pri technikách, ktoré nám umožňujú tieto ťažkosti do určitej miery prekonať. V prvom rade je potrebné zorganizovať ladenie programu tak, aby sa čo najskôr odladili moduly, ktoré vykonávajú zadávanie dát – následne je možné testovacie dáta pripraviť vo forme určenej pre užívateľa, čo značne zjednodušiť prípravu následných testov. Tento vstup nie je v žiadnom prípade vždy vykonávaný v module head, takže najprv musíte odladiť reťazce modulov vedúce k modulom, ktoré vykonávajú špecifikovaný vstup (porovnaj s metódou účelovej konštruktívnej implementácie v 7. prednáške). Kým nie sú vstupné moduly odladené, testovacie údaje dodávajú niektoré simulátory: buď sú zahrnuté v simulátore ako jeho súčasť, alebo sú zadávané týmto simulátorom.
Pri testovaní zhora nadol sa niektoré stavy informačného prostredia, pri ktorých je potrebné testovať ladený modul, nemusia vyskytnúť počas vykonávania ladeného programu pre žiadny vstup. V týchto prípadoch by bolo možné ladený modul vôbec netestovať, pretože zistené chyby sa v tomto prípade neprejavia pri spustení ladeného programu pod akýmikoľvek vstupnými údajmi. Neodporúča sa to však robiť, pretože pri zmene ladeného programu (napríklad pri údržbe PS) už môžu nastať stavy informačného prostredia, ktoré neboli použité na testovanie ladeného modulu, čo si vyžaduje dodatočné testovanie tohto modulu (a to by sa pri racionálnej organizácii ladenia nedalo vykonať, ak sa samotný modul nezmenil). Na otestovanie ladeného modulu v týchto situáciách sa niekedy používajú vhodné simulátory na vytvorenie požadovaného stavu informačného prostredia. Častejšie sa používa modifikovaná verzia testovania zhora nadol, pri ktorej sa ladené moduly pred integráciou predtestujú samostatne (v tomto prípade sa v prostredí ladeného modulu objaví hlavný ladiaci modul spolu s modulom simulátory, ku ktorým má ladený modul prístup). Ako vhodnejšia sa však javí iná modifikácia testovania zhora nadol: po dokončení testovania zhora nadol ladeného modulu na dosiahnuteľné testovacie stavy informačného prostredia by sa mal samostatne otestovať zostávajúce požadované stavy informácií. životné prostredie.
Často sa používa aj kombinácia testovania zdola nahor a zdola nahor, ktorá sa nazýva sendvičová metóda. Podstata tejto metódy spočíva v súčasnej implementácii vzostupného aj zostupného testovania, kým sa tieto dva testovacie procesy nestretnú na nejakom module niekde v strede štruktúry ladeného programu. Táto metóda umožňuje pri rozumnom prístupe využiť výhody testovania zdola nahor aj zhora nadol a do značnej miery neutralizovať ich nedostatky. Tento efekt je prejavom všeobecný princíp: najväčší technologický efekt možno dosiahnuť kombináciou metód vývoja OS programov zhora nadol a zdola nahor. Architektonický prístup k vývoju softvéru je určený práve na podporu tejto metódy (pozri 7. prednášku): vrstva dobre navrhnutých a starostlivo otestovaných modulov výrazne uľahčuje implementáciu rodiny programov v príslušnej tematickej oblasti a ich následnú modernizáciu.
Veľmi dôležité pri offline ladení je testovanie párovania modulov. Faktom je, že špecifikácia každého programového modulu, okrem hlavného, sa v tomto programe používa v dvoch situáciách: po prvé pri vývoji textu (niekedy sa hovorí: telo) tohto modulu a po druhé pri písaní textu. apelovať na tento modul v iných programových moduloch. V oboch prípadoch môže byť v dôsledku chyby porušená požadovaná zhoda s danou špecifikáciou modulu. Takéto chyby je potrebné odhaliť a opraviť. Toto je účelom testovania párovania modulov. Pri testovaní zhora nadol sa testovanie párovania vykonáva počas každého vynechaného testu, čo sa považuje za najsilnejšiu výhodu testovania zhora nadol. Počas testovania zdola nahor sa k ladenému modulu nepristupuje z modulov ladeného programu, ale z hlavného ladiaceho modulu. V tomto smere existuje nebezpečenstvo, že posledný modul sa môže prispôsobiť niektorým „chybným predstavám“ o ladiacom module. Preto pri spustení (v procese integrácie programu) ladenia nového modulu je potrebné otestovať každé volanie predtým ladeného modulu, aby sa odhalili nezrovnalosti medzi týmto volaním a telom príslušného modulu (a je možné, že za to môže predtým odladený modul). Preto je potrebné čiastočne zopakovať testovanie predtým odladeného modulu v nových podmienkach a vznikajú rovnaké ťažkosti ako v prípade testovania zhora nadol.
Autonómne testovanie modulu by malo prebiehať v štyroch po sebe nasledujúcich krokoch.
Krok 1: Na základe špecifikácie modulu, ktorý ladíte, pripravte test pre každú možnosť a situáciu, pre každú hranicu rozsahov všetkých vstupov, pre každý rozsah zmien údajov, pre každý neplatný rozsah všetkých vstupov a každý neplatný stav.
Krok 2. Skontrolujte text modulu, aby ste sa uistili, že každý smer ktorejkoľvek vetvy prejde aspoň jedným testom. Pridajte chýbajúce testy.
Krok 3. Overte si z textu modulu, že pre každú slučku existuje test, pri ktorom sa telo slučky nevykoná, test, pri ktorom sa telo slučky vykoná raz, a test, pri ktorom sa telo slučky vykoná maximálny počet krát. Pridajte chýbajúce testy.
Krok 4. Skontrolujte citlivosť textu modulu na jednotlivé špeciálne hodnoty vstupných údajov - všetky takéto hodnoty by mali byť zahrnuté v testoch. Pridajte chýbajúce testy.
10.5. Komplexné ladenie softvéru.
Ako už bolo spomenuté vyššie, pri komplexnom ladení sa testuje PS ako celok a testy sa pripravujú pre každý z dokumentov PS. Testovanie týchto dokumentov sa zvyčajne vykonáva v opačnom poradí ako pri ich vývoji (výnimkou je len testovanie aplikačnej dokumentácie, ktorá sa vyvíja podľa externého popisu súbežne s vývojom programových textov; toto testovanie je najlepšie vykonať po testovaní vonkajší popis je dokončený). Testovanie v rámci komplexného ladenia je aplikácia PS na konkrétne dáta, ktoré v zásade môžu pochádzať od užívateľa (najmä všetky testy sú pripravované vo forme určenej pre užívateľa), ale prípadne v simulovanom (a nie reálnom) životné prostredie. Napríklad niektoré vstupné a výstupné zariadenia, ktoré sú počas zložitého ladenia nedostupné, môžu byť nahradené ich softvérovými simulátormi.
Testovanie architektúry PS. Účelom testovania je nájsť nesúlad medzi popisom architektúry a súborom programov PS. V čase, keď sa začne testovanie architektúry PS, by už malo byť dokončené autonómne ladenie každého subsystému. Chyby implementácie architektúry môžu súvisieť predovšetkým s interakciou týchto subsystémov, najmä s implementáciou architektonických funkcií (ak existujú). Preto by som rád preveril všetky spôsoby interakcie medzi subsystémami PS. Ale keďže ich môže byť príliš veľa, bolo by žiaduce otestovať aspoň všetky vykonávacie reťazce podsystémov bez toho, aby ste ich znova zadali. Ak daná architektúra predstavuje PS ako malý systém vybraných subsystémov, tak počet takýchto reťazcov bude dosť viditeľný.
Testovanie vonkajšie funkcie. Účelom testovania je nájsť nezrovnalosti medzi funkčnou špecifikáciou a súborom softvérových programov PS. Napriek tomu, že všetky tieto programy už boli nezávisle odladené, tieto nezrovnalosti môžu byť spôsobené napríklad nesúladom medzi internými špecifikáciami programov a ich modulov (na základe ktorých bolo vykonané autonómne testovanie) a externou funkčnou špecifikáciou. z čs. Testovanie externých funkcií prebieha spravidla rovnako ako testovanie modulov v prvom kroku, t.j. ako čierna skrinka.
Testovanie PS kvality. Účelom testovania je vyhľadávanie porušení kvalitatívnych požiadaviek formulovaných v špecifikácii kvality PS. Toto je najťažší a najmenej skúmaný typ testovania. Je len jasné, že nie každé primitívum kvality PS sa dá otestovať testovaním (pozri nasledujúcu prednášku o hodnotení kvality PS). Úplnosť PS sa kontroluje už pri testovaní externých funkcií. V tejto fáze možno pokračovať v testovaní tohto kvalitatívneho primitíva, ak je to potrebné na získanie akéhokoľvek pravdepodobnostného odhadu stupňa spoľahlivosti PS. Metodiku takéhoto testovania je však ešte potrebné vypracovať. Testovať sa dá presnosť, robustnosť, bezpečnosť, časová efektivita, do určitej miery efektivita pamäte, efektivita zariadenia, rozšíriteľnosť a čiastočne aj nezávislosť na zariadení. Každý z týchto typov testovania má svoje špecifiká a zaslúži si samostatnú úvahu. Tu sa obmedzíme na ich vymenovanie. Pri testovaní dokumentácie o používaní PS sa hodnotí jednoduchosť použitia PS (kritérium kvality, ktoré zahŕňa niekoľko kvalitatívnych primitív, pozri prednášku 4).
Skúšobná dokumentácia o aplikácii PS. Účelom testovania je hľadanie nezrovnalostí medzi dokumentáciou k aplikácii a súborom softvérových programov, ako aj nepríjemnosti pri používaní softvéru. Táto fáza bezprostredne predchádza pripojeniu používateľa k dokončeniu vývoja PS (testovanie požiadaviek na PS a certifikácia PS), preto je veľmi dôležité, aby vývojári najprv použili PS sami tak, ako to bude robiť používateľ. to. Všetky skúšky v tomto štádiu sú pripravované výlučne na základe dokumentácie o aplikácii PS. V prvom rade treba otestovať schopnosti softvéru tak, ako to bolo pri testovaní externých funkcií, ale len na základe aplikačnej dokumentácie. Mali by sa otestovať všetky nejasné miesta v dokumentácii, ako aj všetky príklady použité v dokumentácii. Ďalej sa testujú najťažšie prípady aplikácie PS, aby sa zistilo porušenie požiadaviek na relatívnosť jednoduchosti použitia PS.
Testovanie definície požiadaviek na PS. Účelom testovania je zistiť, do akej miery softvér nezodpovedá prezentovanej definícii požiadaviek naň. Zvláštnosťou tohto typu testovania je, že ho vykonáva nákupná organizácia alebo užívateľská organizácia PS ako jeden zo spôsobov, ako prekonať bariéru medzi vývojárom a používateľom (pozri prednášku 3). Zvyčajne sa toto testovanie vykonáva pomocou kontrolných úloh – typických úloh, pri ktorých je známy výsledok riešenia. V prípadoch, keď by vyvinutý PS mal nahradiť inú verziu PS, ktorá rieši aspoň časť úloh vyvinutého PS, testovanie sa vykonáva riešením bežných problémov pomocou starého aj nového PS, po ktorom nasleduje porovnanie výsledkov. získané. Niekedy sa ako forma takéhoto testovania využíva skúšobná prevádzka PS - obmedzená aplikácia nového PS s rozborom využitia výsledkov v praxi. Tento typ testovania má v podstate veľa spoločného s testovaním PS počas jeho certifikácie (pozri prednášku 14), ale vykonáva sa pred certifikáciou a niekedy aj namiesto certifikácie.
Literatúra na prednášku 10.
10.1. G. Myers. Spoľahlivosť softvéru. - M.: Mir, 1980. - S. 171-262.
10.2. D. Van Tassel. Štýl, vývoj, efektívnosť, ladenie a testovanie programov. - M.: Mir, 1985. - S. 179-295.
10.3. J. Hughes, J. Michtom. Štrukturálny prístup k programovaniu. - M.: Mir, 1980. - S. 254-268.
10.4. J. Fox. Softvér a jeho vývoj. - M.: Mir, 1985. - S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. Princípy vývoja softvéru. - M.: Mir, 1982. - S. 105-116.
10.6. Yu.M. Bezborodov. Individuálne ladenie programov. - M.: Nauka, 1982. - S. 9-79.
10.7. V.V. Lipajev. Testovanie programu. - M.: Rádio a komunikácia, 1986. - S. 15-47.
10.8. E.A. Zhogolev. Úvod do technológie programovania (poznámky z prednášky). - M.: "DIALOGUE-MGU", 1994.
10.9. E. Dijkstra. Poznámky k štruktúrovanému programovaniu. //U. Dahl, E. Dijkstra, K. Hoor. Štrukturálne programovanie. - M.: Mir, 1975. - S. 7-13.
Prednáška 11
11.1. Funkčnosť a spoľahlivosť ako povinné kritériá kvality softvéru.
V predchádzajúcich prednáškach sme uvažovali o všetkých fázach vývoja PS okrem jeho certifikácie. Zároveň sme sa nedotkli problematiky zabezpečenia kvality PS v súlade s jej špecifikáciou kvality (pozri prednášku 4). Je pravda, že pri implementácii funkčnej špecifikácie PS sme diskutovali o hlavných otázkach zabezpečenia kritéria funkčnosti. Po deklarovaní spoľahlivosti softvéru ako jeho hlavného atribútu (pozri prednášku 1) sme zvolili prevenciu chýb ako hlavný prístup na zabezpečenie spoľahlivosti softvéru (pozri prednášku 3) a diskutovali sme o jej implementácii v rôznych fázach vývoja softvéru. Tým sa prejavila téza o povinnej funkčnosti a spoľahlivosti PS ako kritéria jeho kvality.
Špecifikácia kvality softvéru však môže obsahovať dodatočné charakteristiky týchto kritérií, ktorých poskytnutie si vyžaduje osobitnú diskusiu. Na tieto otázky sa zameriava táto prednáška. Zabezpečenie ďalších kritérií kvality bude diskutované v nasledujúcej prednáške.
Poskytovanie primitív kvality MS, ktoré vyjadrujú kritériá funkčnosti a spoľahlivosti MS, je diskutované nižšie.
11.2. Zabezpečenie úplnosti softvéru.
Úplnosť PS je všeobecným primitívom kvality PS na vyjadrenie funkčnosti aj spoľahlivosti PS a pre funkčnosť je jediným primitívom (pozri prednášku 4).
Funkčnosť PS je určená jeho funkčnou špecifikáciou. Úplnosť PS ako primitíva jeho kvality je mierou toho, ako je táto špecifikácia implementovaná v danom PS. Poskytnúť toto primitívum v plnom rozsahu znamená implementovať každú z funkcií definovaných vo funkčnej špecifikácii so všetkými podrobnosťami a vlastnosťami, ktoré sú tam uvedené. Všetky predtým diskutované technologické procesy ukazujú, ako sa to dá urobiť.
V špecifikácii kvality PS je však možné definovať niekoľko úrovní implementácie funkcionality PS: možno definovať nejakú zjednodušenú (počiatočnú alebo štartovaciu) verziu, ktorá musí byť implementovaná ako prvá, a možno definovať aj niekoľko medziverzií. V tomto prípade vzniká ďalší technologický problém: organizácia zvyšovania funkčnosti PS. Tu je dôležité poznamenať, že vývoj zjednodušenej verzie PS nie je vývojom jeho prototypu. Prototyp sa vyvíja za účelom lepšieho pochopenia podmienok používania budúceho PS, objasnenia jeho vonkajšieho popisu. Je určený pre vybraných používateľov a preto sa môže od požadovaného PS značne líšiť nielen vykonávanými funkciami, ale aj vlastnosťami používateľského rozhrania. Zjednodušená verzia požadovaného PS by mala byť navrhnutá pre praktické použitie každým používateľom, pre ktorého je určená. Hlavnou zásadou zabezpečenia funkčnosti takéhoto OS je preto vyvíjať OS od samého začiatku tak, ako keby bol potrebný celý OS, kým sa vývojári nezaoberajú tými časťami alebo detailmi OS, implementácia ktorý môže byť odložený podľa jeho kvalitatívnej špecifikácie. Preto musí byť plne vypracovaný vonkajší popis aj popis architektúry PS. Odložiť je možné len implementáciu tých softvérových subsystémov definovaných v architektúre vyvíjaného PS, ktorých fungovanie nie je v počiatočnej verzii tohto PS potrebné. Implementáciu samotných softvérových subsystémov je najlepšie vykonať metódou účelovej konštruktívnej implementácie, pričom v počiatočnej verzii PS ponecháme vhodné simulátory tých softvérových modulov, ktoré v tejto verzii nie sú potrebné. Prijateľná je aj zjednodušená implementácia niektorých softvérových modulov, pričom sa vynechajú niektoré detaily príslušných funkcií. Z technologického hľadiska je však lepšie považovať takéto moduly za ich pôvodných imitátorov (hoci ďaleko pokročilých).
Vzhľadom na chyby vo vyvíjanom PS nemusí byť dosiahnutá úplnosť pri zabezpečení jeho funkčnosti (v súlade so špecifikáciou jeho kvality) skutočne taká, ako sa očakávalo. Môžeme len povedať, že táto úplnosť bola dosiahnutá s určitou pravdepodobnosťou, danou objemom a kvalitou testovania. Aby sa táto pravdepodobnosť zvýšila, je potrebné pokračovať v testovaní a ladení PS. Odhad takejto pravdepodobnosti je však veľmi špecifická úloha (berúc do úvahy skutočnosť, že prejav chyby v PS je funkciou počiatočných údajov), ktorá ešte len čaká na príslušné teoretické štúdie.
11.3. Zabezpečenie presnosti softvérového nástroja.
Poskytnutie tohto primitíva je spojené s operáciami s hodnotami skutočných typov (presnejšie s hodnotami reprezentovanými s určitou chybou). Zabezpečiť požadovanú presnosť pri výpočte hodnoty konkrétnej funkcie znamená získať túto hodnotu s chybou, ktorá nepresahuje stanovené limity. Druhmi chýb, metódami ich odhadu a metódami na dosiahnutie požadovanej presnosti (tzv. približné výpočty) sa zaoberá výpočtová matematika. Tu venujeme pozornosť len určitej štruktúre chyby: závisí chyba vypočítanej hodnoty (celková chyba).
o chybe použitej metódy výpočtu (do ktorej započítavame aj nepresnosť použitého modelu),
z chyby v prezentácii použitých údajov (z tzv. fatálnej chyby),
od chyby zaokrúhľovania (nepresnosť vo vykonávaní operácií použitých v metóde).
11.4. Zabezpečenie autonómie softvéru.
Toto kvalitatívne primitívum sa poskytuje v štádiu špecifikácie kvality prijatím rozhodnutia, či použiť akýkoľvek vhodný základný softvér vo vyvinutom PS alebo v ňom nepoužiť žiadny základný softvér. Zároveň je potrebné brať do úvahy ako jeho spoľahlivosť, tak aj zdroje potrebné na jeho použitie. Pri zvýšených požiadavkách na spoľahlivosť vyvíjaného PS sa môže ukázať, že spoľahlivosť základného softvéru, ktorý majú vývojári k dispozícii, je neuspokojivá, preto sa od jeho používania musí upustiť a implementácia jeho funkcií v požadovanom objeme musí byť zahrnutá do PS. Podobné rozhodnutia sa musia prijímať za prísnych obmedzení použitých zdrojov (podľa kritéria účinnosti PS).
11.5. Zabezpečenie udržateľnosti softvéru.
Toto kvalitné primitívum je zabezpečené pomocou takzvaného obranného programovania. Všeobecne povedané, defenzívne programovanie sa používa na zlepšenie spoľahlivosti MS pri programovaní modulu v širšom zmysle. Ako uvádza Myers, "Defenzívne programovanie je založené na dôležitom predpoklade: Najhoršia vec, ktorú môže modul urobiť, je prijať zlý vstup a potom vrátiť nesprávny, ale hodnoverný výsledok." Aby sa tomu predišlo, text modulu obsahuje kontroly správnosti jeho vstupných a výstupných údajov v súlade so špecifikáciou tohto modulu, najmä plnenie obmedzení na vstupné a výstupné údaje a vzťahy medzi nimi. je potrebné skontrolovať v špecifikácii modulu. V prípade negatívneho výsledku kontroly sa vyvolá príslušná výnimka. V tejto súvislosti sú na konci tohto modulu zaradené fragmenty druhého druhu - spracovatelia zodpovedajúcich výnimočných situácií, ktorí okrem vydávania potrebných diagnostických informácií môžu prijať opatrenia buď na odstránenie chýb v údajoch (napr. vyžadovať ich opätovné zadanie) alebo zmierniť dopad chyby (napríklad mäkké zastavenie zariadení ovládaných PS, aby sa predišlo ich poruche v prípade núdzového ukončenia vykonávania programu).
Použitie ochranného programovania modulov vedie k zníženiu účinnosti PS v čase aj v pamäti. Preto je potrebné rozumne regulovať mieru uplatnenia defenzívneho programovania v závislosti od požiadaviek na spoľahlivosť a účinnosť PS, formulovaných v kvalitatívnej špecifikácii vyvíjaného PS. Vstupné dáta vyvinutého modulu môžu pochádzať buď priamo od užívateľa alebo z iných modulov. Najčastejším prípadom použitia defenzívneho programovania je jeho použitie pre prvú skupinu dát, čo znamená realizáciu stability PS. Toto by sa malo vykonať vždy, keď špecifikácia kvality PS obsahuje požiadavku na zabezpečenie stability PS. Použitie defenzívneho programovania pre druhú skupinu vstupných údajov znamená pokus o zistenie chyby v iných moduloch počas vykonávania vyvíjaného modulu a pre výstupné údaje vyvíjaného modulu pokus o zistenie chyby v samotnom module. počas jeho vykonávania. V podstate to znamená čiastočnú implementáciu prístupu samodetekcie chýb na zabezpečenie spoľahlivosti softvéru, o ktorej sa hovorilo v prednáške 3. Tento prípad defenzívneho programovania sa používa extrémne zriedkavo – iba vtedy, keď sú splnené požiadavky na spoľahlivosť softvéru sú extrémne vysoké.
11.6. Zabezpečenie bezpečnosti softvéru.
Existujú nasledujúce typy ochrany PS pred skreslením informácií:
ochrana pred poruchami hardvéru;
ochrana pred vplyvom „cudzieho“ programu;
ochrana pred poruchami "vlastného" programu;
ochrana pred chybami operátora (používateľa);
ochrana pred neoprávneným prístupom;
ochrana pred ochranou.
Ochrana pred zlyhaním hardvéru nie je v súčasnosti príliš urgentnou úlohou (s ohľadom na dosiahnutú úroveň spoľahlivosti počítača). Ale stále je užitočné poznať jej riešenie. Toto je zabezpečené organizáciou takzvaných „double-triple miscalculations“. Za týmto účelom je celý proces spracovania údajov, ktorý určuje PS, časovo rozdelený do intervalov podľa takzvaných „referenčných bodov“. Dĺžka tohto intervalu by nemala presiahnuť polovicu priemernej doby prevádzky počítača. Kópia stavu pamäte zmeneného v tomto procese pre každý referenčný bod sa zapíše do sekundárnej pamäte s určitým kontrolným súčtom (číslo vypočítané ako funkcia tohto stavu) v prípade, keď sa bude uvažovať, že spracovanie údajov z predchádzajúci referenčný bod k tomuto (t. j. jeden „chybný výpočet“) je urobený správne (bez zlyhania počítača). Aby sa to zistilo, urobia sa dva takéto „chybné výpočty“. Po prvom "výpočte" sa vypočíta a uloží zadaný kontrolný súčet a potom sa obnoví stav pamäte pre predchádzajúci referenčný bod a vykoná sa druhý "výpočet". Po druhom „chybnom výpočte“ sa znova vypočíta zadaný kontrolný súčet, ktorý sa potom porovná s kontrolným súčtom prvého „chybného výpočtu“. Ak sa tieto dva kontrolné súčty zhodujú, druhý výpočet sa považuje za správny, inak sa uloží aj kontrolný súčet druhého „výpočtu“ a vykoná sa tretí „výpočet“ (s predbežným obnovením stavu pamäte pre predchádzajúci referenčný bod). Ak sa kontrolný súčet tretieho „nesprávneho výpočtu“ zhoduje s kontrolným súčtom jedného z prvých dvoch „nesprávnych výpočtov“, potom sa tretí nesprávny výpočet považuje za správny, inak je potrebná technická kontrola počítača.
Ochrana pred vplyvom „cudzieho“ programu sa týka predovšetkým operačných systémov alebo programov, ktoré čiastočne vykonávajú svoje funkcie. Existujú dva typy tejto ochrany:
ochrana pri poruche,
ochranu pred škodlivým vplyvom „cudzieho“ programu.
Keď sa objaví multiprogramový režim činnosti počítača, v jeho pamäti môže súčasne bežať niekoľko programov, ktoré striedavo dostávajú riadenie v dôsledku prerušenia (tzv. kváziparalelné vykonávanie programov). Jeden z týchto programov (zvyčajne: operačný systém) spracováva prerušenia a riadi multiprogramovanie. V každom z týchto programov sa môžu vyskytnúť zlyhania (zobrazia sa chyby), ktoré môžu ovplyvniť výkon funkcií inými programami. Preto musí riadiaci program (operačný systém) chrániť seba a ostatné programy pred takýmto vplyvom. Na tento účel musí hardvér počítača implementovať nasledujúce funkcie:
ochrana pamäte,
dva režimy prevádzky počítača: privilegovaný a pracovný (používateľský),
dva typy transakcií: privilegované a bežné,
správna implementácia prerušení a počiatočné spustenie počítača,
dočasné prerušenie.
Ochrana pamäte znamená možnosť programovo nastaviť pre každý program oblasti pamäte, ktoré sú preň nedostupné. V privilegovanom režime je možné vykonávať akékoľvek operácie (obyčajné aj privilegované) a v prevádzkovom režime iba bežné. Pokus o vykonanie privilegovanej operácie, ako aj o prístup k chránenej pamäti v prevádzkovom režime, spôsobí zodpovedajúce prerušenie. Okrem toho privilegované operácie zahŕňajú operácie na zmenu ochrany pamäte a prevádzkového režimu, ako aj prístup k externému informačnému prostrediu. Počiatočné zapnutie počítača a akékoľvek prerušenie by mali automaticky povoliť privilegovaný režim a prepísať ochranu pamäte. V tomto prípade sa riadiaci program (operačný systém) môže úplne chrániť pred vplyvom iných programov, ak všetky riadiace prenosové body pri prvom zapnutí a prerušeniach patria do tohto programu, ak neumožňuje prácu žiadnemu inému programu. privilegovaný režim (pri prenose riadenia do akéhokoľvek iného program zapne iba prevádzkový režim) a ak úplne ochráni svoju pamäť (obsahujúcu najmä všetky jej riadiace informácie vrátane tzv. vektorov prerušenia) pred inými programami. Potom mu nikto nebude brániť vykonávať akékoľvek ochranné funkcie v ňom implementované pre iné programy (vrátane prístupu do externého informačného prostredia). Na uľahčenie riešenia tohto problému je časť takéhoto programu umiestnená v trvalej pamäti, t.j. neoddeliteľné od samotného počítača. Prítomnosť dočasného prerušenia umožňuje riadiacemu programu chrániť sa pred zacyklením v iných programoch (bez takéhoto prerušenia by mohol jednoducho stratiť schopnosť ovládať).
Ochrana pred poruchami „vlastného“ programu je zabezpečená spoľahlivosťou tohto programu, na ktorú sa zameriava celá programovacia technológia, o ktorej sa v tomto kurze prednášok hovorí.
Ochrana pred chybami používateľa (okrem chýb vstupných dát, pozri zabezpečenie stability PS) je zabezpečená vydávaním varovných správ o pokusoch o zmenu stavu externého informačného prostredia s požiadavkou na potvrdenie týchto akcií, ako aj možnosťou obnovenia stavu jednotlivých zložiek vonkajšieho informačného prostredia. Ten je založený na implementácii archivačných zmien v stave externého informačného prostredia.
Ochrana pred neoprávneným prístupom je zabezpečená použitím tajných slov (hesiel). V tomto prípade sú každému používateľovi poskytnuté určité informačné a procedurálne prostriedky (služby), ktorých použitie si vyžaduje predloženie hesla do PS, predtým zaregistrovaného v PS týmto používateľom. Inými slovami, používateľ akoby „zavesil zámok“ na zdroje, ktoré mu boli pridelené, „kľúč“, ku ktorému má iba tento používateľ. Ak však majú chránené zdroje pre niekoho extrémnu hodnotu, možno sa v jednotlivých prípadoch usilovať o prelomenie takejto ochrany. V takom prípade je potrebné prijať dodatočné opatrenia na ochranu pred narušením bezpečnosti.
Ochrana pred narušením bezpečnosti je spojená s používaním špeciálnych programovacích techník v PS, ktoré sťažujú prekonanie ochrany pred neoprávneným prístupom. Používanie bežných hesiel nestačí, keď ide o extrémne pretrvávajúcu túžbu (napríklad kriminálneho charakteru) získať prístup k cenným informáciám. Jednak preto, že informácie o heslách, ktoré PS používa na ochranu pred neoprávneným prístupom, môže pomerne jednoducho získať „cracker“ tejto ochrany, ak má prístup k tomuto PS samotnému. Po druhé, pomocou počítača je možné vykonať dostatočne veľký zoznam možných hesiel s cieľom nájsť vhodné heslo na prístup k požadovaným informáciám. Pred takýmto hackom sa môžete chrániť nasledujúcim spôsobom. Tajné slovo (heslo) alebo iba tajné celé číslo X pozná iba vlastník chránených informácií a pre kontrolu prístupových práv je v počítači uložené ďalšie číslo Y=F(X), ktoré jednoznačne vypočíta PS pri každom pokuse o prístup k týmto informáciám po predložení tajného slova. Funkciu F zároveň môžu všetci používatelia PS dobre poznať, no má takú vlastnosť, že obnovenie slova X z Y je prakticky nemožné: pri dostatočne veľkej dĺžke slova X (napríklad niekoľko stoviek znakov ), to si vyžaduje astronomický čas. Takéto číslo Y sa bude nazývať elektronický (počítačový) podpis vlastníka tajného slova X (a teda chránených informácií).
Ďalší typ takejto ochrany súvisí s ochranou správ odosielaných cez počítačové siete, úmyselným (alebo zlomyseľným) skreslením. Takáto správa môže byť zachytená na „prekladiskách“ počítačovej siete a nahradená inou správou od autora zachytenej správy. Táto situácia vzniká predovšetkým pri realizácii bankových operácií pomocou počítačovej siete. Nahradením takejto správy, ktorá je príkazom majiteľa bankového účtu na vykonanie nejakej bankovej operácie, môžu byť peniaze z jeho účtu prevedené na účet „hackerskej“ ochrany (druh počítačovej bankovej lúpeže). Ochrana pred takýmto narušením bezpečnosti môže byť vykonaná nasledovne. Spolu s funkciou F, ktorá určuje počítačový podpis vlastníka tajného slova X, ktoré pozná adresát chránenej správy (ak je klientom tohto adresáta len jej vlastník), je v tzv. PS, z ktorej musí odosielateľ správy vypočítať číslo S=Stamp(X,R ) pomocou tajného slova X a textu prenášanej správy R. Funkcia Pečiatka sa tiež považuje za dobre známu všetkým používateľom MS a má napr. vlastnosť, že je prakticky nemožné obnoviť číslo X z S, alebo vybrať inú správu R s príslušným počítačovým podpisom. Samotná prenášaná správa (spolu s jej ochranou) by mala vyzerať takto:
navyše Y (počítačový podpis) umožňuje adresátovi zistiť pravdu o klientovi a S akoby spájal chránenú správu R s počítačovým podpisom Y. V tejto súvislosti budeme číslo S nazývať elektronickým (počítačovým ) tuleň. PS definuje ešte jednu Notársku funkciu, podľa ktorej príjemca chránenej správy kontroluje pravdivosť prenášanej správy:
To vám umožní jednoznačne určiť, že správa R patrí vlastníkovi tajného slova X.
Ochrana pred ochranou je potrebná v prípade, že používateľ zabudol (alebo stratil) svoje heslo. Pre takýto prípad by malo byť možné, aby špeciálny používateľ (správca PS) zodpovedný za fungovanie systému ochrany dočasne odstránil vlastníkovi ochranu pred neoprávneným prístupom. zabudnuté heslo aby mal možnosť opraviť si nové heslo.
Literatúra na prednášku 11.
11.1. JE. Berezin, N.P. Židkov. Metódy výpočtu, zv. 1 a 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bakhvalov, N.P. Židkov, G. M. Kobelkov. Numerické metódy. - M.: Nauka, 1987.
11.3. G. Myers. Spoľahlivosť softvéru. - M.: Mir, 1980. S. 127-154.
11.4. A.N. Lebedev. Ochrana bankových informácií a moderná kryptografia//Problémy informačnej bezpečnosti, 2(29), 1995.
Prednáška 12. Zabezpečenie kvality softvéru
12.1. Všeobecné charakteristiky procesu zabezpečenia kvality softvéru.
Ako už bolo uvedené v 4. prednáške, špecifikácia kvality definuje hlavné usmernenia (ciele), ktoré vo všetkých fázach vývoja PS tak či onak ovplyvňujú výber vhodnej možnosti pri rôznych rozhodnutiach. Každý kvalitatívny primitív má však svoje vlastné charakteristiky takéhoto vplyvu, takže zabezpečenie jeho prítomnosti v PS si môže vyžadovať vlastné prístupy a metódy na rozvoj PS alebo jeho jednotlivých častí. Okrem toho bola zaznamenaná aj nejednotnosť kritérií kvality PS a kvalitatívnych primitív, ktoré ich vyjadrujú: dobré zabezpečenie jedného z kvalitatívnych primitív PS môže výrazne skomplikovať alebo znemožniť poskytnutie niektorých ďalších z týchto primitív. Podstatnú časť procesu zabezpečovania kvality PS preto tvorí hľadanie prijateľných kompromisov. Tieto kompromisy by mali byť čiastočne definované už v špecifikácii kvality PS: model kvality PS by mal špecifikovať požadovaný stupeň prítomnosti každého z jeho kvalitatívnych primitív v PS a určiť priority na dosiahnutie týchto stupňov.
Zabezpečenie kvality sa vykonáva v každom technologickom procese: rozhodnutia v ňom prijaté do tej či onej miery ovplyvňujú kvalitu softvéru ako celku. Najmä preto, že významná časť kvalitatívnych primitív nie je spojená ani tak s vlastnosťami programov zahrnutých v PS, ale s vlastnosťami dokumentácie. Vzhľadom na konštatovanú nejednotnosť kvalitných primitívov je veľmi dôležité dodržiavať zvolené priority pri ich poskytovaní. V každom prípade je však užitočné dodržiavať dve všeobecné zásady:
najprv je potrebné zabezpečiť požadovanú funkčnosť a spoľahlivosť PS a následne uviesť ostatné kvalitatívne kritériá na prijateľnú úroveň ich prítomnosti v PS;
nie je potrebné, a môže to byť dokonca škodlivé, hľadať vyššiu úroveň prítomnosti akéhokoľvek kvalitatívneho primitíva v PS, ako je definovaná v špecifikácii kvality PS.
Zabezpečením funkčnosti a spoľahlivosti PS sme sa zaoberali v predchádzajúcej prednáške. Poskytnutie ďalších kritérií kvality OS je popísané nižšie.
12.2.. Zabezpečenie jednoduchosti používania softvérového nástroja
P-dokumentácia PS určuje zloženie užívateľskej dokumentácie
V predchádzajúcej prednáške sa už uvažovalo o zabezpečení dvoch z piatich kvalitných primitív (stabilita a bezpečnosť), ktoré určujú jednoduchosť používania PS.
P-dokumentácia a informatívnosť určujú zloženie a kvalitu užívateľskej dokumentácie (pozri nasledujúcu prednášku).
Komunikácia je zabezpečená vytvorením vhodného používateľské rozhranie a príslušné spracovanie výnimiek. Aký je tu problém?
12.3. Zabezpečenie efektívnosti softvéru.
Efektívnosť PS je zabezpečená prijímaním vhodných rozhodnutí v rôznych fázach jeho vývoja, počnúc vývojom jeho architektúry. Voľba štruktúry a prezentácie údajov ovplyvňuje účinnosť PS obzvlášť výrazne (najmä z hľadiska pamäte). Ale výber algoritmov používaných v určitých softvérových moduloch, ako aj vlastnosti ich implementácie (vrátane výberu programovacieho jazyka) môžu výrazne ovplyvniť účinnosť PS. Zároveň musíme neustále riešiť rozpor medzi časovou efektívnosťou a efektívnosťou z pamäte. Preto je veľmi dôležité, aby špecifikácia kvality explicitne uvádzala kvantitatívny vzťah medzi ukazovateľmi týchto kvalitatívnych primitív, alebo aspoň stanovila kvantitatívne hranice pre jeden z týchto ukazovateľov. A predsa, rôzne softvérové moduly majú rôzny vplyv na efektivitu PS ako celku: tak z hľadiska ich príspevku k celkovým nákladom PS z hľadiska času a pamäte, ako aj z hľadiska vplyvu na rôzne kvalitatívne primitívy. (niektoré moduly môžu silne ovplyvňovať dosiahnutie časovej efektívnosti a prakticky neovplyvňujú efektívnosť pamäte, zatiaľ čo iné môžu výrazne ovplyvniť celkovú spotrebu pamäte bez výrazného ovplyvnenia prevádzkovej doby PS). Navyše tento vplyv (predovšetkým z hľadiska časovej efektívnosti) nie je možné vopred (pred ukončením implementácie PS) vždy správne posúdiť.
najprv musíte vyvinúť spoľahlivý PS a až potom dosiahnuť jeho požadovanú účinnosť v súlade so špecifikáciou kvality tohto PS;
na zlepšenie účinnosti PS v prvom rade použite optimalizačný kompilátor - to môže poskytnúť požadovanú účinnosť;
ak dosiahnutá účinnosť PS nevyhovuje špecifikácii jej kvality, potom nájdite najkritickejšie moduly z hľadiska požadovanej účinnosti PS (v prípade časovej účinnosti si to bude vyžadovať distribúciu po moduloch PS prevádzkový čas príslušnými meraniami počas vykonávania PS); tieto moduly a pokúsiť sa ich najskôr optimalizovať manuálnou úpravou;
neoptimalizujte modul, ak to nie je potrebné na dosiahnutie požadovanej účinnosti PS.
12.4. Zabezpečenie udržiavateľnosti.
C-dokumentácia, informačný obsah a zrozumiteľnosť určujú zloženie a kvalitu dokumentácie údržby (pozri nasledujúcu prednášku). Okrem toho je možné uviesť nasledujúce odporúčania týkajúce sa textov programov (modulov).
používať komentáre v texte modulu, ktoré objasňujú a vysvetľujú vlastnosti prijímaných rozhodnutí; ak je to možné, zahrňte komentáre (aspoň v krátkej forme) v najskoršom štádiu tvorby textu modulu;
používať zmysluplné (mnemotechnické) a trvalo rozlíšiteľné názvy (optimálna dĺžka mena je 4-12 písmen, čísla sú na konci), nepoužívať podobné mená a kľúčové slová;
buďte opatrní pri používaní konštánt (jedinečná konštanta musí mať v texte modulu jeden výskyt: keď je deklarovaná alebo v extrémnych prípadoch, keď je premenná inicializovaná ako konštanta);
nebojte sa použiť voliteľné zátvorky (zátvorky sú lacnejšie ako chyby ;
neumiestnite viac ako jeden výrok na riadok; na objasnenie štruktúry modulu použite nadbytočné medzery (zarážky) na začiatku každého riadku;
vyhnúť sa trikom t.j. taký programovacie techniky, keď sa vytvoria fragmenty modulu, ktorých hlavný účinok nie je zrejmý alebo skrytý (zahalený), ako sú vedľajšie účinky .
Rozšíriteľnosť je zabezpečená vytvorením vhodného inštalátora.
Štruktúra a modularita zjednodušujú pochopenie textov programu a ich modifikáciu.
12.5. Zabezpečenie mobility.
Literatúra na prednášku 12.
12.1. Ian Somerville. Softvérové inžinierstvo. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Štýl, vývoj, efektívnosť, ladenie a testovanie programov. - M.: Mir, 1985. S. 8-44, 117-178.
12.4. Používateľská dokumentácia softvéru/norma ANSI/IEEE 1063-1987.
Prednáška 13
13.1. Dokumentácia vytvorená počas procesu vývoja softvéru.
Pri vývoji PS vzniká veľké množstvo rôznej dokumentácie. Je nevyhnutný ako prostriedok prenosu informácií medzi vývojármi PS, ako prostriedok riadenia vývoja PS a ako prostriedok prenosu informácií potrebných pre aplikáciu a údržbu PS k používateľom. Tvorba tejto dokumentácie tvorí veľkú časť nákladov na PS.
Túto dokumentáciu možno rozdeliť do dvoch skupín:
dokumenty riadenia rozvoja PS.
Dokumenty zahrnuté v PS.
Dokumenty riadenia rozvoja PS (procesná dokumentácia) zaznamenávajú procesy vývoja a údržby PS, zabezpečujú komunikáciu v rámci vývojového tímu a medzi vývojovým tímom a manažérmi (manažérmi) - osobami riadiacimi vývoj. Tieto dokumenty môžu byť nasledujúcich typov:
Plány, odhady, plány. Tieto dokumenty vytvárajú manažéri na predvídanie a riadenie procesov vývoja a údržby.
Správy o využití zdrojov počas vývoja. Vytvorené manažérmi.
Normy. Tieto dokumenty predpisujú vývojárom, aké zásady, pravidlá, dohody musia dodržiavať v procese vývoja PS. Tieto normy môžu byť buď medzinárodné alebo národné, alebo špeciálne vytvorené pre organizáciu, v ktorej sa tento PS vyvíja.
Pracovné dokumenty. Toto sú hlavné technické dokumenty, ktoré zabezpečujú komunikáciu medzi vývojármi. Obsahujú fixáciu myšlienok a problémov, ktoré sa vyskytnú počas procesu vývoja, popis použitých stratégií a prístupov, ako aj pracovné (dočasné) verzie dokumentov, ktoré by mali byť súčasťou PS.
Poznámky a korešpondencia. Tieto dokumenty zachytávajú rôzne detaily interakcie medzi manažérmi a vývojármi.
Dokumenty zahrnuté v PS (dokumentácia k produktu) popisujú programy PS tak z pohľadu ich používania užívateľmi, ako aj z pohľadu ich vývojárov a správcov (v súlade s účelom PS). Tu je potrebné poznamenať, že tieto dokumenty budú použité nielen vo fáze prevádzky PS (vo fázach jej aplikácie a údržby), ale aj vo fáze vývoja na riadenie procesu vývoja (spolu s pracovnými dokumentmi) - v akomkoľvek V tomto prípade by sa mali skontrolovať (otestovať), či sú v súlade s programami PS. Tieto dokumenty tvoria dva súbory s rôznym účelom:
Používateľská dokumentácia PS (P-dokumentácia).
Dokumentácia pre podporu PS (C-dokumentácia).
13.2. Používateľská dokumentácia softvéru.
Používateľská dokumentácia PS (užívateľská dokumentácia) vysvetľuje používateľom, ako musia postupovať, aby mohli túto PS aplikovať. Je potrebné, ak PS zahŕňa akúkoľvek interakciu s používateľmi. Súčasťou takejto dokumentácie sú dokumenty, ktoré užívateľa usmerňujú pri inštalácii PS (pri inštalácii PS s vhodným nastavením pre prostredie na používanie PS), pri používaní PS na riešenie jeho problémov a pri správe PS (napr. keď tento PS interaguje s inými systémami). Tieto dokumenty čiastočne pokrývajú problematiku softvérovej podpory, ale nezaoberajú sa otázkami súvisiacimi s úpravou programov.
V tomto ohľade by sa mali rozlišovať dve kategórie používateľov PS: bežní používatelia PS a správcovia PS. Bežný používateľ PS (koncový používateľ) používa PS na riešenie svojich problémov (vo svojej tematickej oblasti). Môže to byť inžinier navrhujúci technické zariadenie alebo pokladník predávajúci lístky na vlak pomocou PS. Možno nepozná veľa podrobností o fungovaní počítača alebo princípoch programovania. Správca PS (správca systému) spravuje používanie PS bežnými používateľmi a poskytuje podporu PS, ktorá nesúvisí s úpravou programov. Môže napríklad regulovať prístupové práva k OS medzi bežnými používateľmi, komunikovať s poskytovateľmi OS alebo vykonávať určité akcie na udržanie operačného systému v prevádzkovom stave, ak je súčasťou iného systému.
Zloženie používateľskej dokumentácie závisí od cieľových skupín používateľov, na ktorých je tento PS zameraný, a od spôsobu používania dokumentov. Publikum je tu chápané ako kontingent používateľov PS, ktorý potrebuje určitú používateľskú dokumentáciu PS. Úspešný používateľský dokument v podstate závisí od presnej definície cieľovej skupiny, ktorej je určený. Používateľská dokumentácia by mala obsahovať informácie požadované pre každú cieľovú skupinu. Spôsob použitia dokumentu sa vzťahuje na spôsob, akým sa dokument používa. Zvyčajne používateľ dostatočne veľkých softvérových systémov vyžaduje buď dokumenty, aby si preštudoval PS (použitie v inštrukcie), alebo na objasnenie niektorých informácií (použite ako referenciu).
V súlade s prácami možno za typické považovať nasledovné zloženie užívateľskej dokumentácie pre dostatočne veľké PS:
Všeobecný funkčný popis PS. Poskytuje stručný popis funkčnosti PS. Je určený pre používateľov, ktorí sa musia rozhodnúť, ako veľmi tento PS potrebujú.
Inštalačná príručka PS. Určené pre správcov systému. Malo by podrobne predpisovať, ako nainštalovať systémy v konkrétnom prostredí. Obsahuje popis strojovo čitateľného média, na ktorom sa MS dodáva, súbory reprezentujúce MS a požiadavky na minimálnu hardvérovú konfiguráciu.
Návod na použitie PS. Určené pre bežných používateľov. Obsahuje potrebné informácie o aplikácii PS, usporiadané vo forme vhodnej na jej štúdium.
Referenčná kniha o aplikácii PS. Určené pre bežných používateľov. Obsahuje potrebné informácie o aplikácii PS, usporiadané vo forme vhodnej na selektívne vyhľadávanie jednotlivých detailov.
Príručka pre správu PS. Určené pre správcov systému. Mal by popisovať správy generované pri interakcii MS s inými systémami a ako na tieto správy reagovať. Okrem toho, ak MS používa systémový hardvér, tento dokument môže vysvetliť, ako tento hardvér udržiavať.
Ako už bolo spomenuté (pozri 4. prednášku), vývoj užívateľskej dokumentácie začína ihneď po vytvorení externého popisu. Kvalita tejto dokumentácie môže výrazne rozhodnúť o úspechu PS. Mal by byť celkom jednoduchý a užívateľsky prívetivý (inak tento PS vo všeobecnosti nestál za vytvorenie). Preto aj keď koncepty (návrhy) používateľských dokumentov vytvárajú hlavní vývojári PS, na tvorbe ich finálnych verzií sa často podieľajú profesionálni technickí autori. Okrem toho bolo na zabezpečenie kvality užívateľskej dokumentácie vypracovaných množstvo štandardov (pozri napr.), ktoré predpisujú postup tvorby tejto dokumentácie, formulujú požiadavky na jednotlivé typy užívateľských dokumentov a určujú ich štruktúru a obsah. .
13.3. Dokumentácia k softvérovej podpore.
Dokumentácia pre údržbu PS (systémová dokumentácia) popisuje PS z hľadiska jej vývoja. Táto dokumentácia je potrebná, ak PS zahŕňa štúdium toho, ako je usporiadané (navrhnuté) a modernizáciu svojich programov. Ako už bolo uvedené, údržba je neustály vývoj. Ak je teda potrebné upgradovať PS, do tejto práce sa zapája špeciálny tím sprievodných vývojárov. Tento tím sa bude musieť zaoberať rovnakou dokumentáciou, ktorá určovala činnosť tímu prvotných (hlavných) vývojárov PS, len s tým rozdielom, že táto dokumentácia bude spravidla cudzou pre vývojársky tím správcu ( vytvoril ho iný tím). Údržbársky tím bude musieť túto dokumentáciu preštudovať, aby pochopil štruktúru a proces vývoja modernizovaného PS a vykonať potrebné zmeny v tejto dokumentácii, pričom do značnej miery zopakuje technologické postupy, ktorými bol pôvodný PS vytvorený.
Dokumentáciu o podpore PS možno rozdeliť do dvoch skupín:
(1) dokumentácia, ktorá definuje štruktúru programov a dátové štruktúry PS a technológiu na ich vývoj;
(2) dokumentácia na pomoc pri vykonávaní zmien v PS.
Dokumentácia prvej skupiny obsahuje finálne dokumenty každej technologickej etapy vývoja PS. Zahŕňa nasledujúce dokumenty:
Externý popis PS (dokument s požiadavkami).
Popis systémovej architektúry PS vrátane externej špecifikácie každého z jeho programov.
Pre každý program PS popis jeho modulárnej štruktúry vrátane externej špecifikácie pre každý modul, ktorý je v ňom zahrnutý.
Pre každý modul - jeho špecifikácia a popis jeho štruktúry (opis návrhu).
Texty modulov vo vybranom programovacom jazyku (výpis zdrojového kódu programu).
Dokumenty overenia OS popisujúce, ako bola stanovená platnosť každého programu OS a ako boli overovacie informácie spojené s požiadavkami na OS.
Dokumenty na overenie softvéru zahŕňajú predovšetkým testovaciu dokumentáciu (návrh testu a popis testovacej sady), ale môžu zahŕňať aj výsledky iných typov validácie softvéru, ako sú dôkazy o vlastnostiach programu.
Dokumentácia druhej skupiny obsahuje
Sprievodca údržbou systému, ktorý popisuje známe problémy spolu so softvérom, popisuje, ktoré časti systému sú závislé od hardvéru a softvéru a ako je vývoj softvéru zohľadnený v jeho štruktúre (návrhu).
Bežným problémom údržby PS je zabezpečiť, aby všetky jeho reprezentácie držali krok (zostali konzistentné), keď sa PS zmení. Aby to bolo možné, vzťahy a závislosti medzi dokumentmi a ich časťami musia byť zachytené v databáze riadenia konfigurácie.
Literatúra na prednášku 13.
13.1. Ian Somerville. Softvérové inžinierstvo. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE štandard pre softvérovú užívateľskú dokumentáciu.
13.3. ANSI/IEEE Std 830-1984, IEEE príručka pre špecifikáciu softvérových požiadaviek.
13.4. ANSI/IEEE Std 1016-1987, odporúčaná prax IEEE pre popis návrhu softvéru.
13.5. ANSI/IEEE Std 1008-1987, IEEE štandard pre testovanie softvérových jednotiek.
13.6. ANSI/IEEE Std 1012-1986, štandard IEEE pre plány overovania a validácie softvéru.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE štandard pre dokumentáciu testovania softvéru.
Prednáška 14
Vymenovanie softvérovej certifikácie. Testovanie a hodnotenie kvality softvéru. Typy testov a metódy hodnotenia kvality softvéru.
14.1. Vymenovanie softvérovej certifikácie.
Certifikácia PS je smerodajným potvrdením kvality PS. Zvyčajne je pre certifikáciu softvérového systému vytvorená reprezentatívna (atestačná) komisia zložená z odborníkov, zástupcov objednávateľa a zástupcov vývojára. Táto komisia vykonáva testy PS s cieľom získať potrebné informácie na posúdenie jeho kvality. Pod skúškou PS rozumieme proces vykonávania súboru opatrení, ktoré skúmajú vhodnosť PS pre jeho úspešnú prevádzku (aplikáciu a údržbu) v súlade s požiadavkami zákazníka. Tento komplex zahŕňa kontrolu úplnosti a presnosti softvérovej dokumentácie, preštudovanie a diskusiu o jej ďalších vlastnostiach, ako aj potrebné testovanie programov, ktoré sú súčasťou softvérového balíka, a najmä súlad týchto programov s dostupnou dokumentáciou.
Na základe informácií získaných pri testovaní PS je potrebné v prvom rade zistiť, že PS plní deklarované funkcie a tiež je potrebné zistiť, do akej miery má PS deklarované primitívne a kvalitatívne kritériá. Posudzovanie kvality PS je teda hlavným obsahom certifikačného procesu. Posúdenie kvality PS je zaznamenané v príslušnom rozhodnutí atestačnej komisie.
14.2. Typy testovania softvéru.
Sú známe nasledujúce typy skúšok PS, ktoré sa vykonávajú na účely certifikácie PS:
testovanie PS komponentov;
systémové testy;
akceptačné testy;
terénne pokusy;
priemyselné skúšky.
Testovanie komponentov PS je overenie (testovanie) prevádzkyschopnosti jednotlivých subsystémov PS. Konajú sa len vo výnimočných prípadoch na základe osobitného rozhodnutia atestačnej komisie.
Systémové testovanie PS je kontrolou (testovaním) prevádzkyschopnosti PS ako celku. Môže zahŕňať rovnaké typy testovania ako pri komplexnom ladení PS (pozri prednášku 10). Vykonáva sa rozhodnutím atestačnej komisie, ak existujú pochybnosti o kvalite odladenia zo strany vývojárov PS.
Akceptačné skúšky sú hlavným typom skúšok na certifikáciu PS. Práve týmito testami začína svoju prácu certifikačná komisia. Tieto testy začínajú preštudovaním predloženej dokumentácie vrátane dokumentácie o testovaní a odlaďovaní PS. Ak dokumentácia neobsahuje dostatočne úplné výsledky testovania softvéru, certifikačná komisia môže rozhodnúť o vykonaní systémového testovania softvéru alebo o ukončení certifikačného procesu s odporúčaním vývojárovi vykonať dodatočné (kompletnejšie) testovanie softvéru. Okrem toho je možné pri týchto testoch selektívne preskočiť vývojárske testy, ako aj úlohy používateľského ovládania (pozri prednášku 10) a doplnkové testy pripravené komisiou na posúdenie kvality certifikovaného PS.
Testovanie PS v teréne je ukážkou PS spolu s technickým systémom riadeným týmto PS úzkemu okruhu zákazníkov v reálnych podmienkach a správanie PS je starostlivo monitorované. Zákazníci by mali mať možnosť nastaviť si vlastné testovacie prípady, najmä od východov do kritických režimov prevádzky technického systému, ako aj s volaním núdzových situácií v ňom. Ide o dodatočné skúšky vykonávané rozhodnutím atestačnej komisie len pre niektoré PS, ktoré ovládajú niektoré technické systémy.
Priemyselné testovanie PS je proces prevodu PS do trvalej prevádzky používateľom. Ide o obdobie skúšobnej prevádzky PS (pozri prednášku 10) užívateľmi so zberom informácií o správaní PS a jeho prevádzkových vlastnostiach. Ide o záverečné skúšky PS, ktoré sa vykonávajú rozhodnutím atestačnej komisie, ak sa pri predchádzajúcich skúškach získali nedostatočne úplné alebo spoľahlivé informácie na posúdenie kvality certifikovaného PS.
14.3. Metódy hodnotenia kvality softvéru.
Hodnotenie kvality PS pre každé z kritérií sa redukuje na hodnotenie každého z primitív spojených s týmto kritériom kvality PS, v súlade s ich špecifikáciou, vykonanou v špecifikácii kvality tohto PS. Metódy hodnotenia primitív kvality PS možno rozdeliť do štyroch skupín:
priame meranie kvalitných primitívnych ukazovateľov;
spracovanie programov a dokumentácie PS špeciálnymi softvérovými nástrojmi (procesory);
testovanie programov PS;
odborné hodnotenie na základe štúdia programov a dokumentácie PS.
Priame meranie primitívnych ukazovateľov kvality sa vykonáva spočítaním počtu výskytov charakteristických jednotiek, objektov, štruktúr atď. v konkrétnom programovom dokumente, ako aj meraním prevádzkového času. rôzne zariadenia a množstvo obsadenej pamäte počítača počas vykonávania testovacích prípadov. Určitým meradlom efektívnosti pamäte môže byť napríklad počet riadkov programu v programovacom jazyku a určitým meradlom časovej efektívnosti môže byť čas odozvy na dotaz. Použitie akýchkoľvek ukazovateľov pre kvalitatívne primitívy môže byť definované v špecifikácii kvality ČŠ. Metódu priameho merania kvalitných primitívnych ukazovateľov je možné kombinovať s využitím programového testovania.
Určité softvérové nástroje možno použiť na určenie, či má členský štát určité kvalitatívne primitívy. Takéto softvérové nástroje spracúvajú programové texty alebo softvérovú dokumentáciu s cieľom kontrolovať akékoľvek kvalitatívne primitívy alebo získať nejaké ukazovatele týchto kvalitatívnych primitív. Na posúdenie štruktúrovanosti programov PS, ak by boli naprogramované vo vhodnom štrukturálnom dialekte základného programovacieho jazyka, by stačilo prejsť cez štruktúrovaný programový konvertor, ktorý vykonáva syntaktickú a určitú sémantickú kontrolu tohto dialektu a prekladá texty tzv. tieto programy do vstupného jazyka základného prekladača. Takto sa však dá v súčasnosti ovládať len malý počet kvalitných primitívov a aj to v ojedinelých prípadoch. V niektorých prípadoch je namiesto softvérových nástrojov, ktoré kontrolujú kvalitu softvéru, užitočnejšie použiť nástroje, ktoré transformujú prezentáciu programov alebo programovú dokumentáciu. Takým je napríklad formátovač programov, ktorý prináša texty programov do čitateľnej podoby - spracovanie textov programov PS takýmto nástrojom dokáže automaticky zabezpečiť, že PS má patričný kvalitný primitív.
Testovanie sa používa na hodnotenie niektorých primitív kvality PS. Medzi takéto primitívy patrí predovšetkým úplnosť PS, ako aj jeho presnosť, stabilita, bezpečnosť a ďalšie kvalitné primitívy. V niektorých prípadoch sa testovanie používa v kombinácii s inými metódami na hodnotenie jednotlivých primitív kvality PS. Takže na posúdenie kvality dokumentácie o používaní PS (P-dokumentácia) sa používa testovanie v kombinácii s odborným posúdením tejto dokumentácie. Ak sa pri komplexnom odlaďovaní PS vykonalo dostatočne úplné testovanie, potom je možné rovnaké testy použiť aj pri certifikácii PS. V tomto prípade môže certifikačný výbor použiť testovacie protokoly vykonávané počas komplexného ladenia. Aj v tomto prípade je však potrebné vykonať nejaké nové testy alebo aspoň znova spustiť niektoré zo starých. Ak sa zistí, že testovanie počas komplexného ladenia nie je dostatočne dokončené, je potrebné vykonať úplnejšie testovanie. V tomto prípade sa môže rozhodnúť vykonať testy komponentov alebo systémové testy PS, ako aj vrátiť PS vývojárom na revíziu. Je veľmi dôležité, aby sa na vyhodnotenie PS podľa kritéria jednoduchosti použitia (počas ladenia a certifikácie PS) vykonalo úplné testovanie na skúškach pripravených na základe dokumentácie pre aplikáciu a podľa na kritérium udržiavateľnosti - na testy pripravené pre každý z dokumentov navrhnutých na údržbu PS.
Na posúdenie väčšiny kvalitatívnych primitív PS možno v súčasnosti použiť len metódu znaleckých posudkov. Táto metóda spočíva v tom, že sa určí skupina odborníkov, z ktorých každý si na základe preštudovania predloženej dokumentácie urobí názor na vlastníctvo PS požadovaným kvalitatívnym primitívom a následne sa posúdi požadovaná akostný primitív PS vzniká hlasovaním členov tejto skupiny. Toto hodnotenie je možné vykonať ako na dvojbodovom systéme („má“ – „nemá“), ako aj zohľadňovať mieru držby PS týmto kvalitným primitívom (môže sa napríklad vykonať na päťke -bodový systém). Zároveň by sa expertná skupina mala riadiť špecifikáciou tohto primitíva a uvedením spôsobu jeho hodnotenia, formulovaného v špecifikácii kvality certifikovaného PS.
Literatúra na prednášku 14.
14.2. V.V. Lipajev. Testovanie programu. - M.: Rádio a komunikácia, 1986. - S. 231-245.
14.3. D. Van Tassel. Štýl, vývoj, efektívnosť, ladenie a testovanie programov. - M.: Mir, 1985. - S. 281-283.
14.4. B. Schneiderman. Psychológia programovania. - M.: Rádio a komunikácia, 1984. - S. 99-127.
Prednáška 15. Objektový prístup k vývoju softvéru
15.1. Objekty a vzťahy v programovaní. Podstata objektového prístupu k vývoju softvéru.
Svet okolo nás pozostáva z predmetov a vzťahov medzi nimi. Objekt stelesňuje nejakú entitu a má nejaký stav, ktorý sa môže časom meniť v dôsledku vplyvu iných objektov, ktoré sú nejakým spôsobom s údajmi. Môže mať vnútornú štruktúru: môže pozostávať z iných predmetov, ktoré sú tiež v určitom vzájomnom vzťahu. Na základe toho je možné z objektov vybudovať hierarchickú štruktúru sveta. Pre každú konkrétnu úvahu o svete okolo nás sa však niektoré predmety považujú za nedeliteľné („bodové“) a v závislosti od cieľov posudzovania možno akceptovať takéto (nedeliteľné) objekty rôznych úrovní hierarchie. Vzťah spája niektoré objekty: môžeme uvažovať, že spojenie týchto objektov má nejakú vlastnosť. Ak vzťah spája n objektov, potom sa takýto vzťah nazýva n-miestne (n-ary). Na každom mieste asociácie objektov, ktoré môžu byť spojené akýmkoľvek špecifickým vzťahom, môžu byť rôzne objekty, ale celkom určité (v tomto prípade ide o objekty určitej triedy). Vzťah na jednom mieste sa nazýva vlastnosť objektu (príslušnej triedy). Stav objektu možno študovať hodnotou vlastností tohto objektu alebo implicitne hodnotou vlastností zväzkov objektov spojených s daným jedným alebo druhým vzťahom.
V procese poznávania alebo zmeny sveta okolo nás vždy berieme do úvahy ten či onen zjednodušený model sveta (modelový svet), do ktorého zaraďujeme niektoré predmety a niektoré vzťahy okolitého sveta, resp. spravidla jedna úroveň hierarchie. Každý objekt, ktorý má vnútornú štruktúru, môže predstavovať svoj vlastný modelový svet, vrátane objektov tejto štruktúry a vzťahov, ktoré ich spájajú. Svet okolo nás teda možno považovať (v určitom priblížení) za hierarchickú štruktúru modelových svetov.
V súčasnosti, v procese učenia alebo zmeny sveta okolo nás, sa výpočtová technika široko používa na spracovanie rôznych druhov informácií. V tomto smere sa využíva počítačová (informačná) reprezentácia objektov a vzťahov. Každý objekt môže byť informačne reprezentovaný nejakou dátovou štruktúrou, ktorá zobrazuje jeho stav. Vlastnosti tohto objektu je možné nastaviť priamo ako samostatné komponenty tejto štruktúry, alebo špeciálnymi funkciami na tejto dátovej štruktúre. N-árne vzťahy pre N>1 môžu byť reprezentované buď v aktívnej forme alebo v pasívnej forme. Vo svojej aktívnej forme je N-miestna relácia reprezentovaná nejakým programovým fragmentom, ktorý implementuje buď N-miestnu funkciu (určujúcu hodnotu vlastnosti zodpovedajúceho spojenia objektov) alebo procedúru, ktorá mení stavy niektorých z nich na základe o stave reprezentácií objektov spojených reprezentovaným vzťahom. V pasívnej forme môže byť takýto vzťah reprezentovaný určitou dátovou štruktúrou (ktorá môže zahŕňať reprezentácie objektov spojených týmto vzťahom), interpretovaná na základe prijatých dohôd o všeobecných postupoch, ktoré sú nezávislé od konkrétnych vzťahov (napr. relačná databáza). V oboch prípadoch reprezentácia vzťahu definuje niektoré činnosti spracovania údajov.
Pri skúmaní modelového sveta môže používateľ prijímať (alebo chcieť prijímať) informácie z počítača rôznymi spôsobmi. V jednom prístupe môže mať záujem získať informácie o jednotlivých vlastnostiach objektov, ktoré ho zaujímajú, alebo o výsledkoch akejkoľvek interakcie medzi niektorými objektmi. Na tento účel nariadi vývoj jedného alebo druhého PS, ktorý vykonáva funkcie, ktoré ho zaujímajú, alebo nejaký informačný systém schopný vydávať informácie o vzťahoch, ktoré ho zaujímajú, pomocou príslušnej databázy. V počiatočnom období rozvoja výpočtovej techniky (s nedostatočne vysokým výkonom počítačov) bol takýto prístup k využívaniu počítačov celkom prirodzený. Práve on vyprovokoval funkčný (vzťahový) prístup k rozvoju PS, o ktorom sa podrobne hovorilo v predchádzajúcich prednáškach. Podstatou tohto prístupu je systematické využívanie dekompozície funkcií (relácií) na budovanie štruktúry PS a programových textov v nej zahrnutých. Samotné objekty, na ktoré sa nariadené a realizované funkcie aplikovali, boli zároveň prezentované fragmentárne (v rozsahu potrebnom na plnenie týchto funkcií) a vo forme vhodnej na realizáciu týchto funkcií. Nebola teda poskytnutá úplná a primeraná počítačová reprezentácia modelového sveta, ktorý by bol pre používateľa zaujímavý: jeho zobrazenie na použitom PS by sa mohlo ukázať ako dosť namáhavá úloha pre používateľa, pokus o mierne rozšírenie objemu a povahy informácie o modelovom svete, ktorý používateľa zaujíma. z takejto rozvodne by mohlo viesť k ich vážnej modernizácii. Tento prístup k vývoju PS je podporovaný väčšinou používaných programovacích jazykov, od assemblerov a procedurálne jazyky(Fortran, Pascal) na funkčné jazyky (LISP) a logické programovacie jazyky (PROLOGUE).
Pri inom prístupe k štúdiu modelového sveta pomocou počítača môže mať používateľ záujem o pozorovanie zmeny stavov objektov v dôsledku ich interakcií. To si vyžaduje pomerne solídnu reprezentáciu objektu záujmu používateľa v počítači a softvérové komponenty, ktoré implementujú vzťahy, na ktorých sa tento objekt zúčastňuje, sú s ním výslovne spojené. Na implementáciu tohto prístupu bolo potrebné vybudovať softvérové nástroje, ktoré simulujú procesy interakcie medzi objektmi (modelový svet). S pomocou tradičných vývojových nástrojov sa to ukázalo ako dosť namáhavá úloha. Je pravda, že sa objavili programovacie jazyky, ktoré sú špecificky zamerané na takéto modelovanie, ale to len čiastočne zjednodušilo úlohu vývoja požadovaného PS. Najkompletnejším riešením tohto problému je objektový prístup k rozvoju PS. Jej podstata spočíva v systematickom využívaní dekompozície objektov pri výstavbe štruktúry PS a textov programov v nej zaradených. Zároveň funkcie (vzťahy) vykonávané takýmto PS boli vyjadrené prostredníctvom vzťahov objektov rôznych úrovní, teda ich rozklad výrazne závisel od rozkladu objektov.
Keď už hovoríme o objektovom prístupe, mali by sme tiež jasne pochopiť, o aký druh objektov ide: objekty modelového sveta používateľa, ich informačná reprezentácia, programové objekty, s ktorými je PS zostavený. Okrem toho je potrebné rozlišovať medzi skutočnými objektmi („pasívne“ objekty) a subjektmi („aktívne“ objekty).
15.2. Objekty a subjekty v programovaní.
15.3. Objektívne a subjektívne prístupy k vývoju softvéru.
Descartes poznamenal, že ľudia majú zvyčajne objektovo orientovaný pohľad na svet (c).
Veria, že objektovo orientovaný dizajn je založený na princípoch:
zvýraznenie abstrakcií,
Obmedzenie prístupu,
modularita,
hierarchia,
písanie,
paralelizmus,
udržateľnosť.
Ale toto všetko sa dá aplikovať vo funkčnom prístupe.
Je potrebné rozlišovať medzi výhodami a nevýhodami všeobecného objektového prístupu a jeho špeciálnym prípadom – subjektovo orientovaným prístupom.
Výhody všeobecného objektívneho prístupu:
Prirodzené mapovanie reálneho sveta na štruktúre PS (prirodzené ľudské vnímanie schopností PS, netreba „vymýšľať“ štruktúru PS, ale používať prirodzené analógie).
Použitie dostatočne zmysluplných štruktúrnych jednotiek PS (objekt ako celistvosť neredundantných asociácií, informačne silné moduly).
Zníženie zložitosti vývoja softvéru prostredníctvom použitia novej úrovne abstrakcií (využívanie hierarchie „neprogramových“ abstrakcií pri vývoji softvéru: klasifikácia objektov reálneho sveta, metóda analógií v prírode) ako novej úrovne dedičstvo.
15.4. Objektový prístup k vývoju externého popisu a softvérovej architektúry.
Objektovo orientovaný dizajn je metóda, ktorá využíva rozklad objektov; objektovo orientovaný prístup má svoj vlastný systém symbolov a ponúka bohatú sadu logických a fyzických modelov pre návrh systému vysoký stupeňťažkosti. .
Objektovo orientovaná analýza (OOA) poskytla objektový prístup. OOA má za cieľ vytvárať modely, ktoré sú bližšie realite pomocou objektovo orientovaného prístupu; ide o metodiku, v ktorej sa požiadavky tvoria na základe pojmov tried a objektov, ktoré tvoria slovnú zásobu predmetnej oblasti. .
Vlastnosti objektovo orientovaného programovania.
Objekty, triedy, správanie objektov, vlastnosti, udalosti.
Literatúra na prednášku 15.
15.1. K. Futi, N. Suzuki. Programovacie jazyky a obvody VLSI. - M.: Mir, 1988. S. 85-98.
15.2. Ian Somerville. Softvérové inžinierstvo. - Addison-Wesley Publishing Company, 1992. P. ?-?
15.3. G. Butch. Objektovo orientovaný dizajn s príkladmi použitia: per. z angličtiny. - M.: Concord, 1992.
15.4. V.Sh.Kaufman. Programovacie jazyky. Pojmy a princípy. Moskva: Rádio a komunikácia, 1993.

Prednáška 8. Vývoj softvérového modulu

8.1. Postup pri vývoji softvérového modulu.

8.2. Štrukturálne programovanie.

8.3. Podrobný popis a koncept pseudokódu.

8.4. Ovládanie softvérového modulu.

Literatúra na prednášku 8.

Prednáška 9

9.1. Programové odôvodnenia. Formalizácia vlastností programu.

9.2. Vlastnosti jednoduchých operátorov.

9.3. Vlastnosti základných štruktúr štruktúrneho programovania.

9.4. Ukončenie vykonávania programu.

9.5. Príklad dôkazu vlastnosti programu.

Literatúra na prednášku 9.

Prednáška 10

10.1. Základné pojmy.

10.2. Princípy a typy ladenia.

10.3. Ladiace príkazy.

10.4. Offline ladenie modulu.

10.5. Komplexné ladenie softvéru.

Literatúra na prednášku 10.

Prednáška 11

11.1. Funkčnosť a spoľahlivosť ako povinné kritériá kvality softvéru.

11.2. Zabezpečenie úplnosti softvéru.

11.3. Zabezpečenie presnosti softvérového nástroja.

11.4. Zabezpečenie autonómie softvéru.

11.5. Zabezpečenie udržateľnosti softvéru.

11.6. Zabezpečenie bezpečnosti softvéru.

Literatúra na prednášku 11.

Prednáška 12. Zabezpečenie kvality softvéru

12.1. Všeobecné charakteristiky procesu zabezpečenia kvality softvéru.

12.3. Zabezpečenie efektívnosti softvéru.

Literatúra na prednášku 12.

Prednáška 13

13.1. Dokumentácia vytvorená počas procesu vývoja softvéru.

13.2. Používateľská dokumentácia softvéru.

Literatúra na prednášku 13.

Prednáška 14

14.1. Vymenovanie softvérovej certifikácie.

14.2. Typy testovania softvéru.

14.3. Metódy hodnotenia kvality softvéru.

Prednáška 15. Objektový prístup k vývoju softvéru

15.1. Objekty a vzťahy v programovaní. Podstata objektového prístupu k vývoju softvéru.

15.2. Objekty a subjekty v programovaní.

15.3. Objektívne a subjektívne prístupy k vývoju softvéru.

15.4. Objektový prístup k vývoju externého popisu a softvérovej architektúry.

Literatúra na prednášku 15.