Programozás | Programozás-elmélet » Palócz Erika - A szoftverfejlesztés lépései

http://www.doksihu A szoftverfejlesztés lépései A PROGRAM valamely számítógép számára készült, az által végrehajtható lépések sorozatával leírt, tehát kódolt algoritmus. Programot valamilyen feladat megoldására készítünk (Általában nemcsak egyetlen konkrét feladat megoldására, hanem egy egész „feladatosztály” megoldására készítenek programot, vagyis a program, különböző input adatok esetén is képes azoknak megfelelően – megoldani a feladatot.) Elöljáróban soroljunk fel néhányat a programokkal szemben támasztott általános "külső" követelmények közül (ezek nem minden esetben követelmények, a felhasználónak lehetnek speciális igényei): ⇒ hordozhatóság: A program legyen minél függetlenebb a konkrét hardver adottságoktól, hogy más konfigurációban is használható legyen (fokozottan érvényes ez a grafikát használó programokra), esetleg működjék más operációs rendszerrel is. ⇒

felhasználó-barátság: A program a végfelhasználó számára egyértelmű üzeneteket jelenítsen meg a képernyőn, jól olvasható formában, szép képernyő-képpel. Legyen lehetőség a beviteli javításra, bonyolultabb inputok esetén kérjen jóváhagyást a begépelőtől. Ne a felhasználóval végeztessünk kódolást ("yes=1, no=0") ! A billentyűzettel, egérrel való munkához találjunk könnyen megjegyezhető billentyűkombinációkat, ikonokat! A programkészítést bonthatjuk a következő lépésekre: A feladat megfogalmazása (feladatspecifikáció) A probléma elemzése (problémaspecifikáció) Programtervezés Kódolás Ellenőrzés és hibakeresés Dokumentálás Kísérőfejlesztés és karbantartás A teljes programkészítésből a különböző lépések körülbelül a következő időigényűek: Specifikáció/Tervezés: 30-40 % Kódolás: 15-20 % Tesztelés/Hibakezelés: 30-40 % Dokumentálás: 10-15 % Mivel a változtatások költsége a

programkészítés lépéseinek előrehaladtával kb. egyenes arányossággal nő, fontos lenne, hogy legkésőbb a tervezés fázisáig történjenek változások. A FELADAT MEGHATÁROZÁSA (FELADATSPECIFIKÁCIÓ) Hétköznapi nyelven leírjuk, mi az, amit meg kell valósítani, pontosítjuk a feltételeket és rögzítjük azokat. Meghatározzuk, hogy milyen adatokat használunk fel (input) és milyen adatokat kell előállítanunk (output). Nagyon lényeges lépés, mert ha nem világos a megfogalmazás, akkor nem lehet egyértelmű a feladatmegoldás. Sajnos a megrendelő és a programozó között ez okozza a leggyakoribb gondot A http://www.doksihu A programkészítés lépései 2.oldal megrendelő utólag közölheti, hogy ezt ő nem is így gondolta. Minden programozónak saját érdeke, hogy a feladatot pontosan, jól értse meg és rögzítse. Tisztázni kell a felhasználói környezetet is; milyen hardver eszközökkel kell működnie a programnak, ill. milyen

felkészültségű ember fogja működtetni Mindezeket üzleti környezetben szerződésnek 1 is rögzítenie kell. A PROBLÉMA ELEMZÉSE: Megoldható-e egyáltalán a feladat. Ha igen, akkor milyen megoldási módok vannak Általában nagyon sokféle lehetőség kínálkozik. Cél, hogy a megoldási módszerek közül a legjobban alkalmazhatót válasszuk ki. Általában itt lehetőség adódhat magasabb matematikai ismeretek alkalmazására A megoldás kiválasztásánál figyelembe kell venni a hardver, szoftver adta lehetőségeket is. PROGRAMTERVEZÉS (PROGRAM DESIGN) Bonyolultabb, team-munkában készülő, ill. később továbbfejlesztendő programok esetén a programkészítés legdöntőbb lépése a programtervezés. Gyakran előfordul, hogy a program tervezését nem az végzi, aki a programot meg fogja írni. A program tervezésekor nem mindig veszik figyelembe a hardver-, ill. szoftver adottságokat, hanem általánosan készítik el a tervet, hogy a terv alapján

többféle környezetre is elkészíthető legyen ugyanaz a program. A programtervezés során lényegében két feladatot kell megoldani: • adatszerkezetek meghatározása és megvalósítása • algoritmus készítése Ezek megoldása történhet különböző sorrendben, de legtöbbször érdemes párhuzamosan végezni, a programtervezési módszertől függően. Adatbáziskezelő programok esetén általában az adatszerkezeteket rögzítik előbb, különleges (nem „típusfeladat”) programoknál pedig inkább az algoritmuskészítés vezeti a tervezés folyamatát. A szerződés rögzíti a megrendelő és a programozó adatait, a program által megoldandó feladatot, a megrendelő részére járó egyéb termékeket és szolgáltatásokat (dokumentáció, felhasználói kézikönyv, betanítás, tanácsadás, karbantartás, stb.), a megrendelőnek a program forgalmazására való jogát, a vállalási határidőt, mindezek árát, stb. 1 http://www.doksihu A

programkészítés lépései 3.oldal Az adatszerkezetek meghatározása és megvalósítása részletesebben a következőket jelenti: • Kimenő adatok rögzítése (mennyi adatot, milyen adatokat, milyen adathordozón, milyen formában kívánnak tőlünk) • Bemenő adatok rögzítése (felmérjük, hogy mennyi adat, milyen adatok, milyen adathordozón, milyen formában állnak rendelkezésre) • Közbülső adattárolás meghatározása (eldöntjük, hogy a feldolgozás során mennyi adatot, milyen adathordozón, milyen formában tárolunk) Mindehhez segítséget nyújt az ADATÁRAMLÁSI ÁBRA (data flow diagram) készítése. Ez a feldolgozás során az adatok áramlásának irányát, tárolását és a közben velük történő műveleteket mutatja. A következő példával bemutatjuk a szokásos jelöléseket: A nyilak az adatáramlás irányát, az íves keretek a velük végzett műveleteket, a vastag párhuzamos vonalak az adattárolást jelzik. Ha előfordulnak még

külső elemek, amelyek nem részei a rendszernek, de a program kommunikál velük, azokat szögletes kerettel (téglalap) jelöljük. A jól ismert folyamatábrának is van egy szabványos formája, amellyel az adatok transzformációját rögzíteni tudjuk: ADAT-FOLYAMATÁBRA. Tükrözi az adatok útját és azokat a programokat, melyek kezelik, felhasználják őket, sőt a hardware eszközök is leolvashatók az ábráról. Ez az ábrázolás segítséget nyújt az üzemeltetőknek is: (Az ábrázolással kapcsolatban megjegyezzük, hogy a szöveget az ábrákban kellene elhelyezni!) Az algoritmus elkészítése pedig magában foglalja az algoritmus elkészítését és vizsgálatát is. (Ez utóbbit a tervezéshez kapcsolódóan végezzük el, és „íróasztal-teszt”-nek is nevezzük.) Az algoritmus elkészítése talán a legnehezebb feladat, de segítségünkre vannak különböző programtervezési módszerek, amelyekből 50-nél is több létezik. Sok programtervezési

módszerhez tartozik jellegzetes formalizmus, amellyel az algoritmust leírhatjuk, ill. vannak általános algoritmus-leíró módszerek, amelyek közül választhatunk. Ezek segítségével módszertől függően szöveges, grafikus vagy vegyes formában rögzíthetjük az algoritmust. Érdemes ezt megtenni, mert később megkönnyíti az utólagos megértést, hibajavítást, és így a fejlesztői dokumentációban is helye van. Általunk már ismert algoritmus-leíró eszközök: pszeudokód, folyamatábra, struktogram (lásd külön jegyzetben). PROGRAMTERVEZÉSI MÓDSZEREK: Elsőként említsük meg a folyamatábra-módszert. Ez a programtervezés egyik legrégebbi módszere Ma már egyre kevésbé használatos, mert az újabb tervezési módszerek közelebb állnak a programozási nyelvekhez. Mivel ez a módszer a többivel ellentétben az algoritmus ábrázolását helyezi előtérbe a program felépítésével szemben, így a program megtervezéséhez kevesebb segítséget

nyújt és az ábra is nehezebben követhető. Ezért kisebb, egyszerűbb programoknál, ill strukturált programozást nem támogató nyelvek esetén használjuk csak. http://www.doksihu A programkészítés lépései 4.oldal A STRUKTURÁLT PROGRAMOZÁS lényegében az input-output adatok szerkezetéből származtatja a programszerkezetet, a feladatot e szerint részfeladatokra osztja, majd a részfeladatokkal ezt ismétli addig, amíg a feladatok elemi tevékenységekre bomlanak. Ezt a több lépéses programtervezési technikát top-down technikának (felülről lefelé haladó tervezésnek) hívják. Olyan programozási nyelvek használata esetén érdemes ezt alkalmazni, amelyben a részfeladatok megoldhatók alprogramokkal, unitokkal, stb. A top-down technika során tehát először megfogalmazzuk, mit kell megoldani, majd a részfeladatokra osztás, a finomítás lépései során eljutunk addig, hogy kialakuljon, hogyan kell azt megoldani. Szokás ezt a módszert a

következő módon ábrázolni, érzékeltetve a feladat lebontása során kialakuló fa-szerkezetet: Amint látszik, a lebontás, finomítás során újabb és újabb procedurális- és adatabsztrakciók kerülnek bevezetésre. A strukturált programozás részletes algoritmusának jellemző ábrázolási módja a struktogram. A strukturált programozáson belül külön ki lehet emelni a Moduláris programozást, amelyre a következők jellemzőek: (A modul részt, elemet jelent.) A feladatot a strukturált programozásból megismert módon, a top-down módszer segítségével részfeladatokra bontjuk; ha ezt úgy oldjuk meg, hogy a részfeladatok áttekinthetőek, egymástól viszonylag jól elhatároltak legyenek, akkor ezeket moduloknak hívjuk, és külön valósítjuk meg őket (például egy-egy eljárással). A modulok akkor jól elhatároltak, ha egy modul egy funkciót old meg. A modulokra jellemző a funkció (mi történik a modul végrehajtásakor - milyen adatokon

milyen műveleteket végez, milyen adatokat szolgáltat), a logika (a végrehajtás módja), és az interface (milyen a kapcsolata a többi modullal - az alatta, felette lévőkkel, és a külvilággal). Moduláris programot szokás többféleképpen ábrázolni: A modulok külön-külön és együttesen is tesztelhetők. Ha nincs készen minden modul, akkor is tesztelhetjük együtt őket dummy(ál)-modulok segítségével. Újabb modul beépítésekor ismét tesztelni kell az együttest, tehát fokozatos tesztelés valósulhat meg az integrációs szakaszban (egybeépítéskor). Az így kialakított modulok későbbi programokba is beilleszthetők lesznek, ezért is szükséges a pontos leírásuk. A JACKSON-MÓDSZER szintén a strukturált programtervezés egyik válfaja. Elsősorban adatfeldolgozási programokhoz fejlesztették ki, de később rendszerprogramozásban, szervezésben is használták. Abból indultak ki, hogy a program szerkezete a probléma szerkezetén alapuljon,

vagyis az (input-output) adatszerkezeteken. A tervezés menete ekkor a következő: definiáljuk az adatszerkezeteket, elemezzük őket, így kialakítjuk a programszerkezetet, a szükséges elemi funkciókat hozzárendeljük a megfelelő programkomponensekhez. Akkor célszerű alkalmazni ezt a módszert, ha az adatoké, nem pedig http://www.doksihu A programkészítés lépései 5.oldal az algoritmusé a fő szerep (az első ezer prímet nem így állítanánk elő). Ehhez a tervezési módszerhez tartozik saját ábrázolási forma, a Jackson-ábra. Jelölései: Például: elemi tevékenységek: 1) p:=0 2) n:=0 3) z:=0 4) szám beolvasása 5) inc(p) 6) inc(n) 7) inc(z) 8) p,n,z kiíratása A programtervezéshez kapcsolódóan a képernyőterveket is készítsük el! KÓDOLÁS, vagyis a forrásnyelvű program elkészítése. Ezt röviden kódnak, forrásnak, másképp forrásprogramnak, forrásszövegnek, programlistának, programszövegnek is nevezik, hiszen ez egy

szöveg(fájl). Kódolás előtt kiválaszthatjuk több programozási nyelv közül a legalkalmasabbat. Ha jó a terv, akkor a kódolás könnyű feladat. A programnyelvek fejlesztői környezetéhez mindig tartozik egy szövegszerkesztő (editor), amivel ez a munka kényelmesen elvégezhető, valamint help, amelyben sok, a kódolás folyamán felmerülő kérdésre választ találhatsz, ezek általában példákkal is segítséget adnak a kódolás elvégzéséhez. A kódoláshoz ismernünk kell az adott programnyelv s zi nt ak t i k áját, ennek leírását megtaláljuk a kézikönyvben (általában valamilyen metanyelv segítségével rögzítve). A fejlesztői környezet helpjében is szerepelnek, példákkal együtt. Ennek segítségével elkészítjük az adott nyelvnek megfelelő programszöveget, amely tartalmazza az algoritmust (is). A legtöbb programnyelvben a program szerkezetében külön részt foglal el az adatszerkezetek deklarációja. Minden programnyelv

lehetőséget ad arra, hogy a program szövegében (a továbbfejlesztésre gondolva, az adott programrészlethez) megjegyzéseket (commenteket) fűzhessünk, amelyek kizárólag e http://www.doksihu A programkészítés lépései 6.oldal forrásprogramnak a részei, a kész (lefordított) programban természetesen semmilyen szerepet nem játszanak. A programszövegben ezen kívül szerepelhetnek a fordítónak szóló utasítások, amelyekkel a fordítás módját határozhatjuk meg. Az algoritmus kódolásánál ismernünk kell a programnyelv adott implementációjának lehetőségeit: beépített eljárásait, függvényeit, stb. A programszöveggel kapcsolatban van néhány formai konvenció, aminek betartásával megkönnyíthetjük a későbbi lépéseknél adódó munkákat: • A programlista formailag igazodjon a program vezérlőszerkezeti felépítéséhez (illetve blokkstruktúrájához); "beljebbírás". Többféle használat közül is választhatunk, de azt

tartsuk be következetesen. • A változónevek utaljanak a tartalmukra, de ne legyenek túl hosszúak. • Ne legyenek túl hosszúak a kifejezések, de ugyanakkor az értékadások száma se legyen túl nagy. • A programnév utáni sorokban szokás a következőket megjegyzésként elhelyezni: néhány soros megfogalmazás arról, hogy a program milyen feladatot milyen módszerrel old meg, a programozó neve, a készítés dátuma, stb. Esetleg a kódolás idejére halasztott s z e ma nt i ka i elemek: Általában a kódolásnál kell ügyelni az olyan tartalmi apróságokra is, amelyekre a (vázlatosabb) programtervezésnél esetleg nem tértünk ki (jobb, ha ezek szerepelnek a programtervben, de általában itt sem késő utánagondolni): ∗ input-hibák kezelése, ∗ függvények, műveletek értelmezésével kapcsolatos futási hibák elkerülése, ∗ változók illegális értékadásának elkerülése, ∗ lebegőpontos műveletekből adódó pontatlanságok kiszűrése,

∗ a felhasználó-barátságot biztosító apróbb utasítások elhelyezése (például hosszabb ideig tartó műveletek közben a felhasználót tájékoztató felirat elhelyezése a képernyőn) ∗ file-kezeléssel kapcsolatos körültekintő megoldások ∗ stb. ELLENŐRZÉS ÉS HIBAKERESÉS A forrásprogram elkészülte után meg kell győződnünk annak helyességéről, illetve ha nem helyes, meg kell találnunk és ki kell javítanunk a hibákat. Egy program helyességét lehet matematikai eszközökkel (léteznek erre vonatkozó axiómák, tételek) bizonyítani. Az alapvető algoritmusokat éppen azért nevezik sokszor „programozási tételek”-nek, mert ezek helyességét matematikailag be lehet bizonyítani. Gyakorlati okokból azonban inkább teszteléssel ellenőrzünk. TESZTELÉS A program-helyességet általában teszteléssel ellenőrizzük. A tesztelés a matematikai igazolással szemben nem bizonyítja a program helyességét, csak azt mondhatjuk, hogy minél

körültekintőbb a tesztelés, annál valószínűbb, hogy a programban nem marad hiba. Sokféleképpen lehet a tesztelési módszereket csoportosítani; • A programterv vizsgálatát íróasztal-tesztnek szokás nevezni, és ezt még a tervezés időszakában végzik el (fehér doboz-módszerrel). • Statikus tesztelésnek is nevezik a forrásprogram ellenőrzését; ekkor összevetik a programtervvel (kódellenőrzés), megkeresik a fordítóprogrammal a szintaktikai hibákat és ellenőrzik a változók http://www.doksihu A programkészítés lépései 7.oldal használatát (formai ellenőrzés), a változók értékadásait és a vezérlőszerkezeteket (tartalmi ellenőrzés), valaki mást megkérnek arra, hogy nézze végig a listát (walk-through). • DINAMIKUS TESZTELÉS: Futtatással vizsgáljuk a különböző input adatokból előállt output adatokat. Vagyis a programot lefuttatjuk a jól összeállított tesztadatokkal, és a kapott eredményeket

összehasonlítjuk a vártakkal. A dinamikus tesztelésnek két alapvető fajtája van: fekete doboz módszer: Magát a programot fekete doboznak tekintjük; nem foglalkozunk a szerkezetével. Mivel minden adatra nem tudjuk kipróbálni a programot, ezért a lehetséges input adatokat (beleértve érvényes és érvénytelen input adatokat is) jellemzőik szerint csoportokra (ekvivalencia-osztályokra) osztjuk. Ezután a ekvivalencia-osztályok egy vagy néhány tagjával kipróbáljuk a programot. Ha a program jól/rosszul működik az osztály egy adatára, akkor a többire is valószínűleg ugyanolyan módon működne. A tesztelésnél használt adatok mennyisége és minősége közelítse meg a futtatáskor várhatóakat, hogy a program gyorsaságáról is képet kapjunk. Fehér doboz módszer: Figyelembe veszi a program szerkezetét, a program logikájához igazodik. Olyan input-adatokat kellene, összeállítunk, amelyek a program végrehajtódásakor annak összes ágát

lefedik. Ez bonyolult programok esetén többnyire gyakorlatilag kivitelezhetetlen, helyette sok módszert használhatunk, melyek közül megemlítünk kettőt: • Utasítások egyszeri lefedésének elve: A tesztadatokat úgy határozzuk meg, hogy a program minden utasítására ráfusson legalább egyszer (vagyis minden programágra kerülő adatok előforduljanak). • Döntés-lefedés: A programban szereplő összes döntésnél (elágazási feltételnél) legyen hamis és igaz is a feltétel. Nagyobb rendszerek esetén a program kereskedelmi forgalomba hozatalát kétlépcsős tesztelés előzi meg. A fejlesztők által végzett ellenőrzést (α-teszt) követően a programot átadják néhány kiválasztott felhasználónak (β-teszt), és az ő véleményük alapján még változtatnak a rendszeren. A β-tesztre bocsátott programot szokás β-verziónak nevezni. Sokszor egyetemek kapják meg, mivel ott a felhasználók egyben hozzáértők is. Sok esetben az Interneten

mindenki számára elérhetővé teszik a β-verzót („publikus βverzió”), így sok ingyentesztelőt szereznek, illetve felkeltik az érdeklődést a majdani program iránt HIBAKERESÉS Ha a tesztelésnél valamilyen hibát találunk, akkor szükségünk van a helyének meghatározására, hogy kijavíthassuk, ez a célja a hibakeresésnek. A hibakeresés megoldható a programfejlesztői környezet lehetőségeinek kihasználásával (TP-nál Iásd IDE). A HIBAKERESÉS MÓDSZEREI: Indukciós módszer: A rendelkezésre álló tesztelési tapasztalatokat rendszerezzük, s ezekből megpróbálunk következtetni a hibára. Ha jó ekvivalencia-osztályokat határoztunk meg, a hibás outputokból következtethetünk arra, hogy a program melyik ágán lépett fel a hiba. Dedukciós módszer: Az összes lehetséges hibaokot felsoroljuk, majd ezek körét szűkítjük. Visszalépéses módszer: A hiba helyétől visszafelé haladva vizsgáljuk a programot, és megpróbáljuk

megállapítani azt a pontot, ahol még nincs hiba. A HIBAKERESÉSI ESZKÖZÖK a programozási nyelvhez tartozó fejlesztői környezet lehetőségeitől függenek. Általában a következők használhatók: Kiíratás: A program több pontján elhelyezhetünk (ideiglenesen) kiíró utasításokat (ezek később törölhetők a programból, vagy comment-ekké tehetők), így futtatás közben láthatóvá tehetünk sok mindent (változókat, vagy, hogy melyik ágon fut a végrehajtás, stb.) Töréspontok elhelyezése: (a programfejlesztői környezettől függően TP-ban Ctrl-F8, BASlCben Stop vagy Break, dBASE-ben Pause, Wait vagy Esc-pel, a program esetleg folytatható Resume-mal.) Meg http://www.doksihu A programkészítés lépései 8.oldal lehet nézni a változók tartalmát, a file-ok állapotát a kívánt pillanatban, sőt szükség esetén módosíthatjuk is azokat, majd futtathatjuk tovább a programot. Nyomkövetés: Utasításonként (vagy blokkonként) hajtja végre

a programot, azok eredményéről tájékoztatást ad (Id.változók értékének követése) Állapotellenőrzés: Különböző feltételeket helyezünk el, amelyek a program változóira vonatkoznak, és figyeljük annak helyességét. Ezek megállítják a programot, vagy üzenetet küldenek Szemantikus hibák keresése: Átnézhetjük a program kritikus részeit a programozási típushibákra koncentrálva. Ilyenek például: gépelési hiba, azonosító hibás megadása, vezérlésátadási hiba, elágazási hiba, szervezési hibák, a ciklusszervezés hibái (rossz egymásbaágyazás, nem hajtódik végre, végtelen ciklus), inputadat hiba, változó hibái (nem kap kezdőértéket, értékhatáron kívüli értéket kap), aritmetikai és logikai kifejezések hibái, tömbökkel kapcsolatos hibák (méret, indexelés), eljárásokkal kapcsolatos hibák (paraméterátadási hiba), file-kezelési hibák (nyitás, zárás, olvasás, írás - itt is jól használható lehet néhány

direktíva fejlesztéskori alkalmazása, pl. R, I direktíva, Id fordító direktívák jegyzet) FORDÍTÁS (ÉS SZERKESZTÉS) A hibák kijavítása (és ismételt tesztelés) után sor kerülhet a futtatható program előállítására. Interpreter használata esetén ez egyszerű futtatást jelent, compiler esetén viszont fordítást 2. A fordítás célja a forrásprogram(ok)ból önállóan futtatható program előállítása. Némely nyelvek esetén ez egy lépésben (fordítás) történik, mások esetében viszont két lépésben (fordítás és szerkesztés) 3. Futtatható programot több, sőt különböző nyelveken megírt, lefordított programrészletekből is előállíthatunk, ekkor azonban szükség van a szerkesztésre is. 2 Valójában a programozó által megírt program fordítása és futtatása kétféle módon történhet: 1. compilerrel (fordító programmal): A compiler először egy szintaktikai ellenőrzést végez Ha nem talált hibát, a teljes programot

lefordítja, vagyis előállítja a gépi kódú programot. Amikor a programot futtatják, ez az (egyszer előállított) tárgyprogram fog futni. 2. interpreterrel (értelmező programmal): Az interpreter a forrásprogramot soronként fordítja le gépi kódra és hajtatja végre a processzorral. Így nem képződik tárgyprogram, mert a fordítás és futtatás egyszerre; soronként zajlik le Emiatt lehetséges, hogy valamelyik sorban szintaktikai hibát találva ott elakad a program. Az interpreterrel futtatott HLL-program végrehajtási ideje sokkal hosszabb (tipikusan 10-szeres). 3fordítás (compile): forrásprogram tárgymodul (object file) (*.OBJ) szerkesztés (link): tárgymodul végrehajtható modul (executive file) (*.EXE) http://www.doksihu A programkészítés lépései 9.oldal Itt most kitérnénk a TP programok lefordításának lehetőségeire: A TP-ban nem különül el a fordítás és szerkesztés, így a fordítás során a forrásprogramból (*.PAS)

futtatható program (*.EXE) válik Ehhez szükséges minden olyan object és programkönyvtár, amelyekben a hivatkozott eljárások, függvények, stb. megtalálhatók (például TPU-k, grafikus driverek, CHR-ek). A fordításra TP-ban két lehetőség van: az IDE segítségével: A fordítás az IDE-ben beállított paramétereknek, ill. opcióknak megfelelően történik (direktívák, alkönyvtárak elérési útjai, stb). Az IDE tartalmazza menüpontként a szükséges funkciókat (ld.IDE-jegyzetet is!): COMPILE: Az aktív ablakban lévő állományt (programot vagy unitot) fordítja, a DESTINATION beállításától függően lemezre vagy memóriába. Csak akkor fordítja le, ha a program hibátlan MAKE: Mint az előbbi, de unithasználat esetén, ha a forrásunit új, vagy újabb, mint a meglévő TPU-ja, akkor azt is újrafordítja. BUILD: Vizsgálat nélkül a használt unitok újrafordításával együtt fordítja le a programot. RUN: futtatást jelent, de előbb mindig

megtörténik a fordítás a MAKE szerint. TPC 4 programmal: Ha terjedelmes forrásprogramot szeretnénk fordítani, előfordulhat, hogy az IDE mellett szabadon maradó memória ehhez kevés lenne. Ekkor az IDE betöltése nélkül, a TPC paranccsal fordíthatjuk a programunkat. Így viszont nem használhatjuk ki az IDE-beli beállításokat, tehát mindent a parancs opciójaként kell megadni, például a direktívákat, szükséges állományok elérési útjait (directorykat), fordítás módját (compile, make, vagy build típusú legyen-e). A parancs szintaxisa: TPC [opciók] filenév[.kit] [opciók] , ahol az opciókat a szokásos módon / jel vezeti be, az opciók betűjelei pedig a kézikönyvben megtalálhatók, de logikusan illeszkednek az eddig ismertekhez (pl. a direktívák meghatározása itt is ugyanaz). PROGRAMOK DOKUMENTÁLÁSA A programokhoz érdemes elkészíteni a dokumentáció(ka)t. A használathoz szükséges dokumentáció biztosítása a program eladásánál

elengedhetetlen. A program értékét is jelentős mértékben megnöveli a dokumentáció, hiszen nagy segítséget nyújthat a felhasználónak, üzemeltetőnek egyaránt. Az illegális programmásolásnak pedig egy apró gátja, hiszen dokumentáció nélkül a program esetleg nem, vagy csak nehézkesen kezelhető. (Ezért találkozunk sokszor oly terjedelmes és nem szokásos méretű kötetekkel, azok fénymásolását is megnehezítendő.) A dokumentáció fajtáját az határozza meg, hogy kinek készül: • Fejlesztői (programozói) dokumentáció: Ha egy program úgy kerül eladásra, hogy annak fejlesztési jogait is megvásárolják, akkor ez elengedhet len. A programozónak érdemes enélkül is elkészítenie ezt a saját számára, hasznos lehet a továbbfejlesztésnél, karbantartásnál, felmerülő változtatások elvégzésénél. Tartalmaznia kell a részletes feladatspecifikációt; a program tervét; input-, output- terveket; az adatok leírását (milyen

változók milyen céllal); a programlistát (megjegyzésekkel, rövid magyarázatokkal, ha szükséges), a használt speciális nyelvi eszközök leírását; a tesztadatokat és a tesztelés eredményét. Mindezeket érdemes a tervezés közben is használt szabványos formalizmusokkal leírni, vagyis a dokumentálást végezhetjük a programtervezés megfelelő részeivel párhuzamosan. A fenti dokumentumok birtokában szükség esetén egy másik programozó is elvégezheti a későbbi módosításokat. • Felhasználói dokumentáció (user guide): 4Turbo Pascal Compiler http://www.doksihu A programkészítés lépései 10.oldal A mindennapi használathoz és a telepítéshez kapcsolódó tudnivalókat kell tartalmaznia. Részletesen leírja a program indítását és használatát, a menürendszerét, általában képernyőmintákkal, példákkal illusztrálva. Ezenkívül felsorolja a lehetséges hibaüzeneteket és ehhez kapcsolódóan a hibák elkerülésének,

kijavításának lehetőségeit. A dokumentációnak olyan részletesnek kell lennie, hogy a legkevesebb hozzáértéssel is használni lehessen, hiszen ez elsősorban nem szakembereknek készül. Olyan felhasználók esetén, ahol van külön munkatárs az üzemeltetési, operátori teendők ellátására (például többfelhasználós környezetben), szokás a felhasználói dokumentációt kettéválasztani üzemeltetői (operátori) illetve felhasználói kézikönyvre (user guide). Ebben az esetben az üzemeltetői kézikönyv tartalmazza a konfigurációval, telepítéssel, beállításokkal, indítással, paraméterezéssel kapcsolatos tudnivalókat, előírja a szükséges (archiválási, biztonsági mentések idejét, módját, menetét. A hibaüzenetekhez kapcsolódóan a hibák megszüntetésének módját szintén tartalmaznia kell. A felhasználói kézikönyvben ilyenkor már csak a szorosan vett alkalmazói tudnivalók (indítás, használat) szerepelnek.

KÍSÉRŐFEJLESZTÉS, KARBANTARTÁS A rendelkezésre álló fejlesztői dokumentumok alapján elvégezhető. Módosítás, kiegészítés esetén meg kell ismételni a programkészítés lépéseit, a változásokat bevezetve közben a fejlesztői dokumentációba