|
Databáze Integritní omezení
Osoba/sluzby - 1=objednané, 0=žádné objednané Triggery
email - kontrola validnosti při zadávání Slovní popis modelu Datový model databáze je nakreslen ve standardním ER modelu a z toho vyplývají významy jednotlivých značek (unikátnost atributu, vztahy atd.) Osoba
ID_osoby - přezdívka či username objednavka
mail - email, kam doručovat objednaná data (může být odlišný od mailu osoby) Data
ID_veliciny - určuje měřenou veličinu v rámci jedné stanice Snimky
ID_kamery - určuje kameru v rámci stanice (je-li jich více) Stanice
ID_stanice - unikátní ID přidělené měřicí stanici Cidlo
ID_cidla - unikátní ID přidělené čidlu Prevod již naměřených dat ze starého systému do nově navržené databáze Data jsou ve starém systému uložena v následující podobě Pro každou stanici existuje adresář, ve kterém jsou soubory pojmenované datumem a časem (např. 200405051124.tar.gz). Každý soubor je tar archiv zakomprimovaný algoritmem gzip a obsahuje pro každou měřenou veličinu jeden soubor s hodnotami naměřenými od posledního předcházejícího souboru. Soubor je tvořen dvěma sloupci oddělenými čárkou. V prvním sloupci je unixový čas, kdy byla hodnota naměřena a v druhém sloupci je hodnota samotná. Protože je možné, že v rámci jedné sekundy byly pořízeny dvě hodnoty a mají tedy uveden stejný čas měření, při převodu do databáze se použije jen jedna hodnota - bylo rozhodnuto, že měření častěji než jednou za sekundu nemá smysl. Je zjevné, že takový systém ukládání dat je dlouhodobého hlediska neudržitelný neboť soubory přibývají zhruba každých 5 minut a jejich množství nezadržitelně roste což po jisté době začne být problém i pro takové souborové systémy, jako je ReiserFS. Nehledě na obtížnost zálohování takových dat. Pro převod dat do nové databáze je tedy třeba napsat shellový script, který v každém adresáři projde postupně všechny soubory, každý nejprve pomocí taru a gzipu rozbalí a pak v něm otevře postupně soubory příslušící všem veličinám a pomocí utility sed oddělí čas a hodnotu. Takto získané údaje se zanesou do předem vytvořené databáze pomocí standardnícho shellového rozhraní pro mysql databázi. Z naplněné databáze se udělá dump a ten je již možné snadno přenést na server, kde hydronet poběží a databázi z něj naplnit. Testy Verifikační testy Cíle testování je nejdříve ověření korektnosti dokumentace a návrhu (databáze, softwaru, …) a dále ověření funkčnosti a správného chování nejen jednotlivých komponent, ale i systému jako celku. Test úvodní studie Test spočívá v kontrole jednotlivých částí úvodní studie (odborný článek, diagram kontextu, model
jednání, datový slovník, návrh HW a SW, …) a hlavně jejich vzájemné návaznosti. Na testu by se měli podílet všichni
tvůrci jednotlivých části (tzn. zkontrolovat oddíly, které tvořili ostatní a ověřit souvislost se svou částí práce).
Dále by si měl celou úvodní studii přečíst a zkontrolovat aspoň jeden nezávislý zasvěcený člověk. Test návrhu databáze V této části bude kontrolována správnost návrhu ER modelu databáze (korektnost entit a vztahů mezi nimi,
dostatečnost údajů u jednotlivých entit). ER model by měl být kontrolován s ohledem na budoucí generaci SQL skriptů pro
tvorbu databáze a efektivního využití databáze. Bylo by vhodné, aby se na kontrole kromě členů týmu podílel i zkušený
databázový expert, který by mohl lépe odhalit případná úskalí návrhu. Návrh by bylo vhodné prokonzultovat i se zadavatelem,
jestli je schopen pojmout všechny jeho požadavky. Test testovacího softwaru K otestování některých částí bude potřeba vytvořit jednoduchý testovací software a pro zaručení správnosti
následných testů bude nutné i tento pomocný software otestovat. Bude potřeba navrhnout dvojice vstup/výstup a zkontrolovat,
zda předpokládaný výstup odpovídá skutečnému výstupu softwaru. U softwaru generujícího data budeme ověřovat, jestli data
splňují zadaná kritéria. Testy systému (moduly a celek) Pro testování rozdělíme systém na co nejmenší části, které je možné otestovat samostatně a provedeme jejich testy. Vždy musíme předem znát správný výsledek, který budeme konfrontovat se získaným výsledkem. K těmto testům budeme využívat metody "white-box testing" Pokračovat budeme integračními testy - tj. do systému budeme metodou zdola nahoru přidávat jednotlivé části a opět budeme kontrolovat správnost výsledků. Zavlečení chyby při skládání modulů se budeme bránit pomocí regresivního testování. K testům využijeme metody "black-box testing". Test systému bude nejrozsáhlejším a zároveň jedním z nejdůležitějších testů, proto jsem se rozhodl znázornit
jednotlivé jeho části na vývojovém diagramu (viz. obr), ze kterého jsou patrné i místa návratu po opravách případných chyb. Test stability systému Zabývat se budeme reakcí systému na nekorektní data, schopností systému zpracovávat velké množství
požadavků od uživatelů současně, využívat budeme "stress testing". Důležitou částí těchto testů bude kontrola schopnosti
zpětně zkompletovat data po výpadku spojení od měřicí stanice. Test bezpečnosti systému Zkouška odolnosti systému se bude provádět pomocí nasazení "hackera", který se bude snažit proniknout do
systému. V ideálním případě se mu to vůbec nemělo podařit, maximálně však s vynaložením nepřiměřených prostředků. Test uživatelského rozhraní Budeme ověřovat dostupnost všech funkcí systému, přehlednost uspořádání nabídek, rychlost systému (na
pomalejším počítači, příp. pomalejším připojení k internetu). Součástí bude i kontrola nápovědy k funkcím systému. Na testech
by se měla podílet i osoba nezapojená do vývoje, která může jednotlivé vlastnosti zhodnotit objektivněji. Validační testy U těchto testů je již nutná úzká spolupráce se zadavatelem, který ověřuje, zda produkt splňuje jeho očekávání - validační kritéria. Alfa testování Zadavatel zkouší jednotlivé funkce systému, přičemž programátor z vývojového týmu jej sleduje a může reagovat
na vzniklé neočekávané situace. Beta testování Zadavatel testuje systém ve skutečných podmínkách a zapisuje si případné problémy, které až následně konzultuje
s vývojovým týmem. Doba testování Důkladnost testů závisí na důležitosti jednotlivé testované části. Podíváme-li se na tento problém z ekonomického hlediska, dojdeme k závěru, že bychom měli testovat tak dlouho, dokud "se to vyplatí" - tedy do doby, než překročí náklady na testování náklady na opravu případné chyby. Situaci znázorňuje graf (doba, kdy bude ukončeno testování, je označena jako optimum) Výsledky testů Výsledky všech testů by měly být dlouhodobě uchovány. Po provedení nového testu by se měla zachovat i původní verze. U většiny testů je výstupem výsledek, který říká že systém daný požadavek buď splňuje nebo nesplňuje. V případě negativního výsledku se předpokládá sjednání nápravy v co možná nejkratším termínu za přispění zodpovědných osob z vývojového týmu. Licenční podmínky Text licence (XHTML, iso-8859-8) Instalace a dokumentace Instalace Měřící stanice Předpokladem je správně nainstalovaný a nakonfigurovaný os linux, zajištěné připojení k Internetu a provoz měřících čidel. Instalace: - Rozbalit dodaný balíček hydronet-stanice.tar.gz Instalace Server Předpokladem je opět správně nainstalovaný a nakonfigurovaný os linux, databáze SQL včetně přístupových práv, webserver Apache včetně php a SQL klienta, zajištěné připojení k Internetu. Instalace: - Rozbalit dodaný balíček hydronet-server.tar.gz Instalační skripty Seznam akcí, které musí instalační skript vykonat Měřící stanice - Zkopírovat binárky do /usr/bin Server - Zkopírovat systémové skripty do /usr/bin Návrh uživatelského rozhraní Přihlašovací obrazovka Prohlížení dat Nastavení pravidelného zasílání dat |