Programming | UML » Bettenbuk István - Éttermi alkalmazás tervezése UML segítségével

Debreceni Egyetem Informatikai Kar Éttermi alkalmazás tervezése UML segítségével Témavezető: Készítette: Pánovics János Bettenbuk István számítástechnikai munkatárs programozó matematikus Debrecen 2006 Tartalomjegyzék Tartalomjegyzék Előszó . - 1 1 2. Bevezetés . - 2 11 A szakdolgozat célja, felépítése . - 2 - 1.2 Az egységesített modellező nyelv . - 2 - 1.21 Háttértörténet . - 2 - 1.22 Az UML . - 3 - Követelmények rögzítése . - 4 23 Áttekintés . - 4 - 2.4 Fogalomszótár . - 5 - 2.5 Használati esetek . - 6 - 2.51 Az aktorok . - 6 - 2.52 Az aktorok használati esetei . - 7 - 2.521 A Vendég használati esetei . - 7 - 2.522 A Vezető használati esetei . - 8 - 2.523 A Pincér használati esetei . - 8 - 2.524 A Pultos használati esetei . - 9 - 2.525 A Szakács használati esetei . - 9 - 2.53 2.531 A Szakács és a Pultos tevékenységeinek összefüggései . - 10 - 2.532 A Pincér és a Pultos

tevékenységének összefüggései . - 11 - 2.533 Az aktorok kapcsolatai . - 12 - 2.54 2.6 A használati eset diagramok összefüggései. - 10 - A használati eset diagram . - 12 - Követelmény elemzés szöveg dokumentumai . - 14 - 2.61 Alkalmazási példák . - 14 - 2.62 Forgatókönyvek . - 15 - 2.63 Működési leírások. - 17 - 2.64 Előzetes felhasználói leírás, felhasználói felületek . - 18 - 2.7 Csomagok, a rendszerek együttműködése. - 21 - 2.71 Az alkalmazás külső kapcsolatai . - 22 - 2.72 A külső kapcsolatok pontosítása . - 22 - 2.73 A rendeléskezelés csomag. - 23 i Tartalomjegyzék 3. Osztálydiagramok . - 24 38 Model-View-Controller tervezési sablon . - 24 - 3.81 Az MVC felépítése . - 24 - 3.82 A modell . - 25 - 3.83 A nézet . - 25 - 3.84 A vezérlő . - 26 - 3.85 Az MVC belső kapcsolatai . - 26 - 3.9 A modell. - 27 - 3.91 Módszerek az osztályok kialakításához. - 27 - 3.911 A RUP módszer. - 27 -

3.912 A Q módszer . - 28 - 3.913 A módszerek összehasonlítása . - 28 - 3.92 A Modell osztály . - 28 - 3.93 A Tárolandó interfész . - 30 - 3.94 A Halmaz osztály . - 30 - 3.95 A Tábla absztrakt osztály . - 32 - 3.96 Az Asztal osztály . - 33 - 3.961 Az Asztal osztály attribútumai. - 33 - 3.962 Az Asztal osztály metódusai . - 34 - 3.97 Az Alkalmazott és a Munkakör osztályok . - 34 - 3.98 A Menü és a kapcsolódó osztályok . - 35 - 3.99 A Rendelés osztály . - 37 - 3.910 4. 5. 6. A Számla osztály . - 40 - Interakció-diagramok . - 41 410 Az MVC szekvencia-diagramja . - 41 - 4.11 A rendeléskezelés szekvencia-diagramja . - 41 - Időben lezajló változások . - 44 512 A rendeléstétel rögzítés aktivitás-diagramja. - 44 - 5.13 A rendeléskezelés aktivitás-diagramja . - 44 - 5.14 A rendeléskezelés állapot-átmenet diagramja . - 45 - Összegzés . - 47 - Felhasznált irodalom . - 48 Melléklet - 49 - ii Előszó

Előszó A számítástechnikai tanulmányaim kezdetén a tervezést, szakterülettől függetlenül, felesleges procedúrának tartottam, melyhez valószínűleg a megoldandó problémák egyszerűsége vezetett. Gyakran ugyanis, már a probléma felvázolásakor, rögtön láttam a fejemben a megoldást. Természetesen sokszor tévedtem és csak másodszorra, esetleg harmadszorra, lett helyes eredményem. Ennek ellenére úgy gondolom, az adott problémáknál, a tervezésbe befektetett energia irreálisan magas lett volna – főleg ha figyelembe vesszük, hogy a t ervezéshez elsajátított, bevált módszertanom sem volt. A tervezés jelentőségét először a programozás során ismertem fel, mikor az úgynevezett „szép kód”-ot szándékoztam írni objektum orientált eszközzel (JAVA). A kis vázlatok, melyeket készítettem egy-egy problémához, gyakran órákat spóroltak, mivel nem kellett számtalanszor átírni a forráskódot a cél érdekében. A későbbiekben,

egy konkrét tervezési feladat során, felismerésem újabb megerősítést nyert. A költségtervező rendszer kialakításakor több okból is szükséges volt a tervezés. Egyrészt az áttekinthetőség indokolta, mely a rendszer nagyságából adódóan csak így volt biztosítható; másrészt, mivel többen vettünk részt a projektben, a feladatok tisztázásához elkerülhetetlenné vált; harmadrészt felhasználói igényként jelentkezett, hogy a rendszer könnyen fejleszthető legyen, illetve az ehhez szükséges dokumentációk rendelkezésre álljanak. Aktuális munkahelyemen szerzett tapasztalataim alapján már látom, hogy a tervezés előnye nem csak kódírás támogatásában van. A cél tisztázása legalább annyira fontos, az ügyfél kapcsolattartás során ugyanis visszatérő probléma a szakkifejezések eltérő értelmezése. A tanáraim ehhez kapcsolódó – általam akkoriban túlzottnak tartott – példái elevenedtek meg előttem, nemegyszer

jelentős többletmunkát okozva. Ma már úgy vélem, a tervezés egy befektetés, mely közép-, illetve hosszútávon garantáltan megtérül. -1- 1 Bevezetés 1. Bevezetés 1.1 A szakdolgozat célja, felépítése Dolgozatom elsődleges célja, hogy bemutassam a témát szolgáltató HarMónika elnevezésű – Elektronikus étteremi folyamatokat követő, nyilvántartó rendszer – alkalmazás elemzését, tervezését UML eszközök segítségével. Mindemellett törekedtem arra is, hogy az UML eszközök minél szélesebb palettája kerüljön ismertetésre, annak érdekében, hogy teljesebb képet alkothassunk az UML-ről. A szakdolgozat keretei nem teszik lehetővé, hogy egy alkalmazás teljes, mindenre kiterjedő, elemzését, tervezését ismertessem, így a dolgozat elkészítése során az alábbi koncepciókat követem: - A „Követelmények rögzítése” (2. pont) során elsődleges célom a közérthetőség, azaz egy laikus számára is egyértelmű,

áttekinthető legyen az alkalmazás célja, felépítése. Ennek érdekében nagyobb hangsúlyt kapott az UML fogalmainak, jeleinek magyarázata. - A dolgozat további részéiben az alkalmazás logikai összefüggései dominálnak, mely sokat segít az UML ábrák tisztázásban is. - A terjedelmesebb részeknél kiemelésre kerültek a kritikus pontok, és csak ezek leírása található meg a dolgozatban. Ez az adott pontoknál külön említésre kerül. 1.2 Az egységesített modellező nyelv 1.21 Háttértörténet Az objektumorientált koncepciók először különféle programozási nyelvekben jelentek meg, majd csak ezután alkalmazták a szemlélet a t ervezésben és végül az elemzésben. A kilencvenes évek közepére az objektumorientált technikák oly népszerűvé váltak, hogy sok csoport önálló jelöléseket, módszereket fejlesztett ki. Ez azonban – annak ellenére, hogy alapjaiban megegyeztek és gyakran csak minimális eltérések voltak –

megnehezítette ezek ipari méretű alkalmazását, így megjelent az igény az egységesítésre, szabványosításra. A három legnépszerűbb módszer -2- 1 Bevezetés megalkotója közös jelölésrendszert alakított ki, melyet Egységesített Modellező Nyelvnek nevezetek el, angolul Unified Modelling Language (UML). 1.22 Az UML Az UML jellemzői: - Az objektumorientált szemléletre épülő elemzés és tervezés eszköze, mely kiterjedt eszközkészlettel rendelkezik az OO koncepciók jelölésére. - Jogilag is szabványos jelölésrendszer. - Alapvetően grafikus nyelv, azaz a modellt különböző diagramok segítségével ábrázolja. - Modellező nyelv: - „modellező”, mivel segítségével csak alkalmazás vázlata készíthető el, a teljes implementáció nem - „nyelv” mivel a jelölőrendszere modellek ábrázolására szolgál, azaz módszertant nem ad. -3- 2 Követelmények rögzítése 2. Követelmények rögzítése 2.3 Áttekintés A

fejlesztés kiindulópontja, egy vázlatos terv, melyben összefoglalásra kerülnek az alkalmazás céljai, víziói, továbbá leírásra kerülnek az alap szituációk, illetve bemutatásra kerül a környezet is. HarMónika – Elektronikus étteremi folyamatokat követő, nyilvántartó rendszer A HarMónika rendszerrel nyomon követhetők az éttermi folyamatok. Segítségével egyrészt a vezető, kategóriákba sorolva, rögzítheti az éttermében értékesíthető ételeket, italokat és egyéb cikkeket, másrészt lehetőség válik arra, hogy a szakácsok, pultosok jelezzék az esetleges hiányokat. Végig követhető a vendégek teljes kiszolgálási folyamata, a rendelésfelvételtől a kifizetésig, majd ezt követően az alkalmazottak elszámoltatása. A tárolt adatok alapján különböző kimutatásokat kérhet a vezető, melynek segítségével, stratégiai célok megvalósításához nélkülözhetetlen információkhoz juthat. Így a pincér, kézi számítógép

használatával, a rendszer alkalmazásával kiválaszthatja – a vezető által előre rögzített kínálatból - a vendégek rendelési igényeit. Ezt követően a rögzített rendelési igények, kategóriától függően, továbbíthatóak a szakácsok (ételkategória), vagy a pultosok (italkategória) számára. A szakácsok (pultosok), a pincérek által felvett rendelések alapján, elkészítik az ételeket (előkészítik az italokat), majd felszolgálási egységenként értesítik erről a pincért. A pincér azonnal jelzést kap a rendszertől, hogy a rendelések felszolgálásra várnak, melynek következtében elindulhat a konyhába (pulthoz), hogy felszolgálja az ételeket (italokat). A pultosok, a pincérek által felvett ital rendelések készítésén kívül, a pultnál italrendelést leadó vendégek kiszolgálását is elláthatják. A vendégeknek, asztalonként egy mozdulattal, a f elvett rendelések alapján számla készíthető akár forintban, akár

euróban. A rendszer az egyes fizetéseket követően rögzíti, hogy melyik pincért kell az aktuális tétellel elszámoltatni. Mindehhez rendelkezésre áll a vezető számára egy tevékenység színtű jogosultsági rendszer, melynek segítségével kezében tarthatja az irányítást a r endszer, illetve a t árolt adatok felett. A rendszer ideiglenesen az összes adatot eltárolja – rendkívüli helyzetekre való tekintettel –, melyek egy rendelés folyamat zárását követően, részben törlésre kerülnek. Azonban a számlázas adatai végleg archiválódnak, egyrészt a törvényi előírások végett, másrészt pedig az adatok utólagos elemzéséhez – ennek megvalósíthatósága érdekében, a adott számlához, annak kötelező tartalmi elemeinél jóval több adat kerül eltárolásra. -4- 2 Követelmények rögzítése 2.4 Fogalomszótár Az alkalmazás fejlesztése során használt elnevezések, rövidített elnevezések és a kapcsolódó értelmezések

összessége – mely az egyértelműséghez, tisztánlátáshoz elengedhetetlen. A továbbiakban az alábbi fogalmak a szótárnak megfelelően kerülnek alkalmazásra. Aktuális információk: Árazás: Asztalnál történő rendelés: Értesítés: Ételkészítés: Ételrendelés: Étel: Ételfogyás jelzés: Felszolgálás: Fizetés: Fogyásjelzés: Időszaki információk: Ital összekészítés: Italrendelés felvétel: Italrendelés: Ital: Italfogyás jelzése: Kiszolgálás: Lekérdezés: Menü nyomtatás: Pénzbeszedés: Pincér értesítés Pultnál történő rendelés: Pultos rendelés számlázása Pultos számla pénzbeszedése: Rendelésfelvétel: Rendelésfelvételről értesítés: Rendelés leadás: Rendelés összekészítés: Számla stornózás: Számlázás: Tálca: Törzsadatok kezelése Zárás: Azon adatok halmaza, melyet a rendszer nem véglegesen tárol, elsődlegesen a napi rendeléseket tartalmazza (ezek zárást követően törlődnek) Ételek, italok

árának beállítása, aktualizálása. Rendelés leadás egyik változata, mikor a Vendég az asztalnál a pincérnek adja le rendelési igényeit. Információ továbbítás az illetékes felhasználónak. Szakács azon tevékenysége, mikor ételrendeléseket felszolgálható állapotba hozza Rendelések azon csoportja, amikor ételt rendelnek (csak asztalnál tehető). Szakács készíti, egyéb tekintetben megfelel az általános használatnak. Szakács által adott jelzés, azon ételekről, amelyek nem készíthetők el, mert pl.: elfogyott az alapanyag. Pincér azon tevékenysége, mikor a rendeléseket kiviszi a Vendégeknek. A Pénzbeszedés fogalmának megközelítése a Vendég oldaláról. Az Ételfogyás jelzés és az Italfogyás jelzés összefoglaló tevékenysége Azon adatok halmaza, melyeket a rendszer elsődlegesen háttértáron tárol, idetartoznak a számlák és az azokhoz kapcsolt adatok. Pultos azon tevékenysége, mikor a V endégek által leadott

italrendeléseket felszolgálható, kiszolgálható állapotba hoz. Rendelésfelvétel speciális változata, mikor csak Italrendelés kerül rögzítésre (a Pultos csak ilyet tud). Rendelések azon csoportja, amikor italt rendelnek. Tágabb értelembe van használatba, mint az ál talános fogalom. Magában foglalja azokat a cikkeket is, amelyek a pultnál találhatók, így pl.: mogyoró, dohányáruk stb Pultos jelzése azon italokról, amelyek nem állnak rendelkezésre pl.: kifogyott A Felszolgálás speciális esete, mikor a Pultos a Vendéget közvetlenül szolgálja ki. A rendelkezésre álló adatokból, a megadott feltételeknek megfelelő, listák készítése. Az összeállított Menü nyomtatását illetve exportálását takarja. Ennek segítségével készülhet árlap, itallap a Vendégek részére A Vendégektől a kiállított számla ellenértékének átvétele. Az Értesítés speciális esete, mikor a célfelhasználó a Pincér Rendelés leadás egyik

változata, mikor a V endég a p ultnál a p ultosnak adja le rendelési igényeit (kizárólag ital) Számlázás speciális esete, mikor a Pultnál történt rendeléseket számlázza ki a Pultos. Pénz beszedés speciális esete, a Pultnál történt rendelések ellenértéke kerül rendezésre. A Rendelés leadás rögzítése a rendszerbe Az értesítés speciális esete, mikor a Pincér értesíti az illetékes felhasználót. Azon folyamat mely során a Vendég elmondja igényeit a Pincérnek, Pultosnak Az ételkészítés és az Ital összekészítés összefoglaló tevékenysége. Elkészült számla hivatalos formájú törlése. Vendég részére számlakészítés, melynek alapja a rendszerben rögzített rendelések. Rendeléstételek csoportja, melyeket egyszerre kell felszolgálni (pl.: rántott sajt, vegyes körettel, savanyusággal) – csak ételeket vagy italokat tartalmazhat. Az ételek, italok, valamint a kapcsolódó csoportosítások, adatok rögzítését,

naprahozását takarja a cselekvés. Adott nap forgalmának lezárása, mely magába foglalja a Pincérek, Pultosok pénzügyi elszámoltatását is. -5- 2 Követelmények rögzítése 2.5 Használati esetek 2.51 Az aktorok A rendszer határain kívül eső külső elemek, melyek közvetetten vagy közvetlenül kapcsolódnak az alkalmazáshoz. Az aktorokba nem csak a rendszert használó emberek, hanem a külső rendszerek, háttértárak is bele tartoznak. (Ez utóbbi csoportba, a HarMónika alkalmazáson belül, csak az Archívum tartozik.) 1. ábra -6- 2 Követelmények rögzítése 2.52 Az aktorok használati esetei A használati esetek technikájával összegyűjthetjük és áttekinthetjük az alkalmazással szemben támasztott legfontosabb követelményeket. Első lépésben az aktorok különkülön kerülnek bemutatásra, így láthatók azon tevékenységek, funkciók, melyeken keresztül – közvetetten vagy közvetlenül – kapcsolódnak az alkalmazáshoz.

Ezáltal sokkal pontosabb kép alkotható az aktorok szerepköréről. A használati eset diagramokon, mely az UML egyik diagramtípusa, folyamatos nyilak jelölik a k apcsolatokat, ahol a nyíl mutatja meg az információáramlás irányát. A szaggatott nyilak jelöléstől függően, más-más sztereotípiát jelölnek: - extend : változatot, speciális esetet jelöl, ahol a nyíl az általánosból, a fő esetre, funkcióra mutat - 2.521 include: részfunkciót jelöl, a nyíl a főfunkcióra mutat A Vendég használati esetei 2. ábra -7- 2 Követelmények rögzítése 2.522 A Vezető használati esetei 3. ábra 2.523 A Pincér használati esetei 4. ábra -8- 2 Követelmények rögzítése 2.524 A Pultos használati esetei 5. ábra 2.525 A Szakács használati esetei 6. ábra -9- 2 Követelmények rögzítése 2.53 A használati eset diagramok összefüggései Az ábrák, tevékenységek vizsgálata során több összefüggést is

észrevehetünk, melyeket célszerű megvizsgálni, annak érdekében, hogy az összefüggő használati eset (Use Case) diagram áttekinthetőbb legyen. 2.531 A Szakács és a Pultos tevékenységeinek összefüggései A Szakács által végzett ételkészítés és Pultos végzett ital összekészítés, az alkalmazás szempontjából ugyanaz a m unkafolyamat (megegyezik a s zerepe és tartalmazott tevékenységeik is). Vonjuk össze a két tevékenységet és vezessük be a „rendelés összekészítés”-t. Ugyan ez vonatkozik az étel-, italfogyás-jelzésre is melyek helyett vezessük be a „fogyásjelzés”-t. 7. ábra - 10 - 2 Követelmények rögzítése 2.532 A Pincér és a Pultos tevékenységének összefüggései A Vendég szempontjából két eshetőség létezik, vagy rendel az asztalnál a Pincértől, vagy a pultnál a Pultostól. Ebből a szempontból gyakorlatilag ugyanazt csinálják, annyi különbséggel, hogy a P ultos a pul t mögött szolgál

ki és csak italokat lehet rendelni tőle. Ezt kihasználva a Pultos tevékenységeit a Pincér tevékenységeinek speciális eseteinek tekinthetjük. 8. ábra - 11 - 2 Követelmények rögzítése 2.533 Az aktorok kapcsolatai A használati esetek összefüggéseit követve a Pultost, tevékenységei alapján, részben Szakácsként, részben Pincérként kezelhetjük. 9. ábra 2.54 A használati eset diagram A használati eset diagram (Use Case Diagram) alapvető fontosságú a követelmények elemzésében, segítségükkel rajzolhatjuk meg a r endszer határait, azaz milyen funkciók kerüljenek be a kifejlesztendő alkalmazásba, illetve melyek ne. A követelmények összegyűjtése során csak olyan használati eseteteket veszünk bele a diagramba, amely a felhasználók által is látható értelmezhető, így nem tartalmazza a megvalósítással kapcsolatos technikai részleteket. A HarMónika alkalmazás következő használati eset diagramjának kialakítása

során felhasználásra kerültek, az előző pontokban bemutatott, használati eset összefüggések, melynek eredményeképpen egy tömörebb, könnyebben átlátható ábrát kapunk. - 12 - 2 Követelmények rögzítése 10. ábra - 13 - 2 Követelmények rögzítése 2.6 Követelmény elemzés szöveg dokumentumai A továbbiakban leírásra kerülő szöveges dokumentumok célja, hogy segítségükkel részletesebb képet alkothassunk a fejlesztendő alkalmazásról, valamint konkrét formába öntsük az alkalmazással szembe támasztott igényeinket. A leírásokban az alábbi metodikát alkalmazzuk: • Az aktorok nagybetűvel kezdődnek, valamint dőltbetűvel, • míg a használati eset diagramokon is fellelhető tevékenységek, funkciók aláhúzva kerülnek kiírásra. 2.61 Alkalmazási példák Az alkalmazási példák, a szöveges dokumentáció azon részei, amelyek a használati esetek alkalmazásainak menetét mutatják meg, a felhasználói

célok eléréséhez. A Vendég rendelésének felvétele asztalnál, a rendelt étel, ital elkészítése, felszolgálás, számlakészítés, archiválás, pénzügyi rendezés: • A Vendég leadja a rendelését. • A Pincér a teljesíthető rendeléseket felveszi, majd a rögzítést követően értesítést küld, a rendelés kategóriájától függően, a Pultosnak, vagy a Szakácsnak. o Amennyiben valamely rendelés nem teljesíthető, a Pincér tájékoztatja a Vendéget (pl.: elfogyott) • Rendeléstől függően: o Az italrendelések a Pultoshoz futnak be, aki a rendelkezésre álló információk alapján összekészíti az italokat, ezt követően értesítést küld a Pincérnek.  Amennyiben valamely termék kifogyott a Pultos értesíti a Pincért, hogy mely ital fogyott ki. o Az ételrendelések a Szakácshoz futnak be, aki a rendelkezésre álló információk alapján elkészíti az ételeket, ezt követően felszolgálási egységenként értesítést küld a

Pincérnek.  Amennyiben valamely alapanyag elfogy – ezáltal valamely étel nem készíthető el - a Szakács értesíti a Pincért, hogy mely étel nem készíthető el (ételfogyás). • A Pincér a Pultos, Szakács értesítése követően felszolgálja a rendeléseket a Vendégnek. • Fogyasztást követően, illetve mikor a Vendég kéri a számlát, az asztal rendelése alapján, a Pincér kiállítja a számlát (számlázás), mely ezzel egyidejűleg az Archívumba kerül. o Amennyiben a számla hibás, Pincér stornózza a számlát. • A Vendég a számla alapján kifizeti az ellenértéket, melyet a Pincér vesz át (pénzbeszedés). - 14 - 2 Követelmények rögzítése A Vendég rendelésének felvétele pultnál, a rendelt ital elkészítése, felszolgálás, számlakészítés, archiválás, pénzügyi rendezés: • A Vendég leadja a rendelését. • A Pultos a teljesíthető italrendeléseket felveszi. o Amennyiben valamely rendelés nem teljesíthető,

a Pultos tájékoztatja a Vendéget (pl.: elfogyott) o Amennyiben ételt rendel a Vendég, egy asztalhoz küldi. • A felvett rendelés alapján összekészíti az italokat. o Amennyiben valamely termék kifogyott a Pultos értesíti a Pincért, hogy mely ital fogyott ki. • A Pultos felszolgálja a rendeléseket a Vendégnek. • Fogyasztást követően, illetve mikor a Vendég kéri a számlát, az asztal rendelése alapján, a Pultos kiállítja a számlát (számlázás), mely ezzel egyidejűleg az Archívumba kerül. o Amennyiben a számla hibás, Pultos stornózza a számlát. • A Vendég a számla alapján kifizeti az ellenértéket, melyet a Pultos vesz át (pénz beszedés). 2.62 Forgatókönyvek A forgatókönyvek, a s zöveges dokumentáció azon részei, amelyek megmutatják, az egyes használati esetek funkció elemeinek időbeli egymásutániságát. Jellemzően felhasználói interakciók határozzák meg. A Vezető aktualizálja az árakat (árazás): • A Vezető

kiválasztja „Árak” menüpontot • Megjelennek az aktuális ételek, italok • Kiválasztva az átárazandó tételt, megjelenik az árazó ablak • Kategóriánként beállítja az aktuális forint illetve euró árat A Szakács, Pultos bejelöli az ideiglenesen nem rendelhető tételeket, illetve kiveszi ebből a státuszból (fogyásjelzés): • A Szakács, Pultos eléri a „menü” listakezelőt • Megjelennek az aktuális ételek, italok (az ideiglenesen nem rendelhetők is) • Kiválasztja az étintett tételt • „Fogyás” gomb segítségével: o ideiglenesen nem rendelhetővé teszi, ha most rendelhető o rendelhetővé állítja, ha ideiglenesen nem rendelhető - 15 - 2 Követelmények rögzítése A Pincér, Pultos felveszi a rendelést: • A Pincér, Pultos eléri a tevékenységeit kezelő felületet (ezek az alapértelmezettek) • A Pincér (Pultos) kiválasztja melyik asztal (pult) rendelését rögzíti • Kiválasztja, hogy étel vagy ital

kategóriájú rendelést szeretne felvenni (a Pultos kizárólag ital kategóriát tud) (Gyakorlatilag egyszerre egy személyre felszolgálandó egység, kvázi a tálca fogalom) • Kiválasztja a megfelelő alkategóriát (tálca részletezés) • Megjelennek az alkategóriának megfelelő tételek • Kiválasztja miből, milyen kiszerelésben, mennyit rendeltek • Lezárja a rendeléstételt: o Alkategória kijelöléssel újabb tételt rögzíthet (tálcára) o Kategória választással új tálcát rögzíthet o Rendelés gombbal lezárja az asztal aktuális rendelését (nem végleg) A Szakács, Pultos, össze(el)készíti a felvett rendelést majd értesíti a Pincért: • A Szakács, Pultos eléri a tevékenységeit kezelő felületet (ezek az alapértelmezettek) • Megjelennek a felvett rendelések asztalonkénti (pultonkénti) bontásban, tálca csoportosításban o Lehetőség van a következő elkészítendő rendelés megajánlására (rendelés felvétel ideje

alapján) • A Szakács (Pincér) elkészíti (összekészti) az ételt, majd átteszi az elkészültek közé • Felszolgálandó egységenként értesítést küld a rendelést felvett Pincérnek A Pincér értesítést fogad (felszolgálás): • Az üzenet fogadó gomb kiírja, hány nem kezelt üzenete van • A gombra klikkelve megjelenik a legrégebben kapott nem kezelt üzenet • Körülményeknek megfelelően kezeli az üzenetet: o Tájékoztató jelegűnél (pl.: elfogyott valami), csak az „OK” lehetséges (azaz már nem jelenik meg többet az üzenet) o Felszolgáláshoz kapcsolódónál két lehetőség van:  Felszolgálva (nem jelenik meg többet az üzenet)  Később (azaz annak ellenére, hogy foglalkozott vele nem kezelt állapotban marad) A Pincér, Pultos elkészíti a számlát (számlázás): • A Pincér, Pultos eléri a tevékenységeit kezelő felületet (ezek az alapértelmezettek) • A Pincér (Pultos) kiválasztja melyik asztalnak (pultnak)

akar számlát készíteni • A számlázó gomb segítségével elkészíti a számlát o Amennyiben nem lett minden felszolgálva jelzést kap a Pincér (Pultos) - 16 - 2 Követelmények rögzítése Az illetékes aktor számlát stornóz: • Kiválasztja a „számla” menüpontot • Kiválasztja a stornózandó számlát • A Stornó gomb segítségével stornózza a számlát o Van lehetősége a korrigált számla készítésére (aktualizált számlafej adatokkal) A Pincér, Pultos átveszi a pénzt (pénz beszedés) • A Pincér, Pultos eléri a tevékenységeit kezelő felületet (ezek az alapértelmezettek) • A Pincér (Pultos) kiválasztja melyik asztalnál (pultnál) szedi be pénzt • A pénz gomb segítségével jelzi, hogy átvette a pénzt A Vezető adatokat kér le (lekérdezés): • Kiválasztja a megfelelő lekérdezést • Beállítja a lehetséges szűkítő feltételeket • Megjelennek a szükséges adatok melyet: o Kinyomtathat o Excelbe

exportálhat o Text formátumú fájlba exportálhat 2.63 Működési leírások A működési leírások azokat a használati eseteket mutatják be, melyek viszonylag kevés interakcióra, ugyanakkor több és összetettebb tevékenységsorozatra épülnek. A Vezető elvégzi a napi zárást: • Sorra veszi a felvett rendeléseket o A nem befejezett rendeléseket (nem kerültek kifizetésre) felgyűjti egy listába o A Vezető minden rendelést kézzel megfelelő befejezett állapotba állít a körülményeknek megfelelően:  kifizetésre került • Amennyiben nincs hozzákapcsolódó számla, akkor automatikusan elkészül a számla  technikai befejezés • Összesítést készít a napról, mely alapján elszámoltathatóak a pénzt beszedő alkalmazottak (Pincér, Pultos) • Törli az összes rendeléssel kapcsolatos adatot - 17 - 2 Követelmények rögzítése 2.64 Előzetes felhasználói leírás, felhasználói felületek Mint már a bevezetőben is

említésre került, a szakdolgozat keretei nem teszik lehetővé, hogy minden területen teljes részletességgel bemutatásra kerüljön az alkalmazás tervezése. Ezáltal csak az alkalmazás egyik kritikus felülete, kezelése – a pincérek kézi számítógépre tervezett felülete – kerül nagyító alá. (A mellékletben az alkalmazás további tervezett felületei megtekinthetők.) A pincér funkciók A pincérek kézi számítógépén megjelenő felület az 1. képen látható, melynek segítségével a standard tevékenységeit maximálisan el tudja látni. 1. kép A felület alapvetően két részből áll, a felső – információs – részben az egyes asztalok által leadott rendelések találhatók (az asztalok száma és neve mobilan állítható), míg az alsó részben a gyors funkció gombok találhatók, melyek minden esetben az aktuális asztalhoz kapcsolódóan funkcionálnak. - 18 - 2 Követelmények rögzítése Információs rész felépítése:

• • • • A felső sorban kiválaszthatjuk, melyik asztallal kívánunk foglalkozni (a képen az „Asztal 2” az aktív). A táblázatos rész felett található gombok segítségével különböző gyors szűrésekre van lehetőség, természetesen csoportosan is alkalmazható: o Étel: csak az ételrendelések láthatók a listában o Ital: csak az italrendelések láthatók a listában o Rendelt: még nem összekészített rendelések o Elkészült: még nem felszolgált, de már összekészített rendelések o Felszolg.: már felszolgált rendelések A táblázatban soronként egy rendelés csoport található – étel esetében egy az egyben megfelel a tálca fogalmának. (pl: rántott sajt; hasáb burgonya; savanyú káposzta). Amennyiben a kurzorral ráállunk egy sorra, megjelenik egy buborék, melyben részletesen látszanak a tételek – miből, mennyit, milyen kiszerelésben. Az alsó részben, a közvetlenül a táblázat alatt további gombok találhatók,

melyek a már rögzített rendelések kezelésére szolgálnak: o Törlés: Az aktuális sor, azaz egy rögzített tálca törölhető – természetesen csak abban az esetben, ha még nem lett átküldve a s zakácsnak vagy a pultosnak. o Másolás: Az aktuális tálca másolható egy az egyben, amennyiben korrigálásra lenne szükség a Módosít gombot is meg kell nyomni (nem kell kikeresni, automatikusan a másolt tálca lesz az aktív). o Módosítás: Az aktuális tálca összetétele módosítható – természetesen csak abban az esetben, ha még nem lett átküldve a szakácsnak vagy a pultosnak. Részletesebben lásd az új étel, ital rögzítése alatt. Funkció gombok: • • • Tányér: Új ételek (tálca) rögzítésének kezdése – részletesebben lásd az új étel, ital rögzítése alatt. Ital: Új italok (tálca) rögzítésének kezdése – részletesebben lásd az új étel, ital rögzítése alatt. Ital esetében is tálcát rögzítünk (általában

jobban megfelel a pohár), jelentősége extra kérések esetében van (pl.: 0,5 dl whisky; 1 dl szódával), ha az nincs külön rögzítve a rendszerben. Pincér: Nem pontos a jelölés, ugyanis ez az ikon dinamikusan változik, az alábbi változatok vannak: o Pincér: A rendelések végelegesítése, azaz alkalmazása esetén a rendelések elküldésre kerülnek a szákácshoz, pincérhez. Csak abban az esetben látható, ha van olyan tétel, amely nem került továbbításra. o Számla: Számla készíthető az asztal számára. Akkor érhető el, ha minden tétel fel lett szolgálva, de még nincs számlázva. o Fizetés: A számlázást követően áll át, ezt követően az asztal rendelései már nem érhetők el, csak lekérdezéssel (zárásig). o Szem: Új rögzítés esetén (lásd lentebb), ennek segítségével térhetünk vissza az 1-es ábrához. Így van lehetőség esetleges egyeztetésre korrekcióra, egyebekre. - 19 - 2 Követelmények rögzítése •

Üzenet: Amennyiben a pincér üzeneteket kap, e g omb segítségével kezelheti azokat. A gombon található szám jelzi, mennyi a még fel nem dolgozott üzenet Mindig időrendi sorrendben dobja fel az üzeneteket, amelyek üzenet típusától függően kezelhetők: o Tájékoztató jellegű üzenet: A feldobott üzenet csak leOKézható, azaz csak egyszer olvasható a pincér számára – ilyen a fogyásjelzés. o Felszolgálást jelző üzenet: A pincér elfoglaltságától függően választhat két gomb közül:  Felszolgálva (nem jelenik meg többet az üzenet), ekkor a r endelt tételek státusza is átáll felszolgáltra.  Később (azaz annak ellenére, hogy foglalkozott vele továbbra is nem kezelt állapotban marad) Új rendelés tételek (tálca) rögzítése, módosítása: 2. kép Minden esetben a 2. képen látható felületre tér át a rendszer, azaz az előzőek során bemutatott információs rész megváltozik, de funkció gombok továbbra is az ott

leírtak szerint működnek. (Ebben a funkcióban nincs lehetőség asztalváltásra) - 20 - 2 Követelmények rögzítése A felső részben található a tálcára rögzített tételek, három gomb támogatásával: o +;-: A gombok segítségével a mennyiség változtatható, melynek alapértéke 1. (Egyben ez a legkisebb érték ami felvehető) o Törlés: Egy rögzített tétel rögzíthető a tálcára. • A középső rész jobb oldalán az italok, ételek alkategóriái látszanak, attól függően milyen kategóriájú tálcát rögzítünk, módosítunk. A kategóriák dinamikusan szerkeszthetők (minimum kétszintűt érdemes alkalmazni). A 2 képen étel típusú tálcát rögzítünk, és a p incér választhat halak, köretek, szárnyasok alkategóriák közül. A panel alsó sarkában egy állandó gomb található, mellyel egy szinttel vissza léphetünk a kategóriákban – jelenleg inaktív, mivel ez az első kategória. • A középső rész baloldalán az

aktuális kategóriának megfelelő menük közül választható a rögzítendő tétel. A rendszer nem kínálja fel azokat a tételeket, amelyek ideiglenesen nem rendelhetők – a pultos megjelölte, hogy elfogyott. • Az alsó részben a rendelésrögzítéshez kapcsolódó gombok segítik a pincért: o Kiszerelés: A rendszer az alapértelmezett kiszerelést ajánlja fel a rendelés tételekhez, ha ez nem megfelelő a pincér a gomb használatával megkapja egy listán a l ehetséges kiszereléseket, melyek közül a v endég igényei szerint választhat. o Segítség: Az aktuális menünek a leírása jeleníthető meg vele, így szükség esetén teljes körűen tájékoztatható a vendég. o OK: Felrögzíti a rendelési tételt alapértelmezett kiszerelésben a tálcára. Az alsó funkció gombok mindegyike rögzíti a tálca tételeit. Új tálca rögzítése esetén üresen kapjuk meg a felületet, míg módosítás esetén a már rögzített tételek a „tételek” nevű

táblában megjelennek. • 2.7 Csomagok, a rendszerek együttműködése A csomagok segítségével – jele egy címkézett téglalap – a modellünk szorosabban összetartozó elemeit magasabb színtű egységekbe csoportosíthatjuk, eredményeképp áttekinthetőbb, könnyebben kezelhetők a korábbiakban bemutatásra került ábrák, leírások – elsődleges jelentősége a tervezés további fázisaiban dominál. A csomagok kialakításához elsődlegesen a 2.34 pontban található Use Case Diagram (10. ábra) szolgált alapul Egyes módszertanok – például a Q modellező módszer – az UML megszokott használatától eltérve, de a szabvány keretein belül, további kiegészítéseket ajánl, melynek segítségével jól vázolható a rendszerek együttműködése. Az ábrákon a csomagok mellett, azok külső rendszerekkel, aktorokkal fennálló kapcsolódásai is bemutatásra kerülnek, majd a csomagok részletezésével együtt ezek - 21 - 2

Követelmények rögzítése is pontosodnak. Az eddigi sztereotípiák kiegészülnek egy request sztereotípiával, mely a közvetett és megszakítás jellegű vezérléseket jelzi. 2.71 Az alkalmazás külső kapcsolatai 11. ábra 2.72 A külső kapcsolatok pontosítása 12. ábra - 22 - 2 Követelmények rögzítése Érdemes külön figyelmet szentelni az Archívumnak. Látható, hogy a rendszer belső csomagjainak megjelenése ellenére, az azokkal történő kapcsolat mellett továbbra is fenntartja az egész rendszerrel a kapcsolatot. Erre szükség van, mivel – az áttekintés alapján – a váratlan helyzetekre is fel kell készíteni a rendszert. Így minden adat – ha csak ideiglenesen is – tárolásra kerül, és rendkívüli esetben visszaállíthatók az adatok. 2.73 A rendeléskezelés csomag 13. ábra - 23 - 3 Osztálydiagramok 3. Osztálydiagramok Objektumorientált modellek esetén, alapvető jelentőségűek az alkalmazás strukturális

szerkezetét leíró osztálydiagramok, melyeken osztályokat, illetve a köztük lévő viszonyokat ábrázolják. A szemlélet alapja, hogy a valóság fogalmait osztályokként modellezi, melyeket attribútumokkal (egy objektumra vonatkozó értékjellegű adatok), műveletekkel (az osztályra vonatkozó viselkedés) határoz meg. 3.8 Model-View-Controller tervezési sablon Az alkalmazás lelke a Modell-View-Controller (MVC) tervezési sablon, megfelel az összes olyan igénynek, amely szükséges egy optimális alkalmazáshoz: - egységes üzleti logika betartása, függetlenül attól ki, hogyan éri el a rendszert - több fajta megjelenítési lehetőség (a pincérek kézi számítógépen keresztül érik el a rendszert) - fejlesztési idő minimalizálás (legrégebben elterjedt, legismertebb tervezési sablonok egyike) - hibakeresési idő minimalizálás (felépítéséből adódóan jónak számít) - a javítás egyszerű kivitelezése (egy hibát egy helyen kell

módosítani) A sablon alkalmazásával elkülöníthető a rendszer adatainak modellezése az üzleti logikától, és az adatok megjelenítéstől. Miután a s ablonnal és a r észleteivel több tanulmány is foglalkozik, valamint sok kapcsolódó anyag található az interneten, így a szakdolgozatban a részletezésétől eltekintek, csak alapjaiban kerülnek bemutatásra. 3.81 Az MVC felépítése A sablon struktúrája – amire az elnevezés is utal – három fő pillérből áll: a modellből, a nézetből és a vezérlőből. - 24 - 3 Osztálydiagramok Modell - Reprezentálja az alkalmazás állapotát - Kiszolgálja az állapotlekérdezéseket - Üzleti logikának megfelelően módosítja az állapotot - Értesíti a nézeteket a változásokról - Nézet Megjeleníti a modell bizonyos állapotát Értesítést vár a modell megváltozásáról Felhasználó bemenetet küld a vezérlőnek Lehetőséget biztosít a vezérlőnek, hogy nézetet választhasson

Vezérlő - Definiálja az alkalmazás munkamenetét - A felhasználói utasításokat hozzárendeli a modell üzleti metódusához - Kiválasztja a válasz nézetet Metódushívás Események 3.82 A modell A modell (model) reprezentálja az alkalmazás adatainak modellezését, és az adatok kezelését meghatározó üzleti logikát. Általában valamilyen valóságos folyamat modellezésén alapul a hármas modell pillére, ezért alkalmazhatók a v alóságos folyamatmodellezésnél alkalmazott technológiák. 3.83 A nézet A nézet (view) feladata a modellben tárolt, modellből elérhető adatok, illetve azok egy részének, egy jól specifikált módon történő megjelenítése. További feladata, hogy fenntartsa a k onzisztenciát a m odellben tárolt és a néz etben megjelenített adatok között, azaz amint megváltozik valamilyen adat a modellben, a nézetnek frissíteni kell a megjelenített adatokat. Ennek megvalósítására két lehetőség van: - Push model:

lényege az, hogy a nézet regisztrálja magát a modellnél, ami értesíti a regisztrált nézeteket az állapotváltozásról. - Pull model: abból áll, hogy a n ézet kéri le a modell állapotának aktuális helyzetét, amikor frissíteni kell a megjelenítést. - 25 - 3 Osztálydiagramok 3.84 A vezérlő A vezérlő (controller) alakítja át a nézetből érkező felhasználói bemenetet a modell által végrehajtandó parancsokká. Egy kliens oldali alkalmazásnál ez lehet egy kattintás egy gombon, webes alkalmazásnál pedig egy kérés. 3.85 Az MVC belső kapcsolatai Az MVC tervezési sablon többet jelent, mint az alkalmazás osztályainak csoportosítási szempontja, mivel definiálja a pillérek közötti kapcsolatokat is. Az ábrán látható, hogy a nézet és a vezérlő közvetlen kapcsolatban áll a modellel, például mindkettő egy osztály attribútumon keresztül képes elérni a modellt. A szoros kapcsolat lényeges, mivel mindkét pillér igényli a

m odell jelenlétét. (A vezérlő a klienstől érkező bementek alapján módosítja a modellben tárolt adatokat, míg a nézet a modellben tárolt adatok egy részét jeleníti meg.) A vezérlő és a nézet nem képes tehát működni a modell nélkül. A vezérlővel és a nézettel ellentétben a modell teljesen önálló egységet alkot. Nem igényel semmilyen kommunikációt, csak lehetőséget biztosít más objektumoknak a tárolt adatok elérésére, módosítására. Alapvetően kétféle modell lehet: - Passzív modell: a nézet sosem kap értesítést arról, hogy a modellben változtak az adatok, csak akkor kapja meg a friss adatokat, ha a felhasználó kéri a frissítést. - Aktív modell: a modell értesíti a nézetet a változásról. Ez akkor fordulhat elő, ha az adatokat valamilyen más akció módosítja (például egy másik felhasználó). A problémára megoldást jelent az Observer (megfigyelő) sablon használata. Az alkalmazás jellegéből adódóan

tökéletes megoldás a passzív modell. (Egyszerre kevesen használják ugyanazokat az adatokat.) De igény esetén könnyen módosítható a modell passzívból aktívba. A továbbiakban kizárólag a m odell kerül részletesebb bemutatásra, mivel ez a pi llér az, amelytől igazán különböznek az MVC sablonra épülő alkalmazások. - 26 - 3 Osztálydiagramok 3.9 A modell A modell, mint olvasható a 3.12 pontban is, reprezentálja az alkalmazás adatait A továbbiakban a modell alkalmazáshoz kapcsolódó osztályai kerülnek bemutatásra. 3.91 Módszerek az osztályok kialakításához Az osztályok kialakításához a Rational Unified Process (RUP) az alkalmazás szakterülettel kapcsolatos fogalmainak összegyűjtését ajánlja. Ehhez remek kiinduló pont egy szöveges megfogalmazás, mint a 2.1 pontban található áttekintés Egy másik ajánlat a Q módszer javaslata, mi szerint az alapvető osztályokat a külvilággal történő adatcsere protokollja, azaz

felhasználói felületek alapján keressük. A módszerek nem adnak egyértelmű útmutatást az attribútumok típusára, így a módszerek könnyebb követhetősége érdekében, mint objektumok kerülnek bemutatásra. 3.911 A RUP módszer A 2.1 pontban található áttekintés alapján az alábbi objektumot lehet összerakni: 14. ábra - 27 - 3 Osztálydiagramok 3.912 A Q módszer A mellékletben található menürendszer alapján, az alábbi objektumként jelenne meg az alkalmazás: 15. ábra 3.913 A módszerek összehasonlítása A 14-es, 15-ös ábrát összehasonlítva szembetűnő különbség, hogy jóval több objektum szerepel a 15-ös ábrán. A eltérés oka, hogy az áttekintés és az alkalmazás menü rendszere a tervezés különböző fázisaiban készült. A felhasználói felületek kialakításakor már sok, előre nem látható probléma megoldásra került, és ezek a korrekciók nem találhatók meg az áttekintésben. 3.92 A Modell

osztály A 15-ös ábrától eltérően, további attribútumokkal kell kiegészíteni az osztályt. Szükség van ugyanis olyan attribútumokra is, melyek egyik felületen sem érhetők el, ilyen a „kapcsolat”, ami az archívummal (adatbázissal) tartja a kapcsolatot. - 28 - 3 Osztálydiagramok Az ábra nem csak a Modell osztályt, hanem a hozzá szorosan kapcsolódó osztályokat is bemutatja: - Kapcsolat osztály: a rendszer és az adatbázis kapcsolatért felelős. - Cégadatok osztály: itt tárolódnak a H arMonika alkalmazást használó vállalkozás adatai. - Számlatömb osztály: példánya a s zámlatömbre vonatkozó törvényi előírások betartásáért felelős. Az ábrán az is látható, hogy ezek az osztályok csak egy-egy példányban fognak előfordulni, valamint az is, hogy a Cégadatok, Számlatömb osztályok is implementálják a Tárolandó interfészt, azaz letárolásra kerülnek az adatbázisban (lásd később). 16. ábra - 29 -

3 Osztálydiagramok 3.93 A Tárolandó interfész Ez az interfész gondoskodik arról, hogy minden őt implementáló osztály objektuma tárolódjon az adatbázisban. Azaz a rendszerek együttműködésénél (25 pont) bemutatott kapcsolatokat – az alkalmazás és az archívum között – ezen keresztül biztosítja a r endszer. Ezáltal minden ilyen típusú – azaz ezt implementáló osztály típusú – objektum tudni fogja az alábbiakat: - getTabla: A metódus segítségével meg tudja mondani, milyen táblán keresztül kapcsolódik az adatbázishoz (részletsebben a Halmaz osztályon belül). - letolt: Ezzel a m etódussal ki tudja olvasni az adatbázisból a s zükséges adatokat, a megfelelő formában (Set osztálynak megfelelően). - uj: A metódus új objektumtárolását teszi lehetővé az adatbázisban. - modosit: Segítségével már egyszer kiírt objektum tulajdonságai (attribútumai) módosíthatók az adatbázisban. - torol: Ez a metódus

biztosít lehetőséget az adatbázisba kiírt objektumok törlésére. Ezekhez minden esetben egy kapcsolatra van szükség az adatbázissal, melyet a kapcsolat objektum tartalmaz, továbbá egy Tábla típusú objektumra, mely az adatbázison belüli szerkezethez alkalmazkodik, valamint (létrehozás, módosítás, törlés esetén) az objektum tárgyára. Az általános megvalósításhoz a g enerikus használata elengedhetetlen, ezek az ábrákon X típussal kerültek megjelölésre. 3.94 A Halmaz osztály A Halmaz osztálynak központi szerepe van alkalmazásban és nem csak Modell osztályon belül, hanem a rendelések, számlák kezelésében is. A Set osztályra azért esett a v álasztás, mivel fogalmilag tökéletesen megfelel az elvárásoknak, valamint, a s zámlák kivételével, minden halmaz várhatóan maximum 100 elemet fog tartalmazni, így a speciális Collection típusú osztályok előnye nem érvényesülne. - 30 - 3 Osztálydiagramok Az adatbázis és az

alkalmazás közötti minimális adatforgalom érdekében, a számlák kivételével minden tárolásra kerül a m emóriában. A számlák és kapcsolódó tételei pedig csak addig tárolódnak a memóriában, ameddig feltétlenül szükséges. Erről az MVC vezérlő (controller) része gondoskodik. A 16-os ábrából következik a 1 7-es ábra, melyen szereplő objektumok a Modell osztályon belül mind Halmaz típusúak. 17. ábra Mint látható a 18-as ábrán is, a Halmaz osztály egy generikus osztály, így ezen típusú objektumok létrejöttekor meg kell adni milyen típusú elemeket fog kezelni. Ezek az osztályok a következő ponttól kerülnek bemutatásra. Az osztály úgy valósítja a Tárolandó interfészt, hogy először meghívja a Tábla típusú attribútumának megegyező nevű metódusát, majd végrehajtja ugyanazon funkciójú Set metódust, azaz: - letöltés esetén, kiolvassa az adatokat az adatbázisból, és ezeket felveszi a halmaz elemi közé -

új rögzítésekor kiírja az új elemet a t áblába, majd felveszi új elemként a halmaz elemi közé - módosítás esetén, megkeresi a r ekordot az adatbázisban és módosítja, majd megkeresi az objektumot a halmazban és módosítja - 31 - 3 Osztálydiagramok - törléskor törli az objektum kapcsolódó rekordját az adatbázisból és kiveszi a halmaz elemei közül. A fentivel ekvivalens metodikát valósítnak meg a T árolandó interfészt implementáló nem Halmaz típusú osztályok is (pl.: Cégadatok, Számlatömb osztályok) 18. ábra 3.95 A Tábla absztrakt osztály Az osztály közvetetten felelős az adatok kiírásáért az adatbázisba, mivel külön-külön implementálni kell minden Tárolandó típusú objektumhoz egy-egy osztályt, az ábrán példaként bemutatott AsztalokTabla osztály mintájára. (A 16-os ábrán szereplő Számlatömb és Cégadatok típusú objektumokhoz is létre kell hozni egy-egy Tábla objektumot.) A 3.22-es pontban

kiemelésre került, hogy a Halmaz osztály elemei nem előre meghatározott típusúak, ezek csak futási időben fognak eldőlni (generikus). Az elemek típusait, osztályait a következő pontok részletezik. - 32 - 3 Osztálydiagramok 3.96 Az Asztal osztály Felépítését, illetve kapcsolatait tekintve az egyik legegyszerűbb osztály, miután – mint az ábrán is látható - független minden más osztálytól. Az asztalok nevű Halmaz típusú objektumban, ilyen típusú elemek találhatók. 19. ábra Pont az egyszerűsége miatt érdemes jobban megvizsgálni, miután minden hasonló osztályban, többségében megtalálhatók ugyanezek az elemek. 3.961 Az Asztal osztály attribútumai Az attribútum egyik fele képernyőterv alapján lett beállítva, ezek az alkalmazás szempontjából leírják az objektumot, másik fele az adatbázis tárolás miatt, logikai kapcsolatok fenntartásához elengedhetetlen: - ID: az adatbázis kezelés miatt fontos, így nem kell

a felhasználók kezét megkötni, mi legyen egy asztal neve, vagy rövid neve. Ezt a rendszer belső logika alapján tölti ki. - rovidNev: az asztal rövid neve, melyet a képernyők átláthatósága végett célszerű használni. - nev: az asztal pontos nevét tartalmazza. - pult: jelölésére szolgál, hogy a pincérek vagy a pultosok használják - torolt: az asztal állapotát jelzi. Több szempontból is előnyös, egyrészt a felhasználónak egy eszköz, amivel jelezheti munkatársainak, hogy az asztalt ne has ználják; másrészt egyes inkonzekvensé válhatnak használata nélkül. - 33 - helyzetekben az adatok 3 Osztálydiagramok 3.962 Az Asztal osztály metódusai Alapvetően három csoportba sorolhatók a metódusok: - Konstruktor metódusok: Két fajta konstruktor található. A rövidebb az új felrögzítéshez szükséges, ekkor csak a felhasználó által ismert adatok kerülnek megadásra, a többit az alkalmazás tölti ki. (az ID-t

kitöltésre kerül egyfajta belső logika alapján, míg a torolt, mint látható az ábrán is alapértelmezettként false értékű). A „hosszabb” konstruktor az adatbázisból való betöltéshez szükséges. - Lekérdező metódusok: Minden attribútum külön-külön lekérhető. - Beállító metódusok: Szintén kettő található, az egyik a töröltségi állapot jelölésére, míg a m ásik az objektum tulajdonságainak megváltoztatására szolgál. 3.97 Az Alkalmazott és a Munkakör osztályok Az Alkalmazott osztály az alkalmazottak, míg a Munkakor osztály a munkakörök nevű Halmaz típusú objektumok elemeiként jelennek meg az alkalmazásban. Együtt kerülnek bemutatásra, mivel szoros kapcsolat áll fenn közöttük, miután miden alkalmazotthoz kötelezően tartozik egy munkakör, mint ahogy az ábra is jelzi. Ugyanakkor elképzelhető olyan munkakör, amely egyetlen alkalmazotthoz sem tartozik. A két osztály kapcsolatában más érdekesség is

felfedezhető, ugyanis a tervek alapján kettes számrendszerre épülő, jogosultságot tartalmazó érték a munkakör attribútumai között szerepel, míg az erre vonatkozó részletező kérdések (can illetve is karakterekkel kezdődőek) mind az alkalmazottnál találhatók. Ennek elsődleges oka, hogy jogosultság kezelésnél arra leszünk kíváncsiak, hogy az adott alkalmazott mit csinálhat, illetve mit nem csinálhat. (Ez utóbbi a Vezérlő feladata) Észrevehető, hogy a modellen belül sehol sincs eltárolva, hogy ki van bejelentkezve, ennek az oka, hogy ez nem a modell feladata, hanem a Vezérlőé. - 34 - 3 Osztálydiagramok 20. ábra 3.98 A Menü és a kapcsolódó osztályok A modell legösszetettebb része, mely elengedhetetlen a rugalmas és egyszerű használathoz. E pontban bemutatott osztályok lefedik, az eddig még be nem mutatott Halmaz típusú objektumok elemeinek osztályait. Követve az eddigi logikát, a többes szám a halmaz neve azon belül

egyes szám az elem neve. Az ábra megértésében sokat segíthet a m ellékletben található, kapcsolódó felhasználói felületek. Leegyszerűsítve minden menühöz, tartozik egy kategória, mely egy az egyben meghatározza a m enü AFA kulcsát, illetve azt, hogy mely kiszerelésekből választhatunk. Ez utóbbi elsődlegesen nem közvetlenül kategóriához tartozik, hanem a kiszerelés típusához, ami már a kategóriához rendelhető. Annak érdekében, hogy több kategóriához, ne kelljen külön, egymást átfedő kiszerelés típusokat létrehozni, a kategóriákhoz beállítható, hogy a kiszerelés típuson belül, mely kiszerelések vonatkoznak a kategóriára. - 35 - 3 Osztálydiagramok 21. ábra - 36 - 3 Osztálydiagramok A kategóriák fastruktúrába szerveződnek, ehhez minden kategóriához meg kell adni egy főkategóriát. A szervezés elindításához két, főkategória nélküli kategória standard módon be van állítva, egyik az

italkategória, másik az ételkategória. Ez a s truktúra teszi lehetővé az előzetes felhasználói könyv részletben bemutatott gyors étel-, italválasztást. A menü árkezelését, egy külön osztály, az Ár osztály segíti, mely a k orábban már ismertetett Halmaz típusú árak attribútumba kerülnek tárolásra. Így megoldható, hogy kiszerelésenként eltérő árat adjunk meg, az áttekintésben leírt igények szerint, külön forintba és külön euróban. Az áttekinthetőség érdekében a devizákhoz egy új felsorolás típus kerül kialakításra. A Halmaz osztály leírásakor, említésre került, hogy minden adat, a számlák kivételével, a m emóriában tárolásra kerül, ennek megvalósítási módja látható a Kategória és a Menü osztályok konstruktoraiban. 3.99 A Rendelés osztály Ilyen típusúak a Modell rendelések attribútumának elemi. Közvetve már bemutatásra került az előzetes felhasználói kézikönyvben, illetve a további

UML diagramok során is központi szerephez jut. Alapjában egy rendelés objektum egy asztal összes rendelést takarja, ezen belül a rendeléstételeket tálcákba csoportosítva. Ez alapvetően, mint a fogalomtárba is olvasható, egy felszolgálási egység, ezzel jelezzük mit, mivel kell felszolgálni. E hármas egységgel jól elkülöníthető, hogy melyik egységgel mit tehet a pincér. A rendelés-tétel elkészíthető, a tálca felszolgálható, valamint a rendelés számlázható, fizethető. A valóságtól eltérően további csoportosítást nem alkalmazunk, holott szóba jöhetne még a t ányér fogalma. Azonban használata, megnehezítené a felületek átláthatóságát, valamint lassítaná a rögzítés folyamatát. Ezzel szemben jelentős előnyhöz nem jutnánk, miután az éttermekben előre meghatározott módon tálalják az ételeket. Így véletlenül sem fordulhat elő, az-az eset például, hogy az általam rendelt - 37 - 3

Osztálydiagramok rántott sajt hasáb burgonyával, tartármártással és savanyúsággal, három edénynél kevesebben vagy többen kerüljön felszolgálásra (a szakács tisztában van azzal, hogy a rántott sajt és a hasáb burgonya egy, míg a saláta és a mártás külön-külön tányérra kerüljön tálaláskor). 22. ábra Ahhoz, hogy semmilyen fennakadás ne forduljon elő, folyamatosan követni kell minden egység állapotát, amit az alkalmazás státuszkezeléssel valósít meg. A státusz alapján dönti el a rendszer, milyen művelet hajtható végre az adott rendelési tétellel. Ezáltal biztosan elkerülhetők az olyan kellemetlen helyzetek, hogy a vendégnek olyan - 38 - 3 Osztálydiagramok tételeket számlázzanak ki, amelyet fel sem szolgáltak részére. Ennek biztosításhoz a következőket kell betartani: - Ha elindul egy státuszmódosulást rendelésegységen von maga után, egy akkor olyan az metódus, összes amely tartalmazott

rendelésegység státuszát át kell állítani. - Előzőekből következően, a státusz kifelé nem terjed, így minden lekérdezés előtt, minden tartalmazó rendelési egységben, le kell futatni a státusz beállítást, miszerint a tartalmazó státusza mindig a legrosszabb tartalmazott státuszával egyezik meg. A rendelések átláthatóbb kezeléséhez kialakításra került egy Státusz elnevezésű felsorolt típus, mely a következők szerint épül fel: - rögzített: Alaphelyzetben, minden felrögzített rendelésegység ilyen státuszú. Ebben a státuszban, meghívható a r endelés osztály rendelés metódusa, mely minden tálcára meghívja ugyanezen nevű metódusát, ami rendelt státuszba állítja a tálcát, ha eddig rögzített státuszú volt. - rendelt: Ilyenkor, kizárólag a tételek elkészítés metódusa hívható meg, ami a tételek státuszát tovább görgeti előkészítettbe. - előkészített: Ha egy tálca előkészített, azaz

minden tétele előkészített, akkor a szakács jelezheti a pincérnek, hogy felszolgálható. - felszolgálható: Ez a lépcső abban az esetben szükséges, ha egy asztalhoz több tálcát kell kivinni, hogy a vendégek egyszerre kezdhessék meg az étkezést. Ebben a s tátuszban kap értesítést a pi ncér, ha egy valamennyi megrendelt tálca felszolgálható. - felszolgált: Felszolgálást követően kerül ebbe a státuszba. Ha egy rendelés felveszi ezt a státuszt, futtatható a számlázás. - számlázott: Ha egy rendelés számlázott, akkor nyílik lehetőség a fizetésre. - fizetett: Gyakorlatilag az ilyen rendelések csak arra várnak, hogy a nap végén lefusson a z árás és el lehessen számoltatni az alkalmazottat, majd törlődnek a rendszerből. - 39 - 3 Osztálydiagramok 3.910 A Számla osztály A számla osztályok a számlák elemei, melyek a többi osztálytól eltérően kezelik a Halmaz típusú objektumokat, a számlatételeket. Az

adatbázisból való feltöltéskor, nem tölti be automatikusan a számlatételeket, erre csak akkor kerül sor, ha olyan metódust hívunk meg, amely használja azokat. A számla osztályok további egyedisége, hogy a s zámlatételek jóval kevesebb információt tartalmaznak, mint az adatbázisba kiírtak. Ez azért megvalósítható, mivel a törvényi előírások szerint utólag nem módosíthatók a számlák (csak stornózhatók), illetve azért célszerű, mert a egyébként a számla szempontjából nem releváns, lekérdezésekhez fontos információk is tárolásra kerülnének. Ezt úgy éri el a rendszer, hogy új számla létrehozásakor, a teljes rendelés átadásra kerül, amiből a szükséges adatok tárolásra kerülnek az adatbázisban. 23. ábra - 40 - 5 Időben lezajló változások 4. Interakció-diagramok Interakció-diagramok segítségével az objektumokat nem strukturális kapcsolatai, hanem a k öztük lefolytatott kommunikáció alapján

jellemezük. A diagramokkal az összetettebb feladatok megvalósítása során együttműködő objektumokat ábrázoljuk, ahol az együttműködést üzenet váltások segítségével valósítjuk meg. Az UML két interakció-diagram típust definiál, a s zekvencia diagramokkal az üzenet időbeli viszonyait emeljük ki, míg az együttműködési diagram az objektumok szerveződésére helyezi a hangsúlyt. 4.10 Az MVC szekvencia-diagramja Az osztálydiagramoknál vázlatosan leírásra került a M odel-View-Controller sablon, mely alapjaiban valósítja meg az alkalmazás belső kommunikációját. Az MVC sablonban a modell lehet passzív, vagy aktív, ettől függ a szekvencia-diagramjának felépítése. Az alkalmazáshoz passzív modell lett beállítva, mivel az alkalmazás jellege nem tette szükségessé az aktív változat kialakítását. 24. ábra 4.11 A rendeléskezelés szekvencia-diagramja Rendelés osztály részletezésénél, bővebb szöveges leírás található

az osztály, illetve tartalmazott osztályok információ áramlásáról. Ennek szemléletes megjelenítését tartalmazza a diagram. - 41 - 5 Időben lezajló változások 25. ábra Az ábrán jól látható, hogy a r endelésegységek státusza sosem terjed kifelé, csak befelé. Ha megvizsgáljuk a f elszolgálható eseményt, látható, hogy a t álca felszolgálható lesz és vele együtt a tétele(i) is, ez azonban nem jelenti automatikusan azt, hogy az egész rendelés felszolgálható. Ugyanakkor az egész rendelésre vonatkozó számlázás esemény magával vonja, hogy mind a tálca, mind a tálca tétele számlázott lesz. - 42 - 5 Időben lezajló változások A diagramból az is kitűnik, miért nincs szükség üzenet objektumra. Sok alkalmazás ilyen és hasonló objektumokat használ az üzenetek továbbítására, ami egy jól bevált technológia. Azonban a rendelések kezelését célszerű egy állapotjelzővel végig kísérni, ami részben lefedi az

üzenetküldést is. A szakács értesítést kap, azokról a tételekről, amelyek még nem készültek el, de megrendelték, és az üzenet mindaddig aktív, amíg meg nem jelölte, hogy elkészült. Ugyanez igaz a pi ncérre is, azaz addig lesz aktív az üzenete, míg fel nem szolgál egy felszolgálandó tálcát. Természetesen sokkal rugalmasabb és szélesebb körben is felhasználható egy üzenet objektum, de ebben az alkalmazásban erre nincs igény. - 43 - 5 Időben lezajló változások 5. Időben lezajló változások Az időben lezajló változást az UML két diagramtípusával ábrázolhatjuk. Az aktivitásdiagramok segítségével a változást alapvetően az aktivitás szempontjából írjuk le, a végrehajtandó tevékenységek és azok sorrendiségének meghatározásával. Ábrázolható vele párhuzamos működés, illetve szinkronizáció is. Az állapot-átmenet diagram a változást passzív oldalról közelíti meg, a vizsgált elemet elérő

külső események hatására bekövetkező reakciók alapján. 5.12 A rendeléstétel rögzítés aktivitás-diagramja Gyakorlatilag az az esemény van kiemelve, amikor a pultos vagy a pincér, a vendégek által leadott rendelést, rögzíti a rendszerben. 26. ábra 5.13 A rendeléskezelés aktivitás-diagramja Maga a rendeléskezelés már többször is elemzésre került. Ami miatt mégis érdemes a diagramot jobban szemügyre venni, azok a s zinkronizációs pontok. Ezeken a helyeken kapcsolódnak össze a r endelési egységek. (Az ábrán, az átláthatóság érdekében, egy oszlop egy rendelési egységet jelöl) Azokon a pontokon, ahol feltétel szerepel egy választási lehetőséggel, a rendelési egység megvizsgálja saját magát, hogy minden rendben van-e. - 44 - 5 Időben lezajló változások 27. ábra 5.14 A rendeléskezelés állapot-átmenet diagramja Az alkalmazás a rendeléskezelést állapot-, státuszkezeléssel oldja meg, ezért ez a diagram

illeszkedik legjobban a rendeléskezelés bemutatásához. - 45 - 5 Időben lezajló változások 28. ábra - 46 - 6 Összegzés 6. Összegzés Napjainkban egyre nagyobb és nagyobb rendszereket fejlesztenek, melyek más-más rendszerekhez kapcsolódnak. Ezeket a rendszereket lehetetlen előkészítés nélkül létrehozni, az előkészítés minősége pedig nagyban befolyásolja a kivitelezés időigényét. Optimális esetben egy terv az alábbi kritériumokat teljesíti: - általános, azaz programnyelvtől független legyen - könnyen olvasható, lehetőleg grafikus eszközöket használjon - szabványos, azaz mindenki által értelmezhető legyen - kiterjedt eszközkészlettel rendelkezzen Ezeknek teljes egészében megfelel az UML, bár elsődlegesen a ma elterjedt, OO koncepciók jelölésére hozták létre. A fentieken túl az UML a pr oblémák elemzéséhez is biztosít eszközöket, melyek szintén megfelelnek a tervekkel szemben támasztott

kritériumoknak. Ennek a nyelvnek egy jelentős hátránya van, az hogy nem ad módszert az ábrák, diagramok elkészítéshez. Azonban több olyan módszer is elterjedt, melyek jól használhatók (pl.: a „Q” modellező módszer), és megfelelnek az UML előírásainak Összességében az UML előnyös tulajdonságai miatt egy olyan eszköz, mely az informatika sok területén jól használható, azaz manapság nem előnyt jelent az ismerete, hanem hátrányt a nem ismerete. - 47 - Felhasznált irodalom Felhasznált irodalom Csík Norbert: A Model-View-Controller tervezési sablon, 2004 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Programtervezési minták - újrahasznosítható elemek objektumközpontú programokhoz Kiskapu Kft., 2004 Ian Sommerville: Szoftverrendszerek fejlesztése Panem Kft., 2002 Oszlávszki Szabolcs: Éttermi alkalmazás adatbázisának elkészítése ingyenes eszközök használatával, 2005 Vég Csaba: Alkalmazásfejlesztés Logos 2000

Bt., 1999 - 48 - Melléklet Melléklet 1. képernyőterv 2. képernyőterv 3. képernyőterv - 49 - Melléklet 4. képernyőterv 5. képernyőterv - 50 - Melléklet 6. képernyőterv 7. képernyőterv 8. képernyőterv - 51 - Melléklet 9. képernyőterv 10. képernyőterv - 52 - Melléklet 11. képernyőterv 12. képernyőterv - 53 -