10.2. Osztálydiagram

Az entitások, és a közöttük lévő kapcsolatok a 9. ábrán láthatóak. Az egyszerűség kedvéért a korábban ismertetett modulok, szűrők, loginmodulok nem szerepelnek az ábrán, ezek rendre a FeedgenModule, Filter és LoginModule osztályok leszármazottai lennének. Ezekről bővebben a fejezet későbbi részében lesz szó.

9. ábra: A főbb osztályokat ábrázoló osztálydiagram
9. ábra: A főbb osztályokat ábrázoló osztálydiagram

A rendszerben a UserURL osztály tölt be központi szerepet. Ez az osztály reprezentálja a figyelendő weboldalakat. A legutóbbi és azelőtti lekérdezés tartalmát két URLData (HostURL.recvData és UserURL.recvDataOld) objektum tartalmazza, amelyeken majd a FeedgenModule absztrakt osztály megfelelő leszármazottja végzi el az összehasonlítást, és ezzel együtt az RSS csatornába kerülő hír, hírek generálását. Ezen hírek adatait News entitások tárolják, amiket a UserURL összegez egy gyűjtemény (collection) formájában. A UserURL-ekhez kapcsolódnak a szűrők is (egy sorrendezett lista formájában). A szűrők a Filter osztályból származnak, ez biztosít közös felületet a futtatásukhoz, és a Module‑hoz hasonlóan ezek is az URLData objektumokon végeznek műveleteket. Az errorCount és lastError mezők a hibákat okozó URL-ek megjelölésére szolgálnak (a korábban ismertetett exponenciális visszalépéses algoritmussal, 3.3. fejezet), a disabledBefore pedig a frissítést tiltja le az általa tartalmazott időpontig (hiba esetén).

A 9. ábrán látható felépítést akkor célszerű választani, ha egyetlen globális időzítővel dolgozunk. Az időzítő ütésekor egy ciklus végighalad a Host objektumokon, majd lekérdez minden HostURL-ben tárolt URL-t, hostonként egyetlen kapcsolat létrehozásával, elkerülve a többszöri kapcsolódást egy szerverhez. Ezután a kapott adatok átadhatóak minden UserURL‑nek, amelyek futtatják a hozzájuk tartozó szűrőket és modult, így egy lépésben frissíthető minden felhasználó adott HostURL-hez tartozó news listája.

A LoginModule-ok miatt a helyzet valójában nem ilyen egyszerű, mivel a HostURL‑ek a bejelentkezési adatokban is különbözhetnek, így ugyanahhoz a linkhez más-más tartalom tartozhat különböző felhasználónév-jelszó páros esetén. Ezért a HostURL‑ben szerepel a bejelentkezési adatok hash‑e (benne a LoginModule típusával). Így már minden linkhez más-más HostURL tartozik, ha különbözőek ezek az adatok. A LoginModule‑t nem célszerű a HostURL‑hez kapcsolni, mert nagyon megnehezíti az objektumok közti kapcsolatok kezelését (gondoljunk csak arra az esetre, ha több felhasználó ugyanazzal a felhasználónév‑jelszó párral figyeltet egy oldalt, de az egyik megváltoztatja ezen adatokat). Másrészt nem túl valószínű, hogy több felhasználó is ugyanazokat a bejelentkezési adatokat használja (bár azért előfordulhat, például nyílt titokként kezelt közös jelszóval védett oldalak esetén).

Ezen felépítés ugyan kevéssé redundáns és próbálja kímélni a szerverek erőforrásait, de az is megfigyelhető, hogy az adatok még így is eléggé „szétszórtan” helyezkednek el: például a figyelt weboldal teljes URL-je két helyről állítható össze, a LoginModule adatait is két helyen kell frissíteni változás esetén. Továbbá, ha nem fogadjuk el azt a megoldást, hogy globális időzítőt használunk, akkor már egyáltalán nem optimális ez a felépítés.

A 7.6. fejezetben is említésre került, hogy a fix időközönként történő frissítés korántsem a legjobb megoldás, aminek egy még inkább kötött formája a globális időzítő használata. A kevésbé konfigurálható időzítő nagyobb terheléshez vezethet, hiszen a felhasználók a frissítési időközök minimumát igyekeznek elérni ahelyett, hogy minden időszaknak és weboldalnak a neki megfelelő időközt állítanák be.

Testreszabhatóbb (például cron-szerű) időzítéshez ezért inkább a következő struktúra javasolt (10. ábra).

10. ábra: A fejlettebb időzítéshez javasolt rendszer osztálydiagramja
10. ábra: A fejlettebb időzítéshez javasolt rendszer osztálydiagramja

Az optimalizációt itt a működés fogja megvalósítani. Minden UserURL-hez külön időzítők tartozhatnak (a triggers mező leírása alapján), amelyek első körben csak az adott UserURL‑t frissítik. Második körben viszont megkeresnek minden olyan további UserURL‑t, amely ugyanazt a linket tartalmazza ugyanazokkal a LoginModule beállításokkal. Ha egy ilyen UserURL alwaysRefresh mezője true értékű, akkor lefuttatjuk a szűrőket és modulokat az első körben lekért adatokkal erre a UserURL objektumra is. Az alwaysRefresh mezőre azért van szükség, mert nem biztos, hogy minden felhasználó az általa beállítottnál gyakrabban kíván értesülni az oldal frissítéseiről. Elképzelhető, hogy valaki csak hetente egy értesítést szeretne kapni, akárhányszor is módosult közben az oldal.

A checkEmbeddedResources mező az oldalon szereplő képek változásainak figyelését jelzi. A képekből (vagy az oldalon szereplő egyéb objektumokból) képezett hash‑t az URLData tárolja.

Tartalom átvétel