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: 2007/2008

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 HTML ako aplikácia SGML Sémantika HTML XHTML XML Extensible Markup Language XHTML a XML Sémantika XHTML Niektoré ďalšie aplikácie XML Ďalšie webové štandardy CSS Cascading Style Sheet DOM + ECMAScript (mozno len spomenut, ze take daco je, ale pre vyhladavace to nema zmysel, pretože javascript neriešia), Nástroje na validáciu zdrojového kódu webových stránok 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 Sumarizácia modelu údajov Ď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ť WWW (World Wide Web). 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 webové adresáre. 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ú indexovaný, tzv. viditeľný a ten, ktorý nemajú, tzv. neviditeľný. Podľa publikácie [1] bolo na internete približne 11,5 miliardy indexovatelných stránok v roku To je ale zanedbateľné číslo v porovnaní s množstvom stránok, ktoré tvoria tzv. neviditeľný web, teda taký, ku ktorému sa používateľ nedokáže dostať pomocou bežných vyhľadávačov. 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 indexovaná je, že neexistuje žiadny na ňu ukazujúci odkaz z niektorej inej už indexovanej 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 nedostane. 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ích strojov 3. Syntakticky chybný dokument síce môže byť viditeľný pre vyhľadávače, ale používateľ, ktorý si ho zobrazí nemusí byť schopný ho prehliadať. Prehľadávač totiž nedokáže správne rozanalyzovať takýto dokument a pri zobrazení dôjde k jeho znehodnoteniu. Ď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 jazyku 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. Pomocou 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ší) nadpisy väčším fontom, ako ti menej 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 dizajnérov 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é hádam 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 ang. Search engines Result Pages (SERP) 4 slov. kaskádové štýly 2

4 o štandardizáciu HTML aj CSS, tieto prvky je stále možné používať a každý prehliadač na ne reaguje inak [6]. Ak sa programátorovi podarí konečne vytvoriť webovú 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 neindexujú automaticky. Príkladom je AltaVista 1. Najobvyklejším znakom, ktorý prezradí, že ide o automaticky generovaný obsah je otáznik, 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í 2 (pavúk je iný názov pre prehľadávacieho 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 indexovať 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 číslo 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 súboru 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árskej práce, ktorej zadanie je na začiatku tohto dokumentu. V dokumente bude opísaná problémová oblasť web, syntax html, sémantika 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 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, kontrolu 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 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 Dnes sa na tvorbu webových stránok používajú dva jazyky. Prvým je HTML, ktorý je vytvorený pomocou SGML a druhým je XHTML, ktorý je vytvorený oveľa novším, o 12 rokov mladším štandardom XML. Snahou je prejsť z už zastaralej HTML na XTHML, ktorá prináša niekoľko výhod. Je napr. akceptovaná vo väčšom množstve koncových zariadení. Hlavnou výhodou ale je, že sada elementov, ktorá je daná špecifikáciou, je rozšíriteľná o nové vlastné elementy. Nie všetky prehľadávače ale podporujú tento pomerne nový štandard. Príkladom takého je aj Internet Explorer (posledná verzia je 7), ktorý so svojimi 77.87% 1 trhu značne ovplyvňuje vývojárske prostredie. Preto aj HTML je stále aktuálny štandard. A v nasledujúcich podkapitolách si ho vysvetlíme. Naopak XHTML už dnes podporujú napr. Firefox, Safari alebo Opera. 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 štandardizá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 konzorcia sú spoločnosti ako Microsoft Corporation, AOL LLC (odkúpil Netscape v roku 1999) alebo Google, Inc. 2. 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 tvorbu jednotný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 sémantickej 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í, pričom aby boli aplikácie schopné pracovať so SGML dokumentom je najdôležitejšia z nich DTD (Document Type Definition). DTD - Document Type Definition DTD je formálny opis štruktúry konkrétnej triedy dokumentov [7] Povedané inak, DTD deklaruje elementy, ktoré sa v môžu vyskytnúť v danej triede dokumentov a zároveň štrukturálne vzťahy medzi týmito elementmi, 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. Veľmi jednoduchým príkladom DTD môže byť nasledujúce zadefinovanie elementu kontakt spolu s elementmi celemeno a telefon: <!ELEMENT kontakt <!ELEMENT celemeno <!ELEMENT telefon - - ( celemeno, telefon*)> - - ( krstne, priezvisko)> - - ( mobil pevnalinka)> SGML nie je schopné definovať význam (sémantiku), ktorý by opísal, čo predstavuje daný element. Na druhej strane ale jeho meno, 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. Príkladom takejto je aj špecifikácia pre HTML 4.01 dostupná z Každý element, ktorý môžeme pri tvorbe stránok používať a je zadeklarovaný v DTD pre HTML 4.01 má v tejto špecifikácii vysvetlené

6 použitie, a tie, ktoré majú aj sémantický význam ho tu majú vysvetlený tiež. Touto špecifikáciou by sa potom mali riadiť prehliadače a iné aplikácie spracúvajúce HTML 4.01 dokumenty. Aby bolo možné pre aplikáciu rozoznať jednotlivé elementy SGML dokumentu a správne ho rozobrať, je potrebné aby na začiatku každého bola určená DTD pre daný dokument. Toto sa obyčajne robí referenciou, ktorá sa nachádza v SGML DOCTYPE deklarácii. Jej syntax je nasledujúca: <!DOCTYPE root-tag [PUBLIC public-id alebo SYSTEM] system-id [ - tu môžu nasledovať nejaké ďalšie deklarácie značiek]> 1 Význam jednotlivých častí: root-tag: je to prvý element v dokumente PUBLIC: znamená, že DTD je určená pre verejnosť a musí byť zároveň určené public-id SYSTEM: DTD je v súkromné, vtedy public-id nemusí byť určené ale mal by nasledovať system-id public-id: odkaz na zvolenú DTD všeobecne známym menom, obyčajne definovaným v súvisiacom štandarde system-id: URI určené na identifikovanie DTD HTML ako aplikácia SGML V súčasnosti najnovšia špecifikácia HTML má verziu DTD pre túto verziu má tri rôzne formy: strict sú vylúčené prezentačné atribúty a elementy, ktoré chce W3C postupne vyradiť, ako podporu CSS 2 transitional prezentačné atribúty a elementy vylúčené nie sú 3 frameset je identická s transitional, ale element body je nahradený elementom frameset 4 V dokumente môže byť typ dokumentu zadefinovaný ako v nasledujúcej deklarácii, podľa ktorej bude napr. webový prehliadač vedieť, že zobrazovaný dokument, na ktorého začiatku sa deklarácia nachádza, bol vytvorený práve DTD HTML 4.01, konkrétne jeho strict formou: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" " V DTD sú určené všetky elementy, ktoré vývojár môže použiť a prehliadač by mal byť schopný rozoznať. Ako príklad si uvedieme element TITLE. Ukážeme si jeho syntaktický význam ale aj sémantický a povieme si, kde sú špecifikované. Zápis tohto elementu v HTML 4.01 Strict DTD [8] spolu s niektorými výňatkami vyzerá takto: <!ELEMENT TITLE - - (#PCDATA) -( SCRIPT STYLE META LINK OBJECT )> <!ATTLIST TITLE %i18n> <!-- nasledujú niektoré výňatky z DTD potrebné na pochopenie elementu TITLE --> <!ENTITY % i18n "lang %LanguageCode; #IMPLIED -- language code -- dir (ltr rtl) #IMPLIED -- direction for weak/neutral text --" > <!ELEMENT HTML O O ( HEAD, BODY )> <!ELEMENT HEAD O O ( TITLE & BASE? ) + ( SCRIPT STYLE META LINK OBJECT )> Z tejto definície je vidieť, že root element HTML musí obsahovať najprv element HEAD a potom element BODY. Element HTML, rovnako ako HEAD nemusí mať otváraciu ani uzatváraciu značku (hovorí o tom písmeno O ako optional za názvom elementu v poradí otváracia, uzatváracia značka). Element HEAD musí obsahovať element TITLE a môže obsahovať element BASE, pričom na ich poradí nezáleží. A nakoniec element TITLE. Tento musí mať aj otváraciu aj zatváraciu značku (znak - ). V dokumente sa musí nachádzať práve raz, keďže HTML musí obsahovať raz HEAD a ten musí obsahovať jedenkrát TITLE

7 Môže Obsahovať parsovateľný text (je to element #PCDATA), pričom nemá určené, ktoré elementy sú povolené, preto sú všetky sú zakázané. A zároveň nesmie obsahovať ani elementy SCRIPT, STYLE, atď., ktoré sú povolené pre jeho rodičovský element HEAD. Keby neboli tieto elementy zakázané explicitne, boli by povolené. Element TITLE teda môže obsahovať len text bez akýchkoľvek značiek. V DTD sú určené aj atribúty, ktoré sa môžu používať pre TITLE. Sú nimi lang a dir, ktorých typ už nejdem rozoberať. Ako vidieť TITLE je definovaný veľmi presne. Je jasne určené, koľkokrát sa môže nachádzať v dokumente, kde sa môže resp. musí nachádzať, či musí byť označený začiatok a koniec elementu, ale aj atribúty, ktoré môžu špecifikovať jeho konkrétnu inštanciu. Podobne je zadefinovaný každý element, ktorý sa môže v HTML používať. Význam a dôležitosť tohto elementu ale z DTD jasný nemusí byť. Tie ako bolo spomenuté skôr sú zahrnuté v špecifikácie HTML 4.01 spolu s DTD. Pre TITLE je sémantický význam určený takto: Autori by mali používať element TITLE na identifikáciu obsahu dokumentu. Pretože používateľom sa často zdá dokument mimo kontext, mali by autori poskytovať obsahovo výstižné titulky. Tak namiesto titulku Úvod, ktorý neposkytuje dostatočné kontextové pozadie, by mali použiť titulok ako Úvod do stredovekého včelárstva. [4] Z tohto vyplýva, že názov stránky, ktorý neskôr ako dúfame priláka návštevníkov bude zapísaný práve medzi otváracou a zatváracou značkou elementu TITLE. Podľa toho, či elementy môžu obsahovať iné elementy rozlišujeme dva typy: kontajnerové a prázdne. Viaceré publikácie uvádzajú, že toto rozdelenie je na základe toho, či element má otváraciu a zatváraciu značku. Toto tvrdenie je ale mylné, pretože v HTML už od verzie 1 je napr. element HEAD špecifikovaný tak, že nemusí mať ani otváraciu ani zatváraciu značku, pritom sa uvádza ako jeden zo základných kontajnerových elementov. Toto rozdelenie je dôležité pochopiť, kvôli porozumeniu toho ako prehliadače chápu určenie veľkosti, pozície a pod. pri vnorených elementoch. Pre vyhľadávacie stroje je ale dôležitý hlavne konkrétny obsah elementov, pričom rôznym elementom je priradená rôzna dôležitosť. Napr. TITLE má väčšiu váhu ako H6, ale zároveň oba by sa mali obsahovo významne dotýkať dokumentu, resp. jeho časti, ku ktorej sú viazané. Tomuto sa budeme venovať neskôr v časti venovanej vyhľadávacím strojom Sémantika HTML Pôvodne HTML nebol vytváraný ako sémantický jazyk. Preto jeho možnosti významovo presne určiť typ značky sú obmedzené. Rozdelenie elementov Vezmime si ako príklad značku pre nadpis. Hn nehovorí o tom, o aký nadpis ide. Či ide o názov knihy, alebo filmu alebo je to názov zjazdovky v lyžiarskom stredisku. Akokoľvek, určitá významová hodnota tu je. Je určené, že je to nadpis, tým pádom by mal byť obsahovo zviazaný s nadchádzajúcim odstavcom, resp. celým textom článku. Takisto je určené, že obsah H1 je dôležitejší ako H6. Niektoré elementy však majú určený význam úplne presne a naopak iné nemajú vôbec. Podľa toho je možné rozdeliť HTML elementy do nasledujúcich skupín: štrukturálne: -DIV, SPAN, OL, UL, LI, DL, P sémantické: -A, ADDRESS, BLOCKQUOTE, Q, DEL, INS, H1- H6, DT, DD, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR a ACRONYM prezentačné: -TT, I, B, BIG, SMALL, STRIKE, S, U, HR, PRE, SUB, SUP, EM, STRONG obrázky a iné médiá -IMG, MAP, AREA, PARAM, OBJECT, APPLETS iné: -značky pre tabuľky, formuláre a ďalšie tu nespomenuté Štrukturálne značky slúžia na definovanie štruktúry dokumentu. Napríklad DIV ohraničuje nejaký logický blok dokumentu, zatiaľ čo SPAN iba úsek vnútri riadku. Tieto dva elementy nevyžadujú žiadne prezentačné odlíšenie, ale spolu s atribútmi id a class, umožňujú pomocou kaskádových štýlov dodatočne určiť vizuálnu stránku danej štruktúry. To isté platí aj pre ostatné elementy z tejto skupiny. Samotné elementy tejto skupiny nemajú definovaný žiadny význam pre svoj obsah. 6

8 Podľa špecifikácie HTM 4.01 od W3C 1 sú jednou skupinou značiek tzv. frázové značky. Pomocou týchto je možné pridať ďalšiu štruktúru dokumentu, ale zároveň aj prezentačne odlišujú ohraničený obsah (záleží na prehliadači, ako ho odlíši). Okrem EM a STRONG (dávajú dôraz na obsah, ale neurčujú, čo ním je) však majú ostatné elementy aj určený význam svojho obsahu (CITE obsahuje odkaz na zdroj, CODE obsahuje počítačový kód, atď.). Preto som elementy z tejto skupiny prerozdelil tak, že EM, STRONG sú v skupine prezentačných elementov a ostatné v skupine sémantických. V skupine sémantických elementov sú zaradené elementy, podľa ktorých vieme určiť, čo tvorí ich obsah. Hoci môžu obsahovať všetky riadkové elementy 2 (v DTD ich označuje entita %inline) vrátane obrázkov a formulárových elementov, autor by ich mal vložiť medzi otváraciu a zatváraciu značku, len pokiaľ naozaj majú význam, ktorý značka určuje. Vďaka týmto elementom môže dokument spracúvať aplikácia, ktorej cieľom je získať nejaké konkrétne informácie napr. kontaktné údaje, alebo zozbierať všetky ukážky zdrojového kódu a pod.. Prezentačné elementy určujú ako má byť ich obsah zobrazený. Niektorým to určuje špecifikácia, iným špecifikácia len určuje, že majú byť odlíšené. Pre tieto elementy nie je nijak určené, čo by mali obsahovať. Názov skupiny obrázky a iné média hovorí sám za seba. Ich jediný sémantický význam je, že vkladajú do dokumentu nejaký objekt, prípadne umožňujú definovať oblasti nad daným objektom, slúžiace na interakciu s používateľom. Skupinu iné nejdem rozpisovať, pretože obsahujú pomerne veľa elementov, ktoré nie sú podstatou sémantickej kontroly v obsiahnutej v tejto práci. A myslím si, že na základe predchádzajúceho vysvetlenia dokáže čitateľ tieto elementy správne kategorizovať. Sémantika môže byť dodaná do dokumentu aj pomocou tzv. Mikroformátov 3. Podľa definície je to množina jednoduchých otvorených dátových formátov, založených na existujúcich a verejne prijatých štandardoch [10]. Použitie Mikroformátov vyzerá asi tak, že kombináciou atribútov id, class (definovaním ich správnych mien) a blokových, a riadkových elementov dokážeme vytvoriť formát, ktorý odpovedá niektorému jednoduchému otvorenému štandardu. Príkladom mikroformátu je napr. hcard, ktorý je založený na štandarde vcard 4. Slúži na označenie a identifikovanie jednotlivých častí kontaktných údajov. Ďalším príkladom je hcalendar založený na icalendar 5 a popisuje udalosti. Mikroformáty umožňujú vniesť do HTML oveľa významnejšiu sémantiku ako hociktorý element sám o sebe. Rozdelenie atribútov HTML 4.01 má okolo 120 rôznych atribútov. Tieto slúžia na odlíšenie jedného elementu alebo celej triedy elementov od ostatných elementov, tj. bližšie určujú vlastnosti konkrétneho elementu. Do tohto množstva patria atribúty, ktoré môžu byť rozdelené nasledovne: sémantické: určujú presnejšie sémantiku daného elementu -hreflang určuje, že odkaz je na dokument s konkrétnym jazykom opisné: popisujú obsah elementu -title je pomocný titulok, ktorý je možné použiť pri takmer všetkých elementoch prezentačné: definujú prezentačnú stránku elementu -height určuje výšku pre IMG, OBJECT, IFRAME vzťahové: určujú vzťah k inému dokumentu -rel popisuje typ vzťahu aktuálneho dokumentu k odkazu špecifikovanému atribútom href identifikačné: identifikujú element -class určuje triedu, do ktorej element patrí atribúty správania: ohraničujú alebo bližšie špecifikujú pre prehliadače ako sa má element správať -maxlength definuje, koľko znakov môže byť maximálne zadaných v textovom poli Do týchto šiestich skupín je možné rozdeliť všetky atribúty. Pri každej je použitý len jeden príklad ako ukážka. Z týchto skupín so sémantikou a jej správnosťou úzko súvisia sémantické, opisné a vzťahové. Ako sme si ukázali pri Mikroformátoch, aj identifikačné atribúty sa dajú použiť na vytváranie sémantických ang. inline elements 3 ang. Microformats

9 štruktúr. Ich základnou vlastnosťou však je len identifikovať element vrámci dokumentu. Nijak inak neurčujú jeho obsah. Správne použité atribúty môžu pomôcť vyhľadávacím strojom identifikovať obsah a zvýšiť hodnotenia pre spracúvanú webovú stránku. 1.2 XHTML XML Extensible Markup Language XHTML a XML Sémantika XHTML Niektoré ďalšie aplikácie XML smil, vml, mathml, svg 1.3 Ďalšie webové štandardy CSS Cascading Style Sheet Treba len trosku spomenut, ze daco take je a velmi zhruba, co to robi DOM + ECMAScript (mozno len spomenut, ze take daco je, ale pre vyhladavace to nema zmysel, pretoţe javascript neriešia), 1.4 Syntaktická validácia zdrojového kódu webových stránok Syntaktická validita html stránky má niekoľko výhod: vyhovovanie špecifikovanej DTD môže byť správne spracovaná parserom jednoduchšie spracovanie prehľadávacím strojom To že dokument vyhovuje jednej konkrétnej DTD môže byť napr. výhodou ak robíte stránky pre niekoho iného. V prípade, že sa zákazník v budúcnosti rozhodne dať upraviť tieto stránky inému vývojárovi, ten bude vedieť presne akú štruktúru môže očakávať. Všetky aplikácie, ktoré nejakým spôsobom spracúvajú zdrojový kód webových stránok musia mať implementovaný parser. Napr. prehľadávač tak vie rozhodnúť, čo ešte patrí do nadpisu a čo už nie. Vďaka tomu dokáže stránku správne zobraziť. Pokiaľ teda html dokument odpovedá niektorej verejne známej špecifikácii HTML, mal by byť takpovediac prenosný a aspoň štruktúrne zobrazený vo všetkých prehliadačoch rovnako. Pokiaľ sa na vytvorenú stránku dostane vyhľadávací stroj (to väčšinou tvorca stránky chce), dokáže správne analyzovať dokument a napr. si vytvoriť jednoduchý obsah podľa nadpisov, prípadne vyextrahovať kľúčové slová. To potom môže pomôcť pri získavaní návštevníkov, na ktorých bola stránka cielená. Nehovoriac o tom, že bude mať naša stránka lepšie hodnotenie a tým pádom bude aj na vyšších priečkach vo výsledkoch vyhľadávača Princíp syntaktickej validácie Či už ide o XHTML alebo HTML alebo akýkoľvek iný jazyk, princíp syntaktickej validácie je rovnaký. Vykonáva sa počas procesu ktorý sa nazýva parsovanie: Parsovanie je proces štruktúrovania lineárnej reprezentácie vzhľadom na určenú gramatiku. [9] Pričom lineárna reprezentácia je v našom prípade zdrojový kód kontrolovanej stránky. Gramatiku zas predstavuje DTD určená pre túto stránku. Z nej sa dá vytvoriť nekonečne veľa rôznych dokumentov tej istej triedy, teda (X)HTML stránok. Techník parsovania je niekoľko základnými sú zhora-nadol a zdola-nahor, ktoré sa môžu používať v kombinácii s niektorou ďalšou metódou. Pokiaľ vás táto téma zaujíma, odporúčam knihu Techniky Parsovania: Praktická Príručka [9] alebo jej druhú edíciu, ktorá v čase písania tejto práce ešte nebola dostupná. 8

10 Pokiaľ počas štruktúrovania dokumentu parser natrafí na nezrovnalosť s gramatikou, ktorou sa má dokument riadiť, bude táto nezrovnalosť označená za chybu. Príkladom môže byť, že element TITLE nebude uzatvorený Nástroje na syntaktickú validáciu zdrojového kódu webových stránok Na validáciu SGML dokumentov existuje niekoľko nástrojov. Asi najznámejším je OpenSP, SGML analyzátor založený na analyzátore SP od Jamesa Clarka. Tento ale dokáže skontrolovať len syntax dokumentu, ktorá je daná DTD. Teda napr. pokiaľ nebudem mať uzatvorenú značku, ktorá zatváraciu značku musí mať, hierarchia elementov v dokumente nebude vyhovovať špecifikácii, prípadne použijem iný atribút ako je v konkrétnom prípade povolený. Nasledujúcu chybu ale tento nástroj odhaliť nedokáže: <img src="obrazok.gif" width="12.5" alt="obrazok"> Spomenutá chyba je v atribúte width, ktorý podľa špecifikácie môže mať dve prípustné hodnoty: nn určuje šírku ako konkrétny počet pixlov nn% - určuje šírku pomocou percentuálneho pomeru k dostupnému miestu (to väčšinou znamená k veľkosti rodičovského kontajnera) Hodnota teda nemôže byť 12.5, pretože je to aj z hardvérového hľadiska nezmysel. Nie je možné zobraziť pol pixlu. Prehľadávače ale toto prehliadnu a šírku upravia na najbližšiu vhodnú. Akokoľvek, toto bol len jeden príklad a kontrolovať je treba aj takéto chyby. Riešením je napr. HTML Tidy od Dava Raggetta, ktorý takéto chyby odhalí a upozornení na ne. Tento nástroj dokáže niektoré jednoduché chyby aj automaticky opraviť. Oba spomenuté nástroje sú len jedným z mnohých existujúcich riešení. Ja ale použijem na syntaktickú validáciu zdrojového kódu práve tieto dva a to preto, lebo aj samotné W3C používa vo svojej Službe na Validáciu Značkovania (Markup Validation Service) 1 obe spomenuté. 1.5 Sémantická validácia zdrojového kódu webových stránok pár riadkov popisat semanticky web, mozno nejake zakladne standardy, ktore sa vyuzivaju pri plnohodnotnej semantickej kontrole a potom spomenut, ze kvoli takejto zlozitosti ja budem len kontrolovat, ci text medzi otvaracim a zatvaracim tagom, a nadpis stranky na ktoru ukazuje su rovnake 1.6 Prehliadače 1.7 Vyhľadávacie stroje Optimalizácie webových stránok pre vyhľadávacie roboty Automaticky generovaný obsah 1.8 Citlivosť osobných údajov zverejňovaných na webe Zverejňovanie osobných údajov 1 9

11 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. 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 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 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

12 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. 11

13 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 (odstránenie zamestnanca z databázy) Pridanie, správa, využívanie a vyradenie softvéru z databázy: 12

14 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 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. 13

15 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. 14

16 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). 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ť 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 15

17 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: 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 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. 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. 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. 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). 16

18 UC01 Zaevidovanie knihy <<include>> Knihovník UC02 Zaevidovanie autora 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. Identifikáto Jednoznačný identifikátor (napr. UC01) r Názov Stručný názov Opis Priorita Vstup. podm. Výstup. podm. Používatelia Základná postupnosť Alternatívna postupnosť Poznámky k k Slovný opis 1 = vysoká 2 = stredná 3 = nízka Frekven cia Vstupné podmienky, ktoré musia byť splnené Výstupné podmienky Kto ho používa Kro Činnosť Kro UC03 Vyhľadávanie v knihách Činnosť 1.a Prípadné ďalšie poznámky Ako často sa v systéme použije (denne, raz za rok, a pod.) 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) 17

19 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 registrovať vydanie rezervovaných titulov 18

20 2.5 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). 19

21 Č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. 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). 20

22 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 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. 21

23 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 2.6 Ďalšie poţiadavky, 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. 22

24 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. I 2 Názo Vydanie titulov D v Prípad použitia UC02 Úroveň splnenia testu Musí Mal by Mohol by Rozhranie IS/ Čitateľ/ Výpožičky Účel Overenie správnej funkčnosti vydania titulov. Vstupné podmienky Čitateľ je evidovaný v knižnici a má platný preukaz. Výstupné podmienky Čitateľ má priradené vypožičané tituly. K rok 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 3 Preverenie správnosti dočasných výpožičiek a ich potvrdenie. dočasných výpožičiek. 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úť aspoň jeden scenár na otestovanie nefunkcionálnych požiadaviek (uvedených v časti 2.3). 23

25 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 1 +FK_ID-citatel +PK_ID-citatel FVypozicka +FK_ID-kopia <<PK>> ID : Integer datum-vytvorenia : Date 0..n 0..n datum-vydania : Date datum-vratenia : Date <<FK>> ID-citatel : Integer <<FK>> ID-kopia : Integer +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 0..n +PK_ID-titul +PK_ID-titul 1 FTitul 1 <<PK>> ID : Integer nazov : String rok-vydania : Integer poznamka : Integer Obr. 10. Časť fyzického modelu údajov. 24