5.3.1. Jelenlegi környezet fizikai adatfolyam-modellje
A jelenlegi környezet folyamatait az adatfolyam-modellezési technika segítségével lehet felmérni. Ez leírja a nagyobb külsõ objektumokat a rendszeren kívül, amelyek információk forrásai illetve befogadói, a rendszeren belüli folyamatokat, az adatok lerakatait, amelyek idõlegesen tárolják az információt, és a közöttük lévõ adatfolyamokat. A létrejövõ ábrákat ki lehet egészíteni mögöttes leírásokkal a feldolgozási folyamatok részleteirõl és az elemi adategységekrõl, amelyek mozognak a rendszerben. A rajzolás során tisztázódik a felmérés alá vont rendszer kiterjedése, fõbb felépítése és mûködése. A cél az, hogy a jelenlegi fizikai folyamatokat írják le, az összes hiányossággal, felesleges ismétlõdéssel és hibával együtt. Ezt a leírást fel lehet használni, mint hivatkozási alapot a követelmények megfogalmazásához.
5.3.2. Jelenlegi környezet logikai adatmodellje
A jelenlegi környezet által tárolt illetve nyújtott információk szerkezetét és tartalmát a logikai adatmodellezés technikájával lehet meghatározni. Ez a meghatározás eleve logikai, mivel a jelenlegi környezet adatai fizikailag nem biztos, hogy bármilyen egységet alkotnak, valószínûleg eltérõ adathordozókon, lazán vagy egyáltalán nem kapcsolódó adatállományokban, illetve részben papíron vagy "fejben" léteznek. A cél az, hogy meghatározzuk a logikailag összetartozó elemi adatok csoportjait és a csoportok (egyedek) közötti összefüggéseket, egy olyan statikus, általános leírást adva, amely az adatokat áttekinthetõ szerkezetbe fogja össze, és amely egyaránt képes az összes létezõ adatelõfordulást tárolni, illetve az ismert információs igényeket kielégíteni. Az adatszerkezeti ábrát kiegészíti háttérleírás az egyedekrõl, kapcsolatokról és az adatelemekrõl, de itt még nem kell teljes leírást adni.
5.3.3. Logikai adatfolyam modell
A jelenlegi környezet folyamatainak fizikai vonatkozásait itt meg kell szüntetni, az adattárolási kettõsségeket fel kell oldani, a folyamatokat logikus szerkezetbe kell rendezni. Itt kell összevetni a folyamatokat az adatokkal, egy olyan megfeleltetést adva, amely kizárja, hogy a folyamatok által használt különbözõ adattárak ugyanazokra az adatokra vonatkozzanak. A cél az, hogy meghatározott szabályok alkalmazásával kiszûrjük (és a követelmény jegyzékben szükség esetén rögzítsük) a fizikai elemeket és a felesleges többszörözéseket a fizikai folyamatok modelljébõl, kialakítva egy olyan logikai képet a mûködésrõl, amely valószínûleg az új rendszerben is érvényes lesz. Ez a logikai kép lehet az alapja a további lépéseknek, azaz a rendszerszervezési alternatívák kiválasztásának és az igényelt rendszer meghatározásának. A logikai adatfolyam modellt a szokásos háttérleírásokon kívül ki kell egészíteni egy olyan leírással, amely összeköti õt az adatszerkezettel, megfeleltetve a logikai adattárakat az adatszerkezetbeli egyedek csoportjainak.
5.3.4. Követelményjegyzék
A követelményjegyzékben kerülnek feljegyzésre a jelenlegi rendszerrel kapcsolatos illetve az új rendszerre vonatkozó követelmények. A cél az, hogy megfogható, számszerûsíthetõ módon legyenek a követelmények megfogalmazva, úgy, hogy a követelmények által kitûzött cél elérését késõbb objektív módon lehessen mérni.
5.5.1. Igényelt rendszer adatfolyam modellje
A szakasz elsõ lépéseként a jelenlegi környezet logikai adatmodelljét a választott rendszerszervezési alternatíva és az új követelmények figyelembevételével át kell alakítani, részletesen meghatározva az igényelt rendszer adatfolyam modelljét. A cél az, hogy olyan részletességû leírás készüljön az igényelt rendszer folyamatairól, ami alapján majd azonosítani lehet a rendszer funkcióit és eseményeit. Ez a modell kiindulási alapja lesz a funkció meghatározásnak és hivatkozási alap lesz az egyed-esemény modellezésben, mivel tartozni fog hozzá egy logikai adattár-egyed megfeleltetés, ami kapcsolatot teremt a folyamatok és az adatok között. A szakasz végtermékei között az adatfolyam modell nem szerepel.
5.5.2. Igényelt rendszer logikai adatmodellje
Ezt az adatmodellt a szakasz elején az adatfolyam modellel párhuzamosan kell kialakítani, a jelenlegi környezet logikai adatmodelljébõl, figyelembe véve a választott rendszertechnikai alternatívát és az új követelményeket. A cél az, hogy részletesen meghatározzuk a rendszer adatait, úgy, hogy azt késõbb a logikai illetve fizikai tervezésben fel lehessen használni. Ez az adatmodell a szakasz egyik végterméke és a szakasz során folyamatosan össze kell vetni az elkészülõ termékekkel, módosítva, ha szükséges.
A szakasz során van egy olyan lépés, amely kifejezetten a logikai adatmodell ellenõrzésére szolgál a relációs adatelemzési technika használatával. Ennek során a rendszer kritikus kimenetei és bemenetei alapján egy formális szabályokkal meghatározott tevékenységet elvégezve meg kell határozni az információs igényeknek legjobban megfelelõ, alacsony szintû ismétlõdéstõl mentes, optimális adatelrendezést, és össze kell azt hasonlítani az adatmodellel. Az eltéréseket ki kell értékelni és szükség esetén módosítani kell a logikai adatmodellt.
A relációs adatelemzés után megerõsített adatmodellt a funkciók feldolgozási folyamatainak meghatározásához kiindulási alapként kell felhasználni.
5.5.3. Funkció leírások
Az igényelt rendszer adatfolyam modelljébõl kiindulva részletesen meg kell határozni a rendszer funkcióit. Itt az a cél, hogy egy olyan dokumentum készüljön minden funkcióról, amely a szöveges leíráson kívül hivatkozik az összes alkotóelemére az adott funkciónak, meghatározva a részletes feldolgozási folyamatokat, összekapcsolva a folyamatokat az adatokkal. A funkció leírás az egész további fejlesztés során fennmarad és egyre újabb részekkel egészül ki, egészen a fizikai megvalósításig. Ebben a szakaszban meg kell határozni a funkciók mûködését kiváltó eseményeket (módosító funkcióknál), a funkciók bemenõ és kimenõ adatait és szerkezetüket, valamint a funkciókhoz tartozó mérhetõ követelményeket (szolgáltatási szinteket).
A funkciók feldolgozási folyamatait más technikákkal kell kialakítani. A lekérdezõ funkciókhoz a logikai adatmodellezés technikájának részeként a lekérdezési utakat kell meghatározni, megadva a lekérdezés adatainak elõállításához szükséges utat (egyedeket), amelyet a logikai adatszerkezeten kell bejárni. A módosító funkciókhoz tartozó feldolgozási részleteket az egyed-esemény modellezés során kell meghatározni.
5.5.4. Specifikációs prototípus
A rendszer kritikus funkcióira el lehet készíteni egy specifikációs prototípust. Ennek a célja az, hogy ellenõrizni lehessen a felhasználókkal együtt a rendszer követelményeinek a helyes megértését, ezért hívják specifikációs prototípusnak. Nem cél az, hogy a prototípust a fizikai megvalósítás során felhasználják. A szakaszon belül a funkciók kezdeti azonosítása után lehet elõállítani. Az eredményeit fel lehet használni a követelmény specifikáció bármely elemének a módosítására, elsõsorban a funkció leírások bemenõ és kimenõ adatainak leírásánál. A felhasználók által javasolt dialógus részleteket a logikai illetve fizikai tervezés során lehet felhasználni (pl. menüszerkezetek, tájékoztatási követelmények, szolgáltatási szintek stb.)
5.5.5. Feldolgozás meghatározása
Ez egy közös név a módszer 360. számú lépésének termékeire, ami az egyed élettörténeteket, esemény kölcsönhatási ábrákat és lekérdezési utakat jelenti.
Az egyed élettörténetek célja az adatbázist módosító események szabályszerûségeinek felderítése, egyedenként meghatározva a rendszer mögöttes mûködését, minden olyan szabályt, amely nem fejezhetõ ki az adatok statikus szerkezetével. Az események hatásait egyedenként felsorolva azonosítani lehet a feldolgozási folyamatok alapmûveleteit, amelyeket majd a logikai tervezés során kell feldolgozási folyamatokba szervezni.
Az esemény kölcsönhatási ábrák eseményenként sorolják fel az elérendõ egyedeket, hasonlóan a lekérdezési utakhoz, meghatározva az esemény által elindított feldolgozási folyamat által bejárt utat az adatszerkezeten. Ezekbõl az ábrákból fog a logikai tervezés feldolgozási folyamatokat szervezni.
A lekérdezési utak a lekérdezõ funkciókhoz, illetve funkció részekhez határozzák meg a bejárandó utat a logikai adatszerkezeten. Ezekbõl az ábrákból fog kiindulni a lekérdezõ feldolgozási folyamatok logikai tervezése.
5.5.6. Követelményjegyzék
A szakasz során a követelményjegyzék bejegyzéseit fokozatosan az elõálló specifikáció egyes elemeihez kell kötni. A szakasz végére nem maradhat olyan követelmény, amelyhez ne tartozna valamilyen specifikáció részlet. A nem-funkcionális követelményeket is teljes mértékben meg kell határozni, mert ezek alapján lehet majd a rendszertechnikai alternatívákat megadni és késõbb a fizikai tervezésnél a teljesítményt optimalizálni.
5.8.1. Módosító feldolgozási modellek
Az egyed-esemény modellezés termékeibõl kiindulva itt részletesen meg kell határozni a módosító (aktualizáló) folyamatok belsõ szerkezetét és a szerkezethez tartozó elemi mûveleteket és feltételeket, meghatározva az adatokkal kapcsolatos hibakezelést is. Minden eseményhez készül egy ilyen modell, amelynek a szerkezetét az eseményhez tartozó esemény kölcsönhatási ábra alapján kell kialakítani, figyelembe véve a szigorú sorrendiségeket a funkció leírás alapján. Az így létrejövõ feldolgozási szerkezethez mûveleteket kell rendelni. A mûködés lényegéhez tartozó aktualizáló mûveleteket az egyed élettörténeti ábrák alapján lehet összegyûjteni. Ezeket a mûveleteket, kiegészítve adatbázis navigálási és hibakezelési mûveletekkel, kell a szerkezet megfelelõ részeihez rendelni. A feldolgozási szerkezet elágazásaihoz és ismétlõdõ csoportjaihoz feltételeket rendelve készülnek el végül a módosító feldolgozási modellek. Ezek a modellek lesznek a belsõ feldolgozási folyamatok fizikai tervezésének alapjai.
5.8.2. Lekérdezõ feldolgozási modellek
A módosító modellekhez hasonlóan itt is az a cél, hogy a belsõ feldolgozást meghatározzuk. A kiindulópontot itt a lekérdezési utak jelentik, ezek alapján kell létrehozni a feldolgozási szerkezeteket. Figyelni kell a kimeneti adatok és az adatbázis szerkezete közötti szerkezeti (strukturális) ütközésekre. Ezek egy részét itt nem lehet feloldani, de fel kell jegyezni õket a fizikai tervezés részére. Az elemi mûveleteket a lekérdezések esetében nincs honnan összegyûjteni, mivel nem szerepelnek az egyed élettörténetekben, így itt kell ezeket meghatározni. A feldolgozási szerkezethez rendelve a mûveleteket és feltételeket elõállnak a lekérdezõ folyamatok modelljei.
5.8.3. A rendszer felhasználói felületének termékei
Itt a dialógustervezés segítségével elõ kell állítani azokat a leírásokat, amelyek meghatározzák a felhasználó rendszeren belüli "mozgását", funkciókon belül és funkciók között egyaránt. A cél az, hogy a funkcióleírások, a belépõ és kilépõ adatok szerkezete és a követelmény jegyzék alapján olyan logikai leírás keletkezzen, amelyik nem fizikai korlátokat vesz figyelembe, hanem a felhasználó nézõpontjából határozza meg a rendszer feldolgozási folyamatainak egységeit, azokat a logikai adatcsoportokat, amelyekkel a felhasználó kapcsolatba kerül, a lehetséges útvonalakat, ahogyan ezek között a csoportok illetve feldolgozási egységek között közlekedik, a tájékoztatás lehetõségeit. Az esetleg elkészített és kiértékelt specifikációs prototípus alapján a kritikus dialógusokat könnyebben meg lehet határozni. Az eredmény egy olyan termékhalmaz, amely dialógusokra osztja fel a rendszer mûködését, meghatározza a dialógusok szerkezetét, belsõ bejárását és tartalmát (dialógus vezérlési táblázatok, dialógus szerkezetek), illetve meghatározza a dialógusok szintjén a tájékoztatási igényeket, a dialógusok közötti általános és egyedi mozgási lehetõségeket (dialógusszintû információnyújtás, menüszerkezetek, parancs-szerkezetek).
5.9.1. Fizikai adatterv
Ez az egyik végterméke ennek a szakasznak. A logikai adatmodellbõl kiindulva el kell készíteni egy kezdeti adattervet, figyelembe véve a technikai környezet elõírásait, lehetõségeit és korlátait. A nem-funkcionális követelmények és a funkcióleírások szolgáltatási szintre vonatkozó követelményei alapján meg kell becsülni, hogy a kezdeti adatterv megfelel-e az igényeknek (tár- és idõigény becslés). Ha nem, és csak akkor, optimalizálni kell a fizikai adattervet, illetve esetleg jelezni kell további feldolgozási részletekre vonatkozó követelményeket (pl. rendezés). Ha az optimalizálás során a fizikai adatterv jelentõsen eltávolodik a logikai adatmodelltõl, akkor azt majd a folyamat-adat kapcsolat kialakításakor kezelni kell. A fizikai adatterv jelentheti a konkrét adatbázis létrehozását az adott technikai környezetben, mivel ez nem jelent sokkal több erõfeszítést az adatterv leírásánál. Mindenképpen el kell azonban készíteni egy adatbázis specifikációt, mivel a rendszer karbantartása során erre szükség lesz.
5.9.2. Fizikai folyamatterv
Itt kell specifikálni, a technikai környezet elõírásainak, korlátainak és lehetõségeinek figyelembevételével a funkciók minden komponensét. A funkciók logikai komponenseihez hozzá kell rendelni a fizikai megvalósítás részleteit. Ez azt jelenti, hogy létre kell hozni egy funkció-komponens megvalósítási tervet, amelyben az összes funkció minden logikai eleméhez (komponenséhez) meg kell határozni a megvalósításának módját (fizikai alkotóelemét), különös figyelmet szentelve a kettõzések elkerülésére és a közös részfeldolgozások kiemelésére (újrafelhasználás). Ehhez a tervhez kapcsolódóan, azokat a komponenseket, amelyeket nem-procedurális módon meg lehet határozni, részletesen le is kell írni, illetve a technikai környezet számára létre kell hozni (fizikailag meg kell valósítani). Ennek az az oka, hogy a nem-procedurális részek megvalósítása közelebb áll a tervezéshez, mint a hagyományos megvalósításhoz és lehetõvé teszi, hogy az alacsony szintû részleteket már a technikai környezet önállóan kezelje (alkalmazás generátorok, negyedik generációs nyelvek stb.). Természetesen itt nincs szó arról, hogy a megvalósítás olyan tevékenységeit, mint tesztelés, hibajavítás, itt el kellene végezni.
Azokhoz a funkció elemekhez, amelyeket nem lehet nem-procedurális módon meghatározni, el kell készíteni egy részletes fizikai specifikációt. Itt kell kezelni a logikai tervezés során felderített strukturális ütközési eseteket, amelyek esetleg olyan feldolgozási részleteket igényelnek, mint sorbarendezés vagy adatok ideiglenes tárolása.
5.9.3. Folyamat-adat kapcsolat
A fizikai folyamatterv a logikai adatmodellen alapul, mivel a felhasználók a rendszer karbantartása során abból kiindulva látják át az esetlegesen módosítani kívánt adatokat, illetve a rendszer használata során utalhatnak rá (pl. ad-hoc, felhasználó által összeállított lekérdezések esetén). Ha a fizikai adatterv az optimalizálás során jelentõsen eltávolodna ettõl a logikai adatmodelltõl, akkor léte kell hozni a folyamat-adat kapcsolatot, amely a fizikai folyamatok számára a fizikai adatokat a logikai adatmodellnek megfelelõen láttatja. Megfelelõ adatbáziskezelõ eszköz használatával a folyamat-adat kapcsolat egyszerûen létrehozható vagy eleve szükségtelen. Adatbáziskezelõ rendszer nélkül a folyamat-adat kapcsolat létrehozása a fizikai tervezés és megvalósítás során szükséges erõfeszítések mértékét jelentõsen megnöveli.
