A programozás módszertana

Az előadások a következő témára: "A programozás módszertana"— Előadás másolata:

1 A programozás módszertana
Előadó: Dr. Nagy Mihály Elérhetőség: Dr. Kuki Ákos anyagának felhasználásával Nyíregyházi Főiskola

2 A programozás makrofolyamata
Probléma, kérés, ötlet ( a megrendelőtől ) A felvetés értelmezése, pontos megfogalmazása, feladattá alakítása Döntés arról, hogy érdemes-e programot írni A program megírásához használható erőforrásaink számbavétele (hardver, szoftver) A feladat megoldásához szükséges INPUT (bemenő) adatok számbavétele Az OUTPUT (kimeneti) információk tartalmának és formájának megtervezése (képernyő és nyomtatási kép) A megoldás lépésről lépésre történő megadása ( az algoritmus megtervezése) Az algoritmus leírása (folyamatábra, struktokram, leírás, pszeudokód) A programnyelv kiválasztása Az algoritmus lekódolása ( a program megírása ) A program tesztelése (próbaadatokkal történő kipróbálása) A dokumentáció elkészítése Esetleg árualakra hozás Nyíregyházi Főiskola

3 1. Programtervezés Nyíregyházi Főiskola

4 Mit értünk programtervezésen?
A leendő program szerkezetének megalko-tása A program elemeinek megfelelő sorrendben való összerakása A szerkezetnek több szintje lehet átfogó szerk.: függvények, eljárások, alprogramok finomszerkezet: változók, műveletek (utasítás-sorok, ciklusok, döntési szerkezetek) Elkülönül a kódírástól (kódolástól) Nyíregyházi Főiskola

5 A programozás főbb lépései
A probléma meghatározása, felmérése (specifikáció) A megvalósítás (implementáció) tervezés kódolás tesztelés dokumentálás Nyíregyházi Főiskola

6 Mi indokolja a tervezés szükségességét?
Megbízhatóság Ha egy programot megfelelően terveztünk meg, akkor elvileg megfelelően kell működnie Költségek A jó terv lecsökkenti az idő-, és ezáltal költségigé-nyes, tesztelései fázist Karbantartás A jól megtervezett programot egyszerűbb módosítani Nyíregyházi Főiskola

7 1.0. Strukturált programozás
Nyíregyházi Főiskola

8 A goto utasítás használata kerülendő
A strukturált programozás jelenti valamennyi ma használatos programtervezési módszer alapját Széles körben elfogadott az a nézet, hogy a strukturált programozás a programfejlesztés egyetlen lehetséges módja Alapelve: a programok összesen háromféle építőelemből állnak össze (Dijkstra): szekvenciák (utasítássorok) döntési szerkezetek (elágazások v. szelekciók) iterációk (ismétlődő részek v. ciklusok) A goto utasítás használata kerülendő A strukturált programozás gyakran a felülről lefelé történő elvonatkoztatást, tervezést is jelenti Több szint, egymásba ágyazás. Absztrakció Lokális adatok Nyíregyházi Főiskola

9 Szabvány (Federal Standard 1037C)
structured programming: A technique for organizing and coding computer programs in which a hierarchy of modules is used, each having a single entry and a single exit point, and in which control is passed downward through the structure without unconditional branches to higher levels of the structure. Three types of control flow are used: sequential, test, and iteration. Nyíregyházi Főiskola

10 Építőelemek Minden építőelemnek csak egy belépési, illetve kilépési pontja van egy sem tartalmaz háromnál több alapelemet a belépési pont az algoritmuselemek elején, a kilépési pont a végén található Nyíregyházi Főiskola

11 Strukturált programozási nyelvek
Az 1970-es évektől, amikor a strukturált programozás népszerű technikává vált, olyan új programozási nyelvek születtek, melyek támogatták, hangsúlyozták a módszer alkalmazását. A legismertebbek ezek közül: Pascal, Ada Nyíregyházi Főiskola

12 Strukturált programozás vs. goto
Bohm, Jacopini: a goto utasítás segítségével megírt bármely program megírható pusztán a strukturált programozás alapelemeinek használatával is A strukturált programozás, mint módszer általánosan elfogadott, de nincs vizsgálat, bizonyíték arra, hogy hatékonyabb, jobb A program karbantarthatóságát vizsgáló kísérletek a strukturált programozás melletti eredménnyel zárultak Vessey, Weber: „a strukturál programozás használ-hatóságát alátámasztó érvek meglehetősen gyengék” (megbízható kísérletek hiánya) Nyíregyházi Főiskola

13 További érvek a goto mellőzésére
Világos írásmód és kifejezőerő címke: if a > 0 goto címke A bal oldali kódot felülről lefelé olvasva nem világos, hogy mi a címke szerepe, sőt több goto utasítás is ugorhat ugyanezen címkére. A goto több, egymástól lényegesen különböző cél megvalósítására is használható (elágazás, ciklus, ciklusból való kilépés, eljáráshívás), ezért kicsi a kifejezőereje. Világosabb kódot kapunk, ha a megfelelő egyedi nyelvi elemet használ-juk. Könnyebb a programok helyességének bizonyítása (minden program-elemnek csak egy belépési, ill. kilépési pontja van). while a > 0 do endwhile ... Nyíregyházi Főiskola

14 Érvek a goto használata mellett
A goto is része a programozási nyelvek eszközkészletének, ha megtiltjuk a használatát, a programozó elől elvesszük a lehetőséget, hogy értelmesen felhasználja. Hibakezelés (a programegység belsejéből egy hibakezelő rutinra ugorhatunk, így az egységnek több kilépési pontja lesz). Növelhető a teljesítmény Néha kifejezetten természetes a goto használata (Donald Knuth: lazább megkötés a strukturált programozásra) Nyíregyházi Főiskola

15 A hatékonyság vizsgálata:
A vitaindító cikk: Dijkstra, E.W.: Go to statement considered harmful Communications of the ACM, Vol. 11, No. 3, 1968 Az első tankönyv: Dahl, Dijkstra, Hoare: Structured Programming, 1972 A hatékonyság vizsgálata: Schneiderman: Software Psychology: Human Factors in Computer and Information Systems, 1980 Vessey, Weber: Research on Structured Programming: an empiricist’s evaluation, 1984 Nyíregyházi Főiskola

16 1.1. A feladat funkcionális felbontása
Nyíregyházi Főiskola

17 Műveletek - fokozatos finomítás
Ez a tervezési módszer a megírandó program által végrehajtott műveletekre összpontosít. Első lépés: a megtervezni kívánt program feladatának megfogalma-zása Majd egyszerűen (magyarul) leírjuk azt a műveletsort, amit a programnak végre kell majd hajtania Ezután a műveleteket fokozatosan finomítjuk, míg el nem érjük a kellő részletezettséget Ez általában akkor következik be, amikor a műveletek már a használni kívánt programnyelv elemeivel is leírhatók A műveletsor egyes lépéseit tekinthetjük egy-egy eljárásnak, az elemi lépéseket pedig utasításoknak. Nyíregyházi Főiskola

18 Példa - kávéfőző robot A feladat első leírása
csinálj egy csésze kávét Leírás egyszerűbb műveletekkel forralj vizet vegyél elő egy csészét tegyél kávét a csészébe önts rá vizet adj hozzá tejet adj hozzá cukrot ízlés szerint A fenti lista minden egyes eleméről pontosabban leírjuk, hogy mit is jelent A finomítást a kellő részletezettségig elvégezzük Nyíregyházi Főiskola

19 Álkód (pszeudokód) Azt a nyelvet, amit a probléma leírására használunk álkódnak (pszeudokódnak) vagy programtervezési nyelvnek (Program Design Language, PDL) hívjuk. A végeredmény értelmes magyar mondatok sorozata, melyek valamennyien egy-egy igével kezdődnek Tartalmazhat valódi programozásból átvett szerkezeteket is (pl if…then…else… vagy while) Nyíregyházi Főiskola

20 Például a „forralj vizet” eljárás felbontása elemibb utasításokra
gyújts be a teáskanna alá while a víz nem forr do fütyöréssz egy dallamot endwhile kapcsold le a fűtést a kanna alatt Az „adj hozzá cukrot ízlés szerint” eljárás részletezése például a következő lehet if kell bele cukor then tegyél cukrot a csészébe keverd meg endif Nyíregyházi Főiskola

21 Példa - videojáték Pattogó labdát ütögetve egy falat kell lebontanunk (ld. mellékelt program) A képernyőt egy tömbön keresztül kezeljük ke: array[1..50,1..80,1..2]of char A labda koordinátáit az xlabda és ylabda tárolja. Nyíregyházi Főiskola

22 Általános logikai leírás
videojáték rajzold meg az oldalfalakat rajzold meg az ütőt a kezdőpozícióban while akar valaki játszani do rajzold meg a falat játszd a játékot jelenítsd meg a legjobb eredményt endwhile A konkrét részleteket itt még általános utasítások fedik el, mely lehetővé teszi, hogy tanulmányozzuk, módosítsuk a tervet anélkül, hogy az apróbb részletekkel kellene törődnünk. Például észrevesszük, hogy hiányzik még a legjobb eredmény kezelése Nyíregyházi Főiskola

23 videojáték rajzold meg az oldalfalakat rajzold meg az ütőt a kezdőpozícióban legjobb eredmény := 0 while akar valaki játszani do eredmény := rajzold meg a falat játszd a játékot if eredmény > legjobb eredmény then legjobb eredmény := eredmény endif jelenítsd meg a legjobb eredményt endwhile Nyíregyházi Főiskola

24 Vegyük a „játszd a játékot” eljárást:
Ha az eredmény ezen a szinten már kielégítő, nekiállhatunk az egyes lépések részletesebb kidolgozásának Vegyük a „játszd a játékot” eljárást: játszd a játékot maradék labdák := 4 while maradék labdák > 0 do játssz a labdával csökkentsd eggyel a maradék labdák számát endwhile Megjelent egy újabb eljárás („játssz a labdával”), melyet illik részletesebben is leírni Nyíregyházi Főiskola

25 Készítsük még el a ciklus három eljárásá-nak részletezését
játssz a labdával rajzolj egy új labdát while a labda játékban van do vizsgáld meg a labda helyzetét mozgasd a labdát mozgasd az ütőt endwhile töröld a labdát a képernyőről Készítsük még el a ciklus három eljárásá-nak részletezését Nyíregyházi Főiskola

26 vizsgáld meg a labda helyzetét ellenőrizd, hogy játékban van-e még a labda ellenőrizd, hogy eltalálta-e a határfalak valamelyikét ellenőrizd, hogy eltalálta-e az ütőt ellenőrizd, hogy nekiütközött-e egy téglának ellenőrizd, hogy eltalálta-e az határfalak valamelyikét if a labda bármelyik oldafalnál van then XLépés := - XLépés endif if a labda a felső határon van then YLépés := - YLépés endif ellenőrizd, hogy nekiütközött-e egy téglának if ke[YLabda+YLépés, XLabda+XLépés] egy tégla helye then ke[YLabda+YLépés, XLabda+XLépés] := üres növeld az eredményt eggyel YLépés := -YLépés vonj le egyet a maradék téglák számából if maradék téglák száma = 0 then rajzolj falat endif endif Nyíregyházi Főiskola

27 mozgasd a labdát töröld a labdát a régi helyén XLabda := XLabda + XLépés YLabda := YLabda + YLépés ke[YLabda, XLabda, 1] := "o„ mozgasd az ütőt if billentyű = "q" then mozdulj balra endif if billentyű = "w" then mozdulj jobbra endif mozdulj balra töröld az ütőt if ütő helyzete > bal oldali fal + 1 then ütő helyzete := ütő helyzete – 1 endif rajzold meg az ütőt Nyíregyházi Főiskola

28 A módszer elemzése, értékelése
Ahhoz, hogy a tervezés bármely szintjén megértsük a rendszer működését, nem kell pontosan ismernünk az alacsonyabb szintek működését. Tudnunk kell, hogy az alacsonyabb szintek mit csinálnak, de azt nem, hogy hogyan. Két út: szintről-szintre történő finomítás (breadth first) egy ágnak a lehető legnagyobb részletességgel való kifejtése (depth first) A pszeudokód minden részletét a strukturált programozás szabályainak betartásával írunk le. A módszer erős akaratot igényel. Nyíregyházi Főiskola

29 Az adatok csak a másodhegedűs szerepét játsszák
Rugalmasság: több terv is alkotható egy problémára A funkcionális felbontás módszerének Dijkstra és Wirth nevéhez fűződik Az 1960-as években a strukturált programo-zással párhuzamosan fejlődött Felülről lefelé építkező tervezési módszer Gyakran nevezik lépésenkénti finomításnak is Nem vált kereskedelmi termékké, az egyete-meken született, kevésbé kidolgozott, mint más eljárások Nyíregyházi Főiskola

30 Tág teret ad a kreativitásnak (ez gyengeség is)
A funkcionális felbontás mint tervezési módszer első-sorban a program által végzett műveletekre összponto-sít, így olyan területeken alkalmazható elsősorban, ahol ezek a műveletek egyértelműek, és központi szerepet töltenek be. Pl: numerikus problémák, soros folyamatok irányítása. Használható a program alacsony szintű finomszerkeze-tének és egészen magas szintű, átfogó szerkezetének kialakítására. A funkcionális felbontás támaszkodik a tervező fantázi-ájára és szakmai képességeire. Tág teret ad a kreativitásnak (ez gyengeség is) Nem szisztematikus módszer, nincsenek benne jól meg-határozott tervezési lépések. A módszert az „érdeklődőknek”, a programozást élvezőknek találták ki. Nyíregyházi Főiskola

31 Összefoglalva A funkcionális felbontás egy, a strukturált programozás elveire támaszkodó általános célú tervezési módszer, mely több különböző logikai szerkezet kialakítását teszi lehetővé, ezzel teremt néhány kérdést: Honnan vesszük az ötleteket? Hogyan választunk a különböző lehetséges tervek közül? Honnan fogjuk tudni, hogy a legjobb, az igényeknek leginkább megfelelő tervet állítottuk elő? Sokan azt állítják, hogy a funkcionális felbontás nem nevezhető „komoly” tervezési módszernek. Nyíregyházi Főiskola

32 1.2. A Michael Jackson programtervezési módszer
JSP – Jackson Structured Programming Nyíregyházi Főiskola

33 Alapfilozófia Egy program logikai szerkezete egyértelműen előállítható az általa kezelt vagy előállított adatok szerkezete alapján. Pl: A bemenetről érkező pozitív számokat adjuk össze. A számsort egy negatív szám zár le. A bemenő adatokban ismétlődés tapasztalható, így a programban is lennie kell egy ismétlődő szakasznak. Tehát a bemenő adatok szerkezetéből kiindulva vontunk le egy, a program szerkezetére vonatkozó következtetést. Nyíregyházi Főiskola

34 Első lépés: az adatszerkezet elemzése – adatszerkezet-diagram
Példa: Rajzolja ki a program a következő ábrát a karakteres képernyőre: * *** ***** ***** *** * Első lépés: az adatszerkezet elemzése – adatszerkezet-diagram Kép Felső fél Közép Alsó fél * * Vonal Vonal A rajzolandó ábra egy felső részből, egy középső kihagyásból és egy alsó részből áll A felső és az alsó rész is ismétlődő sorokat tartalmaz Nyíregyházi Főiskola

35 Tartalmaz: A tartalmazza B-t Ismétlés: A objektum 0 vagy több B
Általánosságban a diagram jelölései a következőket jelentik: Tartalmaz: A tartalmazza B-t Ismétlés: A objektum 0 vagy több B objektum sorozata A A B * B Sorozat: A valójában egy B és egy C sorozata A B C Nyíregyházi Főiskola

36 Programszerkezeti diagram
Vegyük észre, hogy az adatszerkezetet a logikai felépítésben felülről lefelé haladva (egyre fino-mítva) írjuk le. Az adatszerkezet elkészítése után a következő lépés annak programszerkezetté történő át-alakítása Ez könnyű, hiszen a programszerkezetnek pontosan tükröznie kell a feldolgozni kívánt adatok szerkezetét Programszerkezeti diagram Nyíregyházi Főiskola

37 Programszerkezeti diagram:
Kép fel- dolgozása Felső fél fel-dolgozása Közép fel-dolgozása Alsó fél fel-dolgozása * * Vonal fel-dolgozása Vonal fel-dolgozása A diagram értelmezése: A program mint egész (a diagram legfelső doboza) tartalmazza (vonalak a dobozok között) bizonyos utasítások egy sorozatát (egy szinten elhelyezkedő dobozok) Egyes programösszetevőket néha ismételten is végre kell hajtani (csillag a doboz sarkában) Nyíregyházi Főiskola

38 A példánkban a lista az alábbi műveleteket tartalmazza:
A következő lépés, hogy tetszőleges sorrendben leírjuk mindazokat az elemi műveleteket, amelyeket a programnak végre kell hajtania (ez a legkevésbé meghatározott eleme ennek a tervezési módszernek) A példánkban a lista az alábbi műveleteket tartalmazza: n darab csillag nyomtatása üres sor nyomtatása s darab szóköz nyomtatása s növelése s csökkentése n növelése n csökkentése n és s kezdeti beállítása Nyíregyházi Főiskola

39 A következő lépésben az elemi műveletek el kell helyeznünk a program szerkezeti diagramjának megfelelő pontjain Kép fel- dolgozása Felső fél fel-dolgozása Közép fel-dolgozása Alsó fél fel-dolgozása 8 8 n darab csillag nyomtatása üres sor nyomtatása s darab szóköz nyomtatása s növelése s csökkentése n növelése n csökkentése n és s kezdeti beállítása * * Vonal fel-dolgozása 2 Vonal fel-dolgozása 1 3 6 5 1 3 7 4 Nyíregyházi Főiskola

40 Utolsó lépés: a programszerkezet-diagram pszeudokóddá való alakítása
n és s beállítása while vannak még sorok do s darab szóköz kinyomtatása n darab csillag kinyomtatása s csökkentése n növelése endwhile üres sor nyomtatása n és s beállítása while vannak még sorok do s darab szóköz kinyomtatása n darab csillag kinyomtatása s növelése n csökkentése endwhile Nyíregyházi Főiskola

41 Összefoglalva a tervezés lépéseit
Felrajzoljuk a feldolgozandó adatok szerkezetét ábrázoló diagramot Elkészítjük az ennek megfelelő programszerke-zet-diagramot Leírjuk azoknak az elemi műveleteknek a listáját, amelyeket a programnak végre kell hajtani Elhelyezzük ezeket a műveleteket a program szerkezetét leíró diagramban Előállítjuk a program vázlatos logikai szerkezetét Nyíregyházi Főiskola

42 Negatív szám feldolgozása
Példa: Adjunk össze egy számsorozatot, melynek a végét egy negatív szám jelzi! Adatszerkezet-diagram Programszerkezet-diagram az elemi műveletekkel Számok fel- dolgozása Számok Negatív szám Törzs Törzs fel-dolgozása Negatív szám feldolgozása 3 * * Szám fel-dolgozása 4 Szám 1 2 1. szám beolvasása 2. szám hozzáadása az összeghez 3. az összeg kezdeti beállítása 4. az összeg kiíratása Nyíregyházi Főiskola

43 Átalakítás pszeudokóddá:
összeg := 0 while a szám nem negatív do a szám beolvasása a szám hozzáadása az összeghez endwhile a szám kiírása A logikai szerkezet felírása a diagram alapján mechanikusan történt, nem tökéletes. A Jackson tervezési módszer csak a program logikai vázát segít megadni, a finomabb részletek kidolgozásában nem segít. A kód helyesen: összeg := 0 a szám beolvasása while a szám nem negatív do a szám hozzáadása az összeghez a szám beolvasása endwhile a szám kiírása Nyíregyházi Főiskola

44 Példa: Egy soros elérésű fájl személyek rekordjait tartalmazza
Példa: Egy soros elérésű fájl személyek rekordjait tartalmazza. Számoljuk meg, hogy a lista hány férfit és hány nőt tartalmaz! Adatszerkezet-diagram Pszeudokód fájl megnyitása számlálók beállítása while a fájlnak nincs vége do egy bejegyzés olvasása if bejegyzés = férfi then férfiak számlálójának növelése else nők számlálójának növelése endif endwhile a számlálók értékének kiírása a fájl bezárása Fájl Törzs Fájlvége * Bejegyzés   Férfi Nő Látható, hogy az alternatívákra utaló, -rel jelölt dobozok if…then…else szerkezetként jelennek meg a kódban. Nyíregyházi Főiskola

45 Példa: http://en.wikipedia.org/wiki/Jackson_Structured_ Programming
As an example, here is how a programmer would design and code a run length encoder using JSP. A run length encoder is a program which takes as its input a stream of bytes. It outputs a stream of pairs consisting of a byte along with a count of the byte's consecutive occurrences. Run length encoders are often used for crudely compressing bitmaps. With JSP, the first step is to describe the structure of a program's inputs. A run length encoder has only one input, a stream of bytes which can be viewed as zero or more runs. Each run consists of one or more bytes of the same value. This is represented by the following JSP diagram. Például: input output – Nyíregyházi Főiskola

46 The run length encoder input
Nyíregyházi Főiskola

47 The run length encoder output
The second step is to describe the structure of the output. The run length encoder output can be described as zero or more pairs, each pair consisting of a byte and its count. In this example, the count will also be a byte. The run length encoder output Nyíregyházi Főiskola

48 The next step is to describe the correspondences between the operations in the input and output structures. Nyíregyházi Főiskola

49 In this example, there is no structure clash, so the two structures can be merged to give the final program structure. Nyíregyházi Főiskola

50 At this stage the program can be fleshed out by hanging various primitive operations off the elements of the structure. Primitives which suggest themselves are read a byte remember byte set counter to zero increment counter output remembered byte output counter The iterations also have to be fleshed out. They need conditions added. Suitable conditions would be while there are more bytes while there are more bytes and this byte is the same as the run's first byte and the count will still fit in a byte Nyíregyházi Főiskola

51 #include <stdio.h> #include <stdlib.h>
If we put all this together, we can convert the diagram and the primitive operations in to C, maintaining a one-to-one correspondence between the code and the operations and structure of the program design diagram. #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int c; c = getchar(); while (c != EOF) { int count = 1; int first_byte = c; c = getchar(); while (c != EOF && c == first_byte && count < 255){ count++; c = getchar(); } putchar(first_byte); putchar(count); } return EXIT_SUCCESS; } Nyíregyházi Főiskola

52 A módszer elemzése, értékelése
A Jackson tervezési módszer alapelve szerint egy program logikai felépítését alapvetően az határozza meg, hogy milyen adatokat akarunk vele feldolgozni. A napjainkban használatos módszerek közül valószínűleg a legrendszerezettebb, jól elkülöníthető lépések sorozatából áll. Nem támaszkodik a programozó „megérzéseire” (viszont kreativitást igényel) Néhány könnyen átlátható alapelvre épít (strukturált programo-zás, az adatszerkezet és a feldolgozó program szerkezete közötti szoros kapcsolat) Könnyen tanítható Következetes (egy adott feladatnál két ember valószínűleg ugyanarra fog jutni) Egyszerű, könnyen használható Programozási nyelv független Nyíregyházi Főiskola

53 Alkalmazhatóság Szerepe Jackson szerint általánosan alkalmazható
A szakirodalom leginkább adatok (fájlok) soros feldolgozásával (kötegelt adatfeldolgozás) kapcsolatos problémákat említ Nehezen elképzelhető például az alkalmazása egy szám négyzet-gyökét fokozatos közelítéssel kiszámító program esetén, hiszen a be- és kimenő adatok szerkezetéből (mindkettő egy-egy szám) nem lehet következtetéseket levonni a program szerkezetével kapcsolatban. Kisebb programok tervezésére (ahol még nem kerülnek előtérbe az objektumorientált módszerek) Szerepe Újabban divatossá vált alábecsülni a módszer jelentőségét, mondván a soros feldolgozás elavult Ezzel szemben: képfájlok (GIF, JPEG), hangfájlok, nyomtató parancsfájlok, weblapok, irodai alkalmazások saját fájl-formátumaik soros elérésű fájlok Például: Word-el írt fájlt átalakítása Apple Macintoshon futó szövegszerkesztő formátumára. Felmérések mutatják, hogy Európában ma is elterjedten használják a módszert, Amerikában ez az arány kisebb. Nyíregyházi Főiskola

54 1.3. Adatfolyam tervezés Nyíregyházi Főiskola

55 Célja egy program átfogó felépítésének meghatározása.
Az adatfolyam tervezési módszer a meg-tervezni kívánt program adatáramlási rendszerének és adatkezelési folyamatainak tanulmányozásán alapul. Célja egy program átfogó felépítésének meghatározása. A programot alkotó modulok A modulok logikai kapcsolatrendszere Leginkább közepes vagy kifejezetten nagy rendszerek tervezése során használható Nyíregyházi Főiskola

56 Előállítottuk a program átfogó logikai szerkezetét
Példa: Tervezzünk programot, mely a Celsiusban megadott hőmérsékletet Fahrenheitre számítja át! Első lépés az adatfolyam-diagram (adatáramlás-diagram, Data Flow Diagram, DFD) felrajzolása. Az nyilakat (adatáramokat) és köröket (folyamatokat) tartalmaz. Hőmérséklet Celsiusban Hőmérséklet Fahrenheitben Billentyűzet Képernyő Bemenet Átalakítás Kimenet Előállítottuk a program átfogó logikai szerkezetét Nyíregyházi Főiskola

57 A részfolyamatok során megvalósítandó műveletek: Bemenet
Párbeszéd a felhasználóval, mely bekéri a bemenő adatot Ellenőrzés, hogy a felhasználó valóban számot adott-e meg A hiba kijavítása, ha megadott bemenet érvénytelen A bemenet átalakítása a megfelelő belső formátummá Feldolgozás Az érték átalakítása a Fahrenheit skálán kifejezett hőmérsékletté úgy, hogy közben a kívánt pontosság megmaradjon Kimenet A kiszámított hőmérséklet megjelenítése a képernyőn a megkívánt formában Nyíregyházi Főiskola

58 Ez a program moduljait, valamint azok kapcsolat-rendszerét tartalmazza
Második lépés: az adatáramlási diagramot program-szerkezeti diagrammá alakítjuk. Ez a program moduljait, valamint azok kapcsolat-rendszerét tartalmazza Az átalakítás lépései: Állapítsuk meg, hogy melyik a legfontosabb folyamat (példánkban az átalakítás) Ez lesz a programszerkezet legmagasabb szintjén elhelyezkedő modul Ezt az egységet gondolatban a levegőbe emeljük, és elképzeljük, hogy lóg le róla a többi szerkezeti elem. Így egy fagráfként ábrázolt hierarchiához jutunk. Alakítsuk a folyamatokat jelölő köröket modulokat ábrázoló téglalapokká, az adatáramoknak megfelelő nyilakat pedig modulhívásoknak megfelelő vonalakká Nyíregyházi Főiskola

59 Átalakítás Bemenet Kimenet Adattár Név és telefonszám Név Billentyűzet
Képernyő Bemenet Lekérdezés Kimenet Nyíregyházi Főiskola

60 Az adatáramlás diagram előállításának módszerei
Egyetlen nagy buborékkal kezdjük a rajzolást, amely a program teljes működését leírja, majd ezt kisebb egységekre, részfolyamatokra bonjuk A kimeneti adatáramból indulunk ki, majd a szerkezetben visszafelé haladunk A bemeneti adatfolyam útját követjük a logikai szerkezetben előre haladva A diagram felrajzolására nincs jól meghatározott, szisztematikus eljárás Nyíregyházi Főiskola

61 Formázott ár küldése az 1.
Példa: Vonalkód-leolvasó vezérlése Adatáramlási diagram Vonalkód Érvénye- sítés Érvényes vonalkód Ár Formázott ár küldése az 1. terminálra Keresés Formázott ár Ár Ár Az összeg frissítése Formázott ár küldése a 2. terminálra Összeg Az összeg formázása Formázott ár Nyíregyházi Főiskola Formázott összeg

62 Formázott ár küldése az 1.
Programszerkezeti diagram Keresés Formázott ár küldése az 1. terminálra Formázott ár küldése a 2. terminálra Érvénye- sítés Az összeg frissítése Összeg formázása Nyíregyházi Főiskola

63 az egyes modulok belsejét külön-külön is meg kell terveznünk.
A tervezési módszer a modulok és azok kapcsolatrendszerének azonosításával megadja a megvalósítandó program világos logikai felépítését, de az egyes modulok belsejét külön-külön is meg kell terveznünk. Szükségünk van alacsonyabb szintű tervekre is, melyek készülhetnek Michael Jackson módszer-rel, a funkcionális felbontás módszerével vagy bármely más alacsony szintű tervezésre megfelelő módszerrel. Nyíregyházi Főiskola

64 A legtöbb lépés kreativitást, beleérző képességet kíván
Az adatfolyam tervezési módszer (Larry Constantine) egyidős a moduláris programozással A módszer lényeges elemét képezi egy általában strukturált tervezésnek (Structured Design) nevezett eljáráscsomagnak Jól használható mindazon esetekben, amikor az adatáramlásnak központi jelentősége van a feladat megoldása szempontjából A legtöbb lépés kreativitást, beleérző képességet kíván Nyíregyházi Főiskola

65 Általánosan használható információs rendszerek tervezésére (top down)
Nyíregyházi Főiskola

66 Nyíregyházi Főiskola

67 1.4. Formális módszerek Nyíregyházi Főiskola

68 Természetes nyelv – formális leírás
A programok specifikációját, dokumentációját általában természetes nyelven készítik el. Ez tartalmazhat félreérthető elemeket Matematikai eszközök használatán alapuló formális leírás egyértelmű Ha a megbízhatóság, biztonság kiemelt fontosságú Nyíregyházi Főiskola

69 A formális jelölésrendszer használatának előnyei
Matematikailag elemezhetők, vagyis matematikai bizonyítási módszereket használhatunk a leírás helyességének vizsgálata során A leírások könnyebben karbantarthatók A formális leíráshoz használt nyelv bővíthető A programok helyességét, a leírással való össz-hangját matematikai szigorúsággal bizonyít-hatjuk Lehetővé tesz a leírás → program átalakítás automatizálását Nyíregyházi Főiskola

70 Szintjei 0. szint: formális specifikációt készítenek, majd a fejlesztés hagyományos eszközökkel folyik formal methods lite A legtöbb esetben a legköltséghatékonyabb választás 1. szint: formális fejlesztés és ellenőrzés Nagy integritású rendszerek fejlesztésekor 2. szint: A tervezés egyes lépéseinek helyességét (mint matematikai tételeket) bizonyítják (Automatic Theorem Prover) Nagyon drága, csak akkor éri meg, ha a hibák költsége különlegesen nagy Nyíregyházi Főiskola

71 Formális eljárással több lépésben történik a szoftverfejlesztés
Leírás (specifikáció) modell alapú megközelítés matematikai fogalmakkal jellemzi a program futása során felvehető egyes állapotokat, állapotátmeneteket (műveleteket) Tervezés Az elvont matematikai modell közelítése egy konkrét programnyelv eszközeihez (adatfinomítás) Megvalósítás Kódolás (műveleti finomítás) Nyíregyházi Főiskola

72 Eszközök Z formális nyelv (Z notation, ejtsd zed)
Vienna Development Method (VDM) Nyíregyházi Főiskola

73 Példa: könyvtári program 1. Leírás
A matematikai modell megalkotása (sémák) Felső rész: az állapottal kapcsolatos összetevők Alsó rész: invariáns, melynek igaznak kell maradnia állapot-változáskor A könyvtár két halmazból áll: a bent lévő és a kikölcsönzött könyvek halmazából Egy típus bevezetése: KATNO – katalógusszám, illetve azok halmaza Konyvtar kolcsonozheto, kikolcsonzott: P KATNO kolcsonozheto  kikolcsonzott = { } KATNO hatványhalmaza predikátum, melynek igaznak kell maradnia (invariáns) Nyíregyházi Főiskola

74 Műveletek megadása ellenőrzés: az invariánsoknak igaznak kell maradniuk pl. Kolcsonzes művelet a művelet előtti és utáni állapotok leírása bemeneti változó Kolcsonzes ΔKonyvtar előfeltétel művelet utáni állapot konyv?: KATNO művelet előtti állapot konyv?  kolcsonozheto kolcsonozheto' = kolcsonozheto \ {konyv?} kikolcsonzott' = kikolcsonzott  {konyv?} A predikátumok logikai ÉS kapcsolatban állnak. A ΔKonyvtar séma automatikusan a rendelkezésünkre áll ( modularitás) ΔKonyvtar kolcsonozheto, kolcsonozheto': P KATNO kikolcsonzott, kikolcsonzott': P KATNO kolcsonozheto  kikolcsonzott = { } kolcsonozheto'  kikolcsonzott' = { } Nyíregyházi Főiskola

75 A Kolcsonzes séma teljes alakja sémabeszúrás nélkül a következőképpen nézne ki
kolcsonozheto, kolcsonozheto': P KATNO kikolcsonzott, kikolcsonzott': P KATNO konyv?: KATNO konyv?  kolcsonozheto kolcsonozheto  kikolcsonzott = { } kolcsonozheto'  kikolcsonzott' = { } kolcsonozheto' = kolcsonozheto \ {konyv?} kikolcsonzott' = kikolcsonzott  {konyv?} Nyíregyházi Főiskola

76 A Visszavetel művelet leírás az előbbihez ha-sonlóan a következő
ΔKonyvtar konyv?: KATNO konyv?  kikolcsonzott kikolcsonzott' = kikolcsonzott \ {konyv?} kolcsonozheto' = kolcsonozheto  {konyv?} Nyíregyházi Főiskola

77 A leírás helyességének ellenőrzése
Az, hogy a teljes logikai rendszert Z nyelven fogalmaztuk meg, még nem biztosítja annak helyességét. Megfelel-e a leírás a megrendelő által megfogalmazott elvárásoknak? Követtünk-e el valamilyen hibát a Z nyelv használata közben? Bizonyítanunk kell a modell helyességét, egyfajta matematikai tételként kell azt kezelnünk. Például vizsgáljuk meg, milyen hatással van egy könyv kikölcsönzése a könyvtár teljes raktárkészletére. Nyilvánvaló, hogy a könyvállománynak nem szabad megváltoznia. Bizonyítsuk be, hogy ennek az elvárásnak megfelel a modellünk! Nyíregyházi Főiskola

78 Tehát a bizonyítandó állítás
kolcsonozheto'  kikolcsonzott' = kolcsonozheto  kikolcsonzott Bizonyítás: kolcsonozheto'  kikolcsonzott' 1. = (kolcsonozheto \ {konyv?})  (kikolcsonzott  {konyv?}) a Kolcsonzes művelet meghatározása alapján 2. = (kolcsonozheto \ {konyv?})  ({konyv?}  kikolcsonzott) az unióképzés kommutatív 3. = ((kolcsonozheto \ {konyv?})  {konyv?})  kikolcsonzott az unióképzés asszociatív 4. = (kolcsonozheto  {konyv?})  kikolcsonzott az unióképzés és a különbség közötti általános összefüggés 5. = kolcsonozheto  kikolcsonzott a Kolcsonzes művelet konyv?  kolcsonozheto kitétele miatt Nyíregyházi Főiskola

79 2. Tervezés Jelenleg ott tartunk, hogy van egy logikailag ellenőrzött, halmazokkal megfogalmazott elvont leírásunk Az elvont adattípusokat át kell alakítanunk olyan szerkezetekké, melyek könnyen megfeleltethetők a programozás során használható szerkezeteknek. (Halmazok helyett pl. tömbök) Segítségül hívjuk a Z nyelv új eszközeit, a függvényeket Nyíregyházi Főiskola

80 A Z nyelvben a tömb egy függvénnyel modellezhető, példánkban
Példánkban a kolcsonozheto és kikolcsonzott típusoknak feleltessünk meg egy-egy tömböt: Pl. Kkolcsonozheto: k1 k2 k4 … na = 3 K: konkrét Kkikolcsonzott: k3 k5 … nb = 2 A Z nyelvben a tömb egy függvénnyel modellezhető, példánkban Kkolcsonozheto, Kkikolcsonzott: N1  KATNO ahol N1 = {1, 2, 3, …} a Z nyelv egy alapvető halmaza és a példánk szerint: Kkolcsonozheto = {1  k1, 2  k2, 3  k4, …} na =3 Kkikolcsonzott = {1  k3, 2  k5, …} nb =2 A programnyelvekben használatos Kkolcsonozheto[2] hivatkozás meg- felel a Z nyelv Kkolcsonozheto(2) függvényhívásának. Nyíregyházi Főiskola

81 Kkolcsonozheto, Kkikolcsonzott: N1  KATNO na, nb: N
Mint a leírásnál, a konkrét modellt is egy séma formájában fogalmazzuk meg: KKonyvtar Kkolcsonozheto, Kkikolcsonzott: N1  KATNO na, nb: N i,j: 1..na  i  j  Kkolcsonozheto(i)  Kkolcsonozheto(j) i,j: 1..nb  i  j  Kkikolcsonozott(i)  Kkikolcsonzott(j) i: 1..na  (j: 1..nb  Kkolcsonozheto(i)  Kkikolcsonzott(j)) A KKonyvtar séma invariánsa három „univerzális meghatározásból” áll, melynek általános alakja:  deklarációk  predikátum azaz „valamennyi így bevezetett változóra teljesülnie kell a következő állításnak” A példában az állítások azt jelentik, hogy nem lehet egyik tömbnek sem ismétlődő eleme, illet nem szerepelhet egyszerre egy katalógusszám mindkét tömbben Nyíregyházi Főiskola

82 A konkrét Kolcsonzes művelet:
KKolcsonzes ΔKKonyvtar konyv?: KATNO i: 1..na  konyv? = Kkolcsonozheto(i) na' = na - 1 Kkolcsonozheto' = squash({i} Kkolcsonozheto) nb' = nb + 1 Kkikolcsonzott' = Kkikolcsonzott  (nb'  konyv?)  deklaráció  predikátum – a változónak létezik olyan értéke, amelyre az állítás igaz s f – tartománykivonás: azt a függvényt jelenti, amely úgy keletke-zik, hogy az f függvény értelmezési tartományából elvesszük az s tartományt. squash: az indexek átrendezésével összehúzza a „lyukas” tömböt Nyíregyházi Főiskola

83 Mindez nem egyszerű feladat
Még formálisan be kell bizonyítani, hogy a KKolcsonzes művelet valóban a Kolcsonzes művelet finomítása a két séma előfeltétele egyenértékű, azaz valahány-szor a Kolcsonzes végrehajtható, mindannyiszor a neki megfelelő KKolcsonzes is elvégezhető; a Kolcsonzes és a konkrét KKolcsonzes művelet által előállított végállapotok egyenértékűek Ezt az egyenértékűséget természetesen a tervben szereplő valamennyi műveletpárra be kell bizonyítanunk Mindez nem egyszerű feladat Nyíregyházi Főiskola

84 3. Megvalósítás A következő lépés az elvont leírás meg-valósítása, vagyis a kódolás intuitív módon megalkotjuk a szükséges algoritmusokat, majd a keletkezett kódot formális módszerek használatával összevetjük az eredeti tervvel; formális átalakítási szabályok alkalmazásával közvetlenül állítjuk lő az elvont tervből a kódot (műveleti finomítás). Nyíregyházi Főiskola

85 1.5. Objektumorientált tervezés, programozás
Nyíregyházi Főiskola

86 A fejlesztés strukturált és objektumorientált megközelítése
Eljárások, függvények: műveletek Adatok Objektum Objektum Objektum Strukturált program Objektumorientált program Nyíregyházi Főiskola

87 A strukturált megközelítés
A rendszert két részre osztja: adatok és műveletek A tervezés különálló adatmodellek és funkcionális modellek segítségével történik A megvalósításban az adatok és műveletek szigorúan elkülönülnek egymástól, és csak szükség esetén rendelődnek egymáshoz Az objektumorientált megközelítés Együttműködő objektumok halmaza Az objektumok adatokkal (ismeretekkel) rendelkeznek Az objektumok feladatokat végeznek Nyíregyházi Főiskola

88 Objektum, osztály Objektum: Információkat tárol, és kérésre feladatokat hajt végre. Logikailag összetartozó adatok és rajtuk dolgozó algoritmusok összessége: adatok metódusok Az objektumot üzenetek (kérelmek) által lehet megkérni a feladatok elvégzésére. (Ez egy metódus végrehajtását jelenti.) Osztály (class): Objektumtípus, minta, amely alapján példányokat, azaz objektumokat hozhatunk létre. Nyíregyházi Főiskola

89 Kialakulása, előnyök, célok
60-as évek vége Válasz a szoftverkrízisre A szoftverfejlesztés során az együtt változó részek elkülöníthetők Projektek közötti újrahasznosíthatóság növelése Nyíregyházi Főiskola

90 OOP jellemzők Bezárás, az információ elrejtése: az adatokat csak interfészeken (metódusok) keresztül lehet elérni. Öröklődés: az utód osztály örökli az ős adatait, metódusait, valamint tartalmazhat újakat, és felülírhat régi metódusokat. Polimorfizmus – többalakúság: ugyanarra az üzenetre (kérelemre), azaz metódus hívásra, különböző objektu-mok különbözőképpen reagál-hatnak. Utánzás, modellezés elvének alkalmazása a programo-zásban Nyíregyházi Főiskola

91 OO program vezérlő objektum üzenet3 objektum3 fut üzenet1 üzenet2
Egy objektumorientált program egymással kommunikáló objektumok összessége, melyben minden objektumnak megvan a feladatköre vezérlő objektum üzenet3 objektum3 fut üzenet1 üzenet2 objektum1 objektum2 üzenet1 Nyíregyházi Főiskola

92 Az objektumközpontú tervezés jellemző lépései
A szükséges osztályok azonosítása: az adott alkalmazási terület milyen osztályok, objektumok bevezetését teszi szükségessé. A jó tervezés kulcsa a valóság valamely részének közvetlen modellezése, vagyis a program fogalmainak osztályokra való leképezése. Az osztályok feladatainak meghatározása: meg kell határozni a rendszerben előforduló valamennyi osztály szerepét és feladatát. Az osztályokkal együttműködő osztályok meghatározása Nyíregyházi Főiskola

93 A fenti célokat segíti a CRC kártyák készítése (Class, Responsibility, Collaborators, vagyis Osztály, Felelősség, Együttműködők); brainstorming eszköz. elkészítése: a specifikáció szövegéből a főnevek osztályok, igék felelősségek (feladatok) lesznek. nem része az UML-nek, de nagyon népszerű technika Class name: Shape Superclass: Drawable Subclasses: Circle, Rectangle, … Responsibilities: Collaborations: Knows location, size Point, BoundingBox Draw self on canvas Canvas Move self Nyíregyházi Főiskola

94 Felhasználási esettanulmányok alapján finomítani kell az osztályok feladatköreit (use case): kiválasztunk jellemző alkalmazási példákat, és a terv alapján nyomon követjük az üzenetek objektumok közötti áramlását. A használati esetek a rendszert (dinamikusan) működő egységként tekintik. Át kell tekintenünk az osztályok egymás közötti viszonyát: „esete”, „hasonló”, „része” Hierarchiába szervezés: ez az öröklődés révén lehetővé teszi a kód újrahasznosíthatóságát; elvont osztályok Újrahasznosítható tervezési keretrendszerek létrehozása: egymással együttműködő osztályok rendszere valamilyen feladatkör megoldására Nyíregyházi Főiskola

95 OO szoftver fejlesztése
UML (Unified Modeling Language, Egységesített Modellező Nyelv): Grafikus jelölésrendszer a szoftver különböző nézeteinek modellezésére Egységesített Eljárás (Unified Process): Módszertan a fejlesztés módjára vonatkozóan C++, Java, stb.: Magas szintű programnyelvek programjaink implementálásához CASE eszközök: pl Rational Rose Nyíregyházi Főiskola