Esettanulmány: Hallgatói adminisztráció A feladat megismerése

1. Esettanulmány: Hallgatói adminisztrációA feladat megismerése • Rendszer fejlesztése, mely segít egy egyetem számítástechnika tanszékének az utolsó évestantárgyak adminisztrálásában. • Minden akadémiai év végén meghatározzák, hogy melyik modulok elérhetőek a CS4 diákoknak a következő évben. (CS4 azok a diákok, melyek bármilyen 4. éves modult felvettek a számítástechnika tanszéken, függetlenül attól, hogy a szakra járnak vagy sem) • A vezetőség minden lekötött modulhoz tanárt rendel. • Az oktató frissíti a modul tantárgy naplóját. CS4 koordinátor frissíti a napló egyéb részeit és ellenőrzi az oktató által bevitt adatokat. A naplóba LATEX nyelven írnak. • Az (ATI) Alulképzett Tanárok Irodája kap egy kivonatot papíron, melyet latex2html-el generálnak.

2. I. Feladat megismerése 2 • A CS3 koordinátor ad egy listát a CS4-be lépő diákokról a CS4 koordinátornak és az ATI-nak. A CS4 koordinátor továbbítja az ATI-nak minden nem CS3-ból érkező CS4 diák listáját (pl a nem képzés alatt álló diákokat) • Az ATI megtartja a CS4 hallgatók listáját és frissíti a levelezési címeket. • Minden diákot a Tanulmányi Vezetők (TV) egy tagja segíti. (első évtől amíg nem távozik az iskolából) • A hallgatók ideiglenesen regisztrálnak egy modulba, kitöltött formanyomtatvánnyal, és beadják az ATI-nak. Az ATI ellenőrzi a listát és a a CS4-eket beregisztrálja a modulokba. A hallgató TV-vel konzultálhat.

3. I. Feladat megismerése 3 • Az ATI ad egy listát a hallgatónak a modulok oktatóinak listáját. Ez a lista nem garantálja, hogy eléri az oktatókat kevesebb, mint 3 héten belül. • Ezen túl sajnos késő, mert az oktató nem tudja hány másolatot készítsen.

4. Fogalomszótár • Tanszék, (végzős)tantárgy, modul, hallgató(=diák?), évfolyam, vezetőség, tanár(=oktató), tanulmányi vezető, koordinátor, tantárgynapló, (Alulképzett) TanárokIrodája,

5. II Kérdések • Melyik hallgatókkal foglalkozunk és ez mindig azonos halmaz? A szöveg néha CS4 hallgatóként, néha hallgatóként említi. • Mi a CS4 levelező lista és hogyan frissítik? • Milyen más információt kell folyamatosan frissíteni? Például: Web oldalak? • Mi a tantárgy napló és mennyi van belőle?

6. II Kérdések - Válaszok • Minden végzős tantárgynak van tantárgy naplója. A végzős tantárgy és a végzettsége szinonimák ebben a környezetben. A végzős tantárgyak a rendszerhez tartoznak, melyek lehetnek: Számítástechnika, Számítástechnika és Mesterséges Intelligencia, Számítástechnikai Villamosmérnök, stb. A modulok kombinációs lehetősége más és más ezeken a szakokon, ezért eltérő naplójuk van. • Ugyanakkor sok modul elfogadható számos végzős szakon, és ebben az esetben a modul leírása minden naplóban azonos. Minden hallgató egy végzős szakra van regisztrálva és megkapja a megfelelő tantárgy naplót. A CS4 Koordinátor felelős az összes tantárgy napló vezetéséért.

7. III Vizsgálat A vezetőség megkért, hogy vizsgáld meg a rendszer fejlesztésének lehetőségét és az egyes részek automatizálásának lehetőségeit, szerintük lehetséges: • Rutin munkákat csökkenteni minden személyzetnél, főleg a CS4 Koordinátornál • Hallgatók on-line regisztráljanak a modulokba • ATI-tól naprakész információk könnyen megkaphatóak legyenek • Információk nyomon követésének (áttekintés) javítása • Információk, mint pl. a Tanfolyami leírás és a hallgatók listája modulonként automatikus készítése és elérhetővé tétele.

8. III Vizsgálat Use-Case Modell • Ebben a részben egyelőre nem foglalkozunk a lekérdezésekkel, ezért az ezekhez tartozó use-case-eket kivettük.

9. III VizsgálatUse-Case Modell 2

10. III VizsgálatUse-Case Modell 3 Tantárgy napló vezetése: • Ez a use-case csak akkor használható, ha a tanfelügyelet megállapította az elérhető modulok csoportját és a tanszékvezető meghatározta a felelős oktatókat. • A CS4 tantárgyvezető frissíti az alapinformációkat (modulfüggéseket) minden tantárgy naplóban. (kiveszi az információt a rendszerből, módosítja, és módosított verzióval visszateszi) • Minden tantárgy oktató minden modul leírását frissíti. (kiveszi az információt a rendszerből, módosítja, és módosított verzióval visszateszi) • A frissítés bármilyen sorrendben történhet. A rendszer nyomon követi, melyik frissítés készült el. Ha mindegyik frissítés elkészült, akkor a rendszer elküldi a tantárgy napló szövegét e-mail-en az Alulképzett Tanárok Irodájában, akik kinyomtatják és frissítik a Web oldalakat.

11. III VizsgálatUse-Case Modell 4 A többi use-case-hez kell leírás? Ezt a projekt folyamán kell megbeszélni a felhasználóval. Mi most kihagyjuk.

12. III Vizsgálat(Szakterületi) Osztály Modell

13. III VizsgálatDinamika

14. III Vizsgálat Dinamika

15. III VizsgálatÁllapot Nincs érdekes állapot a rendszerben.

16. III VizsgálatAktivitások

17. III VizsgálatFelhasználói felület Nem készítünk felhasználói felületet, arról, hogy a szereplők hogyan érik el ezeket a szolgáltatásokat. A megfontolás az, hogy egyszerű felhasználói felületek vannak, melyeken minden szereplő csak a rendszer egy-egy részét látja.

18. Tartalom • I. Feladat megismerése • Amőba • Sakk • II. Keretrendszer • III. Vizsgálat • Use-Case modell • Osztály modell • Dinamika • IV Amőba • Keretrendszerbe illesztés • Dinamika • Együttműködés • Osztály modell • Állapot

19. I. Feladat megismerése • Egy új cég be akar törni az internetes táblajátékok piacára. Több jól ismert két-személyes játék képernyős változatát tervezik elkészíteni. Kezdetnek az Amőbát és a Sakk-ott. • Minden játéknál két felhasználó osztozik a képernyőn és körönként lépnek. A program biztosítja, hogy csak engedélyezett lépések történjenek és megállapítja a nyertest. • Hogy az új játékokat egyszerű legyen megvalósítani, a vállalat keretrendszer készítését tervezi.

20. I. Feladat megismerése • A fejlesztés meghatározó pontja a grafikus felület és mivel a felületet több platform-on is meg kell valósítani, ezért a java applet a legjobb megoldás. • Milyen legyen a keretrendszer? • Tartalmazza az ilyen játékokra jellemző általános műveleteket. • A valós életben egy keretrendszerhez sok példát kell készíteni, amitől most eltekintünk.

21. I Feladat megismerése Amőba Amőba • A játékot egy 3x3 négyzetes asztalon két játékos játssza. A kezdő játékos X-et rak a másik O-t a táblára. • Csak az üres helyekre lehet tenni. • A nyertes, aki először kitesz egy vonalat (függőlegesen, vertikálisan vagy átlósa). 3 jeléből. • Ha a tábla megtelik, anélkül, hogy valakinek meglenne a sora, a játék döntetlen.

22. I Feladat megismerése Sakk Sakk • A Sakk sokkal komplikáltabb • Rövid leírása: • A játék 8*8-a négyzetrácsos táblán játszódik különféle figurákkal: gyalog, bástya, lovag, futó, királynő, király. • Mindegyik bábu két színben létezik, fekete és fehér. • Két játékos van, a fehér játékos a fehér, a fekete játékos a fekete bábukat uralja. • A kezdő felállást lásd a képen.

23. I Feladat megismerése Sakk

24. I Feladat megismerése Sakk • Egy figurával megtehető lépések függenek a figura fajtájától és a játék történetétől. • Bizonyos helyzetben, a király sakkban van. Ilyenkor a játékosnak a királlyal kell lépni, hogy ne legyen sakkban (ha lehetséges). Ha ez nem lehetséges, akkor sakk-matt és a másik játékos nyert. • Ha a játék 3x visszaáll azonos elrendezéshez, akkor döntetlen.

25. II Keretrendszer Keretrendszer készítéséhez meg kell határozni a játékok közös tulajdonságait, melyek az eddigi ismereteink szerint: • 3 játékos játssza • négyzet alakú négyzethálós asztalon játsszák • a játékosok különféle módon léphetnek. • Lépésnek számít, a bábu felvitele, eltávolítása és/vagy mozgatása • Minden bábu egy játékos tulajdonában van • Minden információ elérhető mindkét játékos számára • A lehetséges lépések függenek a tábla állapotától, vagy akár a játék eddigi történetétől • A nyertes kiléte azonos feltételektől függ

26. III Vizsgálat • Tegyük fel, hogy a felhasználóval történő egyeztetés után az 1, 4, 6, 7, 8 funkciókat megtartjuk, de a 2, 3, 5 funkciókat elvetetjük • Tehát az asztal bármilyen formájú lehet. Az állapot a bábuk pozíciójától függ. A bábuk játékosok tulajdonában vannak • A mozgás lehetséges egy vagy mindkét játékosnak: lehet olyan bábu, amivel mindkét játékos léphet. • A játékos nem mindig egymás után lépnek, ez függ a játék eddigi történetétől és a tábla állásától.

27. III Vizsgálat Use-Case Modell • Ebben e feladatban a use-case diagram nem sokat segít.

28. III Vizsgálat Osztályok Nézzük milyen osztályok vannak: • Jatekos • AktualisPozicio • Babu • Mozgas • Jatek A nevek nem mindig határozzák meg pontosan, hogy mire való az osztály.

29. III VizsgálatDinamika

30. III Vizsgálat Dinamika

32. III VizsgálatDinamika

33. IV AmőbaKeretrendszerbe illesztés • Nézzük meg, hogy ebbe a keretbe hogyan illeszthető az amőba játék. Meg kell valósítani az osztályokat a megállapított felelősségekkel. • Az összes vagy néhány osztálynak specializációját kell elkészíteni, a vizsgált játék (amőba) megvalósításához. • Ezt nevezzük architektúra vezérelt fejlesztésnek. • Használjunk egyszerű névkonvenciót és a Babu osztály specializációja legyen OXOBabu… stb. • Az AktualisPozicio osztály jó példája annak, hogy néha szükséges a megvalósításban több osztály objektumait használ a keretrendszer egy osztályának megvalósítására. A Tabla és a Negyzet osztályok együtt felelősek a pozíció karbantartásáért.

34. IV AmőbaDinamika

35. IV AmőbaEgyüttműködés • A játékos interakcióját az amőba esetén a Tabla vezérli. • A játékos kattint valahol a táblán, ami egy üzenetet generál a Tabla-nak, arról hogy mi történt. • A Tabla a Negyzet segítségével kitalálja, melyik Negyzet-be klikkelt. • A Tabla tudja, melyik játékos klikkelt, így a megfelelő jelet teszi be. • Létrehoz új OXOMozgást , mely tudja melyik négyzet és melyik játékos érdekelt, és átadja az OXOMozgas-t a OXOJatek-nak hitelesítésre. • OXOJatek ellenőrzi, hogy nincs-e más OXOBabu a Negyzet-en. Ha nincs, akkor érvényes a mozgás. • Ezután OXOJatek ellenőrzi, hogy vége-e a játéknak. Ha nincs, akkor hitelesíti a mozgást. • A Tabla megkéri OXOMozgast, hogy frissítse a képernyőt a helyét, amire OXOMozgas rajzol egy jelet (OXOBabu) a Negyzet-en. • Törli OXOMozgas-t, mert már nincs rá szükség, és várja a következő lépést.

36. IV AmőbaOsztály modell • Egy lehetséges osztály diagram, melyen az egyszerűség kedvéért nem jelenítjük meg az alaposztályokat és a Jatekos osztályt. A Jatekos osztályt azért hagytuk ki, mert egyrészt nem kell specializálni, másrészt mivel sok kapcsolata van, ezért összezavarná a diagramot. • Az egyszerűség kedvéért kihagytuk a rejtett metódusokat is.

37. IV AmőbaOsztály modell

38. IV AmőbaKeretrendszerOsztály Modell Keretrendszer általános kapcsolatokkal

39. IV AmőbaÁllapot AktualisPozicio osztály érdekes, mivel sok feladata van és még a nyertest is ő állapítja meg. Nézzük 3 állapotát • A lép • B lép • Vége a játéknak

40. IV AmőbaÁllapot – AktualisPozicio

41. Referenciák • Irodalom • Perdita Stevens:Using UML • Booch, Rumbaugh, Jacobson:The Unified Modeling User Guide • Scott W. Ambler: Building Object Applications That Work • Hivatkozások • www.omg.org • www.modelingstyle.com • Kapcsolódó tanfolyamok • Üzleti modellezés UML-el • Adatbázis modellezés UML-el • Web alkalmazások modellezése UML-el • Vállalati J2EE alkalmazások modellezés UML-el • Szoftverfejlesztés a Rational Unified Process alkalmazásával • eXtrém programozás • Iteratív szoftver projektek vezetése O K T A T Ó K Ö Z P O N T K F T.