1. Programtervezés

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)

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

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

1.0. Strukturált programozás

 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

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.

É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ó

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

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)

További érvek a goto mellőzésére Világos írásmód és kifejezőerő címke: címke: if a > 0 goto 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...

É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)

 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

1.1. A feladat funkcionális felbontása

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.

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

Á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 )

 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

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.

Á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

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 := 0 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

 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

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

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

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

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.

 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

 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.

Ö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.

1.2. A Michael Jackson programtervezési módszer JSP – Jackson Structured Programming

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.

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 Felső fél Közép Alsó fél Kép 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

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

 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

Programszerkezeti diagram: Felső fél fel- dolgozása Kép fel- dolgozása * * Alsó fél fel- dolgozása Közép 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)

 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: 1. n darab csillag nyomtatása 2. üres sor nyomtatása 3. s darab szóköz nyomtatása 4. s növelése 5. s csökkentése 6. n növelése 7. n csökkentése 8. n és s kezdeti beállítása

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

 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

Ö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

Példa: Adjunk össze egy számsorozatot, melynek a végét egy negatív szám jelzi! Adatszerkezet-diagram Törzs Negatív szám Számok Szám * Törzs fel- dolgozása Számok fel- dolgozása * Negatív szám feldolgozása Szám fel- dolgozása 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 Programszerkezet-diagram az elemi műveletekkel

Á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

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 Törzs Fájl * Fájlvége Bejegyzés Férfi Nő   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 Pszeudokód Látható, hogy az alternatívákra utaló,  -rel jelölt dobozok if…then…else szerkezetként jelennek meg a kódban.

Példa: Programming Programminghttp://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 –

The run length encoder input

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

The next step is to describe the correspondences between the operations in the input and output structures.

In this example, there is no structure clash, so the two structures can be merged to give the final program structure.

 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 1. read a byte 2. remember byte 3. set counter to zero 4. increment counter 5. output remembered byte 6. output counter  The iterations also have to be fleshed out. They need conditions added. Suitable conditions would be 1. while there are more bytes 2. 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

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 #include #include #include 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(); } c = getchar(); while (c != EOF && c == first_byte && count < 255){ count++; c = getchar(); } putchar(first_byte); putchar(count); putchar(first_byte); putchar(count); } return EXIT_SUCCESS; } } return EXIT_SUCCESS; }

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

 Alkalmazhatóság  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.

1.3. Adatfolyam tervezés

 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ó

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. Bemenet Átalakítás Kimenet Billentyűzet Hőmérséklet Celsiusban Hőmérséklet Fahrenheitben Képernyő Előállítottuk a program átfogó logikai szerkezetét

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

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á

Átalakítás KimenetBemenet Lekérdezés Kimenet Billentyűzet Név Név és telefonszám Képernyő Adattár

Az adatáramlás diagram előállításának módszerei 1. 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 2. A kimeneti adatáramból indulunk ki, majd a szerkezetben visszafelé haladunk 3. 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

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

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

 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.

 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

Általánosan használható információs rendszerek tervezésére (top down)

1.4. Formális módszerek

 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ú Természetes nyelv – formális leírás

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

High-Integrity systems are complex, software controlled systems, which, in the event of failure, have a high impact on humans, the environment, organizations and society. 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

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)

Eszközök  Z formális nyelv (Z notation, ejtsd zed)  Vienna Development Method (VDM)

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 P kolcsonozheto, kikolcsonzott: P KATNO kolcsonozheto  kikolcsonzott = { } KATNO hatványhalmaza predikátum, melynek igaznak kell maradnia (invariáns)

 Műveletek megadása  ellenőrzés: az invariánsoknak igaznak kell maradniuk  pl. Kolcsonzes művelet Kolcsonzes konyv?: KATNO konyv?  kolcsonozheto ΔKonyvtar 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 P kolcsonozheto, kolcsonozheto': P KATNO kolcsonozheto  kikolcsonzott = { } P kikolcsonzott, kikolcsonzott': P KATNO kolcsonozheto'  kikolcsonzott' = { } művelet utáni állapot művelet előtti állapot bemeneti változó a művelet előtti és utáni állapotok leírása előfeltétel

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

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

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!

Tehát a bizonyítandó állítás kolcsonozheto'  kikolcsonzott' = kolcsonozheto  kikolcsonzottBizonyí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

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

Példánkban a kolcsonozheto és kikolcsonzott típusoknak feleltessünk meg egy-egy tömböt: … k1 k2k4 … k3 k5 Pl. Kkolcsonozheto : Kkikolcsonzott: nb = 2 na = A Z nyelvben a tömb egy függvénnyel modellezhető, példánkban Kkolcsonozheto, Kkikolcsonzott: N 1  KATNO ahol N 1 = {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. K : konkrét

Mint a leírásnál, a konkrét modellt is egy séma formájában fogalmazzuk meg: KKonyvtar N Kkolcsonozheto, Kkikolcsonzott: N 1  KATNO N 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

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

 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

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).

1.5. Objektumorientált tervezés, programozás

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

 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

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 (): Objektumtípus, minta, amely alapján példányokat, azaz objektumokat hozhatunk létre.  Osztály ( class ): Objektumtípus, minta, amely alapján példányokat, azaz objektumokat hozhatunk létre.

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

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

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

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

 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 ShapeSuperclass: Drawable DrawableSubclasses: Circle, Rectangle, … Responsibilities:Collaborations: Knows location, size Point, BoundingBox Draw self on canvas Canvas Move self

 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

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