Programming | UML » Molnár Ágnes - UML

NetAcademia-tudástár Az UML – 1. rész A modellezés témát folytatva, pontosabban részletezve UML sorozatom első részében a módszer kialakulásának körülményeit szeretném bemutatni, illetve néhány olyan alapfogalmat, amelyek megértése elengedhetetlen a későbbiek megértéséhez. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Az igények Az előző számban már írtam arról, hogy csekélyértelmű medvebocs korom óta mennyit fejlődtem, legalábbis a programozási szokások terén. Eleinte minden előzetes tervezés nélkül vágtam bele a dolgokba, majd az első hibák, memóriatúlcsordulások és reménytelennek tűnő debuggolások után gondolkodni is elkezdtem (mekkora előrelépés volt ez!) Egy idő után megtanultam, hogy ha előre gondolkodom, sokkal messzebb jutok. Valahogy így történt ez a szoftverfejlesztéssel, mint globális fogalommal is.

A megvalósítható dolgokkal együtt az igények is egyre nőttek, nőnek ma is, a növekvő igényeknek meg kell felelni, egyre több, addig kivitelezhetetlennek tűnő dolgot meg kell valósítani, és így tovább. Úgy tűnik, ebből az ördögi körből nincs kiszállás A folyamatosan növekvő igények kielégítéséhez pedig hatékony technikák és módszerek szükségesek. Ezeket a mindig újabb és újabb és újabb fogásokat persze folyamatosan tanulni kell, ha lépést akarunk tartani rohanó világunk kihívásaival. Sok informatikus szakember azonban még mindig a több évtizedes, „jól bevált” módszereket használja, az idő múlásával pedig egyre nehezebben és nehézkesebben változtatja meg ezeket a szokásokat, beidegződéseket. Sajnos ezen egyik pillanatról a másikra nem tudunk változtatni. Nem is létezik módszer, amellyel mindenki meggyőzhető lenne, talán nem is cél ez. Én egyetlen dolgot szeretnék most megpróbálni: bemutatni az UML-t,

mint módszertant, és érveket felsorakoztatni mellette. Először is gondoljuk végig, hogy egy átlagos, hétköznapi fejlesztőnek (persze ha létezik ilyen) milyen igényei lehetnek egy tervezési metodikával kapcsolatban: • jól elkülöníthető, személyekre és csoportokra egyértelműen felbontható, pontosan definiált feladatokat határozzon meg, elősegítve a hatékony csapatmunkát; • pontosan definiálja a fejlesztendő terméket; • a termék minőségének méréséhez (és eléréséhez) egyértelmű mérési szempontokat állapítson meg; • a felhasználói igényeket teljes mértékben vegye figyelembe, a fejlesztők és a megrendelők között magasfokú együttműködést tegyen lehetővé; • az egyéni és csoportos feladatok egységes kezelését is tegye lehetővé, ugyanakkor ne jelentsen túl szigorú megkötéseket sem, ezáltal biztosítson teret az egyéni fejlesztői kreativitásnak. Természetes igény, hogy mindezen követelményeknek egy

szemléletes, sokatmondó ábrázolásmódot feleltessünk meg, amely érthető mindenki számára. Ezáltal a fejlesztők közötti belső, és a kereskedők, megrendelők, felhasználók felé irányuló külső kommunikáció is egyszerűbbé, egyértelműbbé válhat. A „sikersztori” Az egységesítés első gondolata a ’70-es évek közepén merült fel, és persze eleinte korántsem egységes javaslatok születtek. (Sajnos sok helyen ma is jellemző, hogy egy fejlesztőnek annyi jelölésmódot, ábrázolási technikát kell ismernie, ahány különböző projektben dolgozik.) A szoftverek komplexitásának növekedésével és az objektumorientált nyelvek megjelenésével, terjedésével egyre sürgetőbb lett új, mindenki által használható tervezési, elemzési módszerek és egységes nyelvek, jelölésrendszerek kidolgozása. A ’90es évek elejéig több javaslat is született, ezek többsége azonban nem felelt meg az előbb felsorolt igényeknek (legalábbis

nem mindegyiknek), illetve a fejlesztendő rendszer bonyolultságának, az egyre növekvő problématér nagyságának kezelése is kívánalmakat hagyott maga után. Ekkor azonban jött a Nagy Áttörés: olyan új módszertanok jelentek meg, amelyek sikeresen megfeleltek a kihívásnak, és kiállták a fejlesztők próbáját. Ilyen eszközök voltak például: Coad-Yourdon, Fusion, Martin-Odell, OMT, OOSE, ShlaerMellor, stb [1] Az egységesítés Három élvonalbeli fejlesztő (Grady Booch, Ivar Jacobson és James Rumabugh) felismerte az igényt egy egységes módszertan kidolgozására, így összefogtak, hogy az addig megszületett metodikák előnyös tulajdonságait kiemeljék, és azok alapján egy közös koncepciót dolgozzanak ki. Az ő munkásságuknak köszönhetően, több más szerző módszertanának és tapasztalatainak felhasználásával született meg 1997-ben az UML (Unified Modeling Language) modellezőnyelv, illetve 1998-ban a RUP (Rational Unified Process)

módszertan (később több, UML-re építő módszertant is kidolgoztak a szoftvercégek). Mindeközben alakult ki az a fejlesztési metodika is, amelyet inkrementális fejlesztésnek nevezünk. Ezt az a felismerés hívta életre, hogy a gyakorlatban a legtöbb szoftver életének nagyobbik részét teszi ki (és a költségek nagyobb részét is igényli) az újabb és újabb verziók előállítása, a különböző módosítások végrehajtása, korábbi hibák kijavítása, hiányosságok pótlása. Ebben a folyamatban az új szoftver mindössze az első változat előállítását képviseli A „semmiből” létrehozott verzió után az újabbakat mindig a meglévő változatok módosításával, kiegészítésével hozzuk létre. Egy-egy verzió megvalósítása azonban hosszú ideig (akár évekig is) elhúzódhat, közben a fejlesztők egyre több dolgok megtanulnak, tapasztalnak, így az új ismeretek fényében szükség lehet a követelmények módosítására (ugye

ismerős a helyzet?). Ezért célszerű lehet egy verzió készítését több kisebb lépésben, alváltozatok egymásutánjaként előállítani Ezt a folyamatot nevezzük a fejlesztés inkrementális modelljének. Ennek során lehetőség van arra, hogy a rendszer problematikus részeit fejlesszük ki először, majd ehhez hozzáfejlesztjük az újabb és újabb részleteket. (Először többnyire a rendszer viselkedését és kezelési stílusát érzékeltetjük, vagyis a felhasználói felületeket készítjük el.) A rendszer tehát nem egyenletesen fejlődik, hanem bizonyos részeivel egészen a megvalósításig előreszaladunk, tapasztalatokat gyűjtünk, és az elkészült részekhez rakjuk hozzá a még hiányzókat. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár A másik, meghatározó paradigma az architektúraszemléletű fejlesztés. Ez azt jelenti, hogy a rendszer

architektúráját különböző nézetekben képzeljük el, így a modellt sokkal jobban le lehet írni, mintha egyetlen diagramba szeretnénk mindent besűríteni. Ezzel el is érkeztünk jelen cikksorozatom témájához, az UML-hez. Az UML Az UML egy szabványos, egységesített modellezőnyelv, amelynek segítségével a fenti leírások, fejlesztési modellek rendkívül jól szemléltethetőek; a tervezés, a specifikáció, a dokumentálás mind grafikus formában, beszédes ábrák, diagramok, táblázatok segítségével végezhető. A legtöbb vezető szoftvervállalat felismerte már az UML-ben rejtőző lehetőségeket, foglalkozik a szabvány továbbfejlesztésével, így ma már az UML-eszközök kínálata szerfelett széles, mindenki megtalálhatja a számára legmegfelelőbbet. A szoftverfejlesztők egymás közötti, és a felhasználók felé irányuló kommunikációt csak egy közösen elfogadott, mindenki által ismert modellezőnyelv teszi lehetővé. A legtöbb

fejlesztési módszertan ajánl valamiféle jelölésrendszert, viszont a nyelv és a tervezési módszer élesen elkülöníthető (ha kész a terv, és azt valamilyen módon ismertetni tudjuk a többiekkel, akkor már mindegy, hogy hogyan, milyen módon jutottunk el a kész tervig). Ezt ismerték fel az UML készítői, és fejlesztették ki a jelölésrendszert. A grafikus szemléltetés rendkívül hatékony módszer, azonban szem előtt kell tartanunk, hogy a fejlesztésben részt vevő különböző szakemberek mind különböző szemszögből szemlélik a rendszert, illetve ugyanaz a szakember is láthatja másképp ugyanazt a rendszert a fejlesztés más és más szakaszaiban. Ezért olyan módszert kell alkalmazni, amely képes kezelni ezt a sokrétűséget, viszont kellően egyszerű ahhoz, hogy széles körben elterjedjen. Az UML nézetei Az UML-ben mindez úgy valósul meg, hogy egy rendszerhez több különböző nézetet rendelünk, melyek kiegészítik, és bizonyos

értelemben át is fedik egymást (lásd az ábrát). A rendszerről oly módon kapunk teljes képet, ha ezekre a nézetekre együtt, egy egészként tekintünk. Component view Deployment view Use case view Process view Design view Az UML nézetei 1. A használati eset nézet (use case view) A rendszer viselkedését, funkcionalitását írja le a szereplők és a feladatok megjelölésével, a felhasználó szemszögéből nézve. (A szereplő (actor) olyan személy vagy elem, amely kapcsolatban áll a rendszerrel, és aktívan kommunikál azzal, funkciókat indít el, vagy hajt végre.) A használati esetek jól meghatározott funkciók, amelyek végrehajtása üzenetváltást kíván. Meghatározó szerepet játszanak a fejlesztési folyamatban, hiszen a működés leírása a többi nézetet is jelentősen befolyásolja. 2. A komponens/implementációs nézet (component view) A rendszer struktúráját, a programkomponensek, állományok kapcsolatát írja le. Elsősorban a

programfejlesztők használják, hiszen az elemek, kódkomponensek egyetlen működőképes rendszerré integrálását valósítja meg. 3. A folyamatnézet (process view) A rendszert folyamataira, végrehajtható egységeire bontva ábrázolja. Célja a párhuzamosítható műveletek felismerése, az aszinkron események megfelelő kezelése, ezáltal hatékony erőforrás-gazdálkodás elérése. 4. A telepítési/működési nézet (deployment view) A rendszer fizikai felépítését rögzíti, a hardvertopológiát, az adott szoftverkomponensek által igényelt erőforrásokat írja le. 5. A logikai/tervezési nézet (design view) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Azokat az elemeket, feltételeket határozza meg, amelyek a megfelelő működéshez kellenek. Elsősorban a tervezők és fejlesztők számára fontos, hiszen a rendszer statikus struktúráját, az

együttműködést, az objektumok közötti kommunikációt írja le. Itt kell pontosan meghatározni a belső struktúrát és interfészeket is Elemek és relációk A rendszer egyes nézeteinek statikus és dinamikus sajátosságait különböző diagramokkal fejezhetjük ki, amelyek a rendszer elemei közötti relációkat írják le, több különböző szemszögből nézve. Az UML négy relációtípust különböztet meg: 1. függőség (dependency) Két elem között akkor áll fenn, ha az egyik (a független) elem változása hatással van a másik (a függő) elemre. Kölcsönös a függőség akkor, ha mindegyik elem hatással van a másikra. Grafikus ábrázolásában a szaggatott nyíl a független elem felé mutat. 2. asszociáció (association) Az objektumok kapcsolatát, ezek struktúráját határozza meg. Speciális esete a rész-egész viszony, amely kétféle lehet: aggregáció vagy kompozíció. Aggregáció esetén a rész az egészhez tartozik, de önmagában

is létező entitás, míg kompozíció esetén a rész önmagában nem létezhet, csak az egész elemeként. A szemléltető nyílon jelöljük az asszociáció irányát, multiplicitását. Rész-egész viszony esetén az egésznél lévő vonalvég egy csúcsára állított, aggregációnál „lyukas”, kompozíciónál tömött rombusz. 3. általánosítás és specializáció (generalization/ specification) Az objektumok speciális viszonya, gyermek-szülő kapcsolat, amelyben a fölérendelt elem az általános, az alárendelt a specializált. Ábrázolása egy „lyukas” nyíl, amely a szülő felé mutat. 4. megvalósítás (realization) Annak kifejezése, hogy egy osztály biztosít egy másikat arról, hogy elvégez számára egy bizonyos feladatot. Grafikus szimbóluma egy szaggatott, „lyukas” fejű nyíl. A relációk UML szimbólumai Diagramok A diagramok olyan gráfok, amelyek csomópontjai elemeket, élei az elemek közötti kapcsolatokat képviselik. A

különböző diagramok közös elemeket is tartalmazhatnak, hiszen ugyanazt a rendszert ábrázoljuk többféle megközelítésben. Az UMLben két nagy csoportról, statikus és dinamikus diagramokról beszélünk A statikus diagramoknak öt fajtáját különböztetjük meg: 1. Osztály-diagram (class diagram) Az osztályok, interfészek, ezek együttműködésének és kapcsolataiknak ábrázolására szolgál. Egy tipikus osztálydiagramot mutat a következő ábra, melyet Orwell: Állatfarmja alapján rajzolhatunk fel. (Bizonyára mindenki ismeri a nagysikerű regényt.) Az alábbi ábráról jól látható, hogy az osztályokat olyan téglalapokkal jelöljük, amelyek három részből állnak: felső harmadában az osztály neve, középen az osztály attribútumai, alul pedig az osztályhoz tartozó metódusok szerepelnek. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár

Állatok -egyenlők : bool = true Lovak Disznók Tyúkok -egyenlőbbek : bool = true +Dolgozik() +Kapirgál() +TojástTojik() : int Osztálydiagram („Minden állat egyenlő, de egyes állatok egyenlőbbek a többinél”) A nyilak mentén érvényesek az öröklési szabályok, azaz minden gyermek-osztály rendelkezik egy bool típusú egyenlők attribútummal, míg a Disznók osztálynak még egy egyenlőbbek nevű attribútuma is van. A Lovak dolgoznak, a Tyúkok kapirgálnak és bizonyos számú tojást tojnak (például éves szinten). Az attribútumok előtt szereplő apró jelek a következőket jelenthetik: + : public - : private # : protected attribútumról van szó. 2. Objektum-diagram (object diagram) Az osztály-diagram elemeinek pillanatnyilag létező példányait, azok kapcsolatait szemléleti. Objektumdiagram („A tanítás és a szervezés munkája természetszerűen a disznókra hárult, mert általánosan elismerték, hogy ők a legokosabbak az állatok

között Leghűségesebb tanítványuk a két igásló lett, Bandi és Rózsi”) Az objektumokat két részből álló téglalapok reprezentálják, amelyek felső felében az objektum nevét és osztályát, alsó felében attribútumait tároljuk (aktuális értéküket is feltüntetve). 3. Komponens-diagram (component diagram) A komponensek egymáshoz való viszonyát fejezi ki. Ha egy komponens osztályok, interfészek és köztük lévő kapcsolatok együttese, ez az ábrázolásmód szoros kapcsolatban áll az osztály-diagrammal. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár Forradalom.EXE CsakADisznókTudják.DLL Állatizmus.XML Komponens-diagram („Nem tudták, hogy az Őrnagy megjósolta Forradalomra mikor kerül sor, és jó okkal nem is gondolhattak arra, hogy az ő életükben bekövetkezik, de világosan látták, hogy kötelességük felkészülni rá. a

rendszernek az Állatizmus nevet adták.”) A komponenseket a fent látható módon téglalapokkal jelöljük, bal oldalukon két kis „fogacskával”. A szaggatott nyilak az mutatják, hogy mely komponens melyiknek szolgáltat valamilyen információt, eljárást, stb. 4. Telepítési/működési diagram (deployment diagram) A futás közben igényelt erőforrásigényt, és a csomópontokon működő komponenseket ábrázolja. Hétparancsolat.XML Fal Istálló Telepítési diagram („Ezt a Hétparancsolatot most fel fogják írni a falra, ezek változtathatatlan törvények lesznek, és az Állatfarm valamennyi állatának mindörökké ezek szerint kell élnie.”) Az erőforrásokat téglatestek ábrázolják, ezek közötti kapcsolatot, illetve a szoftverkomponensek „hovatartozását” szemlélteti a fenti ábra. 5. Használati eset (use case) diagram A valós rendszer szereplőit, ezek kapcsolatát és tevékenységeit mutatja be. A rendszer szervezése,

viselkedésének leírása és ellenőrzése szempontjából létfontosságú! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Irányít Disznó Termés Ló Dolgozik Tyúk Szamár Használati eset diagram („Mennyit gürcöltek, izzadtak, hogy begyűjtsék a szénát!. De a disznók olyan okosak voltak, hogy minden nehézséget le tudtak győzni.”) Az UML diagramok másik csoportja, a dinamikus (más néven viselkedés-) diagramok az objektumok egymásra hatását, kommunikációját, üzenetváltásait mutatják be. Négy típus sorolható ide: 1. Szekvenciadiagram (sequence diagram) Az üzenetek küldésének és fogadásának időrendi sorrendjét határozza meg, a használati esetekből kiindulva. Szekvenciadiagram („Az állatok ebben az évben úgy dolgoztak, mint a rabszolgák.”) Itt az üzenetváltás szereplőit nagy téglalapokkal jelöljük az ábra

tetején. Az idő múlását a függőleges tengely szemlélteti, a cselekvéseket a szaggatott vonalú tengelyeken lévő hosszú téglalapok (ezek hossza a cselekvés időtartamával arányos). Az üzenetek a küldőtől a fogadóig húzott nyíllal szerepelnek az ábrán 2. Együttműködési diagram (collaboration diagram) Az üzeneteket váltó objektumok kapcsolatát, és az üzenetváltás struktúráját ábrázolja. A szekvenciadiagramból egyszerű algoritmus alapján megkapható. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár 4. Elosztás Disznó 5. Maradék elosztás 1. Dolgozni kell Ló 3. Termés raktáron 2. Termés betakarítva Raktár Együttműködési diagram a szekvenciadiagram alapján Az üzenetküldőket és –fogadókat itt egyszerű ellipszisek jelképezik, az üzenetek itt is a fentihez hasonló nyilak, rajtuk az üzenet küldésének relatív

időpontja (az üzenet sorszáma) és az üzenet neve. 3. Állapot- vagy állapotátmeneti diagram (state-chart) A diagram csomópontjai állapotok, az irányított élek az állapotok közötti átmeneteket reprezentálják. Rendkívül fontos az eseményorientált viselkedés vizsgálatánál. Felszántva Bevetve Parlagon Learatva Mûvelve Állapotátmenet-diagram („Ez a munka szigorúan önkéntes volt, de aki kihúzta magát belőle, annak felére csökkentették a fejadagját.”) 4. Aktivitás- vagy tevékenység-diagram (activity diagram) Speciális állapotdiagram, amely a végrehajtandó tevékenységek folyamatát mutatja. Jelentősége az objektumok vezérlési folyamatainak tervezésénél a legnagyobb. Aktivitás-diagram Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 8 NetAcademia-tudástár Amint ezekből az egyszerű példákból is látszik, az UML rendkívül sokoldalú

modellezőnyelv. Remélem, sikerült mindenkit meggyőznöm arról, hogy a valós (vagy valósnak vélt) folyamatok több oldalról, több szempontból történő vizsgálata mennyire fontos. Sokoldalúsága mellett egyszerűsége az UML-t alkalmassá teszi arra is, hogy mindennapi munkánkban alkalmazzuk, nem kell megijedni az első ránézésre kacifántosnak tűnő ábráktól! Az UML óriási előnye, hogy a jelölésre koncentrál, nem a konkrét tervezési módszerekre vagy megvalósításokra, így bármit le lehet írni vele. Egy UML-lel megtervezett rendszer pedig megvalósítható C++-ban, Javaban, C#-ban, VB.NET-ben A következő hónapokban részletesen is bemutatok néhány hasznos „fogást”, „trükköt”, amelyet a modellalkotás során érdemes alkalmazni, és hamarosan már minden Tech.Net olvasó jártas lesz ebben a „misztikus” világban  Molnár Ágnes agnes.molnar@t-systemscom A cikkben szereplő URL-ek: [1] http://wwweb.org/smo/bmc/ Ez a dokumentum a

NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 9 NetAcademia-tudástár Az UML – 2. rész Az előző részben igyekeztem szemléletesen bemutatni az UML felépítését, nézeteit és diagramjait. Arról azonban nem szóltam, hogy az első ötleteléstől hogyan, mi módon juthatunk el a kész termékig. Ezúttal igyekszem pótolni ezt a hiányt, és megválaszolni a felmerült kérdéseket. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 10 NetAcademia-tudástár Mindezt egy konkrét példán keresztül teszem meg. Tegyük fel, hogy megrendelőnk egy számítógépes biliárdjátékot szeretne készíttetni velünk. A konkrét megvalósításról nincs elképzelése (valószínűleg nem is informatikai szakember), azonban a játék szabályait pontosan ismeri, ez alapján kell megvalósítanunk a rendszert. Szabályok: • A dákóval csak a

fehér golyót lehet meglökni. • Aki az első golyót a lyukba löki, az ettől kezdve ilyen színű golyókkal van, míg ellenfele az ellenkező színűekkel. • Ha valaki csak saját színű golyót juttat lyukba, akkor még egyszer jöhet. • A soron következő játékos kétszer jön, ha társa a fekete golyót vagy ellenfele egy golyóját találja el először; ellenfele golyóját is lyukba juttatja; nem koccantja a fehér golyót más golyóhoz; a fehér golyót a lyukba juttatja (ekkor a fehér golyót kezdő pozíciójának környezetébe helyezzük vissza); kivéve, ha valakinek elfogyott az összes golyója az asztalról. • Ha valamely játékos utolsó golyóját is lyukba juttatta, akkor az utolsó leeső golyó lyukával átellenes lyukba kell a fekete golyót juttatnia. • A játékot az nyeri, akinek ez elsőként sikerül. • A játékot elvesztette valaki, ha a fekete golyót idő előtt vagy rossz lyukba juttatta, illetve ha jó lyukba juttatta, de ezzel

együtt a fehér golyó is lyukba esett. A biliárdasztal képe a dákóval és golyóval Első lépés: az igények felmérése A megrendelőtől tehát csak köznapi nyelven kapjuk meg az igényt, ez alapján kell elindulnunk a megvalósítás felé. Egy szoftver fejlesztése azonban meglehetősen egzakt folyamat, pontos, szabatos fogalmak használatát igényli. Ezért szükséges, hogy a kapott definíció alapján elkészítsük a rendszer szótárát, amelyben definiáljuk a fontosabb szavak, fogalmak pontos jelentését. A fenti szabályoknak megfelelő szótár egy részlete például ez lehet: Fal: Az asztal széle, az asztal síkjára merőleges. A játék során a helyzete nem változik Lyuk: Az asztal kör alakú része, amely elnyeli a golyókat. Dákó: Ezzel az eszközzel lökjük meg a golyót. Játékosok: A játékot játszó személyek. Két csapatra oszlanak, és a két csapat felváltva lökhet (kivéve, ha a szabályok másként nem rendelkeznek). Golyó színe:

Egy golyónak 4 különböző színe lehet: csíkos, sima, fekete és fehér. Lökés: A dákóval kezdősebességet adunk a fehér golyónak. Ütközés: A golyók egymással, vagy a fallal való érintkezése. Felmerülhet a kérdés, hogy milyen fogalmakat érdemes belevenni a szótárba. Honnan állapíthatjuk meg, mi lényeges és mi lényegtelen a megvalósítandó rendszer szempontjából? Néhány irányelv alapján könnyedén válaszolhatunk erre a kérdésre. Először is fel kell térképeznünk a rendszer szereplőit, akik valamilyen módon részt vesznek a folyamatokban. Esetünkben ilyen szereplő a két játékos (akik lökéseikkel irányítják a Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 11 NetAcademia-tudástár játék menetét), a dákó, a golyók, a fal és a lyukak. (Ez utóbbiak jelentősége abban rejlik, hogy létükkel és elhelyezkedésükkel befolyásolják,

megváltoztatják a golyók irányát, sebességét, stb.) A szereplők a felhasználói specifikációban többnyire főnévként jelennek meg, és vagy ők végzik a cselekvést (játékos), vagy passzív résztvevői annak (dákó, golyó stb.) A szereplőkhöz különböző jellemzők is tartozhatnak, melyek közül a kiemelkedő fontosságúakat szintén szerepeltetni kell a szótárban (pl. a golyó színe) A cselekvések és események jelentik a program működésének másik kulcsát, így azokat is pontosan meg kell magyarázni a szótárban (mit jelent például a lökés vagy az ütközés). Ezeket többnyire a felhasználói specifikáció igéi vagy igenevei közül szűrhetjük ki (lökés), illetve az alapján adjuk hozzá a triviálisan adódókat (ütközés). Követelményspecifikáció A felhasználó elvárásainak dokumentálása a fejlesztés első lépése. Sajnos bármilyen részletes is ez a dokumentáció, a legapróbb gondosság mellett sem tartalmazhat

minden apró részletet. Nehéz megállapítani, hogy mi az a részletezettség, amely szükséges és elégséges is, hiszen ez a különböző szakterületektől, a céloktól, a környezettől és még sok egyéb tényezőtől függően nagyon változó. A követelményelemzésnél továbbra is kívülről szemléljük a rendszert, és nem bonyolódunk bele a technikai részletekbe. Ez a munka nagyon sok megbeszélést, egyeztetést és a felhasználóval való szoros együttműködést igényel. Üzleti folyamatelemzési technikákat és use case-eket használunk, célunk pedig (vázlatosan) definiálni a készülő rendszer funkcionalitását, az elemek viszonyát kifejező együttműködési diagramokat, vagy a folyamatok feltérképezéséhez szükséges aktivitás-diagramokat. Már ebben a fázisban is lehet végezni különböző költség- és erőforrásbecsléseket, azonban ezek még meglehetősen durva, nagyvonalú közelítések, csak tájékoztató jellegűek lehetnek. A

biliárd esetében először tisztázzuk a fizikai részleteket. A felhasználóval egyeztetve rögzítenünk kell azokat a fizikai törvényeket, amelyek a játék során hatnak, ezeket definiálni kell, és itt szükséges annak tisztázása is, milyen pontosságot várunk el a megvalósítandó programtól. Fizikai részletek • ütközést detektálunk, ha két golyó középpontjának távolsága nem több a sugár kétszeresénél (megengedett maximális egymásba csúszás a sugár 1/10-e) • két ütközés közötti lassulás megvalósítására időben lineáris függvényt alkalmazunk • fallal és egymással való ütközés nem ideális, az ütközés utáni sebesség az ideális sebesség 95 %-a Apróságnak tűnő, de lényeges fizikai jellemzője a játékban részt vevő tárgyaknak a mérete. Pontosan meghatározott arányban kell állnia a golyók, a dákó, az asztal méretének egymással ahhoz, hogy a számítógépes játékmodell a valós életben

megszokottat élethűen tükrözhesse. A követelmények között rögzíthetünk olyan részleteket is, amelyek nem lesznek részei ugyan az aktuális rendszernek, azonban későbbre olyan bővíthetőségi lehetőséget tartalmaznak, amely már most jól körvonalazható és leírható. Például: A jobb játszhatóság érdekében a játékba a lökésnél (az erősség és az irány megadásánál) bevehető a véletlen. Ezt a funkciót az első verzió még nem fogja tudni, de a kódban meghagyjuk a lehetőséget a fejlesztésre. Definiálni kell a felhasználói felület alapjait is: mit vár a megrendelő, milyen funkciók hogyan legyenek kivezetve az interfészre. A menük alapfelépítését, az esetleges ábrák elhelyezkedését, igény szerinti gyorsbillentyűket stb határozhatunk itt meg, például az alábbi módon: • • • • A kezelői felületet alapvetően három részre oszthatjuk: (felülről lefelé) vezérlési rész, játéktér, állapotsor. A

vezérlési rész tulajdonságait tekintve lehetőséget biztosít a kilépésre, az újrakezdésére (a játék végén automatikusan lehetőséget nyújt az újrakezdésre), valamint a játékosok adatainak bevitelére. A játék közben, ha az összes golyó megállt, mentési lehetőség is rendelkezésre áll. A játékrészen megjelenik az asztal a lyukakkal, a golyók és a dákó, természetesen méretarányosan. A lyukba esett golyók a játéktérről eltűnnek és ezek után már nem vesznek részt a játékban (kivéve, ha a fehér golyóról van szó). Az állapotsor kijelzi a következő lökő játékos nevét, golyóinak színét és a játék állását. Természetesen vázlatos képernyőterv is készíthető, amely a fejlesztés további szakaszaiban még módosulhat – a megrendelővel egyeztetve. A biliárd esetében a valódi asztal képe alapján nem nehéz elképzelni, hogyan nézhet ki a játékfelület: Ez a dokumentum a NetAcademia Kft. tulajdona

Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 12 NetAcademia-tudástár A biliárdjáték képernyőterve Fontos tisztáznunk a rendszer életciklusmodelljét is, azaz azt, hogy egyedi fejlesztésről van-e szó, vagy tovább értékesíthetjük a megrendelő beleegyezésével, avagy a nélkül. Itt szükséges a fejlesztés ütemének meghatározása, a fontosabb részfeladatokra lebontva. Pontosan le kell írnunk azokat a feltételeket, amelyeket a készterméknek teljesítenie kell (a futtatható programon kívül ide értendők a megfelelő dokumentációk is). A biliárdprogram esetében rendszernek magát az asztalt tekintjük, a falakkal, lyukakkal és golyókkal egy egységet alkotva. A felhasználó szemszögéből nézve ez önálló „életet él”, működésébe beavatkozni csak néhány ponton lehet (játék indítása, golyó meglökése stb.) Rendszerünkkel ketten állnak kapcsolatban (ők a rendszer aktorai): Maga a játékos, a

külső felhasználó, aki a golyókat meglöki, illetve egyéb utasításokat ad a rendszernek, mint például a játék újraindítása, elmentése, betöltése. A játékos a billentyűzeten és az egéren keresztül kommunikál a rendszerrel A játékfelügyelő egy programmodul, ami a szabályok betarttatásáért felelős. Ő utasítja például a rendszert, hogy a fehér golyót helyezze vissza az asztalra, ha az valamelyik lyukba beleesett. Ennek a modulnak a megfelelő kialakításával elérhető, hogy a programban akár több szabály szerint is játszhassunk. A játékfelügyelő modul a programon belül, objektumok közötti üzenetek váltásával kommunikál. Működése a játékosok számára transzparens, láthatatlan Látható, hogy a játékos kétféle, a felügyelő modul pedig egyféle utasításokat adhat. Ezek alapján három use case különböztethető meg: • Játék interface: közvetlenül a játékhoz tartozó utasítássorozat. A játék elején, majd

azután minden körben, miután a golyók megálltak a játékos neve megjelenik a képernyőn, majd a játékos kiválasztja a lökés irányát, ezután annak erősségét. Ezzel a kommunikáció véget ért, a játékos nem adhat újabb utasításokat a rendszernek, amíg a golyók meg nem állnak. • Játék opciók: a játék interface kiterjesztése, mely során a játékos a golyók összességét befolyásoló utasításokat adhat, eldöntheti, hogy kilép a programból, újraindítja a játékot, elmenti annak állását, esetleg betölt egy korábbit. Ez a kommunikációs csatorna is a golyók megállásakor aktiválódik, és véget ér, ha a játékos meglökte a golyókat, vagy kilépett a programból. Ha az állás újrakezdést/mentést/töltést választja, a use case azonnal újraindul • Játékfelügyeleti modul: a játékfelügyelő beavatkozása a rendszerbe. Működése a megfelelő események felismerésekor indul (golyó lyukba került), a modul eldönti, hogy

a szabályok alapján mi a teendő, majd utasítást ad a megfelelő cselekvésre (színes golyó esetén annak levételére, fehér golyó esetén annak visszahelyezésére ad utasítást). Az utasítás végrehajtásával ér véget a use case. Korábban már volt szó arról, hogy a használati eset (use case) a rendszer viselkedését, funkcionalitását írja le a szereplők és a feladatok megjelölésével, a felhasználó szemszögéből nézve. A fenti szereplők és szerepek alapján most tehát már felrajzolhatjuk a rendszer használati eset diagramját: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 13 NetAcademia-tudástár A biliárd játék use case diagramja A követelménydefiníciós fázisban tehát eljutottunk oda, hogy a felhasználói igényeket pontosan rögzítettük, definiáltuk, kitűztük a fejlesztés célját. Körvonalazódtak az elvégzendő feladatok, ennek megfelelően

kialakítható az a csapat, amely ezek megoldásán dolgozik majd. Személyre szabottan kioszthatók az egyes feladatok Egy olyan, számunkra és a megrendelő számára ideális modellt dolgoztunk ki, amely mindenki igényeinek és korlátainak megfelel. Osztályok leírása Eddig csupán kívülről szemléltük rendszerünket. Meghatároztuk a megvalósítandó szoftverrel szemben a felhasználó által támasztott követelményeket, tudjuk, mit kell tennie majd a programnak, azonban még nem szóltunk a hogyan-ról. Ebbe általában a megrendelő már nem szól bele, nincs igénye (és többnyire kellő ismeretei sem) arra, hogy megmondja, milyen osztályokat, kapcsolatokat, együttműködéseket implementáljunk. Számára az a fontos, hogy a program működjön (esetleg egy általa előre kikötött hardver/szoftver konfiguráción). Kritikus lehet még esetleg a sebesség vagy a felhasználóbarát interfész, de ezek mind olyan kritériumok, amelyek a belső megvalósítástól

függnek. Előttünk tehát a feladat, hogy mindezen követelményeknek megfeleljünk. Az igények sokoldalúságából következik, hogy a készítendő rendszert pontosan, gondosan meg kell terveznünk. A belső tervezés első lépése a különböző osztályok, objektumok meghatározása, feladatainak specifikációja, a közöttük lévő kapcsolatok feltárása. Ez alapján aztán már felrajzolható a statikus struktúradiagram. Fontos, hogy az osztályok meghatározásánál a célszerűségre törekedjünk. Derítsük fel, milyen nagy objektumkategóriák szerepelnek a rendszerben, melyek általánosíthatók, melyeket kell ezek közül konkrétabbá tenni. Vizsgáljuk meg az egyes kategóriák közötti kapcsolatot, együttműködéseket, üzenetváltásokat. Lássuk, hogyan néz ki mindez a biliárd esetében. Gyűjtsük össze eddigi ismereteink alapján a szükséges osztályokat, és röviden írjuk le viselkedésüket: Szabályok Egyetlen példánya van. Felelőssége

ellenőrizni a játékszabályokat. (Továbbfejlesztés esetén ennek több példánya is lehet, lehetőséget nyújtva különböző típusú biliárdjáték játszására.) Input interface Egyetlen példánya van. Figyeli a játék menetébe kívülről érkező beavatkozásokat. Lökéskezelő Egyetlen példánya van. Beolvassa a játékosok lökéseit. Menüutasítások Egyetlen példánya van. A felhasználói felület három egységéből (vezérlési rész, állapotkijelző, játékrész) a vezérlési rész működését koordinálja. Asztal Egyetlen példánya van, a biliárdasztal. Felelősségei: Figyeli a golyók mozgását, ütközteti. az ütközéseket. A megfelelő golyókat egymással és a falakkal Golyó Példányai a játékgolyók. Feladatai: tárolja a golyó helyét (asztalon, lyukban van-e, az asztalon hol van), és hogy merre gurul, milyen sebességgel. Asztal-, golyórajzoló Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül

szabadon terjeszthető  2000-2003, NetAcademia Kft 14 NetAcademia-tudástár Egyetlen példánya van. A felhasználói felület három egységéből a játékrészt jeleníti meg, a megfelelő paraméterek birtokában kirajzolja a kezdőállapotot, majd a játék során a többi objektumtól kapott információk alapján frissíti a látványt. Játékállapot-kijelző Egyetlen példánya van. A felhasználói felület három egységéből az állapotkijelző karbantartását végzi a kapott adatok alapján. Lökés-/Dákórajzoló Egyetlen példánya van. Feladata a játék során a lökés műveletének látványtechnikai megvalósítása. Menürajzoló Egyetlen példánya van. Felelőssége a felhasználói felület három egységéből a vezérlési rész megjelenítése. Az osztálykatalógussal szinkronban az objektumkatalógus is felírható, ennek elemei a játékprogram objektumai és azok leírása: Szabály A main indítja el. Figyeli a játék és a pillanatnyi

lökés állását Miközben a golyók mozognak, gyűjti az adatokat. Miután értesítést kapott az összes golyó megállásáról, kiértékeli a történteket (ki következik, mely golyókat kell visszarakni, vége van-e a játéknak) Ezután törli az események listáját, így felkészülve a következő lökésre, majd elindítja az input interface-t. Input interface Kezeli a billentyű, későbbiekben az egér bemenetet. továbbítja Az inputot a Lökéskezelőnek és a Menüutasításoknak Menüutasítások A következő menüopciók vannak: - Játék újraindítása Ehhez közvetlenül hozzátartozik a játékosok nevének lekérdezése, majd utasításküldés a Szabályobjektumnak, hogy helyezze el a golyókat az asztalon - Játék mentése - Játék visszatöltése Lökéskezelő A dákó mozgatását, asztalnak. és a lökés erősségét kezeli. Mikor a lökés megtörténik, a paramétereket áradja az Asztal Miután a lökéskezelőtől megkapta a

fehér golyó kiindulási sebességét és irányát, szimulálja a golyók mozgását. Minden lényeges eseményről (első koccanás, golyó lyukba került, minden golyó megállt) üzenetet küld a Szabályobjektumnak Golyó Az asztal tulajdonában van, négy leszármazottja a fehér, a fekete és a hét teli és csíkos golyó Csíkos golyó Hét darab Szülőosztály: Golyó Teli golyó Hét darab Szülőosztály: Golyó Fekete golyó Egy darab van belőle Szülőosztály: Golyó Fehér golyó Egy darab van belőle. Csak ezt kehet meglökni Szülőosztály: Golyó Dákórajzoló A lökés során a dákó képét rajzolja, ill. a lökés erősségét (terv: a dákó forog a fehér golyó körül, a lökés erősségét a dákónak a golyótól való távolsága mutatja) Menürajzoló A menü kirajzolásáért felelős. (Első előreláthatólag a későbbi verziókban) verzióban csak kiírás a gombkombinációkról, legördülő menü Játékállás-kijelző Ez a

dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 15 NetAcademia-tudástár A játék állásáról tudósít: ki következik, kinek hány golyója van még. Asztalrajzoló Kirajzolja az asztalt, ill. az azon lévő golyókat Képes csak egyetlen golyót újrarajzolni A fizikai modell koordinátáit átszámolja képernyő-koordinátákra A fenti osztályok és objektumok alapján rajzoljuk fel a statikus struktúradiagramot: A biliárdjáték statikus struktúradiagramja Mit is láthatunk a fenti diagramon? Középen található a Szabályobjektum, amely a program indulásakor azonnal betöltődik. A Menüutasítások, az Input interfész, a Játékállás-kijelző és az Asztal objektumokkal áll kapcsolatban. Ez utóbbi kettőnek üzeneteket küld (egy-egy esemény bekövetkezésekor hogyan módosul a játék állása, adott lökés hatására hogyan kell mozgatni a golyókat, valamelyiket el kell-e tüntetni

stb.) Az asztalon golyók találhatók, amelyek négyfélék lehetnek (fekete, fehér, csíkos vagy teli). A bemeneti interfész kezeli a felhasználói üzeneteket, ő dolgozza fel a billentyű- és egéreseményeket, a szabályokon keresztül ő rajzolja ki a dákót illetve indítja el a golyók mozgását. Az Input interfész szintén kapcsolatban áll a Menüutasításokkal (a felhasználó aktiválja az egyes menüpontokat), illetve a Lökéskezelővel, amely a játékos utasításainak megfelelően a dákó kezelését végzi, és kirajzoltatja azt a Dákórajzolóval. A statikus struktúra felrajzolása után rátérhetünk a dinamikus nézetekre. Ezek a program folyamatait, az objektumok egymásra hatását, kommunikációját írják le. Lássuk, milyen alapvető folyamatokból épül fel a biliárd: Először is biztosan van egy inicializáló folyamat, amely a program betöltődésekor indul. Ezen kívül két másik folyamatot kell definiálnunk: a lökést, és a

menüpontok aktiválását. Ezekkel a rendszer teljes működése leírható Példaként a lökés szekvenciadiagramját mutatom be, a többi ehhez hasonlóan egyszerűen megadható. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 16 NetAcademia-tudástár A lökés szekvenciadiagramja Lássuk, mi történik a fenti ábra alapján. A Szabályobjektum indulása után egy engedélyező üzenetet küld az Input Interfésznek, s az ennek következtében a bemeneti adatokat elküldi a Lökéskezelőnek. A Lökéskezelő rajzolásra utasítja a Dákórajzolót, majd letiltja a bemeneti csatornákat (amíg a lökés nem ért véget, vagyis a golyó nem állt meg, a felhasználó nem adhat újabb utasításokat a rendszernek). A golyó elmozdulásának irányát és sebességét megkapja az Asztal, amely az Asztalrajzoló segítségével kirajzolja az aktuális állapotot a képernyőre. Ha a golyó egy másik

golyóval koccan, a Szabályobjektum kap egy üzenetet erről (az üzenet paramétere az a golyó, amellyel ütközött a mozgó golyó; a többszörös ütközéseket visszavezetjük több kétgolyós ütközésre). Hasonlóan tájékoztatjuk a Szabályt arról is, ha egy golyó elment (beleesett egy lyukba), vagy megállt. Mindeközben a Szabályobjektum folyamatosan értesíti az Asztalt az aktuális állásról, a megjelenítés céljából. A golyómozgások leállásával a Szabály újra engedélyezi az Input interfészt, ezzel az egész fenti folyamat kezdődhet elölről. Ezen kívül fontos lehet felírni az egyes objektumok állapotait és állapotátmeneteit is. Erre szolgál az állapotátmeneti diagram (state-chart), mely rendkívül fontos a rendszer eseményorientált viselkedésének feltárásánál és leírásánál. A diagram csomópontjai az adott objektum állapotai, irányított élei az átmeneteket jelölik. Tekintsük például az Input interfész objektumot.

Milyen állapotai lehetnek? A kezdeti inicializálás után alapértelmezésben tiltva van (nem fogadunk felhasználói utasításokat), majd az engedélyezés után válik engedélyezetté, és újabb tiltás után ismét letiltódik. Az, hogy kitől érkeznek ezek az üzenetek, az állapotátmenetek szempontjából nem lényeges Az Input interfész állapotátmenet-diagramja Hasonlóképp rajzolhatjuk fel a többi objektum (Asztal, Szabály stb.) állapotátmeneteit is, ezt az Olvasóra bízom Összegzés Lássuk, hova is jutottunk el idáig. A követelmények tisztázása, a megrendelő igényeinek rögzítése után szükséges a feltételek pontos, szabatos megfogalmazása, a rögzített követelmények elemzése, a rendszer analízise. Elsőként a rendszerrel kapcsolatos szavakat, fogalmakat definiáljuk, pontosítjuk, konkretizáljuk. Ismeretes ugyanis, hogy mi, földi halandók hányféleképp tudjuk érteni ugyanazokat a dolgokat. A követelmények meghatározása hasonló

célokból szükséges, muszáj egyértelművé tenni, mit is várunk (mit vár a megrendelő) a megvalósítandó rendszertől, mikor nevezhetjük „kész”-nek a terméket. Ezek után kerülhet sor a használati eset diagram (use case) felrajzolására, amely a rendszer szereplőit és feladatait írja le. Ez már konkrét, precíz fejlesztői dokumentáció, és egész további munkánk alapját jelenti. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 17 NetAcademia-tudástár A statikus struktúradiagram a következő lépés, amely közelebb visz bennünket a megoldáshoz. Hogyan is fejleszthetnénk szoftvert, ha nem ismerjük annak statikus felépítését, szerkezetét? Hasonlóan fontos a különböző folyamatok részletes felírása különböző szekvencia-diagramokkal, majd pedig egy-egy objektumra koncentrálva annak állapotátmenetidiagramjával. Ez utóbbiak már a dinamikus viselkedést

írják le, amely szintén elengedhetetlen feltétele a későbbi megvalósításoknak. Jól látható, hogy mindezidáig egyetlen sor kódot sem írtunk. Tapasztalataim szerint a fejlesztők jelentős hányada sokkal jobban szereti a „vágjunk a közepébe” módszert, mint bajlódni a sok-sok dokumentációval. Pedig – mint azt példánkban is láthatjuk – a dokumentálás hosszú távon igen gyümölcsöző befektetés. Egyetlen sor kódot sem írtunk még le, sőt még arra sem utaltunk, hogy milyen technológiák segítségével, milyen nyelven végezzük majd a fejlesztési munkát, és máris mennyi mindent tudunk jövőbeli rendszerünkről! És mennyi mindent megtudunk még, ha folytatjuk ezt a folyamatot A következő hónap(ok)ban végigvezetem a rendszer teljes fejlesztési ciklusát, folytatva a megfelelő dokumentumok készítésével, és a programkódok, a tulajdonképpeni szoftver megírásával. Addig is mindenkinek jó szórakozást kívánok saját

rendszeréhez! Molnár Ágnes agnes.molnar@t-systemscom Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 18 NetAcademia-tudástár Az UML – 3. rész Az UML témát folytatva tovább boncolgatom a biliárd játékot, újabb lépésekkel közelebb kerülve a kész programhoz. Az elmúlt hónapban eljutottunk a követelményspecifikáción, a fizikai részleteken és a használati eseteken keresztül az osztályok leírásáig. Innen szeretném most folytatni Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 19 NetAcademia-tudástár A szkeleton Egy rendszer szkeleton változatának célja annak bizonyítása, hogy az objektum és dinamikus modellek a definiált feladat egy modelljét alkotják. A szkeleton egy program, amelyben már valamennyi, a végső rendszerben is szereplő üzleti objektum szerepel. Az objektumoknak csak az

interfésze definiált Valamennyi metódus az indulás pillanatában az ernyőre szöveges változatban kiírja a saját nevét, majd meghívja azon metódusokat, amelyeket a szolgáltatás végrehajtása érdekében meg kell hívnia. Amennyiben a metódusból valamely feltétel fennállása esetén hívunk meg más metódusokat, akkor a feltételre vonatkozó kérdést interaktívan az ernyőn fel kell tenni és a kapott válasz alapján kell a továbbiakban eljárni. A szkeletonnak alkalmasnak kell lenni arra, hogy a különböző forgatókönyvek és szekvencia diagramok ellenőrizhetők legyenek. A jó szkeleton osztott képernyővel dolgozik. Az ernyő egyik része szolgál a szöveges üzenetek és párbeszédek lefolytatására, a másik félben egy szekvencia diagramot célszerű kirajzolni. Csak karakteres ernyőkezelés fogadható el, mert ez biztosítja a rendszer egyszerűségét. A biliárd szkeletonja ugyanúgy három használati esetre bontható, mint a majdani kész

program, különbség csak az egyes use-case-ek megnyilvánulásaiban van. Mivel a kezelő felület a program készítésének ebben a fázisában még nem kerül megvalósításra, ezért a felhasználó irányába történő kommunikáció egyszerű dialógusokra redukálódik. A mögöttes algoritmusok hiánya miatt pedig az egyes programrészek közötti használati esetek (a szabály objektum és az asztal közötti) üzenetváltásokra is a felhasználó fog utasítást adni. Az alábbi ábrán látható a két részre osztott szöveges képernyő: a baloldalon folyik a kommunikáció a felhasználóval, itt teszi fel a rendszer azokat a kérdéseket, amelyekre a későbbiekben algoritmikus választ kapunk, ám a fejlesztés jelenlegi szakaszában ezek még nem elérhetők. (Ilyen pl annak meghatározása, hogy a felhasználói interfész engedélyezett-e vagy sem, lesz-e újabb lökés stb.) Jobboldalt a kommunikációs diagram látható. Ez egy fa struktúra, amely az egyes

metódusokat illetve a metódusok közötti üzenetváltásokat mutatja, meghívásuk sorrendjében és mélységében. A szkeleton futása közben ez a lista folyamatosan frissül. Így az ábrán látható diagram például azt mutatja, hogy a rendszer betöltődésekor először az az AsztalAsztal metódus került betöltésre, majd ez sorra meghívta az az AsztalRajz.AsztalRajz, a FeherFeherg, stb függvényeket Amikor ezek is sikeresen lefutottak, az a Szabaly objektum Szabaly metódusát hívjuk meg, stb. Természetesen ezeket a függvényhívásokat befolyásolják a bal oldali ablakrészben megadott felhasználói utasítások is. (Az ábrán látható kék ágak csupán a megértést segítik, a karakteres képernyőn megvalósított szkeleton természetesen nem tartalmazza ezeket a grafikus elemeket.) A fastruktúra nemcsak a képernyőn jeleníthető meg, hanem naplófájl is készíthető belőle, amely a egyrészt későbbi vizsgálatokat könnyíti meg, másrészt a

rendszer futására való rálátásunk nem korlátozódik néhány sorra. A Biliárd szkeletonja működés közben A szkeletonban megvalósított használati esetek tehát a következők lesznek: • • Játék interfész (megvalósító objektum: lökéskezelő): Inicializáláskor az interfész objektumon keresztül a szabály objektum indítja el, valamint minden alkalommal, amikor az összes golyó megállt, és még nincs vége a játéknak. Futása a lökés megtörténtével ér véget A szkeleton a lökés paramétereire (irány, erősség) nem, csak a lökés megtörténtére kérdez rá. Játék opciók (megvalósító objektum: menükezelő): Szintén az interfész objektum indítja. Ugyanúgy inicializáláskor, vagy az összes golyó megállása után aktivizálódik, azzal a különbséggel, hogy a játék végetérte után is működésbe lép. A lökés megtörténtekor, vagy a játékból való kilépéskor ér véget. Működése során rákérdez, milyen

esemény történt: játék-újrakezdés, mentés, betöltés, kilépés Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 20 NetAcademia-tudástár • Játékfelügyeleti utasítások (megvalósító objektum: szabály): A lökés megtörténtekor a lökéskezelő indítja. A Szabály objektum és az Asztal közötti üzenetváltásokat csoportosítjuk ide. Ezek a következők lehetnek: – az asztal által a szabálynak küldött üzenetek a golyók mozgása közben történt eseményekről; – a golyók megállta utáni utasítások az asztal felé: fehér golyó visszahelyezése az asztalra, összes golyó visszahelyezése (inicializáláskor, és játék újrakezdéskor). Mivel a szabály objektum algoritmust még nem tartalmaz, ezért a felhasználónak továbbítja az eldöntendő kérdéseket: véget ért-e a játék, elment-e a fehér golyó. Emellett az asztal is rákérdez az egyes eseményekre:

történt-e ütközés, első ütközés-e, elment-e a golyó, megállt-e minden golyó stb. A Biliárd szkeletonjának használati eset diagramja A szkeleton működése során felmerülnek olyan döntési helyzetek, amelyek algoritmus hiányában a szkeleton még nem tud megoldani, így nem tudja, melyik legyen a következő aktivizálandó objektum. A biliárddal kapcsolatban négy ilyen esetet különböztetünk meg: • • • • Interface: A program futása közben nem lehet tudni, hogy egy lökés befejeződése után a kapott inputot melyik objektum dolgozza fel. (Menüutasítások / Lökéskezelő) Szabály: Ez az eset akkor áll fenn, ha a futás során minden golyó megállt. A felmerülő lehetőségek: az egyes vagy a kettes játékos jön, nyer valaki, elment a fehér golyó. Asztal Az asztal szempontjából több jelentős esemény lehetséges, amelyek közül ebben a stádiumban még nem tud választani a program: mely golyók mozognak (ezeknek utasítást küld

egységnyi mozgásra), megállt-e mindenki, elment-e az első golyó, ütközés történt-e két golyó vagy golyó és fal között (üzenet a megfelelő golyó(k)nak), első ütközés történt-e. Menü Ha a menü aktivizálódott, akkor a következők közül választhatunk: ment, betölt, kilép, újraindít. A szkeleton megírásakor kell ügyelnünk arra is, hogy a megfelelő kollaborációs (együttműködési) diagramokat helyesen írjuk fel, hiszen ezek alapvetően meghatározzák a program további működését és felépítését. Szabály 6: Engedélyez() 3: Kiír() Játékállás kijelző Input interfész 4: Start() 1: Start() Menüutasítások Asztal 5: Rajzol() 2: Rajzol() Asztalrajzoló Menürajzoló Az inicializálás kollaborációs diagramja Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 21 NetAcademia-tudástár A fenti ábrán az inicializáció együttműködési

diagramja látható. Az egyes objektumok közötti nyilak a meghívások irányát jelzik, a metódusok előtti sorszámok pedig azt, hogy ezek sorrendben hogyan következnek egymás után. Hasonló módon felrajzolható a lökés és a menüutasítások végrehajtásának diagramja is. A rendszer architektúrájának felrajzolása is itt történik. A biliárdprogram három fő egységre osztható A kommunikációs modul feladata a felhasználó és a másik két egység közti kapcsolattartás. További két egységre bontható: az adatbeviteli és a megjelenítő egységre. A megjelenítő rész feladata a játék többi egysége által neki küldött információkat a képernyőn megjeleníteni. Tehát az ő felelőssége minden, a felhasználó irányába történő kommunikáció Az adatbeviteli rész felelőssége pedig, hogy a játékostól jövő inputot fogadja, majd kis mértékben feldolgozva tovább adja a Fizikai modellnek és a Szabálynak. Ezenkívül a üzenetekkel

tájékoztatja a megjelenítő részt az ehhez kapcsolódó kijelzési feladatokról A Fizikai modul feladata, hogy az asztalon mozgó golyók viselkedését irányítsa: az asztal széleinek, a lyukak helyének, és a golyók mozgását megszabó törvényeknek a modellezése. Közben üzenetekkel tájékoztatja az Asztalrajzoló osztályt (Kommunikációs modul) a megjelenítendő információkról. A Szabály felelőssége a játék menetének irányítása. Induláskor ő indítja el a többi rész inicializáló folyamatát Ismeri továbbá a biliárd szabályait, így vezérli a többi egység működését. Egyetlen, Szabály nevű osztályból áll A játék során folyamatosan tájékoztatja a Játékállás- kijelzőt a megjelenítendő információkról. A Szabály és az Adatbeviteli modul közötti adatáramlás kétirányú. Egyrészt a Szabály engedélyezi az Input interfészt, amikor inputot vár, másrészt a Menü utasítások feladatuk elvégzését a Szabálynak

üzenik meg. Az Asztal és az Adatbeviteli modul közötti kommunikáció azonban egyirányú. Ennek során a Lökéskezelő tájékoztatja az Asztalt a lökés végeredményéről. A szkeleton célja tehát az, hogy a fejlesztendő program moduljainak helyességbizonyítása. Mindezzel egyidőben annak tervezésére is sor kerülhet (és praktikusan kerül is), hogy mely osztálydefiníciókat milyen állományokban helyezünk majd el. Már a szkeletont is érdemes úgy felépíteni, hogy kövesse ezt a struktúrát, hogy ezáltal is átláthatóbbá tegyük a programot, és segítsük saját, jövőbeli munkánkat. A prototípus A prototípus program célja annak demonstrálása, hogy a program elkészült, helyesen működik, valamennyi feladatát teljesíti. A prototípus változat egy elkészült program – kivéve a kifejlett grafikus interfészt. A változat tervezési szempontból elkészült, az ütemezés, az aktív objektumok kezelése megoldott. Az objektumok - a

megjelenítésre vonatkozó részeket kivéve valamennyi metódusa a végleges algoritmusokat tartalmazza A megjelenítés és működtetés egy alfanumerikus ernyőn követhető, ugyanakkor a megjelenítés fájlban is logolható, ezzel megteremtve a rendszer tesztelésének lehetőségét. Különös figyelmet kell fordítani az interfész logikájára, felépítésére, valamint arra, hogy az mennyiben tükrözi és teszi láthatóvá a program működését, a beavatkozások hatásait. A Biliárd prototípusa működés közben A prototípus tehát továbbra is egy karaktergrafikus képernyővel rendelkező program. A fenti ábrán látható a biliárd prototípusa, amely egy három részre osztott képernyővel működik: baloldalon a felhasználó által elérhető funkciók láthatók, középen az asztal rajza a golyókkal, jobbra pedig a működés során változó paraméterek: az egyes golyók koordinátái és sebességvektora, valamint néhány egyéb információ. Ez a

dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 22 NetAcademia-tudástár A középső képernyőrészen látható zöld mező az asztalt modellezi. Négyféle golyó található rajta: fekete (k), fehér (f), csíkos (c), teli (t). A golyók mozgását a karakteker mozgása szemlélteti, természetesen durva kerekítéseket alkalmazva Az információs táblázatok a számítások során folyamatosan frissülnek. A golyók állapottáblájában lévő üres sorok azt jelentik, hogy az adott golyó már beleesett valamelyik lyukba, így nem vesz részt több a játékban. Természetesen a fehér golyó lyukba esését követően újra az asztalra kerül a kezdő pozícióba, a fekete eltűnése pedig a játék végét jelenti. A szkeletonhoz hasonlóan a prototípus is készít naplófájlt a meghívott függvényekről, az aktuális paramétereikkel együtt. Ezen kívül készül egy másik naplófájl is, amelybe

a golyók és a játék állapotának változásai kerülnek. A prototípus tartalmazza a végleges, valós program használati eseteit, ezen kívül különböző tesztelési use case-eket is. Ez utóbbiak olyan többletszolgáltatásokat kínálnak, amelyek a tesztelés során elengedhetetlenül szükségesek (golyók adatainak megadása, játék állapotába való belenyúlás). Valamennyi, a felhasználóval kommunikáló use-case két lehetséges módon kommunikálhat: interaktívan, a képernyőn keresztül, illetve a válaszokat egy, tesztadatokkal előre feltöltött config fájlból olvasva. A tesztelés a programfutás ellenőrzésének megkönnyítése. Többek között lehetőséget ad a golyók sebességének és helyzetének megadására, lehetővé teszi tetszőleges golyó levételét, feltételét, valamint ésszerű keretek között lehetőséget biztosít a szabály állapotainak megváltoztatására: utasíthatja, hogy a következő játékos kétszer jöjjön,

megadhatja, hogy a fekete golyót mely lyukba kelljen belőni, illetve, hogy a játékos a teli vagy a csíkos golyókkal legyen-e. A tesztfájlok beolvasását és értelmezését természetesen nekünk kell megvalósítanunk, a végleges programban nem szereplő use case-ek segítségével. Az állományokban található adatoknak megfelelően egyszerű szerkezetűnek kell lenniük a feldolgozás egyszerűsége érdekében, ugyanakkor kellően kifejezőnek ahhoz, hogy a sokrétű feladatnak megfeleljenek. Ehhez használhatunk saját formátumot (lásd alább), de sokkal célszerűbb valamilyen szabványos formátum, például az XML használata. Az ütközések tesztelésére szolgáló, saját formátumú konfigurációs állomány felépítése például: #Lokes tesztelese #Fenntrol elinditott feher golyo eppen beloki a #lyukba a csikosat Golyo megad #leszedjuk az alapbol fent levo golyokat Golyok le #az asztallal valo surlodasi #egyutthato:0.1, a rugalmassagi tenyezo:1 Surlodas

0.1 1 #felrakjuk a golyokat (sugaruk 5.0 egyseg) Golyo 0 feher 27.07 1500 0.0 00 Golyo 1 csikos 20.0 200 00 00 /Golyo megad Jatek #elinditjuk a tesztet Lokes -90 7 /Jatek Ugyanezen adatok beállítása XML-ben: <?xml version="1.0"?> <biliard> <config> <golyok le/> <surlodas>0.1</surlodas> <rugalmassag>1</rugalmassag> <golyo 0> <szin>feher</szin> <koordX>27.07</koordX> <koordY>150.0</koordY> <sebX>0.0</sebX> <sebY>0.0</sebY> <golyo 0> <golyo 1> <szin>csikos</szin> Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 23 NetAcademia-tudástár <koordX>20.07</koordX> <koordY>20.0</koordY> <sebX>0.0</sebX> <sebY>0.0</sebY> <golyo 0> <jatek> <lokes> <szog>-90</szog>

<erosseg>7</erosseg> </lokes> </jatek> </config> </biliard> A prototípus esetében három aktort különböztetünk meg, ebből kettő a végleges programban is szerepelni fog, egy pedig a prototípus sajátja. A Játékos és a Szabály szerepét korábban már definiáltam, az újonnan belépő szereplő a Tesztelő A Tesztelő a prototípus, és ezen keresztül a leendő program tesztelését végző külső személy, vagy más program. Utasításokat küld a tesztobjektumnak, ezekkel utasítva azt a játék menetében olyan módosítások végrehajtására, amikre egyébként nem lenne mód (lásd fentebb). A Biliárd prototípusának használati eset diagramja Természetesen ezekhez a tesztelésekhez előzetes tervet is kell készítenünk (már megint tervezés ). Ez azt jelenti, hogy definiálnunk kell, pontosan milyen eseteket szeretnénk végigpróbálni, milyen konfigurációs adatokkal stb. Például az ütközés tesztelése során

két golyóra lesz szükség. Az egyik álló helyzetben van, a másik egy adott kezdősebességgel nekikoccan. Vagy a képernyőre kiírt, vagy az output fájlban megkapott eredmények segítségével ellenőrizhetjük le, hogy az ütközés után a golyók helyes paraméterekkel indultak-e tovább. A többszörös tesztelés célja annak felmérése, hogy a program valóban determinisztikusan működik-e. Mivel a specifikáció során kikötöttük, hogy az egyes ütközésekben a véletlen nem játszik szerepet, ezért ugyanazt a lökést többször végrehajtva mindig ugyanazt az eredményt kell kapni. Ha mégsem egyeznének az eredmények, az például inicializálatlan változókra utalhat, amelyek így előre nem megállapítható értékeket vesznek fel a program futása során. Hogy ezek könnyebben felszínre kerüljenek, ez a tesztsorozat viszonylag hosszabb, bonyolultabb számolásokkal járó feladatokra utasítja a prototípust. A kifárasztásos tesztelés célja

megállapítani, hogy a program képes-e hosszú időn keresztül folyamatosan működni. A külső, tesztelő program olyan, kellően hosszú bemeneti adatokat állít elő, amely a program számára kellően sok műveletet jelent. Ezek a műveletek lehetőség szerint teszteljék a játék valamennyi használati esetét, nagyjából a valóságos felhasználásnak megfelelő eloszlásban. A programnak a teszt alatt nem szabad lefagynia, továbbá az általa felhasznált memóriának egy bizonyos korlát alatt kell maradnia (nem foglalhat le mindig újabb és újabb memóriát). A grafikus felület tervezése Az egyik utolsó lépés a végső program grafikus felületének tervezése és megvalósítása. Fontos, hogy az interfész felhasználóbarát, esztétikus és praktikus legyen. A biliárd grafikus osztályai: DakoRajz, MenuRajz, AllasRajz. Ezek felelőssége nyilvánvaló az elnevezésükből Példaként az állásrajzoló felépítését mutatom be: Ez a dokumentum a

NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 24 NetAcademia-tudástár A Biliárd állásrajzoló osztályának felépítése A játék állásáról tudósít: ki következik, kinek hány golyója van még, továbbá kétszer jön-e a következő játékos. Plusz lehetőségként hozzáadható még például a játékosok eredményességének nyilvántartása (a játék kezdetén a játékos egy felhasználói névvel bejelentkezik, majd a nyert/veszített játékok alapján a pontozást elmentjük). Az eddigiekhez hasonlóan itt is le kell írni a különböző grafikus osztályok, objektumok viselkedését szekvencia-, használati eset-, osztály- és egyéb, korábban említett diagramok segítségével. Ezzel elértünk a biliárd program tervezésének végéhez. Remélem, sikerült némi ízelítőt adnom a szisztematikus programtervezés módszereiről és az UML használatáról. A következő hónapokban a

modellezés, tervezés témát folytatva itthagyjuk a biliárdot, most már mindenki játszadozhat vele kedvére  Molnár Ágnes agnes.molnar@t-systemscom Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 25