A „Számítógépes rendszerek szoftvermoduljainak fejlesztése” szakmai modul képzési gyakorlatának munkaprogramja. PM.01
"Szoftverfejlesztés
szoftver modulok
szoftver számítógéphez
rendszerek"
MDK
Rendszer programozásAlkalmazás programozás
A modul céljai és célkitűzései
tud:a szoftverfejlesztés főbb szakaszai
Biztonság;
szerkezeti technológia alapelvei
és objektumorientált
programozás;
a hibakeresés és tesztelés alapelvei
szoftvertermékek;
a technikai fejlesztés módszerei és eszközei
dokumentáció.
A modul céljai és célkitűzései
képesnek lenni:szoftver kódot fejleszteni
modulok modern programozási nyelveken;
készítsen programot a kidolgozott algoritmus szerint
külön modulként;
hibakereső és tesztelje a programot
modulszint;
szoftver dokumentációt készíteni
felszerelés;
eszközöket használjon
papírmunka automatizálása;
A modul céljai és célkitűzései
gyakorlati tapasztalattal rendelkezik:a feladathoz algoritmus kidolgozása és
eszközökkel való megvalósítás
automatizált tervezés;
szoftver termékkód fejlesztés
szinten kész specifikáció alapján
modul;
eszközök használata be
a szoftvertermék hibakeresési szakasza;
szoftver tesztelés
modul egy adott forgatókönyv szerint;
Szakmai kompetenciák
PC 1.1. Egyedi specifikációk kidolgozásaösszetevő.
PC 1.2. Szoftver termékkód fejlesztésének elvégzése
modulszintű kész specifikációk alapján.
PC 1.3. Végezze el a programmodulok hibakeresését a
speciális szoftver segítségével.
PC 1.4. Végezze el a szoftvermodulok tesztelését.
PC 1.5. A modul programkódjának optimalizálásához.
PC 1.6. Tervezési és műszaki alkatrészek fejlesztése
dokumentáció grafikus nyelvekkel
specifikációk.
Interdiszciplináris kapcsolatok
Informatika és IKT;Információs technológia;
Építészet számítógépes rendszerek;
Programozási alapismeretek;
OS.
A tanulmányozás szakaszai
Auditív leckékGyakorlati leckék
Önálló munkavégzés
tanfolyam projekt
Nevelési gyakorlat
Szakmai gyakorlat
Minősítő vizsga (védés
portfólió)
Alkalmazás programozás
1. rész Az alkalmazásfejlesztés alapelvei
Téma 1.1. Alapfogalmakalkalmazás programozás
Kérdések
Osztályozás szoftverA szoftver életciklusa
Programfejlesztési szakaszok
Program Dokumentáció Mi a programozás? Programozás – tág értelemben
képviseli az összes műszaki
létrehozásához szükséges műveleteket
programok, beleértve a követelményelemzést és
a fejlesztés és a megvalósítás minden szakaszában. BAN BEN
szűk értelemben a kódolás és
program tesztelése belül
valamilyen konkrét projekt. Mi az a szoftver? Szoftver (szoftver) (szoftver)
- általános kifejezés erre
"megfoghatatlan" (szemben a fizikaival)
számítógépes rendszer összetevői.
A legtöbb esetben arra utal
programok futnak
számítógépes rendszerhez
hangsúlyozzák a hardvertől való különbségüket
ugyanazon rendszer eszközeivel. Milyen osztályú szoftverek
Tudod? rendszer: operációs rendszerek; járművezetők
eszközök; különféle közművek;
fejlesztőknek: programozási környezetek;
fordítók és tolmácsok; CASE szerszámok;
programkönyvtárak;
végfelhasználók számára: szöveg
processzorok; táblázatok; grafikus
szerkesztők; matematikai feladatok megoldói;
képzési és ellenőrzési rendszerek;
számítógépes játékok; alkalmazási programok. Mi az az alkalmazott
program? alkalmazási program (alkalmazás
program) - bármilyen program,
hozzájárul a feladathoz,
ezen belül a számítógéphez rendelve
szervezése és közvetlen hozzájárulása
e feladat végrehajtása. Mit nevezhetünk szoftverrendszernek? A szoftverrendszer képviseli
a halmaz megoldásainak halmaza
különböző, de összefügg
feladatok (OS, DBMS).
Magasabbra specializálódott
a programokat nem rendszernek nevezzük
(szövegszerkesztő, fordító, stb.)
Szoftver életciklusa (szoftver életciklusa) a létezés teljes időszaka
szoftver rendszerek,
a kezdeti fejlesztésétől kezdve
ennek a rendszernek a koncepcióját és annak befejezését
avulás
A SZOFTVER ÉLETCIKLUSA
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
Rendszer elemzése.A követelmények elemzése
alapú szoftverrendszer
az összes információáramlás elsődleges tanulmányozása
hagyományos munkavégzés során és végzik
a következő sorrendben:
a) minden munka típusának és sorrendjének tisztázása;
b) a célok meghatározása
a kidolgozott program által elért;
c) az eredményt biztosító analógok azonosítása
hasonló célok, azok előnyei és hátrányai.
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
Külső specifikációKülső specifikációk meghatározásából áll, pl.
a bemeneti és kimeneti információk leírása,
bemutatásuk formái és az információfeldolgozás módjai.
Megvalósítása a következő sorrendben:
a) feladat kitűzése új program kidolgozására;
b) a fejlesztettek elért céljainak értékelése
szoftver termék.
Továbbá, ha szükséges, az 1-2. lépések megismételhetők, amíg
a program kielégítő megjelenésének elérése
rendszer az általa ellátott funkciók leírásával és néhány
működésének végrehajtásának egyértelműsége.
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
ProgramtervezésA program leírásának kialakítása érdekében munkálatokat végeznek.
Ennek a fázisnak a kezdeti adatai a meghatározott követelmények
az előző lépésben kidolgozott specifikációban. elfogadott
a követelmények teljesítésével kapcsolatos döntések
specifikációk. A programfejlesztés ezen szakasza két szakaszra oszlik:
a) építészeti tervezés. Ez egy fejlesztés
programleírások itt Általános nézet. Ez a leírás tartalmazza
információk a szerkezetépítés lehetséges lehetőségeiről
szoftvertermék (akár több program formájában, akár
egy program több része), valamint a fő
algoritmusok és adatstruktúrák. Ennek a munkának az eredménye
a szoftverrendszer architektúra végleges verziója,
az egyes szoftverkomponensek szerkezetére vonatkozó követelmények és
Fájlok szervezése programok közötti adatcseréhez;
b) munkaterv. Ebben a szakaszban az építészeti leírás
A program olyan szinten van részletezve, amely lehetővé teszi
megvalósításának lehetséges munkája (kódolás és összeszerelés). Mert
Ez a modulok specifikációinak összeállításával és ellenőrzésével történik,
modulok logikájának leírásainak összeállítása, a döntő összeállítása
program végrehajtási tervet.
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
Kódolás és tesztelésEgyedi modulokhoz és
ig kész modulok gyűjteménye
megkapta a kész programot.
Átfogó tesztelés
Működési fejlesztés
dokumentáció
Elfogadás és egyéb típusok
tesztek
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
ProgramjavításEredmények alapján
korábbi tesztek.
Kiszállítás a vevőnek
Végső szállítás folyamatban
szoftverterméket az ügyfélnek.
Replikáció
A PROGRAMOK LÉTREHOZÁSÁNAK SZAKASZAI
Program támogatásTartalmazza az összes szükséges műszaki műveletet
hogy használja ezt a programot a munkában
mód. A program módosítás alatt áll
javítások elvégzése a munkadokumentációban,
programjavítás stb.
Az ilyenek széles skálája miatt
a műveletek támogatása iteratív
folyamat, amelyet kívánatos végrehajtani
annyi után, mint a szoftver kiadása előtt
általános használatra szánt termékek.
Kérdések
1. Programozási alapfogalmak.Szoftver osztályok.
2. A szoftver életciklusa
biztosítsa
3. A programok létrehozásának szakaszai
A PROGRAM DOKUMENTÁCIÓJA
Minden tervezési szakaszbana megfogalmazásban csúcsosodik ki
vonatkozó dokumentumokat, tehát
fontos tervezési elem
szoftveralkalmazások
szoftver dokumentáció elkészítése.
A PROGRAM DOKUMENTÁCIÓJA
Program specifikáció (programspecifikáció) – annak pontos leírása
elérendő eredmény
a program használatával. Ez a leírás
pontosan meg kell határozni, hogy mit
készítsen programot anélkül, hogy megadná, hogyan
meg kellene tennie.
A PROGRAM DOKUMENTÁCIÓJA
Azokra a programokra, amelyek valamilyen eredménnyel fejezik be munkájukat, általában lefordítvaI/O specifikációk, amelyek leírják
a bemeneti készlet kívánt leképezése
mennyiségeket a kimeneti mennyiségek halmazává.
Ciklikus programok esetén (amelyekben a 2. sz
jelölje meg a végpontot), fejlessze
specifikációk, ahol a hangsúly van
az egyéni funkciókra összpontosít,
ciklus során valósítja meg a program
tevékenységek.
A PROGRAM DOKUMENTÁCIÓJA
Az elsődleges specifikáció a következőket írja le:a feladatban érintett objektumok (amit a program csinál
és mit csinál az ezzel a programmal dolgozó személy);
folyamatok és tevékenységek (projekteljárások és tevékenységek
ember, algoritmusok gépi problémák megoldására,
az információfeldolgozás rendje, a működési méret
a program működéséhez szükséges memória);
bemeneti és kimeneti adatok, valamint azok szervezettsége
(például egy párbeszéd szkript képernyő formákkal,
a rekordmezők hosszát meghatározó fájlok szervezése és
maximális információmennyiség a fájlokban);
utasításokat a jövőbeli program használatához.
A PROGRAM DOKUMENTÁCIÓJA
Tegyen különbséget a külső szoftverek között-vel összhangban lévő dokumentációt
ügyfél és középhaladó
belső projektdokumentáció.
Program összeállításakor
először a dokumentációt dolgozzák ki
külső specifikációk, majd -
belső.
A PROGRAM DOKUMENTÁCIÓJA
A külső specifikációk közé tartozikbemeneti és kimeneti specifikációk
adatok, azok szerveződése, reakciói
kivételek, meghatározás,
mit csinál az ember (milyen algoritmusok szerint
működik, és honnan szerez információkat), és
azt a gépet.
A PROGRAM DOKUMENTÁCIÓJA
A belső specifikációk közé tartozikbelső programadatok leírása
(változók, különösen strukturált) és
az egész program algoritmusainak leírása és annak
alkatrészek.
A belső specifikációk egységben vannak megadva
a szoftver architektúra leírásával
összetett és belső szerkezet
külön szoftver építése
összetevő.
Házi feladat
Készítsen listát a dokumentumtípusokróla szoftver életciklusának biztosítása.
befogadás elve, amely azt biztosítja
létrehozásának, működtetésének és fejlesztésének követelményei
A szoftvert a bonyolultabbak oldaláról határozzák meg,
az azt tartalmazó rendszer;
a rendszerszintű egység elve, amely az
hogy a teremtés, a működés minden szakaszában és
szoftverfejlesztés, annak integritása biztosított lesz
alrendszerek közötti kapcsolatok, ill
a vezérlő alrendszer működése;
fejlesztési elv, amely szoftvert biztosít
bővítési és fejlesztési lehetőség
összetevők és a köztük lévő kapcsolatok;
A PROGRAMOK LÉTREHOZÁSÁNAK RENDSZERRE VONATKOZÓ ELVEI
a komplexitás elvehogy a szoftver biztosítja
az információfeldolgozás összekapcsolhatósága
egyes elemekre és a teljes kötetre
adatok általában a feldolgozás minden szakaszában;
az információegység elve, vagyis
minden alrendszerben, támogatási eszközökben és
a szoftverösszetevők gyakoriak
kifejezések, szimbólumok, konvenciók és
prezentációs módszerek;
A PROGRAMOK LÉTREHOZÁSÁNAK RENDSZERRE VONATKOZÓ ELVEI
A kompatibilitás elve aznyelv, szimbólumok, kódok és szoftvereszközök
rendelkezés megegyezett, biztosít
valamennyi együttes működése
alrendszereket, és nyitott struktúrát tartsanak fenn
rendszerek egésze;
az invariancia elve határozza meg
a szoftveralrendszerek és komponensek változatlansága
a feldolgozott információkhoz, azaz univerzálisak vagy tipikusak.
A programozási technológiák azok
bevált alkotási stratégiák
metódusok formájában bemutatott programok
információs alapokkal, leírásokkal
tervezési eljárások és tervezési műveletek.
Van egy szerkezeti technológia
programozás, technológia
programok tervezése racionális
adatstruktúra, objektum-orientált programozási technológia,
vizuális programozási technológia.
TECHNOLÓGIÁK ÉS PROGRAMOZÁSI PARADIGMÁK
Programozási paradigmák (fogalmak,hitrendszerek) különböznek
a programok írásának megközelítései.
Négy fő paradigma létezik
amelyek a mai nap nagy részét leírják
programozási módszerek: kötelező,
alkalmazkodó, szabályalapú
és objektumorientált.
TECHNOLÓGIÁK ÉS PROGRAMOZÁSI PARADIGMÁK
imperatív paradigmaEz a modell a hardver jellemzőiből következik
szabványos számítógép, amely utasításokat hajt végre
(parancsokat) egymás után.
Az ebben használt absztrakció fő típusa
paradigma, algoritmusok. Ennek alapján alakult ki
sok operátor-orientált nyelv
programozás.
Egy ilyen nyelvű program a sorozatból áll
operátorok, amelyek mindegyikének végrehajtása magában foglalja
az érték megváltoztatása egy vagy több memóriacellában. BAN BEN
Általában egy ilyen nyelv szintaxisa a következő:
Operator_1:
Operator_2:
...
TECHNOLÓGIÁK ÉS PROGRAMOZÁSI PARADIGMÁK
Applikatív paradigmaEz a paradigma a megfontoláson alapul
a program által végrehajtott funkció.
A kérdés az: milyen funkcióra van szükség
alkalmazza a gép kezdeti állapotára (by
kezdeti változókészlet kiválasztása és
bizonyos módon kombinálva) ahhoz
eléri a kívánt eredményt?
Nyelvek, amelyek ezt a nézetet hangsúlyozzák
számításokat alkalmazó, ill
funkcionális. Egy nyelv szintaxisa, mint pl
szabály így néz ki:
Funkció_n (... függvény_2 (függvény_1 (adatok))...)
TECHNOLÓGIÁK ÉS PROGRAMOZÁSI PARADIGMÁK
Szabályalapú paradigmaEzen a paradigmaellenőrzésen alapuló nyelvek
a szükséges megengedő feltétel megléte, illetve annak fennállása esetén
az észlelések elvégzik a megfelelő műveletet.
Egy program futtatása hasonló nyelven olyan, mint
parancsoló nyelven írt program végrehajtása.
A nyilatkozatok azonban nem abban a sorrendben kerülnek végrehajtásra
amelyeket a programban definiáltak. Végrehajtási sorrend
megengedő feltételeket határoz meg. Az ilyen nyelvek szintaxisa
alábbiak szerint:
megengedő feltétel_1 -> művelet_1 megengedő
feltétel_2 -> művelet__2
feltétel_n -> művelet _n engedélyezése
Néha a szabályok úgy vannak megírva, hogy "ha cselekvés
megengedő feltétel", amikor a műveletet végre kell hajtani
balra írva.
TECHNOLÓGIÁK ÉS PROGRAMOZÁSI PARADIGMÁK
Objektum-orientált paradigmaEz a modell összetett adatobjektumokat épít fel.
A rajtuk végzett műveletekhez néhány
korlátozott módszerkészlet. Létrehozva
az objektumok örökölhetik az egyszerűbb tulajdonságokat
tárgyakat.
E képesség miatt az objektum-orientált programok magas
a programok hatékonyságát
kötelező nyelveken írva. Lehetőség
használó különféle osztályok fejlesztése
adatobjektumok korlátozott készlete,
rugalmasságot és megbízhatóságot biztosít, ami
egy applikatív nyelvre jellemző.
Adás (összeállítás)
Ez egy módszer a beírt programok fordítására
magas szintű nyelvek, megfelelőre
használt gépi nyelvű programok
számítógép.
Ezt követően a tolmács beépített
mikroprocesszoros hardver,
közvetlenül végrehajtja a fordítást
gépi kód program. Ennek az az előnye
módszer - nagyon gyors programvégrehajtás
a fordítási folyamat befejezése után.
MŰSORSZÁMÍTÁS, ÉRTELMEZÉS
A fordító olyan nyelvfeldolgozó, amelyvalamilyen forrásból fogad programokat
nyelv bemenetként és kimenetként
funkcionalitásukban egyenértékűek
programokon, de már egy másik, ún
tárgynyelv (ami lehet
tetszőleges szint).
Az assembler az a fordító, akinek a forrása
a nyelv szimbolikus reprezentáció
gépi kód (assembler) és objektumnyelv
egyfajta gépi nyelv
bármilyen valódi számítógép.
MŰSORSZÁMÍTÁS, ÉRTELMEZÉS
A fordító olyan fordító, amelyhez a forrásegy magas szintű nyelv, és annak tárgynyelve
közel áll egy valódi számítógép gépi nyelvéhez. Ez
akár assembly nyelven, akár valamilyen változatán
gépi nyelv.
A linker (linker) egy fordító,
amelynek forrásnyelve a nyelven található programokból áll
gépi nyelv áthelyezhető formában és táblázatokban
adatok, amelyek jelzik azokat a pontokat, ahol
az áthelyezhető kódot módosítani kell,
végrehajthatóvá válni. Az objektumnyelv a következőkből áll
készen áll a gépi utasítások végrehajtására. feladat
linker egyetlen végrehajtható fájl létrehozása
programot használó megegyezés szerint
táblázatban látható címeket.
MŰSORSZÁMÍTÁS, ÉRTELMEZÉS
Az előfeldolgozó (makroprocesszor) azfordító, akinek forrásnyelve
kiterjesztett formája
magas szintű nyelv (például Java vagy
C++), az objektumnyelv pedig a szabvány
ennek a nyelvnek a változata. objektum program,
az előfeldolgozó által létrehozott, készen
a szokásos fordítása és végrehajtása
az eredeti szabvány processzorai
nyelv
MŰSORSZÁMÍTÁS, ÉRTELMEZÉS
Értelmezés (szoftveres szimuláció)Ez a módszer a program használatakor
(tolmács) végrehajtva
hardver számítógép, létrehozva
gépi nyelvű virtuális számítógép
magas szint. A tolmács dekódolja és
végrehajtja a program minden utasítását
magas szintű nyelv a megfelelő
sorozatokat és kimenetet állít elő
az ezzel definiált eredő adatokat
program.
MŰSORSZÁMÍTÁS, ÉRTELMEZÉS
Vegyes megvalósítási rendszerekElőször a programot lefordítják az eredetiről
olyan formává alakítja, amely kényelmesebb a végrehajtáshoz.
Ez általában több létrehozásával történik
a program önálló részei, ún
modulok.
A töltési szakaszban ezek a független részek egyesülnek
futásidejű programokkal,
szoftver-szimulált megvalósítása
(értelmezett) műveletek. Oda vezet
program végrehajtható formájának létrehozása, utasítások
amelyek dekódolása és végrehajtása azok segítségével történik
értelmezés.
A PROGRAMOZÁSI NYELVEK KÖRNYEZETEI ÉS MEGVALÓSÍTÁSAI
A programozási környezet egy halmaza fejlesztés során használt eszközöket
szoftver.
Ez a készlet általában egy fájlból áll
rendszer, szövegszerkesztő, szerkesztő
linkek és fordító. Ráadásul ő
nagy számot tartalmazhat
hangszeres komplexusokkal
egységes felhasználói felület
Gyakorlat
Sorolja fel és írja le a különféle fajtákatprogramozási környezetek.
A szoftvermodul fejlesztésének eljárása.
- 1. a modul specifikáció tanulmányozása, ellenőrzése, programozási nyelv kiválasztása; (azaz a fejlesztő a specifikációt tanulmányozva rájön, hogy világos-e számára vagy sem, kellően leírja-e a modult; majd kiválasztja a programozási nyelvet, amelyen a modul megírásra kerül, bár a programozási nyelv lehet a ugyanaz az egész PS-re)
- 2. az algoritmus és az adatstruktúra megválasztása (itt kiderül, hogy ismert-e algoritmus a probléma megoldására, és ha igen, akkor használja)
- 3. modul programozás (programkód írása)
- 4. a modul szövegének csiszolása (meglévő megjegyzések szerkesztése, további megjegyzések hozzáadása a szükséges minőség biztosítása érdekében)
- 5. a modul ellenőrzése (a modul logikájának ellenőrzése, működése hibakeresés)
A következő programmodul-vezérlési módszereket alkalmazzuk:
- - a modulszöveg statikus ellenőrzése (a szöveg elejétől a végéig elolvasásra kerül, hogy a modulban hibákat találjunk. Általában a modulfejlesztőn kívül egy vagy akár több programozó is részt vesz egy ilyen ellenőrzésben. Javasoljuk, hogy az ellenőrzés során észlelt hibákat nem azonnal, hanem a modul szövegének beolvasása után kell javítani)
- - végpontok közötti nyomkövetés (a modul végrehajtásának manuális görgetése (operátoronként a modul logikájából következő sorrendben) egy bizonyos tesztsorozaton)
- 6. a modul összeállítása.
Strukturális programozás.
Manapság a legnépszerűbb programozási technika a felülről lefelé irányuló strukturált programozás.
A strukturális programozás az a folyamat, amikor egy algoritmust lépésről lépésre egyre kisebb részekre bontanak annak érdekében, hogy olyan elemeket kapjanak, amelyekre egyszerűen konkrét előírások írhatók fel.
A strukturált programozás két alapelve:
- 1. szekvenciális részletezés "fentről lefelé"
- 2. korlátozott alapkészlet struktúrák tetszőleges bonyolultságú algoritmusok készítéséhez
Strukturált programozási követelmények:
- 1. A programot kis lépésekben kell összeállítani, így az összetett feladat meglehetősen egyszerű, könnyen érzékelhető részekre oszlik.
- 2. a programlogikának minimális számú kellően alapvető vezérlőstruktúrán kell alapulnia (lineáris, elágazó és ciklikus struktúrák)
A strukturált programozás főbb tulajdonságai és előnyei:
- 1. A programok összetettségének csökkentése
- 2. a programok helyességének bemutatásának lehetősége a probléma megoldásának különböző szakaszaiban
- 3. a programok láthatósága
- 4. a programok egyszerű módosítása (változtatása).
A modern programozási eszközöknek maximális védelmet kell nyújtaniuk az esetleges fejlesztői hibák ellen.
Itt analógiát vonhatunk a járművezetési módszerek fejlődésével. A biztonságot eleinte a közlekedési szabályok kidolgozásával biztosították. Aztán volt egy útburkolati jelrendszer és a kereszteződések szabályozása. És végül elkezdték építeni a forgalmi csomópontokat, amelyek elvileg megakadályozzák az autók és a gyalogosok forgalmának kereszteződését. Az alkalmazott eszközöket azonban a megoldandó probléma természete alapján kell meghatározni: országút esetén elég egy egyszerű szabály betartása - "nézzen a lába alá és körül".
A strukturált programozás alapötlete: a programnak egy hierarchikus fastruktúrában kombinált blokkkészletnek kell lennie, amelyek mindegyikének van egy bemenete és egy kimenete.
Bármely program csak három alapvető blokktípusból építhető fel:
- 1. funkcionális blokk - külön lineáris operátor vagy ezek sorrendje;
- 2. elágazó blokk - Ha
- 3. generalizált hurok – While típusú konstrukció
Lényeges, hogy ezeknek a struktúráknak csak egy bemenete és egy kimenete legyen a vezérlés szempontjából. Így az általánosított operátornak is csak egy bemenete és egy kimenete van.
A strukturált programozást néha "GO TO nélküli programozásnak" is nevezik. Itt azonban nem a GO TO utasítás a lényeg, hanem annak válogatás nélküli használata. Nagyon gyakran, amikor strukturált programozást hajtanak végre egyes programozási nyelveken, az átmeneti operátort (GO TO) használják strukturális konstrukciók megvalósítására anélkül, hogy csökkentenék a strukturált programozás fő előnyeit. A "nem strukturális" jump utasítások zavarják meg a programot, különösen az ugrás egy utasításra, amely a végrehajtott ugró utasítás felett (korábban) található a modul szövegében. A jump utasítás elkerülésére irányuló kísérlet azonban néhány egyszerű esetben túlságosan nehézkes strukturált programokhoz vezethet, ami nem javítja áttekinthetőségüket, és magában hordozza a további hibák veszélyét a modul szövegében. Ezért ajánlatos lehet kerülni a jump utasítás használatát, ahol csak lehetséges, de nem a program áttekinthetőségének az árán.
Az átmeneti operátor használatának hasznos esetei közé tartozik, hogy egy hurokból vagy eljárásból olyan speciális feltétellel lépünk ki, amely "korán" leállítja ennek a ciklusnak vagy az eljárásnak a munkáját, pl. valamely szerkezeti egység (általánosított üzemeltető) munkájának megszüntetése és ezáltal csak lokálisan sérti a program felépítését. Nagy nehézségeket (és a struktúra bonyolítását) okozza a rendkívüli (gyakran hibás) helyzetekre adott válasz strukturális megvalósítása, hiszen ehhez nem csak a szerkezeti egységből való korai kilépés, hanem ennek a helyzetnek a szükséges feldolgozása is szükséges (pl. , a megfelelő diagnosztikai információk kiadása). A kivételkezelő a programstruktúra bármely szintjén elhelyezhető, és különböző alacsonyabb szintekről érhető el. Technológiai szempontból teljesen elfogadható a rendkívüli helyzetekre adott válasz következő "nem strukturális" megvalósítása. Egy-egy szerkezeti egység végére kivételkezelőket helyeznek el, és minden ilyen kezelőt úgy programoznak, hogy munkája befejeztével kilép abból a szerkezeti egységből, amelynek végére került. Egy ilyen kezelőt az ugrás operátor hív meg az adott szerkezeti egységből (beleértve bármely beágyazott szerkezeti egységet is).
Általánosságban elmondható, hogy a strukturált programozásban a fő dolog a program helyes logikai sémájának hozzáértő összeállítása, amelynek nyelvi úton történő megvalósítása másodlagos kérdés.
8. előadás Szoftver modul fejlesztése
A szoftvermodul fejlesztésének eljárása. Strukturális programozás és lépésről lépésre történő részletezés. A pszeudokód fogalma. Szoftver modul vezérlés.
8.1. A szoftvermodul fejlesztésének eljárása.
Szoftvermodul fejlesztésekor tanácsos a következő sorrendet betartani:
a modul specifikáció tanulmányozása és ellenőrzése, nyelvválasztás
programozás;
algoritmus és adatstruktúra megválasztása;
modul programozás;
a modul szövegének csiszolása;
modul ellenőrzése;
modul összeállítása.
A szoftvermodul fejlesztésének első lépése nagymértékben a program felépítésének alulról történő folyamatos ellenőrzése: a modul specifikációjának tanulmányozásával a fejlesztőnek meg kell győződnie arról, hogy az érthető és elegendő a fejlesztéshez. ezt a modult. Ennek a lépésnek a végén kiválasztásra kerül egy programozási nyelv: bár a programozási nyelv már előre definiálható a teljes PS számára, bizonyos esetekben (ha a programozási rendszer ezt lehetővé teszi) választhat egy másik nyelvet, amely jobban megfelel a megvalósításnak. modul (például assembly nyelv).
A szoftvermodul fejlesztésének második lépésében azt kell kideríteni, hogy ismert-e már valamilyen algoritmus a feltett probléma megoldására, vagy ahhoz közel áll. És ha van megfelelő algoritmus, akkor azt célszerű használni. A megfelelő adatszerkezetek kiválasztása, amelyeket a modul funkcióinak ellátása során alkalmazni fognak, nagymértékben meghatározza a fejlesztés alatt álló modul logikai és minőségi mutatóit, ezért nagyon fontos döntésnek kell tekinteni.
A harmadik lépésben a modul szövege a választott programozási nyelven épül fel. A modulspecifikációban megadott funkciók megvalósítása során figyelembe veendő mindenféle részlet bősége könnyen oda vezethet, hogy egy nagyon zavaros, sok hibát és pontatlanságot tartalmazó szöveg keletkezik. Egy ilyen modulban hibák felkutatása és a szükséges módosítások elvégzése nagyon időigényes feladat lehet. Ezért nagyon fontos, hogy a modul szövegének felépítéséhez technológiailag indokolt és gyakorlatilag bevált programozási tudományágat alkalmazzunk. Dijkstra először hívta fel erre a figyelmet, megfogalmazva és alátámasztva a strukturált programozás alapelveit. A gyakorlatban széles körben használt programozási tudományágak közül sok ezeken az elveken alapul. A legelterjedtebb a drill down tudományág, amelyet részletesen a 8.2 és 8.3 szakasz tárgyal.
A modul fejlesztésének következő lépése a modul szövegének végleges formába hozásához kapcsolódik a PS minőségi előírásnak megfelelően. A modul programozása során a fejlesztő a modul funkcióinak megfelelő megvalósítására összpontosít, a megjegyzéseket befejezetlenül hagyja, és megengedi a program stílusával szemben támasztott követelmények néhány megsértését. Egy modul szövegének csiszolásakor szerkesztenie kell a szövegben található megjegyzéseket, és esetleg további megjegyzéseket is be kell illesztenie a szükséges minőségi primitívek biztosítása érdekében. Ugyanebből a célból a program szövegét a stilisztikai követelményeknek megfelelően szerkesztjük.
A modulellenőrzési lépés a modul belső logikájának manuális ellenőrzése a hibakeresés előtt (számítógépen történő végrehajtással), megvalósítja a tárgyalt programozási technológiára megfogalmazott általános elvet, a programozás egyes szakaszaiban meghozott döntések ellenőrzésének szükségességéről. PS fejlesztés (lásd 3. előadás). A modul érvényesítési módszereit a 8.4. szakasz tárgyalja.
Végül a modul fejlesztésének utolsó lépése a modul érvényesítésének befejezését jelenti (a fordító segítségével), és továbblép a modul hibakeresési folyamatára.
8.2. Strukturális programozás.
A modul programozásánál figyelembe kell venni, hogy a programnak nem csak a számítógép, hanem az ember számára is érthetőnek kell lennie: mind a modulfejlesztő, mind a modult ellenőrző személyek, mind a hibakeresési teszteket készítő szövegírók számára. modult, és a modulon a szükséges módosításokat végrehajtó PS-karbantartóknak ismételten elemezniük kell a modul logikáját. A modern programozási nyelvekben elegendő eszköz van ahhoz, hogy ezt a logikát tetszőlegesen összezavarja, ezáltal a modul nehezen érthetővé válik az ember számára, és ennek következtében megbízhatatlanná vagy nehezen karbantarthatóvá válik. Ezért ügyelni kell a megfelelő nyelvi eszközök kiválasztására és egy bizonyos programozási fegyelem betartására. Dijkstra először hívta fel erre a figyelmet, és javasolta egy program felépítését többféle vezérlési struktúra (struktúra) összetételeként, amely nagymértékben növelheti a program logikájának érthetőségét. A csak ilyen konstrukciókat használó programozást strukturális programozásnak nevezték.
A strukturált programozás fő konstrukciói a következők: követés, elágazás és ismétlés (lásd 8.1. ábra). Ezen konstrukciók összetevői az S, S1, S2 általánosított operátorok (feldolgozó csomópontok) és egy P feltétel (predikátum). Általánosított operátorként a használt programozási nyelv egyszerű operátora is lehet (hozzárendelés, bemenet, kimenet, eljárás). hívások), vagy egy programrészlet , amely a strukturált programozás fő vezérlőstruktúráinak összetétele. Lényeges, hogy ezeknek a struktúráknak csak egy bemenete és egy kimenete legyen a vezérlés szempontjából. Így az általánosított operátornak is csak egy bemenete és egy kimenete van.
Az is nagyon fontos, hogy ezek a konstrukciók már matematikai objektumok (ami lényegében megmagyarázza a strukturált programozás sikerének okát). Bebizonyosodott, hogy minden strukturálatlan programhoz létre lehet hozni egy funkcionálisan egyenértékű (vagyis ugyanazt a problémát megoldó) strukturált programot. A strukturált programok esetében bizonyos tulajdonságok matematikailag igazolhatók, ami lehetővé teszi a program egyes hibáinak észlelését. Ennek a kérdésnek külön előadást fogunk szentelni.
A strukturált programozást néha "GO TO nélküli programozásnak" is nevezik. Itt azonban nem a GO TO utasítás a lényeg, hanem annak válogatás nélküli használata. Nagyon gyakran, amikor strukturált programozást hajtanak végre egyes programozási nyelveken (például FORTRAN-ban), az átmeneti operátort (GO TO) használják a szerkezeti struktúrák megvalósítására anélkül, hogy csökkentenék a strukturált programozás fő előnyeit. A "nem strukturális" jump utasítások zavarják meg a programot, különösen az ugrás egy utasításra, amely a végrehajtott ugró utasítás felett (korábban) található a modul szövegében. A jump utasítás elkerülésére irányuló kísérlet azonban néhány egyszerű esetben túlságosan nehézkes strukturált programokhoz vezethet, ami nem javítja áttekinthetőségüket, és magában hordozza a további hibák veszélyét a modul szövegében. Ezért ajánlatos lehet kerülni a jump utasítás használatát, ahol csak lehetséges, de nem a program áttekinthetőségének az árán.
Az átmeneti operátor használatának hasznos esetei közé tartozik, hogy egy hurokból vagy eljárásból olyan speciális feltétellel lépünk ki, amely "korán" leállítja ennek a ciklusnak vagy az eljárásnak a munkáját, pl. valamely szerkezeti egység (általánosított üzemeltető) munkájának megszüntetése és ezzel csak lokálisan megsértve a program strukturáltságát. Nagy nehézségeket (és a struktúra bonyolítását) okozza a rendkívüli (gyakran hibás) helyzetekre adott válasz strukturális megvalósítása, hiszen ehhez nem csak a szerkezeti egységből való korai kilépés, hanem ennek a helyzetnek a szükséges feldolgozása (kizárása) is szükséges. (például megfelelő diagnosztikai információ kiadása). A kivételkezelő a programstruktúra bármely szintjén elhelyezhető, és különböző alacsonyabb szintekről érhető el. Technológiai szempontból teljesen elfogadható a rendkívüli helyzetekre adott válasz következő "nem strukturális" megvalósítása. Egy-egy szerkezeti egység végére kivételkezelőket helyeznek el, és minden ilyen kezelőt úgy programoznak, hogy munkája befejeztével kilép abból a szerkezeti egységből, amelynek végére került. Egy ilyen kezelőt az ugrás operátor hív meg az adott szerkezeti egységből (beleértve bármely beágyazott szerkezeti egységet is).
8.3. Részletezés lépésről lépésre és a pszeudokód fogalma.
A strukturált programozás javaslatokat tesz arra vonatkozóan, hogy mi legyen egy modul szövege. Felmerül a kérdés, hogyan kell egy programozónak eljárnia egy ilyen szöveg megalkotása érdekében. Néha egy modul programozása a blokkdiagram felépítésével kezdődik, amely általánosságban írja le működésének logikáját. A modern programozási technológia azonban nem javasolja ezt. Bár a folyamatábrák nagyon vizuálisan ábrázolják egy modul logikáját, programozási nyelven kódolva egy nagyon specifikus hibaforrás merül fel: lényegében kétdimenziós struktúrák, például folyamatábrák egy modult reprezentáló lineáris szövegre való leképezését tartalmazzák. a modul logikájának eltorzulásának veszélye, sőt lélektanilag meglehetősen nehéz a magas szintű figyelem fenntartása az újbóli áttekintés során. Kivételt képezhet az az eset, amikor egy grafikus szerkesztőt használnak a folyamatábrák felépítéséhez, és azokat úgy formalizálják, hogy programozási nyelvű szöveg automatikusan generálódik belőlük (mint pl. az R - technológiában).
A modulszöveg felépítésének fő módszereként a modern programozási technológia a lépésről lépésre történő részletezést javasolja. Ennek a módszernek a lényege, hogy a modul szövegének fejlesztési folyamatát több lépésre osztja. Az első lépés leírja általános séma a modul működése látható lineáris szöveges formában (azaz nagyon nagy fogalmakat használva), és ez a leírás nem teljesen formalizált, és az emberi észlelésre összpontosít. Minden következő lépésben az egyik fogalom (nevezzük finomítottnak) finomításra és részletezésre kerül, amelyet (általában nem formalizált) használunk az előző lépések valamelyikében kidolgozott leírásban. Ennek a lépésnek az eredményeként létrejön a finomítás alatt álló kiválasztott fogalom leírása vagy az alapprogramozási nyelv (azaz a reprezentációhoz választott modul) szerint, vagy az első lépésben leírtakkal megegyező formában, új finomítás alatt álló fogalmak segítségével. . Ez a folyamat akkor ér véget, amikor az összes finomított fogalom végül kifejezésre kerül a mögöttes programozási nyelven. Az utolsó lépés a modul szövegének beszerzése az alap programozási nyelven úgy, hogy a finomított fogalmak minden előfordulását lecseréljük a megadott leírásukra, és kifejezzük a strukturált programozási konstrukciók minden előfordulását ezzel a programozási nyelvvel.
A lépésről lépésre történő részletezés magában foglalja egy részben formalizált nyelv használatát az említett leírások megjelenítésére, amelyet pszeudokódnak neveznek. Ez a nyelv lehetővé teszi az összes formalizált strukturált programozási konstrukció, valamint az informális természetes nyelvi töredékek használatát az általános állítások és feltételek megjelenítésére. Az alapprogramozási nyelvben a megfelelő töredékek is megadhatók általánosított operátorként és feltételként.
A pszeudokódban található fejleírás a modul külső kialakításának tekinthető az alap programozási nyelvben, amely
a modul eleje az alapnyelven, azaz. ennek a modulnak az első mondata vagy címsora (specifikációja) ;
leírások szakasza (készlete) az alapnyelven, és az eljárások és funkciók leírása helyett - csak azok külső kialakítása;
a modultörzs utasítások sorozatának informális kijelölése egy általánosított állításként (lásd alább), valamint az egyes eljárások vagy funkcióleírások törzsutasítási sorozatának informális kijelölése egy általánosított állításként;
a modul utolsó mondata (vége) az alapnyelven.
Hasonló módon kerül bemutatásra egy eljárás vagy funkció leírásának külső kialakítása. Dijkstra nyomán azonban érdemesebb itt is informális jelöléssel bemutatni a leírások részét, külön leírásként részletezve.
Az általánosított operátor informális megjelölése a pszeudokódban természetes nyelven egy tetszőleges mondattal történik, amely általánosságban felfedi annak tartalmát. Az ilyen megjelölés kialakításának egyetlen formai követelménye a következő: ennek a mondatnak teljes egészében egy vagy több grafikus (nyomtatott) sort kell elfoglalnia, és ponttal kell végződnie.
Minden informális általánosított operátorhoz külön leírást kell készíteni, amely a strukturált programozás és egyéb általánosított operátorok fő struktúráinak összetételét felhasználva fejezi ki működésének logikáját (tartalmának részletezésével). Az ilyen leírás fejléce a finomítás alatt álló általános operátor informális megnevezése. A strukturált programozás alapvető konstrukcióit a következőképpen ábrázolhatjuk (lásd 8.2. ábra). Itt a feltétel vagy kifejezetten megadható az alapul szolgáló programozási nyelvben logikai kifejezésként, vagy informálisan természetes nyelven reprezentálható valamilyen töredékkel, amely felvázolja ennek a feltételnek a jelentését. Utóbbi esetben ezt a feltételt részletező külön leírást kell készíteni, címként feltüntetve ennek a feltételnek a megjelölését (természetes nyelvű töredék).
Rizs. 8.2. A strukturált programozás alapvető konstrukciói pszeudokódban.
Rizs. 8.3. Az átmeneti operátor, mint általánosított operátor sajátos esetei.
A pszeudokód általánosított operátoraként használhatja az átmeneti operátor fenti speciális eseteit (lásd 8.3. ábra). A kivételkezelők (kivételek) sorrendje egy modul vagy eljárás (funkció) leírásának végén van megadva. Mindegyik ilyen kezelő így néz ki:
EXCEPTION kivétel_neve
generic_operator
MINDEN KIVÉTEL
A kivételkezelő és a paraméter nélküli eljárás közötti különbség a következő: az eljárás végrehajtása után a vezérlés visszatér a hívást követő utasításhoz, a kivétel végrehajtása után pedig a modul hívását követő utasításhoz. vagy eljárás (függvény), amelynek (melynek) végére kerül ez a kivétel.
A részletezés minden lépésénél ajánlatos kellően értelmes, de jól látható (vizuális) leírást készíteni, hogy az egy szövegoldalra kerüljön. Ez általában azt jelenti, hogy egy ilyen leírásnak öt vagy hat strukturált programozási konstrukcióból kell állnia. Az egymásba ágyazott szerkezetek elhelyezése is javasolt több pozícióval jobbra tolva (lásd 8.4. ábra). Ennek eredményeként olyan leírást kaphat a munka logikájáról a láthatóság szempontjából, amely meglehetősen versenyképes a folyamatábrákkal, de jelentős előnye van - a leírás linearitása megmarad.
TÖRLÉS A FÁJL FELVÉTELEKBŐL AZ ELSŐ ELŐTT,
A BEÁLLÍTOTT SZŰRŐHEZ ALKALMAS:
BEÁLLÍTJA A FÁJL ELEJÉT.
HA EGY MÁSIK REKORD MEGLÉV
SZŰRÉS HOGY
TÖRLÉS A FÁJLBÓL MÁSIK FELVÉTELT.
MINDEN HA
VISZLÁT
HA NEM TÖRÖLJÜK A BEVÉTELT, AKKOR
TÍPUSA „NEM TÖRÖLT FELVÉTELEK”.
NYOMTATJA ki az „ELVÁLTOZOTT n RECORDS” elemet.
MINDEN HA
A lépésről lépésre történő részletezés ötletét néha Dijkstrának tulajdonítják. Dijkstra azonban egy alapvetően más módszert javasolt a modulszöveg felépítésére, ami számunkra mélyebbnek és ígéretesebbnek tűnik. Először az operátorok finomításával együtt javasolta a használt adatstruktúrák fokozatos (lépésről lépésre) finomítását (részletezését). Másodszor, minden lépésnél azt javasolta, hogy hozzon létre egy bizonyos virtuális gépet, amely részletezi, és ennek értelmében részletezi mindazokat a finomított koncepciókat, amelyek számára ez a gép lehetővé teszi. Így Dijkstra lényegében a vízszintes rétegek szerinti részletezést javasolta, ami a réteges rendszerekről alkotott elképzelésének (lásd 6. előadás) átvitelét jelenti a modulfejlesztés szintjére. Ezt a modulfejlesztési módszert jelenleg ADA nyelvi csomagok és objektumorientált programozási eszközök támogatják.
8.4. Szoftver modul vezérlés.
A következő programmodul-vezérlési módszereket alkalmazzuk:
a modul szövegének statikus ellenőrzése;
végpontok közötti követés;
a szoftver modul tulajdonságainak igazolása.
A modul szövegének statikus ellenőrzése során ezt a szöveget az elejétől a végéig elolvassa a modul, hogy megtalálja a hibákat a modulban. Általában a modulfejlesztőn kívül még egy vagy akár több programozó is részt vesz egy ilyen ellenőrzésben. Javasoljuk, hogy az ilyen ellenőrzés során észlelt hibákat ne azonnal, hanem a modul szövegének elolvasása után javítsák ki.
A végpontok közötti követés a modul dinamikus vezérlésének egyik fajtája. Több programozó is részt vesz benne, akik manuálisan hurkolják végig a modul végrehajtását (utasításról utasításra a modul logikájából következő sorrendben) egy bizonyos tesztsorozaton.
A következő előadás a programok tulajdonságainak bizonyítására irányul. Itt csak azt kell megjegyezni, hogy ezt a módszert még mindig nagyon ritkán használják.
Irodalom a 8. előadáshoz.
8.2. E. Dijkstra. Megjegyzések a strukturált programozáshoz// W. Dahl, E. Dijkstra, K. Hoor. Strukturális programozás. - M.: Mir, 1975. - S. 24-97.
8.3. N. Wirth. Szisztematikus programozás. - M.: Mir, 1977. - S. 94-164.
9. előadás
A programindoklás fogalma. Programtulajdonságok formalizálása, Hoor-hármas. Hozzárendelési operátor, feltételes operátor és összetett operátor tulajdonságainak beállítására vonatkozó szabályok. A hurokoperátor tulajdonságainak megállapításának szabályai, a ciklusinvariáns fogalma. A program végrehajtásának befejezése.
9.1. A program indoklása. A program tulajdonságainak formalizálása.
A szoftverek megbízhatóságának javítása érdekében nagyon hasznos a programokat további információkkal ellátni, amelyek segítségével jelentősen növelheti a szoftver vezérlési szintjét. Az ilyen információk megadhatók informális vagy formalizált nyilatkozatok formájában, amelyek különféle programrészletekhez kötődnek. Az ilyen állításokat programindoklásnak nevezzük. A programok nem formalizált indoklása magyarázhatja például az egyes döntések meghozatalának indítékait, ami nagyban megkönnyítheti a hibák felkutatását, kijavítását, valamint a programok tanulmányozását azok karbantartása során. A formalizált indoklás lehetővé teszi a programok egyes tulajdonságainak manuális bizonyítását és automatikus vezérlését (beállítását).
A programok formális indoklásának egyik jelenleg használt fogalma az úgynevezett Hoor-hármasok használata. Legyen S valamilyen általánosított operátor az IS információs környezet felett, P és Q - néhány predikátum (állítás) ezen a környezeten. Ekkor a (P)S(Q) jelölést Hoor triádnak nevezzük, amelyben a P predikátumot előfeltételnek, a Q predikátumot pedig utófeltételnek nevezzük az S operátorhoz képest. Az operátor (különösen a program) Azt mondjuk, hogy S rendelkezik a (P)S(Q) tulajdonsággal, ha valahányszor P predikátum igaz az S végrehajtása előtt, akkor a Q predikátum igaz az S végrehajtása után.
Egyszerű példák a program tulajdonságaira:
(9.1) (n=0) n:=n+1 (n=1),
(9.2) (n
(9.3) (n
(9,4) (n>0) p:=1; m:=1;
WHILE m /= n DO
VISZLÁT
Az S program tulajdonságának bizonyítására a programozási nyelv egyszerű operátorainak tulajdonságait használjuk (itt az üres operátorra és a hozzárendelési operátorra szorítkozunk), valamint azon vezérlőstruktúrák (összetételek) tulajdonságait, amelyekből a program épül. egyszerű operátorok (itt a strukturált programozás három fő összetételére szorítkozunk, lásd 8. előadás). Ezeket a tulajdonságokat általában programellenőrzési szabályoknak nevezik.
9.2. Egyszerű operátorok tulajdonságai.
Üres operátor esetén
9.1. Tétel. Legyen P az információs környezet predikátuma. Ekkor a (P)(P) tulajdonság teljesül.
Ennek a tételnek a bizonyítása kézenfekvő: az üres operátor nem változtatja meg az információs környezet állapotát (szemantikája szerint), így előfeltétele a végrehajtás után is fennáll.
A megbízás operátora számára
9.2. Tétel. Az IS információs környezet álljon az X változóból és az információs környezet RIS többi részéből:
Aztán az ingatlan
(Q(F(X, RIS), RIS)) X:= F(X, RIS) (Q(X, RIS)) ,
ahol F(X, RIS) egy egyértékű függvény, Q egy predikátum.
Bizonyíték. Legyen igaz a Q(F(X0, RIS0), RIS0) predikátum a hozzárendelési operátor végrehajtása előtt, ahol (X0, RIS0) az információs környezet IS tetszőleges állapota, majd a hozzárendelési operátor végrehajtása után a predikátum Q(X, RIS) igaz lesz, tehát az, hogy X hogyan kapja meg az F(X0, RIS0) értéket és a RIS állapotát nem változtatja meg az adott hozzárendelési utasítás, így ebben az esetben a hozzárendelési utasítás végrehajtása után sem.
Q(X, RIS)=Q(F(X0, RIS0), RIS0).
Az információs környezet állapotának megválasztásának önkényességéből adódóan a tétel bizonyítást nyer.
Példa egy hozzárendelési operátor tulajdonságára a 9.1. példa.
9.3. A strukturális programozás alapstruktúráinak tulajdonságai.
Tekintsük most a strukturált programozás fő struktúráinak tulajdonságait: követés, elágazás és ismétlés.
Az egymásutániság tulajdonságait a következők fejezik ki
9.3. Tétel. Legyenek P, Q és R predikátumok az információs környezet felett, S1 és S2 pedig általánosított operátorok, amelyeknek a tulajdonságai rendre
(P)S(Q) és (Q)S2(R).
Aztán az összetett operátornak
S1; S2<.blockquote>
ingatlan van
(P) S1; S2(R) .
Bizonyíték. Legyen igaz a P predikátum az információs környezet valamely állapotára az S1 operátor végrehajtása előtt, majd az S1 operátor tulajdonsága alapján a végrehajtása után a Q predikátum igaz lesz az S2 operátor végrehajtásával. Következésképpen az S2 operátor végrehajtása után a tulajdonságánál fogva az R predikátum igaz lesz, és mivel az S2 operátor befejezi az összetett utasítás végrehajtását (szemantikája szerint), az R predikátum igaz lesz azután. ennek az összetett állításnak a végrehajtása, amit bizonyítani kellett.
Például, ha a (9.2) és (9.3) tulajdonság teljesül, akkor
hely és ingatlan
(n
Az elágazási tulajdonságot a következő fejezi ki
9.4. Tétel. Legyenek P, Q és R predikátumok az információs környezet felett, S1 és S2 pedig általánosított operátorok, amelyeknek a tulajdonságai rendre
(P,Q)S1(R) és (`P,Q)S2(R).
Aztán a feltételes operátornak
HA P, akkor S1 EGYÉB S2 MINDEN HA
ingatlan van
(Q) HA P AKKOR S1 MÁS S2 MINDEN HA (R) .
Bizonyíték. Legyen igaz a Q predikátum az információs környezet valamely állapotára a feltételes operátor végrehajtása előtt Ha a P predikátum is igaz, akkor a feltételes operátor szemantikája szerinti végrehajtása az S1 operátor végrehajtására redukálódik. . Az S1 operátor tulajdonsága miatt a végrehajtása után (és ebben az esetben a feltételes operátor végrehajtása után) az R predikátum igaz lesz. Ha azonban a feltételes operátor végrehajtása előtt a P predikátum ha hamis (és Q továbbra is igaz), akkor a feltételes operátor szemantikája szerinti végrehajtása az S2 operátor végrehajtására redukálódik. Az S2 operátor tulajdonsága folytán a végrehajtása után (és ebben az esetben a feltételes operátor végrehajtása után) az R predikátum igaz lesz, így a tétel teljes mértékben bizonyítást nyer.
Mielőtt rátérnénk az ismétlési konstrukció tulajdonságaira, meg kell jegyezni, hogy hasznos a továbbiakhoz
9.5. Tétel. Legyenek P, Q, P1 és Q1 predikátumok azon információs környezet felett, amelyre az implikációk vonatkoznak
P1=>P és Q=>Q1,
és hagyjuk érvényesülni a (P)S(Q) tulajdonságot az S operátorra. Ekkor a (P1)S(Q1) tulajdonság teljesül.
Ezt a tételt gyengítő tulajdonságtételnek is nevezik.
Bizonyíték. Legyen igaz a P1 predikátum az információs környezet valamely állapotára az S operátor végrehajtása előtt. Ekkor a P predikátum is igaz lesz (a P1=>P implikáció miatt). Következésképpen az S operátor tulajdonságánál fogva a végrehajtása után a Q predikátum igaz lesz, és így a Q1 predikátum (a Q=>Q1 implikáció miatt). Így a tétel bizonyítást nyer.
Az ismétlési tulajdonságot a következő fejezi ki
9.6. Tétel. Legyenek I, P, Q és R predikátumok azon információs környezet felett, amelyre az implikációk vonatkoznak
P=>I és (I,`Q)=>R ,
és legyen S általánosított operátor (I)S(I) tulajdonsággal.
Aztán a hurok operátornak
BYE Q DO S ALL BYE
ingatlan van
(P) BYE Q DO S ALL BYE (R) .
Az I predikátumot a hurokoperátor invariánsának nevezzük.
Bizonyíték. Ennek a tételnek a bizonyításához elegendő a tulajdonság bizonyítása
(I) BYE Q DO S ALL YE (I,`Q)
(a 9.5. Tétel alapján, a tétel feltételeiben szereplő implikációk alapján). Legyen igaz az I predikátum az információs környezet valamely állapotára a ciklus operátor végrehajtása előtt. Ha ebben az esetben a Q predikátum hamis, akkor a ciklus operátor ekvivalens egy üres operátorral (szemantikája szerint) és a 9.1. Tétel értelmében a ciklus operátor végrehajtása után az (I ,`Q) utasítást. Ha a Q predikátum igaz a ciklusoperátor végrehajtása előtt, akkor a ciklusoperátor a szemantikája szerint összetett S operátorként ábrázolható; BYE Q DO S ALL BYE
Az S operátor tulajdonsága folytán a végrehajtása után az I predikátum igaz lesz, és a ciklusoperátor tulajdonságának bizonyításához a kiindulási helyzet adódik: az I predikátum igaz a ciklusoperátor végrehajtása előtt, de az információs környezet eltérő (megváltozott) állapota (amelyre a Q predikátum igaz vagy hamis lehet). Ha a ciklusutasítás végrehajtása véget ér, akkor a matematikai indukció módszerét alkalmazva, véges számú lépésben olyan helyzethez jutunk, hogy az (I,`Q) utasítás a végrehajtása előtt igaz lesz. És ebben az esetben, mint fentebb bebizonyosodott, ez az állítás a ciklus utasítás végrehajtása után is igaz lesz. A tétel bizonyítást nyert.
Például a (9.4) példa hurokoperátoránál a tulajdonság megtörténik
m: = m+1; p:= p*p
MÉG MINDEN (p=n.!}
Ez a 9.6. Tételből következik, mivel ennek a hurokoperátornak az invariánsa a p=m predikátum! és az implikációk (n>0, p=1, m=1) => p=m! és (p=m!, m=n) => p=n!
9.4. A program végrehajtásának befejezése.
Az egyik programtulajdonság, ami érdekelhet bennünket a PS esetleges hibáinak elkerülése érdekében, a leállása, pl. a kerékpározás hiánya benne bizonyos kezdeti adatokhoz. Az általunk vizsgált strukturált programokban csak az ismétlési konstrukció lehet a ciklus forrása. Ezért egy program befejezésének bizonyításához elegendő egy hurokoperátor befejezését bizonyítani. Ehhez hasznosak a következők.
9.7. Tétel. Legyen F egész függvény, amely az információs környezet állapotától függ, és teljesíti a következő feltételeket:
(1) ha a Q predikátum igaz az információs környezet adott állapotára, akkor értéke pozitív;
(2) csökken, ha az információs környezet állapota az S operátor végrehajtása következtében megváltozik.
Ezután a ciklus utasítás végrehajtása
A WHILE Q DO S EVERYthing WHILE befejeződik.
Bizonyíték. Legyen az információs környezet állapota a ciklus utasítás végrehajtása előtt, és legyen F(is)=k. Ha a Q(is) predikátum hamis, akkor a ciklusutasítás végrehajtása véget ér. Ha Q(is) igaz, akkor a k>0 tétel feltételezésével. Ebben az esetben az S utasítás egy vagy több alkalommal végrehajtásra kerül. Az S operátor minden egyes végrehajtása után a tétel feltételének megfelelően az F függvény értéke csökken, és mivel az S operátor végrehajtása előtt a Q predikátumnak igaznak kell lennie (a ciklusoperátor szemantikája szerint) , az F függvény értékének ebben a pillanatban pozitívnak kell lennie (a tétel feltételének megfelelően). Ezért az F függvény integritása miatt az S operátor ebben a ciklusban k-nál többször végrehajtható. A tétel bizonyítást nyert.
Például a fent vizsgált ciklusoperátor példájára a 9.7. Tétel feltételeit az f(n, m)= n-m függvény teljesíti. Mivel az m=1 ciklusutasítás végrehajtása előtt ennek a ciklusnak a törzse (n-1) alkalommal kerül végrehajtásra, azaz. ez a ciklusutasítás véget ér.
9.5. Példa egy programtulajdonság-bizonyításra.
A programellenőrzés bevált szabályai alapján a hozzárendelési utasításokból és üres utasításokból álló programok tulajdonságai igazolhatók a strukturált programozás három alapvető összetételével. Ehhez a program felépítését elemezve, annak elő- és utófeltételeit felhasználva az elemzés minden lépésénél megfelelő ellenőrzési szabályt kell alkalmazni. Ismétléses kompozíció esetén megfelelő ciklusinvariánst kell választani.
Példaként bizonyítsuk be a (9.4) tulajdonságot. Ez a bizonyítás a következő lépésekből áll majd.
(1. lépés). n>0 => (n>0, p - tetszőleges, m - tetszőleges).
(2. lépés). Bekövetkezik
(n>0, p - tetszőleges, m - bármilyen) p:=1 (n>0, p = 1, m - tetszőleges).
A 9.2 tétel szerint.
(3. lépés). Bekövetkezik
(n>0, p=1, m - bármely) m:=1 (n>0, p=1, m=1).
A 9.2 tétel szerint.
(4. lépés). Bekövetkezik
(n>0, p - tetszőleges, m - tetszőleges) p:=1; m:=1 (n>0, p=1, m=1).
A 9.3. Tétel szerint, a 2. és 3. lépés eredményei miatt.
Bizonyítsuk be, hogy a p=m predikátum! egy ciklusinvariáns, azaz. (p=m m:=m+1; p:=p*m {p=m!}.!}
(5. lépés). Megtörténik (p=m m:=m+1 {p=(m-1)!}.!}
A 9.2. Tétel szerint, ha az előfeltételt a (p=((m+1)-1) formában ábrázoljuk.!}
(6. lépés). Megtörténik (p=(m-1) p:=p*m {p=m!}.!}
A 9.2. Tétel szerint, ha az előfeltételt a (p*m=m) formában ábrázoljuk.!}
(7. lépés). Van egy invariáns ciklus
(p=m m:=m+1; p:=p*m {p=m!}.!}
A 9.3 Tétel szerint, az 5. és 6. lépés eredményei miatt.
(8. lépés). Bekövetkezik
(n>0, p=1, m=1) MIközben m /= n DO
m: = m+1; p:= p*p
MÉG MINDEN (p=n.!}
A 9.6. Tétel szerint, a 7. lépés eredménye alapján, és szem előtt tartva, hogy (n>0, p=1, m= 1)=>p=m!; (p=m!, m=n)=>p=n!.
(9. lépés). Bekövetkezik
(n>0, p - tetszőleges, m - tetszőleges) p:=1; m:=1;
WHILE m /= n DO
m: = m+1; p:= p*p
MÉG MINDEN (p=n.!}
A 9.3 Tétel szerint, a 3. és 8. lépés eredményei miatt.
(10. lépés). A (9.4) tulajdonság a 9.5. Tétel szerint az 1. és 9. lépés eredményei miatt teljesül.
Irodalom a 9. előadáshoz.
9.1. S.A. Abramov. A programozás elemei. - M.: Nauka, 1982. S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. A szoftverfejlesztés alapelvei. - M.: Mir, 1982. S. 98-105.
10. előadás
Alapfogalmak. Teszttervezési stratégia. Hibakeresési parancsok. Szoftvermodulok offline hibakeresése és tesztelése. A szoftverek átfogó hibakeresése és tesztelése.
10.1. Alapfogalmak.
A PS hibakeresése egy olyan tevékenység, amelynek célja a PS hibáinak észlelése és kijavítása a programok végrehajtási folyamatai segítségével. A PS tesztelés az a folyamat, amikor programjait egy bizonyos adathalmazon futtatják, amelyre az alkalmazás eredménye előre ismert, vagy ismertek e programok viselkedésének szabályai. A megadott adatkészletet tesztnek vagy csak tesztnek nevezzük. Így a hibakeresés három folyamat ismételt megismétléseként ábrázolható: tesztelés, melynek eredményeként megállapítható a hiba megléte a PS-ben, a hiba helyének keresése a PS programjaiban és dokumentációjában, ill. programok és dokumentáció szerkesztése az észlelt hiba kiküszöbölése érdekében. Más szavakkal:
Hibakeresés = Tesztelés + Hibák keresése + Szerkesztés.
A külföldi szakirodalomban a hibakeresésen gyakran csak a hibák megtalálásának és kijavításának (tesztelés nélküli) folyamatát értik, amelyek meglétét a tesztelés során állapítják meg. Néha a tesztelést és a hibakeresést szinonimának tekintik. Hazánkban a hibakeresés fogalmába általában a tesztelés is beletartozik, így a kialakult hagyományt követjük. Ezeknek a folyamatoknak az előadásban való együttes figyelembevétele azonban a jelzett eltérést nem annyira jelentőssé teszi. Meg kell azonban jegyezni, hogy a tesztelést a PS tanúsítási folyamat részeként is használják (lásd a 14. előadást).
10.2. A hibakeresés elvei és típusai.
A hibakeresés sikerét nagymértékben meghatározza a tesztelés racionális megszervezése. A hibakeresés során elsősorban azokat a hibákat találják meg és szüntetik meg, amelyek jelenléte a PS-ben a tesztelés során állapítható meg. Amint már említettük, a tesztelés nem tudja bizonyítani a PS helyességét, legjobb esetben is kimutathatja a hiba jelenlétét. Más szóval, nem garantálható, hogy a szoftvert egy gyakorlatilag megvalósítható tesztkészlettel tesztelve minden, a szoftverben előforduló hiba megléte megállapítható legyen. Ezért két probléma merül fel. Először készítsen elő egy ilyen tesztkészletet, és alkalmazzon rájuk PS-t, hogy a lehető legtöbb hibát észlelje. Azonban minél tovább tart a tesztelési folyamat (és általában a hibakeresés), annál nagyobb lesz a szoftver költsége. Ezért a második feladat: meghatározni azt a pillanatot, amikor a PS (vagy egyes összetevői) hibakeresése befejeződik. A hibakeresés megszűnésének jele, hogy a PS-n átmenő tesztek (vagyis azok a tesztek, amelyekre a PS-t alkalmazzák) teljes körű lefedettsége a PS-programok végrehajtása során felmerülő számos különböző helyzetnek, és a a tesztfolyamat utolsó szakaszában a PS hibáinak viszonylag ritka megnyilvánulása. Ez utóbbit a PS megkívánt megbízhatósági fokának megfelelően határozzák meg, a minőségi specifikációban meghatározott.
A tesztcsomag optimalizálásához, pl. egy olyan tesztsorozat elkészítéséhez, amely adott számú (vagy a tesztelésre szánt időintervallumban) nagyobb számú hiba észlelését teszi lehetővé, először is előre meg kell tervezni ezt a készletet, másodsorban , racionális tervezési stratégia (tervezési) tesztek használatához. A próbatervezés a szakasz befejezése után azonnal megkezdődhet külső leírás PS. Különböző megközelítések léteznek egy teszttervezési stratégia kidolgozására, amely feltételesen elhelyezhető grafikusan (lásd 9.1. ábra) a következő két szélső megközelítés között. A bal szélső megközelítés az, hogy a teszteket csak a PS specifikációk (külső leírás, architektúra leírás és modulspecifikáció) tanulmányozása alapján tervezzük. A modulok felépítését semmilyen módon nem veszik figyelembe, pl. fekete dobozként kezelik őket. Valójában ez a megközelítés megköveteli az összes bemeneti adatkészlet teljes felsorolását, mivel ha ezeknek a készleteknek csak egy részét használjuk tesztként, előfordulhat, hogy a PS programok egyes részei nem működnek egyetlen teszten sem, ezért a bennük lévő hibák nem fognak működni. megjelenik. A PS tesztelése azonban teljes bemeneti adatkészlettel gyakorlatilag lehetetlen. A helyes szélsőséges megközelítés az, hogy a teszteket a programszöveg tanulmányozása alapján tervezik, hogy teszteljék az egyes PS-programok végrehajtásának összes módját. Ha figyelembe vesszük a változó ismétlésszámú ciklusok jelenlétét a programokban, akkor a PS programok végrehajtásának is rendkívül sok különböző módja lehet, így ezek tesztelése is gyakorlatilag lehetetlenné válik.
Az optimális teszttervezési stratégia ezen szélsőséges megközelítések közötti intervallumon belül, de közelebb a bal oldalhoz található. Ez magában foglalja a tesztek jelentős részének specifikáció szerinti tervezését, a következő elvek alapján: minden használt funkcióhoz vagy szolgáltatáshoz - legalább egy teszt, minden területhez és bármely bemeneti változó változásának minden határához - legalább egy teszt, mindegyikhez speciális eset vagy az előírásokban meghatározott kivételek esetén - legalább egy teszt. De ehhez bizonyos tesztek és programszövegek megtervezése is szükséges, az elv alapján (legalább): minden PS program minden parancsának legalább egy teszten működnie kell.
Az optimális teszttervezési stratégia a következő elv alapján határozható meg: minden programdokumentumhoz (beleértve programszövegeket), amely a PS részét képezi, saját teszteket kell készítenie a benne lévő hibák azonosítása érdekében. Ezt az elvet mindenesetre be kell tartani a szoftver definíciójával és a programozási technológia, mint megbízható szoftverfejlesztési technológia fogalmának tartalmával összhangban (lásd 1. előadás). Ezzel kapcsolatban Myers még különböző tesztelési típusokat is meghatároz, attól függően, hogy milyen programdokumentum alapján készülnek a tesztek. Hazánkban a hibakeresésnek (beleértve a tesztelést is) két fő típusa van: az önálló és az összetett hibakeresés. Az offline hibakeresés a PS-ben szereplő programnak csak egy részének tesztelését jelenti, a tesztelés során rögzített hibák keresésével és javításával. Valójában magában foglalja az egyes modulok hibakeresését és a modul párosításának hibakeresését. Az átfogó hibakeresés a PS egészének tesztelését jelenti a tesztelés során rögzített hibák felkutatásával és kijavításával a PS egészére vonatkozó összes dokumentumban (beleértve a PS programok szövegeit is). Ilyen dokumentumok közé tartozik a PS követelményeinek meghatározása, a PS minőségi specifikációja, a PS funkcionális specifikációja, a PS architektúra leírása és a PS programok szövegei.
10.3. Hibakeresési parancsok.
Ez a rész általános irányelveket ad a hibakeresés megszervezéséhez. De először is meg kell jegyezni egy jelenséget, amely megerősíti a hibamegelőzés fontosságát a fejlesztés korábbi szakaszaiban: ahogy a szoftverben feltárt és kijavított hibák száma nő, úgy nő a felderítetlen hibák előfordulásának relatív valószínűsége is. Ez azzal magyarázható, hogy a PS-ben feltárt hibák számának növekedésével az abban elkövetett hibák teljes számáról, és ezáltal bizonyos mértékig a még fel nem fedezett hibák számáról is finomodik. Ez a jelenség megerősíti a hibák korai felismerésének fontosságát és a szoftverfejlesztés minden szakaszában meghozott döntések gondos ellenőrzésének szükségességét.
Parancs 1. Tekintse a tesztelést a szoftverfejlesztés kulcsfeladatának, bízza a legképzettebb és legtehetségesebb programozókra; nem kívánatos a saját program tesztelése.
2. parancsolat. Jó teszt az, amelyikben nagy a valószínűsége annak, hogy hibát talál, nem pedig az, amely a program helyes működését mutatja be.
3. parancsolat. Készítsen teszteket mind a helyes, mind a helytelen adatokra!
4. parancsolat. Kerülje a nem reprodukálható teszteket, dokumentálja azok áthaladását a számítógépen; részletesen tanulmányozza az egyes tesztek eredményeit.
5. parancs. Minden modult csak egyszer csatlakoztasson a programhoz; soha ne módosítson egy programot a tesztelés megkönnyítése érdekében.
6. parancs. Hagyja át a PS-programok működésének vagy más programokkal való interakciójának ellenőrzésével kapcsolatos összes tesztet, ha változtatásokat hajtottak végre rajta (például egy hibajavítás eredményeként).
10.4. Offline modul hibakeresés.
Az offline hibakeresés során minden modult ténylegesen tesztelnek valamilyen programozási környezetben, kivéve, ha a hibakeresés alatt álló program csak egy modulból áll. Ez a környezet más modulokból áll, amelyek egy része a hibakeresés alatt álló program modulja, amelyek már hibakeresésre kerültek, és vannak olyan modulok, amelyek a hibakeresést vezérlik (hibakereső modulok, lásd alább). Így az offline hibakeresés során mindig tesztelnek valamilyen programot, amely kifejezetten a hibakeresés alatt álló modul tesztelésére készült. Ez a program csak részben egyezik a hibakeresés alatt álló programmal, kivéve, ha a hibakeresés alatt álló program utolsó moduljának hibakeresése folyik. A program hibakeresésének előrehaladtával a következő hibakereső modul környezetének egyre nagyobb része ennek a programnak már hibakeresett modulja lesz, és a program utolsó moduljának hibakeresése során a hibakeresés alatt álló modul környezete teljes egészében a hibakereső program összes többi (már debuggolt) modulja (mindenféle) hibakereső modul.modulok, pl. ebben az esetben magát a hibakereső programot teszteljük. Ezt a folyamatot, amelyben egy hibakereső program felépítése történik hibakereső és hibakereső modulokkal, programintegrációnak nevezzük.
A hibakereső modul környezetében található hibakereső modulok attól függnek, hogy milyen sorrendben történik az adott program moduljainak hibakeresése, melyik modul hibakeresése folyik, és esetleg melyik teszt kerül kihagyásra.
Az alulról felfelé irányuló tesztelésnél (lásd a 7. fejezetet) ez a környezet mindig csak egy hibakereső modult tartalmaz (kivéve, ha a hibakeresés alatt álló program utolsó modulja hibakeresés alatt áll), amely a tesztelés alatt álló program feje lesz, és amely ún. a mester (vagy sofőr). A vezető hibakereső modul előkészíti az információs környezetet a hibakeresés alatt álló modul teszteléséhez (azaz kialakítja ennek a modulnak a teszteléséhez szükséges állapotát, különösen tud bizonyos tesztadatokat bevinni), meghívja a hibakeresés alatt álló modult, majd a munka után elkészült, kiadja a szükséges üzeneteket. Egy modul hibakeresése során különböző fő hibakeresési modulok fordíthatók különböző tesztekhez.
A lefelé irányuló tesztelés során (lásd a 7. fejezetet) a hibakereső modul környezete hibakereső modulként tartalmazza az összes olyan modul szimulátorait, amelyekhez a hibakereső modul hozzá tud férni, valamint azoknak a moduloknak a szimulátorait, amelyekhez a hibakereső hozzáférhet. a hibakeresés alatt álló program moduljai (ebbe a környezetbe beletartoznak), de még nem lettek hibakeresve. Ezen szimulátorok némelyike módosulhat a különböző tesztekhez egy modul hibakeresése során.
Valójában a hibakereső modul környezete sok esetben mindkét típusú hibakereső modult tartalmazhat a következő okok miatt. Mind a felfelé, mind a lefelé irányuló tesztelésnek megvannak a maga előnyei és hátrányai.
Az alulról felfelé irányuló tesztelés előnyei közé tartozik
a tesztek elkészítésének egyszerűsége és
a modul teszttervének maradéktalan megvalósításának képessége.
Ez annak köszönhető, hogy az információs környezet tesztállapota közvetlenül a hibakeresés alatt álló modul (leading debugging modul) hívása előtt készül el. Az alulról felfelé irányuló tesztelés hátrányai a következők:
a tesztadatokat általában nem a felhasználó számára kialakított formában készítik el (kivéve, ha a hibakeresés alatt álló program utolsó, feje, modulja hibakeresésre kerül);
nagy mennyiségű hibakereső programozás (egy modul hibakeresésekor gyakran sok vezető hibakereső modult kell összeállítani a különböző tesztekhez);
az interfészmodulok speciális tesztelésének szükségessége.
A felülről lefelé irányuló tesztelés előnyei a következő funkciókat tartalmazzák:
a legtöbb teszt a felhasználó számára kialakított formában készül;
sok esetben viszonylag kis mennyiségű hibakeresési programozás (a modulszimulátorok általában nagyon egyszerűek, és mindegyik alkalmas nagy számú, gyakran minden tesztre);
nincs szükség a modulok párosításának tesztelésére.
A felülről lefelé irányuló tesztelés hátránya, hogy az információs környezet tesztállapota a hibakeresés alatt álló modul elérése előtt közvetett módon készül el - ez a már hibakeresett modulok tesztelési vagy szimulátorok által kiadott adatok alkalmazása eredménye. Ez egyrészt megnehezíti a tesztek elkészítését, magasan képzett tesztvégrehajtót igényel, másrészt megnehezíti vagy akár lehetetlenné teszi a hibakeresés alatt álló modul teljes teszttervének megvalósítását. Ez a hiányosság néha arra kényszeríti a fejlesztőket, hogy felülről lefelé irányuló fejlesztés esetén is alulról építkező tesztelést alkalmazzanak. Gyakrabban azonban a felülről lefelé irányuló tesztelés bizonyos módosításait, vagy a felülről lefelé és alulról felfelé irányuló tesztelés valamilyen kombinációját alkalmazzák.
Abból a tényből kiindulva, hogy a felülről lefelé irányuló tesztelés elvileg előnyösebb, térjünk ki azokra a technikákra, amelyek lehetővé teszik, hogy bizonyos mértékig leküzdjük ezeket a nehézségeket. Először is úgy kell megszervezni a program hibakeresését, hogy az adatbevitelt végző modulok mihamarabb hibakeresésre kerüljenek - ekkor a tesztadatok a felhasználó számára kialakított formában elkészíthetők, ami nagymértékben egyszerűsítse a későbbi vizsgálatok előkészítését. Ez a bevitel semmi esetre sem mindig a fejmodulban történik, ezért először a megadott bemenetet végrehajtó modulokhoz vezető modulláncokat kell debugolni (vö. a 7. előadásban a célirányos konstruktív megvalósítás módszerével). A bemeneti modulok hibakereséséig egyes szimulátorok tesztadatokat szolgáltatnak: vagy annak részeként bekerülnek a szimulátorba, vagy ez a szimulátor adja meg.
A felülről lefelé irányuló tesztelés során előfordulhat, hogy bizonyos információs környezeti állapotok, amelyekben a hibakeresés alatt álló modult tesztelni kell, nem fordulnak elő a hibakeresés alatt álló program végrehajtása során egyetlen bemenet esetében sem. Ezekben az esetekben lehetőség lenne egyáltalán nem tesztelni a hibakereső modult, mivel az ebben az esetben talált hibák nem jelennek meg, amikor a hibakereső program lefut semmilyen bemeneti adat alatt. Ezt azonban nem ajánlatos megtenni, mivel a hibakereső program megváltozásakor (például a PS karbantartásakor) előfordulhat, hogy az információs környezet olyan állapotai, amelyeket nem használtak a hibakereső modul tesztelésére, már felléphetnek, ami további igényeket igényel. ennek a modulnak a tesztelése (és ez a hibakeresés racionális megszervezésével nem végezhető el, ha maga a modul nem változott). A hibakeresés alatt álló modul ilyen helyzetekben történő tesztelésére időnként megfelelő szimulátorokat használnak az információs környezet kívánt állapotának létrehozására. Gyakrabban a felülről lefelé irányuló tesztelés egy módosított változatát alkalmazzák, amelyben a hibakereső modulokat külön előzetesen tesztelik az integrálás előtt (ebben az esetben a hibakereső modul környezetében megjelenik egy vezető hibakereső modul a modullal együtt szimulátorok, amelyekhez a hibakeresés alatt álló modul hozzáférhet). A felülről lefelé irányuló tesztelés egy másik módosítása azonban megfelelőbbnek tűnik: miután a hibakeresés alatt álló modul felülről lefelé irányuló tesztelése befejeződött az információs környezet elérhető tesztállapotaira vonatkozóan, külön kell tesztelni az információ többi szükséges állapotára. környezet.
Gyakran alulról felfelé és alulról felfelé irányuló tesztelés kombinációját is alkalmazzák, amelyet szendvicsmódszernek neveznek. Ennek a módszernek a lényege a felfelé és lefelé irányuló tesztelés egyidejű végrehajtása mindaddig, amíg ez a két tesztelési folyamat össze nem találkozik valamelyik modulon, valahol a hibakereső program szerkezetének közepén. Ez a módszer ésszerű megközelítéssel lehetővé teszi mind az alulról felfelé, mind a felülről lefelé irányuló tesztelés előnyeinek kihasználását, és nagymértékben semlegesíteni azok hiányosságait. Ez a hatás egy általánosabb elv megnyilvánulása: a legnagyobb technológiai hatást a COP programozás felülről lefelé és alulról felfelé irányuló módszereinek kombinálásával érhetjük el. Ennek a módszernek a támogatására irányul a szoftverfejlesztés architekturális megközelítése (lásd 7. előadás): a jól megtervezett és gondosan tesztelt modulokból álló réteg nagyban megkönnyíti a megfelelő tantárgyi területen egy programcsalád megvalósítását, majd azok korszerűsítését.
Az offline hibakeresésben nagyon fontos a modulpárosítás tesztelése. A helyzet az, hogy az egyes programmodulok specifikációit, kivéve a fejet, két helyzetben használják ebben a programban: először is a modul szövegének (néha azt mondják: törzsének) kidolgozásakor, másodszor pedig egy hivatkozzon erre a modulra más programmodulokban. Mindkét esetben egy hiba következtében megsérülhet az adott modul specifikációnak való megfelelés. Az ilyen hibákat fel kell ismerni és ki kell javítani. Ez a célja a modulok párosításának tesztelésének. A felülről lefelé irányuló tesztelés során minden egyes kihagyott teszttel együtt párosítási tesztelést hajtanak végre, ami a felülről lefelé irányuló tesztelés legerősebb előnyének tekinthető. Az alulról felfelé irányuló tesztelés során a hibakereső modul nem a hibakereső program moduljaiból, hanem a vezető hibakereső modulból érhető el. Ebben a tekintetben fennáll annak a veszélye, hogy az utolsó modul alkalmazkodni tud a hibakeresés alatt álló modul néhány "tévhitéhez". Ezért egy új modul hibakeresésének indításakor (a programintegráció folyamatában) minden egyes korábban hibakeresett modul hívását tesztelni kell, hogy feltárjuk a hívás és a megfelelő modul törzse közötti inkonzisztenciákat (és lehetséges, hogy a korábban debuggolt modul okolható ezért). Így egy korábban debuggolt modul tesztelését részben meg kell ismételni új körülmények között, és ugyanazok a nehézségek merülnek fel, mint a felülről lefelé történő tesztelésnél.
A modul autonóm tesztelését négy egymást követő lépésben kell elvégezni.
1. lépés: A hibakereső modul specifikációi alapján készítsen tesztet minden lehetőségre és helyzetre, az összes bemenet tartományának minden határára, minden adatváltozási tartományra, az összes bemenet minden érvénytelen tartományára, érvénytelen állapot.
2. lépés: Ellenőrizze a modul szövegét, hogy megbizonyosodjon arról, hogy bármely ág minden iránya megfelel legalább egy tesztnek. Adja hozzá a hiányzó teszteket.
3. lépés: Ellenőrizze a modulszövegből, hogy minden ciklushoz van-e egy teszt, amelyhez a huroktörzs nem kerül végrehajtásra, egy teszt, amelyhez a ciklustörzs egyszer kerül végrehajtásra, és egy teszt, amelyhez a ciklustest a maximális számú alkalommal. Adja hozzá a hiányzó teszteket.
4. lépés: Ellenőrizze, hogy a modul szövege mennyire érzékeny az egyes speciális bemeneti adatokra – minden ilyen értéket fel kell venni a tesztekbe. Adja hozzá a hiányzó teszteket.
10.5. A szoftver komplex hibakeresése.
Mint fentebb említettük, az összetett hibakeresés során a PS egészét tesztelik, és teszteket készítenek minden PS-dokumentumhoz. Ezeknek a dokumentumoknak a tesztelése általában a fejlesztésük fordított sorrendjében történik (az egyetlen kivétel az alkalmazási dokumentáció tesztelése, amely a külső leírás szerint készül a programszövegek fejlesztésével párhuzamosan; ezt a tesztelést a legjobb a a külső leírás elkészült). A komplex hibakeresésben végzett tesztelés a PS alkalmazása olyan konkrét adatokra, amelyek elvileg a felhasználótól származhatnak (különös tekintettel arra, hogy minden tesztet a felhasználó számára kialakított formában készítenek el), de esetleg szimulált (és nem valós) formában. környezet. Például néhány olyan bemeneti és kimeneti eszköz, amelyek nem érhetők el az összetett hibakeresés során, helyettesíthetők szoftverszimulátorukkal.
PS architektúra tesztelése. A tesztelés célja eltérések feltárása az architektúra leírása és a PS programkészlete között. A PS architektúra tesztelésének megkezdésekor az egyes alrendszerek autonóm hibakeresésének már be kell fejeződnie. Az architektúra-megvalósítási hibák elsősorban ezen alrendszerek interakciójához köthetők, különösen az építészeti funkciók megvalósításához (ha vannak ilyenek). Ezért szeretném ellenőrizni a PS alrendszerek közötti interakció összes módját. De mivel túl sok lehet belőlük, kívánatos lenne legalább az alrendszerek összes végrehajtási láncát tesztelni anélkül, hogy az utóbbit újra be kellene léptetni. Ha az adott architektúra a PS-t kiválasztott alrendszerek kis rendszereként ábrázolja, akkor az ilyen láncok száma jól látható lesz.
Külső funkciók tesztelése. A tesztelés célja eltérések feltárása a PS funkcionális specifikációja és szoftverprogramjai között. Annak ellenére, hogy ezeket a programokat már egymástól függetlenül hibakeresték, ezek az eltérések például a programok és moduljaik belső specifikációinak (amelyek alapján az autonóm tesztelést végezték) és a külső funkcionális specifikáció közötti eltérésből adódhatnak. az MS. A külső funkciók tesztelése általában ugyanúgy történik, mint a modulok tesztelése az első lépésben, azaz. mint egy fekete doboz.
PS minőségi tesztelés. A tesztelés célja a PS minőségi előírásban megfogalmazott minőségi követelmények megsértésének felkutatása. Ez a legnehezebb és legkevésbé tanulmányozott vizsgálati típus. Csak az világos, hogy nem minden PS minőségi primitív tesztelhető teszteléssel (lásd a következő előadást a PS minőségértékelésről). A PS teljességét már külső funkciók tesztelésekor is ellenőrizzük. Tovább ezt a szakaszt ennek a minőségi primitívnek a tesztelése folytatható, ha szükség van a PS megbízhatósági fokának valószínűségi becslésére. Az ilyen vizsgálatok módszertanát azonban még ki kell dolgozni. Tesztelhető a pontosság, a robusztusság, a biztonság, az időbeli hatékonyság, bizonyos mértékig a memória hatékonysága, az eszközhatékonyság, a bővíthetőség és részben az eszközfüggetlenség. Az ilyen típusú tesztelések mindegyikének megvannak a sajátosságai, és külön figyelmet érdemelnek. Itt ezek felsorolására szorítkozunk. A PS könnyű használhatóságát (egy minőségi kritérium, amely több minőségi primitívet is tartalmaz, lásd a 4. előadást) a PS használatára vonatkozó dokumentáció tesztelésekor értékeljük.
Vizsgálati dokumentáció a PS alkalmazásáról. A tesztelés célja az alkalmazás dokumentációja és a szoftverprogramok halmaza közötti ellentmondások, valamint a szoftver használatának kényelmetlenségének felkutatása. Ez a szakasz közvetlenül megelőzi a felhasználó csatlakozását a PS fejlesztésének befejezéséhez (a PS követelményeinek tesztelése és a PS tanúsítása), ezért nagyon fontos, hogy a fejlesztők először maguk használják a PS-t úgy, ahogyan azt a felhasználó fogja tenni. azt. Ebben a szakaszban minden tesztet kizárólag a PS alkalmazására vonatkozó dokumentáció alapján készítenek el. Mindenekelőtt a szoftver képességeit kell tesztelni, ahogyan azt a külső funkciók tesztelésekor is megtették, de csak az alkalmazás dokumentációja alapján. A dokumentációban minden nem egyértelmű helyet, valamint a dokumentációban használt összes példát tesztelni kell. Ezután a PS alkalmazásának legnehezebb eseteit teszteljük annak érdekében, hogy feltárjuk a PS egyszerű használatának relativitása követelményeinek megsértését.
A PS követelményeinek meghatározásának tesztelése. A tesztelés célja annak megállapítása, hogy a szoftver mennyiben nem felel meg a rá vonatkozó követelményeknek. Az ilyen típusú tesztelés sajátossága, hogy a PS beszerző szervezete vagy felhasználói szervezete végzi el a fejlesztő és a felhasználó közötti akadály leküzdésének egyik módjaként (lásd 3. előadás). Általában ez a tesztelés ellenőrzési feladatok segítségével történik - tipikus feladatok, amelyeknél ismert a megoldás eredménye. Azokban az esetekben, amikor a kifejlesztett PS-nek a PS egy másik verzióját kell lecserélnie, amely a kifejlesztett PS feladatainak legalább egy részét megoldja, a tesztelést a közös problémák megoldásával végzik mind a régi, mind az új PS használatával, majd az eredményeket összehasonlítják. kapott. Néha az ilyen tesztelés egy formájaként a PS próbaüzemét használják - egy új PS korlátozott alkalmazása az eredmények gyakorlati felhasználásának elemzésével. Lényegében ez a fajta tesztelés sok hasonlóságot mutat a PS tesztelésével annak tanúsítása során (lásd a 14. előadást), de a tanúsítás előtt, néha pedig a tanúsítás helyett végzik el.
Irodalom a 10. előadáshoz.
10.1. G. Myers. Szoftver megbízhatóság. - M.: Mir, 1980. - S. 171-262.
10.2. D. Van Tassel. Stílus, fejlesztés, hatékonyság, hibakereső és tesztelő programok. - M.: Mir, 1985. - S. 179-295.
10.3. J. Hughes, J. Michtom. A programozás strukturális megközelítése. - M.: Mir, 1980. - S. 254-268.
10.4. J. Fox. Szoftver és fejlesztésük. - M.: Mir, 1985. - S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. A szoftverfejlesztés alapelvei. - M.: Mir, 1982. - S. 105-116.
10.6. Yu.M. Bezborotov. Programok egyedi hibakeresése. - M.: Nauka, 1982. - S. 9-79.
10.7. V.V. Lipaev. Program tesztelés. - M.: Rádió és kommunikáció, 1986. - S. 15-47.
10.8. E.A. Zhogolev. Bevezetés a programozási technológiába (előadásjegyzet). - M.: "PÁRBESZÉD-MGU", 1994.
10.9. E. Dijkstra. Megjegyzések a strukturált programozáshoz. //U. Dahl, E. Dijkstra, K. Hoor. Strukturális programozás. - M.: Mir, 1975. - S. 7-13.
11. előadás
11.1. A funkcionalitás és a megbízhatóság, mint a szoftver minőségének kötelező kritériuma.
Az előző előadásokon a PS fejlesztésének minden szakaszát figyelembe vettük, kivéve a tanúsítását. Ugyanakkor nem érintettük a PS minőségbiztosításának kérdéseit a minőségi előírása szerint (lásd 4. előadás). Igaz, a PS funkcionális specifikációjának megvalósítása során ezzel megbeszéltük a funkcionalitási kritérium biztosításának főbb kérdéseit. Miután a szoftver megbízhatóságát deklaráltuk fő tulajdonságként (lásd 1. előadás), a hibamegelőzést választottuk a szoftver megbízhatóságának biztosításának fő megközelítéseként (lásd 3. előadás), és megvitattuk annak megvalósítását a szoftverfejlesztés különböző szakaszaiban. Így megnyilvánult a tézis a PS kötelező funkcionalitásáról és megbízhatóságáról, mint minőségi kritériumáról.
A szoftverminőségi specifikáció azonban tartalmazhat ezen kritériumok további jellemzőit, amelyek biztosítása külön tárgyalást igényel. Ezek a kérdések állnak az előadás középpontjában. Az egyéb minőségi kritériumok biztosításáról a következő előadásban lesz szó.
Az alábbiakban tárgyaljuk az MS minőségi primitívek biztosítását, amelyek kifejezik az MS működőképességének és megbízhatóságának kritériumait.
11.2. A szoftver teljességének biztosítása.
A PS teljessége egy általános PS minőségi primitív a PS funkcionalitásának és megbízhatóságának kifejezésére, a funkcionalitás szempontjából pedig az egyetlen primitív (lásd 4. előadás).
A PS funkcionalitását a funkcionális specifikációja határozza meg. A PS teljessége, mint minőségének primitívje, annak mértéke, hogy ez a specifikáció hogyan valósul meg egy adott PS-ben. Ennek a primitívnek a teljes körű biztosítása a funkcionális specifikációban meghatározott funkciók mindegyikének megvalósítását jelenti, az ott feltüntetett összes részlettel és jellemzővel együtt. Az összes korábban tárgyalt technológiai folyamat megmutatja, hogyan lehet ezt megtenni.
A PS funkcionalitásának megvalósításának azonban több szintje is definiálható a PS minőségi specifikációjában: definiálható néhány egyszerűsített (kezdeti vagy induló) verzió, amelyet először meg kell valósítani, illetve több köztes verzió is meghatározható. Ebben az esetben egy további technológiai probléma merül fel: a PS funkcionalitásának növelésének megszervezése. Itt fontos megjegyezni, hogy a PS egyszerűsített változatának fejlesztése nem prototípusának fejlesztése. A prototípus fejlesztése a jövőbeni PS használati feltételeinek jobb megértése, külső leírásának tisztázása érdekében zajlik. Kiválasztott felhasználók számára készült, ezért nemcsak az elvégzett funkciókban, hanem a felhasználói felület jellemzőiben is jelentősen eltérhet a szükséges PS-től. A szükséges PS egyszerűsített változatát úgy kell megtervezni, hogy minden olyan felhasználó gyakorlati használatra alkalmas legyen, akinek szánták. Ezért egy ilyen operációs rendszer működőképességének biztosításának fő elve az, hogy az operációs rendszert a kezdetektől úgy kell fejleszteni, mintha az egész operációs rendszerre lenne szükség, egészen addig, amíg a fejlesztők nem foglalkoznak az operációs rendszer azon részeivel vagy részleteivel, a megvalósítással. amely minőségi előírása szerint halasztható. Így mind a külső leírást, mind a PS architektúra leírását teljes körűen ki kell dolgozni. Csak azoknak a szoftveralrendszereknek a megvalósítását lehet elhalasztani, amelyeket a kifejlesztett PS architektúrája határoz meg, amelyek működését a jelen PS kezdeti verziója nem írja elő. Maguk a szoftveralrendszerek megvalósítása a céltudatos konstruktív megvalósítás módszerével a legjobban megoldható, a PS kezdeti verziójában meghagyva azoknak a szoftvermoduloknak megfelelő szimulátorait, amelyekre ebben a verzióban nincs szükség. Egyes szoftvermodulok egyszerűsített megvalósítása is elfogadható, a megfelelő funkciók egyes részleteinek megvalósítása mellőzésével. Technológiai szempontból azonban jobb, ha az ilyen modulokat eredeti imitátoraiknak tekintjük (bár messze fejletteknek).
A kifejlesztett PS hibái miatt előfordulhat, hogy a funkcionalitás biztosításában elért teljesség (a minőségi előírásnak megfelelően) nem felel meg az elvárásoknak. Csak azt mondhatjuk, hogy ezt a teljességet bizonyos valószínűséggel sikerült elérni, amelyet a tesztelés mennyisége és minősége határoz meg. Ennek a valószínűségnek a növelése érdekében folytatni kell a PS tesztelését és hibakeresését. Egy ilyen valószínűség becslése azonban nagyon specifikus feladat (figyelembe véve, hogy a hiba megnyilvánulása a PS-ben a kiindulási adatok függvénye), amely még megfelelő elméleti tanulmányokra vár.
11.3. A szoftvereszköz pontosságának biztosítása.
Ennek a primitívnek a megadása valós típusú értékekkel (pontosabban bizonyos hibával ábrázolt értékekkel) kapcsolatos műveletekhez kapcsolódik. Egy adott függvény értékének kiszámításakor a szükséges pontosság biztosítása azt jelenti, hogy ezt az értéket olyan hibával kapjuk meg, amely nem lépi túl a megadott határokat. A hibák típusaival, becslési módszereivel és a szükséges pontosság elérésének módszereivel (ún. közelítő számításokkal) a számítási matematika foglalkozik. Itt csak a hiba egy bizonyos szerkezetére figyelünk: a számított érték hibája (teljes hiba) függ
az alkalmazott számítási módszer hibájáról (amelybe beleszámítjuk az alkalmazott modell pontatlanságát),
a felhasznált adatok bemutatásának hibájából (ún. fatális hibából),
a kerekítési hibától (a módszerben alkalmazott műveletek végrehajtásának pontatlansága).
11.4. A szoftver autonómiájának biztosítása.
Ezt a minőségi primitívet a minőség-specifikáció szakaszában biztosítjuk úgy, hogy döntést kell hozni arról, hogy használunk-e megfelelő mögöttes szoftvert a kifejlesztett PS-ben, vagy nem használunk benne semmilyen mögöttes szoftvert. Ugyanakkor figyelembe kell venni mind a megbízhatóságát, mind a használatához szükséges erőforrásokat. A kifejlesztett PS megbízhatóságával szembeni megnövekedett követelmények mellett a fejlesztők rendelkezésére álló alapszoftver megbízhatósága nem bizonyulhat kielégítőnek, ezért annak használatát fel kell hagyni, funkcióinak szükséges mennyiségben való megvalósítását be kell építeni a a PS. Hasonló döntéseket kell meghozni a felhasznált erőforrások szigorú korlátozása mellett (a PS hatékonysági kritériuma szerint).
11.5. A szoftver fenntarthatóságának biztosítása.
Ezt a minőségi primitívet úgynevezett defenzív programozás segítségével biztosítjuk. Általánosságban elmondható, hogy a defenzív programozást az MS megbízhatóságának növelésére használják a modul tágabb értelemben vett programozása során. Ahogy Myers kijelenti: "A védekező programozás egy fontos előfeltevésen alapul: A legrosszabb, amit egy modul tehet, hogy elfogadja a rossz bevitelt, majd helytelen, de elfogadható eredményt ad vissza." Ennek elkerülése érdekében a modul szövege tartalmazza a bemeneti és kimeneti adatok helyességének ellenőrzését a jelen modul specifikációinak megfelelően, különös tekintettel a bemeneti és kimeneti adatokra vonatkozó korlátozások teljesítésére, valamint a köztük lévő kapcsolatokra. a modul specifikációjában meghatározottakat ellenőrizni kell. Az ellenőrzés negatív eredménye esetén a megfelelő kivételt emelik. Ebben a tekintetben a második típusú töredékek a modul végén találhatók - a megfelelő kivételes helyzetek kezelői, amelyek a szükséges diagnosztikai információk kiadása mellett intézkedhetnek az adatok hibáinak kiküszöbölésére (pl. újbóli beírásuk előírása) vagy a hiba hatásának mérséklése (például a PS által vezérelt eszközök lágy leállítása, hogy elkerülhető legyen a meghibásodásuk a programvégrehajtás vészleállítása esetén).
A modulok védelmi programozásának alkalmazása a PS hatékonyságának csökkenéséhez vezet mind időben, mind a memóriában. Ezért szükséges a defenzív programozás alkalmazási fokának ésszerű szabályozása a PS megbízhatóságára és hatékonyságára vonatkozó, a kifejlesztett PS minőségi specifikációjában megfogalmazott követelmények függvényében. A kifejlesztett modul bemeneti adatai származhatnak közvetlenül a felhasználótól vagy más modulokból. A defenzív programozás használatának leggyakoribb esete az első adatcsoporthoz való felhasználás, ami a PS stabilitásának megvalósítását jelenti. Ezt minden esetben meg kell tenni, ha a PS minőségi specifikációja előírja a PS stabilitásának biztosítását. A defenzív programozás alkalmazása a bemeneti adatok második csoportja esetében azt jelenti, hogy a kifejlesztett modul végrehajtása során más modulokban hibásan észlelnek, a kifejlesztett modul kimeneti adatainál pedig magában a modulban próbálják feltárni a hibát. végrehajtása során. Ez lényegében a 3. előadásban tárgyalt hiba-önészlelési megközelítés részleges megvalósítását jelenti a szoftver megbízhatóságának biztosítása érdekében. A védekező programozás ezen esetét rendkívül ritkán alkalmazzák - csak akkor, ha a szoftver megbízhatóságának követelményei teljesülnek. rendkívül magasak.
11.6. A szoftverek biztonságának biztosítása.
Megkülönböztetni a következő típusok a PS védelme az információtorzulástól:
hardverhibák elleni védelem;
védelem egy "idegen" program befolyása ellen;
védelem a "saját" program hibái ellen;
védelem a kezelői (felhasználói) hibák ellen;
védelem az illetéktelen hozzáférés ellen;
védelem elleni védelem.
A hardverhibák elleni védelem jelenleg nem túl sürgős feladat (az elért számítógép-megbízhatósági szintet figyelembe véve). De még mindig hasznos tudni a megoldását. Ezt az úgynevezett "dupla-hármas tévedések" megszervezése biztosítja. Ennek érdekében a teljes, a PS által meghatározott adatfeldolgozási folyamatot az úgynevezett "referenciapontok" időközönként felosztják. Ennek az intervallumnak a hossza nem haladhatja meg a számítógép átlagos üzemidejének felét. Az ebben a folyamatban megváltozott memória állapotának minden referenciapontra egy másolata a másodlagos memóriába kerül valamilyen ellenőrző összeggel (az állapot függvényében számított számmal) abban az esetben, ha úgy tekintjük, hogy az adatfeldolgozás az előző hivatkozási pont erre (azaz egy "hibás számítás") helyesen (számítógép meghibásodások nélkül) készült. Ennek kiderítése érdekében két ilyen "téves számítás" történik. Az első „számítás” után a megadott ellenőrző összeg kiszámításra és tárolásra kerül, majd visszaáll az előző referenciapont memóriaállapota, és megtörténik a második „számítás”. A második „hibás számítás” után újra kiszámítja a megadott ellenőrző összeget, amelyet ezután összehasonlít az első „hibás számítás” ellenőrző összegével. Ha ez a két ellenőrző összeg egyezik, a második számítást helyesnek tekintjük, ellenkező esetben a második „számítás” ellenőrző összegét is eltárolja, és a harmadik „számítást” hajtja végre (az előző referenciapont memóriaállapotának előzetes visszaállításával). Ha a harmadik „hibás számítás” ellenőrző összege megegyezik az első két „hibás számítás” ellenőrző összegével, akkor a harmadik hibás számítást helyesnek tekintjük, ellenkező esetben a számítógép műszaki ellenőrzése szükséges.
Az "idegen" programok befolyása elleni védelem elsősorban az operációs rendszereket vagy a funkcióikat részben ellátó programokat jelenti. Ennek a védelemnek két típusa van:
hibavédelem,
védelem egy "idegen" program rosszindulatú befolyása ellen.
Egy számítógép többprogramozási üzemmódjának megjelenésekor a memóriájában egyszerre több program is futhat, amelyek a megszakítások (ún. kvázi-párhuzamos végrehajtás) következtében felváltva kapnak irányítást. Az egyik ilyen program (általában: az operációs rendszer) kezeli a megszakításokat és kezeli a többprogramozást. Mindegyik programban hibák léphetnek fel (hibák jelenhetnek meg), amelyek befolyásolhatják más programok funkcióinak teljesítményét. Ezért a vezérlőprogramnak (operációs rendszernek) meg kell védenie magát és más programokat az ilyen hatásoktól. Ehhez a számítógép hardverének a következő szolgáltatásokat kell megvalósítania:
memória védelem,
két számítógép üzemmód: privilegizált és munka (felhasználó),
kétféle tranzakció: privilegizált és közönséges,
a megszakítások helyes végrehajtása és a számítógép első indítása,
átmeneti megszakítás.
A memóriavédelem azt a képességet jelenti, hogy programozottan beállíthatja az egyes programok számára elérhetetlen memóriaterületeket. Privilegizált módban bármilyen művelet végrehajtható (mind a normál, mind a privilegizált), míg a futtatási módban csak a szokásos műveletek. Egy privilegizált művelet végrehajtására, valamint a védett memória elérésére tett kísérlet működési módban a megfelelő megszakítást okozza. Ezenkívül a privilegizált műveletek közé tartoznak a memóriavédelem és az üzemmód megváltoztatásának műveletei, valamint a külső információs környezethez való hozzáférés. A számítógép kezdeti bekapcsolásakor és minden megszakításkor automatikusan engedélyeznie kell a privilegizált módot, és felül kell írnia a memóriavédelmet. Ebben az esetben a vezérlőprogram (operációs rendszer) teljesen meg tud védeni magát más programok befolyásától, ha a kezdeti bekapcsoláskor és megszakításokkor minden vezérlés átviteli pont ehhez a programhoz tartozik, ha nem engedi meg más program működését. privilegizált mód (a vezérlés átadásakor a program csak az üzemmódot kapcsolja be), és ha teljes mértékben védi a memóriáját (amely különösen az összes vezérlési információt tartalmazza, beleértve az ún. megszakítási vektorokat is) a többi programtól. Ekkor senki sem akadályozza meg abban, hogy a benne megvalósított védelmi funkciókat más programok számára lássa el (beleértve a külső információs környezethez való hozzáférést is). A probléma megoldásának megkönnyítésére egy ilyen program egy részét állandó memóriába helyezzük, pl. elválaszthatatlan magától a számítógéptől. Az ideiglenes megszakítás jelenléte lehetővé teszi a vezérlőprogram számára, hogy megvédje magát a többi programban való hurkolással szemben (ilyen megszakítás nélkül egyszerűen elveszítheti a vezérlési képességét).
A „saját” program meghibásodásai elleni védelmet ennek a programnak a megbízhatósága biztosítja, amely az előadások során tárgyalt teljes programozási technológia középpontjában áll.
A felhasználói hibák elleni védelmet (a bemeneti adatok hibái mellett, lásd a PS stabilitásának biztosítását) figyelmeztető üzenetek kibocsátásával biztosítják a külső információs környezet állapotának megváltoztatására tett kísérletekről, amelyek megkövetelik ezen műveletek megerősítését, valamint a a külső információs környezet egyes összetevőinek állapota. Ez utóbbi a külső információs környezet állapotában bekövetkezett változások archiválásán alapul.
Az illetéktelen hozzáférés elleni védelmet titkos szavak (jelszavak) használata biztosítja. Ebben az esetben minden felhasználót ellátnak bizonyos információkkal és eljárási erőforrásokkal (szolgáltatásokkal), amelyek használatához jelszó bemutatása szükséges a PS számára, amelyet a felhasználó korábban regisztrált a PS-ben. Más szóval, a felhasználó mintegy „zárat akaszt” a számára kiosztott erőforrásokra, a „kulcsra”, amelyhez csak ez a felhasználó rendelkezik. Egyedi esetekben azonban kitartó kísérletek történhetnek a védelem megtörésére, ha a védett erőforrások valakinek rendkívüli értéket képviselnek. Ilyen esetben további intézkedéseket kell tenni a biztonság megsértése elleni védelem érdekében.
A biztonsági rések elleni védelem a PS-ben speciális programozási technikák használatához kapcsolódik, amelyek megnehezítik az illetéktelen hozzáférés elleni védelmet. A közönséges jelszavak használata nem elegendő, ha az értékes információkhoz való hozzáférés rendkívül tartós (például bűnügyi jellegű) vágyáról van szó. Először is, mert a jelszavakra vonatkozó információkat, amelyeket a PS használ az illetéktelen hozzáférés elleni védelemre, viszonylag könnyen meg lehet szerezni ennek a védelemnek a "crackerével", ha hozzáfér ehhez a PS-hez. Másodszor, számítógép segítségével lehetőség van a lehetséges jelszavak kellően nagy számbavételére, hogy megtaláljuk a megfelelőt az érdeklődésre számot tartó információk eléréséhez. A következő módon védheti meg magát egy ilyen feltöréstől. A titkos szót (jelszót) vagy éppen a titkos X egész számot csak a védett információ tulajdonosa ismeri, a hozzáférési jogok ellenőrzésére pedig egy másik Y=F(X) szám kerül a számítógépbe, amelyet egyedileg számít ki a PS minden alkalommal, amikor a titkos szó bemutatásakor megpróbálnak hozzáférni ehhez az információhoz. Ugyanakkor az F függvényt minden PS-felhasználó jól ismerheti, de van egy olyan tulajdonsága, hogy az X szó visszaállítása Y-ből gyakorlatilag lehetetlen: kellően nagy X szó hosszúságával (például több száz karakterrel). ), ehhez csillagászati időre van szükség. Az ilyen Y számot a titkos X szó (és innen a védett információ) tulajdonosának elektronikus (számítógépes) aláírásának nevezzük.
Az ilyen védelem egy másik típusa a számítógépes hálózatokon keresztül küldött üzenetek védelmével, a szándékos (vagy rosszindulatú) torzítással kapcsolatos. Egy ilyen üzenet a számítógépes hálózat „átrakodási” pontjain elfogható, és helyettesíthető az elfogott üzenet szerzőjének másik üzenetével. Ez a helyzet elsősorban a banki műveletek számítógépes hálózat segítségével történő végrehajtása során merül fel. Egy ilyen üzenet cseréjével, amely egy bankszámla tulajdonostól kapott megbízás valamilyen banki művelet elvégzésére, a számlájáról pénzt lehet átutalni egy "hacker" védelem számlájára (egyfajta számítógépes bankrablás). Az ilyen biztonsági rések elleni védelem a következőképpen történhet. Az F függvény mellett, amely meghatározza az X titkos szó tulajdonosának számítógépes aláírását, amelyet a védett üzenet címzettje ismer (ha csak a tulajdonosa ennek a címzettnek a kliense), egy másik Bélyegző funkció is meghatározásra kerül a PS, amelyből az üzenet küldőjének ki kell számítania az S=Bélyeg(X,R ) számot az X titkos szó és a továbbított üzenet R szövegének felhasználásával. A Bélyegző funkció szintén jól ismertnek tekinthető minden MS felhasználó számára, és rendelkezik ilyen egy tulajdonság, hogy gyakorlatilag lehetetlen visszaállítani az X számot S-ből, vagy kiválasztani egy másik R üzenetet a megfelelő számítógépes aláírással. Magának a továbbított üzenetnek (a védelmével együtt) így kell kinéznie:
továbbá az Y (számítógépes aláírás) lehetővé teszi a címzett számára, hogy megállapítsa az ügyfél igazságát, S pedig az R védett üzenetet az Y számítógépes aláírással rögzíti. Ebben a tekintetben az S számot elektronikusnak (számítógépnek) nevezzük. ) fóka. A PS még egy közjegyzői funkciót határoz meg, amely szerint a védett üzenet címzettje ellenőrzi a továbbított üzenet valódiságát:
Ezzel egyértelműen megállapítható, hogy az R üzenet az X titkos szó tulajdonosához tartozik.
A védelem elleni védelem szükséges abban az esetben, ha a felhasználó elfelejtette (vagy elvesztette) jelszavát. Ilyen esetben lehetővé kell tenni, hogy a védelmi rendszer működéséért felelős speciális felhasználó (PS adminisztrátor) ideiglenesen megszüntesse a jogosulatlan hozzáférés elleni védelmet az elfelejtett jelszó tulajdonosa számára, hogy új jelszót rögzíthessen.
Irodalom a 11. előadáshoz.
11.1. I.S. Berezin, N.P. Zsidkov. Számítási módszerek, vol. 1. és 2. - M.: Fizmatgiz, 1959.
11.2. N.S. Bakhvalov, N.P. Zsidkov, G. M. Kobelkov. Numerikus módszerek. - M.: Nauka, 1987.
11.3. G. Myers. Szoftver megbízhatóság. - M.: Mir, 1980. S. 127-154.
11.4. A.N. Lebegyev. A banki információk védelme és a modern kriptográfia//Az információbiztonság kérdései, 2(29), 1995.
12. előadás Szoftver minőségbiztosítás
12.1. A szoftver minőségbiztosítási folyamatának általános jellemzői.
Ahogy azt a 4. előadásban már jeleztük, a minőségi specifikáció meghatározza azokat a fő irányelveket (célokat), amelyek a PS fejlesztésének minden szakaszában valamilyen módon befolyásolják a megfelelő opció kiválasztását a különböző döntések meghozatalakor. Mindazonáltal minden minőségprimitívnek megvannak a sajátosságai az ilyen hatásokra, így a PS-ben való jelenlétének biztosítása megkövetelheti a saját megközelítéseket és módszereket a PS vagy egyes részei fejlesztéséhez. Emellett a PS minőségi kritériumok és az azokat kifejező minőségi primitívek inkonzisztenciája is megfigyelhető: az egyik PS minőségi primitív jó biztosítása jelentősen megnehezítheti vagy lehetetlenné teheti a többi primitív biztosítását. Ezért a PS minőségbiztosítási folyamatának lényeges része az elfogadható kompromisszumok megtalálása. Ezeket a kompromisszumokat részben már a PS minőségi specifikációjában meg kell határozni: a PS minőségi modellnek meg kell határoznia az egyes minőségprimitívek PS-ben való jelenlétének szükséges mértékét, és meg kell határoznia e fokozatok elérésének prioritásait.
A minőségbiztosítás minden technológiai folyamatban megtörténik: az abban meghozott döntések ilyen vagy olyan mértékben befolyásolják a szoftver egészének minőségét. Különösen azért, mert a minőségi primitívek jelentős része nem annyira a PS-ben szereplő programok, hanem a dokumentáció tulajdonságaihoz kötődik. A minőségi primitívek észrevehető inkonzisztenciája miatt nagyon fontos a kiválasztott prioritások betartása az ellátásuk során. Mindenesetre célszerű betartani két általános elvet:
először is biztosítani kell a PS szükséges funkcionalitását és megbízhatóságát, majd a fennmaradó minőségi kritériumokat a PS-ben való jelenlétük elfogadható szintjére kell hozni;
nincs szükség, sőt káros is lehet, hogy a PS minőségi specifikációjában meghatározott minőségi primitívek magasabb szintjét keressük a PS-ben.
A PS működőképességének és megbízhatóságának biztosításáról az előző előadásban szó esett. Az alábbiakban tárgyaljuk az operációs rendszer egyéb minőségi kritériumainak biztosítását.
12.2.. A szoftvereszköz egyszerű használatának biztosítása
A PS P-dokumentációja határozza meg a felhasználói dokumentáció összetételét
Az előző előadásban már szóba került a PS könnyű használhatóságát meghatározó öt minőségi primitív (stabilitás és biztonság) közül kettőnek a biztosítása.
A P-dokumentáció és az informatívság határozza meg a felhasználói dokumentáció összetételét és minőségét (lásd a következő előadást).
A kommunikációt megfelelő kialakítása biztosítja felhasználói felületés a megfelelő kivételkezelés. mi itt a probléma?
12.3. A szoftver hatékonyságának biztosítása.
A PS hatékonyságát a megfelelő döntések meghozatala biztosítja fejlesztésének különböző szakaszaiban, kezdve az architektúra fejlesztésével. Az adatstruktúra és a megjelenítés megválasztása különösen erősen befolyásolja a PS hatékonyságát (főleg a memória tekintetében). De az egyes szoftvermodulokban használt algoritmusok megválasztása, valamint megvalósításuk jellemzői (beleértve a programozási nyelv kiválasztását is) jelentősen befolyásolhatják a PS hatékonyságát. Ugyanakkor folyamatosan az emlékezetből kell feloldani az időbeli hatékonyság és a hatékonyság közötti ellentmondást. Ezért nagyon fontos, hogy a minőségi specifikáció kifejezetten jelezze ezen minőségi primitívek mutatói közötti mennyiségi kapcsolatot, vagy legalább mennyiségi határokat szabjon meg ezen mutatók valamelyikéhez. És mégis, a különböző szoftvermodulok eltérő hatással vannak a PS egészének hatékonyságára: mind a PS teljes költségéhez való hozzájárulásuk idő és memória tekintetében, mind pedig a különböző minőségi primitívekre gyakorolt hatás tekintetében. (egyes modulok erősen befolyásolhatják az időhatékonyság elérését, és gyakorlatilag nem befolyásolják a memória hatékonyságát, míg mások jelentősen befolyásolhatják a teljes memóriafogyasztást anélkül, hogy jelentősen befolyásolnák a PS működési idejét). Ráadásul ez a hatás (elsősorban az időhatékonyság szempontjából) előre (a PS megvalósításának befejezése előtt) nem mindig értékelhető helyesen.
először ki kell fejlesztenie egy megbízható PS-t, és csak ezután kell elérnie a szükséges hatékonyságot a jelen PS minőségi specifikációi szerint;
a PS hatékonyságának javítása érdekében először is használjon optimalizáló fordítót - ez biztosítja a szükséges hatékonyságot;
ha a PS elért hatékonysága nem felel meg a minőségi specifikációnak, akkor keresse meg a legkritikusabb modulokat a PS szükséges hatékonysága szempontjából (időbeli hatékonyság esetén ehhez a PS modulok szerinti megoszlását kell megszerezni működési idő megfelelő mérésekkel a PS végrehajtása során); ezeket a modulokat, és először kézi módosításukkal próbálja meg optimalizálni őket;
ne optimalizálja a modult, ha ez nem szükséges a PS kívánt hatékonyságának eléréséhez.
12.4. A karbantarthatóság biztosítása.
A C-dokumentáció, az információtartalom és az érthetőség határozza meg a karbantartási dokumentáció összetételét és minőségét (lásd a következő előadást). Emellett a programok (modulok) szövegére vonatkozóan a következő ajánlások tehetők.
megjegyzéseket használjon a modul szövegében, amelyek tisztázzák és elmagyarázzák a meghozandó döntések jellemzőit; lehetőség szerint a modul szövegének kidolgozásának legkorábbi szakaszában tegyen megjegyzéseket (legalább rövid formában);
értelmes (mnemonikus) és tartósan megkülönböztethető neveket használjunk (a név optimális hossza 4-12 betű, számok a végén), ne használjunk hasonló neveket és kulcsszavakat;
legyen óvatos a konstansok használatakor (egy egyedi állandónak csak egyszer kell előfordulnia a modul szövegében: amikor deklarálják vagy végső megoldás, amikor egy változót konstansként inicializálunk );
ne féljen opcionális zárójeleket használni (a zárójelek olcsóbbak, mint a hibák ;
soronként legfeljebb egy állítást helyezzen el; a modul felépítésének tisztázásához használjon extra szóközt (behúzást) az egyes sorok elején ;
kerülje a trükköket, pl. ilyen programozási technikák, amikor egy modul töredékeit hozzuk létre, amelyek fő hatása nem nyilvánvaló vagy rejtett (fátyolos), például függvények mellékhatásai.
A bővíthetőséget megfelelő telepítő létrehozásával biztosítjuk.
A strukturáltság és a modularitás leegyszerűsíti mind a programszövegek megértését, mind azok módosítását.
12.5. A mobilitás biztosítása.
Irodalom a 12. előadáshoz.
12.1. Ian Somerville. Szoftverfejlesztés. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Stílus, fejlesztés, hatékonyság, hibakereső és tesztelő programok. - M.: Mir, 1985. S. 8-44, 117-178.
12.4. Szoftver felhasználói dokumentáció/ANSI/IEEE 1063-1987 szabvány.
13. előadás
13.1. A szoftverfejlesztési folyamat során készült dokumentáció.
A PS fejlesztése során nagy mennyiségű különféle dokumentáció jön létre. Szükséges a PS fejlesztői közötti információátadás eszközeként, a PS fejlesztésének irányításának eszközeként, valamint a PS alkalmazásához és karbantartásához szükséges információk továbbításának eszközeként a felhasználókhoz. Ennek a dokumentációnak a létrehozása a PS költségeinek nagy részét teszi ki.
Ez a dokumentáció két csoportra osztható:
PS fejlesztési menedzsment dokumentumok.
A PS-ben szereplő dokumentumok.
A PS fejlesztési menedzsment dokumentumok (folyamatdokumentáció) rögzítik a PS fejlesztésének és karbantartásának folyamatait, kommunikációt biztosítva a fejlesztői csapaton belül, valamint a fejlesztői csapat és a vezetők (menedzserek) - a fejlesztést irányító személyek között. Ezek a dokumentumok a következő típusúak lehetnek:
Tervek, becslések, menetrendek. Ezeket a dokumentumokat a vezetők hozzák létre a fejlesztési és karbantartási folyamatok előrejelzése és kezelése érdekében.
Jelentések az erőforrás-felhasználásról a fejlesztés során. Menedzserek hozták létre.
Szabványok. Ezek a dokumentumok előírják a fejlesztőknek, hogy milyen elveket, szabályokat, megállapodásokat kell követniük a PS fejlesztése során. Ezek a szabványok lehetnek nemzetköziek vagy nemzetiek, vagy kifejezetten azon szervezet számára készültek, amelyben ezt a PS-t fejlesztik.
Munkadokumentumok. Ezek a fő műszaki dokumentumok, amelyek a fejlesztők közötti kommunikációt biztosítják. Tartalmazzák a fejlesztési folyamat során felmerülő ötletek és problémák rögzítését, az alkalmazott stratégiák és megközelítések leírását, valamint a dokumentumok működő (ideiglenes) változatait, amelyeket a PS-be kell foglalni.
Feljegyzések és levelezés. Ezek a dokumentumok a menedzserek és a fejlesztők közötti interakció különféle részleteit rögzítik.
A PS-ben (termékdokumentációban) szereplő dokumentumok a PS programokat mind a felhasználók általi használatuk, mind a fejlesztőik és fenntartóik (a PS céljának megfelelően) szempontjából ismertetik. Itt kell megjegyezni, hogy ezeket a dokumentumokat nem csak a PS működési szakaszában (az alkalmazási és karbantartási szakaszában), hanem a fejlesztési szakaszban is felhasználják a fejlesztési folyamat irányítására (a munkadokumentumokkal együtt) - bármely Ebben az esetben ellenőrizni kell (tesztelve), hogy megfelelnek-e a PS-programoknak. Ezek a dokumentumok két különböző célú halmazt alkotnak:
PS felhasználói dokumentáció (P-dokumentáció).
Dokumentáció a PS támogatásához (C-dokumentáció).
13.2. Szoftver felhasználói dokumentáció.
A PS felhasználói dokumentációja (felhasználói dokumentáció) elmagyarázza a felhasználóknak, hogyan kell eljárniuk a jelen PS alkalmazásához. Szükséges, ha a PS bármilyen interakciót igényel a felhasználókkal. Az ilyen dokumentáció olyan dokumentumokat tartalmaz, amelyek útmutatást nyújtanak a felhasználónak a PS telepítésekor (amikor a PS-t a környezetnek megfelelő beállításokkal telepíti), amikor a PS-t a problémák megoldására használja, és amikor a PS-t kezeli (például amikor ez a PS kölcsönhatásba lép más rendszerekkel). Ezek a dokumentumok részben kitérnek a szoftvertámogatás kérdéseire, de nem foglalkoznak a programok módosításával kapcsolatos kérdésekkel.
Ebben a tekintetben a PS-felhasználók két kategóriáját kell megkülönböztetni: a közönséges PS-felhasználókat és a PS-adminisztrátorokat. A PS közönséges felhasználója (végfelhasználó) a PS-t használja problémái megoldására (a tárgykörében). Ez lehet egy műszaki eszközt tervező mérnök, vagy egy pénztáros, aki vonatjegyeket árusít egy PS segítségével. Lehet, hogy nem ismeri a számítógép működésének vagy programozási elveinek sok részletét. A PS adminisztrátor (rendszergazda) felügyeli a PS közönséges felhasználók általi használatát, és olyan támogatást nyújt a PS számára, amely nem kapcsolódik a programok módosításához. Például szabályozhatja az operációs rendszerhez való hozzáférési jogokat a közönséges felhasználók között, kommunikálhat az operációs rendszer szolgáltatóival, vagy végrehajthat bizonyos műveleteket az operációs rendszer működőképességének megőrzése érdekében, ha az egy másik rendszer része.
A felhasználói dokumentáció összetétele a jelen PS által megcélzott felhasználói közönségtől és a dokumentumok felhasználási módjától függ. A közönség itt a PS felhasználóinak kontingensét jelenti, akiknek szüksége van a PS bizonyos felhasználói dokumentációjára. A sikeres felhasználói dokumentum alapvetően a célközönség pontos meghatározásától függ. A felhasználói dokumentációnak tartalmaznia kell az egyes közönségekhez szükséges információkat. A dokumentum felhasználási módja a dokumentum felhasználási módjára vonatkozik. Általában a kellően nagy szoftverrendszerek használójának vagy dokumentumra van szüksége a PS tanulmányozásához (használd utasítás), vagy egyes információk pontosítására (használd referenciaként).
A munkáknak megfelelően a kellően nagy PS felhasználói dokumentációjának alábbi összetétele tekinthető jellemzőnek:
A PS általános működési leírása. Rövid leírást ad a PS működéséről. Olyan felhasználóknak készült, akiknek el kell dönteniük, hogy mennyire van szükségük erre a PS-re.
PS telepítési útmutató. Rendszergazdák számára készült. Részletesen elő kell írnia, hogyan kell rendszereket telepíteni egy adott környezetben. Tartalmaznia kell annak a géppel olvasható adathordozónak a leírását, amelyen az MS-t szállítják, az MS-t képviselő fájlokat, valamint a minimális hardverkonfigurációra vonatkozó követelményeket.
Útmutató a PS használatához. Hétköznapi felhasználók számára készült. Tartalmazza a szükséges információkat a PS alkalmazásáról, a tanulmányozáshoz kényelmes formában rendezve.
Útmutató a PS alkalmazásához. Hétköznapi felhasználók számára készült. Tartalmazza a szükséges információkat a PS alkalmazásáról, olyan formában rendezve, amely kényelmes az egyes részletek szelektív kereséséhez.
PS kezelési útmutató. Rendszergazdák számára készült. Le kell írnia azokat az üzeneteket, amelyek akkor jönnek létre, amikor az MS más rendszerekkel interakcióba lép, és hogyan válaszoljon ezekre az üzenetekre. Ezenkívül, ha az MS rendszerhardvert használ, ez a dokumentum elmagyarázhatja, hogyan kell karbantartani ezt a hardvert.
Ahogy korábban említettük (lásd 4. előadás), a felhasználói dokumentáció fejlesztése közvetlenül a külső leírás elkészítése után kezdődik. A dokumentáció minősége jelentősen meghatározhatja a PS sikerét. Elég egyszerűnek és felhasználóbarátnak kell lennie (egyébként ezt a PS-t általában nem érdemes létrehozni). Ezért, bár a felhasználói dokumentumok vázlatos verzióit (piszkozatait) a PS fő fejlesztői készítik, a végső verziók elkészítésében gyakran professzionális műszaki írók vesznek részt. Ezen túlmenően a felhasználói dokumentáció minőségének biztosítása érdekében számos szabványt dolgoztak ki (lásd pl.), amelyek előírják a jelen dokumentáció elkészítésének menetét, követelményeket fogalmaznak meg az egyes felhasználói dokumentumok típusaira, meghatározzák azok szerkezetét és tartalmát. .
13.3. Szoftver karbantartási dokumentáció.
A PS karbantartási dokumentációja (rendszerdokumentáció) a PS-t a fejlesztése szempontjából írja le. Ez a dokumentáció akkor szükséges, ha a PS magában foglalja annak elrendezésének (tervezésének) tanulmányozását és programjainak korszerűsítését. Mint már említettük, a karbantartás folyamatos fejlesztés. Ezért, ha szükséges a PS frissítése, egy speciális kísérő fejlesztői csapat vesz részt ebben a munkában. Ennek a csapatnak ugyanazzal a dokumentációval kell foglalkoznia, amely meghatározta a PS kezdeti (fő) fejlesztőinek csapatának tevékenységét, azzal a különbséggel, hogy ez a dokumentáció általában valaki másé lesz a karbantartó fejlesztői csapat számára ( egy másik csapat hozta létre). A karbantartó csapatnak át kell tanulmányoznia ezt a dokumentációt, hogy megértse a frissített PS szerkezetét és fejlesztési folyamatát, és meg kell tennie a szükséges változtatásokat ezen a dokumentáción, nagymértékben megismételve azokat a technológiai folyamatokat, amelyekkel az eredeti PS létrejött.
A PS támogatásával kapcsolatos dokumentáció két csoportra osztható:
(1) dokumentáció, amely meghatározza a PS programjainak és adatstruktúráinak felépítését és fejlesztésük technológiáját;
(2) a PS módosítását segítő dokumentáció.
Az első csoport dokumentációja tartalmazza a PS fejlesztésének egyes technológiai szakaszainak záródokumentumait. A következő dokumentumokat tartalmazza:
A PS külső leírása (Requirements document).
A PS rendszerarchitektúrájának leírása, beleértve az egyes programok külső specifikációit.
Minden PS-programhoz annak moduláris felépítésének leírása, beleértve a benne lévő minden egyes modul külső specifikációját.
Minden modulhoz - annak specifikációja és szerkezetének leírása (tervezési leírás).
Modulszövegek a kiválasztott programozási nyelven (programforráskód listák).
Operációs rendszer érvényesítési dokumentumok, amelyek leírják, hogyan állapították meg az egyes operációs rendszer programok érvényességét, és hogyan társították az érvényesítési információkat az operációs rendszer követelményeihez.
A szoftverellenőrzési dokumentumok elsősorban a tesztelési dokumentációt (tesztterv és tesztcsomag leírása) tartalmazzák, de tartalmazhatnak más típusú szoftverellenőrzés eredményeit is, például a programtulajdonságok igazolásait.
A második csoport dokumentációja tartalmazza
A rendszerkarbantartási útmutató, amely a szoftverrel együtt ismerteti az ismert problémákat, leírja, hogy a rendszer mely részei hardver- és szoftverfüggőek, és hogyan veszik figyelembe a szoftver fejlesztését annak felépítésében (tervezésénél).
A PS gyakori karbantartási problémája annak biztosítása, hogy minden reprezentációja lépést tartson (konzisztens marad), amikor a PS változik. Ennek elősegítése érdekében a dokumentumok és részeik közötti kapcsolatokat és függőségeket rögzíteni kell a konfigurációkezelési adatbázisban.
Irodalom a 13. előadáshoz.
13.1. Ian Somerville. Szoftverfejlesztés. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI/IEEE Std 1063-1988, IEEE szabvány a szoftver felhasználói dokumentációjához.
13.3. ANSI/IEEE Std 830-1984, IEEE útmutató a szoftverkövetelmények specifikációjához.
13.4. ANSI/IEEE Std 1016-1987, IEEE ajánlott gyakorlat a szoftvertervezés leírásához.
13.5. ANSI/IEEE Std 1008-1987, IEEE szabvány a szoftveregységek teszteléséhez.
13.6. ANSI/IEEE Std 1012-1986, IEEE szabvány a szoftverellenőrzési és érvényesítési tervekhez.
13.7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.
13.8. ANSI/IEEE Std 829-1983, IEEE szabvány a szoftverteszt-dokumentációhoz.
14. előadás
Szoftvertanúsítvány kijelölése. Szoftverminőség tesztelése és értékelése. A szoftverek minőségének értékelésére szolgáló tesztek és módszerek.
14.1. Szoftvertanúsítvány kijelölése.
A PS-tanúsítvány a PS minőségének hiteles megerősítése. A szoftverrendszer tanúsítására általában egy reprezentatív (tanúsító) bizottság jön létre, amely szakértőkből, a megrendelő képviselőiből és a fejlesztő képviselőiből áll. Ez a bizottság teszteli a PS-t, hogy megszerezze a minőségének értékeléséhez szükséges információkat. A PS tesztje alatt egy olyan intézkedéscsomag végrehajtásának folyamatát értjük, amely megvizsgálja, hogy a PS alkalmas-e a sikeres működésre (alkalmazás és karbantartás), a megrendelő igényeinek megfelelően. Ez a komplexum magában foglalja a szoftver dokumentáció teljességének és pontosságának ellenőrzését, egyéb tulajdonságainak tanulmányozását és megbeszélését, valamint a szoftvercsomagban található programok szükséges tesztelését, különös tekintettel arra, hogy ezek a programok megfelelnek-e a rendelkezésre álló dokumentációnak.
A PS tesztelése során szerzett információk alapján mindenekelőtt azt kell megállapítani, hogy a PS ellátja-e a deklarált funkciókat, illetve azt is, hogy a PS milyen mértékben rendelkezik a deklarált primitívekkel és minőségi kritériumokkal. Így a PS minőségének értékelése a tanúsítási folyamat fő tartalma. A PS minőségének értékelését a tanúsító bizottság erre vonatkozó határozatában rögzíti.
14.2. A szoftvertesztelés típusai.
A következő típusú PS-tesztek ismertek, amelyeket a PS tanúsítása céljából végeznek:
PS alkatrészek tesztelése;
rendszertesztek;
átvételi tesztek;
tereppróbák;
ipari tesztek.
A PS komponens tesztelése a PS egyes alrendszerei működőképességének ellenőrzése (tesztelése). Ezeket csak kivételes esetekben, a tanúsító bizottság külön határozatával tartják.
A PS rendszertesztelése a PS egészének működőképességének ellenőrzése (tesztelése). Ugyanolyan típusú tesztelést tartalmazhat, mint a PS komplex hibakeresésénél (lásd a 10. előadást). A tanúsító bizottság döntése alapján hajtják végre, ha kétségek merülnek fel a PS fejlesztői által végzett hibakeresés minőségével kapcsolatban.
Az elfogadási tesztek a PS tanúsításának fő típusai. Ezekkel a tesztekkel kezdi meg munkáját a tanúsító bizottság. Ezek a tesztek a benyújtott dokumentáció tanulmányozásával kezdődnek, beleértve a PS tesztelésének és hibakeresésének dokumentációját. Ha a dokumentáció nem tartalmazza kellően teljes körű szoftvertesztelési eredményeket, a tanúsító bizottság dönthet a szoftver rendszerteszteléséről, vagy a tanúsítási folyamat megszüntetéséről a fejlesztőnek a szoftver további (teljesebb) tesztelésére vonatkozó ajánlással. Ezen túlmenően ezen tesztek során a fejlesztői tesztek szelektíven átugorhatók, valamint a felhasználói ellenőrzési feladatok (lásd 10. előadás) és a bizottság által készített további tesztek a tanúsított PS minőségének felmérésére.
A PS terepi tesztelése a PS és az általa vezérelt műszaki rendszer bemutatása az ügyfelek szűk köre számára valós körülmények között, és a PS viselkedését gondosan figyelemmel kísérik. Az ügyfeleknek lehetőséget kell adni arra, hogy saját maguk állítsák be teszt esetek, különösen a kijáratoktól a műszaki rendszer kritikus üzemmódjaiig, valamint a benne lévő vészhelyzetek kijelzésekor. Ezek további tesztek, amelyeket a tanúsító bizottság döntése alapján csak egyes műszaki rendszereket vezérlő PS-ek esetében hajtanak végre.
A PS ipari tesztelése azt a folyamatot jelenti, amelynek során a PS-t állandó üzembe helyezik át a felhasználók számára. Ez a PS próbaüzemének időszaka (lásd a 10. előadást) a felhasználók által a PS viselkedésével és működési jellemzőivel kapcsolatos információk gyűjtésével. Ezek a PS végső tesztjei, amelyeket a tanúsító bizottság határozatával hajtanak végre, ha a korábbi tesztek során nem szereztek kellően teljes vagy megbízható információt a tanúsított PS minőségének értékeléséhez.
14.3. A szoftverek minőségének értékelési módszerei.
A PS minőségének értékelése az egyes kritériumok esetében a PS minőségi kritériumához kapcsolódó valamennyi primitív értékelésére korlátozódik, a jelen PS minőségi specifikációjában megadott specifikációjuknak megfelelően. A PS minőségi primitívek értékelési módszerei négy csoportra oszthatók:
a minőségi primitív mutatók közvetlen mérése;
a PS programjainak és dokumentációjának feldolgozása speciális szoftvereszközökkel (processzorokkal);
PS programok tesztelése;
szakértői értékelés a programok tanulmányozása és a PS dokumentációja alapján.
A minőségi primitív mutatók közvetlen mérése a jellemző egységek, objektumok, szerkezetek stb. programdokumentumában előforduló előfordulások számának megszámlálásával, valamint különféle eszközök üzemidejének és térfogatának mérésével történik. használt memória tesztesetek végrehajtásakor. Például a memória hatékonyságának bizonyos mértéke lehet egy program sorainak száma egy programozási nyelvben, és az időhatékonyság bizonyos mértéke lehet a lekérdezésre adott válaszidő. A minőségi primitívek bármely mutatójának használatát az MS minőségi specifikációjában lehet meghatározni. A minőségi primitív mutatók közvetlen mérésének módszere kombinálható a programteszt használatával.
Bizonyos szoftvereszközök használhatók annak meghatározására, hogy egy MS rendelkezik-e bizonyos minőségi primitívekkel. Az ilyen szoftvereszközök programszövegeket vagy szoftverdokumentációkat dolgoznak fel annak érdekében, hogy ellenőrizzék a minőségi primitíveket, vagy megszerezzék e minőségprimitívek néhány mutatóját. A PS programok strukturáltságának felméréséhez, ha az alap programozási nyelv megfelelő strukturális dialektusában lettek programozva, akkor elegendő lenne egy strukturált programkonvertálón átvezetni, amely elvégzi ennek a nyelvjárásnak a szintaktikai és némi szemantikai vezérlését, és lefordítja a nyelvi szövegeket. ezeket a programokat az alap fordító beviteli nyelvére. Azonban jelenleg csak kis számú minőségi primitív irányítható így, és akkor is ritka esetekben. Egyes esetekben a szoftver minőségét szabályozó szoftvereszközök helyett hasznosabb olyan eszközöket használni, amelyek átalakítják a programok megjelenítését vagy a programdokumentációt. Ilyen például egy programformázó, amely a programszövegeket olvasható formába hozza – a PS-programok szövegeinek ilyen eszközzel történő feldolgozása automatikusan biztosíthatja, hogy a PS megfelelő minőségű primitívvel rendelkezzen.
A tesztelést a PS-minőség bizonyos primitíveinek értékelésére használják. Az ilyen primitívek elsősorban a PS teljességét, valamint pontosságát, stabilitását, biztonságát és más minőségi primitíveket tartalmaznak. Egyes esetekben a tesztelést más módszerekkel kombinálva alkalmazzák az egyes PS minőségi primitívek értékelésére. Tehát a PS (P-dokumentáció) használatára vonatkozó dokumentáció minőségének értékeléséhez a tesztelést a dokumentáció szakértői értékelésével kombinálják. Ha a PS komplex hibakeresése során kellően teljes tesztelést végeztek, akkor ugyanezek a tesztek használhatók a PS tanúsítása során is. Ebben az esetben a tanúsító bizottság használhatja a komplex hibakeresés során végzett tesztelési protokollokat. Azonban még ebben az esetben is el kell végezni néhány új tesztet, vagy legalább újra le kell futtatni néhányat a régiek közül. Ha az összetett hibakeresés során végzett tesztelés nem eléggé teljes, akkor teljesebb tesztelést kell végezni. Ebben az esetben döntés születhet a PS összetevő- vagy rendszertesztjének elvégzéséről, valamint a PS visszaküldéséről a fejlesztőknek felülvizsgálatra. Nagyon fontos, hogy a PS-nek a könnyű használhatóság kritériuma szerinti értékeléséhez (a PS hibakeresése és tanúsítása során) teljes körű tesztelés történjen a pályázati dokumentáció alapján elkészített teszteken, ill. a karbantarthatósági kritériumhoz - a karbantartásra javasolt dokumentumok mindegyikéhez elkészített teszteken.
A PS minőségi primitívek többségének értékeléséhez jelenleg csak a szakértői értékelés módszere használható. Ez a módszer a következőkből áll: kijelölnek egy szakértői csoportot, amelyek mindegyike a benyújtott dokumentáció áttanulmányozása eredményeként véleményt nyilvánít a PS szükséges minőségi primitív birtoklásáról, majd a szükséges értékelést. A PS minőségprimitíve e csoport tagjainak szavazatával jön létre. Ez az értékelés elvégezhető kétpontos rendszerben ("birtokolja" - "nincs"), és figyelembe veheti a PS birtoklási fokát ezzel a minőségi primitívvel (például ötösön is elvégezhető). -pontrendszer). Ugyanakkor a szakértői csoportot ennek a primitívnek a specifikációjától és az értékelési módszer megjelölésétől kell vezérelnie, amelyet a tanúsított PS minőségi előírása tartalmaz.
Irodalom a 14. előadáshoz.
14.2. V. V. Lipaev. Program tesztelés. - M.: Rádió és kommunikáció, 1986. - S. 231-245.
14.3. D. Van Tassel. Stílus, fejlesztés, hatékonyság, hibakereső és tesztelő programok. - M.: Mir, 1985. - S. 281-283.
14.4. B. Schneiderman. A programozás pszichológiája. - M.: Rádió és kommunikáció, 1984. - S. 99-127.
15. előadás Szoftverfejlesztés tárgyi megközelítése
15.1. Objektumok és relációk a programozásban. A szoftverfejlesztés tárgyi megközelítésének lényege.
A minket körülvevő világ tárgyakból és a köztük lévő kapcsolatokból áll. Egy objektum valamilyen entitást testesít meg, és van valamilyen állapota, amely idővel megváltozhat más objektumok hatására, amelyek valamilyen módon együtt vannak az adatokkal. Lehet belső szerkezete: állhat más objektumokból is, amelyek szintén valamilyen kapcsolatban állnak egymással. Ebből kiindulva lehet tárgyakból felépíteni a világ hierarchikus struktúráját. A körülöttünk lévő világ minden egyes konkrét megfontolásánál azonban egyes objektumok oszthatatlannak ("pontnak") minősülnek, és a mérlegelési céloktól függően az ilyen (oszthatatlan) különböző hierarchiaszintű objektumok is elfogadhatók. Egy reláció kapcsol össze néhány objektumot: úgy tekinthetjük, hogy ezen objektumok egyesülése rendelkezik valamilyen tulajdonsággal. Ha egy reláció n objektumot köt össze, akkor egy ilyen relációt n-helynek (n-ary) nevezünk. A tetszőleges kapcsolattal összekapcsolható objektumok minden egyes asszociációs helyén különböző objektumok lehetnek, de egészen határozottak (ebben az esetben azt mondják: egy bizonyos osztály objektumai). Az egyhelyes relációt egy objektum (a megfelelő osztály) tulajdonságának nevezzük. Egy objektum állapotát tanulmányozhatjuk az objektum tulajdonságainak értékével, vagy implicit módon egy adott egy vagy másik relációhoz kapcsolódó objektumok unióinak tulajdonságaival.
A körülöttünk lévő világ megismerésének vagy megváltoztatásának folyamatában mindig figyelembe vesszük a világ egyik vagy másik leegyszerűsített modelljét (modellvilág), amelybe belefoglaljuk a körülöttünk lévő világ egyes tárgyait, viszonyait, ill. általában a hierarchia egy szintje. Minden belső szerkezettel rendelkező objektum képviselheti a saját modellvilágát, beleértve ennek a szerkezetnek az objektumait és az azokat összekötő kapcsolatokat. A minket körülvevő világ tehát (bizonyos közelítéssel) modellvilágok hierarchikus struktúrájának tekinthető.
Jelenleg a minket körülvevő világ tanulásának vagy megváltoztatásának folyamatában a számítástechnikát széles körben alkalmazzák különféle információk feldolgozására. Ebben a tekintetben az objektumok és kapcsolatok számítógépes (információs) reprezentációját használják. Minden objektum információsan ábrázolható valamilyen adatstruktúrával, amely megjeleníti az állapotát. Ennek az objektumnak a tulajdonságai beállíthatók közvetlenül a struktúra különálló összetevőiként, vagy ezen az adatszerkezeten speciális funkciókkal. Az N>1-re vonatkozó N-számú relációkat akár aktív, akár passzív formában ábrázolhatjuk. Aktív formájában az N-helyes relációt valamilyen programrészlet képviseli, amely vagy egy N-hely függvényt (amely az objektumok megfelelő uniójának tulajdonságának értékét határozza meg) vagy egy eljárást, amely megváltoztatja egyesek állapotát. a reprezentált reláció által összekapcsolt objektumok reprezentációinak állapotáról. Passzív formában egy ilyen relációt egy bizonyos adatszerkezettel lehet ábrázolni (amely magában foglalhatja az ezzel a relációval összekapcsolt objektumok reprezentációit), amelyet az általános eljárásokra vonatkozó elfogadott megállapodások alapján értelmeznek, amelyek függetlenek a konkrét relációktól (pl. relációs adatbázis). A kapcsolat ábrázolása mindkét esetben meghatároz bizonyos adatfeldolgozási tevékenységeket.
A modellvilág felfedezése során a felhasználó különböző módokon kaphat (vagy szeretne kapni) információkat a számítógéptől. Az egyik megközelítés szerint érdekelheti, hogy információkat szerezzen az őt érdeklő tárgyak egyedi tulajdonságairól vagy egyes objektumok közötti kölcsönhatás eredményeiről. Ehhez elrendeli az őt érdeklő funkciókat ellátó egyik vagy másik PS, vagy valamilyen információs rendszer kidolgozását, amely képes információt kiadni a számára érdekes kapcsolatokról a megfelelő adatbázis segítségével. A számítástechnika fejlődésének kezdeti időszakában (a számítógépek nem elég nagy teljesítménye mellett) a számítógéphasználat ilyen megközelítése teljesen természetes volt. Ő volt az, aki kiváltotta a PS fejlődésének funkcionális (relációs) megközelítését, amelyről a korábbi előadásokban részletesen szó esett. Ennek a megközelítésnek a lényege a függvények (relációk) dekompozíciójának szisztematikus felhasználása a PS és a benne foglalt programszövegek szerkezetének felépítésére. Ugyanakkor magukat az objektumokat, amelyekre a megrendelt és megvalósított funkciókat alkalmazták, töredékesen (a funkciók ellátásához szükséges mértékben) és e funkciók megvalósításához alkalmas formában mutatták be. Így a felhasználó érdeklődésére számot tartó modellvilág teljes és megfelelő számítógépes ábrázolása nem biztosított: a használt PS-en való megjelenítése meglehetősen munkaigényes feladatnak bizonyulhat a felhasználó számára, kísérletként a modell mennyiségének és jellegének kismértékű bővítésére. információkat a felhasználót érdeklő modellvilágról. Az ilyen alállomásról érkezők komoly modernizációjukhoz vezethetnek. A PS fejlesztésének ezt a megközelítését a legtöbb használt támogatja programozási nyelvek, kezdve az assembly nyelvektől és az eljárási nyelvektől (FORTRAN, Pascal) a funkcionális nyelvekig (LISP) és a logikai programozási nyelvekig (PROLOGUE).
A modellvilág számítógépes tanulmányozásának egy másik megközelítésével a felhasználót érdekelheti az objektumok állapotváltozásának megfigyelése az interakciók eredményeként. Ehhez a felhasználó számára érdekes objektum meglehetősen szilárd ábrázolására van szükség a számítógépen, és kifejezetten hozzá vannak rendelve azok a szoftverkomponensek, amelyek megvalósítják azokat a kapcsolatokat, amelyekben ez az objektum részt vesz. Ennek a megközelítésnek a megvalósításához olyan szoftvereszközök kiépítésére volt szükség, amelyek szimulálják az objektumok közötti interakció folyamatait (modellvilág). A hagyományos fejlesztési eszközök segítségével ez meglehetősen fáradságos feladatnak bizonyult. Igaz, megjelentek olyan programozási nyelvek, amelyek kifejezetten az ilyen modellezésre koncentrálnak, de ez csak részben könnyítette meg a szükséges PS fejlesztésének feladatát. A probléma legteljesebb megoldása a PS fejlesztésének tárgyi megközelítése. Lényege az objektumok dekompozíciójának szisztematikus felhasználása a PS szerkezetének és a benne szereplő programok szövegeinek felépítésében. Ugyanakkor az ilyen PS által ellátott funkciók (relációk) különböző szintű objektumok relációin keresztül fejeződtek ki, vagyis ezek dekompozíciója jelentősen függött az objektumok dekompozíciójától.
Ha a tárgyi megközelítésről beszélünk, azt is világosan meg kell érteni, hogy milyen tárgyakról van szó kérdéses: a felhasználó modellvilágának objektumai, információ-ábrázolásukról, a programobjektumokról, amelyek segítségével a PS felépül. Ezenkívül különbséget kell tenni a tényleges objektumok ("passzív" objektumok) és az alanyok ("aktív" objektumok) között.
15.2. Tárgyak és tantárgyak a programozásban.
15.3. A szoftverfejlesztés objektív és szubjektív megközelítései.
Descartes megjegyezte, hogy az emberek általában objektum-orientáltan látják a világot (c).
Úgy gondolják, hogy az objektum-orientált tervezés a következő elveken alapul:
az absztrakciók kiemelése,
hozzáférési korlátozás,
modularitás,
hierarchia,
gépelés,
párhuzamosság,
fenntarthatóság.
De mindez funkcionális megközelítésben is alkalmazható.
Különbséget kell tenni az általános tárgyi megközelítés és speciális esete - a szubjektumorientált megközelítés - előnyei és hátrányai között.
Az általános objektív megközelítés előnyei:
A valós világ természetes feltérképezése a PS-struktúrán (a PS-képességek természetes emberi érzékelése, nem kell "feltalálni" a PS-struktúrát, hanem természetes analógiákat kell használni).
A PS kellően értelmes szerkezeti egységeinek használata (egy objektum, mint a nem redundáns asszociációk, információerős modulok integritása).
A szoftverfejlesztés komplexitásának csökkentése az absztrakciók új szintjének alkalmazásával (a szoftverfejlesztésben a „nem program” absztrakciók hierarchiájának alkalmazása: a valós világ objektumainak osztályozása, a természetben található analógiák módszere), mint a program új szintje. öröklés.
15.4. Objektum megközelítés külső leírás és szoftverarchitektúra fejlesztéséhez.
Az objektumorientált tervezés olyan módszer, amely objektumbontást használ; Az objektum-orientált megközelítésnek megvan a maga rendszere szimbólumokés logikai és fizikai modellek gazdag készletét kínálja rendkívül összetett rendszerek tervezéséhez. .
Az objektumorientált elemzés (OOA) az objektum megközelítést jelenítette meg. Az OOA célja a valósághoz közelebb álló modellek létrehozása objektum-orientált megközelítéssel; ez egy olyan módszertan, amelyben a követelményeket a tantárgyi terület szókincsét alkotó osztályok és objektumok fogalmai alapján alakítják ki. .
Az objektum-orientált programozás jellemzői.
Objektumok, osztályok, objektumok viselkedése, tulajdonságai, események.
Irodalom a 15. előadáshoz.
15.1. K. Futi, N. Suzuki. Programozási nyelvek és VLSI áramkör. - M.: Mir, 1988. S. 85-98.
15.2. Ian Somerville. Szoftverfejlesztés. - Addison-Wesley Publishing Company, 1992. P. ?-?
15.3. G. Butch. Objektumorientált tervezés alkalmazási példákkal: per. angolról. - M.: Concord, 1992.
15.4. V.Sh.Kaufman. Programozási nyelvek. Fogalmak és alapelvek. Moszkva: Rádió és kommunikáció, 1993.
J. Hughes, J. Michtom. A programozás strukturális megközelítése. - M.: Mir, 1980. - p. 29-71.
V. Tursky. Programozási módszertan. - M.: Mir, 1981. - 90-164.
E.A. Zhogolev. A moduláris programozás technológiai alapjai // Programozás, 1980, 2. sz. - 44-49.
R.C. Holt. Számítógépes programok felépítése: Felmérés // Proceedings of the IEEE, 1975, 63(6). - p. 879-893.
G. Myers. Szoftver megbízhatóság. - M.: Mir, 1980. - p. 92-113.
I.Pyle. Az ADA egy beágyazott rendszernyelv. M.: Pénzügy és statisztika, 1984. - p. 67-75.
M. Zelkovets, A. Shaw, J. Gannon. A szoftverfejlesztés alapelvei. - M.: Mir, 1982, p. 65-71.
A.L. Fuksman. Szoftverrendszerek létrehozásának technológiai vonatkozásai. M.: Statisztika, 1979. - p. 79-94.
Rizs. 8.4. Példa a pszeudokód részletezésének egyik lépésére.
OKTATÁSI ÉS TUDOMÁNYOS MINISZTÉRIUM
DONYECKI NÉPKÖZTÁRSASÁG
ÁLLAMI SZAKMAI
OKTATÁSI INTÉZMÉNY
"DONYECKI IPARI ÉS GAZDASÁGI FŐiskola"
MUNKAPROGRAM
Nevelési gyakorlat UP.01
szakmai modul PM.01 Szoftvermodulok fejlesztése számítógépes rendszerekhez
szakterület 09.02.03 "Programozás számítógépes rendszerekben"
Összeállította:
Volkov Vladimir Aleksandrovich, a "legmagasabb kategóriájú szakember" minősítési kategória számítástechnikai tudományának tanára, "Donyecki Ipari és Gazdasági Főiskola" Állami Oktatási Intézmény
A programot jóváhagyta: Vovk Pavel Andreevich, az "Smart IT Service" igazgatója
| 1. A GYAKORLATI PROGRAM ÚTVÉNYE | |
| 2. A GYAKORLAT EREDMÉNYEI | |
| 3. A GYAKORLAT FELÉPÍTÉSE ÉS TARTALMA | |
| 4. A GYAKORLAT SZERVEZÉSÉNEK ÉS VÉGREHAJTÁSÁNAK FELTÉTELEI | |
| 5. A GYAKORLATI EREDMÉNYEK ELLENŐRZÉSE ÉS ÉRTÉKELÉSE |
1 OKTATÁSI GYAKORLATI PROGRAM ÚTVÉNYE FEL. 01
1.1 Képzési gyakorlat helye UP.01
A PM.01 "Szoftver szoftver modulok fejlesztése számítógépes rendszerekhez" szakmai modul UP.01 oktatási gyakorlat programja 09.02.03 "Programozás számítógépes rendszerekben" » kibővített csoport 09.00.00 "Számítástechnika és számítástechnika", a szakmai tevékenység fő típusának (VPD) elsajátítása szempontjából:
Szoftver szoftver modulok fejlesztése számítógépes rendszerekhez és a kapcsolódó szakmai kompetenciákhoz (PC):
| Végezze el az egyes komponensek specifikációinak kidolgozását. |
|
| Modulszinten kész specifikációk alapján szoftvertermék kód kidolgozása. |
|
| Végezze el a programmodulok hibakeresését speciális szoftvereszközök segítségével. |
|
| Végezze el a szoftvermodulok tesztelését. |
|
| A modul programkódjának optimalizálásához. |
|
| Tervezési és műszaki dokumentáció komponensek kidolgozása grafikus specifikációs nyelvek használatával. |
A PM.01 "Szoftverszoftver-modulok fejlesztése számítógépes rendszerekhez" szakmai modul UP.01 oktatási gyakorlati programja felhasználható az alkalmazottak szakirányú továbbképzésében és szakmai továbbképzésében 09.02.03 Programozás számítógépes rendszerekben középfokú ( teljes) általános műveltség. Munkatapasztalat nem szükséges.
1.2 Célok és célkitűzésekoktatási gyakorlat UP.01
A meghatározott típusú szakmai tevékenység és a vonatkozó szakmai kompetenciák elsajátításához a hallgató az UP.01 oktatási gyakorlat során köteles:
gyakorlati tapasztalattal rendelkezik:
a feladat algoritmusának kidolgozása és megvalósítása számítógépes tervezéssel;
modulszintű kész specifikáció alapján szoftver termékkód fejlesztése;
eszközök használata a szoftvertermék hibakeresésének szakaszában;
szoftvermodul tesztelése egy adott forgatókönyv szerint;
képesnek lenni:
elvégezni a programmodul kód fejlesztését modern programozási nyelveken;
külön modulként készítsen programot a kidolgozott algoritmus szerint;
hibakeresés és tesztelés a program modul szintjén;
szoftver dokumentációt készíteni;
eszközök használata a dokumentáció elkészítésének automatizálására;
tud:
a szoftverfejlesztés főbb szakaszai;
strukturális és objektum-orientált programozási technológia alapelvei;
a szoftvertermékek hibakeresésének és tesztelésének alapelvei;
a műszaki dokumentáció kidolgozásának módszerei és eszközei.
1.3 Hetek száma(órák) a program kidolgozásáhozoktatási gyakorlat UP.01
Már csak 1,5 hét, 54 óra.
2 A GYAKORLAT EREDMÉNYEI
A PM.01 "Szoftver szoftver modulok fejlesztése számítógépes rendszerekhez" szakmai modul UP.01 oktatási gyakorlatának eredménye az általános kompetenciák fejlesztése (OK):
| A gyakorlat eredményének neve |
|
| - |
|
| OK 2. Szervezzék meg saját tevékenységüket, válasszák meg a szakmai feladatok elvégzéséhez standard módszereket, módszereket, értékeljék azok eredményességét és minőségét. | |
| OK 3. Hozz döntéseket standard és nem szabványos helyzetekben, és vállalj felelősséget értük. | |
| OK 4. A szakmai feladatok hatékony végrehajtásához, szakmai és személyes fejlődéséhez szükséges információk felkutatása és felhasználása. | |
| OK 5. Az információs és kommunikációs technológiák alkalmazása a szakmai tevékenységben. | |
| OK 6. Dolgozzon csapatban és csapatban, hatékonyan kommunikáljon kollégákkal, vezetőséggel, fogyasztókkal. | |
| OK 7. Vállaljon felelősséget a csapattagok (beosztottak) munkájáért, a feladatok elvégzésének eredményéért. | - |
| képesítések |
|
| OK 9. Eligazodni a szakmai tevékenységben gyakori technológiaváltás körülményei között. |
szakmai kompetenciák (PC):
| A szakmai tevékenység típusa | Gyakorlati eredmények neve |
|
| A szakmai tevékenység fő típusának elsajátítása | helyi és globális számítógépes hálózatok erőforrásainak használata; adatfájlok kezelése helyi, cserélhető tárolóeszközökön, valamint helyi számítógépes hálózat lemezein és az interneten; dokumentumok nyomtatása, sokszorosítása és másolása nyomtatón és egyéb irodai berendezéseken. minden gyakorlati munkáról beszámoló formájában aktuális ellenőrzés. modul minősítő vizsga. |
|
| műveltség és a munkavégzés pontossága alkalmazási programokban: szöveg- és grafikus szerkesztők, adatbázisok, prezentációszerkesztő; az adatbázisok tartalmában történő információkeresés sebessége. |
||
| az e-mail beállítások, a szerver és a kliens szoftver pontossága és műveltsége: az információkeresés sebessége az internet technológiái és szolgáltatásai segítségével; az információk bevitelének és továbbításának pontossága és műveltsége internetes technológiák és szolgáltatások használatával. |
||
| műveltség az információk jogosulatlan hozzáféréssel szembeni védelmére szolgáló módszerek és eszközök használatában; korrektség és pontosság Tartalékmásolatés adat-helyreállítás; |
||
| a fájlrendszerekkel, különféle fájlformátumokkal, fájlkezelő programokkal való munka műveltsége és pontossága; |
||
| jelentések és műszaki dokumentációk karbantartása. |
3 A PROGRAM FELÉPÍTÉSE ÉS TARTALMAKÉPZÉSI GYAKORLAT FEL.01
3.1 Tematikus terv
| A generált kompetenciák kódjai | A szakmai modul neve | Időtartam, gyakorlatra van rendelve (hetekben, órák) | Dátumok |
| PC 1.1 - PC 1.6 | PM.01 "Szoftvermodulok fejlesztése számítógépes rendszerekhez" | 1,5 hét 54 óra |
3.2 Tartalom gyakorlása
| Tevékenységek | A munkakörök típusai | A tudományos tudományágak neve, témákat megjelölő interdiszciplináris kurzusok, munkatípusok elvégzésének biztosítása | Órák száma (hetek) |
|
| „A szakmai tevékenység fő típusának elsajátítása » | 1. téma. Bevezetés. Algoritmusok a problémák megoldására. Szerkezet lineáris algoritmus. Szerkezet ciklikus algoritmus. Egy szubrutin (függvény) algoritmusa. | Megszerzett ismereteket a speciális objektumok létrehozásának alapjairól | ||
| Tantárgy2 . Környezet Skratch (Scratch). | Megszerzett ismereteket a folyamatautomatizálási eszközök alapjairól Megszerzett ismereteket az objektumokra való animációs effektusok alapjairól; hiperhivatkozások és gombok használata; demo beállítás; különböző formátumokban mentett prezentációk. | MDK.01.01 "Rendszerprogramozás" | ||
| Tantárgy 3 . Képzési program készítése (lecke a tantárgyból). | Megszerzett ismereteket a processzorfüggvényekkel végzett adatelemzés alapjairól | MDK.01.02 "Alkalmazott programozás" | ||
| 4. téma. Játékprogram fejlesztés. | Ismereteket formált a végső jellemzők kiszámításának alapjairól | MDK.01.01 "Rendszerprogramozás" | ||
| 5. téma. Grafikus programozási nyelv LabVIEW. | Megszerzett ismereteket a processzorteszt létrehozásának alapjairól. | MDK.01.02 "Alkalmazott programozás" | ||
| Tantárgy 6. Alkalmazás készítése LabVIEW segítségével. | Kialakult ismerete a felhasználó rendszerrel folytatott párbeszédének alapjairól | MDK.01.02 "Alkalmazott programozás" | ||
| Tantárgy 7 A program egy töredékének újrafelhasználása. | Kialakult ismeretek a rendszer működtetőiről és funkcióiról. | MDK.01.02 "Alkalmazott programozás" | ||
| Tantárgy 8 Workshop a LabVIEW-ről. Munkavédelem a számítógéppel végzett munka során a felhasználó munkahelyén. | Megszerzett ismereteket elemi függvények számításáról. Munkavédelmi ismereteket szerzett. | MDK.01.02 "Alkalmazott programozás". OP.18 "Munkavédelem" | ||
| Tantárgy 9 Következtetések. Gyakorlati jelentés összeállítása. | Kialakulnak a számítástechnikai elemzési, problémamegoldási készségek, formálódnak a készségek. | MDK.01.01 "Rendszerprogramozás" MDK.01.02 "Alkalmazott programozás" MDK.04.01 "Irodai szoftver" |
4 SZERVEZÉSI ÉS VÉGREHAJTÁSI FELTÉTELEK
OKTATÁSI GYAKORLAT FEL. 01
4.1 Dokumentációs követelmények, gyakorláshoz szükséges:
A PM.01 szakmai modul UP.01 oktatási gyakorlatának munkaprogramja. A „Szoftvermodulok fejlesztése számítógépes rendszerekhez” a „Donyecki Ipari és Gazdasági Főiskola” Állami Szakképzési Intézmény által végzett középfokú szakemberek képzési programjának része a szakirányú középfokú szakképzés állami oktatási szabványával összhangban 2003.02.09. „Programozás számítógépes rendszerekben”, amely a szak tantervén alapul, munkaprogram az MDK.01.01 „Rendszerprogramozás”, MDK01.02 „Alkalmazott programozás” tudományágakban módszertani ajánlások a középfokú szakképzés oktatási programjait elsajátító tanulók gyakorlatának oktatási és módszertani támogatására.
4.2 A gyakorlat oktatási és módszertani támogatásának követelményei:
a jóváhagyott feladatok felsorolása munkatípusonként, útmutató a hallgatók számára a munkavégzéshez, ajánlások a gyakorlati beszámolók végrehajtására.
4.3 Logisztikai követelmények:
az ipari gyakorlat megszervezése tantermek és laboratóriumok jelenlétét igényli.
Irodai berendezések és munkahelyek:
ülőhelyek a létszámnak megfelelően (asztal, számítógép, szék);
tanári munkahely (asztal, számítógép, szék);
szekrény oktatási segédanyagok és információhordozók tárolására;
feladatok egyéni tanuláshoz, önálló munka és gyakorlatok megszervezéséhez, tanuló számítógépen;
referencia és módszertani irodalom;
rendszer-, alkalmazás- és képzési programok PC-hez optikai és elektronikus adathordozókon;
a tanulók munkavédelmi oktatásának folyóirata;
oktatási segédanyag készlet.
Technikai oktatási segédletek:
Oktatási számítógépek;
interaktív eszközök készlete (projektor, képernyő, hangszórók);
tűzoltó eszközök (tűzoltó készülék).
osztálytermi tábla;
személyi számítógép licencelt szoftverrel;
lézeres nyomtató;
A fejlesztőeszközök szekrényének és munkaállomásainak felszereltsége: személyi számítógépek (monitor, rendszeregység, billentyűzet, egér), oktatási és módszertani dokumentáció készlet, a tudományág tartalmának megfelelő szoftverek (programozási nyelvek héjai).
Az osztály összes számítógépe csatlakozik a helyi hálózathoz, hozzáfér a hálózati információtárolóhoz és hozzáféréssel rendelkezik az internethez.
Kommunikációs berendezések:
hálózati adapterek;
hálózati kábelek;
WiFi vezeték nélküli berendezés.
Alkatrészek hálózatok telepítéséhez, felszerelés a telepítéshez.
4.4 Oktatási kiadványok listája, Internetes források, kiegészítő irodalom
Fő források:
Olifer V.G. Hálózati operációs rendszerek: tankönyv egyetemek számára / V.G. Olifer, N.A. Olifer. - 2. kiadás - Szentpétervár: Péter, 2009,2008. - 668 p.:
E. Tanenbaum. OS. Fejlesztés és megvalósítás. Szentpétervár: Piter, 2006. - 568 p.
Pupkov K.A. A Unix operációs rendszer elsajátítása / K. A. Pupkov, A. S. Chernikov, N. M. Yakusheva. - Moszkva: Rádió és kommunikáció, 1994. - 112 p.
L. Beck Bevezetés a rendszerprogramozásba - M.: Mir, 1988.
Grekul V.I., Denishchenko G.N., Korovkina N.L. Információs rendszerek tervezése / Moszkva: Binom, 2008. - 304 p.
Lipaev, V. V. Szoftvermérnökség. Módszertani alapok [Szöveg]: Proc. / V. V. Lipaev; Állapot. un-t - Közgazdasági Felsőiskola. - M.: TEIS, 2006. - 608 p.
Lavrishcheva E. M., Petrukhin V. A. A szoftverfejlesztés módszerei és eszközei. - Tankönyv
Ian Somerville. Szoftverfejlesztés, 6. kiadás.: Per. angolról. – M. : Williams Publishing House, 2002.―624 p.
Excel 2010: professzionális programozás VBA-ban.: Per. angolról. - M.: LLC „I.D. Williams”, 2012. - 944 p. : ill. - Párhuzamos. cinege. angol
Fowler M. Refaktoring: Improving Existing Code. Angolból.—St. Petersburg: Symbol Plus, 2003.—432 p.
További források:
Volkov V.A. MÓDSZERTANI UTASÍTÁSOK a gyakorlati munka végrehajtásához a „Rendszerprogramozás” tudományágban, Donyeck: DONPEK, 2015.
Volkov V.A. Irányelvek tanfolyami projekt megvalósításához, Donyeck: DONPEC, 2015.
Internet- erőforrások:
Rendszerprogramozás [elektronikus erőforrás] / Hozzáférési mód: http://www.umk3.utmn.ru.
Szoftver és internetes források: http://www.intuit.ru
Irodalom tudományágonként - http://www.internet-technologies.ru/books/
Elektronikus tankönyv "Bevezetés a szoftverfejlesztésbe" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info
Elektronikus tankönyv "Programozási technológia" - http://bourabai.kz/alg/pro.htm
4.5 Oktatási intézményből és szervezetből származó gyakorlatvezetőkkel szemben támasztott követelmények
Az oktatási intézmény gyakorlatvezetőivel szemben támasztott követelmények:
mérnöki és oktatói kar: diplomások - interdiszciplináris kurzusok és általános szakmai tudományok tanárai. A megfelelő szakmai terület szervezeteiben szerzett tapasztalat kötelező.
Fő ipari képzés: 5-6 minősítési kategória elérhetősége kötelező szakmai gyakorlattal szakosodott szervezeteknél legalább 3 évente. A megfelelő szakmai terület szervezeteiben szerzett tapasztalat kötelező.
5 AZ EREDMÉNYEK ELLENŐRZÉSE ÉS ÉRTÉKELÉSE
OKTATÁSI GYAKORLAT FEL. 01
Beszámoló az oktatási gyakorlatról UP.01 - gyakorlati jelentés, a módszertani ajánlások követelményeinek megfelelően elkészítve.
| eredmények (elsajátított szakmai kompetenciák) | Alapvető mutatók a felkészülés eredménye | Formák és módszerek ellenőrzés |
| PC 1.1. Az egyes komponensek specifikációinak kidolgozása | A feladat algoritmusának kidolgozása és megvalósítása számítógépes tervezéssel | A hallgató tevékenységének szakértői megfigyelése és értékelése az oktatási program elsajátítása során a gyakorlati órákon, az oktatási és ipari gyakorlaton végzett munka során. |
| PC 1.2. Modulszinten kész specifikációk alapján szoftvertermék kód kidolgozása. | Ismerje a strukturális és objektumorientált programozási technológia alapelveit. A programmodul kód fejlesztésének elvégzése modern programozási nyelveken. |
|
| PC 1.3. Végezze el a programmodulok hibakeresését speciális szoftvereszközök segítségével | Végezze el a program hibakeresését és tesztelését modulszinten. |
|
| PC 1.4. Végezze el a szoftvermodulok tesztelését. | Készítsen programot a kidolgozott algoritmus szerint külön modulként. |
|
| PC 1.5. Végezze el a modulkód optimalizálását | Modulszintű kész specifikáció alapján szoftvertermék kód kidolgozása. |
|
| PC 1.6. Tervezési és műszaki dokumentáció komponensek fejlesztése grafikus specifikációs nyelvek segítségével | Ismerje a műszaki dokumentáció elkészítésének módszereit és eszközeit. Készítse el a szoftver dokumentációját. Használjon eszközöket a dokumentáció automatizálásához. |
A tanulási eredmények nyomon követésének és értékelésének formáinak és módszereinek lehetővé kell tenniük a hallgatók számára, hogy ne csak a szakmai kompetenciák kialakulását, hanem az általános kompetenciák és az azokat biztosító készségek fejlődését is ellenőrizzék.
| eredmények (általános kompetenciák elsajátítása) | Az eredmény értékelésének főbb mutatói | Az ellenőrzés és értékelés formái és módszerei |
| OK 1. Értse meg a lényegét és társadalmi jelentőségét jövőbeli szakma tartós érdeklődést mutat iránta. | A leendő szakma iránti állandó érdeklődés bizonyítása; - az elsajátított szakmai kompetenciák alkalmazásának érvényessége; | Szakértői megfigyelés és értékelés a gyakorlati órákon az ipari gyakorlaton végzett munka során; |
| OK 2. Megszervezi saját tevékenységét, meghatározza a szakmai feladatok ellátásának módszereit, módjait, értékeli azok eredményességét és minőségét. | A cél kitűzésének indoklása, a szakmai problémák megoldására szolgáló módszerek, módszerek kiválasztása és alkalmazása; Önelemzés elvégzése, saját munkájuk eredményeinek korrekciója | Értékelés gyakorlati órákon a munkavégzés során; Megfigyelés gyakorlat közben; Önelemzés |
| OK 3. Problémák megoldása, kockázatok felmérése és döntések meghozatala nem szabványos helyzetekben. | A standard és nem szabványos szakmai feladatok döntéshozatalának eredményessége meghatározott időn belül; A terv hatékonysága az elvégzett munka minőségének optimalizálására | A tanuló tevékenységeinek ellenőrzése eredményeinek értelmezése a feladatok elvégzése során |
| OK 4. A szakmai problémák felállításához, megoldásához, szakmai és személyes fejlődéséhez szükséges információk felkutatása, elemzése és értékelése. | A szükséges információk kiválasztása és elemzése az egyértelmű és gyors végrehajtás szakmai feladatokat, szakmai és személyes fejlődést | Szakértői értékelés a munkavégzés során; Önkontroll a problémafelvetés és -megoldás során |
| OK 5. Információs és kommunikációs technológiák alkalmazása a szakmai tevékenység javítására. | az információs és kommunikációs technológiák alkalmazásának képessége szakmai problémák megoldására | feladatok értékelése |
| OK 6. Csapatban és csapatban dolgozni, annak kohézióját biztosítani, hatékonyan kommunikálni a kollégákkal, vezetőséggel, fogyasztókkal. | Képes kölcsönhatásba lépni egy csoporttal, tanárokkal, ipari képzés mesterével | |
| OK 7. Tűzz ki célokat, motiváld a beosztottak tevékenységét, szervezd és irányítsd munkájukat a feladatok eredményéért való felelősségvállalással. | - a saját és a csapat munkájának eredményeinek önelemzése és korrekciója | A csoportban végzett munka előrehaladásának megfigyelése a termelési gyakorlat során |
| OK 8. Önállóan határozza meg a szakmai és személyiségfejlesztés feladatait, vegyen részt önképzésben, tudatosan tervezzen továbbképzéseket. | Önálló munka szervezése kreatív és szakmai arculat kialakítása érdekében; Önképzési és fejlesztési munka szervezése képesítések | Megfigyelés és értékelés az ipari gyakorlat folyamatában; Reflexiós elemzés (tanulói cselekvések algoritmusa); Gyakorlónapló; Diákportfólió-elemzés |
| OK 9. Készüljön fel a technológiaváltásra a szakmai tevékenységek során. | Innovációk elemzése a ruhadarabok fejlesztésére és gyártására szolgáló technológiai eljárások területén | Szituációs problémák megoldásainak értékelése; Üzleti és szervezeti-oktatási játékok; Megfigyelés, értékelés gyakorlati órákon, a gyártási gyakorlat során |