Priklad dokumentu

Prepis

1 Slovenská technická univerzita Fakulta informatiky a informačných technológií Ilkovičova 3, Bratislava 4 Kontrola vhodnosti webovej stránky pre vyhľadávače a dohľad nad zverejňovanými osobnými informáciami na webe Martin Sadauskas Študijný odbor: Informatika Študijný program: Informatika Ročník: 3 Vedúci projektu: Mgr. Martin Šechný Ak. rok: 2006/2007

2 Obsah 0 ÚVOD Účel a rozsah dokumentu Slovník pojmov problémovej oblasti Použitá notácia ANALÝZA RIEŠENÉHO PROBLÉMU HTML SGML Standard Generalized Markup Language Sémantika HTML Prehliadače Vyhľadávacie stroje Optimalizácie webových stránok pre vyhľadávacie roboty Automaticky generovaný obsah Citlivosť osobných údajov zverejňovaných na webe Zverejňovanie osobných údajov POŽIADAVKY NA INFORMAČNÝ SYSTÉM Biznis model stratégie a ciele produktu Biznis procesný model Vlastnosti produktu Špecifikácia požadovaného riešenia BP 01 Príjem kníh do knižnice Sumarizácia modelu údajov Kópia titulu Titul Ďalšie požiadavky AKCEPTAČNÉ TESTY REVÍZIA A DOPLNENIE ŠPECIFIKÁCIE POŽIADAVIEK Sumarizácia modifikácií a doplnkov špecifikácie požiadaviek ARCHITEKTÚRA SYSTÉMU ZHODNOTENIE ODKAZY A ZDROJE

3 0 Úvod Takmer každá osoba, ktorá dnes potrebuje získať nejaké informácie použije ako prvotný zdroj informácií Internet. Konkrétnejšie hlavne jeho časť World Wide Web(WWW). Táto je v dnešnej dobe jednoznačne najväčším zdrojom informácií na svete. Aby človek dokázal nájsť v obrovskom množstve dát na webe akurát to, čo hľadá používa vyhľadávacie stroje, prípadne webo. Najväčšie zastúpenie na trhu má dnes vyhľadávací stroj Google 1. V roku 2006 mal 66.63% zastúpenie na trhu, čo je o vyše 50% viac ako má 2. najväčší subjekt na tomto trhu, webový adresár Yahoo![3]. Keďže Google má takýto výrazný náskok, prispôsobujú sa tomu aj tvorcovia weboých stránok a svoju tvorbu sa snažia optimalizovať hlavne na prehľadávacie roboty tohto vyhľadávača. Faktorov, podľa ktorých tieto roboty hodnotia jednotlivé stránky je vyše Mnohé z nich sú rovnaké pre väčšinu vyhľadávacích strojov, nie len pre Google. Priestor, ktorý tvorí WWW, je rozdelený na ten, ktorý vyhľadávače a webové adresáre majú zaindexovaný, tzv. viditeľný a ten, ktorý nemajú, tzv. neviditeľný. Podľa publikácie[1] bolo na internete približne 11,5 miliardy indexovateľných stránok v roku To je ale zanedbateľné číslo v porovnaní s množstvom stránok, ktoré tvoria neviditeľný web. Ten sa odhaduje byť 500 násobne väčší ako je viditeľná časť[2]. Základným dôvodom, prečo webová stránka nie je zaindexovaná je, že neexistuje žiadny na ňu ukazujúci odkaz z niektorej inej už zaindexovanej stránky. Závažnejšou chybou je, že odkazy síce môžu existovať, ale nie sú správne syntakticky zapísané alebo sú generované niektorou technológiou na strane používateľa (napr. javascript) na základe interakcie používateľa so stránkou. Takéto odkazy vyhľadávací robot buď nie je schopný analyzovať alebo ich vôbec nevidí. Nedokáže tak získať potrebný odkaz a na stránku sa vôbec nedostne. Oveľa horšie to ešte je, ak je to odkaz na vstupný bod pre celé webové sídlo, ktoré je potom poprepájané internými linkami, ale neukazujú naň žiadne externé odkazy. Tatko je zablokované komplet celé sídlo a je odkázané na opravu chybného odkazu. Samozrejme, že pre umožnenie prehľadania dokumentu nie je potrebná len správna syntax externého odkazu, ale aj syntax celého prehliadaného dokumentu, ktorá môže taktiež zmiasť prehľadávacieho robota a ten následne pri najlepšom zníži hodnotenie tohto dokumentu a teda aj poradie na stránke výsledkov vyhľadávacíxh strojov 3. Ďalším hodnoteným faktorom, je dodržanie určitej sémantiky pri písaní (generovaní) zdrojového kódu stránky. Tá by mala mať logickú štruktúru a sémanticky správne značkovanie. V jayzku HTML majú niektoré značky obsahový význam, napr. ADDRESS, významom tejto je, že medzi otváracou a uzatváracou značkou nasledujú kontaktné údaje pre dokument alebo väčšinovú časť dokumentu, takú ako formulár[4]. Takto označená informácia sa dá potom jednoducho extrahovať z dokumentu, pri automatickom spracovaní a vyhľadávaní kontaktných údajov. Ďalšou kategóriou sú značky, ktoré majú iba štrukturálny význam, napr. DIV. Pomocu tejto značky je možné pridať štruktúru do dokumentu[4]. Sú tu ale aj značky ako napr. H1,...,H6, ktoré majú jasný obsahový význam, pretože stručne opisujú tému sekcie, ktorú predstavujú, ale zároveň majú štrukturálny význam, pretože vizuálne prehliadače interpretujú dôležitejšie (H1 je najdôležitejší) nadpisi väčším fontom, ako ti emenej dôležité[4]. Vyhľadávače dokážu programovo aspoň čiastočne skontrolovať, či napr. nadpis stránky ohraničený tagom H1 súvisí s obsahom stránky. Keď už má dokument sémanticky správnu štruktúru, môže mu tvorca pridať vizuálnu prezentáciu pomocou CSS (Cascading Style Sheets) 4. Pre koncového používateľa je často rovnako dôležitá ako obsah aj prezentácia dokumentu. Cieľom web designerov je vytvoriť pre používateľa také prostredie, aby sa cítil dobre a rýchlo, a jednoducho našiel informácie, ktoré hľadá. Vytvoriť takéto prostredie vyžaduje ťažkú prácu a značné skúsenosti. Na trhu totiž existuje niekoľko prehliadačov pre každý operačný systém, ktorý sa bežne používa a každý z nich je v niečom iný. Po tzv. vojne prehliadačov koncom 90. rokov vzniklo zásluhou Netscape aj Microsoft niekoľko prvkov, ktoré hadam vôbec nerešpektovali špecifikácie HTML a CSS. Pre Netscape to bola napr. značka LAYER a pre Microsoft zase filtre. Hoci konzorcium W3C založené v roku 1994 prišlo so snahou o štandardizáciu HTML aj CSS, tieto prvky je stále možné používať a každý prehliadač na ne reaguje inak[6] ang. Search engines Result Pages (SERP) 4 slov. kaskádové štýly 2

4 Ak sa programátorovi podarí konečne vytvoriť web stránku aj z pohľadu vizuálnej prezentácie, stále sa môže stať, že jeho tvorba nebude prístupná cez vyhľadávače. Pokiaľ sa jedná o rozsiahle webové sídlo, čo do množstva webových stránok, je často efektívnejšie, ak sa ich obsah generuje dynamicky na základe údajov uložených v databáze. Tie sa pomocou skriptu, ktorý sa o generovanie stará a parametrov, ktoré mu boli poslané z databázy vyberú a vložia napr. do šablóny, ktorá predstavuje štruktúru webovej stránky. Takéto stránky, ale môžu byť problém, pretože niektoré vyhľadávacie stroje ich nezaindexujú automaticky. Príkladom je AltaVista 5. Najobvyklejším znakom, ktorý prezradí, že ide o automaticky generovaný obsah je opytovacie znamienko, za ktorým nasledujú parametre pre skript spracúvajúci požiadavku. Takímto stránkam sa tieto vyhľadávacie stroje vyhýbajú, pretože sa môžu chytiť do tzv. pavúčích pascí 6 (pavúk je iný názov pre prehľadávecieho robota). Tak sa nazýva, napr. ak tvorca generuje milióny podobných, ale nie identických stránok s účelom ovplyvniť výsledky vyhľadávacích strojov. Prípadne môže byť výsledkom nezodpovedného programovania skript, ktorý uvedie robota to nekonečnej slučky[5]. Aj AltaVista, môže zaindexovať dynamicky generovanú stránku, musí to ale spraviť sám programátor manuálne. Súčasťou informácií, ktoré sa objavujú na webových stránkach sú aj osobné informácie týkajúce sa konkrétnych osôb. Nie vždy ale chceme, aby boli tieto zverejnené a sprístupnené širokej verejnosti. Na web sa dnes dávajú všetky možné dokumenty od zoznamov uchádzačov prijatých na vysoké školy, cez osobné stránky až po zoznam živnostníkov. Z takýchto a podobných dokumentov môže o nás cudzí človek zistiť ako sa presne voláme, kde bývame, kto sú naši rodičia, príp. konkrétne identifikačné údaje ako čislo občianskeho preukazu, rodné číslo, atď. Aj keď existuje riešenie ako zabrániť prehľadávacím strojom pristúpiť ku konkrétnym oblastiam vyvíjaného webu v podobe suboru robots.txt, funguje to len pre tie, ktoré ho rešpektujú. Ak takýto robot prechádza našu stránku a nerešpektuje obmedzenia, je zamedzenie získania dát zložitejšie, pretože server, ktorý mu údaje posiela, nemá ako rozlíšiť či ide o používateľa alebo robota. 0.1 Účel a rozsah dokumentu Predkladaný dokument obsahuje špecifikáciu softvérového systému, ktorý vznikne ako výsledok bakaláskej práce, ktorej zadanie je na začiatku tohto dokumentu. V dokumente bude opísaná problémová oblasť web, syntax html, semantika html, zverejňovanie osobných údajov a ďalšie. Každá z oblastí bude rozanalyzovaná v rozsahu potrebnom pre splnenie zadania. Zároveň tu bude špecifikácia navrhovanej aplikácie na kontrolu zdrojového kódu webových stránok. Ako základné požiadavky na túto aplikáciu som spolu s vedúcim projektu Martinom Šechným stanovil syntaktickú kontrolu zdrojového kódu stránok, sémantickú kontrolu v zmysle kontroly súvisu popisu odkazu so stránkou na ktorú odkazuje, kotrolu funkčnosti odkazov a simuláciu prehľadávacieho robota, ktorý počas prehľadávania analyzovaného webu bude tieto kontroly vykonávať. Aplikácia sa nebude nijak týkať citlivosti osobných údajov, keďže tejto časti sa venuje druhý študent pracujúci na tejto téme. Dokument je bude slúžiť ako podklad pre implementáciu daného softvérového systému. Bude určený každému, kto bude chcieť preštudovať stavbu tohto systému alebo získať informácie z prostredia tvorby webových stránok a príbuzných oblastí. 0.2 Slovník pojmov problémovej oblasti 0.3 Použitá notácia ang. spider traps 3

5 1 Analýza riešeného problému 1.1 HTML Prvý krát bola špecifikácia HTML(HyperText Markup Language) sprístupnená v roku 1990 Timom Berners-Leem (TBL)[7]. Táto špecifikácia poskytovala len základné možnosti na narábanie s textom. Od tých čias dospelo HTML už k verzii Hlavnou organizáciou, ktorá sa stará o štandardyzáciu technológií týkajúcich sa WWW je World Wide Web Consortium (W3C), na čele ktorej stojí práve TBL. Medzi inými sa stará aj o špecifikácie HTML. Členmi tohto kozorcia sú spoločnosti ako Microsoft Corporation, AOL LLC (odkúpil Netscape v roku 1999) alebo Google, Inc. 7. Jeho úlohou je aj napriek snahe jednotlivých spoločností posilniť si čo najviac vlastnú základňu, ukázať potrebu pre dodržiavanie a tvobu jendnotných špecifikácií webových technológií. HTML bolo vytvorené ako aplikácia SGML (Standard Generalized Markup Language). SGML je štandard vytvorený na formálnu definíciu textu, ktorá bude nezávislá od zariadenia, systému a aplikácie, ktorá s textom pracuje. Aby bolo teda možné pochopiť ako vytvoriť fungujúci syntaktický validátor, bude najprv potrebné konkrétnejšie vysvetliť, čo to SGML je. Niektoré informácie nám pomôžu aj pri semantickej analýze kódu SGML Standard Generalized Markup Language Medzinárodná organizácia pre štandardizáciu si osvojila a odsúhlasila SGML ako oficiálny ISO štandard v roku Bol zaevidovaný pod opisným číslom ISO Tento štandard opisuje jazyk, ktorý sa používa na definovanie opisného značkovacieho jazyka. Volá sa inak aj metajazyk. Výhodou SGML je, že sa nezaoberá prezentačnou stránkou dokumentu, ale určuje jeho logickú štruktúru. SGML dokument sa skladá z niekoľkých potrebných častí: voliteľná SGML deklarácia požadovaná DTD (Document Type Definition) inštancie elementov dokumentu a ich atribúty odkazy na entity označené sekcie Z hladiska tejto bakalárskej práce si nás bude ďalej zaujímať hlavne DTD. DTD - Document Type Definition DTD je formálny opis štruktúri konkrétnej triedy dokumentov [7] Povedané inak, DTD deklaruje elementy, ktoré sa v môžu vyskytnúť v danej triede dokumentov a zároveň štruktúrálne vzťahy medzi týmito elementami, ktoré musia byť v dokumente dodržané. Každý element vyskytujúci sa v dokumente musí mať v DTD zadefinované meno a údaje z ktorých môže, resp. musí pozostávať obsah daného elementu. Ukážeme si jednoduchý príklad ako môže vyzerať časť DTD: <!ELEMENT kontakt <!ELEMENT celemeno <!ELEMENT telefon - - ( celemeno, telefon*)> - - ( krstne, priezvisko)> - - ( mobil pevnalinka)> Samozrejme, že príklad pokrýva len veľmi malú časť analyzovanej oblasti, ale na vytvorenie určitej predstavy to bude stačiť. Môžme si tu ukázať hneď niekoľko vecí: definujeme tu značky kontakt, celemeno, telefon hviezdička za elementom telefon hovorí o tom, že element kontakt môže obsahovať nula alebo viac elementov telefon v elemente kontakt sa musí vyskytovať najprv jedenkrát element celemeno a až potom sa môže vyskytnúť element telefon, toto určuje znak,, oddeľujúci tieto dva elementy 7 4

6 pokiaľ sú elementy oddelené, element v ktorého definícii sa nachádzajú musí obsahovať jeden z nich SGML nie je schopné definovať význam (sémantiku), ktorý by opísal, čo predstavuje daná značka. Na druhej strane ale meno značky, pokiaľ bolo zvolené rozumne význam často ukazuje. Obyčajne sa ešte vytvorí prídavná dokumentácia, do ktorej sa význam jednotlivých elementov zapíše. Vďaka tomu, že značky sú sebaopisné, hovoríme o opisnom značkovaní. Opakom sú procedurálne značkovacie jazyky ako napr. troff Sémantika HTML 1.2 Prehliadače 1.3 Vyhľadávacie stroje Optimalizácie webových stránok pre vyhľadávacie roboty Automaticky generovaný obsah 1.4 Citlivosť osobných údajov zverejňovaných na webe Zverejňovanie osobných údajov 5

7 2 Požiadavky na informačný systém Táto kapitola obsahuje požiadavky na vytváraný informačný systém. Požiadavky sa modelujú diagramom prípadov použitia a diagramom modelu údajov, ktorý sa vytvára zvlášť pre každý diagram prípadov použitia a tiež celkový pohľad na model údajov. Súčasťou kapitoly je stanovenie aj ďalších (nefunkcionálnych) požiadaviek na systém. Cieľom je porozumenie a zachytenie požiadaviek, pričom takéto vyjadrenie požiadaviek je často podkladom pre zmluvu medzi zadávateľom a riešiteľom. Táto kapitola obsahuje požiadavky na vytváraný informačný systém. Je rozdelená na tri časti. Prvá časť obsahuje špecifikáciu požadovaného riešenia vo forme modelu prípadov použitia a zodpovedajúceho modelu údajov. Druhá časť sumarizuje model údajov. Tretia časť kapitoly ponúka ostatné, nefunkcionálne požiadavky na vytváraný systém. 2.1 Biznis model stratégie a ciele produktu Účelom vytváraného informačného systému je nielen centralizácia väčšiny činností spojených s inštaláciou a prevádzkou rôzneho softvéru v rámci nejakej spoločnosti (evidencia softvéru, odstránenie administrácie, udržanie konzistentnosti systému), ale aj zjednodušenie a zefektívnenie samotného procesu inštalácie a správy softvéru. Z účelu systému vyplývajú biznis ciele na obr. 1. Obr. 1. Modelovanie stratégie biznis ciele. 2.2 Biznis procesný model Náš informačný systém ponúka tieto služby: evidovanie zamestnancov spoločnosti v centrálnej databáze prideľovanie práv zamestnancom na inštaláciu rozličného softvéru na základe ich pracovného zaradenia umožňuje vytvoriť a jednoducho spravovať centrálnu databázu zamestnancami použiteľného softvéru, ktorú je možné kedykoľvek prispôsobiť aktuálnym potrebám a podmienkam v spoločnosti 6

8 flexibilné, bezpečné a veľmi rýchle pridávanie a odoberanie softvéru na počítačoch jednotlivých zamestnancov vedenie štatistiky o používaní softvéru jednotlivými zamestnancami Pre riešený problém sme identifikovali päť základných biznis procesov, ktoré bude systém realizovať. Znázornené sú na obr. 2. Obr. 2. Biznis procesy V nasledujúcej časti postupne opíšeme identifikované biznis procesy. Pridanie a odobratie zamestnanca z databázy: Ak chceme udržať konzistentnosť systému a vytvoriť evidenciu zamestnancov a nimi používaného softvéru, je potrebné prijímať nových zamestnancov podľa presne určených pravidiel. Náš informačný systém ponúka jednoduché pridanie nového zamestnanca do databázy, spolu s uchovaním jeho osobných údajov a taktiež umožňuje jeho zaradenie do jednej z používateľských skupín. Na základe jeho zaradenia do skupiny zamestnancovi vznikajú práva na používanie softvéru určeného pre tú ktorú skupinu. Tento proces je opísaný na obrázku 3. 7

9 Obr. 3. Biznis proces Príjem zamestnanca (pridanie zamestnanca do databázy). Prepúšťanie zamestnancov sa taktiež riadi určitými pravidlami. Je potrebné bezpečne a ľahko odstrániť údaje o zamestnancovi, zrušiť jeho práva, odobrať ho z jeho skupiny do ktorej bol zaradený a taktiež odstrániť všetky programy a dáta, ktoré sú pre spoločnosť naďalej irelevantné. Tento proces opisuje obrázok 4. Obr. 4. Biznis proces prepustenia zamestnanca 8

10 (odstránenie zamestnanca z databázy) Pridanie, správa, využívanie a vyradenie softvéru z databázy: Nato, aby sme nejaký softvér mohli inštalovať z centrálnej databázy, je potrebné ho najskôr do tejto databázy pridať. Náš informačný systém ponúka možnosti pridávania softvéru do centrálnej databázy viacerými spôsobmi. Prvým z nich je pridanie odkazu na inštalačné súbory požadovaného softvéru na vzdialenom počítači. V tomto procese správca databázy určí server alebo skupinu serverov na ktorých sa požadovaný softvér nachádza. Vytvorí zoznam dostupného softvéru na daných serveroch a odkazy na jednotlivé programy pridá do databázy. Ďalej určí ktoré používateľské skupiny budú mať prístup k tomuto softvéru v rámci spoločnosti. Jednotliví zamestnanci potom pri inštalácii softvéru ťahajú inštalačné súbory priamo zo vzdialeného počítača čo šetrí najmä miesto na pevnom disku a zabezpečuje stiahnutie vždy aktuálnej verzie daného softvéru. Druhým spôsobom je inštalácia softvéru zo zakúpeného CD prípadne iného média. Pri tomto postupe správca uloží inštalačné súbory v centrálnej databáze. Taktiež priradí jednotlivým skupinám práva na používanie tohto softvéru. Takýmto spôsobom sa zaručí okamžitá dostupnosť softvéru a jeho rýchla inštalácia, ktorá nie je závislá na funkčnosti vzdialeného počítača. Proces pridania softvéru je opísaný na obrázku 5. Obr. 5. Pridanie nového softvéru do databázy 9

11 Pridanie softvéru do databázy nestačí. Programy v databáze je potrebné spravovať a udržiavať ich najnovšie verzie, prípadne verzie, ktoré sú najvhodnejšie pre prácu zamestnancov. 10

12 Obr. 6. Správa a využívanie softvéru Informačný systém umožňuje aj spracovanie štatistických údajov o používaní softvéru zamestnancami ako aj správu licencii programov a presuny zamestnancov medzi používateľskými skupinami. Keď zamestnanec už nepotrebuje určitý program, systém mu umožní jednoducho a bezpečne odstrániť tento program z jeho počítača tak, aby tým neovplyvnil funkčnosť ostatných programov. Ak spoločnosť stratí potrebu využívať určitý softvér alebo jej skončí na softvér licencia alebo je potrebné odstrániť softvér z databázy z iných dôvodov, systém poskytuje proces vyradenia softvéru z centrálnej databázy (obr. 7). Obr. 7. Biznis proces Vyradenie softvéru z databázy 2.3 Vlastnosti produktu Požiadavkou na náš Manažér Automatickej Inštalácie a Správy Systému bolo, aby ponúkal centralizovaný spôsob správy celého systému. Myslí sa tým, že v prípade, ak systém bude nainštalovaný v spoločnosti, ktorej pracovníci sú pripojení na jednotnú sieť, všetky inštalácie v rámci celej spoločnosti budú zaznamenávané a spravované z jedného miesta. Užívatelia si budú môcť na klientských počítačoch nainštalovať len softvér, ktorý je sprístupnený z firemného servera, príp. z povolených serverov prístupných na internete. Aplikácia je v prvom rade určená na správu inštalácií v sieti. V prípade väčších spoločností môže ísť 11

13 o niekoľko oddelení, ktoré majú rôzne potreby na softvér. Títo užívatelia musia byť preto diferencovaný do rôznych skupín, ktoré majú rôzne práva. Priraďovanie užívateľov do skupín a priraďovanie práv týmto skupinám je úlohou administrátora, ktorý musí byť minimálne jeden v systéme. Ďalej bude možné prideliť určitej skupine práva na rôzne štatistiky o nainštalovaných produktoch v rámci celej firmy, prípadne len vlastných, o ich využití a cene a pod. Aplikáciu ale bude možné použiť aj ako standalone aplikáciu na jednom počítači. V tomto prípadne sa bude kategória užívateľa taktiež rozlišovať podľa prihlásenia sa do systému. Okrem softvéru uloženého priamo na serveri, je možné sťahovať softvér aj z administrátorom povolených vzdialených serverov. V tomto prípade je možnosť určiť, či sa bude udržovať databáza dostupného softvéru centralizovane, tj. databáza sa bude aktualizovať len podľa jedného spoľahlivého servera (napr. prevádzkovateľa služieb IBM). V prípade distribuovaného spôsobu bude určených niekoľko serverov, ktoré môžu mať rôznu prioritu. Napríklad update alebo novú verziu Adobe Reader je najlepšie stiahnuť priamo od Adobe, teda pre tento program bude mať server Adobe najväčšiu prioritu. Systém drží informácie o závislostiach jednotlivých inštalovaných programov. V prípade inštalácie upozorní na to, že na fungovanie sú potrebné ďalšie aplikácie a ponúkne užívateľovi možnosť nainštalovať všetky potrebné komponenty naraz. Ak inštalovaná služba bude v konflikte s nejakou už nainštalovanou, taktiež je na to treba upozorniť a dať možnosť zrušiť inštaláciu. V prípade odinštalácie, zas treba užívateľa upozorniť v prípade, že sú na danej službe závislé niektoré ďalšie služby. Ku každému nainštalovanému produktu existuje licencia, ktorá musí byť uložená a administrátorom zapracovaná do databázy takým spôsobom, aby systém mohol následne rozhodnúť o požiadavke na ďalšiu inštaláciu daného programu napr. podľa licenciou povoleného počtu inštalácii. Pri dostupnom softvéri treba tiež rozhodnúť o tom, či ide o verziu: b) Stabilnú - jedná sa o stabilný a dobre vyskúšaný softvér, ktorý sa mení iba vtedy, ak sa jedná o podstatné vylepšenie použiteľnosti alebo o dôležité bezpečnostné opravy c) Testovaciu - existujú prísne kritériá, ktoré musí balíček z nestabilnej (viď nižšie) distribúcie spĺňať, aby sa mohol dostať do testovacej distribúcie. Dôležité je tiež to, že pre testovaciu nie sú bezpečnostným týmom vydávané bezpečnostné aktualizácie. d) Nestabilnú - balíčky v nestabilnej sú najmenej vyskúšané a môžu byť zdrojom problémov, dosť vážnych na to, aby ovplyvnili stabilitu systému Je možnosť rozhodnúť, či bude možné inštalovať len stabilnú verziu a ostatné zakázať alebo aj niektorú z menej stabilných. V prípade vyskytnutia sa chyby počas inštalácie by malo byť možné vrátiť späť všetky zmeny vykonané počas inštalácie, kvôli stabilite systému. Pre jednoduchšiu prácu s aplikáciou je vytvorené užívateľské rozhranie, ktoré umožní jednoduchú prácu či už bežnému užívateľovi alebo administrátorovi. 2.4 Špecifikácia požadovaného riešenia Cieľom tejto časti je zaznamenať požiadavky na správanie sa systému vo forme prípadov použitia. Prípady použitia treba opísať na takej úrovni detailnosti, aby mali obe strany zadávatelia (zákazníci, v tomto prípade učiteľ) aj tvorcovia systému (tí, ktorí na základe vami vytvorenej špecifikácie budú pokračovať v projekte) jasnú a dostatočne presnú predstavu o tom, čo bude vytváraný systém robiť. V tejto časti sa rozpracujú jednotlivé biznis procesy identifikované v biznis analýze tak, že sa opíšu požiadavky diagramom prípadov použitia a zodpovedajúcim modelom údajov. Charakterizujte všetkých účastníkov, ktorí sa vyskytujú v modeli prípadov použitia BP 01 Príjem kníh do knižnice V prvom kroku sa iba snažte identifikovať všetky prípady použitia. Nezabudnite na to, že každý prípad použitia musí mať hodnotu pre používateľa (splní nejaký jeho cieľ). Až v druhom kroku sa snažte diagram rozmiestniť tak, aby bol prehľadný, aby spoločné časti opisov boli zhromaždené na jedno miesto (do jedného prípadu použitia). Využite prípady použitia identifikované v biznis analýze, ktoré môžete zjemniť. V diagrame prípadov použitia sa nezakresľujú prístupové práva používateľov. Prístupové práva používateľov je vhodné uviesť samostatne (napr. vo forme tabuľky). 12

14 UC01 Zaevidovanie knihy <<include>> Knihovník UC02 Zaevidovanie autora UC03 Vyhľadávanie v knihách Obr. 5. Model prípadov použitia pre BP01 Príjem kníh do knižnice. Na obr. 5 je znázornený diagram prípadov použitia, ktorý poskytuje pohľad na služby systému realizované pre biznis proces príjem kníh do knižnice. Diagram prípadov použitia treba opísať ako celok, vysvetliť spôsob štrukturovania prípadov použitia a tiež uviesť zaradenie do celkového pohľadu na systém (v prípade, že diagram rozpracúva nejakú časť modelu prípadov použitia). Netreba duplikovať informácie, ktoré budú nižšie (účastníci a samotné prípady použitia). Ďalej postupne opíšte stručne všetky prípady použitia a za každým diagramom uveďte logický model domény (model údajov) prislúchajúci príslušnému prípadu použitia). Podrobne opíšte niekoľko vybraných prípadov použitia z diagramu prípadov použitia (počet aj výber schváli cvičiaci). Na opis využite nasledujúcu tabuľku. r Identifikáto Názov Opis Priorita Vstup. podm. Výstup. podm. Používatelia Základná postupnosť Alternatívna postupnosť Poznámky Jednoznačný identifikátor (napr. UC01) Stručný názov Slovný opis 1 = vysoká Frekven Ako často sa v systéme použije 2 = stredná cia (denne, raz za rok, a pod.) 3 = nízka Vstupné podmienky, ktoré musia byť splnené Výstupné podmienky Kto ho používa Kr Činnosť ok Kr Činnosť ok 1.a Prípadné ďalšie poznámky Pre každý podrobne opisovaný prípad použitia navrhnite obrazovku (alebo niekoľko obrazoviek) používateľského rozhrania. Tú zaraďte do dokumentu ako obrázok a vložte ju hneď za príslušný prípad použitia. Ako ukážka je ďalej opis prípadu použitia Vydanie titulov (je súčasťou biznis procesu Požičiavanie kníh čitateľom) 13

15 Vydanie titulov Identifikáto UC02 r Názov Vydanie titulov Opis Knihovník vydá knihy čitateľovi podľa platných výpožičiek Priorita 1 = vysoká Frekvencia denne niekoľko desiatok až stoviek krát Vstup. podm. čitateľ si najneskôr pred 10 hodinami vybral z ponuky knihy, ktoré si chce požičať alebo mu najneskôr pred 10 dňami bolo odoslaná výzva na požičanie rezervovanej knihy Výstup. nie sú podm. Používatelia Základná postupnosť Alternatívna postupnosť Poznámky knihovník Kr Činnosť ok 1 Knihovník si vyberie, že chce vydať titul. 2 Systém zobrazí formulár na výber čitateľa. 3 Knihovník zadá meno a priezvisko čitateľa, ktorému chce vydať knihy. 4 Systém overí dobu platnosti preukazu pre vybraného čitateľa. 5 Systém zobrazí dočasne platné výpožičky pre vybraného čitateľa. Systém stanoví štandardnú dobu, dokedy treba knihy vrátiť. 6 Knihovník potvrdí platnosť údajov na formulári. 7 Systém vytlačí dokument o požičaní. Systém vytvorí trvalé výpožičky na všetky knihy zo zoznamu. Kr ok Činnosť 3.a Knihovník má možnosť vybrať čitateľa zo systémom ponúknutého zoznamu čitateľov, ktorí majú platné dočasné výpožičky. 4.a Ak preukaz nie je platný, pokračuje sa prípadom použitia UC Predĺženie platnosti preukazu. Po jeho ukončení pokračovanie v 5. 6.a Systém vytvorí dočasnú výpožičku na základe zmenených údajov, pôvodnú dočasnú výpožičku zruší. Pokračuje sa bodom 5. 6.b Ak čitateľ požiada, knihovník môže zmeniť štandardnú dobu vrátenia knihy. Pokračuje sa bodom 7. Štandardná doba vrátenia kníh sú 4 týždne. Predĺženie požičania je možné maximálne na 10 týždňov. Obr. 6 zobrazuje model údajov pre analyzovaný prípad použitia. Model údajov nižšie je len ukážkový a nezodpovedá prípadu použitia, ktorý sa opisuje vyššie. Titul Názov Rok vydania n 1 zodpovedá n Kópia titulu Evidenčné číslo 1 Žáner Názov prislúcha Obr. 6. Model údajov pre prípad použitia XXX. Na obr. 7 je prípad použitia UC02 Vydanie titulov vyjadrený podrobnejšie diagramom sekvencií. Knihovník aktivuje proces vydávania titulov. Zo zoznamu čitateľov vyberie čitateľa, ktorému chce 14

16 registrovať vydanie rezervovaných titulov Obr. 7. Diagram sekvencií pre prípad použitia UC Sumarizácia modelu údajov Táto časť obsahuje sumarizáciu logického pohľadu na uchovávané údaje. Identifikuje základné entity, ich atribúty a vzťahy v zmysle analýzy požiadaviek pri jednotlivých prípadoch použitia uvedených v predchádzajúcej časti. Uveďte slovný opis modelu údajov na konceptuálnej úrovni tak, ako by ste ho niekomu vysvetľovali. Zaujímavé sú vzťahy medzi entitami (v tomto diagrame sa neuvádzajú atribúty, resp. uvádzajú sa iba významné atribúty). Ďalej definujte ďalšie atribúty a priložte vytlačený diagram aj s atribútmi entít (nižšie je uvedený len jeden diagram, ktorý je neúplný, slúži len na ilustráciu). 15

17 Čitateľ priezvisko meno 0..n adresa adresa datum zapisania 1 vykoná 0..n požičiava Rezervácia dátum vytvorenia sa vzťahuje 0..n 1 Kópia titulu evidenčné číslo stav 0..n 1 Titul názov poznámka rok vydania zodpovedá 0..n 1..n definuje Katalóg 1 0..n Kľúčové slovo slovo CD operačný systém Časopis číslo vydavateľ Kniha ISBN vydavateľ počet strán napísal 1..n 0..n Autor meno priezvisko Obr. 7. Logický model údajov informačného systému knižnica. Ďalej opíšte všetky entity diagramu modelov údajov. Aspoň pre dve entity vytvorte stavový diagram. 16

18 2.5.1 Kópia titulu Kópia titulu je konkrétny exemplár knihy, časopisu alebo CD nosiča. Kópia je zaevidovaná v knižnici a čitatelia si ju môžu požičiavať. Stavový diagram entity je uvedený na nasledujúcom obrázku (obr. 4). UC01 Zaevidovanie knihy do systému Dostupná UC21 Zaevidovanie pôžičky knihy Požičaná UC22 Zaevidovanie vyradenia knihy Stratená UC22 Zaevidovanie vyradenia knihy Vyradená Obr. 8. Stavový diagram entity Kópia titulu 17

19 2.5.2 Titul Pod titulom rozumieme knihy, časopisy a CD nosiče, ktoré sa v knižnici požičiavajú. Ide o zovšeobecnenie a v modeli sme ho zaviedli z dôvodu sprehľadnenia a tiež preto, že je možné, že v budúcnosti pribudnú iné typy titulov (DVD a video pásky). Titul nie je konkrétny exemplár knihy, časopisu, atď., ale predstavuje tie informácie, ktoré sú spoločné pre všetky exempláre titulu.. pre V budúcnosti môže pribudnúť iný typ titulov. Na obr. 9 je uvedený stavový diagram pre dátovú entotu titul. Objednaný Objednanie titulu Nezaevidovaný Prijatie došlých titulov K dispozícii na požičanie UC01 Zaevidovanie knihy UC23 Výzva na vypožičanie knihy Rezervovaný Bez rezervácií UC24 Rezervovanie knihy UC22 Zaevidovanie vyradenia knihy Obr. 9. Stavový diagram entity Titul 2.6 Ďalšie požiadavky V tejto časti treba špecifikovať relevantné nefunkcionálne požiadavky na vytváraný produkt. Treba vychádzať z časti 0. Vlastnosti produktu, pritom tieto vlastnosti treba rozpracovať na konkrétne požiadavky na vytvárané riešenie. Ak je požiadaviek viac, je vhodné ich zoskupovať a prípadne aj číslovať hierarchicky. Každá nefunkcionálna požiadavka by mala mať aspoň názov a opis. Nemajte veľké oči a nesnažte sa pokryť všetky požiadavky metodológie len preto, aby ste sa ku nim vyjadrili. Menej je niekedy viac aj pre realizovateľnosť produktu. 18

20 3 Akceptačné testy Cieľom akceptačných testov je preveriť, či vytvorený softvérový systém spĺňa akceptačné kritériá. Akceptačné testy (alebo aspoň akceptačné kritériá!!!) treba navrhnúť čím skôr (najlepšie už pri podpise zmluvy). Ak sa na špecifikáciu požiadaviek využívajú prípady použitia, otestovanie funkcionality sa opiera práve o prípady použitia. Akceptačné testy (v ideálnom prípade) navrhuje zákazník. Výsledky akceptačných testov pomáhajú rozhodnúť o akceptovaní/neakceptovaní vytvoreného systému. Výsledky testov sú často podkladom na podpísanie preberacieho protokolu. Nasledujúci zoznam akceptačných testov určuje dohodnutý postup otestovania vytvoreného systému. Predpokladá sa, že akceptačné testy vykoná zákazník. D I Prípad použitia e Rozhrani 2 Náz ov Vydanie titulov UC02 Úroveň splnenia testu IS/ Čitateľ/ Výpožičky Účel Overenie správnej funkčnosti vydania titulov. Musí Mal by Mohol by Vstupné podmienky Čitateľ je evidovaný v knižnici a má platný preukaz. Výstupné podmienky rok K Čitateľ má priradené vypožičané tituly. Akcia Očakávaná reakcia Skutočná reakcia 1 Vyplnenie výberového kritéria pre výber čitateľa meno a priezvisko. Systém zobrazí údaje o čitateľovi (ak je čitateľov s rovnakým menom viac, ponúkne výber jedného zo zoznamu spolu s číslom preukazu). 2 Potvrdenie čitateľa. Systém zobrazí informáciu o platnosti preukazu a zoznam dočasných výpožičiek. 3 Preverenie správnosti dočasných výpožičiek a ich potvrdenie. Systém zaeviduje výpožičky (dočasné výpožičky nahradí trvalými) a vytlačí dokument o vypožičaní. Okrem funkcionálnych testov pokúste sa navrhnúť 19

21 aspoň jeden scenár na otestovanie nefunkcionálnych požiadaviek (uvedených v časti 2.3). 20

22 4 Revízia a doplnenie špecifikácie požiadaviek Cieľom tejto kapitoly je na základe statickej prehliadky doteraz vytvoreného dokumentu a prezentácie revidovať špecifikáciu požiadaviek (model prípadov použitia a model údajov). 4.1 Sumarizácia modifikácií a doplnkov špecifikácie požiadaviek Prehľadne a presne (najlepšie v tabuľke) uveďte všetky navrhované zmeny a doplnky oproti kapitole 2. V prípade podstatných zmien (po dohode s cvičiacim) uveďte v ďalších častiach znovu celú dokumentáciu k špecifikácii požiadaviek. Zároveň doplňte návrh fyzického modelu údajov. 4.2 Fyzický model údajov Uvedie sa model údajov, v ktorom budú rozriešené vzťahy M ku N, identifikované primárne a cudzie kľúče a určené typy pre jednotlivé atribúty každej dátovej entity. +PK_ID-citatel FCitatel <<PK>> ID : Integer priezvisko : String name : String String datum-zapis : Date 1 +PK_ID-citatel 1 +FK_ID-citatel FVypozicka <<PK>> ID : Integer datum-vytvorenia : Date 0..n 0..n datum-vydania : Date 1 datum-vratenia : Date <<FK>> ID-citatel : Integer <<FK>> ID-kopia : Integer +PK_ID-citatel +FK_ID-kopia +PK_ID-kopia 1 FKopia_titulu <<PK>> ID : Integer evid-cislo : Integer stav : String <<FK>> ID-titul : Integer +FK_ID-titul 0..n +FK_ID-citatel FAdresa 1 <<PK>> ID : Integer ulica : String mesto : String psc : Integer <<FK>> ID-citatel : Integer +FK_ID-citatel 0..n FRezervacia <<PK>> ID : Integer Datum-vytvorenia : Date <<FK>> ID-citatel : Integer <<FK>> ID-titul : Integer +FK_ID-titul +PK_ID-titul 0..n 1 +PK_ID-titul 1 FTitul <<PK>> ID : Integer nazov : String rok-vydania : Integer poznamka : Integer Obr. 10. Časť fyzického modelu údajov. 21

23 5 Architektúra systému Uvedie a vysvetlí sa návrh architektúry budúceho systému. Identifikujú sa základné moduly a ich vzájomné väzby. Každý modul sa stručne slovne opíše a vzájomné väzby sa vyjadria obrázkom. Môžete sa vyjadriť aj k otázkam závislosti architektúry vytváraného informačného systému od organizačnej štruktúry. Takisto sa v tejto časti môžete vyjadriť aj k dátovej architektúre (vzťah databáz a jednotlivých modulov), resp. obrázok môže zahŕňať funkčné aj údajové zložky systému. Dôležité je primerane vysvetliť význam jednotlivých prvkov v diagrame (typy čiar, typy uzlov v grafe) uveďte v časti 0.6 Notácia. Treba tiež prehľadne (napr. tabuľka, matica, vymenovanie) uviesť prepojenie prípady použitia moduly systému. Na základe tohto prepojenia je možné napr. skontrolovať, či sa na niektorý z prípadov použitia nezabudlo. 22

24 6 Zhodnotenie Zhodnotí sa celý projekt vzhľadom na ciele (časť 0.1). Treba uviesť sumarizáciu, čo sa podarilo dosiahnuť, kde sú problémy, resp. alternatívy riešenia. Čo by ste riešili ináč, keď sa na problém pozeráte s odstupom času. Mali by ste tiež uviesť, čo bude ďalej s týmto projektom. Predstavte si, že tento dokument by mal slúžiť ďalšej skupine ľudí, ktorá bude pracovať na podrobnom návrhu, prípadne implementácii systému. V zhodnotení treba zhrnúť najdôležitejšie skutočnosti, ktoré by mohli ovplyvniť ďalšie etapy vývoja systému. 23

25 7 Odkazy a zdroje 1. Gully, A. & Signoriny, A., The indexable Web is more than 11.5 billion pages. Dostupné na: (prezerané 1. novembra 2007). 2. Digimind, január 2006, Discover and exploit the Invisible Web for competitive intelligence. Access a wealth of top quality hidden resources, Dostupné na: (prezerané 1. novembra 2007). 3. Chen, R., et al., University of California február 2007, Strategic Use of Information Technology - Google. Dostupné na: (prezerané 1.novembra 2007) 4. W3C recommendation 24 December 1999, The global structure of an HTML document, HTML 4.01 Specification.Dostupné na: (prezerané 2. novembra 2007) 5. Sherman CH. & Price G. The Invisible Web : uncovering information sources search engines can t see. Medford, New Jersey, Information Today, Inc., ??????? HTML a CSS treba pozriet v kniznici este raz, ako sa to presne volalo 7. Tittel, E., et al., Foundations of World Wide Web Programming with HTML and CGI. IDG Books Foster City, California, Worldwide, Inc.,