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ó éves tantá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.

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.

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.

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,

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?

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.

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.

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.

III Vizsgálat Use-Case Modell 2

III Vizsgálat Use-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.

III Vizsgálat Use-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.

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

III Vizsgálat Dinamika Osztály neve: Tanulmányi Vezető Felelősségei Együttműködés Emberi TV interfész szolgáltatása a rendszernek Osztály neve: Végzős Tantárgy Felelősségei Együttműködés Modulok csoportjának tárolása Modul Szöveges Tantárgynapló készítése

III Vizsgálat Dinamika Osztály neve: Modul Felelősségei Együttműködés Tantárgy leírásának tárolása Tantárgy oktatójának tárolása

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

III Vizsgálat Aktivitások

III Vizsgálat Felhaszná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.

Tartalom I. Feladat megismerése II. Keretrendszer III. Vizsgálat Amőba Sakk II. Keretrendszer III. Vizsgálat Use-Case modell Osztály modell Dinamika IV Amőba Keretrendszerbe illesztés Együttműködés Állapot A bevezetés arra ad választ, hogy miért szükséges a webes alkalmazások modellezésével foglalkozni. Milyen problémát vetnek fel a webes alkalmazások és ezeket a problémákat milyen elvek alapján akarjuk feloldani. Fontos hangsúlyozni, hogy a webes alkalmazások bizonyos részei „hagyományosan” modellezhetők (pl. üzleti logika, adatbázis), illetve az UML széles körben elterjed modellező nyelv ezért célszerű ennek keretein belül maradni.

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.

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.

I Feladat megismerése 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.

I Feladat megismerése 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.

I Feladat megismerése Sakk

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.

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

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.

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

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.

III Vizsgálat Dinamika Osztály neve: Jatekos Felelősségei Együttműködés Felhasználó adatainak karbantartása Játékos azonosítása a játékban Vizuális jelkép biztosítása a játékosnak

III Vizsgálat Dinamika Osztály neve: AktualisPozicio Felelősségei Együttműködés Felhasználó által látható adatok karbantartása: pozíció, ki lépett; ki a nyertes. Elfogadja a játékos lépését és csomagolja engedélyeztetésre.

Osztály neve: Babu Felelősségei Együttműködés A bábut valósítja meg a játékban A bábu pozíciójának karbantartása? [Vagy ez a AktualisPozicio feladata?]

III Vizsgálat Dinamika Osztály neve: Mozgas Felelősségei Együttműködés Összegzi, hogy milyen változások voltak egy játékos lépésénél. Tudja hogy igazolja magát? Osztály neve: Jatek Felelősségei Együttműködés Játék szabályait megérti: Lehetséges mozgások Nyertes megállapítása. Minden szükséges információ megőrzése az előző lépésekről

IV Amőba Keretrendszerbe 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.

IV Amőba Dinamika Osztály neve: Negyzet Felelősségei Együttműködés A tábla egy négyzetéhez tartozó adatok karbantartása: hol van, tartalmaz-e bábut, ha igen, milyet. Babu Megmondja, hogy egy pont a négyzeten belülre esik-e. Osztály neve: Tabla Felelősségei Együttműködés Felhasználó által látható adatok karbantartása: pozíció, ki lépett; ki a nyertes. Negyzet Elfogadja a játékos lépését és csomagolja engedélyeztetésre.

IV Amőba Együ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.

IV Amőba Osztá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.

IV Amőba Osztály modell

IV Amőba Keretrendszer Osztály Modell Keretrendszer általános kapcsolatokkal

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

IV Amőba Állapot – AktualisPozicio

Referenciák Irodalom Hivatkozások Kapcsolódó tanfolyamok 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.