Výrče:SW. Uživatelská příručka - Server

Transkript

1 Výrče:SW Uživatelská příručka - Server

2 VýRČe DiAna 1 je projekt o rozpoznávání českých nářečí ze zvukových nahrávek. Související softwarový nástroj umožňuje sběr a analýzu nasbíraných nahrávek pro analýzu nářečí. Skládá se ze dvou částí - serverové a klientské. Na serverové části se definují nahrávací scénáře a všechna nastavení pro sběr a analýzu. Aplikace vyžaduje pro běh Javu 5 nebo vyšší. Všechny související soubory lze stáhnout na stránce projektu. Server se spouští z příkazové řádky příkazem: java -jar Server.jar konfigurační-soubor Pro kontrolu nastavení si stáhněte Klienta, vyžaduje alespoň Javu 6 a spouští se: java -jar Klient.jar Příprava Stáhněte si Server ze stránky projektu a rozbalte jej. Pro vyzkoušení jsou zde připravené dvě modelové konfigurace. Na jednodušší verzi budeme vysvětlovat možnosti nastavení serveru. Jednoduchá konfigurace je ve dvou verzích: configfile-simple-lin.xml pro linuxové platformy, configfile-simple-win.xml pro Windowsové platformy. Obě nastavení jsou stejná, ale nastavení pro platformy windows neobsahuje modelový skript pro analýzu, ten je připraven pouze jako jednoduchý skript pro shell. Všechny související soubory pro ukázkovou konfiguraci jsou v souboru setfiles-simple. Pro spuštění serveru s modelovým nastavením použijte příkaz: java -jar Server.jar configfile-simple-lin.xml nebo java -jar Server.jar configfile-simple-win.xml Konfigurace serveru Server se nastavuje pomocí xml souborů které obsahují veškeré důležité informace. Existují dva typy konfiguračních souborů: Hlavní konfigurační soubor Předává se při spuštění jako parametr a skládá se ze dvou částí - úvodní parametry pro spuštění serveru a nahrávací scénář. Setting pro znovupřipojení Vytváří je server za běhu a používají se pro navazování starších spojení. Úvodní nastavení serveru V úvodní části nastavení serveru je potřeba sada informací pro nastavení parametrů spojení. Pro vytváření spojení server potřebuje číslo portu, na kterém bude poslouchat. Server otevírá pro každé spojení nové vlákno, takže musí být omezené množství vláken spojení. Protože je kapacita omezená, kontroluje se aktivita vláken, aby neaktivní spojení nedržely prostředky. Určují tedy časové kontroly aktivity a neaktivní vlákna jsou vražděna za lenost. Specifikuje je interval kontroly a maximání dovolená doba neaktivity. Server pak během sběru dat bude vytvářet jednoduchou strukturu korpusu ve zvláštní složce, data 1 Zkratka z "Výslovnostní rysy češtiny - dialektová analýza"

3 od mluvčích bude třídit pomocí ID spojení. V konfiguraci se také určuje audio formát ve kterém chceme, aby nám mluvčí nahrávali data. Nahrávací scénář Obrázek 1: Ukázkové vstupní nastavení Nahrávací scénář se jmenuje sada (set) a skládá se z jednotlivých obrazovek (set members) s pokyny k nahrávání. Každá obrazovka definuje jeden vzhled okna zobrazený na klientské straně. Každá taková obrazovka pak produkuje buď audio nebo textovou informaci. Máme celkem 4 typy definic nahrávacích obrazovek: UniSM TxtFileSM AnalyzeSM Univerzální prvek scénáře pro běžné použití, definuje právě jednu obrazovku. Umožňuje jednodušší zápis pro zobrazení několika po sobě jdoucích obrazovek stejného vzhledu. Po odeslání standardní obrazovky spustí vybraný příkaz pro spuštění externích programů, příp. skriptů. GeneratedSM Vygenerovaný prvek scénáře, předpokládá se že bude vytvořen až za běhu pro konkrétního uživatele. Tyto způsoby definic jsou postupně použity v jednoduchém nastavení a jejich specifika si vysvětlíme na příkladech. Zatím ale obecně, každá obrazovka scénáře potřebuje tyto elementy: design - soubor s XML pro design obrazovky withrec - true/false informace, jestli obrazovka má nahrávat zvuk nebo ne maxlength - maximální délka nahrávky files - seznam doplňujících souborů resets - struktura resetů desc, itemnumber, itemtotal - popisy prvků pro logování a zobrazení postupu nahrávací sadou

4 1. obrazovka - dotazník První obrazovka v ukázkovém scénáři je vstupní dotazník. Je to univerzální prvek scénáře typu unism a neprodukuje zvuk ale textové informace o mluvčím. Pokud se v Klientovi připojíte k běžícímu serveru, uvidíte obrazovku na obrázku 3. Definuje jej XML definice na obrázku 2. Obrázek 2: Nastavení dotazníkové obrazovky Obrázek 3: Výsledná obrazovka Jak jsme výsledku docílili teď probereme postupně po jednotlivých složkách definice - začneme s designem okna a pak si vysvětlíme přenastavování komponenty.

5 Designový soubor Designový soubor, který definuje vzhled obrazovky na klientské části je ve formátu XML a na straně kliena se renderuje pomocí knihovny SWIX ml. Tato knihovna generuje z XML souborů objekty javax.swing. Tyto designové soubory obsahují objekty a jejich rozmístění, které jsou sdruženy v panelu, který se musí jmenovat include, protože tak jej bude Klient zpracovávat. Ukázkový design pro tuto obrazovku není příliš pěkný, protože používá GridBagLayout, ale když z něj ponecháme pouze jednotlivé objekty, je pak výsledný vzhled okna zcela jasný: <panel id="include"> <textpane name="shortdesc" text="úvodní dotazník"...some parameters /> <label text="jméno" /> <textfield name="jmeno" send="true" regex="..*" errmsg="zadejte nějaké jméno"/> <label text="koukej kombobox!"> <combobox name="combo" send="true" preferredsize="200,20"> </panel> Tento design je navíc specifický tím, že získává o mluvčím informace - vyplněné hodnoty do textového pole a vybrané hodnoty v roletce si chceme na serverové části uložit. Proto obsahují tyto komponenty nějaké atributy navíc, ty jsou v kódu zde podtrhnuty zeleně. Parametry jsou: send - pokud je true, znamená to, že nás hodnota objektu zajímá a chceme ji odeslat. regex - používá se pro validaci vstupu, např. pro korektní formát u nebo pro povinné neprázdné položky a jiné. Je to regulární výraz, který musí textový obsah v komponentě splnit. (používá se pro objekty typu JTextComponent) errmsg - pokud vstup nesplňuje regulární výraz, luvčím se zobrazí chybová zpráva, aby se mohli napravit. name - použije se jako popis hodnot od klienta a také pro identifikaci položky která je nesprávně vyplněná - při chybové zprávě. Nyní zkusíme vyplnit zobrazený dotazník. Víme, že položka jméno je povinná - regulární výraz..* vyžaduje, aby nezůstala prázdná. Pokud ji necháme prázdnou, při odeslání vyskočí chybová zpráva podle ostatních atributů, viz obrázek 4. Na obrázku 5 je pak správně vyplněný dotazník. Informace vyplněné zde Klient sesbírá a pošle Serveru, aby si je mohl uložit do textového souboru s popisem. Formát souboru je TSV soubor - je to dvouřádková tabulka s položkami oddělenými tabulátory. Názvy položek jsou v prvním řádku, ve druhém řádku jsou vyplněné hodnoty. Když dotazník odešlete, ve složce spojení bude nový soubor info txt s tímto obsahem: jmeno combo Já Druhá

6 Obrázek 4: Špatně vyplněný dotazník Obrázek 5: Správně vyplněný dotazník

7 Resetování komponent Některých výsledků při návrhu oken nelze dosáhnout jen pomocí XML souboru Pro tyto účely je navrhnut systém resetů komponent - co a jak se má resetovat obdrží Klient od Serveru spolu s doplňujícími informacemi o designu okna. Reset se skládá ze tří informací name - jméno komponenty, které se ná resetovat as - typ resetu value - hodnota resetu: text nebo název souboru, podle typu resetu Používají se 4 typy resetů: text přenastaví textovým komponentám (JTextComponent a JLabel) jejich text pomocí settext metody. Jako text se nastavuje obsah položky value image Přenastaví JLabel tak, aby vykreslil obrázek, jehož cesta je ve value resetu. file Přenastaví textovým komponentám zobrazený text stejně jako typ resetu text, ale obsah resetu čte ze souboru ve value. cbvalues Používá se pro přenastavení obsahu komponenty JComboBox. Value obsahuje položky pro komponentu oddělené znakem " ". V této obrazovce jsme přenastavovali hodnoty roletce - ComboBoxu, v následujících obrazovkách vyzkoušíme i ostatní typy resetů. 2. Obrazovky s textovými pokyny Následující obrazovka je v modelovém nastavení typu TxtFileSM. Tento prvek se používá, pokud máme za sebou zařazeno několik stejných obrazovek, ve kterých se mění jen právě jedna textová komponenta (například pro seznam vět ke čtení). K základním informacím o obrazovce se přidá cesta k textovému souboru a název komponenty, která se má přenastavit. Každý řádek se pak chová jako jedna obrazovka a před odesláním se zabalí jako objekt typu UniSM s potřebným přenastavením komponenty. Elementy pro toto nastavení jsou file a resetto. XML pro definice obrazovek je na obrázku 6. Obrázek 6: Definice obrazovek s textovými pokyny

8 Náš ukázkový soubor obsahuje pouze dva řádky: První řádek souboru s větama. Druhý řádek souboru s větama. Obrazovky které vygeneruje toto nastavení budou vypadat takto: Tyto nahrávací obrazovky mají mít za výsledek zvukovou nahrávku a obrazovka proto obsahuje i ovládací panely pro nahrávání zvuku. 3. Obrazovky s analýzou Za nahrávacími obrazovkami jsou zařazeny obrazovky pro analýzu přijatých souborů. Modelový skript pro analýzu je připravený pro demonstraci na linuxových platformách a z druhého konfiguračního souboru je vypuštěn. Pro analýzu je připraven typ obrazovky AnalyzeSM, který se od předchozích obrazovek liší přidáním elementu command. V definici okna je tak kromě standardního designu také řádka: <command>./setfiles-simple/simple-analyze.sh</command> Obsahem je příkaz, který se po odeslání obrazovky klientovi spustí s jedním parametrem - cestou ke složce aktuálního spojení, tj. se všemi daty mluvčího. Modelový skript pouze zjišťuje obsah složky mluvčího a vytváří defnici následující obrazovky, která tento obsah zobrazí. Následující obrazovka pro nahrávání tedy nebude (a nemůže být) v hlavním konfiguračním souboru, protože se vygeneruje až za běhu. Pro zobrazení této obrazovky se použije typ GeneratedSM. Ten je velmi stručný a obsahuje pouze jednu řádku: <generated> <path>resultsm.xml</path> </generated> Cesta označuje cestu k nové vygenerované obrazovce a je relativní vůči složce mluvčího - aby se zamezilo konfliktům s názvy souborů a zároveň název mohl být přesně určený. Sled obrazovek s těmito skripty je pak zobrazen na obrázcích 7 a 8.

9 Obrázek 7: Obrazovka při spuštění skriptu s analýzou Obrázek 8: Výsledek analýzy - výpis vytvořených souborů během nahrávání

10 Závěrečná obrazovka a zobrazování obrázků Zobrazování obrázků v rámci designů jsme zapojili do závěrečné loučící se obrazovky. Obrázky se musí odeslat ze Serveru zvlášť a poté se proto musí resetovat příslušné komponentě. Příklad odeslání doplňujícího obrázku a jeho přenastavení je na obrázku 9. Obrázek 9: Obrazovka s obrázkem Pro posílání dodatečných souborů používáme element sendfile, který má dva parametry - jméno souboru a jeho umístění. Umístění je vzhledem k pracovnímu adresáři Serveru. Jméno je to, které použije Klient při ukládání a musí se shodovat se jménem v části resetů. Přiřazení obrázku se dělá formou resetu typu image. Jak bude nakonec výsledná obrazovka vypadat je ukázáno na obrázku 10. Obrázek 10: Závěrečná obrazovka s obrázkem vepříka

11 Struktura korpusu V průvěhu nahrávání a analýzy budeme od klienta přijímat spousty souborů. Na straně serveru se budou všechna data ukládat do složek podle jednotlivých mluvčích a budou pojmenované jejich indentifikačním číslem. Struktura souborů je na obrázku 11. Obrázek 11: Struktura dat v korpusu Kromě souborů od Klienta si Server ukládá další konfigurační soubory - setting a configfile. Používají se pro navazování spojení, pokud vypadne. Soubor Setting Je také ve formátu XML a ukládá se spolu s kopií hlavního konfiguračního souboru. Obsahuje indexy a jiné informace pro orientaci v konfiguračním souboru - ukazují, která obrazovka byla zobrazena naposledy. Kopie hlavní konfigurace je zde proto, aby indexy zůstaly stále relevantní i kdyby se nastavení pro Server změnilo. Struktura souboru s nastavením je na obrázku 12. Obrázek 12: Soubor Setting Distribuce klienta Klientská část programu se může distribuovat několika způsoby:.zip soubor se spustitelným.jar souborem a složkou s knihovnami.jar soubor sbalený jako fat jar se všemi závislostmi.exe soubor pro uživatele Windows Spustitelný.exe soubor se vytvoří pomocí wrapperu launch4j, který umožní kromě snazšího spuštění pro uživatele taky kontrolu dostupné verze Javy před spuštěním Klienta.

12 Skripty pro vytvoření všech souborů pro distribuci jsou ke stažení buď jako build.xml konfigurační soubor pro Ant nebo jako skript pro launch4j. Pro distribuci je také pohodlné umožnit předvyplnění informací pro spojení se serverem - adresu serveru a port - aby se jimi uživatelé nemuseli zabývat. Ty se připraví do souboru client.config v kořeni spustitelného.jaru. Soubor client.config má právě dva řádky - na prvním řádku adresu serveru, na druhém řádku port. Poznámky: Všechny cesty v konfiguračních souborech musí být relativní vůči pracovnímu adresáři Serveru, tj. je nejpraktičtější, pokud bude ve stejné složce jako spustitelný.jar soubor serveru. V souborech s designy je nutné vyvarovat se konfliktům ID, proto všechny objekty na straně Klienta mají své ID uvozeny písmeny VD.