Rendszerterv

Egy rendszerterv általában az alábbi fejezetekből és alfejezetekből áll:

1. A rendszer célja: Definiálja a rendszer célját. Gyakran leírjuk azt is, ami nem cél, hogy ezzel is tisztázzuk a feladat kört (scope), amit meg akarunk oldani.

2. Projekt terv: Itt soroljuk fel a rendszer létrehozásához rendelkezésre álló erőforrásokat. Ezek közül a két legfontosabb az emberek és az idő. Fontos tisztázni a felelősségi köröket. Itt adjuk meg az ütemterv alapján a mérföldköveket.

3. Üzleti folyamatok modellje: Itt adjuk meg a támogatandó vagy kiváltandó üzleti folyamatokat. Leírjuk az eseményeket, a felhasznált erőforrásokat, a folyamatok bemeneteit, kimeneteit, a szereplőket. A modell célja a megértés, így sok példát is tartalmazhat.

4. Követelmények: Itt a teljes követelmény listából csak azokat soroljuk fel, amelyek megvalósítását megcélozza a rendszerterv. Fontos, hogy az itt leírt követelmények a tényleges követelmények legyenek félreértések nélkül. A követelmények a fejlesztés során változhatnak. Erre a különböző módszertanok más és más választ adnak. Itt kell felsorolnunk a vonatkozó törvényi előírásokat, szabványokat, amiket be kell tartanunk.

5. Funkcionális terv: A funkcionális terv a fejlesztők szemszögéből írja le az elkészítendő funkciókat a funkcionális specifikáció alapján (ami a felhasználó szemszögéből írja le a funkciókat). Nagyon fontos része a használati esetek lefutásai. Ezek adják meg, hogyan kell megvalósítani a funkciót. Ezek általában aktivitási és szekvencia UML diagramok. A határ osztályok (presenter) a képernyők tartalmát és funkcionalitását leíró osztályok.

6. Fizikai környezet: Itt határozzuk meg, hogy milyen platformon (Java, .NET, …) fogunk fejleszteni, milyen operációs rendszerre és hardverre. Gyakran fontos tudnunk a hálózat felépítését is, például, hogy van-e tűzfal, az milyen portokat engedélyez. Ha vannak megvásárolt komponenseink, azokat is itt kell megadnunk.

7. Absztrakt domain modell: Itt írjuk le a megvalósítandó rendszer fogalmait. Illetve a megvalósítás nagyon magas szintű vázát általában egy-két konkrét példán keresztül. Megadjuk a fő komponenseket és ezek kapcsolatait. Ez a rendszer nagyvonalú (vagy csak konceptuális) terve.

8. Architekturális terv: A nem-funkcionális követelmények alapján kell kialakítani. Ez csak akkor lehetséges, ha ezek mögé nézünk. Pl. ha az a követelmény, hogy 10 000 felhasználót kell kiszolgálnia a rendszernek, akkor meg kell tudnunk, mi történik a 10 001. felhasználóval, mi van, ha ez a vezérigazgató. Fontos, hogy a választott architektúra könnyen tudjon alkalmazkodni a változásokhoz (pl. konfigurációs állományok használata) és rugalmasan bővíthető legyen. Itt adhatjuk meg a biztonsági funkciókat, pl. a jogosultság kezelést.

9. Adatbázis terv: Meg kell adni a táblákat, a köztük lévő kapcsolatokat. Általában elvárás, hogy az adatbázis terv 3. normálformában legyen. Itt lehet megadni a tárolt eljárásokat is.

10. Implementációs terv: Az implementációs terv adja meg a megvalósítás osztályait. Meg kell felelnie a kiválasztott architektúrának. A lenti alfejezetek 3-rétegű alkalmazás esetén használhatóak. Az implementációs tervben érdemes tervezési mintákat alkalmazni és betartani a tervezési alapelvek ajánlásait, hogy rugalmas, könnyen bővíthető és módosítható szerkezetet kapjunk.

11. Tesztterv: Lefekteti a tesztelés elveit, folyamatát és kontrolját. Meghatározza a fő teszteseteket.

Megahatározza a sikeres teszt kritériumait.

12. Telepítési terv: A rendszer kialakítására (pl. szerver telepítés), a telepítő csomag elkészítésére vonatkozó elvek, megszorítások. Itt is meg lehet adni a fizikai környezetet.

13. Karbantartási terv: A szoftver frissítésének módja, folyamata. Karbantartási teszttervek. Általában csak akkor készül el, ha már egy verziót átadtunk és a következő verziót tervezzük.

5.7.1. Határosztály tervezés

Az adatbeviteli felület tervezés célja, hogy meghatározza az adatbeviteli felületeket, mező szinten teremtse meg a kapcsolatot az adatmodell entitás osztályai és az adatbeviteli felületek között.

Egy határosztály alatt egy olyan logikai egységet/osztályt értünk amelyik:

1. a szereplő és az rendszer közötti kommunikációért felelős, 2. inputot fogad és továbbít,

3. outputot generál.

A határosztályokon szereplő funkciókat a határosztályok metódusaiban kell megadni. A határosztályok attribútumai megadják a képernyőn megjelenő input mezőket.

A határosztályok közötti statikus kapcsolatokat osztály diagramokkal mutathatjuk meg. Például határosztály lehet egy képernyő is, de határosztálynak tekinthetjük egy képernyő egyik részét is. Például egy keresési ablakban a kereső mező és a találati lista két különböző határosztálynak tekinthető.

Határosztályok közötti függőségeket, hogy melyik határosztályból hová lehet eljutni, úgynevezett kollaborációs diagramokkal mutatjuk meg. A diagramokon a határosztályok lesznek a csomópontok és az őket összekötő asszociációk reprezentálják a képernyők egymásutániságát.

5.7.2. Menü hierarchia tervezés

A menü hierarchia tervezés célja, hogy meghatározza az adott alkalmazás menüszerkezetét, az egyes menüelemekhez hozzárendelje az adott alkalmazás által szolgáltatott funkciókat.

A menü hierarchia tervezést három lépésben valósítjuk meg:

1. Először megtaláljuk az alkalmazás fő menüstruktúrájának elemeit.

2. Majd a logikai alrendszerek menüstruktúráját kell meghatározni.

3. Legvégül a menü elemeket össze kell kötni a határosztályokkal egy osztálydiagramon így mutatva meg azt, hogy melyik menüt választva melyik képernyő jelenik meg.

A menü hierarchiát általában osztálydiagramon ábrázoljuk.

5.7.3. Storyboard

A határosztály modellezésnek egy felsőbb szintű nézetét mutatja a Storyboard modellezés. Megmutatja, hogy melyik ablakból milyen szolgáltatások érhetők el.

Előnyei:

1. ablak elérhetőségi hierarchiák megértését biztosítja 2. user interface designer-eknek szól

3. rövid tevékenység leírások Storyboard tervezés kérdései:

1. Milyen szolgáltatásokra lenne a felhasználónak szüksége?

2. Milyen szolgáltatásokat tud a rendszer adni?

3. A fentiek közül milyen szolgáltatásokat kéne megvalósítani?

Storyboard példa:

A use case kezeli a bejövő üzeneteket, mielőtt használhatósági szempontokkal kiegészülne.

1. A use case akkor indul, mikor a levelező user kérést küld, hogy üzeneteket kezelhessen, és a rendszer megjeleníti azokat.

2. A levelező user ezután követhet a következő lépésekből egyet vagy többet:

3. Rendezheti az üzeneteket küldő vagy tárgy szerint.

4. Elolvashajta az üzeneteket.

5. Fájlként mentheti az üzenetet.

6. Az üzenet csatolmányát mentheti fájlként.

7. A use case véget ér, mikor a levelező user kérést indít a bejövő üzenetkezelőből.

30. ábra

5.7.4. Logikai rendszerterv

A logikai rendszerterv a következő főbb részekből áll:

1. üzleti folyamatok modellje 2. követelmények

3. feldolgozási folyamatok 4. funkcionális felépítés 5. felhasználói felületek, menük 6. adatszótár, logikai adatmodell 7. adatfolyam diagramok

5.7.5. Fizikai rendszerterv

A fizikai rendszerterv a következő főbb részekből áll:

1. osztály tervek 2. adatbázis terv 3. teszt tervek 4. telepítési terv

5. rendszerspecifikációk (fejlesztési, futtatási környezet) 6. szoftver architektúra

7. az alkalmazás rétegei

8. adatspecifikációk/objektumspecifikációk (környezetfüggő adattervek) 9. programspecifikációk (modulvázak)