SSADM Structured Systems Analysis and Design Method Strukturlt

SSADM Structured Systems Analysis and Design Method Strukturált rendszerelemzési és -tervezési módszer

Rendszerfejlesztési projektek problémái Hosszú, a tervezettet meghaladó fejlesztési idő 1. • • Nem normázható tevékenységek A projekt megkezdése előtt nem világos az elérendő cél Magas fejlesztési költségek, ezzel szemben kevés kimutatható eredmény 2. • • Elhúzódó fejlesztés A várható eredmények számszerűsítése nehéz Az elkészült rendszerek nehezen módosíthatók, rugalmatlanok 3. • • • Hiányos dokumentáció Rendszer funkcióinak helytelen megválasztása Rossz programtervezés

Rendszerfejlesztési projektek problémái 4. Kielégítetlen felhasználói követelmények • Követelmények nem megfelelő leírása a felhasználói oldalon 5. Gyakori a redundáns adattárolás • Azt jelzi, hogy baj van a rendszer integráltságával 6. Új eszközökön régi rendszer valósul meg • A régi rendszer megoldásait automatikusan átviszik az újra, az új eszközök sajátosságait figyelmen kívül hagyják

A megoldás 1980 -as évek: Rendszervezési módszertanok. Cél: nagy rendszerek, projektek kézben tartása. Alapjai: strukturált programozás (modulokból építkezés), projektvezetési módszertanok, dokumentálási rendszerek. Strukturált módszertanok: SSADM = Structured Systems Analysis and Design Method (Strukturált rendszerelemzési és tervezési módszertan) Technikák (módszerek) gyűjteménye: részben már korábban léteztek, pl. E-K modell. Lehetnek diagrammra épülők és nem diagrammra épülők.

Strukturált módszertanok alapelvei Elemzés felülről lefelé: alrendszerekre, funkciókra, folyamatokra bontás Tervezés alulról felfelé: hierarchikus építkezés alapelemekből, pontos, részletes terv. Logikai (mi történik) és fizikai (hogyan történik) vizsgálatok szétválasztása. Logikai: a rendszer működésének belső logikája, viszonylag állandó. Fizikai: a tényleges megvalósítás adott eszközökön. Fokozatosság: pl. egy új egyednél először csak a nevét és kapcsolatait határozzuk meg, az attribútumai csak később adjuk meg. Iterativitás: amit egyszer már megterveztünk, az – akár többször is – módosításra szorulhat.

SSADM dokumentáció részei 1. Áttekintés 2. A strukturális modell 3. Az SSADM technikái 4. Az SSADM termékei

Nyolc ok az SSADM használatára 1. A rendszer elkészítése időre 2. A felhasználók igényeit kielégítő rendszer készítése 3. Olyan rendszer készítése, amely követni tudja a működési környezet változásait 4. A meglévő szakértelem hatékony és gazdaságos kihasználása.

Nyolc ok az SSADM használatára 5. A minőség növelése a hibák csökkentése révén 6. A hajlékonyság növelése 7. A termelékenység növelése 8. Az egy szállítótól való függés csökkentése

A módszer környezete és felépítése

SSADM-projektindítás alapfeltételei Információ Eljárások Terjedelem

A módszer felépítése: A három nézet modellje

SSADM törzsrésze Megvalósíthatóság Követelmény-elemzés Követelmény-specifikáció Logikai rendszerspecifikáció Fizikai rendszertervezés

A strukturális modell Megvalósíthatóság-elemzési modul (FS) 0. szakasz: Megvalósíthatóság Követelményelemzési modul (RA) 1. szakasz: Jelenlegi helyzet vizsgálata 2. szakasz: Rendszervezési alternatívák RS: Követelmény specifikációs modul 3. szakasz: Követelmények meghatározása Logikai rendszerspecifikációs modul (LS) 4. szakasz: Rendszertechnikai alternatívák 5. szakasz: Logikai rendszertervezés

Megvalósíthatóság-elemzési modul (FS) Kérdés: érdemes-e egyáltalán megvalósítani a projektet? Elhagyható, ekkor szerepét a következő szakasz veszi át.

Követelményelemzési modul (RA) 1. Jelenlegi helyzet vizsgálata A felmérés fő irányai: Adatok feltárása Folyamatok feltárása Követelmények meghatározása Követelmény katalógus: készítése a projekt kezdetén indul el, és folyamatosan bővül, a megvalósítandó követelmények informális leírását tartalmazza

Követelményelemzési modul (RA) 2. Rendszervezési változat kiválasztása 1. Az eleve alkalmatlan változatok kiszűrése. Változatok javasolt száma: 3 -6. Költségek és várható hatások alapján lehet jellemezni őket: a rendszer határai, inputjai, outputjai. 2. A megmaradt változatok javasolt száma: 2 -3. Ezekről részletesebb (logikai szintű) leírás: költségek, előnyök, megtakarítások, szervezeti kihatások. A felhasználó választ az általunk kidolgozott alternatívák közül.

RS: Követelmény specifikációs modul 3. Követelmények meghatározása Adatbázis interfész Feldolgozás interfész Felhasználó A tervezett rendszert logikai szinten vizsgáljuk. Adatgyűjtés: Interjúk Dokumentumok Fő szempontok: Adatok Funkciók Felhasználói interfész

3. Követelmények meghatározása: adatok A meglévő rendszer logikai adatmodellje (az 1. szakaszban már elkészült) A tervezett rendszer logikai adatmodellje. Lényegében egyed-kapcsolat modell, amely felülről lefelé (top-down) elemzéssel készül, és csak a legfontosabb tulajdonságokat tartalmazza (kulcsok, stb. ). Követelmény katalógus alapján: a meglévő rendszert mivel kell bővíteni (új egyedek, tulajdonságok, kapcsolatok), esetleg mit lehet elhagyni. A tervezett rendszer normalizált logikai adatmodellje. A normalizált modell a tulajdonságokból kiindulva, alulról felfelé (bottom-up) módszerrel készül, és független az előző egyedmodelltől. A kétféle eredmény össze-hasonlításával kapjuk a végleges modellt.

3. Követelmények meghatározása: Funkciók Meglévő rendszer fizikai folyamatai (az 1. szakaszban már elkészült) Meglévő rendszer logikai folyamatai (az 1. szakaszban már elkészült) Tervezett rendszer logikai folyamatai Tervezett rendszer funkciói Eszköz: adatfolyam-diagramm Felhasználói interfész: prototipizálási technikával, a felhasználóval egyeztetve. Eredményeként jönnek létre a képernyőtervek, dialógusok és menük. Dokumentálás: fogalom-meghatározások, diagramok, kísérő szöveg.

Logikai rendszerspecifikációs modul (LS) Célja: lehetőséget biztosítani a vezetésnek arra, hogy kiválaszthassa azt a technikai környezetet, amely a követelményeknek megfelel és a legtöbbet nyújtja a kiadásokhoz képest.

4. Rendszertechnikai változat kiválasztása Rendszertechnikai változatok kidolgozása. Többféle műszaki- technikai színvonal és környezet lehetséges. Figyelembe veendő: meglévő eszközök, hosszabb távú fejlesztési stratégia, kapacitás, költség, várható hatások. 3 -6 változat kidolgozása javasolt, amely később 2 -3 változatra szűkíthető. Rendszertechnikai megoldás kiválasztása. A döntés a felhasználóval közösen történik.

5. Logikai rendszertervezés részletesen meghatározni a követelményspecifikációban megfogalmazott feldolgozási szerkezeteket meghatározni a feldolgozás felületét dialógusok formájában részletes specifikációt készíteni, amely: nem-procedurális megvalósítható egy sor technikai környezetben maximális lehetőségeket teremt az újrafelhasználásra

5. Logikai rendszertervezés Logikai adatmodell: a korábbi szakaszokból örököljük. Feldolgozások: karbantartó eljárások tervezése (lekérdezést is tartalmazhat) Lekérdező eljárások tervezése Dialógusok tervezése: dialógusszerkezet menüszerkezet

6. Fizikai rendszertervezés Adatbázis interfész Létrehozandó: Adattervek Feldolgozástervek Interfész-tervek Feldolgozás interfész Felhasználó

Adattervek: logikai adatmodell átalakítása fizikai adattervvé. Első közelítésű terv: egyedtípusokból relációsémák. Finomított terv: idő-követelmények figyelembe vétele. Feldolgozástervek: funkciók áttekintése, majd részletes specifikációk elkészítése. Adattervezéstől független elemek Fizikai adattervre épülő elemek Interfész-tervek: Adat-funkció interfészek Felhasználói interfészek (képernyőtervek, nyomtatványok, listaformátumok) fizikai megtervezésével nem foglalkozunk.

Az SSADM technikái Megvalósíthatósági elemzés Követelmény-meghatározás Adatfolyam-modellezés Logikai adatmodellezés Rendszervezési alternatívák Funkció-meghatározás Relációs adatelemzés Specifikációs prototípus készítése Egyed-esemény modellezés Rendszertechnikai alternatívák kialakítása

Az SSADM technikái 1. Diagramra épülő technikák Dokumentumáramlási diagram Folyamatmodellezés (DFD) Logikai adatmodellezés (Egyedmodell) Egyed-esemény modellezés Elérési út modellezése I/O szerkezet meghatározása (Funkció meghat. része) Dialógus tervezés Logikai feldolgozástervezés (lekérdezések és karbantartások tervezése)

Az SSADM technikái 2. Nem diagramra épülő technikák Követelménykatalógus Rendszervezési változatok kidolgozási módszere (rendszer határai, költség/haszon elemzés, hatások elemzése) Rendszertechnikai változatok kidolgozási módszere (hardver-szoftver környezet, szervezetbeli és munkamódszerbeli változások, stb. ) Funkció meghatározás Relációs adatelemzés (normalizálás) Specifikáció prototipizálás (pl. gépen futó demó változat)

Követelmény katalógus Készítése a projekt kezdetén indul el, és folyamatosan bővül. Funkcionális követelmények: mit kell a rendszernek tudnia (nyilvántartandó adatok, lekérdezési igények, más rendszerekkel való kapcsolatok, stb. ) Nem funkcionális követelmények: hogyan, milyen minőségben kell tudnia a rendszernek (naprakészség, válaszidők, tranzakciók száma, adatvédelem, stb. )

3. Adatfolyam-modellezés Az adatfolyam-ábra: DFD(Data Flow Diagram) Az adatfolyam-modell: DFM (Data Flow Model) Az adatfolyam-modellezés célja az, hogy egy adott információs rendszerről átfogó képet nyújtson, együtt ábrázolva a rendszer folyamatait és adatait.

Az adatfolyam-modellezés konkrét céljai az elemzés különböző fázisaiban Jelenlegi fizikai a követelmények azonosítása (hiányosságok, új funkciók) Jelenlegi logikai Továbbvihető logikai folyamatok azonosítása, a rendszervezési alternatívák kiindulópontja Rendszervezési alternatíva A felhasználói döntés előkészítése, átfogó kép kialakítása a lehetőségekről. Igényelt rendszer Funkciók, események meghatározásának kiindulópontja.

Jelölésmód és fogalmak Az adatfolyam-modell objektumtípusai Külső egyedek A rendszeren kívüli objektumok Folyamatok Az információkat átalakító feldolgozási folyamatok Adattárak Az információk tárolási helyei Adatfolyamok Az információk áramlásának útvonalai

Külső egyedek (környezeti elemek) Tartalma: Megnevezés, Azonosító (szükség esetén). Áttekinthetőség érdekében több példányban is szerepelhet, ezt ferde vonal jelzi.

Folyamatok

Adattárak

Adatfolyamok A rendszerben mozgó információt az adatfolyamok fejezik ki, amiket nyilak jelölnek. Kétirányú nyíl: alsóbb szinten bemenõ és kimenõ adafolyamok is léteznek. A rendszerhatárt át nem lépõ, ún. információ áramlás is jelölhetõ az ábrákon, szaggatott nyíllal.

Anyagáramlások

Hierarchikus szerkezet Magasabb szintű áttekintő diagram (a folyamatok alrendszereket is jelölhetnek), Több részletes diagram. Általában 2 -3 szintet alkalmaznak. Egy diagram mérete általában max. A 4, max. 7 -10 folyamat.

Banki dokumentum áramlási ábra rendszerhatárral

Banki rendszer, felsõ szintû DFD

Hierarchiaszintek szabályai Nulladik szint: kapcsolat diagram, ahol a teljes rendszer egyetlen folyamat. Elkészítése nem kötelező. Ha egy adattárat a magasabb szinten csak egy főfolyamat használ, akkor csak az alacsonyabb szintű diagramon tüntessük fel. Sorszámozás alszámokkal (pl. 2 folyamat alfolyamata 2. 1, adattárnál D 2/1, környezeti elemnél c 1) Egyensúly szabály: a részletező diagram külső kapcsolatai egyezzenek meg a megfelelő főfolyamat külső kapcsolataival. Elemi folyamat: (jele *) amely már tovább nem bontható. Szöveges leírása max. fél A 4 -es oldal legyen.

Példa Horgászegyesületi nyilvántartó rendszer (Simon Nikoletta, 2004)

0. szint: Kapcsolat diagram

1. szint

2. szint: 1. folyamat kifejtése

2. szint: 1. folyamat kifejtése

2. szint: 3. folyamat kifejtése

2. szint: 6. folyamat kifejtése

DFD-k alkalmazása Fizikai és logikai szintű leírásra egyaránt alkalmas: Felméréskor (1. szakasz): először fizikai DFD, azután logikai DFD Különböző lehetséges megoldások közül való választáskor (2. szakasz): logikai DFD-k Új rendszer tervezésekor (3. szakasz): a tervezett rendszer logikai DFD-je Új rendszer fizikai tervezésekor (6. szakasz): a tervezett rendszer fizikai DFD-je Megjegyzés: Szükség esetén a DFD egyes elemeinek szöveges leírása és mellékelendő.

A folyamatmodellezés gyakorlati lépései 1. A meglévő rendszer első szintű fizikai AFD-je. A következőkre koncentráljunk: a rendszer határai, környezeti elemek és be-kimenő adatfolyamok, a rendszer fő funkciói (alrendszerei). A rendszerben használt dokumentumok, nyomtatványok összegyűjtése a kitöltésért felelős egységek megnevezésével. Dokumentumáramlási diagram készítése: csomópontok a szervezeti egységek, nyilak az áramlást jelzik. 2. Részletesebb fizikai AFD-k elkészítése. 3. Logikai AFD-k elkészítése. Folyamatos ellenőrzés a felhasználókkal együttműködve.

4. Logikai adatmodellezés A logikai adatmodellezés a logikai adatszerkezet és kapcsolódó dokumentumainak elkészítésére irányul. Logikai adatszerkezet: LDS (Logical Data Structure) Logikai adatmodell: LDM (Logical Data Modell)

Jelölésmód és fogalmak Egyedek, kapcsolatok Egyed: Könyv 1: 1 kapcsolat: N: M kapcsolat: Könyv Olvasó Nincs sokágú kapcsolat!

Rekurzív kapcsolatok

Rekurzív kapcsolatok 2.

A kapcsolat jellege Egy egyed kötelezően (teljesen) vesz részt a kapcsolatban, ha minden egyedpéldány részt vesz legalább egy kapcsolatban folytonos vonal. Ellenkező esetben az egyed esetlegesen (részlegesen) vesz részt a kapcsolatban szaggatott vonal. Könyv Olvasó Ha a jelleggel nem akarunk foglalkozni, mindenütt folytonos vonal alkalmazható.

Kizáró alárendelt kapcsolatok Kurzus Nappali időpont Levelező időpont Nappali időpont: pl. kedd 8 -10 Levelező időpont: pl. 2006. okt. 13, 14 -16

A logikai adatmodellezés gyakorlata Általában minden kapcsolatot 1: N-re hozunk: • N: M-nél új egyedet veszünk fel, • 1: 1 -nél a két egyedet összeolvasztjuk (ha az célszerű) Elnevezések: • Minden egyed különböző névvel szerepeljen. • Kapcsolat neve képezhető az egyedek neveiből, pl. Könyv-Olvasó kapcsolatnál KÖ-OL.

Funkció-meghatározás A funkciómeghatározási technika a funkciók leírásának és a kapcsolódó bemenet/kimeneti adatszerkezeteknek a létrehozására irányul. A bemenet/ kimeneti adatszerkezet angol rövidítésse IOS (Input/Output Structure).

Funkciók típusai Feldolgozás típusa szerint: lekérdezés, karbantartás Megvalósítás módja szerint: on-line, off-line mindkettő A kezdeményező szerint: Felhasználói (környezeti elemből kiinduló esemény indítja el), Rendszerfunkció (a funkció végrehajtása „belülről” indul, pl. meghatározott időnként ellenőrizni kell a kölcsönzési idők lejártát).

Példaűrlap funkcióhoz

Relációs adatelemzés A relációs adatelemzés az a technika, amellyel az adatoknak egy olyan szerkezetét lehet elõállítani, amely a lehetõ legkevesebb ismétlõdést és a lehetõ legnagyobb rugalmasságot biztosítja. Normalizálás nélkül: felviteli, módosítási és törlési anomáliák, karbantartási nehézségek

A relációs adatelemzés lépései Tulajdonságtípusok összegyűjtése. Relációsémák felírása a tulajdonságtípusokból (esetleg I/O szerkezetek alapján). Normalizálatlanok lehetnek, még 1 NF sem kötelező. Normalizálás 3 NF-ig (tovább menni csak ritkán kell). Konszolidálás: azonos kulcsú sémák összevonása. Eredmény: relációs adatbázis séma.

Relációsémák írásmódja Relációséma neve: Példa: Attribútumok (tulajdonságok): Dolgozó adószám név lakcím munkahely beosztás vastag betű. egymás alá. Kulcs: aláhúzva. Külső kulcs: csillaggal. Halmaz attribútum, ismétlődő csoport (beágyazott tábla): behúzással.

1. példa Normalizálatlan Dolgozó adószám név lakcím munkahelynév munkahelycím beosztás 2 NF 1 NF Dolgozó adószám név lakcím Dolgozik *adószám munkahelynév munkahelycím beosztás Dolgozó adószám név lakcím Dolgozik *adószám *munkahelynév beosztás Munkahely munkahelynév munkahelycím

2. példa Normalizá -latlan Könyv könyvszám szerző cím olvasószám olvasónév lakcím kivétel 1 NF (2 NF) Könyv könyvszám cím olvasószám olvasónév lakcím kivétel Szerző *könyvszám szerző 3 NF Könyv könyvszám cím *olvasószám kivétel Olvasó olvasószám olvasónév lakcím Szerző könyvszám szerző

Összehasonlítás a logikai adatmodellel 1. módszer: A relációs adatelemzés eredményéből írunk fel egyedmodellt: • Relációnév egyed, külső kulcs kapcsolat. • A kapott egyedmodell összehasonlítása a logikai adatmodellezésnél kapott egyedmodellel. 2. módszer: A logikai adatmodellezés eredményéből írunk fel relációs modellt: • EK modell relációs adatbázis séma • A kapott adatbázis séma összehasonlítása a relációs adatelemzés eredményével.

Fizikai adatbázis specifikáció Cél: a relációsémák megadása kulcsokkal és magyarázatokkal Tábla neve attribútum típus, hossz leírás . . . . attribútum típus, hossz leírás

Példa Megrendelés megr. Kod Decimal(10) A megrendelés nyilvántartási kódja *term. Kod Decimal(10) szerz. Szam Varchar(20) A megrendelő által rendelt termék kódja A szerződés száma, amin a megrendelés szerepel menny Decimal(10) hatarido Date teljesites Date A rendelt termék mennyisége A megrendelés határideje A megrendelés elkészülésének dátuma

Egyed-esemény modellezés Az egyed-esemény modellezés két technikát jelent, az egyedtörténeti elemzést és az eseményhatás-elemzést. Egyed-esemény mátrix: • Függőlegesen az egyedek felsorolása. • Vízszintesen az események felsorolása. A mátrix bejegyzései: • L = létrehozás • O = olvasás • M = módosítás • T = törlés • (Más megközelítés: R=read, W=write, M=modify)

Példa egyed-esemény mátrixra (fogászai rendelő nyilvántartása)

Összefoglalás A feladat megfogalmazása [0. Megvalósíthatóság eldöntése] 1. Jelenlegi helyzet vizsgálata • [Dokumentumáramlási diagram] • Jelenlegi fizikai DFD • Jelenlegi egyedmodell • Jelenlegi logikai DFD • Követelmény katalógus

Gyakorlati alkalmazás - 1 [2. Rendszervezési változat kiválasztása] • Különböző lehetséges megoldások közül való választáshoz logikai AFD-k 3. Követelmények meghatározása • Tervezett logikai AFD • Tervezett egyedmodell • Funkció meghatározás • Egyed-esemény mátrix 4. Rendszertechnikai változat kiválasztása

Gyakorlati alkalmazás - 2 5. Logikai rendszertervezés • • Relációs adatelemzés (normalizálás) Relációsból egyedmodell [Egyedmodellek összehasonlítása] [Dialógusok tervezése] 6. Fizikai rendszertervezés • Tervezett fizikai AFD • Fizikai adatbázis specifikáció Felhasználói kézikönyv Működési kézikönyv