A szoftvertervezés módszerei - stadopedia
A legáltalánosabb és leginkább alkalmazható: az alulról felfelé történő fejlesztés módszere és a PS lefelé irányuló fejlesztésének módszere.
Az alulról felfelé irányuló fejlesztés módja a következő. Először is, a program moduláris felépítése egy fa formájában van kialakítva. Ezután felváltva programozott modulok a program, kezdve a modulok a legalacsonyabb (levelek a fa szerkezetű moduláris program) oly módon, hogy az egyes programozható modul, minden modul már programozva, ahová utalhat. Miután az összes programmodul programozva lettek, tesztelésük sorrendben történik, és elvileg ugyanabban a (növekvő) sorrendben debugolták, amelyben programoztak. A programfejlesztés ezen sorrendje első pillantásra teljesen természetes: minden modul kifejezetten a programozott közvetlen alárendelt modulok programozásában fejeződik ki, és a tesztelés során már hibajavított modulokat használ. A modern technológia azonban nem javasolja a programfejlesztés ilyen sorrendjét. Először is, a programozás egy modul nem igényel jelenlétében szöveg által használt modulok, hogy - ez elegendő, hogy valamennyi alkalmazott modul csak a megadott (a kötet, amely lehetővé teszi, hogy építsenek egy megfelelő utalás), és a teszt is lehetséges (sőt , amint azt az alábbiakban mutatjuk be, hasznos) a használt modulokat szimulátorokkal (oszlopok, illesztőprogramok) kicserélni. Másodszor, minden program bizonyos mértékig e bizonyos belső, de a moduljait globális szempontok (a végrehajtási elveket, a feltételezések, adatstruktúrák, és hasonlók), amely meghatározza annak fogalmi integritását és kialakult a fejlődése során. Amikor a fejlődő globális uplink információt a modulok az alsó szinten még nem teljesen egyértelmű, ezért gyakran van szükség újraprogramozni őket, ahol jelentős finomítása a globális információs (például a globális adatstruktúra változik) kerül sor, amikor a programozás más modulokkal. Harmadszor, a korszerű vizsgálati mindegyik modul (kivéve az agy) létre kell hoznia egy host program (modul), amely a felkészülés a teszt modul szükséges állami információs környezet és hajtsa végre a megfelelő kezelést is. Ennek következtében a nagy mennyiségű „hibakeresés” program és ugyanakkor nem nyújt garanciát arra, hogy az egység tesztelése végezzük a feltételeket, amelyek fogják elvégezni a munkaprogramot.
A top-down fejlesztés módja a következő. Az előző módszerhez hasonlóan a program moduláris felépítését először fa formában alakítják ki. Ezután felváltva programozott modulok a program, kezdve a modul a felső réteg (a fej), változások a programozás minden más modul csak akkor, ha a már programozott egy modult, amely hozzáfér azt. Miután minden programmodult beprogramoztak, azokat váltakozva tesztelik, és azonos (csökkenő) sorrendben debugolják. Ezzel teszteljük a program fejmodulját, amely az egész tesztelt programot reprezentálja, és ezért az információs környezet "természetes" állapotában tesztelik, amelyen ez a program elindul. Ugyanakkor a modulok, amelyekhez a fejegység címezhető, helyettesítik azok szimulátorai (úgynevezett dugók). Minden szimulátor modul nagyon egyszerű program fragmens, amely lényegében azt jelzi az a tény, utalva a szimulált modul termel megfelelő működtetéséhez szükséges a program feldolgozását értékeit a bemenő paraméterek (néha a nyomtatás), és kimenetek, ha szükséges, előre feltöltött megfelelő eredményt. A fej és a későbbi modulok tesztelése és hibakeresése után egy átmenetre kerül sor a szimulátorok által jelenleg bemutatott modulok tesztelésére. Ehhez a szimulátort a vizsgálatra kiválasztott modul helyébe a modul és emellett adunk azoknak utánzói, modulok, amelyek elérhetők a kiválasztott teszt modult. Ugyanakkor minden ilyen modult az információs környezet "természetes" állapotaival tesztelnek, amelyek akkor jelentkeznek, amikor a modul a vizsgált program végrehajtása során megérkezik. Így egy nagy mennyiségű "hibakeresés" programozás az upstream teszteléssel helyettesíthető a programban használt modulok meglehetősen egyszerű szimulátorainak programozásával. Ezenkívül a szimulátorok kényelmesen használhatók annak érdekében, hogy a szimulátorok által létrehozott kívánt eredmények beállításával játszhassanak együtt a tesztek kiválasztásával. A programfejlesztés ezen sorrendjével időben létrejön minden szükséges globális információ, pl. egy nagyon kellemetlen hibás forrás a modulok programozásakor megszűnik. Néhány hiánya felülről lefelé fejlődés, ami bizonyos nehézségeket annak alkalmazásáról, annak szükségessége, hogy figyelmen kívül hagyja az alapvető képességek a programozási nyelv, feltalálás absztrakt műveletek, amely később végre kell hajtani dedikált program modulokat. Az ilyen absztrakciók képessége azonban úgy tűnik, hogy a nagy szoftvereszközök fejlesztéséhez szükséges feltételnek tűnik, ezért fejleszteni kell.
A növekvő és csökkenő fejlődés (amelyet klasszikusnak fogjuk nevezni) szempontjainak egyik jellemzője az a követelmény, hogy a moduláris struktúrát kifejlesszük a modulok programozásának (kódolása) előtt. Ez a követelmény teljes mértékben megfelel a vízesés fejlesztési megközelítést az SS, hiszen a fejlesztés a moduláris szerkezet a program és az ezt kódoló végezzük különböző fejlettségű az SS: Az első lépés építésének befejezésére, az SS és a második - megnyitja a kódolási lépést. Azonban ezek a módszerek számos kifogást emelnek: kétségesnek tűnik, hogy a modulok programozása előtt lehetőség nyílt a program szerkezetének pontos és értelmes kidolgozására. Valójában erre nincs szükség, ha több modernizálja a vízesés megközelítését. Az alábbiakban konstruktív és építészeti megközelítést javasolunk azoknak a programoknak a fejlesztésében, amelyekben moduláris struktúra alakul ki a programozási (kódolási) modulok folyamatában.
A programfejlesztés konstruktív megközelítése a felülről lefelé történő fejlesztés módosítása, amelyben a modul moduláris felépítése során a program moduláris felépítése alakul ki. Egy konstruktív megközelítésű program kidolgozása a fej modul programozásával kezdődik, a program egészének meghatározása alapján. Ebben az esetben a program specifikációja a fejmodul specifikációjaként kerül elfogadásra, amely teljes felelősséget vállal a programfunkciók teljesítéséért. A fej egység programozásának folyamata esetén, ha ez a program elég nagy, kiválaszthatók a részegységek (belső funkciók), amelyek alapján a fej modul be van programozva. Ez azt jelenti, hogy minden hozzárendelt részfeladat (függvény) számára egy olyan specifikáció jön létre, amely végrehajtja azt a programfraglt, amely a jövőben a modulok egy bizonyos részfelülete által képviselhető. Fontos megjegyezni, hogy van még végrehajtásáért felelős kijelölt funkció feje van (talán az egyetlen) az egység részfa, hogy a leírás a kiválasztott funkció egyszerre leírás a fej modul részfa. A program főmodulján a meghatározott altitest fejmoduljára hívást állítanak fel a hozzárendelt függvény eléréséhez a létrehozott specifikációnak megfelelően. Így a programfejlesztés első szakaszában (a fej modul programozásakor) a fa felső kezdeti része alakul ki, például az 1.5 ábrán látható.
1.5. Ábra - Az első lépés a moduláris programstruktúra kialakításának konstruktív megközelítéssel
Hasonló műveletek végrehajtására kerül sor a programfájl aktuális állapotából kiválasztott egyéb modulok programozásakor a meghatározott, de még nem programozott modulok közül. Ennek eredményeként a programfa deformálódott, például az 1.6. Ábrán látható.
A programfejlesztés építészeti megközelítése a felemelkedő fejlesztés módosítása, amelyben a modul moduláris felépítése a modul programozásakor alakul ki. Ugyanakkor jelentősen eltérő fejlesztési célt tűztek ki: az alkalmazott programozási nyelv szintjének növelése, és nem egy konkrét program kidolgozása. Ez azt jelenti, hogy egy adott tartomány esetében jellemző funkciók vannak megkülönböztetve, amelyek mindegyike különféle feladatok megoldására használható ezen a területen, és az egyes funkciókat végrehajtó programmodulok meg vannak határozva, majd be vannak programozva. Mivel a folyamat a feladatok szétválasztása társított felhalmozódásának és szintézis megoldások problémái vannak egy adott területen, akkor általában először izoláljuk, és az egyes modulok valósul egyszerűbb funkciókat, majd fokozatosan jelennek modulok segítségével korábban elkülönített funkciót. A modulok ilyen csoportja abban a várakozásban jön létre, hogy egy adott tartomány egy adott programjának konstruktív megközelítés keretében történő kifejlesztésében ezeknek a moduloknak néhány elfogadható lehet. Ez lehetővé teszi, hogy jelentősen csökkentsük a munkaerőköltségeket egy adott program fejlesztéséhez azáltal, hogy az előkészített és a gyakorlatban teszteltük az alsó szint moduláris struktúráit. Mivel az ilyen struktúrák újrahasznosíthatók különböző egyedi programokban, az építészeti megközelítést úgy lehet tekinteni, mint amely a programozás során megismétlődés elleni küzdelmet jelent. E tekintetben az építészeti megközelítés keretében létrehozott programmodulokat rendszerint paraméterezik az ilyen modulok alkalmazhatóságának megerősítésével, paraméterekhez való igazítással.
1.6. Ábra - A moduláris programstruktúra kialakításának második lépése konstruktív megközelítésben.
A klasszikus top-down fejlesztési módszert javasoljuk, hogy először az összes modult fejlesztett szoftver, és csak ezután kezdődnek a lefelé való tesztelése, amely szintén teljes mértékben megfelel a vízesés megközelítés. Azonban ebben a sorrendben a fejlődés nem kellően indokolt: a tesztelés és hibajavítás modulok megváltoztathatják a specifikáció a szolga modulok, és még egy változás a nagyon moduláris szerkezet a program úgy, hogy ebben az esetben a programozás egyes modulok lehet haszontalan munka. Racionálisabbnak tűnik számunkra, hogy más eljárást dolgozzunk ki egy olyan program kidolgozására, amelyet a szakirodalom ismert a felülről lefelé történő végrehajtás módszerként. ami a vízesés megközelítésének néhány módosítását jelenti.
Ebben az eljárásban minden programozott modult azonnal teszteljünk, mielőtt egy másik modul programozásával folytatnánk.
Mindezen módszerek különböző változatokkal rendelkeznek, attól függően, hogy a program faszerkezetének csomópontjait (moduljait) miként kerülik el a fejlesztés folyamatában. Ezt például rétegekben lehet elvégezni (minden szinttel rendelkező modulok fejlesztése, mielőtt a következő szintre lépnének). A felülről lefelé történő fejlődéssel a fa is lexicográfiai sorrendben haladhat (felülről lefelé, balról jobbra). Vannak más lehetőségek a fa áthaladásához. Tehát konstruktív megvalósítás esetén tanácsos követni a Fuksman ötleteit, amelyeket a függőleges foliálás módszerében használt, amit a programfa előterjesztése javasolt.
Az ilyen kitérés lényege a következő. Keretében konstruktív megközelítés először végre csak azokat a modulokat, amelyek szükségesek a legegyszerűbb változata a program, ami általában csak akkor lehet végrehajtani egy nagyon korlátozott számú bemenő adathalmaz, de az ilyen adatokat, ez a probléma megoldódik, amíg a végén. Ahelyett, hogy a többi modulok, melyek egy ilyen programban hivatkozott, csak a utánzói kerülnek be a programot annak biztosítására, hogy a fő, jelezve mintegy túllépve az adott esetben. Ezután a program hozzáadja a végrehajtása néhány más modulok (például ahelyett, hogy néhány, a rendelkezésre álló szimulátorok), hogy biztosítsák a normális teljesítménye néhány más beviteli adathalmaz. Ez a folyamat szakaszosan folytatódik a kívánt program teljes végrehajtásáig.
Így a program fája a legrövidebb út célja, hogy egy normálisan működő program ezt vagy azt a változatot (először a legegyszerűbb) megvalósítsa. Ezzel összefüggésben ezt a konstruktív megvalósítást a céltudatos konstruktív megvalósítás módszerének nevezték. Ennek a módszernek az az előnye, hogy a kifejlesztett program már működő verziója már korai szakaszban már létrejött. Pszichológiailag a doping szerepe, drámai módon növeli a fejlesztő hatékonyságát. Ezért ez a módszer nagyon vonzó.
Az 1.7. Ábra a program szerkezetének kialakításánál figyelembe vett módszerek általános osztályozását mutatja be.
1.7. Ábra - A programstruktúra kidolgozásának módszereinek osztályozása