1. Önnek egy rendszer részeként olyan programot kell készíteni, amely egy a felhasználó által megadott mappa teljes tartalmát alkönyvtárakkal együtt átmásolja egy másik szintén a felhasználó által megadott helyre. Hogyan tervezné meg a felhasználó felületet, és ezt milyen módon választaná szét a programlogikától?

Információtartalom vázlata

–A rendszerelemek tartalmi tervezése– Feladat elemekre bontása

–Eszközkörnyezet meghatározása– A környezet adta lehetőségek feltárása

–Állománykezelés– Állományok másolása

–Eseménykezelés– A másolás folyamatának szemléltetése

–Felhasználói felületek– Folyamatjelző használata

A program működése szempontjából csak egy bejáró scriptet kell írni, mely a másolandó mappa teljes tartalmát beolvassa és abszolút elérési útvonallal letárolja. Az adatok mellé típusát is tároljuk, ami lehet mappa vagy fájl. Innentől kezdve már csak a könyvtárak létrehozása és az aktuális fájlok másolása történik.

A feladat részei: Programozási nyelv(ek) kiválasztása. Program futásához szükséges metódusok tervezése osztályba rendezve A felhasználói interfész egy másik osztályban való létrehozása Kapcsolat kialakítása az osztályok között Hibakeresés

A feladat megoldásához JavaScript és Php programozási nyelveket használnék. De mindkettővel külön-külön is megoldható a szerverbeállításoktól függően.

A másoló osztályunk funkciókra lebontva:

1.1 Másolandó mappa kiindulási helyének beállítása1.2 A célhely beállítása1.3 Mappaszerkezet bejáró függvény1.4 Minden elem külön letárolása tömbbe (az 1.3 folyamat hívja meg)1.5 A cél könyvtárban a mappák létrehozása és vele egy szinten lévő fájlok másolása

( megállapítja, hogy mappa vagy fájl az adott elem addig fut, amíg az összes elem létre nem jött vagy amíg nem kap hibát)

1.6 Könyvtár létrehozó függvény (1.5 hívja meg)1.7 Könyvtár ellenőrző függvény (1.5 hívja meg)1.8 Fájl másoló függvény(1.5 hívja meg)

1/42

1.9 Fájl ellenőrző függvény (1.5 hívja meg)1.10 Ciklus megszakító függvény (1.5 hívja meg)

Felületet létrehozó osztály:

2.1 Egy javaScriptes könyvtárfa rajz létrehozása bal oldalon (2.8 hívja meg)2.2 Egy jobb oldalon a fájlok kilistázása a JS-től kapott értékkel fejlécben a mappa

neve (2.8 hívja meg)2.3 Opció menüsort létrehozó (2.8 hívja meg)2.4 Másolandó elemek megjelenítése (2.8 hívja meg)2.5 Másolandó elemek listázása, másolással egy időben és ha sikeres a másolás egy

pipa ikon ha nem egy x kerül az aktuális név mellé. (2.8 hívja meg)2.6 Hibaüzenet generáló (a futó folyamat ekkor megszakításra kerül, 2.8 hívja meg)2.7 Sikeres üzenetgeneráló (a folyamat alatt nem történt hiba, 2.8 hívja meg)2.8 Az oldal részeinek összefűzése

Folyamatjelző megjelenítése pl.: megjeleníthetjük az átmásolandó fájlok számát és azt mennyi van kész eddig 2.5 de egyébként is folyamatosan jelennek meg a pipák a fájlok nevei mellett.

A szétválasztás megtörténik, amikor van egy osztály, amelyik a másolást végzi illetve egy, amelyik a felület létrehozásáért felelős!

2/42

2. Milyen módszerekkel optimalizálná egy már kész program futását, ha abban sokszor kell tömbökben, listákban keresni?

Információtartalom vázlata

–Programozási tételek (alapalgoritmusok)– Keresés, logaritmikus keresés

–Adatszerkezetek, objektumok– Tömbök, listák bejárása

–Programtervezési módszerek– Keresések optimalizálása

–Tesztelés, hibakeresés– Túlcsordulások kezelése

Kereső algoritmusok

Keresést rendezetlen és rendezett tömbökön is végezhetünk. Rendezetlen tömb esetén a keresés nehézkesebb, lassabb, de az egyéb tömbkezelő műveletek (pl. új elem beszúrás) egyszerűbbek. Rendezett tömb esetén gyorsabb a keresés, viszont a kapcsolatos tömbműveletek bonyolultabbak, hiszen pl. az új elem beszúrása után is meg kell tartani a tömb rendezettségét.

Lineáris keresés

A legegyszerűbb keresési algoritmus a lineáris keresés, amely rendezetlen tömbön dolgozik. A tömb első elemétől kezdve összehasonlítjuk a tömbelemeket a keresendő elemmel. A keresési ciklus akkor ér véget, ha valamelyik tömbelem megegyezik a keresettel, vagy, ha a tömb végére érünk. Az utóbbi esetben a keresett elem nincs a tömbben.A keresést célszerű do while ciklusban végezni, ekkor a ciklusfeltételbe beépíthető mind az elem megtalálásának, mind pedig az utolsó elem elérésének vizsgálata.Az 5. ábrán a keres függvény végzi a paraméterként átvett elem keresését.A függvény visszatérési értéke 1, ha megtaláltuk a keresett elemet, illetve 0, ha nem. Találat esetén az index változó paraméter tartalmazza a megtalált tömbelem indexét. A függvény a keresendő elemet és a tömb utolsó elemének indexét értékparaméterként veszi át. Az algoritmus onnan kapta nevét, hogy a keresések száma, és így a futási idő, lineáris függvénye a tömb elemszámának.

Logaritmikus keresés

A logaritmikus keresési algoritmus rendezett tömbön működik, így az előző módszernél lényegesen gyorsabb keresést tesz lehetővé. A keresendő elemet először a tömb középső eleméhez hasonlítjuk.Ha a két elem egyezik, megtaláltuk a tömbelemet, ha nem, a keresést abban a tömb félben folytatjuk, amelyet a középső és a keresett elem viszonya kijelöl.Ha a tömb, növekvő sorrendbe rendezett és a keresendő elem nagyobb, mint a középső elem, akkor a második tömbrészben, egyébként pedig az elsőben.A keresést akkor fejezzük be, ha megtaláltuk a keresett tömbelemet, vagy a tömbrész elfogyott.

3/42

Az összehasonlítások száma, így a futási idő az elemszám kettes alapú logaritmusával arányos, ami nagy elemszámok esetén lényegesen kisebb lehet, mint a lineáris keresés futási ideje. Létrehozni egy osztályt amelyben keresések lennének, így attól függően hogy rendezett vagy rendezetlen a tömb/lista a megfelelő keresést választhatnánk.

Mert ha rendezett, a leggyorsabb a logaritmikus/bináris keresés: kezdjük a tömb közepén a keresést.Ha nem ez a keresett elem, akkor megvizsgáljuk, a tömb alsó felébe esik-e, majd megfelezzük azt is, így folytatva a keresést egészen addig, míg meg nem találtuk a keresett elemet, vagy a vizsgált tömbrész már csak egyetlen elemet tartalmaz.

• Legrosszabb futási idő: log2(N) + 1 lépés• Átlagos futási idő: log2(N) lépés

algoritmusa:

START0.) i=n1.) i=i/2 (az középső elem indexe)2.) Az i-dik elem kulcsa összehasonlításra kerül a keresett elem kulcsával.3.) VIZSGÁLAT:• ha a kulcsok megegyeznek, a keresés sikeresen véget ért.• ha a kulcsok nem egyeznek, 4.) pont4.) VIZSGÁLAT• ha i = 1, a keresés sikertelenül végetér.5.) VIZSGÁLAT:• ha az i-dik kulcsnál nagyobb a keresett elem kulcsánál, akkor i = i + 1• ha az i-dik kulcsnál kisebb a keresett elem kulcsánál, akkor i = i – 16.) Ismételt végrehajtás az 1.) ponttól kezdve.END

Ha pedig rendezetlen az objektumunk, akkor ha eddig lineáris keresést használt (ha csak ezt tudod elmondani ezt mond el!) egy gyorsított szekvenciális keresést használnánk, aminek a lényege az hogy egymás után párokba ellenőrizzük az elemeket

algoritmusa:

START0.) i=-1 (az első elem indexe); a tömb végére egy fiktív rekord kerül, amelynek kulcsa egyezik a keresettkulccsal; a tömb elejére pedig egy olyan fiktív elem, melynek kulcsa semmiképp nem egyezik akeresett elem kulcsával.1.) i=i+1;2.) Az i-dik elem és az (i+1)-dik elem kulcsa összehasonlításra kerül a keresett elem kulcsával.3.) VIZSGÁLAT:• ha a kulcsok megegyeznek, a keresés sikeresen véget ért.• ha a kulcsok nem egyeznek, 3.) pont4.) Ismételt végrehajtás az 1.) ponttól kezdve.END

Ha pedig a tömb minimum vagy maximum értékét szeretnénk megállapítani, akkor azt egy n hosszúságú tömb legkisebb elemét n-1 összehasonlítással, majd a legnagyobbat ezután n-2 összehasonlítással megkereshetjük. Összesen 2n-3 összehasonlítás. Ahol a minimum vagy maximum értéket egy statikus változóban tároljuk és azzal hasonlítjuk össze.

4/42

Ha nagyon nem tudsz miről beszélni, legalább az alapfogalmakat ismertesd!!!

Adat• Deklarálnunk kell a programban használt:– Változók típusátA változó az adat tárolására alkalmas memória hely, melynek van:– Azonosítója, neve– Értéke– TípusaÖsszetett adatszerkezetek

TömbHa a tömbnek egy indexe van, akkor egy dimenziós tömb: vektorHa a tömbnek két indexe van, akkor két dimenziós tömb: mátrixIndex –egész számok sorozata

Tömbök feldolgozásaA tömbök feldolgozása szorosan összefügg a ciklusokkal• Tömb minden egyes elemét feldogozzuk– Számláló ciklus• Tömb elemein valamilyen tulajdonság meglétét vizsgáljuk– Elől- vagy hátul tesztelő ciklus

Láncolt lista• Akkor használjuk, ha a már tárolt adatok közé kell beszúrni új adatokat vagy a meglevő adatok közül kell törölniEgy lista elem két mezőből áll:– A tárolandó adat– Egy mutató• Mindig van egy lista fej– List első elemére mutat– Ha nincs elem, speciális elem: NIL

Egyirányú láncolt lista• A listában szereplő elemek láncot alkotnakLista utolsó eleme: a mutató NILA lista elemeit csak úgy érhetjük el, hogy a fejtől indulva végigmegyünk a lista elemein és minden elem feldolgozása után a következő elemre ugrunk. Egy elem egy rekord:– adat mező: maga a tárolandó adat– kovetkezo mező: a következő elem a listában

5/42

6/42

Tesztelés (4. tétel)Túlcsordulás nagyon primitíven:pl.: Ha egy egész változót 1 byte-on tárolsz akkor pl: változó = 200+200;Ez már túl is csordult, mert 255 lehet a maximális értéke. Jó esetben runtime hibát kapsz, rossz esetben a változó értéke valami szemét lesz, de biztosan nem 400.

7/42

3. Egy jogosultságokat is kezelő alkalmazásban milyen módszerrel oldaná meg, hogy az egyes felhasználói csoportok függvényében különböző legyen a felhasználói felület?

Információtartalom vázlata

–Szoftver architektúra kialakítása– Felhasználói interfész örököltetése, újrahasznosítása

–Kommunikációs kapcsolatok (felületek) fejlesztése– A felület azonos elemeinek megállapítása

–Rétegek típusai– A felhasználói felület és az üzleti logika szétbontása

A felhasználói jogosultságoknak megfelelően lehet megjeleníteni például menüpontokat, amelyik felhasználónak nincs joga, az nem is látja azokat amiket egyébként sem használhat!!!

(FORRÁS - 1144_06_3_Felhasználói_interfész.pdf)1-3 oldal

(FORRÁS - 1144_06_3_rétegek típusai.pdf)1-4 oldal

Felhasználói csoportokkal adnám a különböző jogokat. Az hogy mely csoportba tartozik a bejelentkezésénél egy munkamenet változóba tárolnám. Több osztályt hoznék létre attól függően hányféle csoport létezik. Az alapcsoport a jogok nélküli egyszerű látogatót takarná. Ebből származtatunk továbbá minden más osztályt. A piramisszerűen épülő csoportoknál az utolsó csoportból származtatunk. Ez nem végez semmilyen műveletet a megkapott adatokkal és nem lép kapcsolatba az adatbázissal, mindösszesen csak egy megjelenítést generál.

A grafikus felhasználói felület vagy grafikus felhasználói interfész (angolul graphical user interface, röviden GUI) a számítástechnikában olyan, a számítógép és ember közti kapcsolatot megvalósító elemek összessége, melyek a monitor képernyőjén szöveges és rajzos elemek együtteseként jelennek meg.A grafikus felhasználói felületeken alapvető szerepe van a mutatóeszközök, például az egér használatának, amelyekkel a grafikus felület elemei intuitív módon, a fizikai világ egyfajta modelljeként kezelhetők.A leggyakoribb grafikus felhasználói elemek az ablakok, menük, választógombok, jelölőnégyzetek és ikonok, valamint a mutatóeszközhöz kapcsolódó egérkurzor.

8/42

4. Egy program működése közben időnként hibák lépnek fel, de ezek nem rendszeresen következnek be. Milyen módszerrel keresné meg a hiba helyét?

Információtartalom vázlata

–Tesztelési ismeretek (teszttípusok)– Fekete doboz és fehér doboz módszer

–Szoftverkomponensek– Az egyes elemek kommunikációjának vizsgálata

–Tesztelés, hibakeresés– A hiba helyének szűkítése

–Alkalmazásfejlesztő eszközök– Debuggolás használata

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ÉSA 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 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 az 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

9/42

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.

10/42

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 ingyen tesztelőt szereznek, illetve felkeltik az érdeklődést a majdani program iránt.

HIBAKERESÉSHa 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 Lá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 hiba okot 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 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 (ld. 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.

11/42

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ást2. 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.

TESZTELÉS CÉLJA

• Helytelen szemlélet:– a szoftver hibamentességének bizonyítása, ill. a specifikált tulajdonságok megvalósításának bizonyítása.• Helyes felfogás:– a szoftvertesztelés a fejlesztett szoftvervégrehajtása azzal a céllal, hogy a benne levő hibákat, ill. a specifikációtól eltérő viselkedését felderítsük.

SZOFTVERRENDSZEREK TESZTELÉSE

• A szoftver fejlesztés célja:– a specifikációban leírt követelményeket kielégítő szoftver készítése.– Fejlesztés során különböző ellenőrző elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet:• Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk.• Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk.

12/42

5. Egy rendszer tervezésénél milyen módszerekkel tenné hatékonyabbá a benne lévő ciklusok futását?

Információtartalom vázlata

–Alapfogalmak (elágazás, ciklus stb.)– Ciklusok megállító feltételeinek vizsgálata

–Programozási tételek (alapalgoritmusok)– Keresések, rendezések gyors változatai

–Kódolás– Globális és lokális változók használata

Beszélhetsz a ciklusokról általában, típusok, mikor melyiket alkalmaznál For-t vagy While-t!!!Mindegyik algoritmusnál elmondhatod, hogy figyelsz ha a feladat megoldódott akkor kilépsz a ciklusból. Ha szükséges egy külön változóba tárolod pl. azt volt-e egy rendezésnél csere!

13/42

Itt pl.: a csere változó!Könyv vagy pl.: http://hu.wikipedia.org/wiki/Ciklus_(programoz%C3%A1s)Keresési algoritmusok 2. tétel.

14/42

Rendezési algoritmusok pl.:

Minimumkiválasztás (rendezett tömb): Megkeressük a legkisebb elemet kicseréljük az első elemmel, ezután a második helyre megint a legkisebbet és kicseréljük… Beszúró rendezés: mint amikor a kártyákat rendezzük, első majd második a helyére tesszük, majd felvesszük a harmadikat a helyére tesszük, majd a negyediket és így tovább, mint amikor kártyázunk és növekvő sorrendbe tesszük a lapokat!

Buborékos rendezés: Az első lépésben a legnagyobb elem „felszáll”.Összehasonlítjuk az első két elemet, ha az első nagyobb kicseréljük, ezután a 2. és a 3. elemmel csináljuk ezt majd sorba a 3-4, 4-5… amíg a tömb végére nem érünk! Második lépésben az utolsó előtti helyre keressük meg a legnagyobbat ugyanúgy ahogyan azt az előbb tettük….

Első sorban optimalizálnám a ciklus futásához szükséges feltétel(ek)et. Az egymásba ágazott ciklusok szétválasztása is megoldás lehet, mivel elég sok erőforrást igényelhet nagy adattömbök feldolgozásánál. Ekkor a metóduson belül vagy statikus változót vagy globális változót használhatunk. Ha a változó értéke csak a z osztály számára lényeges, akkor mindenféleképpen maradjunk a lokális változónál, mivel sok bonyodalmat tud okozni a globális változó. Legyen az változóütközés és máris hibás eredményeket kaphatunk. Ráadásul a lokális változó csak az adott objektum létezéséig él, utána a memória felszabadul, a globális változó viszont manuális úton kell felszabadítani. Ezért érdemes megfelelően kiválasztani, hogy statikus vagy globális változóban tároljuk az adatokat.Attól függően, hogy milyen utasítások futnak le a cikluson belül, azokat is lehet gyorsításra késztetni. Legyen ez keresés vagy rendezési folyamat.

Ha rendezésről beszélünk 2 -féle módszert használhatunk. Ezek a gyorsrendezés és a buborék rendezés.A buborék rendezésnek viszont egy javított gyorsított formájáról beszélhetünk, ami a kétirányú buborékrendezés egy csere változóval ellátva. Ez nagy adathalmazoknál jelentősen gyorsabb , mint a gyorsrendezés ráadásul ha kis tömbökről beszélünk akkor pedig elhanyagolható a quicksort előnye.

Java-ban a 2-s buborékrendezés:

void sort(int T[]){ int j; int limit = T.length; int st = -1; while (st < limit) { st++; limit--; boolean swapped = false; for (j = st; j < limit; j++) { if (T[j] > T[j + 1]) { int tmp = T[j]; T[j] = T[j + 1]; T[j + 1] = tmp; swapped = true; } } if (!swapped) { return; } else { swapped = false; } for (j = limit; --j >= st;) { if (T[j] > T[j + 1]) { int tmp = T[j]; T[j] = T[j + 1]; T[j + 1] = tmp; swapped = true; }

15/42

} if (!swapped) { return; } }}

A keresés már kicsit másabb mivel ott el kell különítenünk a rendezett vagy a rendezetlen objektumot egymástól.Mert a rendezett akkor a bináris (logaritmikus) keresés a leggyorsabb, de rendezetlennél a gyorsított szekvenciális a leghatékonyabb. (2 tétel)

16/42

6. Egy felhasználó nincs teljesen tisztában azzal, milyen programot is szeretne a munkájához használni. Ön fejlesztőként hogyan segítené a megfelelő rendszer kialakításában?

Információtartalom vázlata

–Rendszerek (elemek, jellemzők)– Az egyes programverziók lehetőségeinek vázlata

–Felhasználói igények feltárása, elemzése és csoportosítása– Interjú készítése

–A rendszerelemek tartalmi tervezése– Felhasználói képernyők kialakítása

–Rendszerfunkciók tervezése– Funkciók pontosítása

1144_06_3_szoftvertechnologia_Szabolcsi_Judit_1_lev.pdf 1-51144_06_3_Felhasználói_interfész.pdf1144_06_6_kapcsolat_a_megrendelővel.doc

17/42

7. Egy adatbázist használó program tervezésekor hogyan valósítaná meg az egyes programrétegek kommunikációját?

Információtartalom vázlata

–Rendszerek működésének tervezése– Közös elemek kialakítása, keretrendszer

–Alkalmazásfejlesztés lépései és feladatai– Eseménykezelés

–Rétegek típusai– Felhasználói felület, üzleti logika, adatbázis kapcsolat

1144_06_3_rétegek típusai.pdf

• A közvetlen adatkezelés (Dataprocessing): /ADATBÁZIS/Az alkalmazásnak ez a része végzi el a tárolt adatok fizikai feldolgozását: állományok nyitása, zárása, indexelések, a lekérdezések optimalizálása és futtatása, új adatok felvitele, meglévők törlése, módosítása, az adatok cache-elése, a zárolási konfliktushelyzetek feloldása. Ennek a résznek a megvalósítása függ az adatok tárolási módjától, azaz a használt adatbázis-formátumtól.

• Az alkalmazás-logika (üzleti logika) (Business logic):Ez a rész felelős a teljes alkalmazás helyes működéséért: biztosítja az adatok védelmét (felhasználói jogosultságok), elronthatatlanságát (integritását), hatékony és kényelmes kezelését (a m_veletek csoportosítása, tranzakció-kezelés (Tranzakciónak nevezzük az egyetlen logikai egységet képező adatbázis-kezelési műveleteket.Például egy banki átutalásban a forrás- és célszámla egyenlegeinek módosításai nem választhatók el egymástól (nem lehet „csak félig" átutalni).Vagy a tranzakció összes művelete megtörténik, vagy egyik sem. Egy hiba esetén a teljes tranzakció visszagörgetődik, beáll a tranzakció elindítása előtti konzisztens állapot.))Alkalmazás-logikának nevezzük az adatbázisra vonatkozó szabályok összességét, más szóval az adatbázis működési szabályait.Ezek között megtalálhatók a következők:

• Mezőszintű ellenőrzések: például a jegy csak 1 és 5 közötti lehet. • Rekordszintű ellenőrzések: például egy tanfolyam kezdeti dátuma <= végdátuma. • Hivatkozási integritás: például egy hallgató jegyét csak akkor lehet felvinni, ha a hallgató már

szerepel a nyilvántartásban. • Komplex ellenőrzések: például egy olvasó a könyvtárból maximum 4 könyvet kölcsönözhet ki. • Egyéb adatbázis működését befolyásoló eljárások: például egy újabb jegy felvitelénél újraszámoljuk

a VeszTantSzama mezőt.

18/42

• A felhasználói felület (User Interface):Ez a rész a felhasználóval való közvetlen kapcsolattartásért felelős. A felületnek minél tetszetősebbnek, barátságosabbnak, és ugyanakkor elronthatatlannak kell lennie.Az elronthatatlanság alatt itt a felhasználói felület elemeinek helyes működésére gondolunk. Az adatok helyességéért nem a felhasználói felület, hanem az alkalmazás-logika felel.Ehhez a három részhez még hozzátartozik egy utolsó, a tényleges tárolt adat (a fizikai adatbázis). Az alkalmazásnak (programnak, kódnak) azonban a konkrét adatok nem képezik részét.

Keretrendszer 15. tétel, mik ezek mire jók itt is használhatsz belőle!Kód újrahasznosítás.

19/42

8. Egy már kész rendszerhez telepítő programot készít. Mik egy ilyen program feladatai és hogyan oldaná ezt meg?

Információtartalom vázlata

–Eszközkörnyezet létrehozása– Tömörített állományok

–Állománykezelés– Könyvtárszerkezet kialakítása– Állományok másolása– Registry használata

–Szoftverkomponensek– Az IO komponensek használata

–Telepítő csomagok– Install és uninstall program kialakítása

1144_06_08_BE_DELPHY-maskepp.pdf

20/42

9. Egy rendszert kell dokumentálnia. Mik lesznek ennek a legfontosabb jellemzői? Milyen hátrányai vannak a nem megfelelő dokumentálásnak?

Információtartalom vázlata

–Dokumentálás (dokumentumtípusok)– UML diagramok fajtái

–Kódolás– Kommentezés módszerei

–Szoftverkomponensek– A rendszer architektúrájának felépítése

Források_UML mappa tartalmát megnézni megtanulni, (a 1147-esben rengeteg UML van, úgyhogy úgyis kelleni fog!)UML_jelölések.doc ezt minimum tudni lerajzolni is, hogy egy osztályt, öröklést interfészt miképp jelölünk! A többit felsorolni elmondani!Kommentezés lentebb! Nélküle a továbbfejleszthetőség, hibaelhárítás …stb lesz sokkal nehezebb.

UML diagramok fajtái

A Unified Modeling Language röviden UML, az objektumorientált programozás szabványos specifikációs nyelve. Az UML grafikus jelöléseket használ rendszerek absztrakt modelljének leírására. A szabvány UML jelölést használó diagramokat UML modelleknek nevezzük. Az UML az Object Management Group fejlesztése. Diagramok

Az UML 2.0 verzió 13 különböző diagramtípust definiál, melyek kategóriákba és alkategóriákba oszthatók:

21/42

Az UML 2.0 diagramok hierarchiája

Strukturális diagramok

A strukturális diagramok a modellezett rendszer elemeire vonatkoznak. Ezek altípusai a következők:

Osztálydiagramok

Az osztálydiagram egy statikus modell. A rendszerben használt osztályokat mutatja azok attribútumaival együtt. Az osztálydiagram tartalmazza továbbá az osztály szintű kapcsolatokat.

Komponensdiagramok

A komponensdiagram a rendszer fizikai komponenseit és az azok közötti függőségeket mutatja. Fizikai komponens például a file, a header, a modul, a csomag és a futtatható állomány is.

Összetett struktúradiagramok

Az összetett struktúradiagram (composite structure diagram) az osztályok belső szerkezetét mutatja és azt, hogy az adott szerkezet milyen kollaborációkat tesz lehetővé.

22/42

Telepítési diagramok

Egy deployment (telepítési) diagram

A telepítési diagramok (deployment diagram) a rendszerimplementációhoz használt hardvert, a hardverre telepített szoftverkomponenseket és azok viszonyát hivatottak reprezentálni.

Objektumdiagramok

A modellezett rendszer egy adott időpillanatbeli állapotát mutatják az objektumdiagramok. Az objektumdiagram pillanatfelvétel a rendszer állapotáról. Osztályok példányait és kapcsolatait jeleníti meg. Az objektumdiagram konkrétabb az osztálydiagramnál, mert objektumok példányainak a kapcsolatát írja le objektumosztályok kapcsolata helyett.

Csomagdiagramok

A csomagdiagram azt mutatja, hogy hogyan szerveződnek a szoftverelemek csomagokba illetve hogyan viszonyulnak ezek a csomagok egymáshoz.

23/42

Viselkedési diagramok

egy use case diagram

egy állapotgép diagram

A viselkedési diagramok azt írják le, hogy minek kell történnie a modellezett rendszerben:

Aktivitásdiagramok

Az aktivitásdiagramok a munkafolyamatot (idegen szóval workflow-t) modellezik.

24/42

Állapotgép diagramok

Az állapotgép diagramok a rendszer lehetséges állapotait és az azok közötti átmeneteket mutatják állapotgépes ábrázolással.

Use case diagramok

A use case diagramok fogalmazzák meg a rendszer használati eseteit.

Interakciós diagramok

Az interakciós diagramok fogalmazzák meg a rendszerelemek közötti kommunikációt. Ezeknek további altípusai léteznek:

Kommunikációs diagramok Interakciós Áttekintő diagramok (Az UML 2.0 verziótól) Szekvenciadiagramok UML időzítődiagramok (Az UML 2.0 verziótól)

Kritikák

Bár az UML széles körben elfogadott és használt szabvány, gyakran kritizálják az alábbi hiányosságai miatt:

Túl nagy és túl bonyolult: Az UML szabvány sok diagramot tartalmaz, amelyeknek egy jó részét alig használják, jó része pedig redundáns.

Pontatlan szemantika: Az UML szemantikát részben OCL-lel, részben angol nyelven, részben az UML-lel magával definiálják, és hiányzik a formális nyelveknél megszokott szigorú definíció. A jelenlegi UML szabvány, mint axiómarendszer, ellentmondásos is és nem is teljes.

Kommentezés:Fajtái:Dokumentációs -- a modul használói számára

Blokk kommentKiemelhető a kódból à Kész az API specifikáció!!! Pl. JavaDoc-kal dokumentáció generálható Szabad formátumú ismertető és standard tag-ek

Implementációs – a továbbfejlesztők számára Blokk-komment, egysoros: beszúrt, vagy trailing v, sorvégi

25/42

JavaDoc használata Java 24 óra alatt 487-492

/*** ez egy dokumentációs…* ez is*/

489. oldal tudni párat @author szerző@link a dokumentumra muatató URL@since bevezetés dátuma

A Java forráskódoknál 2 típusú kommentről beszélhetünk: implementációs, és dokumentációs kommentről. Implementációs kommentek a C++ -ból ismert /*...*/ és // által határolt kommentek. A dokumentációs kommentek (röviden: doc comments) csak a Java –ban találhatók meg. A doc commentek javadoc – kal HTML fájlokba húzhatók át.

Az implementációs kommentek az egyes implementációs részekhez tartózó magyarázatot tartalmazzák a forrásban. A doc commentek a kód specifikácóját írják le implementáció-független szemszögből olyan fejlesztőknek, akiknek a forráskód maga nem feltétlenül áll rendelkezésükre.

A kommentek rálátást adnak a kódra, és a rögtön a forrásfájlból kiolvasható plusz információt nyújtanak. A kommentek csak olyan információt tartalmazzanak, amelyek lényegesek, és szükségesek a kód olvasásához és megértéséhez. Például az adott package keletkezésére, illetve elhelyezkedésére a fálrendszerben ne hivatkozzunk kommentben.

Nem nyilvánvaló és nem triviális tervezési döntések rögzítése helyes és nélkülözhetetlen lehet, de a kódból tisztán kiolvasható információ duplikálása kerülendő. A redundáns információ könnyen elvesztheti aktualitását. Általában az ilyen, a kód módosításával könnyen érvényüket vesztő, a kódból könnyen levezethető “nem időt álló” információt tartalmazó kommentek kerülendők.

Megj.:Gyakori kommentek a kód szegénységét tükrözik. Ha kényszert érzünk komment beszúrására, először győződjünk meg, hogy a kód újraírással nem tehető-e világosabbá.

A kommentek ne legyenek “túldizájnolva” nagy keretező *-dobozokkal, soha ne tartalmazzanak speciális karaktereket mint pl. backspace vagy form-feed.

26/42

1.5.1 Az implementációs kommentformátum

4 féle implemetációs komment létezik: blokkomment egysoros komment “utánfutó” (trailing) komment sorvégi komment

1.5.1.1 Blokkommentek

A blokkomentek fájlok, metódusok, adatstruktúrák és algoritmusok leírására használatosak. Blokkomentek használhatók minden fájl elején, minden metódus előtt, illetve máshol, például metódusokon belül is. Az utóbbi esetben a kommentet a kód megfelelő szintjéhez kell igazítani.

A blokkomenteket egy üres sornak kell megelőznie, hogy elkülönüljön a kód többi részétől.

/* * Blokk komment.

*/

Ha a blokkoment “/*-“ karakterkombinációval kezdődik, akkor indent(1) futtatása esetén a kommen rész nem lesz újraformázva.

/*- * Blokk komment specialis formazassal* indent(1) figyelmen kivul hagyja* * one * two* three */

1.5.1.2 Egysoros kommentek

Rövid, egy sorba irható, a vonatkozó kód szintjére csúsztatott kommentek. Ha a komment nem fér egy sorba, blokkomentet kell használni. Egysoros kommentet üres sor előz meg. Itt egy példa egy egyoros kódba ágyazott mommentre:

if (condition) {

/* condition kezelese. */ ...}

27/42

1.5.1.3 “Utánfutó” (trailing) kommentek

Nagyon rövid kommentek, ugyanabban a sorban amiben a hozzájuk tartozó kódrészlet van. Az ilyen kommenteket elegendő mértékben el kell tolni, hogy jól elkülöníthetők legyenek az utasításoktól. Ha egy kódrészletben több ilyen komment is van, akkor tabulátorokkal egymáshoz kell őket igazítani.

Pl.:

if (a == 2) { return TRUE; /* specialis eset */} else { return isPrime(a); /* csk paratlanokra */}

1.5.1.4 Sorvégi kommentek

A // kommenthatároló egy egész sort, vagy csak egy sorrészletet is kikommentezhet. Nem célszerű több egymást követő soron keresztül használni szöveges megjegyzésként, de alkalmazható több, egymást követő kódsor (szekció) kikommentezésére.

Pl. a három fenti stílusra:

if (foo > 1) {

// csinalj valamit ...}else { return false; // Mond el miert itt lepsz ki.}//if (bar > 1) {//// // csinalj valami mast// ...//}//else {// return false;//}

1.5.2 Dokumentációs kommentek

A dolkumentációs kommentek Java osztályokat, interfészeket, metódusokat és mezőket írnak le. Minden egyes doc comment a /**...*/ komment határolókon belül van elhelyezve. Osztályonként, interfészenként, tagként (memberként) egy. Az ilyen kommenteket pontosan a deklaráció elején kell feltüntetni.

/** * A Matrix osztály a ... */public Matrix Pelda { ...

28/42

Nem feledendő, hogy a legfelső szintű osztályok és interfészek rögtön a bal margónál kezdődnek, míg a tagjaik beljebb rendezettek. A doc comment-ek első sora (/**) osztályoknál és interfészeknél szintén nincs beljebb tolva, a többi doc comment sor mindegyike 1 szóközzel beljebb kezdődjön (a csillag függőleges helzreigazítása). A tagok, (beleértve a konstruktorokat is) doc commentjeinek első sora 4 szóközzel kezdődik beljebb, a többi sor pedig öttel.

Amennyiben olyan információt szeretnénk közölni az adott osztályhoz, változóhoz, vagy metódushoz, ami nem megfelelő a dokumentációban történő publikáláshoz, használjunk implementációs blokkommentet, vagy egysoros kommentet rögtön a deklaráció után.

Doc commentek nem helyezhetők metódus-, vagy konstruktordefiníciós blokkon belülre, mert a Java a dokumentációs kommentet az első, a kommentet követő deklarációhoz fogja rendelni.

Lásd még: 1144-09.docx

29/42

10. Egy összetett felhasználó felületet kell terveznie. Ezt milyen szempontok alapján tenné meg, hogy az átlátható, logikus és felhasználóbarát legyen?

Információtartalom vázlata

–Az elemek formai meghatározása– Könnyen használható felület kialakítása

–Navigáció megtervezése– Ablakok nyitásának sorrendje

–Navigáció és interakciók fejlesztése– Események kezelése

–Felhasználói felületek– Ablakozó rendszer alapelvei

–Szerzői rendszerek– Grafikus rendszerek használata

1144_06_3_Felhasználói_interfész.pdf1144-10.docx1144_06_08_BE_DELPHY-maskepp.pdf 9 - 16.oldal

Egy felhasználóbarát felület jellemzői

Legyen szó egyszerű karakter felületről, vagy a legcsillogóbb grafikus rendszerről, az interaktív programokkal illetve kezelői felületekkel szemben támasztott követelmények azonosak. Az alábbiakban röviden felsorolt tulajdonságok szem előtt tartása természetesen nemcsak az operációs rendszerek kezelői felületénél, hanem minden program készítésénél hasznosak.

Könnyű legyen megtanulni. A menüszerkezetek szinte magukért beszélnek, míg egy billentyű kombinációt általában sokáig tart begyakorolni.

Méretezhető legyen. A kezdő felhasználó kapjon sok segítséget, de az örökös javaslatok, tanácsok ne háborgassák állandóan a tapasztalt felhasználót.

Lehessen visszavonni következmények nélkül a tévedésből kiadott, hibás utasításokat. Meg lehessen szakítani az elindított műveleteket végrehajtás közben is. (És a

megszakításnak természetesen ne legyenek káros következményei.) Legyen többszintű súgó (help) rendszer. Az ismerkedőknek szóló tankönyvtől (tutorial) a

részletes technikai leírásig (technical reference) minden szintet érdemes megvalósítani. A súgó rendszerben könnyen lehessen keresni, egyszerűen legyen előhívható. Meghívása esetén csak azok a részek legyenek láthatók, amelyek az adott szituációra alkalmazhatók.

Használata hasonlítson a nyelvhez. Az utasítások legyenek igék, a paraméterek főnevek. Minden utasításra legyen válasz! Nagyon elbizonytalanító érzés, ha begépelünk egy

parancsot vagy az egérrel rákattintunk egy ikonra és látszólag (vagy valójában) semmi sem történik. Ide tartozik az az eset is, ha egy folyamat hosszabb időt vesz igénybe, legyen valami jele annak, hogy éppen fut.

Hasonló funkciókat hasonló módon lehessen végrehajtani akkor is, ha a programok feladata alapvetően különbözik.

Ablakok elemei események akár PHP-ban vagy Java-ban. Mondd el a szakdolgozatod felépítését, ablakait, menüit stb.

30/42

11. Egy cégnél azt a feladatot kapja, hogy többnyelvű legyen a felhasználói felület. Milyen módszert használna ennek megvalósításához?

Információtartalom vázlata

–Rendszerek (elemek, jellemzők)– Adatbázis nyelvi tábláinak kialakítása

–Alkalmazásfejlesztés lépései és feladatai– Felület kialakítása, elemek szövegeinek cseréje

–Programtervezési módszerek– A felület elemeinek bejárása

1144_06_11.docx

3 -féle módon oldhatjuk ezt a feladatot. Minden esetben létrehozunk egy globális változót, vagy ha nem engedélyezett akkor egy munkamenet változóban tároljuk az éppen aktuális nyelvet.

Az első ami a szervernek a legkedvezőbb, az a nyelvi osztály létrehozása. Ez nem használ adatbázist ezáltal nincs is lekérdezés, mely gyorsítja a folyamatokat. Az osztály konstruktorában beállítjuk a használni kívánt nyelvet és kész is. Az objektum változóiban pedig letároljuk a megfelelő nyelven beírt kifejezéseket. Ennek az a hátránya hogy a híreket nem lehet többnyelvűsíteni.

A második lehetőség, ahol adatbázisban tároljuk a különböző nyelvi kifejezéseket. Itt fontos szerepet kap az adattábla kialakítása. A legcélszerűbb, ha létrehozunk egy szo_id, egy nyelv_id és egy print_word mezőt. Ekkor a szo_id szerepe a szó, kifejezés jelentésének elkülönítése a nyelv_id pedig a nyelvet választja ki, tehát egy szó_id-hez több nyelv_id fog tartozni. Ezzel annyi gondunk lehet, hogy pontosan tudnunk kell melyik szo_id milyen jelentést takar. Ezt érdemes a fejlesztőnek egy saját dokumentumban tárolni vagy a szo_id helyett lehet jelentes mezőnév alatt egyértelműsíteni a hordozott információt. Ezek után már csak egy nyelvi osztályra van szükségünk, ami küld egy lekérdezést az adatbázis fele az adott nyelvel ahonnan később a megjelenített szavakat fogjuk kinyerni ( jelentes/szo_id alapjan hivatkotzunk ). Ezt lehet optimalizálni hogy ne az összes rekordot olvassa ki az adott nyelvhez tartozóan hanem a betöltött oldalhoz szükséges adatok kerüljenek bele. Ekkor az alap szavakat lekérdezzük és tartalomfüggően pedig a továbbiakat egy másik lekérdezésben. A létrehozása kicsit hosszadalmasabb, de nagy nyelvi tábla esetében már célszerű ezáltal csökkenteni a szerver leterheltségét. Itt lehetőségünk van az egyszerű szerkeszthetőségre, további szavak hozzáadására illetve törlésére és nyelvfüggően tudjuk a híreket is elkészíteni.

A harmadik lehetőség egy hibrid, ahol a dinamikusan szerkesztendő, nyelvhez kötött szövegeket egy táblában tároljuk a többit pedig egy olyan nyelvi osztályban ahol a szavak mint változók szerepelnek. Ezáltal lényegesen csökkentjük a folyamat terhelését ami gyenge illetve nagy látogatottsággal rendelkező honlapok számára igen hasznos lehet.

Bármely típust használjuk a szavak beillesztése már egy külső interfészgeneráló osztály feladata. Mindenféleképpen legyen elkülönítve a megjelenítést szabályzó és a nyelvet beállító osztály, a hibalehetőségek egyszerűsítése és a továbbfejlesztés végett.

31/42

12. Egy Ön által fejlesztett programot többen is használnak egy helyi hálózatban. Milyen módon oldaná meg, hogy az új programverziók felhasználói beavatkozás nélkül jussanak el a kliens gépekre?

Információtartalom vázlata

–Rendszerek működésének tervezése– Frissítő program kialakítása

–Szoftver architektúra kialakítása– A rendszer egyes elemeinek kommunikációja

–Szoftverkomponensek– Dinamikus könyvtárak (dll) használata

–Telepítő csomagok– Új verzió lekérése

1144-12.docx a Microsoft miképpen oldja meg a frissítéseket, ezt átgondolni és ez alapján.A vázlatba leírtak alapján egyébként elég könnyen meg lehet oldani, fel van sorolva!!!

32/42

13. Egy adott rendszer fejlesztésénél milyen szempontok alapján választaná ki az adatbáziskezelő rendszert, a fejlesztő eszközt, illetve a programozási nyelvet?

Információtartalom vázlata

–Eszközkörnyezet meghatározása– Adatbáziskezelők, fejlesztőeszközök előnyei, hátrányai

–Rendszerek működésének tervezése– A létrehozandó rendszer optimális működésének feltételei

–Alkalmazásfejlesztő eszközök– Fejlesztő eszközök összehasonlítása

Minimum összehasonlítani pl.: PHP MyAdmin, Access, Delphi, JavaBean amiket tanultunk használtunk.

33/42

14. Egy program fejlesztőjeként milyen érvekkel győzné meg a fejlesztő cégét, hogy objektum-orientált módszert használjon a strukturált helyett?

Információtartalom vázlata

–Szoftver architektúra kialakítása– UML, objektumok kommunikációja

–Adatszerkezetek, objektumok– Objektumok használatának előnyei

–Programtervezési módszerek– Objektumok újrahasznosítása– Polimorfizmus

–Felhasználói felületek– Template felületek– Öröklések előnyei

Összehasonlítás az itt következő pár gondolat, és az OOP-ről lehet mindent ami eszedbe jut, amiket órán is csináltunk!

Az objektumorientált programozás (angolul object-oriented programming, röviden OOP) egy programozási módszer. Ellentétben a korábbi programozási nyelvekkel, nem a műveletek megalkotása áll a középpontban, hanem az egymással kapcsolatban álló programegységek hierarchiájának megtervezése. Az objektumorientált gondolkodásmód lényegében a valós világ lemodellezésén alapul – például egy hétköznapi fogalom, a „kutya” felfogható egy osztály (a kutyák osztálya) tagjaként, annak egyik objektumaként. Minden kutya objektum rendelkezik a kutyákra jellemző tulajdonságokkal (például szőrszín, méret stb.) és cselekvési képességekkel (például futás, ugatás). Az objektumorientált programozásban fontos szerep jut az úgynevezett öröklődésnek, ami az osztályok egymásból való származtatását teszi lehetővé: a kutyák osztálya származhat az állatok osztályából, így megörökölve és egyben kibővítve a kutyák tulajdonságait.

Analízisszintű gondolkodás [szerkesztés]

Egy szoftver fejlesztésének korai fázisaiban a megvalósítandó rendszer feladatait szeretnénk feltérképezni: a funkcionális és egyéb jellegű követelményeket. Más szóval, a kérdés ilyenkor az, hogy a rendszernek mit kellene tennie. Ilyenkor határozzuk meg a szoftver (formális és informális) specifikációját, majd abból kiindulva kezdjük magasabb szintű absztrakciók segítségével előállítani a rendszer modelljét, amely a konkrét megvalósítás alapját fogja képezni.

Tervezésszintű gondolkodás [szerkesztés]

A meglévő modell alapján a szoftver konkrét implementációjához (megvalósításához) vezető utat tervezzük meg. Ilyenkor arra keressük a választ, hogy a meghatározott specifikációt hogyan valósítsa meg a rendszer. Ezen a szinten már képbe kerülnek különböző alacsony szintű technikák is, mint például a kommunikációs protokollok, programozási nyelvek és technológiák.

34/42

Az OOP és a szekvenciális nyelvek különbségeiAz OOP és a szekvenciális nyelvek különbségei [[szerkesztésszerkesztés]]

A hagyományos, ún. szekvenciális programozási nyelvekben az utasítások sorról sorra, egymást követően hajtódnak végre. Ez annyit jelent, hogy a program egyes sorai egymásra épülnek: Ha az egyik sorban definiálunk egy változót, akkor a következő sorban is használhatjuk. Ezt az egyszerűséget megtöri az előre definiált rutinok és függvények használata, de még a ciklusokkal, illetve más vezérlési szerkezetekkel együtt is könnyen átlátható a forráskód struktúrája. Az ilyen nyelveknél ez felfogható előnyként is, azonban nagy projektekben kényelmetlenséget okozhat, hogy egy-egy alapvető algoritmust többször, többféleképpen is le kell írnunk, holott lényegi változtatás nincs benne. Ezt a problémát részben lehet szubrutinokkal és függvényekkel orvosolni, de az igazi megoldást az objektumok használata jelenti.

Az objektumközpontú probléma megközelítés alapjaiban megváltoztatja a programozással kapcsolatos gondolkodásmódunkat. Az objektumorientált programozás alapja, hogy az adatokat és az őket kezelő függvényeket egy egységbe „zárjuk” (encapsulation – egységbezárás). Az OOP másik fontos sajátossága az öröklődés (inheritance). Az öröklés azt jelenti, hogy egy osztályból kiindulva újakat hozunk létre, amelyek öröklik az „ősosztály” (baseclass) adattagjait és metódusait. Az új osztályt származtatott (derived) osztálynak nevezzük.

Mik is az objektumok valójában?Mik is az objektumok valójában? [[szerkesztésszerkesztés]]

Ha egy programkódban objektumokról beszélünk, először az osztályok felépítését kell megvizsgálni, ugyanis minden objektum egy előre definiált osztály példánya. Egy osztályban általában egy feladat elvégzéséhez szükséges kódrészleteket gyűjtik össze funkciójuk szerint, tagfüggvényekbe rendezve. Egy osztályt létrehozása után példányosítani kell, hogy használhatóvá váljanak a benne összegyűjtött rutinok. Az osztály példányát nevezzük objektumnak.

class A { }; //egy üres osztály

Az osztályok felépítéseAz osztályok felépítése [[szerkesztésszerkesztés]]

A használt programozási nyelvtől függően, de legtöbbször a class előtétszóval definiálunk osztályokat. Egy osztály csak függvényeket (metódusokat, tagfüggvényeket) és változókat (adattagokat) tartalmazhat. Mivel az osztályokban található függvényeket az objektumon keresztül lehet elérni, ezért hívják őket tagfüggvényeknek, vagy metódusoknak. Bizonyos nyelvek megengedik, az osztály függvényeinek használatát példányosítás nélkül is (például a C++-ban a statikus függvények). Ilyen esetekben azonban a függvény meghívásához meg kell adni annak az osztálynak a nevét, amelynek a metódus tagja.

Minden osztálynak van legalább egy konstruktora. Ez egy különleges függvény, amely az osztály példányosításakor hívódik meg. Feladata az osztály kezdőértékeinek beállítása, helyfoglalás a memóriában stb. Több konstruktort is megadhatunk, a fordító a szignatúrától függően választja ki a megfelelőt. A konstruktor párja a destruktor, ami az elfoglalt memóriát szabadítja fel, eltakarít maga után. Destruktorból pontosan egy darab van az osztályban. Néhány nyelvben (C#, Java) ún. „garbage collector”, „szemétgyűjtő” van, ami a program futása közben automatikusan szabadítja fel a nem használt memóriát.

35/42

Nyelvektől függően léteznek különböző osztályváltozók, melyek többnyire – a tagfüggvényekhez hasonlóan, csak az objektumon belül használhatóak. Például a C++ nyelvben ilyen a this változó (mutató), mely a példányosított osztály nevétől függetlenül mindig saját objektumára fog hivatkozni.

class A{ public: A() { this->msg = "Helló, világ!";} //konstruktor private: std::string msg;}; A* obj = new A(); //példányosítás

ÖröklődésÖröklődés [[szerkesztésszerkesztés]]

Egy osztály definiálása után előfordulhat, hogy az osztályban szereplő kódokat más osztályokban is használni szeretnénk. Például egy adatbázist, vagy mondjuk egy fájlkezelő függvényeket tartalmazó osztályt, valószínűleg más objektumokból is szeretnénk használni. Ehhez csak arra van szükség, hogy egy adott osztályt amiből a másik osztály tagfüggvényeit el akarjuk érni, abból származtassunk. Ezt nevezzük öröklődésnek.

class Base{ public: Base(){ }; void f(){ };}; class Derived : public Base{ public: Derived(){ };}; Derived* der = new Derived();der->f(); //A Derived osztály örökölte az f függvényt

Belátható, hogy az öröklődés használata rendkívül leegyszerűsíti a gyakran kellő függvények integrálását az egyes osztályokba anélkül, hogy meg kellene változtatni az osztályok struktúráját. Azokban a nyelvekben ahol esetleg nem valósították meg az öröklődést, van egy alternatív megoldás a problémára: Abban az osztályban, ahol használni szeretnénk egy másik osztály tagfüggvényét, egyszerűen példányosítanunk kell egy ősosztálybeli objektumot. Ennek a módszernek hátránya lehet, hogy egyes objektumokból esetleg több példány is lesz, ezáltal felesleges memóriát használ a programunk. Ezt kiküszöbölendő megtehetjük, hogy a használt osztályon kívül példányosítjuk a másik osztályt, és paraméterként adjuk át.

36/42

FelületekFelületek [[szerkesztésszerkesztés]]

A felületek, vagy más néven interfészek biztonsági segítséget jelentenek a nagyobb projektekben. Képzeljük csak el, mi történne, ha A objektum példányosításakor paraméterként átadunk neki egy másik, B objektumot, de B objektum nem valósítja meg hozzá fűzött reményeket, azaz nem tartalmaz egy változót, vagy függvényt, amire A osztálynak szüksége van! Az ilyen hibák felkutatása az OOP összetettsége miatt nem egyszerű, de az ilyen hibák felületek használatával elkerülhetőek.

A felület valójában előre meghatározza egy osztály felületét: Megadja a benne található tagfüggvényeket, azok nyilvánossági tulajdonságait, bemenő paramétereit, egyszóval a függvénytörzs kivételével mindent.

interface IF{ void f();}

Egy ilyen felület úgy véd meg a fent említett hibáktól, hogy az osztály definiálásakor megadjuk, milyen felületet kell megvalósítania. Ha a definiált osztály nem illeszkedik a felületre a fordító hibát jelez, de elkerüljük a sokkal kellemetlenebb futásidőben bekövetkező hibát. A fenti interfész az alábbi osztály „csontváza”:

interface ItestInterface{ void f();} class ImplementationClass : ItestInterface{ void IF.f(){;}} ImplementationClass ic = new ImplementationClass();ItestInterface itf = (ItestInterface) ic;itf.f();

Tervezési mintákTervezési minták [[szerkesztésszerkesztés]]

A tervezési minták lényegében azokra a problémákra nyújtanak általános megoldást, melyekkel a szoftverfejlesztők gyakran találkoznak. Ilyen probléma például, amikor egy adott környezetben már bevált kódot alkalmassá kell tennünk egy másik interfészen keresztül történő használatra is. Bár a probléma minden feladatnál egyedinek tűnik, egy idő után felismerjük, hogy a megoldási módszerek lényegében azonos sémát követnek. Így tehát, ha felfedjük egy probléma lényegét és összevetjük hasonló, már megoldott problémákkal, ugyanazokkal a lényegi lépésekkel találkozunk.

37/42

POLIMORFIZMUS:

Az objektumorientált polimorfizmusAz egybezártság és az öröklődés mellett a polimorfizmus az objektumorientáltság harmadik, és talán legszebb, legtermészetesebb tulajdonsága. A polimorfizmus (többalakúság, alakváltás) azt jelenti, hogy ugyanarra az üzenetre különböző objektumok különbözőképpen reagálhatnak, minden objektum a saját (az üzenetnek megfelelő) metódusával

Lásd még:1144_06_14_objektum_orientált_struktúrált.doc

38/42

15. Ön egy program fejlesztésének részeként keretrendszert ír. Mik azok a legfontosabb elvek, ami alapján kialakítja ezt?

Információtartalom vázlata

–Rendszerek (elemek, jellemzők)– Adatbázis-kapcsolatok, osztály-kapcsolatok– Sokszor használt elemek

–Kommunikációs kapcsolatok (felületek) fejlesztése– Adatérzékeny komponensek használata

–Alkalmazásfejlesztés lépései és feladatai– Redundáns részek kiemelése

Önmagában közvetlenül nem használható, de bizonyos tipikus feladatok elvégzését nagy mértékben segítő, egységes módon megszerkesztett "építőkockákat" (komponenseket) tartalmazó halmaz.

A keretrendszerek lényege, hogy a különböző alkalmazásokban leggyakrabban használt elemeket egyetlen helyre gyűjtik össze, és készen kínálják a fejlesztők valamint a programok számára, amelyek így rengeteg elvégzendő munkától mentesülnek.

Az alkalmazásfejlesztési keretrendszerek rendkívüli mértékben képesek munkánkat megkönnyíteni, meggyorsítani és hatékonyabbá tenni. Mégis többször is látom, hogy a fejlesztők egyáltalán nem használnak keretrendszereket a munkájuk során. Azt hiszem, hogy ennek a legfőbb oka, hogy magyarul eléggé ritkán lehet hozzájuk dokumentációt találni.

Alkalmazásfejlesztési keretrendszerek

A keretrendszerek képesek munkánkat megkönnyíteni, meggyorsítani és hatékonyabbá tenni

A keretrendszerek olyan alapelemeket biztosító rendszerek amelyek összetett feladatokat képesek megoldani. Egy vázat adnak alkalmazásaink számára, melyet a fejlesztőnek már csak tovább kell építenie.

Ha nézünk mondjuk egy webes alkalmazást akkor van jó pár olyan feladat amit az alkalmazás funkciójától függetlenül kezelnünk kell. Ilyenek például a rövid URL-ek, a munkamenetek kezelése, vagy éppen az adatbázis kapcsolatok és lekérdezések működtetése. A különböző keretrendszerek ezekre kínálnak kész megoldásokat.

39/42

Előnyök

A fentiekből egyenesen következik, hogy a keretrendszerek használatával sok fejlesztési időt takaríthatunk meg. Az időmegtakarítás egyrészt abból jön, hogy a sztenderd feladatokat a keretrendszer maga automatikusan megoldja. Másrészt, ami legalább ugyanannyira fontos, a keretrendszerek általában rákényszerítenek bennünket valamilyen kódolási és file struktúrálási sztenderdre. Így pár hónap múlva ha újra hozzá kell nyúlni a kódhoz, akkor egyértelműen tudni fogjuk, hogy mit hol keressünk. A sztenderdizálás további haszna, hogy jelentősen megkönnyíti a csoportmunkát. Röviden egy átláthatóbb, könnyebben fenntartható kódot kapunk.

Hátrányok

Tanulásukhoz idő kell. Talán ez az egyetlen hátrányuk. Tapasztalatom szerint egy keretrendszer megtanulására fordított idő rövid távon már az első projekt esetén megtérül, hosszú távon pedig összehasonlíthatatlan a különbség. Némely keretrendszer e mellett nem kellőképpen rugalmas, és az automatizált eljárások hatására időnként nem a legoptimálisabb háttérfolyamatokat kapjuk.

PHP keretrendszerek

Jelen pillanatban 4 népszerű PHP-s keretrendszer van. A Zend, a CakePHP, a Symfony és a CodeIgniter.

Magyar honlap a Zendről, kicsit nézzetek bele!http://www.items.hu/zend-framework

Többé kevésbé azonos tudásúak, azonos a tanulásukra fordítandó idő, azonos licensz alá tartoznak. Azt hiszem, hogy az esetek majd’ 100%-ában az történik, hogy amelyikkel az ember elkezd dolgozni azután arra esküszik és az összes többi nehézkesnek és bugyutának tűnik. Szóval aki még nem kötelezte el magát az katt ide.

JavaScript keretrendszerek

Webfejlesztés esetén nagy valószínűséggel a szerver oldali keretrendszerek mellett bizonyára szükségünk lesz valamilyen kliens oldali keretrendszerre is. Ezek közül a Yahoo! User Interface (YUI), a Prototype és a Dojo a legnépszerűbbek.

Dojo magyarnyelven, picit olvassatok bele!http://geigerpeter.hu/index.php?option=com_content&view=category&id=40:dojo&Itemid=69&layout=default

A JavaScript keretrendszerek egyik legfontosabb tulajdonsága, hogy keresztplatformossá teszik használatukkal a JavaScript alkalmazást, azaz kiszűrik a különböző böngészők eltérő JavaScript kezeléséből adódó problémák nagy részét.

Használati szempontból nagyjából ugyanaz igaz rájuk mint a PHP-sekre, azaz ha az ember elkezdi használni az egyiket akkor arra és csak arra esküszik. Szóval aki még nem használja egyiket sem annak azt mondom, hogy prototype és script.aculo.us.

40/42

Összefoglalás

Ez az általános és rendkívül rövidke bemutató nem vállalta fel azt a feladatot, hogy konkrétan bemutassuk egyik vagy másik keretrendszer használatát. A cél csupán annyi volt, hogy minden webfejlesztő figyelmét felhívjam arra, hogy mennyit nyerünk azzal ha elkezdünk valamilyen alkalmazás fejlesztési keretrendszert használni webes fejlesztéseinkhez. Sok időt nyerünk használatukkal és jobban kezelhető és fenntartható kódot eredményeznek. Mindezért egy rövidke tanulási idővel kell fizetnünk, ami egyértelműen egy jó üzlet. Egyetlen figyelmeztetésem van. Ha valaki elkezd keretrendszerekkel dolgozni utána már nem hajlandó többet nélkülük dolgozni…

A komponens – mint szoftverkomponens – fogalma már 30 éve is jelen volt az információtechnológia területén, azóta mind a definíciója, mind a felhasználása rendkívül sokrétű lett. A komponens egy olyan kódrészlet, amely valamilyen szolgáltatást nyújt, azaz jól definiált funkcionalitással rendelkezik, továbbá kompozíció útján valamilyen cél érdekében rendszert alkot más komponensekkel. Nem fogjuk megkötni, hogy a komponens milyen nyelven íródjon, ebből következik, hogy a komponens akár bináris formában lévő futtatható kódrészlet is lehet. Komponensek esetén az újrafelhasználhatóság opcionális tulajdonság, ehelyett a komponens cserélhetőségét szokták kihangsúlyozni. A komponens kompozícióra született, tehát fontos, hogy nem az (újra) felhasználhatóság van az alkalmazhatóságért, hanem fordítva. Előfordulhat, hogy egy forráskódú komponens jobban támogatja az újrafelhasználhatóságot, mint egy futtatható komponens, de ettől mind a kettő komponensnek tekinthető. A komponens tehát valamilyen paraméterek alapján egy jól meghatározott tevékenységet végez el. A komponensnek, ahhoz hogy a szolgáltatásokat elvégezze, szüksége van bizonyos bemeneti értékekre, hiszen az elvégzendő tevékenység általában valamilyen értékektől függ. Ha a komponenst egy olyan környezetben helyezzük el, amely biztosítani tudja számára ezeket az értékeket, akkor a komponens gond nélkül működhet az adott környezetben. Ahhoz, hogy az elhelyezést el tudjuk végezni, szükség van a komponensek által igényelt és a környezet által nyújtott értékek összerendelésére. Tehát mind a komponensnek, mind annak felhasználójának (másik komponens) szüksége van valamilyen önelemző funkcióra, amely el tudja végezni, hogy a komponens beleillik-e a megadott környezetbe.

41/42

16. Ön egy sakk játékprogramot fejleszt. Milyen architektúrát alakítana ki, hogy a program könnyen karbantartható és továbbfejleszthető legyen?

Információtartalom vázlata

–Rendszerek működésének tervezése– Objektum-orientált rendszer kialakítása

–Programtervezési módszerek– Adatbázis-, illetve filekezelés használata

–Felhasználói felületek– Grafikus rendszerek (GDI, OpenGL, DirectX) használata– A sakkfigurák, mint objektumok

42/42

Vizsgarészhez rendelt követelménymodul azonosítója, megnevezése:0002-06 Marketing tevékenységVizsgarészhez rendelt vizsgafeladat megnevezése:1. vizsgafeladatA piackutatás módszereinek és a marketing tevékenység eszközeinek bemutatása megadott célok és feltételek alapján

Lásd mág: 1144_06_16_grafikus_rendszerek.doc

Sakkjáték – fejlesztési dokumentáció

Követelményspecifikáció:Miképpen működik a sakkjáték, lépések. A figurákat meg tudjuk fogni és oda tudjuk rakni ahová lépni szeretnénk. (a program nem engedi a szabálytalan lépést) Ha egy bábuval olyan mezőre lépünk ahol már áll bábu akkor a másik eltűnik…..

Analízis:Képernyőterv:

SakktáblaBábukKét játékos

Szakterületi objektummodell:Szereplők leírása, felelőssége:Két játékos szereplő, kívülről manipulálják a programotSakk játék: Az irányító, létrehozza a sakktáblát, és a bábukat (helyre is rakja őket), végül felszólítja az első játékost a játék megkezdésére.Objektumok leírása, felelőssége:Sakktábla: összetartja működteti a bábukat, egy konténer amelybe beletesszük a bábukat. Bábu: van típusa (gyalog, királynő… ) figyeli az egeret is nem kell-e lépnie itt részletesebben beszélni arról, hogy a Bábu ősosztályból származtatnánk az egyes specializáltabb osztályokat: gyalog, királynő …stb, mik azok a tulajdonságok metódusok amelyeket a Bábu és melyek azok amelyeket a már példányosításra szánt osztályokban adnál meg… itt elég jól lehet rizsázni!!!

Szakterületiobjektummodell:

Használati esetekA játékosok a következő dolgokat csinálják:Lépnek a bábuval…stb,

Számítógépes környezet fejlesztő eszköz:Op. rendszer: windowsProgramfejlesztési módszer: UMLProgramnyelv: JavaFejlesztőeszköz: JavaBean

44/42

bábu1

bábu2

bábu3

Sakkjáték sakktábla

játékosok

egér

egér

Programterv:Bábu – osztályleíráskomponens amely megjelenik a képernyőn, lépni tud, ütni tud, tudja azt hányat, milyen irányba léphet!Metódusai:Bábu(tipusa:tipus) konstruktor létrehozzalép(irány:number,db:number)…………….stb.Sakktábla – osztályleírás

45/42

Itt egy gyerek autói terepasztalon mozognak, terepasztal a sakktábla, autó a bábu… valami hasonló lenne!

46/42

17. Egy csevegő (chat) program fejlesztésénél milyen lehetőségeket ismer, ami a gépek közötti kommunikációt valósítja meg?

Információtartalom vázlata

–Kommunikációs kapcsolatok (felületek) fejlesztése– Felhasználó felület kialakítása

–Eseménykezelés– Üzenetküldés lehetőségei

–Szoftverkomponensek– TCP/IP, http protokoll lehetőségei– Osztott objektumok használata

1144_06_20_Chat_program.doc

47/42

18. Egy szoftverfejlesztő cég vezető fejlesztőjeként milyen szempontok alapján osztaná szét a feladatokat az egyes fejlesztők között?

Információtartalom vázlata

–Rendszerek (elemek, jellemzők)– Előző rendszerek szerkezete– Fejlesztők előző munkái

–Rendszerfunkciók tervezése– Jól szétválasztható modulok készítése

–Szoftver architektúra kialakítása– Felülettervezés, üzleti logika, adatbázis kapcsolatok

OOP szemléletet működést egységbezárás…stb. itt csoportmunkánál is hasznos tehát el lehet mondani! Kódolási konvenciókról is lehet pár szót ejteni. Megnézni a feladatvázlatot!

Mindenek előtt, először is mindenkinek a saját maga szakterületén kell dolgoznia, ez egyértelmű. Egy program elkészítésének főbb fázisai a tervezés, a fejlesztés, programozás, a tesztelés, forgalomba hozással kapcsolatos teendők, a felhasználó élményei, és a termék menedzselése. De ezen kívül még sok dologra kell oda figyelni, például a minőség biztosítása. Fontos dolog még azt is meghatározni, hogy mennyi a rászánt költségvetés, kihozható-e annyi pénzből, és megéri-e annyi pénzért fejleszteni.

A tervezés és a munka kezdete előtt még azt is megállapíthatjuk, hogy vannak különböző módszertanok, az egyik legismertebbet a Microsoft birtokolja, mégpedig ez az MSF (Microsoft Solution Framework) . Az MSF főbb jellemzői:a projekt középpontjában az ügyfél áll, vagyis az ő igényeinek kielégítése az elsődlegescél; ennek megfelelően a felhasználói felület is a megrendelő maximális kiszolgálását szolgálja; fontos a közös nyelv és terminológia megtalálása vagy kialakítása, amellyel az ügyfél és a fejleszt k hatékonyan kommunikálhatnak egymással; az MSF egyértelmű szerepköröket és felelősségeket definiál, amelyek lehetővé teszik a hatékony csapatmunkát és a félreértések elkerülését; nagy hangsúly kerül a minőségre, amely mind a vég- és köztes termékek, mind a folyamatok vonatkozásában értendő, ezen kívül fontos a csapattagok folyamatos tanulása is: nemcsak a szervezett képzéseken, hanem a korábbi projektekből, tapasztalatokból egyaránt.

Hasnoló még a RUP ( Rational Unified Process ) , aminek a filozófiája szerint a módszertan " elvek, módszerek és fejlesztést támogató eszközök, technikák egysége". Az általa el írt módszertan alappillérei a következők: • komponensalapú • modellszemléletű • use case vezérelt • architektúra-centrikus • iteratív és inkrementális A RUP munkafolyamatai az MSF-hez hasonlóan iteratív és inkrementális modellel írhatók le.

48/42

Miután eldöntöttük, hogy érdemes megcsinálni a programot, akkor nekiállunk, hogy összeszedjük a munkára kiválasztott programozókat, fejlesztőket, tesztelőket. Megkonzultáljuk a programozókkal a program architekturális felépítését, hogyan kezelje a folyamatokat, és adminisztrációs szempontból az egyéb feladatokat. Mikor ezzel a feladattal megvagyunk, jöhet a fejlesztési szakasz, de csak akkor, ha minden tisztázódik a tervezés során a projekttel kapcsolatban.A fejlesztés elején Technológiai tanácsadást kérhetünk, hogy mik a mai modern technikák, módszerek egy hatékony és jól működő program írására. Ezután a megtervezett program felépítésének implementálása következik, mindent leprogramozunk, minden funkciót, minden tervezett eszközt, extrát.Egyéb alkalmazások fejlesztését is lehet ütemezni, ha van rá igény a felmért helyzet alapján. A tervek implementálása és a szoftver készítésének ideje alatt, fontos, hogy a különböző részek moduljai jól elkülönüljenek egymástól. Minden programozót a saját szakterületére kell helyezni, hogy ne tudják esetleg a másik munkáját befolyásolni, elrontani.Ha készen van az alap program, akkor jöhet a tesztelés fázisa, felépítjük a tesztelés fázisait, menetét. Megfelelő embereket keresünk hozzá, akik el tudják mondani, hogy mit tapasztaltak a szoftver használata idején, mi a benyomásuk, a véleményük, milyen hatást, gyakorolt rájuk a program felhasználó-barátsága, általában egyszerű-e a program kezelése.Miután a tesztelés menete végigment, és a sok bugot sikerült kiszűrni, ha minden jól ment, akkor jöhet a teszteredmények dokumentálása, kinek milyen hibaüzenet jött ki, ki mit tapasztalt. Ha minden hibát dokumentáltak, akkor jöhet a kereskedelmi helyzet felmérése, a termék menedzselése, támogatás létrehozása a szoftverhez, a termék reklámozása, másolása. Az üzleti logikán nagyon sok múlik, mivel ha jó időben dobják a piacra a terméket, akkor sokkal több fogyhat belőle esetleg, mintha egy olyan időpontban teszik ezt, amikor nincs szükség ilyen termékre. Fontos lehet az is, hogy több nyelven is kiadjuk a programot, a szélesebb körben való elterjedés miatt, több helyen legyen ismert, több ember lássa, használja, ezáltal a forgalmat is megnövelve. Miután kikerült az életbe a szoftver, készítsünk felméréseket, hogy kinek mennyire tetszett, mennyire találta ésszerűnek, logikusnak a felépítését, felhasználóbarátnak. Ezen adatok után megtudhatjuk, hogy mennyire népszerű programunk, és mennyi bevételre számíthatunk, bár egyre több a kalózkodás a szoftverekkel. Egy idő után kialakíthatjuk saját módszertanunkat is akár.

49/42

19. Milyen kódolási konvenciókat vezetne be egy csoportmunkában fejlesztő cégnél, hogy a lehető leghatékonyabb módon történjen a munkavégzés?

Információtartalom vázlata

–Alapfogalmak (elágazás, ciklus stb.)– Ciklusok egységes használata

–Programozási tételek (alapalgoritmusok)– Algoritmusok kiválasztása

–Kódolás– Változók, osztályok stb. elnevezése

1144_06_19_kódolási_konvenciók.doc

50/42

20. Milyen módszerrel tesztelné az Ön által fejlesztett modult, amely egy másik programozó által írandó modult használná, de az még nincs teljesen kész?

Információtartalom vázlata

–Tesztelési ismeretek (teszttípusok)– Fekete és fehér doboz módszerek

–Adatszerkezetek, objektumok– Virtuális működés kialakítása– Interfészek használata

–Tesztelés, hibakeresés– A modul összes funkciójának tesztelése

4. tétel

51/42