Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Studijní program : Aplikovaná informatika Obor: Informační systémy a technologie
Návrh a vývoj tenkého klienta infrastrukturního cloudu na platformě Android DIPLOMOVÁ PRÁCE
Student
:
Bc. Tomáš Andrle
Vedoucí
:
Ing. Tomáš Bruckner, Ph.D.
Oponent :
Ing. Martin Žamberský
2013
Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.
V Praze dne 24. června 2013
.................................. Bc. Tomáš Andrle
Poděkování Rád bych tímto krátkým odstavcem poděkoval panu Ing. Tomáši Brucknerovi, Ph.D. za jeho ochotné vedení této diplomové práce a sérii odborně-kritických konzultací k jejím dílčím částem. Díky naší spolupráci jsem byl schopen práci dokončit v očekávaném čase a kvalitě. Druhý dík patří kolektivu společnosti OldanyGroup s.r.o. za projevenou důvěru a relativně volné ruce při návrhu a vývoji aplikace BeeScale Client.
Abstrakt Diplomová práce řeší problematiku vývoje mobilního tenkého klienta určeného k řízení komerční infrastrukturní cloudové služby. V úvodní části se nachází přehled nezbytné terminologické výbavy a představení problematické domény, kterou se diplomová práce zabývá. Vedle samotného projektu, jehož výsledek je hlavním výstupem této práce, je součástí teze také rešerše současných diplomových prací, školních informačních zdrojů, manuálů, doporučení a metodik, které se zabývají návrhem designu a implementací grafického uživatelského rozhraní pro mobilní zařízení, zejména pak pro ty, které disponují operačním systémem Android. Informace získané na základě rešerše jsou následně využity jako výchozí znalostní báze pro návrh a realizaci prezentační vrstvy zmiňované aplikace. Dalším cílem diplomové práce je vyhotovení analýzy požadavků na nově vyvíjenou aplikaci. Požadavky jsou následně přetransformovány do konceptuálního návrhu, na který je navázáno vysvětlením implementace jednotlivých vrstev aplikace. K modelování částí návrhu aplikace bylo využito převážně modelovacího jazyka UML v prostředí aplikace Sybase PowerDesigner. Proces programování poté probíhal ve vývojovém prostředí Eclipse SDK. Vlastní přínos tkví v možnosti využití koncentrované znalosti plynoucí z rešerše zabývající se problematikou tvorby GUI pro mobilní zařízení. Programátor v tomto oboru neznalý bude moci využít tuto část práce jako kritický studijní materiál, který byl ověřen praxí. Provozovatelé infrastrukturních cloudů mohou v realizaci mobilního tenkého klienta nalézt inspiraci pro vlastní řešení.
Klíčová slova Tenký klient, Android, IaaS, cloud, grafické uživatelské rozhraní, GUI, návrh GUI, BeeScale
Abstract This diploma thesis deals with the issue of the development of mobile thin client application which is able to manage commercial infrastructure cloud service. The introduction section provides an overview of the necessary terminology and presents the problem domain that is a subject of this thesis. Besides the project itself, of which result is the main output of this work, is also the part dedicated to research of current theses, school information resources, guidelines, recommendations and methodologies that covers topics of design and implementation of graphical user interfaces for mobile devices, especially for those that have the Android operating system installed. Information obtained on basis of the research is after used as a default knowledge base for design and implementation of the presentation layer of the previously mentioned application. The next aim of this thesis is to make analysis of requirements for new application which is being developed. The requirements are then transformed into conceptual design, to which is bound the explanation of implementation of individual application layers. UML was mainly used for the modeling of the application parts design in environment of the Sybase PowerDesigner. The programming process was performed by usage of the development environment called Eclipse SDK. Benefit of this diploma thesis lies in the possibility of reusing its concentrated knowledge resulting from the research dealing with the problems of creating GUI for mobile devices. Programmer, who is untouched in this specialization, will be able to use this part of the thesis as a critical study material which has been verified in practice. Cloud infrastructure solution providers can find there an inspiration for their own mobile thin client application.
Vymezení tématu a motivace výběru .............................................................................7 Cíle práce, výstupy a očekávaný přínos ........................................................................7 Způsob dosažení cílů ......................................................................................................8 Předpoklady a omezení práce.........................................................................................8 Struktura práce ................................................................................................................9
Vymezení problematiky .................................................................................... 10 2.1 Základní pojmy ...............................................................................................................10 2.1.1 Tenký klient .......................................................................................................10 2.1.2 Cloud Computing ..............................................................................................12 2.1.3 Operační systém Android ................................................................................16 2.2 O společnosti OldanyGroup s.r.o. ................................................................................18 2.2.1 Profil ...................................................................................................................18 2.2.2 Portfolio firmy....................................................................................................18 2.3 Služba BeeScale ............................................................................................................20 2.3.1 Architektura .......................................................................................................21 2.3.2 Aplikační rozhraní .............................................................................................24 2.4 Motivace projektu BeeScale Client ...............................................................................26 2.5 Prerekvizity projektu ......................................................................................................27 2.5.1 Nástroje objektové analýzy ..............................................................................27 2.5.2 Vývojové prostředí ............................................................................................28 2.5.3 Metodika vývoje ................................................................................................30 2.5.4 Management projektu .......................................................................................34 2.5.5 Systém pro správu verzí ...................................................................................36 2.5.6 Testovací zařízení .............................................................................................38
3
Studie metodik tvorby GUI mobilních aplikací ............................................... 39 3.1 Rešerše tuzemských a zahraničních tezí .....................................................................39 3.2 Rešerše ostatních informačních zdrojů .......................................................................40 3.3 Doporučení plynoucí ze studie .....................................................................................41 3.3.1 Důkladné plánování ..........................................................................................41 3.3.2 Inspirace ............................................................................................................41 3.3.3 Koncept, detail a realizace ...............................................................................42 3.3.4 Reflexe diverzity cílových zařízení ..................................................................43 3.3.5 Zábava pro uživatele .........................................................................................44 3.3.6 Důkladné testování, potom publikace .............................................................44
4.1 Požadavky na aplikaci BeeScale Client .......................................................................46 4.2 Harmonogram projektu .................................................................................................48
Realizace návrhu ............................................................................................... 63 6.1 Prezentační vrstva .........................................................................................................63 6.1.1 Lokalizace ..........................................................................................................63 6.1.2 Realizace obrazovek GUI ..................................................................................63 6.1.3 Ovládání .............................................................................................................65 6.1.4 Vlastní grafické prvky .......................................................................................66 6.2 Aplikační vrstva .............................................................................................................67 6.2.1 Komunikace s datovou vrstvou .......................................................................67 6.2.2 Hlavní třídy ........................................................................................................70 6.2.3 Třídy aktivit ........................................................................................................76 6.2.4 Vlastní dialogy ...................................................................................................77 6.2.5 Datové adaptéry ................................................................................................79 6.2.6 Pomocné třídy ...................................................................................................80
7.1 Metodiky pro tvorbu GUI ...............................................................................................84 7.2 Vyhodnocení projektu ...................................................................................................84 7.3 Možnosti dalšího rozvoje aplikace ...............................................................................86
8
Závěr 88
Terminologický slovník ........................................................................................... 89 Seznam literatury ..................................................................................................... 91 Seznam obrázků a tabulek ...................................................................................... 95 Základní text...........................................................................................................................95 Seznam obrázků ..........................................................................................................95 Seznam tabulek ...........................................................................................................95 Přílohy ....................................................................................................................................96 Seznam obrázků ..........................................................................................................96 Seznam tabulek ...........................................................................................................96
Hlavním tématem této diplomové práce je komplexní realizace projektu nesoucí název BeeScale Client. Jedná se o projekt nově vznikajícího klientského aplikačního řešení určeného pro komerční infrastrukturní cloud společnosti OldanyGroup s.r.o., v níž shodou okolností již řadu let působím. Uvedená společnost je současně zadavatelem interní vývojářské zakázky. Práce zachycuje jednotlivé vývojové fáze projektu, a to od analýzy požadavků na novou aplikaci, přes její všestranný návrh, až k její programátorské realizaci. Důležitou paralelní linii diplomové práce tvoří kritická studie akademických prací, návodů, metodik, doporučení a pokynů pro tvorbu grafického uživatelského rozhraní pro mobilní zařízení, jež disponují operačním systémem Android. Kombinace vývoje mobilní aplikace spolu se selektivní agregací užitečných přístupů k návrhu a realizaci uživatelského rozhraní, na kterou je v dnešní době kladen enormní důraz, se mi již od počátku jevila jako velice zajímavá a nadčasová. Téma programování aplikace BeeScale Client jsem si mimo jiné zvolil také proto, že mě odjakživa zajímala problematika mobilních technologií. Tento zájem pak přerostl ve výzvu s vidinou možnosti přiučit se něčemu novému.
1.2
Cíle práce, výstupy a očekávaný přínos
Hlavním cílem této diplomové práce je vytvoření funkční aplikace podle představitelů firmy. Tento cíl se dělí na další dílčí cíle, které k naplnění podstaty toho hlavního vedou. Těmi dílčími cíli jsou 1. analýza požadavků vyslovených zadavatelem aplikace, 2. návrh aplikace, který reflektuje výstup analýzy požadavků, 3. převedení návrhu do podoby hotové aplikace reprezentované zdrojovým kódem. Zejména pak návrhová a realizační část je důležitá, protože se na ni bezprostředně váže další z cílů, a to kritická studie materiálů s doporučeními, jak správně postupovat při tvorbě grafického uživatelského rozhraní aplikací pro Android. Výstupem práce by měla být aplikace BeeScale Client, která splňuje parametry vyplývající z jejího zadání a z aplikace know-how získaného v průběhu vzpomínané studie. Přínos, který je svázán s dokončením projektu, je zřejmý. Je jím samotná aplikace, která poskytuje dodatečnou přidanou hodnotu pro registrované uživatele služby BeeScale. Přínos akademické sféře spatřuji v kumulaci užitečných doporučení a postupů pro návrh
Úvod
8
a realizaci uživatelského rozhraní mobilních aplikací. Ve spojení s aplikačním projektem je možné tato doporučení bezprostředně ověřit a zhodnotit. Vedle uváděných přínosů spatřuji jedinečný benefit v možnosti obohacení se o první zkušenost s vývojem mobilní aplikace.
1.3
Způsob dosažení cílů
Logický přístup k věci napovídá, že prvním cílem práce, který následuje po stručném seznámení se s problematikou řešené oblasti, je kritická studie postupů a doporučení pro tvorbu grafického uživatelského rozhraní. Studie se skládá z rešerše současných akademických prací tuzemských a zahraničních univerzit. Následuje rešerše odborných článků, dokumentů a blogů odborníků. Tyto podklady následně kritickým okem syntetizuji ve formulaci vlastních doporučení. Výsledky studie jsou v průběhu vývoje aplikace BeeScale aplikovány v praxi. Aplikací přejatých doporučení pro správnou tvorbu požadavků na aplikaci ze stran zadavatele provádím jejich analýzu, která pak slouží jako výchozí pohled na funkcionální a nefunkcionální výbavu nově vyvíjené aplikace. Návrhová část užívá znalostí autora, nástrojů a technik objektového modelování jazyka UML. V této části je nejdříve nastaven základní architektonický model, který je rozdělen do třívrstvého modelu, kdy každá z vrstev je také popsána. Jednou z vrstev je i vrstva prezentační, kde se snažím přenášet výsledek studie z prvního cíle práce v praxi. Realizační část pak už jen přenáší reálný stav implementace návrhu a finální podobu uživatelského rozhraní do popisné a argumentační polohy. V závěru práce vyhodnocuji úspěšnost při plnění každého ze stanovených cílů.
1.4
Předpoklady a omezení práce
Hlavním předpokladem pro realizaci této diplomové práce je osobní participace na vývoji diskutované aplikace v prostředí zadavatele, společnosti OldanyGroup s.r.o. Nezbytná je však i kooperace ze strany managementu, zejména ve schvalovacích řízeních a stádiu formulace požadavků na aplikaci. Kritická je také součinnost vývojářů služby BeeScale, protože právě jejich výstup udává, jakou funkcionalitu budu moci do aplikace implementovat. Zadavatel musí mimo personálního zabezpečení zajistit patřičné softwarové vybavení a přístup k dokumentaci služby BeeScale. Pravděpodobně největším omezením se jeví faktor času, který že ve firmě působí spousta brigádníků, představuje potenciální stanovených harmonogramů. Zvlášť s přihlédnutím k tomu, že se s více souběžně probíhajícími projekty. Potenciální limit také
vzhledem k tomu, riziko narušování jedná o prostředí spočívá v rozsahu
Úvod
9
diplomové práce, protože ačkoliv se jedná o menší projekt, tak zachycení vysoké míry detailu je poměrně kapacitně náročné. Nevýhodou také je, že převážná část zdrojů užitečných pro řešenou problematiku, je bohužel v cizím jazyce.
1.5
Struktura práce
Diplomová práce je pro svoji přehlednost a metodičnost rozdělena do pěti dílčích částí, vedle nich pak stojí úvod a závěr. První dvě části jsou teoretické a zbytek je praktický. První část je stručným úvodem do terminologické báze nezbytné k pochopení podstaty řešené problematiky. Mimo to zde vysvětluji motivaci projektu v kontextu služby BeeScale a společnosti OldanyGroup s.r.o. Dále popisuji základní softwarové a hardwarové instrumenty, které se k potřebám návrhu a vývoje aplikací pracovníky této společnosti běžně využívají. Následující teoretická část je komentovanou rešerší, která analyzuje dostupné kvalifikované zdroje, které by mohly být užitečné jako znalostní a konfrontační podklad pro návrhovou a realizační fázi projektu. Kapitola shrnuje výsledek analýzy dostupných akademických prací, metodik, nebo také rad a pokynů (tzv. guidelines), určených k návrhu grafického uživatelského rozraní pro mobilní zařízení s Androidem. V pořadí třetí část se budu věnovat předprojektové analýze, která má za úkol shrnout a analyzovat požadavky managementu OldanyGroup na výstup projektu, který tato diplomová práce řeší. V návaznosti na tuto analýzu je dále stanoven předpokládaný harmonogramu prací na projektu, na základě něhož bude nakonec možné vyhodnotit úspěšnost projektu. Předprojektovou analýzu plynule vystřídá návrh samotné mobilní aplikace BeeScale Client v rovině abstrahované od implementačních detailů. V rámci kapitoly bude postupně odhalena výchozí architektura aplikace, případy jejího užití a základní objektová analýza. Po uzavření výše uvedeného je přikročeno k problematice návrhu konkrétního grafického uživatelského rozhraní pro aplikaci. Pátá část práce se nese ve znamení realizace výše popsaného návrhu aplikace. Kapitola se postupně věnuje každé z vrstev uvedených v navrženém architektonickém modelu. Mapuji zde aplikovaná východiska získaná studiem informačních zdrojů, myšlenkové pohnutky a principy, které vedly k řešení jednotlivých stavebních kamenů aplikace, jež jsou v kapitole podrobně popsány. Vyhodnocení dílčích výstupů práce a závěr shrnují výsledky dosažené zpracováním této práce a jejich přínos, a uvádí možný výhled pro další rozvoj aplikace BeeScale Client do budoucna.
Vymezení problematiky
10
2 Vymezení problematiky 2.1
Základní pojmy
2.1.1
Tenký klient
Tenký klient je realizací konceptu komunikace Client-server (Klient-server), tedy že aplikace má dvě od sebe oddělené nezávislé části. Server je místo, kde dochází ke zpracování datových vstupů na požadované výstupy. Klient je komponenta určená k interpretaci dat získaných ze serveru, naproti tomu serveru poskytuje zmíněné datové vstupy, které většinou vznikají na základě interakce s uživatelem. Tenký klient je podle vysvětlení uvedeného v [10 s. 57] typem aplikace, která má za úkol samostatně realizovat prezentační vrstvu, která je fyzicky oddělena od vrstev aplikační a datové logiky, které jsou v tomto modelu umístěny na straně serverové části aplikace. Tento tenký klient, potažmo prezentační vrstva, se potom k serveru připojuje pomocí předepsaného protokolu (rozhraní). Prezentační vrstva vymezuje prostředí, kde se dějí veškeré interakce s uživatelem. Aplikační model tenkého klienta je velice užitečný, protože odděluje klientskou část aplikace, která slouží pouze pro prezentaci průběžných dat nebo datových kolekcí získaných z interakce se severem, od části aplikace, která se stará o samotné funkční zpracování datových vstupů na výstupy. Výkonné aplikační jádro (server) je centralizované a jedinečné, tím pádem i lépe uchopitelné jeho správcem pro účely údržby nebo pro úplnou náhradu za jiné aplikační jádro, které implementuje shodné aplikační rozhraní. Webové aplikace jsou nejideálnějšími zástupci realizací tenkého klienta. Při vývoji počítačových nebo mobilních aplikací, jejichž cílem je využití mimo webové prostředí, se však většinou zastoupení určité „ztlušťující“ porce logiky nelze vyhnout, ale i přesto lze tyto aplikace považovat za tenké klienty. Příklad realizace aplikace v podobě tenkého klienta v porovnání s realizací po vzoru tlustého klienta znázorňuje Obrázek 1.
Vymezení problematiky
11
Obrázek 1 – Rozdíl mezi tlustým a tenkým klientem (zdroj: [10 s. 56])
Tenký klient je ukázkou praktické tendence „odtrhávat“ od výkonného jádra aplikace jeho grafické uživatelské rozhraní (GUI) a jednoduchou prezentační logiku, která je ve většině případů určena jen ke strukturování grafických prvků a přetváření datových struktur do člověkem „konzumovatelné“ podoby. Mimo to se stará o zprostředkování uživatelských požadavků směrem k serveru. Motivace modelu tenkého klienta je taková, že je zapotřebí vyčlenit takové části aplikace, které jsou ve styku s uživatelem a podléhají rychlému zastarávání, a je tedy nutné je častěji obměňovat na úrovni kódu. Zůstává však pravidlem, že čím méně transformací klient na vstupu realizuje, tím je tenčí.
Vymezení problematiky
2.1.2
12
Cloud Computing
Datové centrum Datové centrum je (viz [40 s. 16–17]) budova nebo místnost sloužící ke schraňování serverových systémů, diskových polí, komunikačních komponent, zálohovacích zařízení a jiných podpůrných systémů. Servery v tradičním datovém centru jsou dedikovány specifickým aplikacím nebo službám, přičemž jejich přebytečný výkonový potenciál zůstává nevyužit. Naproti tomu nedostatečný výkon povětšinou není možné kompenzovat jinak, nežli posílením dané serverové sestavy. Virtualizovaná datová centra jsou založena na hardwaru s podporou virtualizačních technologií, díky kterým je umožněno efektivně hospodařit s jejich výpočetním výkonem. Teoretická oblast související s virtualizací je poměrně široká, ale drobné shrnutí, alespoň co se jejího účelu a forem týče, nabízí následující kapitola. Virtualizace Ve zjednodušeném pojetí společnosti OldanyGroup s.r.o. (viz [31]) termín virtualizace znamená možnost sdílet výpočetní zdroje (jádra procesorů, operační paměť, datová úložiště, síťové karty) daného serveru nebo datového centra mezi vícero paralelně běžících operačních systémů (OS). Tyto operační systémy pak figurují jako oddělená virtuální prostředí nebo stroje, tzv. virtual machines (VM). Dosud popisovaný způsob virtualizace je nazýván virtualizací nativní, přičemž roli prostředníka mezi hardwarem a jednotlivými operačními systémy tvoří tzv. hypervizor, který alokaci výpočetních zdrojů mezi těmito dvěma oddělenými vrstvami řídí. Zmíněná forma virtualizace bude v této diplomové práce hrát zásadní roli. Ucelený pohled na modely virtualizace nejlépe ilustruje Obrázek 2 a literatura [10 s. 404–405]. Mimo nativní virtualizaci se rozlišuje ještě virtualizace na úrovni operačního systému a tzv. paravirtualizace. Arbitráž zdrojů je u virtualizace na úrovni OS, na rozdíl od nativní virtualizace, řízena na úrovni hypervizora běžícího nad specializovaným hostujícím operačním systémem, který je pro takovýto druh virtualizace výhradně určen. Paravirtualizace funguje na podobném principu, jen je potřeba, aby hostované operační systémy měly navíc implementovanou podporu tzv. hypercalls, tedy rozhraní, které zprostředkovává volání funkcí na abstrahovaný hardware.
Vymezení problematiky
13
Obrázek 2 – Srovnání virtualizačních modelů (zdroj: [10 s. 405])
Mimo virtualizace hardwaru je v hojné míře využíváno i aplikační virtualizace (viz [10 s. 405–406]). Příkladem takové aplikační virtualizace je například Java Virtual Machine (JVM), tedy virtuální stroj běžící na hostujícím operačním systému a zpracovávající zvláštní aplikační kód (zvaný „bajtkód“), který je pomocí JVM interpretován do kódu strojového. JVM je platformně nezávislá, takže abstrahuje běhové prostředí i hardware od samotné aplikace. Taková aplikace je pak jednoduše přenositelná napříč různými systémovými platformami bez starostí o vzájemnou kompatibilitu. Cloud Computing Oficiální definice organizace National Institute of Standards and Technology (zkráceně NIST) zní takto: „Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.“ [25 s. 2] Ve volném překladu je Cloud Computing sada modelů pro sdílené a konfigurovatelné výpočetní zdroje (sítě, servery, úložiště, aplikace a jiné služby), které jsou dostupné v uživatelem požadované míře, rychle a s co nejnižším úsilím z jakéhokoliv místa na světě. Z výše uvedené definice je patrné, že termín Cloud Computing je zastřešujícím termínem pro všechny moderní modely služeb, které jsou známé pod základními zkratkami SaaS (Software as a Service), PaaS (Platform as a Service) a IaaS (Infrastructure as a Service). Moderní dějiny IS/ICT však zaznamenávají mnohé další služby, které nesou příponu -aaS (as a Service). V praxi je pak možné se setkat i se zkratkou XaaS,
Vymezení problematiky
14
která zjednodušeně znamená „cokoliv jako služba“, což je vlastně základní filosofií Cloud Computingu, tím pádem je možné s trochou nadsázky poznamenat, že XaaS je synonymem pro Cloud Computing. Pokud se v jakémkoliv textu objeví samostatně pojem „Cloud“, je jím velice pravděpodobně míněna konkrétní realizace některé ze služeb založených právě na tomto diskutovaném modelu. Základní charakteristické rysy cloudových služeb jsou dle [25 s. 2] tyto: ● Samoobslužnost provozu a provoz na vyžádání – uživatel se sám v případě potřeby „zapojí“ do užívání služby. Proces zavedení služby je většinou otázkou jen několika málo kliků myší. ● Přístup skrze síť – služba je v závislosti na jejím distribučním modelu poskytována buď veřejně, tedy je běžně dostupná každému, kdo má přístup k síti Internet. Nebo je poskytována privátně, neboli je dostupná pouze definovanému okruhu uživatelů. Dále je možné se setkat s komunitními a hybridními cloudy, ale ty nejsou pro kontext této teze důležité, proto se jim nebudu dále věnovat. ● Sdílené zdroje – cloudové služby zpravidla využívají zázemí jednoho nebo více dislokovaných datových center, na jejichž platformě je daná služba provozována. Disponibilní výpočetní kapacity datacenter neboli zdroje datacenter jsou kolektivně sdíleny a dynamicky alokovány mezi jednotlivé uživatelské instance služby. ● Škálovatelnost – v průběhu užívání služby může nastat situace, kdy výkonnostní nebo jiné (pro službu typické) parametry nevyhovují současným potřebám, proto je možné tyto parametry služby buď uživatelsky, nebo automatizovaně pozměnit na požadovanou úroveň, a to bez ztráty kontinuity v konzumaci služby spotřebitelem. ● Měřitelnost – v závislosti na charakteru služby jsou uživateli účtovány poplatky za její užívání. Může být účtováno například za spotřebovaný výpočetní výkon, disponibilní šířku síťového pásma, aktivní počet uživatelů, úroveň funkcionality, úroveň dostupnosti a cokoliv dalšího, co vyplývá z povahy dané služby. Režimy plateb a modely oceňování služby se mohou různit, ale v každém případě má uživatel jasnou představu o tom, kolik jej zvolené parametry služby aktuálně stojí.
Vymezení problematiky
15
Infrastructure as a Service a další Infrastructure as a Service (zkráceně IaaS) je (podle [33]) v žebříčku modelů Cloud Computingu až na samém dně (viz Obrázek 3). Je to dáno zejména tím, jakou vrstvu IS/ICT tento model zastupuje, a na které zákazníky (potažmo uživatele) tento model cílí. V případě IaaS jsou zákazníky správci a architekti ICT. Služby na tomto modelu založené poskytují virtualizované výpočetní zdroje (výpočetní jádra, operační paměť, úložiště, síťový provoz, síťové přepínače, routery atp.), které by byly v běžném provozu řešeny pomocí vlastních serverů ve vlastním nebo pronajatém datovém centru. V tomto případě je však stejná potřeba řešena formou pronájmu a to tím způsobem, že je placena pouze za využití konkrétních abstrahovaných prostředků, které jsou opravdu v daný okamžik využívány. Výše v hierarchii Cloud Computingu podle [33] stojí PaaS a SaaS. Služby podle modelu Platform as a Service (PaaS) poskytují vývojová prostředí (programovací jazyky, frameworky, knihovny a služby), na kterých mohou jejich zákazníci vyvíjet a nasazovat své vlastní cloudové aplikace založené na dané platformě. Zákazníci tohoto typu služeb budou tedy nejspíše aplikační architekti a vývojáři. Uživatelé těchto služeb jsou ušetřeni od problematiky infrastruktury, na níž PaaS řešení běží. Software as a Service (SaaS) stojí na samé špici hierarchie Cloud Computingu, protože zákazník neřeší nic jiného, než jak se pronajímaná služba uživatelsky používá a kolik jej stojí. Platformu, v jejímž rámci aplikace běží, i infrastrukturu v tomto případě plně zabezpečuje dodavatel. Z definice v [25 s. 2–3] vyplývá, že zákazník službu formátu SaaS ovládá zpravidla jen pomocí standardního webového prohlížeče, jež je integrálním vybavením každého operačního systému.
Obrázek 3 – Hierarchie základních modelů Cloud Computingu (zdroj: [33])
Vymezení problematiky
2.1.3
16
Operační systém Android
Android obecně Rád bych prostřednictvím této kapitoly představil oblíbenou a dominantní platformu určenou pro mobilní zařízení, jako jsou například moderní smartphony, tablety a různé minipočítače. Svůj zjednodušený výklad problematiky opírám o znalosti získané z [37 s. 3]. Android je operační systém, za jehož vznikem stojí iniciativa společnosti Google, ale postupem času a díky otevřenému modelu distribuce, který stojí na principech open-sourcového softwaru, se brzy rozšířil i mezi významné výrobce mobilních technologií a vývojáře, u nichž se dnes těší velké oblibě. Jelikož je dokumentace, zdrojové kódy i Android Software Development Kit (Android SDK) dostupný zcela zdarma na webu, není problémem pro kohokoliv, kdo zná zvyklosti programovacího jazyka Java, aby začal v poměrně krátké době vyvíjet vlastní mobilní aplikace, které potom může pomocí elektronického tržiště Google Play publikovat široké veřejnosti a v případě potřeby patřičně zpeněžit. Android v současnosti „Android powers hundreds of millions of mobile devices in more than 190 countries around the world. It's the largest installed base of any mobile platform and growing fast—every day another million users power up their Android devices for the first time and start looking for apps, games, and other digital content.“ [13] Uvedenou citaci jsem si vypůjčil z vývojářského webu Androidu, a abych se vyhnul nějakým spekulacím a marketingovým mystifikacím ze strany společnosti Google, rozhodl jsem se tyto informace ověřit i u jiných zdrojů. Například v časopise Počítač pro každého (viz [22]) označili Android za jednoznačně nejrozšířenější operační systém v mobilních telefonech a Google Play jako tržiště s největším počtem dostupných aplikací v celosvětovém měřítku, ale i v porovnání na české poměry. Výhled Androidu je vzhledem k celosvětovému boomu smartphonů velice optimistický s potenciálem další velké expanze, protože poptávka po nich má stále ještě kam růst. Dokladem toho je i článek v časopisu Týden (viz [46]), kde se uvádí, že koncem roku 2012 bylo celosvětově prodáno 1,14 miliardy smartphonů, přičemž meziroční nárůst podílu oproti běžným telefonům činil 42%. Podle článku na webu Androidmarket.cz (viz [39]) bylo, s odkazem na konferenci Google I/O konanou v roce 2012, provedeno celkem 400 milionů aktivací zařízení s operačním systémem Android, načež jich je každý další den aktivován další 1 milion.
Vymezení problematiky
17
Historie verzí Aktuální verze Androidu nese název Jelly Bean s číselným označením 4.2. Nejstarší verze, která ještě dnes stojí za zmínku z důvodu držení zpětné kompatibility je verze Donut s číslem 1.6. Postupný vývoj verzí systému a jeho aplikačních rozhraní zachycuje Obrázek 4. Jelly Bean
Verze 4.1 (API 16)
Ice Cream Sandwich
Verze 4.0.3 – 4.0.4 (API 15)
Honeycomb
Verze 3.1 (API 12)
Verze 3.2 (API 13)
Gingerbread
Verze 2.3 – 2.3.2 (API 9)
Verze 2.3.3 – 2.3.7 (API 10)
Froyo
Verze 2.2 (API 8)
Eclair Donut
Verze 4.2 (API 17)
Verze 2.1 (API 7) Verze 1.6 (API 4)
Obrázek 4 – Graf vývoje verzí OS Android (zdroj: autor)
Rozložení jednotlivých verzí Androidu mezi aktivními zařízeními, které ve 14-ti denních intervalech společnost Google monitoruje, ilustruje Obrázek 5. Data vyobrazená na koláčovém grafu jsou aktuální k datu 4. března 2013. Z grafu je patrné, že dominantní verzí je stále ještě postarší Gingerbread, z čehož pro vývojáře vyplývá určitý trend, podle kterého by se měli ve svém vlastním zájmu zařídit. Pokud budu chtít zasáhnout co nejširší publikum spolu s co nejpestřejší paletou dostupných funkcionalit z nových verzí OS, musím novou aplikaci zacílit na minimálně 4 verze staré aplikační programovací rozhraní, abych zajistil kompatibilitu s většinou zařízení na trhu.
Obrázek 5 – Rozložení verzí OS dle přístupů na Google Play (zdroj:[15])
Vymezení problematiky
2.2
O společnosti OldanyGroup s.r.o.
2.2.1
Profil
18
Společnost OldanyGroup s.r.o. (dále jen OldanyGroup) se na českém trhu podle zdroje [30] etablovala již v roce 2005 a od roku 2011 operuje oficiálně i na území Slovenské republiky. Od doby svého vzniku se snaží řešit aktuální témata v oboru IS/ICT, proto se zaměřuje na moderní a inovativní řešení a technologie v tomto odvětví. Společnost si zakládá na svém komplexním portfoliu služeb, díky němuž je svým zákazníkům vždy schopna nabídnout úplný servis v podobě konzultací, návrhu, dodávky, implementace a post-implementační správy daného realizovaného IS/ICT řešení. To vše se děje proto, aby byl zákazníkovi dodán vždy funkční a konzistentní celek k důslednému uspokojení jeho potřeb. Více informací o společnosti, jejích projektech a partnerech se nachází na webu www.oldanygroup.cz.
2.2.2
Portfolio firmy
Znalostní oblasti Mezi oborové specializace firmy OldanyGroup podle [30] patří ● správa serverových operačních systémů na platformách Microsoft a Linux, ● virtualizace serverů a desktopů na technologických produktech společností VMware, Microsoft a Citrix, ● vysoká dostupnost, ● rozložení zátěže, ● webové a aplikační servery, ● databázové servery, ● elektronické poštovní systémy, ● zálohování a archivace dat, ● VPN sítě.
Vymezení problematiky
19
Vlastní projekty ● Přednášky a semináře – již několik let v řadě je jednatel společnosti čestným hostem na půdě Vysoké školy ekonomické v Praze ve volitelném kurzu profesora Jandoše s názvem Technické prostředky a technologická infrastruktura IS (4IT321). Tématem této přednášky je obecný úvod do problematiky virtualizace. Dále pak společnost v minulosti (viz [28]) pořádala cyklus přednášek s názvem „Jen (z)virtualizovat nestačí…”, jehož cílem bylo seznámit publikum se službami a produkty pro zefektivnění dosavadních implementací virtualizace ve firmách a veřejných institucích. ● Thin Client OldanyGroup (TiCtOG) – proprietární řešení v podobě hardwarového tenkého klienta určeného pro koncové uživatele virtualizovaných desktopových infrastruktur (VDI) a terminálových služeb. Takovéto zařízení je pak plnohodnotnou náhradou za běžné stolní PC. Oproti běžnému PC má však tenký klient delší životní cyklus, lepší energetickou spotřebu, snížené tepelné a hlukové emise a nároky na správu. Tyto zmíněné faktory přináší poměrně velký potenciál úspory nákladů na provoz firemní výpočetní infrastruktury. ● TiCtOG Space Management – software pro komplexní centralizovanou správu a nasazení platformy tenkých klientů TiCtOG. ● BeeScale a BeeScale Client – budou předmětem následujících kapitol práce.
Vymezení problematiky
2.3
20
Služba BeeScale
BeeScale je v dokumentu [19 s. 8] popisován jako veřejná cloudová služba typu IaaS, jejíž vývoj byl oficiálně odstartován v červenci 2010. Tomuto datu předcházelo zdlouhavé utváření koncepce a jeden nezdařený vývojářský pokus. Služba byla poprvé uvedena v září roku 2010, ale tehdy ještě jako beta verze dostupná pouze úzké skupině registrovaných zájemců z řad odborné veřejnosti. V březnu 2011 poté vychází podstatně inovovaná verze služby pod označením „BETA 2“. Dne 11. dubna 2011 byla služba konečně spuštěna do ostrého provozu dostupného zájemcům z řad veřejnosti.
Obrázek 6 – Marketingová podoba architektury BeeScale (zdroj: [27])
Účet uživatele služby BeeScale je po svém zaregistrování reprezentován vlastním virtuálním datovým centrem. Toto datové centrum uživatel může posléze naplnit libovolným počtem virtuálních serverů (vServerů). Virtuální servery v podání BeeScalu mohou podle [27] disponovat ● 1 až 4 virtuálními procesory (vCPU), ● 64 MB až 4 GB virtuální operační paměti (vRAM), ● až 4 virtuálními diskovými úložišti o kapacitách do 500GB (vDisk, vStorage), ● 1 veřejnou IPv4 adresou, ● některým z desítek nabízených operačních systémů.
Vymezení problematiky
21
Služba je účtována po hodinách uplynulého provozu. Účtování za zdroje užívané uživatelem je založeno na kreditním systému, který funguje formou předplatného. Každou hodinu se tedy z uživatelského konta odečte částka úměrná čerpání kapacity disponibilních výpočetních zdrojů infrastrukturního cloudu. Vypnuté servery však uživatele nic nestojí. Nativní virtualizaci fyzických serverů (tzv. hives) u služby BeeScale zabezpečuje hypervizor Linux KVM. Jeho základní funkce a přínosy jsou na domovském webu služby popsány textem, který jsem si dovolil níže citovat. „Využíváme nativní virtualizace na Linux KVM a tak jsou všechny jednotlivé virtuální systémy od sebe naprosto izolované. Získáváte plnou kontrolu nad Vaším virtuálním systémem. Můžete používat vlastní jádro, nemusíte se omezovat. Nepoužíváme žádné speciální paravirtualizované ovladače. Váš systém dostává přidělené zdroje, se kterými můžete pracovat – operační paměť je plně vyhrazena, procesorový výkon je agregován mezi konečný počet virtuálních procesorů.“ [27] Komplexní pohled na architekturu BeeScalu (viz Obrázek 6) naleznete v další kapitole.
2.3.1
Architektura
IaaS cloud BeeScale je tvořen kombinací vzájemně propojených komponent z vývojářské dílny OldanyGroup a volně dostupných open-sourcových projektů. Souhrnně je tento celek nazýván jako BeeStack (viz Obrázek 7). BeeStack je koncipován dle návrhového vzoru Model-View-Controller (MVC), aby každá z komponent řešení byla v budoucnu volně nahraditelná nebo rozšířitelná jinou komponentou implementující stejné rozhraní. Tato vlastnost se může hodit například v případě, že by se v budoucnu vyskytl požadavek na změnu virtualizačního hypervizora, což se také v jedné z následných implementací BeeStacku stalo. Na customizované mutace BeeStacku můžete v současnosti narazit u komerčních služeb, jako jsou T-Mobile Cloud (http://cloud.t-mobile.cz/) a C4C-Server Cloud (http://www.c4c-server.com/). Obě tyto alternativní implementace využívají BeeStack takřka v nezměněné podobě, akorát je na úrovni hivu nahrazen standardní hypervizor Linux KVM hypervizorem VMware ESXi.
Název BeeStack je podle [19 s. 5] odvozen z názvu původní služby a anglického slova „stack“ (přeloženo z angličtiny jako „zásobník“1), což v praxi signalizuje, že iniciativa komunikace mezi jednotlivými komponentami modelu probíhá striktně shora dolů. Teprve na konkrétní dotaz shora může nižší hierarchická komponenta reagovat návratem odpovědi směrem vzhůru. Webové rozhraní Komponenta je tvořena třemi nezávislými nebo uživatelskou interakci se službou. Jedná se o
částmi
určenými
pro
aplikační
● webovou aplikaci, ● webovou aplikaci optimalizovanou pro zobrazení v mobilních zařízeních, ● aplikační programovací rozhraní (API). Webová aplikace služby BeeScale v podobě, se kterou uživatel může na adrese www.beescale.com interagovat, je (viz [19 s. 5–6]) výsledkem spojení sady open-sourcových technologií známých pod souhrnným označením LAMP (zahrnuje OS GNU/Linux, Apache HTTP Server, databáze MySQL a skriptovací jazyk PHP) a PHP frameworku Nette. Aplikace byla vyvinuta v jazyce PHP s přispěním interaktivizujících technologií AJAX (Asynchronous JavaScript and XML). Webové rozhraní má vlastní MySQL databázi, do které se ukládají data o uživatelích a nastavení týkajících se této úrovně BeeStacku. O průběžnou aktualizaci zobrazovaných informací a zobrazování zpětnovazebních notifikací na webu se stará sada webových cyclerů (intervalově časovaných nebo interaktivně vyvolaných úloh). Na aplikaci je mimo cyclery navázána i 3DSecure platební brána České spořitelny, díky které si uživatelé mohou pomocí svojí platební karty rychle dobít docházející kredit na svém kreditním kontě služby. Mobilní webová aplikace je dle tvrzení [19 s. 8] optimalizována pro mobilní telefony s menší plochou displeje s integrovaným webovým prohlížečem podporujícím AJAX. Aplikace je derivátem plnohodnotné verze pro PC. Jelikož je mobilní verze v současnosti uprostřed aktivního vývoje, umí provádět pouze základní operace na vlastních virtuálních serverech v serverovně (alias virtuálním datacentru) a zobrazovat o nich základní stavové informace. API BeeScalu považuji za jednu z klíčových částí pro tuto diplomovou práci, proto mu bude věnována samostatná kapitola s označením 2.3.2.
1
Fronta typu FIFO (First In, First Out).
Vymezení problematiky
23
Apiarist V rámci architektury BeeStacku zastává roli takzvaného cloudového hypervizora. Cloud hypervizor podle dokumentace BeeStacku (viz [19 s. 5]) není oficiálním pojmem, přesto však s ním ve svém vlastním znění operuje. Výklad tohoto pojmu lze interpretovat jako „řadič virtuální infrastruktury“, kterému je podřízen jeden a více zvirtualizovaných fyzických serverů, které tvoří infrastrukturní páteř služby. Na těchto serverech potom běží konkrétní virtuální stroje zákazníků. BeeStack tyto fyzické servery označuje pojmem Hives. Je-li potřeba vyhledat analogii k tomu, jakou funkci komponenta Apiarist v rámci BeeStacku zastává, stačí se poohlédnout například po aplikaci VMware vCenter, která slouží k centralizované obsluze fyzických serverů zvirtualizovaných prostřednictvím instalovaného hypervizoru VMware ESX nebo ESXi. Komplexní produktové portfolio pro virtualizaci datových center se v podání VMwaru (podle zdroje [45]) nazývá VMware vSphere. Apiarist je podle definice uvedené v [19 s. 5] software, který, stejně jako webové uživatelské rozhraní aplikace, vznikl tzv. „na zelené louce“, a to zejména proto, aby vyhovoval požadavkům, které si v OldanyGroup sami dle svých interních specifikací služby vytyčili. Kuriozitou je, že celý programový kód apiaristy je naprogramován v jazyce PHP, který je potom provozován na výkonném open-sourcovém webovém serveru Lighttpd. Aplikace má dostupná dvě nezávislá aplikační rozhraní. Prvním rozhraním je CLI (Command-line Interface) rozhraní, které je určeno pro volání metod aplikace pomocí systémové příkazové řádky. Rozhraní CLI využívají zejména cyclery, které zabezpečují chod rutinních operací, jako jsou například: kontrola příchozích plateb od zákazníků, vytváření přehledu o uživatelských účtech nebo spouštění naplánovaných procesů zálohování. Cyclery nejsou nic jiného než cyklicky spouštěné skripty, které do jinak statického apiaristy „vdechují“ život. Druhým rozhraním je XML-RPC (eXtensible Messaging Language – Remote Procedure Call), které pro svoji komunikaci s apiaristou využívá webové uživatelské rozhraní. Komunikace mezi cloudovým hypervizorem a jednotlivými hivy je realizována protokolem SSH (Secure Shell) pomocí další open-sourcové sady aplikací, v tomto případě OpenSSH. Konfigurace apiaristy je spolu s jeho operativními daty uložena v další izolované MySQL databázi. Hive Hive (jehož funkci popisuje [19 s. 6]) je označení pro fyzický serverový systém vybavený rozhraním schopným vykonávat pokyny od komponenty Apiarist skrz již jmenovaný protokol SSH. Úkolem hivu je řídit provoz uživatelských virtuálních strojů a jiných virtuálních zdrojů služby, například diskových úložišť, firewallu a virtuálních
Vymezení problematiky
24
síťových přepínačů. Roli lokálního hypervizora pro uživatelské virtuální stroje umístěné na hivech BeeScalu zastává již dříve zmíněný Linux KVM. Hive je řízen sadou skriptů interně nazývaných jako beescale-tools, které si v případě potřeby pomocí SSH apiarista volá. Mezi funkce této sady skriptů patří provádění základní operativy nad uživatelskými virtuály (například vypnutí/zapnutí/restart, provedení zálohy/obnovy nebo povolení/zablokování portu VNC pro vzdálenou správu) a předávání dat o čerpání výpočetních zdrojů uživatelskými virtuály na daném hivu, jež poslouží apiaristovi jako podklad pro statistiku vytížení jednotlivých hivů a zároveň jako podklad pro billing (vyúčtování poplatků za službu zákazníkovi).
2.3.2
Aplikační rozhraní
V předchozích kapitolách jsem nahrubo představil fungování backendu2 a uživatelského frontendu3 služby BeeScale, proto je teď načase, abych věnoval pár řádek části aplikace, která bude místem styku služby s předmětem této diplomové práce, mobilní aplikací BeeScale Client. Momentálně tedy bude řeč o aplikačním programovacím rozhraní, kterému je marketingově přezdíváno BeeScale API (viz [27]). Základním pilířem současného BeeScale API je Deltacloud, což je otevřený projekt zastřešený organizací Apache Software Foundation. Deltacloud (viz [3]) nabízí unifikované abstraktní rozhraní pro ovládání různorodých infrastrukturních cloudů mainstreamových poskytovatelů, jako jsou například Amazon, Microsoft, Terremark, IBM nebo Fujitsu. Další podporovaná infrastrukturní cloudová řešení mohou být nalezena na webu http://deltacloud.apache.org/drivers.html). Zdroj [3] uvádí, že Deltacloud je tvořen sadou předem připravených „driverů“, které představují rozdílné implementace Deltacloud API pro konkrétní infrastrukturní cloudová řešení. Pro BeeScale API bylo nutné vytvořit vlastní implementaci takového driveru. Mimo drivery Deltacloud obsahuje vlastní REST API rozhraní, pomocí kterého potom lze volat sada univerzálních cloudových metod, jež jsou následně prostřednictvím zvoleného driveru „přeloženy“ na instrukce „pochopitelné“ cílovou infrastrukturní službou. Úkolem serverové komponenty Deltacloudu (viz Obrázek 8) je transformace a výměna dotazů a odpovědí mezi REST API rozhraním a rozhraním infrastrukturního cloudu implementovaného příslušným driverem.
2 3
Backend – výkonné jádro aplikace, s nímž uživatel nepřichází do kontaktu. Frontend – uživatelem viditelná a ovladatelná část aplikace.
Vymezení problematiky
25
Obrázek 8 – Architektura projektu Deltacloud (zdroj: [3])
Rozhraní BeeScale API (https://beescale.com/api), potažmo Deltacloud REST API, je dotazovatelné pomocí jednoduchých HTTP dotazů typu GET, POST, PUT nebo DELETE. Jelikož je komunikace s tímto API bezstavová, je třeba každý dotaz autorizovat pomocí přihlašovacích údajů v podobě, jakou si služba vyžaduje. Dle zdroje [27] je BeeScale API dostupné pomocí nešifrovaného protokolu HTTP, popřípadě je možné využít jeho bezpečnější šifrovanou variantu, tedy protokol HTTPS. Na sémanticky a syntakticky správě formulovaný HTTP/HTTPS dotaz je potom rozhraním BeeScale API odpovězeno zprávou ve formátu XML. V případě, že dojde k jakékoliv chybě na vstupu či výstupu, je iniciátorovi dotazu odeslána odpověď označená standardním stavovým HTTP kódem označujícím událost, která při zpracování dotazu nastala. Výpis, který uvádím níže, demonstruje odpověď BeeScale API, kterou je možné získat při odeslání HTTP GET dotazu na adresu https://beescale.com/api. Výsledkem tohoto dotazu bude seznam dostupných datových kolekcí, s nimiž je možné v klientských aplikacích dále pracovat. Co která z uvedených kolekcí nese za data, bude dále probíráno v kapitole 5.3 věnující se objektové analýze.
Vymezení problematiky
2.4
26
Motivace projektu BeeScale Client
OldanyGroup již několik let pracuje na vývoji vlastní infrastrukturní cloudové služby, která by se stala komplementem již dříve etablovaného portfolia poskytovaných služeb. Výsledkem této snahy je BeeScale, tedy projekt, který navazuje a dále staví na létech praxe získané při implementacích komplexních virtualizačních projektů, a to jak pro komerční, tak i pro veřejnou sféru. Projekt vývoje aplikace BeeScale Client vznikl zejména z důvodu zvýšení atraktivity služby BeeScale pro stávající i nové potenciální klienty. Konkurenční firmy nabízející služby infrastrukturního cloudu většinou takovéto klientské aplikace poskytují, proto ani BeeScale nemohl v tomto ohledu zaostávat, ba navíc, měl by mít ambice dosavadní přidanou hodnotu existujících aplikací posunout ještě o úroveň výše. Další motivací vzniku samostatné mobilní aplikace je propagace služby prostřednictvím elektronického marketu Google Play a výhledově i dalších (v závislosti na rozšíření vývoje aplikace na další mobilní platformy). Platforma operačního systému Android byla přednostně vybrána právě kvůli svému většinovému publiku z řad uživatelů mobilních zařízení (viz [22]), tedy podílu uživatelů, jež může vyvíjená aplikace potenciálně oslovit a přinést další registrace uživatelů do služby BeeScale. Důvodem, proč aplikace BeeScale Client zaměřuje své úsilí zrovna na mobilní zařízení, je prostý. Mobilní zařízení, jako jsou například smartphony nebo tablety, meziročně strmým tempem zvyšují svůj podíl na poli spotřebitelské výpočetní techniky (viz zdroj [46]), proto se vývoj mobilní aplikace BeeScale Client, která by zpřístupňovala registrovaným uživatelům jejich oblíbenou službu na každém jejich kroku, jeví jako racionální krok.
Vymezení problematiky
27
2.5
Prerekvizity projektu
2.5.1
Nástroje objektové analýzy
Pro modelování analýz budu pro projekt BeeScale Client využívat CASE nástroj (Computer-aided Software Engineering) společnosti Sybase. Jedná se konkrétně o produkt PowerDesigner verze 15.3. Vzhled hlavního okna aplikace, které zachycuje její základní pracovní plochu, ilustruje Obrázek 9. K čemu produkt slouží, asi nejvýmluvněji dokumentuje hned první odstavec produktového webu, který jsem si dovolil níže citovat.
Obrázek 9 – Obrazovka aplikace PowerDesigner (zdroj: autor)
„PowerDesigner je první CASE nástroj, který komplexně pokrývá všechny aspekty rozvoje podniku. Obsahuje nástroje pro obchodně orientovanou procesní analýzu, která umožní identifikovat klíčová místa a funkce podniku jako takového a nabízí také plně integrované prostředí pro datovou a objektovou analýzu informačních systémů. Přitom plně podporuje zavedené přístupy a metodiky jako je Unified Modeling Language (UML) nebo tříúrovňový návrh databáze.“ [36]
Vymezení problematiky
28
V případě této práce se budu nejvíce zajímat o zúženou skupinu vývojářských modelů jazyka Unified Modeling Language známého pod zkratkou UML. UML je podle [4 s. 303] objektově orientovaný modelovací jazyk, který byl vyvinut v 90. letech minulého století a dnes je považován v této oblasti za velmi důležitý standard. UML verze 2.0 obsahuje typologickou sadu 13 různých diagramů. Pro kontext této diplomové práce však postačí znalost jen pár z nich. Jedná se o tyto diagramy objektové analýzy: ● Diagram tříd (Class Diagram) – nabízí neměnný (neinteraktivní) pohled na prvky modelovaného systému. [4 s. 309] ● Diagram stavů (State Diagram) – diagram pro zachycení stavů objektů v průběhu jejich životního cyklu. ● Sekvenční diagram (Sequence Diagram) – „zachycuje průběh zpracování v systému v podobě zasílání zpráv.“ [4 s. 313] ● Diagram případů užití (Use Case Diagram) - specifikuje uživatele interagující s daným systémem a popisuje úlohy, které tito uživatelé mohou se systémem provádět. [4 s. 304]
2.5.2
Vývojové prostředí
Nejsnazší cestou k tomu, stát se novým vývojářem platformy operačního systému Android, je naučit se programovat v programovacím jazyce Java a nainstalovat si již zmiňovaný Android SDK. Android SDK vyvěšený na oficiálním webu obsahuje podle zdroje [12] aktuální knihovny androidího aplikačního programovacího rozhraní a vývojové nástroje potřebné k samotnému programování, testování a ladění chyb. Stažením a instalací Android SDK lze získat balíček s volně dostupným komunitním vývojovým prostředím Eclipse4 přímo s vestavěným zásuvným modulem (plug-inem) známým pod zkratkou ADT (Android Developer Tools). Náhled toho, jak hlavní okno vývojového prostředí Eclipse v praxi vypadá, ilustruje Obrázek 10.
4
http://www.eclipse.org – podrobnosti o vývojovém prostředí Eclipse.
Vymezení problematiky
29
Obrázek 10 – Obrazovka vývojového prostředí Eclipse (zdroj: autor)
Android Developer Tools je balík skládající se z dalších dílčích užitečných komponent. Mezi ně patří tyto: ● Softwarové utility pro správu Android SDK. Za zmínku stojí správce virtuálních zařízení zvaný AVD Manager, který se stará o konfiguraci testovacích virtuálních zařízení provozovaných prostřednictvím emulátoru. Další důležitou utilitou je SDK Manager, který je určen ke stahování aktualizací již nainstalovaných součástí Android SDK, dále pak k instalaci a deinstalaci volitelných rozšíření, knihoven a firmwarů pro emulátor. ● Emulátor (virtuální stroj) schopný simulovat běh mobilního zařízení s některým z nainstalovaných firmwarů. ● Ovladače pro propojení vývojového prostředí s vývojovým rozhraním fyzického mobilního zařízení. Díky těmto specializovaným ovladačům je možné detailně sledovat a ladit interakce vyvíjené aplikace s instancí operačního systému běžícího na reálném zařízení.
Vymezení problematiky
2.5.3
30
Metodika vývoje
K tomu, abych dokázal co nejlépe popsat proces organizace softwarových projektů (na úrovni analýzy a vývoje) ve společnosti OldanyGroup, rozhodl jsem se nejdříve provést vlastní krátkou rešerši vývojových metodik s cílem nalézt takovou, která se nejvíce podobá metodice, jež se ve firemní praxi používá, avšak není nikterak formalizována. Pro získání obecného přehledu o problematice vývojových metodik jsem použil literaturu [4 s. 110–119], kde je uveden alespoň krátký popis jejich základních principů a kategorií. V průběhu rešerše jsem narazil na metodiku nazvanou Feature-Driven Development (FDD), která vykazovala s metodikou užívanou v rámci OldanyGroup značnou podobnost. Popis FDD a jeho rozdíly oproti metodice užívané v OldanyGroup uvádím v odstavcích níže. Podle [6] je FDD metodika, která „účelně spojuje modelování s principy agilního vývoje“ [6 s. 1] a je založena na iterativním vývoji tzv. užitných vlastností. Užitné vlastnosti jsou dílčí (účelně dekomponované) elementární funkce, které přináší zákazníkovi okamžitou a měřitelnou přidanou hodnotu. Užitné vlastnosti (tzv. features) se v tomto pojetí i v mé vývojářské praxi jeví jako velice efektivní indikátor a nástroj obhajoby pokroku vývoje. Jak jsem již předeslal, metodika FDD je metodikou agilní. Agilní metodiky jsou protiváhou metodik rigorózních, které jsou svojí přebujelou byrokracií pro malé projekty v malých týmech naprosto nevhodné a neefektivní. Agilní přístupy staví na jednoduchosti svého workflow, nepřetěžují pracovníky nadbytečnou byrokracií, kladou velký důraz na komunikaci a soustředí se na důležité oblasti, které přináší zákazníkovi v danou chvíli nějakou pozitivní přidanou hodnotu [6 s. 1]. Pružnost rozhodování a reakcí na změny je tak u těchto metodik mnohem vyšší než u těch rigorózních. Feature-Driven Development lze z velké části charakterizovat na již zmíněných obecných vlastnostech agilních metodik. Znaky (viz [6]), v nichž se FDD vymezuje oproti jiným metodikám, jsou ● vysoká iterativnost (dvoutýdenní vývojové cykly), ● důraz na kvalitu v každém dílčím výstupu, ● průběžné dodávání funkčních a měřitelných užitných vlastností zákazníkovi, ● snadný, smysluplný a objektivní reporting na všech úrovních projektu, ● minimalizace demotivujících faktorů na straně zákazníka i zpracovatele zakázky, ● procesně řízená metodika (procesní rámec je popsán co nejsrozumitelnějším a nejkratším možným způsobem).
Vymezení problematiky
31
Principy Autoři FDD ve své knize [32] uvádějí, že je jejich na důsledném dodržování 8 základních principů, jimiž jsou:
metodika
založena
● Domain Object Modeling – odhalit a vykonstruovat model nejdůležitějších objektů, které se vyskytují v řešené problematické oblasti (tzv. doméně). K modelování těchto objektů se užívá diagram tříd jazyka UML, který může být následně pro lepší pochopení vzájemných souvztažností doplněn o sadu sekvenčních diagramů. Doménový model je základním odrazovým můstkem pro celý následný proces vývoje. Jeho smyslem je stanovení výchozího architektonického konceptu a udržení celého řešení (množství v čase přidávaných užitných vlastností) v jednom konzistentním celku. ● Developing by Feature – vývoj postupuje po malých funkcích, již uváděných užitných vlastnostech. Každou užitnou vlastnost musí být reálné naprogramovat do dvou týdnů (jedna iterace). Komplexnější užitné vlastnosti je třeba podrobit dekompozici, čili rozdělení na dílčí jednoduché užitné vlastnosti. Užitné vlastnosti si definuje sám zákazník. Zákazník je také ten, kdo udává prioritu jednotlivým užitným vlastnostem v rámci celého jejich portfolia. ● Individual Class Ownership – individuální vlastnictví třídy znamená, že každou dílčí třídu objektů domény má na starost jeden konkrétní vývojář. Tento člověk pak obstarává dohled nad její integritou, konzistencí vzhledem k celku a dodržení dříve stanovené koncepce. Jakýkoliv požadavek na úpravu specifikace třídy musí být nejdříve konzultován s tímto pracovníkem. Vlastník třídy je v dané oblasti domény považován za experta, který o ní má absolutní přehled. ● Feature Teams – každou specifickou třídu vlastní jeden dedikovaný specialista, naproti tomu zpracování konkrétní užitné vlastnosti vyžaduje spolupráci obvykle více vlastníků tříd, jež se daná užitná vlastnost dotýká. Takto dynamicky formované týmy pro užitné vlastnosti v praxi čítají 3 až 6 vývojářů z různých doménových specializací. ● Inspections – odhalování konceptuálních a programových defektů je u metodiky FDD řešeno pomocí pravidelných inspekcí návrhu a kódu. Sleduje se dodržování pravidel zápisu kódu, řešitelská správnost a vhodnost. Inspekce kódu může sloužit méně zkušeným vývojářům i jako nástroj ke vzdělávání sebe sama. Mohou tak získat přehled o podnikem uznávaných best-practises, z čehož pramení možnost přímé absorpce návyků a kultury vývojářů, která se v dané společnosti formálně i neformálně prosazuje.
Vymezení problematiky
32
● Regular Builds – každá vyvíjená užitná vlastnost je v pravidelných intervalech (den až týden) integrována do komplexního aplikačního celku. Každý takový dílčí build5 je podroben testování, a to zejména z důvodu, aby nový přírůstek nenarušil funkčnost aplikace, která v předchozí verzi ještě fungovala. Další možností využití těchto pravidelných buildů může být i jejich pravidelná kontrolní prezentace zákazníkovi. ● Configuration Management – jako každá smysluplná metodika, tak i FDD dbá na udržování verzované historie kódu vyvíjené aplikace a komplexní projektové dokumentace (manažerské, vývojářské a uživatelské). ● Reporting/Visibility of Results – metodika FDD nabízí vlastní formát reportů o stavu projektu, ale hlavním výstupem by vždy měla být viditelně funkční aplikace dle parametrů ve znění, jak byly dříve se zákazníkem sjednány. FDD si zakládá na tom, že odbourává zbytečnou byrokratickou zátěž, proto jsou poskytované reporty vždy jednoduché a omezují se jen na to nejdůležitější, co přináší v danou chvíli nějaký užitek. Procesy
Obrázek 11 – Procesy metodiky FDD (zdroj: [32 s. 57])
Výše jsem zmiňoval, že metodika FDD je procesně řízená. Procesní workflow metodiky zachycuje Obrázek 11. Náplň jednotlivých procesů popisuje [6 s. 5], a to ve zkratce takto: ● Develop an Overall Model – cílem tohoto procesu je vytvoření uceleného konceptuálního diagramu tříd (tzv. domény). Tento výstup vzniká pod vedením hlavního softwarového architekta spolu s vývojáři, uživateli a odborníky na všechny věcné a kontextuální oblasti, jichž se aplikace dotýká.
5
Build – sestavení aplikace.
Vymezení problematiky
33
● Build a Features List – po stanovení doménového modelu přichází na řadu stanovení seznamu funkcí s přidanou hodnotou pro zákazníka. Výstupem tohoto procesu je hierarchický a kategorizovaný katalog užitných vlastností ● Plan By Feature – jakmile je připraven katalog užitných vlastností, pokračuje se vytvářením rámcové projektové osnovy – plánu užitných vlastností. Cílem tohoto procesu je vytvoření projektového plánu, který určuje posloupnost a termíny vývoje jednotlivých užitných vlastností. Role, které v tomto procesu participují: vedoucí projektu, vedoucí vývoje, hlavní programátoři se specializací na dané části domény. ● Iterační procesy o Design By Feature – účelem procesu je vytvoření variantních návrhů pro implementaci dílčí užitné vlastnosti. Dříve určený hlavní programátor ve spolupráci s vlastníky tříd, jež figurují v dotčené oblasti domény, vytváří sekvenční diagram nové užitné vlastnosti a rozšiřuje existující modely tříd o nové vlastnosti (metody a proměnné). o Build By Feature – „každý vlastník třídy realizuje metody, vytváří testovací případy pro svou třídu a provádí jednotkové testy. Po provedení testů vlastník třídy vloží třídu do systému pro správu verzí.“ [6 s. 6] Feature-Driven Development vs. metodika OldanyGroup Zásadním rozdílem mezi výše popsanou metodikou a metodikou užívanou v prostředí OldanyGroup je velikost projektových týmů, a to zejména kvůli četnosti personálního obsazení firmy. V současné době firma zaměstnává 3 kořenové zaměstnance a 4 brigádníky. Tato skromná čísla je nutné respektovat jako silné kapacitní omezení. Vývojové iterace jsou orientovány obvykle na 15 dní, ale vzhledem k časové vytíženosti brigádníků se délka iterace často dodatečně koriguje. Dále je nutné počítat se sezónními pauzami, například o zkouškových obdobích. Týmové role (podle definice FDD) nemohou být vždy dedikovány určité osobě, proto je pro metodiku firmy typické sdílení těchto rolí jedním a více pracovníky, zejména v případě vícero simultánně probíhajících projektů. Projekty v OldanyGroup jsou často dílem 1 až maximálně 3 vývojářů, kteří zároveň plní roli analytiků problematické domény. Koncepce projektu a architektura aplikace je ve fázi svého návrhu konzultována s manažery firmy, popřípadě s partnery, jež se na projektu podílí. Konečné a dílčí výstupy projektu jsou v předem smluvených kontrolních dnech prezentovány manažerům a zainteresovaným partnerům projektu. Vývoj aplikací je orientován na výsledek, čili i testovací scénáře spoléhají na reálnou uživatelskou zkušenost, spíše než na programování jednotkových testů, které by byly akorát tak ztrátou drahocenného času programátorů.
Vymezení problematiky
34
V OldanyGroup je zastáván názor, že aplikaci je lepší všestranně „proklikat“ nezávislým uživatelem, než ji testovat na programové případy, které uživatel v praxi mnohdy ani hypoteticky nemůže navodit. V případě složitějších vývojářských problémů je s oblibou uplatňována praktika párového programování známá z metodiky Extrémního programování (XP), tedy že vývoj určité části kódu je prováděn dvěma programátory sedícími fyzicky vedle sebe a jejich případné myšlenkové rozpory jsou řešeny na místě a právě v daný čas. Tento konsenzus dvou nezávislých kritických stran často ušetří spoustu času, který by byl jinak stráven několika iteracemi inspekcí kódu, konzultacemi a modifikacemi dané implementace.
2.5.4
Management projektu
Pro začátek výkladu této části je nutné řádně upřesnit pojem projekt, který je lidmi v praxi poměrně nadužívaný, přičemž není užíván vždy korektně a vzniká tak zbytečný prostor pro možná nedorozumění. K výkladu pojmu jsem využil obecnou definici podle normy ČSN ISO 10006:2003 (viz [7]), která projekt chápe jako jedinečný a neopakovatelný proces, který je složen z řady koordinovaných a řízených činností, jejichž počátek a konec je předem určen. Projekt má předem určený a parametrizovaný cíl, který by měl být výstupem zmíněného řízeného procesu. Parametry projektu jsou tvořeny především jeho časovým rámcem, potřebnými zdroji (lidské, finanční a kapitálové) k jeho realizaci a ukazateli determinujícími kvalitu jeho výstupu nebo dílčích výstupů. Alternativní definice projektu nabízí kniha [4 s. 283–284]. Pokud chceme projekt účelně a smysluplně řídit, přichází na řadu disciplína přezdívaná projektový management. Pro definici projektového managementu jsem si vypůjčil následující odstavec, tedy že management projektu je „Plánování, organizování, monitorování, řízení a předkládání zpráv o všech aspektech projektu a motivace všech zúčastněných dosáhnout cílů projektu.“ [4 s. 288]. Ve zkratce lze říci, že projektový management je sada činností, díky kterým je možné projekt zdárně dovést ze stádia příprav do stádia uzavření projektu a odevzdání jeho výstupů, kvůli kterým byl zřízen. To vše za soustavného respektování stanovených pravidel, omezení a udržení konzistence. V praxi se pro tuto problematiku užívá osvědčených metodik, jako jsou například PMBOK nebo PRINCE2. Žádný projekt nemůže dobře fungovat bez kvalitního realizačního týmu. Realizační tým nemůže pro změnu dobře fungovat bez schopného rámce pro řízení projektu a zkušeného leadera. Funkci rámce projektového řízení může poskytnout i běžně dostupný komerční software. V případě OldanyGroup je využíváno cloudového (SaaS) řešení nazvaného BaseCamp6, které je ve světě poměrně známé a firmami oblíbené.
6
http://basecamp.com – podrobnosti o službě BaseCamp.
Vymezení problematiky
35
BaseCamp je služba vyvíjená a provozovaná společností 37signals, LLC. Počátek působnosti služby na trhu se datuje k roku 2004. V dnešní době je (podle informací z [1]) skrze BaseCamp řízeno více než 8 milionů projektů ve více než 180 zemích světa. OldanyGroup svoji instanci BaseCampu využívá již od roku 2010 jako primární projektovou kolaborační platformu. BaseCamp je zde využíván jako projektový deník, místo pro zadávání průběžných úkolů, koordinaci a vzájemnou komunikaci pracovníků zodpovědných za přidělený projekt. Dále pak slouží ke správě dílčích projektových milníků (kontrolních bodů) a k uchovávání průběžně získávaného know-how a důležitých dokumentů vážících se na projekt. Úvodní stránku BaseCampu s přehledem aktuálních úkolů, jejich eskalací a zpráv od spolupracovníků ilustruje obrázek níže (Obrázek 12).
Obrázek 12 – Obrazovka dashboardu7 aplikace BaseCamp (zdroj: autor)
7
Dashboard – stránka s agregovaným přehledem důležitých událostí a výstrah aplikace.
Vymezení problematiky
2.5.5
36
Systém pro správu verzí
Systémy pro správu verzí jsou neodmyslitelnou součástí softwarové výbavy pro realizaci jednoduchých, ale i rozsáhlých softwarových projektů, na kterých se podílí jeden a více programátorů. V praxi se lze setkat s pojmenováními Software Configuration Management (SCM), Code Management System (CMS), Source Code Management (SCM), Version Control System (VCS) nebo Revision Control (RC), které s velkou pravděpodobností budou označovat ten samý software. Účelem těchto systémů je dle [21] uchovávání a správa historie verzí zdrojových kódů vyvíjených aplikací a jiných důležitých souborů. Přednosti takových systémů, oproti běžnému adresářovému pojetí úložiště zdrojových kódů například, se dají generalizovat v následujících klíčových vlastnostech: ● Distribuované – software je rozdělen do dvou částí, na serverovou a klientskou. Na serveru jsou uloženy původní verze projektů a jejich následné obsahové rozdíly (verze). Toto úložiště je možné obsluhovat z klientské aplikace, na jejíž straně je uložena jeho lokální (offline) kopie. Programátor pracuje primárně s tímto lokálním úložištěm, na němž jsou zaznamenávány případné změny, které je poté možné reflektovat na vzdáleném úložišti, nebo vrátit provedené změny zpět v případě nežádoucího směru vývoje. [21] ● Umožňující konkurentní vývoj – software je možné používat více uživateli zároveň (konkurentně). Takové úložiště může sloužit k uchovávání práce jednoho a více vývojářů buď v rámci jedné linie kódu, nebo si každý vyvíjí separátně svoji část (větev) programu. Tyto větve je potom (viz [21]) možné vzájemně slučovat, nebo dají možnost vzniku nové alternativě programu. Úložiště projektu může sloužit i pro supervizi (dohled autority) nad vyvíjeným kódem a vzájemné kontrole výstupů mezi programátory. ● Řízeno oprávněními – každému z projektů udržovanému na úložišti je možné nastavit vlastní přístupová oprávnění pro jednotlivé uživatele, aby nedocházelo k neoprávněnému průniku do repozitáře nebo k jeho změně. ● Minimalistické – systémy pro správu verzí podle zdroje [35] šetří čas a místo potřebné k ukládání zdrojových souborů. První načtení souboru nebo souborů do repozitáře proběhne v objemu 1:1. Následné uploady nových verzí potom tvoří pouze fragmenty zdrojových souborů, které zaznamenaly oproti předchozí verzi změnu. ● Bezpečné – mimo to, že je distribuovaný repozitář ochráněn proti neoprávněným manipulacím, nabízí i jiné bezpečnostní benefity (viz [21]). Centralizovaný repozitář se jednoduše zálohuje. V případě, že poslední uložená verze v repozitáři obsahuje nežádoucí chybu, je možné se vrátit v rámci dané vývojové větve zpět do některého jiného předchozího bodu, ve kterém byla aplikace ještě stabilní. Pokud dojde k výpadku serveru, na kterém je repozitář provozován,
Vymezení problematiky
37
ničemu to nevadí, protože každý vývojář má na svém počítači svoji offline verzi zdrojových kódů, která je kopií vzdáleného repozitáře. Ve chvíli, kdy je server s repozitářem opět dostupný, mohou vývojáři uploadovat své změny. Na potenciální konflikty v kódu jsou uploadující vývojáři před samotným uploadem upozorněni a vyzváni k nápravě závadné části. ● Nezávislé na platformě – klientská aplikace může být provozována na libovolné platformě – Linux, Windows nebo Mac. Jedním softwarem, který splňuje výše zmíněné specifikace je i GIT8, kterého shodou okolností pro své projekty využívá i OldanyGroup. Klientskou stranu tohoto řešení zastává aplikace s grafickým uživatelským rozhraním s názvem GIT Extensions9 (snímek historie repozitáře viz Obrázek 13). Bez této grafické nástavby lze s GITem komunikovat pouze pomocí standardního CLI rozhraní. GIT, jako takový, se „nelinuxovému“ uživateli poměrně těžko ovládá, proto tato grafická nástavba přijde vhod uživateli, který je zvyklý na grafické rozhraní operačního systému Windows.
Obrázek 13 – Obrazovka aplikace Git Extensions (zdroj: autor)
8 9
http://git-scm.com – podrobnosti o projektu Git. http://code.google.com/p/gitextensions – podrobnosti o aplikaci Git Extensions.
Vymezení problematiky
2.5.6
38
Testovací zařízení
OldanyGroup klade velký důraz na kontinuální a všestranné testování aplikací vyvíjených na její půdě. Pro vývoj aplikací stavěných na platformě operačního systému Android tento přístup platí dvojnásob, a to díky fragmentaci tohoto systému, jak ji popisuje v [37 s. 19] Jan Šesták. Obzvláště u této platformy je totiž nezbytná dostatečná rozmanitost testovaných zařízení, protože každý výrobce využívá své vlastní modifikované verze tohoto systému. Je proto velice pravděpodobné, že aplikace, jež funguje na zařízení jednoho výrobce, nebude fungovat na zařízení výrobce druhého, a naopak. Pokud se vývojář chce v budoucnosti vyvarovat nežádoucího chování a nechtěných „pádů“ nové aplikace, musí tento fakt respektovat. Mimo emulátoru, který je dostupný ve vývojovém prostředí Eclipse, má OldanyGroup k účelům testování k dispozici zařízení: ● Samsung Galaxy Tab 10.1 – tablet s úhlopříčkou 10,1“, rozlišením 1280 x 800 pixelů, vybavený Wi-fi adaptérem a 3G modemem, Androidem Honeycomb 3.1, ● Samsung Galaxy S2 – smartphone s úhlopříčkou rozlišením 800 x 480 pixelů, vybavený Androidem Gingerbread 2.3,
4,27“,
● HTC One S – smartphone s úhlopříčkou 4,3“, čili 960 x 540 pixelů, vybavený Androidem Jelly Bean 4.1,
qHD,
rozlišením
● HTC One V – smartphone s úhlopříčkou 3,7“, rozlišením 800 x 480 pixelů, vybavený Androidem Ice Cream Sandwich 4.0.3.
Studie metodik tvorby GUI mobilních aplikací
39
3 Studie metodik tvorby GUI mobilních aplikací 3.1
Rešerše tuzemských a zahraničních tezí
Při rešerši tuzemských a zahraničních akademických kvalifikačních prací jsem narazil řadu bakalářských a diplomových tezí, které řeší analogickou problematiku, tedy že provádějí analýzu požadavků, návrh a následný vývoj aplikace, kterou si řešitelé sami navrhli, nebo jim byla přidělena zaměstnavatelem. Co však téměř žádná z nalezených prací konkrétně a do hloubky neřeší, jsou metodologie, principy a doporučení pro tvorbu dotykového grafického uživatelského rozhraní pro mobilní zařízení se zaměřením na platformu Android. Tento poznatek mě poněkud udivil, obzvláště v době, kdy design GUI a pozitivní uživatelská zkušenost hraje ve světě „chytrých telefonů“ prim. Veřejné, dokonce ani neveřejné zahraniční informační zdroje shromažďující odborné práce nevykazovali shodu s problematikou, kterou v rámci této diplomové práce pokládám jako vlastní přínos. Když už teze neřešila problematiku návrhu GUI z pohledu programování pomocí nativního kódu, pokrývala tuto problematiku alespoň částečně z pohledu vývoje aplikací založených na technologiích HTML5 a CSS (viz například [18]). Rozhodl jsem se však, že BeeScale Clienta budu řešit pomocí instrumentů nativního kódu pro konstrukci grafických šablon (layoutů). Pro programátory, kteří hledají publikaci, která je uvede do problematiky vývoje pro Android v obecné rovině, doporučuji nastudovat kvalifikační práce Ing. Jana Šestáka [37] a Bc. Josefa Vaculi [44]. Vedle zákonitostí vývoje na této platformě v nich autoři uvádějí popisy ke každé položce z palety grafických komponent, kterými Android disponuje. Kvalifikačních prací, které se věnují návrhu GUI pro desktopové aplikace, je pro změnu spousta. Bakalářská práce [9] Ing. Tomáše Dohnala shrnuje 13 základních principů, jimiž by se každý vývojář uživatelského rozhraní měl řídit, pokud chce, aby aplikace u uživatele vyvolávala pozitivní emoce. Po přečtení této práce jsem vyhodnotil, že uvedené principy půjde částečně aplikovat i do sféry mobilních zařízení.
Studie metodik tvorby GUI mobilních aplikací
40
Bakalářská práce [38] Ing. Pavla Šilara se taktéž orientuje na problematiku tvorby GUI pro desktopové aplikace, avšak přináší problematice nový úhel pohledu. Snaží se propojit principy návrhu s vazbou na kognitivní vědy. Kognitivní věda je dle slov autora „interdisciplinární obor zahrnující kognitivní psychologii, psychobiologii, filosofii, antropologii, lingvistiku a umělou inteligenci. Jejím cílem je pochopení myšlení (kognice).“ [38 s. 12] V průběhu zpracovávání rešerše jsem narazil na bakalářskou práci, která se na první pohled nemusí zdát pro kontext této práce důležitá, ale může určitým způsobem podporovat alibi, proč se ve vývoji GUI vydat vlastní cestou a ne slepě následovat doporučení, které Google uvádí na svém webu [11]. Jedná se o bakalářskou práci Tomáše Madeje (viz [23]), která empirickým způsobem mapuje produktivitu práce uživatelů na předem připravených testovacích aplikacích napříč všemi hlavními mobilními platformami, jež jsou u nás na trhu zastoupeny. Z toho je možné vyvodit pro a proti každé z platforem a pokusit se tyto přirozené vady odbourat vlastním přičiněním.
3.2
Rešerše ostatních informačních zdrojů
Tato kapitola oproti předchozí zkoumá zdroje mimo akademické kvalifikační práce, tedy odborné časopisy, příručky, blogy odborníků, jež se problematikou grafického uživatelského rozhraní zabývají. V první řadě bych rád zmínil pojem „UI design patterns“, který ve volném překladu znamená „návrhové vzory uživatelského rozhraní“. Po zadání výrazu do internetového vyhledávače bude vylistován nespočet webů, které mohou vývojářům „bez nápadu“ pomoci k cenné inspiraci pro vlastní návrh obrazovek uživatelského rozhraní. Tento postup podporuje i článek [17] webu Dice News. Není nutné se omezovat na platformu, pro kterou je návrhový vzor určen, protože možnosti transformace formy grafických komponent Androidu jsou téměř bezmezné. V článku [2] na webu iriphon redaktorka uvádí zajímavé odkazy řešící problematiku návrhových vzorů přímo pro Android. Článek [34] časopisu InformationWeek přináší 7 tipů k tomu, aby nově vytvářená aplikace nedělala nic jiného, nežli aby sbírala obdiv svých uživatelů. Těchto 7 tipů pokrývá jak oblast analýzy, plánování, ale i návrhu a testování. Článek [47] časopisu Newstex staví proti sobě tvorbu GUI pro Android a iOS. Velebí iOS pro jeho jednoduchost a širokou škálu možností designu a kompozice prvků uživatelského rozhraní. Vývoj aplikací pro iOS by tak měl být o mnoho rychlejší. Apple iOS se však na rozdíl od konkurenta nemusí vypořádávat s různorodostí parametrů potenciálních zařízení, na kterých aplikace poběží, protože napříč generacemi iPhonu
Studie metodik tvorby GUI mobilních aplikací
41
je změn parametrů zanedbatelné minimum. V tom má autor článku i podle zdroje [11] pravdu, ale tuto informaci jsem zatím neměl šanci verifikovat v praxi. Za nejdůležitější zdroje informací považuji pokyny (z angl. guidelines), které od Androidu verze 4.0 publikuje společnost Google na svém webu (zdroj [11]). Jako protipól z praxe jsem nalezl příručku [26], která unikla společnosti Mutual Mobile. Další komplexní sadu pokynů publikoval ve webovém příspěvku [24] Jamie McDonald, který působí ve společnosti Novoda jako vývojář mobilních aplikací pro Android.
3.3
Doporučení plynoucí ze studie
3.3.1
Důkladné plánování
Prvním krokem, než je přikročeno k samotnému návrhu, je zapotřebí si mezi zainteresovanými subjekty řádně ujasnit, čeho chceme s aplikací dosáhnout, co by měla umět, a pro koho je aplikace vůbec určena. S aplikací je možné nakládat jako se zbožím, které má cílovou skupinu, pozici na trhu, distribuční kanál a cenu, popřípadě hodnotu, kterou aplikace uživateli přináší. Nejlépe, když bude k návrhu aplikaci přizvána skupina potenciálních uživatelů, kteří vysloví své každodenní potřeby, přece jen tito lidé budou aplikaci využívat, ne vývojář. Oproštění se od svého úzce orientovaného náhledu na věc je půlka úspěchu.
3.3.2
Inspirace
Cesta k dobrému návrhu, který reflektuje současné trendy uživatelského rozhraní, vede skrze rešerši aplikací, které jsou mezi uživateli oblíbené, a soustředit se zejména na ty, s jejichž zaměření se nová aplikace alespoň částečně shoduje. Tyto aplikace totiž vynucují oborový standard a budují návyky a umělou intuici lidí. Pokud je vývojář s uživateli ve shodě, že dostupné aplikace postrádají nápaditost, otevírá se tak možnost čerpání moderních návrhových vzorů pro uživatelská rozhraní. Podotýkám, že vývojář, který nemá reálnou zkušenost s používáním smartphonu nebo tabletu s Androidem, nemůže pro něj navrhnout dobré GUI.
Studie metodik tvorby GUI mobilních aplikací
3.3.3
42
Koncept, detail a realizace
Prvotní klíčové podněty a nápady, jak by uživatelské rozhraní mělo vypadat, přichází na mysl rychle a nečekaně. Jedná se o iterativní proces, jenž je omezen pouze lidskou fantazií. Z toho důvodu je lepší začít se skicovým papírem s nákresem zařízení, a to nosit stále při sobě pro případ, kdyby dotyčnému vytanula na mysli nějaká revoluční myšlenka. Teprve v případě, že dojde ke kolektivní shodě se zadavatelem a vývojářem, může dojít k vyhotovení prvních detailních maket, ať už v aplikaci Adobe Photoshop pro zpracování grafiky, nebo přímo ve WYSIWYG10 editoru vývojového prostředí. Užitečnou utilitou pro testování bitmapových maket na displeji emulátoru nebo „živého“ zařízení je Android Design Preview Tool. Ve fázi, kdy máme připravenou sadu maket zamýšlených obrazovek, je si potřeba rozvrhnout navigační tok – odkud a kam se půjde navigovat a za jakých podmínek. Prvním doporučeným krokem je výběr hlavní obrazovky, od které se uživatel může dále navigovat. Navigace by měla být jednoduchá a přímočará. Maximální počet navigačních kroků je subjektivní veličinou, ale rozhodně by neměl překročit mez, která by vedla uživatele ke ztrátě orientace, což lze při sledování jeho způsobu používání vypozorovat. Návrh nové aplikace by v žádném případě neměl překračovat dogmata dané platformy, které lze vyčíst na webu dedikovanému této problematice (viz [11]). Stejně tak se nedoporučuje přenášení uživatelského rozhraní hotové aplikace z jedné platformy na druhou. To platí například pro iOS a Android, protože uživatelé těchto systémů mají zákonitě jiné návyky. Nejen konzistence vůči zvyklostem dané platformy je důležitá, ale to stejné platí pro konzistenci uvnitř aplikace. Kompozice, barvy, fonty i ovládání musí mít jednotný charakter. Pro vývojářské firmy je mimo jiné typické, že si určité sjednocující grafické prvky nesou napříč aplikacemi z jejich dílny, a to jako signaturu firemní image. Programátoři, kteří přesedlali z pozice vývojáře pro desktopové aplikace na vývoj aplikací pro mobilní zařízení, si musí uvědomit, že přicházejí do styku se zařízeními, jejichž displeje a ovládací plocha nedisponují rozměry stolního počítače nebo notebooku. Z tohoto pohledu je nutné reflektovat proporce lidského prstu, jakožto nástroje pro ovládání aplikace, a displeje daného zařízení. Je třeba zvolit takové rozměry ovládacích prvků, aby ani uživateli s největšíma rukama nečinilo problém je obsluhovat. Špatná ovladatelnost se prakticky okamžitě odrazí v nechuti uživatele s aplikací dále pracovat. Výsledkem realizační fáze GUI je poté sada XML souborů, které lze upravovat buď zmíněným WYSIWYG editorem nebo prostým zásahem přímo do textové podoby souboru. Pro hrubé vysázení grafických komponent se hodí využít WYSIWYG editor, 10
WYSIWYG – „What you see is what you get”
Studie metodik tvorby GUI mobilních aplikací
43
ale pro následné optimalizace a lazení drobných detailů je praktičtější využívat textovou podobu návrhu tvořenou XML tagy. Důrazně doporučuji separovat formu od obsahu, čili že hodnoty, textové řetězce a styly by měly být umístěny mimo XML soubory layoutů.
3.3.4
Reflexe diverzity cílových zařízení
V momentu, kdy vývojář touží do aplikace přidat první zkrášlující bitmapové grafiky, která slouží například jako ikony tlačítek nebo přihlédnou ke zmíněné diverzitě parametrů cílových zařízení, které velikosti displeje a hustotě umístění obrazových bodů na palec (DPI Rozdíly napříč ustálenými konfiguracemi displejů ilustruje Obrázek 14.
prvky v podobě pozadí, je třeba se týkají hlavně – dots per inch).
Obrázek 14 – Škálování grafických objektů v Androidu (zdroj: [24])
Problémům s deformací grafiky se lze vyhnout například vygenerování velikostních variant pro různé konfigurace displeje, nebo využitím tzv. 9-patches, kdy se ve speciálním editoru vyznačí části obrázku, které se mohou při vykreslování roztáhnout nebo zmenšit bez zjevného zkreslení. Dále se vyznačí části, jejichž obsah bude neměnný. Typickou vlastností Androidu, která od nepaměti trápí vývojáře, je velký počet různých verzí operačního systému. Toto je navíc podpořeno tím, že každý výrobce si originální verzi přizpůsobuje k obrazu svému. Dalším z bodů kritiky je neochota výrobců udržovat verze firmwarů jejich zařízení na úrovni aktuální verze Androidu vydanou společností Google. Vývojářům tak nezbývá nic jiného, nežli si před vývojem aplikace udělat průzkum trhu, aby zjistili, která z verzí je na trhu aktuálně nejvíce zastoupená, a na API této verze aplikaci zacílit. Záleží však na preferencích zadavatele a cílové skupině. Zpětná kompatibilita je však vykoupena řešením starostí s chybami, které jsou v nových verzích již vyřešeny, a omezenou paletou integrovaných komponent.
Studie metodik tvorby GUI mobilních aplikací
3.3.5
44
Zábava pro uživatele
Uživateli se nemůže stát nic horšího, nežli že narazí na aplikaci s designem webu z 90. let minulého století. S aplikací neinteraktivní, mdlou, nekonzistentní a zkrátka nudnou. V tomto ohledu pro mobilní aplikace platí stejná pravidla jako pro ty desktopové. Prvním a nejdůležitějším pravidlem je nezapomínat na zpětnou vazbu. Uživatel musí mít pocit, že s ním aplikace komunikuje jako živý organismus. Každý stisk tlačítka tak musí zákonitě vyvolat adekvátní reakci, a to nejen v podobě požadovaného výkonu, ale i grafickým znázorněním. V případě, že logika aplikace získává nebo zpracovává blokujícím způsobem data, nesmí uživatele nechat čekat bez patřičného zabavení, které odvede jeho pozornost a neznechutí jej. Plochy obrazovek mobilních telefonů často trpí nedostatkem prostoru, proto by počet grafických prvků rozhraní měl být co možná nejvíce úsporný a s co největšími možnými mezerami mezi objekty GUI. Toto platí zejména pro aktivní ovládací prvky, jako například tlačítka, kde hrozí riziko „překliknutí“, jehož následky mohou být fatální. Vývojář by se měl vždy snažit vytěžit z kontextu co nejvíce, a nalezené styčné kontextuální prvky shlukovat v kompaktní celky. Ovládání aplikace tak půjde mnohem lépe porozumět. V místech, kde to kontext dovoluje, je výhodné využít kontextového menu, jimž si lze na layoutu obrazovky ušetřit místo, které by jinak bylo zkonzumováno tlačítky. Aplikace plná textu je pro uživatele vždy nepříjemná. Proto doporučuji využívat krátkých a vystižných formulací, které jsou cílové skupině srozumitelné. To samé lze říci o množství speciálních gest pro ovládání dotykem. Lepší je se omezit pouze na standardní gesta. Bez použití nápovědy by na tato speciální gesta totiž nikdo pravděpodobně nepřišel, nebude to intuitivní. Kvalitně napsaná aplikace a navržené GUI by nápovědu ani nemělo potřebovat.
3.3.6
Důkladné testování, potom publikace
Když už se zdá, že je aplikace připravena k vypuštění do světa, od elektronického tržiště Google Play, není záhodno proces publikace uspěchat, protože to může mít špatné následky, které u uživatelů nastolí pocit, že vaše aplikace nestojí za nic, a je pak docela pravděpodobné, že si už aplikaci stejného výrobce nestáhne. Proto i v případě, že aktualizace aplikace bude nedostatky předchozí verze řešit, znechucený uživatel na to již bohužel ani nemusí přijít, protože již aplikaci odinstaloval. Doporučuji proto aplikaci nechat otestovat skupinou nezávislých uživatelů mimo firmu, kteří nebudou mít zažité žádné testovací scénáře, které byly projity již nespočetněkrát.
Studie metodik tvorby GUI mobilních aplikací
45
Tito uživatelé velice pravděpodobně nějakou chybu naleznou. Takové faux-pas je lepší si před veřejností ušetřit. To stejné platí o designu a ovládání aplikace. Dalším z faktorů ovlivňující výběr aplikace, kterou uživatel do svého zařízení stáhne, je prezentace na Google Play. Tuto problematiku stojí za to přenechat marketingovým specialistům, zejména pokud chcete, aby aplikace vydělávala peníze. Při zadávání prezentace aplikace do elektronického tržiště je třeba správně navolit seznam parametrů, které determinují cílová zařízení, na které lze následně aplikaci nainstalovat. Například, pokud je aplikace vyvíjena ryze pro dotyková zařízení, nebude zrovna nejlepší volbou výběr kategorie zařízení bez dotykového panelu.
Předprojektová analýza
46
4 Předprojektová analýza 4.1
Požadavky na aplikaci BeeScale Client
V měsíci červnu roku 2012 byla na základě mé konzultace s hlavním vývojářem BeeScalu a manažery OldanyGroup formulována následující sada požadavků na aplikaci s pracovním názvem BeeScale Monitor, jež byla následně přejmenována na současný komerční název BeeScale Client. Výsledkem předprojektové zadávací konzultace jsou následující výchozí požadavky, jimž v Příloze A dávám standardizovanou podobu, jak ji dle svých doporučení prezentuje Ing. Radek Theier ve své diplomové práci [41 s. 137]. ● Aplikace musí být kompatibilní se zařízeními s operačními systémy Android 2.1 (Eclair) a vyššími. ● Grafické uživatelské rozhraní musí mít jednoduché a intuitivní ovládání. Měla by respektovat oborově uznávané best-practises pro dotykové ovládání, navigaci na mobilních platformách a vycházet z grafické šablony, která je uživatelům webové verze aplikace BeeScale dobře známa. ● Přístup do aplikace musí být autorizován uživatelským jménem a heslem. Uživatelské jméno a heslo je možné uložit do paměti zařízení. ● BeeScale Client bude před přihlášením zobrazovat aktuality (upozornění, zprávy o výpadcích služby, aktualizace a novinky) vztahující se k provozu služby. Bude využito existujícího informačního kanálu na sociální síti Twitter (http://twitter.com/beescale). ● Vytvoření přehledové obrazovky informací o účtu aktuálně přihlášeného uživatele. Tyto informace zahrnují o jméno uživatele, e-mailovou adresu, o výši kreditu, aktuální spotřebu kreditu, režim (limit) uživatelského účtu, o seznam provedených plateb do kreditního systému, o sumarizaci počtu vServerů a vDisků. ● Možnost provést vklad do kreditního systému služby BeeScale z prostředí aplikace. Využít buď funkcionality API Androidu, nebo umožnit přesměrování uživatele na web, kde bude přichystána aplikace platební brány. ● Možnost registrovat nového uživatele. ● Vytvoření obrazovky s přehledem o virtuálním datacentru uživatele. Tento základní přehled bude zobrazovat vServery uživatele. U každého z vServerů bude zobrazen
Předprojektová analýza
47
jeho název, aktuální stav, veřejná IP adresa (případně IP adresy) a nainstalovaný operační systém. ● Vytvoření obrazovky se seznamem dostupných asynchronních úloh, které lze v danou chvíli nad vybraným virtuálním serverem provést. Seznam možných akcí zahrnuje operativní operace, jako jsou o spuštění/vypnutí/restartování vServeru, o povolení/zakázání portu pro vzdálenou správu pomocí VNC, o smazání vServeru. ● Vytvoření obrazovky detailních informací o aktuálně vybraném vServeru. Mezi tyto informace patří o bližší specifikace aktuálního stavu serveru, o parametry serveru – kapacita vRAM, počet disponibilních vCPU, o informace o připojených vDiscích, o přidělené veřejné IP adresy, o přihlašovací údaje k serveru, o informace o VNC připojení – stav, parametry připojení a přihlašovací údaje. ● Vytvoření obrazovky s grafy vytížení výpočetních zdrojů – vRAM, vCPU, vNET (pokud existuje podpora na dané implementaci podpora). ● Možnost vytvářet nové virtuální servery do datového centra uživatele na základě uživatelem definovaných parametrů. ● Možnost vzdáleného ovládání a ověření dostupnosti vServerů. ● Vytvoření obrazovky pro správu nepřipojených vDisků. Nepřipojené vDisky bude možné prohlížet, mazat nebo je připojit k novému nebo již existujícímu vServeru. ● Možnost rekonfigurace vServerů – konfigurace parametrů vServeru, připojení nebo odpojení vDisků. ● Minimalizace náročnosti na šířku pásma. Komfort práce s aplikací a její odezva by měli být přijatelné nejen na sítích 3. generace a modernějších, ale i na sítích, kde je podpora pouze pomalého GPRS nebo EDGE. ● Důraz na bezpečnost aplikace. ● Možnost snadné lokalizace aplikace do jiných jazyků. ● Možnost snadné změny grafické šablony aplikace pro potřeby rebrandingu.
Předprojektová analýza
4.2
48
Harmonogram projektu
Tabulka 1 shrnuje jednotlivé vývojové fáze projektu. První dvě fáze jsou přípravné. Každá další fáze ve svém závěru reprezentuje build, který je kandidátem k publikování na elektronický obchod Google Play pro distribuci aplikace široké veřejnosti. Implementační fáze (od 3. fáze výše) jsou v tabulce dodatkovány požadavky, které se průběhu dané fáze řeší. Názvy požadavků korespondují s těmi v Příloze A. Termíny uvedených fází na sebe bezprostředně nenavazují, protože vývoj aplikace BeeScale Client je pojímán jako okrajová záležitost. Prioritu má projekt tenkého klienta TiCtOG a operativa obchodního oddělení, kterou v OldanyGroup řeším. Práce na vývoji BeeScale Clienta se soustřeďuje zejména do období letních měsíců, kdy je pracovní tempo uvolněné z důvodů dovolených a tendence k poklesu zakázek. Roli důležitého kapacitního limitu hrálo potenciální studijní zatížení mé osoby. Pořadí 1. 2. 3.
4.
5.
6.
7.
8.
Fáze projektu Termín Analýza požadavků nové aplikace 05. 06. - 12. 06. 2012 13. 06. - 20. 06. 2012 Konceptuální návrh aplikace 25. 06. - 24. 07. 2012 Verze 1.0 - Přihlášení uživatele - Výčet vServerů ve virtuálním datovém centru 25. 07. - 07. 09. 2012 Verze 1.1 - Detail uživatelského účtu - Výčet akcí vybraného vServeru - Výčet detailních informací o vybraném vServeru 24. 09. – 23. 10. 2012 Verze 1.2 - Formulář pro tvorbu nového vServeru - Grafy statistik vybraného vServeru 07. 01. - 19. 02. 2013 Verze 1.3 - Aktuality z Twitteru - Diagnostika vServeru - Správa nepřipojených vDisků 04. 03. - 17. 04. 2013 Verze 1.4 - Registrace uživatele - Dobití kreditu - Rekonfigurace existujícího vServeru 01. 07. - 15. 07. 2013 Verze 1.5 - Vzdálené řízení vServeru Tabulka 1 – Fáze projektu BeeScale Client (zdroj: autor)
BeeScale Client je navržen jako tenký klient, jehož softwarovou architekturu jsem z praktických důvodů rozdělil do tří vrstev – prezentační vrstva, aplikační vrstva a datová vrstva. Aplikace samotná fyzicky obsahuje jen prezentační a aplikační logiku. Aplikace kromě konfiguračních dat neudržuje žádná uživatelská data, poněvadž poměrně rychle zastarávají a jejich objem není tak velký, aby je bylo zapotřebí uchovávat. Veškerá průběžná data jsou načtena v operační paměti přístroje a zapouzdřena v objektovém datovém modelu, jak jej popisuje konceptuální diagram tříd v kapitole 5.3 (viz Obrázek 17). Zdroje datových vstupů (3. vrstva), které jsou opatřeny vlastní logikou a dotazovacím rozhraním, se nacházejí mimo aplikaci.
Návrh aplikace
5.1.1
50
Prezentační vrstva
Prezentační logika aplikace má na starosti odbavování interakce s uživatelem, skladbu jednotlivých obrazovek, jejich dílčích prvků a dialogů dle programátorem předepsané šablony. Na této úrovni je mimo to řešena i lokalizace textových řetězců. Grafická šablona a lokalizační část jsou snadno zaměnitelné za jiné, protože jsou vyčleněny mimo aplikační kód. Nahraditelnost těchto částí výrazně urychluje uspokojení poptávky po případném rebrandingu aplikace pro alternativní implementaci BeeStacku. To stejné platí pro vydávání aplikace v alternativních jazykových mutacích.
5.1.2
Aplikační vrstva
Komponenta aplikační logiky je prostředníkem mezi grafickým uživatelským rozhraním a externími datovými zdroji, ze kterých aplikace získává data a odesílá na ně své požadavky. Jejím úkolem je provádění transformace získaných dat do podoby prezentovatelné pomocí prezentační logiky, proto zároveň udržuje selektivní a účelně strukturovanou stínovou kopii datových kolekcí získaných z BeeScale API. Dále pak reaguje na události vyvolané interakcí uživatele s prezentační vrstvou. Tato komponenta, mimo jiné, samotné aplikaci „vdechuje život“, protože je prvkem, který řídí její vnitřní automatizované procesy. Plní roli tzv. aplikačního controlleru. Hlavním procesem tohoto controlleru je pravidelná aktualizace dat stínové kopie z BeeScale API a následné překreslení dat na prezentační vrstvě.
5.1.3
Datová vrstva
Úkolem externích komponent na této vrstvě je zpřístupňovat své distribuované dotazovací rozhraní, díky kterému může klientská část aplikace získávat požadované datové kolekce a volat dostupné metody, které vyvolají patřičnou reakci cílového systému. Komunikace mezi aplikační a datovou vrstvou je realizována v šifrované podobě pomocí standardního protokolu HTTPS.
Návrh aplikace
5.2
51
Případy užití
Obrázek 16 – Diagram případů užití (zdroj: autor)
Obrázek 16 v přehledné formě prezentuje budoucí funkcionální výbavu aplikace BeeScale Client, která vychází z požadavků, jež byly uvedeny v předprojektové analýze v kapitole 4.1. Uvedený diagram užití dle specifikace modelovacího jazyka UML znázorňuje logický rozpad jednotlivých funkcí, jež zároveň slouží jako podklad pro sestavení navigační mapy a konceptuálního schématu jednotlivých obrazovek aplikace. Případy užití aplikace BeeScale Client zahrnují pouze jednu uživatelskou roli, a to roli řadového zákazníka služby. Rozhraní pro roli administrátora je dostupná pouze skrze plnohodnotnou webovou verzi aplikace služby BeeScale.
Obrázek 17 zachycuje hrubý (konceptuální) diagram tříd, který vnikl na základě zadávacího jednání za účasti vývojářů BeeScalu, mojí osoby a pod supervizí manažerů OldanyGroup. Výslednou podobu a význam jednotlivých tříd spolu se závěry, které diagram není s to interpretovat, popisuji na následujících podkapitolách, kdy každá z nich reprezentuje právě jednu třídu z uvedeného diagramu.
Návrh aplikace
5.3.1
53
Account
Třída Account reprezentuje účet uživatele registrovaného v rámci infrastrukturního cloudu BeeScale. Věcným podkladem této třídy je datová kolekce /api/account. Jednoznačným identifikátorem objektu (v tomto případě uživatele) je jeho uživatelské jméno (email), které bylo převzato z emailové adresy, pod kterou byla provedena prvotní registrace uživatele do služby. Atributy firstname a lastname slouží k následnému oslovení uživatele a jako iniciály pro fakturaci. Limit uživatele je sadou omezení uživatelského účtu, které se promítají do možností manipulace uživatele se svým datovým centrem (možnost vytváření/rekonfigurace vServerů a maximální počet vServerů), dále pak omezují rozsahy přípustných parametrů, jež mohou být uplatňovány při vytváření nových virtuálních serverů nebo jejich rekonfiguracích (maximální počet vCPU, kapacita vRAM, kapacita vDisků atd.). Limity se též dotýkají disponibilní kapacity síťového provozu a množství povolených uživatelsky definovaných periodických akcí (spuštění, restart, vypnutí nebo zálohování). Identifikátor uživatelského limitu, který je v danou chvíli na daný uživatelský účet uplatňován, lze získat z atributu currentLimit. V případě potřeby uvalení dočasných nebo trvalých omezení ze strany administrátora služby na uživatele může být uživatelský limit upraven. To samé se děje, pouze automatizovaně, i v případě nedostatečného finančního krytí na uživatelském kreditním kontě. Jaký limit má uživatel za běžné situace nastaven, může být zjištěno z atributu defaultLimit. U uživatelského účtu lze přes BeeScale API pomocí získané paymentUri lokalizovat datovou kolekci, která je nositelem seznamu provedených plateb na kreditní konto uživatele.
5.3.2
Payment
Třída Payment slouží k reprezentaci jednotlivých datových záznamů o platbách uskutečněných uživatelem na jeho kreditní konto. Tato data jsou získávána z datové kolekce /api/account/payments. Záznam se skládá z částky (amount) zaplacené na vrub virtuálního konta a časového razítka (date) determinujícího dobu, kdy byla platba na konto připsána. Atribut provider potom určuje, skrze který platební kanál byla platba zprostředkována. Platební kanály představují ● běžný převod na účet poskytovatele služby, ● elektronickou platební bránu PayU, ● elektronickou platební bránu České spořitelny, a.s.
Návrh aplikace
5.3.3
54
VmInstance
VmInstance je abstrakcí konkrétních instancí virtuálních serverů vyskytujících se uvnitř uživatelova virtuálního datového centra. Datová reprezentace se nachází na rozhraní BeeScale API pomocí /api/instances. Každá instance této třídy nese informace o aktuálně přidělených výpočetních zdrojích (počet vCPU a kapacita vRAM) a dalších důležitých nastaveních, jako jsou ● výčet IP adres, na kterých je vServer dostupný z internetu, ● přihlašovací údaje k administrátorskému účtu (root nebo Administrator), ● indikace stavu, v jakém se vServer právě nachází (viz kapitola 5.4.1), ● indikace stavu VNC serveru (zapnuto, vypnuto), adresa s portem, na kterém lze server skrze VNC klienta kontaktovat. Dále pak heslo pro autorizaci správce.
5.3.4
HardwareProfile
Mezi třídami HardwareProfile, VmInstance a Account existuje poměrně úzká vazba. V praxi se v aplikaci objeví vždy jen jedna instance této třídy, jejíž hodnoty odrážejí aktuálně aplikovaný uživatelský limit (currentLimit). Instance HardwareProfilu zastává ve fázi vytváření nového vServeru mimo jiné i roli jakési základní šablony předdefinovaných hodnot. Limity (viz kapitola 5.3.1) zahrnují širokou škálu prostředků pro omezování uživatele, ale hardwarové profily řeší vlastně jen ten kus limitů, který determinuje přípustné „technické“ parametry vServeru. Instance vServerů v sobě nesou informaci o hardwarovém profilu, podle kterého byly vytvořeny, a to zejména kvůli tomu, aby bylo možné určit hardwarový profil, na základě kterého je vServer možné následně rekonfigurovat. Atributy, z nichž je diskutovaný hardwarový profil fakticky tvořen, jsou ● minimum, maximum a výchozí hodnota počtu vCPU, ● minimum, maximum, výchozí hodnota a jednotka kapacity vRAM, ● minimum, maximum, výchozí hodnota a jednotka kapacity datových vDisků (označovaných též vStorage v případě, že vDisk není nositelem operačního systému). Zdroj dat pro naplnění obsahu nové instance této třídy je v BeeScale API dosažitelný pomocí relativní cesty /api/hardware_profiles.
Návrh aplikace
5.3.5
55
VmDisk
Třída VmDisk figuruje jako zobecnění objektu virtuálního disku. Virtuální disk v pojetí služby BeeScale může nabývat několika podob, jež jsou z hlediska atributů totožné, ale je zapotřebí je programově rozlišovat kvůli následnému zpracování, respektive jeho optimalizaci. Rozlišuje se podoba virtuálního disku připojeného k určitému virtuálnímu serveru (generický VmDisk), dále pak ● virtuální disk, který není v danou chvíli přiřazen k žádnému z virtuálních serverů uživatele – UnusedVmDisk, ● virtual appliance11 (označována také jako vAppliance) zapouzdřená v klonovatelném distribuovaném vDisku – VmPlatform. Každá podoba VmDisku má vlastní jednoznačný identifikátor (id). Podle něj lze determinovat, zdali se jedná o uživatelsky vytvořený virtuální disk, nebo o disk nesoucí virtual appliance (identifikátor obsahuje prefix „platform“). Identifikace vDisku na uživatelské úrovni je možná díky jeho jedinečnému názvu (name). Atribut description je nositelem popisné informace o obsahu vDisku a o jeho kapacitě. State slouží k rozpoznání aktuálního stavu vDisku, který může nabývat hodnot uvedených v diagramu na kapitole 5.4.2. Všechny zmíněné typy vDisků jsou dostupné v datové kolekci /api/images.
5.3.6
VmAction
VmAction je třída zastupující objekty asynchronních úloh, které lze v danou chvíli na dotyčném vServeru (VmInstance) provést, respektive odeslat pokyn k jejich provedení. Atribut name je relativním identifikátorem každé z úloh, přičemž prostým pohledem na jeho hodnotu lze zjistit, co daná úloha s vServerem provede. Volání jednotlivých úloh se provádí skrze jednoduché HTTP dotazy, jejichž cílem jsou jedinečné, BeeScalem vygenerované URI12 adresy (actionUri). Atribut method determinuje metodu HTTP dotazu, pomocí které se dotaz musí uskutečnit – POST, DELETE, PUT.
5.3.7
VmStatsRec
VmStatsRec je třídou pro tvorbu generických instancí datových záznamů o výkonových statistikách, nebo spíše jejich krátkodobých trendech. Podklady pro tvorbu statistických 11
Virtual appliance – předpřipravený virtuální stroj s přeinstalovaným operačním systémem a se sadou aplikací. 12 Uniform Resource Identifier – jednotný identifikátor objektu (souboru nebo služby) v rámci internetu.
Návrh aplikace
56
záznamů se nalézají v datové kolekci /api/stats. Skládá se z atributu s časovým razítkem (date) a příslušnou hodnotou (value) naměřenou v daný čas. V rámci aplikace BeeScale lze pozorovat statistiky pro ● procentuální vytížení vCPU přidělených sledovanému vServeru, ● průtok dat tekoucích skrz síťové rozhraní vServeru v kilobajtech za sekundu (kB/s nebo kBps), ● procentuální využití disponibilní kapacity (prozatím není v BeeScale implementováno).
5.3.8
vRAM
daného
vServeru
Tweet
Instance této třídy jsou nositeli zpráv ze zpravodajského kanálu služby BeeScale provozovaného prostřednictvím sociální sítě Twitter. Pro účely aplikace je relevantní pouze samotná krátká zpráva (postText), datum a čas (date) její publikace. Data pro plnění obsahu instancí třídy Tweet jsou získávána z Twitter API verze 1.0 pomocí URI https://api.twitter.com/1/statuses/user_timeline/beescale.json?count=1.
5.4
Diagramy stavů
V této kapitole popisuji životní cykly objektů tří tříd, které jsem uvedl a graficky znázornil v předchozí analytické kapitole. Důvod, proč se budu zabývat pouze třídami Account, VmInstance a VmDisk, je, že pouze objekty těchto tříd uvnitř systému během své existence mění svoje stavy. Objekty ostatních tříd nabývají pouze dvou stavů, a to existence nebo neexistence, proto v jejich popisu v rámci této kapitoly neshledávám žádnou přidanou hodnotu. Následující návrhové stavové diagramy popisují události, které vedou od počátku (v diagram označovaného jako Start) životního cyklu objektu až k jeho konci (označovaného jako End). Stavy objektů mohou být determinovány událostmi (usměrněné spojovací čáry mezi jednotlivými stavy) vyvolanými na straně administrátora služby, uživatele, anebo automatizovanými procesy služby. Každý ze stavů pojmenovávám v člověku srozumitelném jazyce. V hranatých závorkách pak uvádím transkripci do hodnot v podobě, v jaké je lze pozorovat ve výstupu z aplikačního programovacího rozhraní BeeScale API.
Návrh aplikace
5.4.1
57
VmInstance
Obrázek 18 – Diagram stavů pro třídu VmInstance (zdroj: autor)
Obrázek 18 je ilustrací životního cyklu jednotlivých uživatelských virtuálních serverů. Existence objektu třídy VmInstance vždy začíná na vstupu uživatele služby, čili sestavením sady parametrů nezbytných pro vytvoření nové instance serveru. Jakmile uživatel potvrdí parametry pro vytvoření nového vServeru, vytvoří se pod účtem uživatele deskriptor nové instance vServeru, která však v této fázi ještě fyzicky neexistuje. Jakmile uživatel inicializuje úlohu prvního spuštění nového vServeru, tak se na apiaristou automaticky přiřazeném hivu provede buď ● nasazení vAppliance, kterou si uživatel při zadávání parametrů pro tvorbu nového vServeru vybral, ● nebo vytvoření instance vServeru bez disku, který by byl nositelem operačního systému, tedy je osazen pouze diskem pro data, ● nebo vytvoření instance vServeru, který nemá absolutně žádné vDisky. Ve všech stavech, vyjma stavu havárie, lze instanci vServeru smazat. S vServerem ve stavu havárie nelze ze strany uživatele nic provádět, jelikož je vyžadována pozornost administrátora služby, který problém zaeviduje, opraví a podá o něm hlášení uživateli. Mimo stavu havárie a stavu probíhajících změn stavu nebo nastavení je také možné
Návrh aplikace
58
vServer kdykoliv rekonfigurovat – změnit jeho parametry podle jeho hardwarového profilu. Stavy typu pozastavený, zapnutý, vypnutý jsou průběžnými stavy, které reagují na úlohy iniciované uživatelem a netrpí žádnou zvláštností. Naproti tomu stav signalizující probíhající změny stavu nebo nastavení je speciálním stavem, který je v BeeScale API doprovázen ještě doplňujícími atributy, které specifikují druh úlohy a determinují fázi (krok) procesu, ve které se právě zpracovávaná úloha nachází. Procentuální „pokrok“ ve zpracování lze vypočítat podílem celkového počtu kroků úlohy a počtu již odbavených kroků, jež lze separátně získat z API. V případě, že se uživatel rozhodne vServer vyřadit (smazat) ze svého virtuálního datového centra, vyvolá úlohu pro jeho výmaz, načež se z domovského Hivu snaží informace o dané instanci. Virtuální disková úložiště, která byla doteď připojena k vServeru, se po jeho smazání uvolní (odpojí). Dokud uživatel vDisky dodatečně nesmaže, tak v rámci jeho uživatelského účtu stále existují a jsou i nadále zpoplatněny. Toto opatření vzniklo zejména kvůli nežádoucí ztrátě dat, která by neopatrným zacházením s aplikací mohla vzniknout. Takto pozůstalé vDisky mohou být znovu připojeny k jakémukoliv jinému vServeru.
5.4.2
VmDisk
Obrázek 19 – Diagram stavů pro třídu VmDisk (zdroj: autor)
Obrázek 19 popisuje postupné změny stavů, jež mohou u objektů třídy VmDisk a jejích potomků v jejich životním cyklu nastat. Způsoby, jak mohou objekty třídy VmDisk v rámci služby BeeScale vznikat, jsou tři. První z nich je vyvolán akcí administrátora aplikace, kdy je do portfolia existujících vAppliances přidána další – nová. Další dva způsoby jsou zachyceny v diagramu změnou stavu vytvoření vDisku, která je realizována buď vytvářením nového vServeru, kdy je dle požadavku uživatele
Návrh aplikace
59
vytvořen odpovídající počet vDisků, nebo je vDisk vytvořen v důsledku rekonfigurace vServeru uživatelem. Rekonfigurací vServeru můžeme vDisk nejen vytvořit, ale i připojit již existující odpojený vDisk, nebo připojený vDisk od vybraného vServeru odpojit, a následně jej třeba i podle potřeby smazat. Každá změna stavu, stejně jako u objektů třídy VmInstance, prochází mezistavem průběhu změny nastavení.
5.4.3
Account
Obrázek 20 vykresluje životní cyklus objektů třídy Account. Existence uživatelského účtu ve službě BeeScale začíná jeho registrací, kterou provádí uživatel samostatně pomocí zadání své emailové adresy (figuruje jako uživatelské jméno) a libovolně zvoleného hesla. Každý nově registrovaný uživatel získá účet s přednastaveným zkušebním limitem a časově neomezeným kreditem ve výši 100,- Kč (viz [29]).
Obrázek 20 – Diagram stavů pro třídu Account (zdroj: autor)
V případě, že apiarista pomocí cycleru zjistí, že na bankovní účet přibyla platba od účastníka se zkušebním limitem, je tomuto uživatelskému účtu automaticky přidělen limit platícího uživatele. Uživateli se zkušebním limitem se po vyčerpání předem nabitého kreditu automaticky nastaví limit nedostatečného krytí a jsou mu vypnuty jeho vServery a vDisky fyzicky smazány. Uživatel s limitem platícího je po vyčerpání svého kreditního konta nejdříve informován pomocí série varovných emailů o nízkém stavu kreditu. Pokud stav kreditu překročí deficit 100 jednotek, vServery jsou automaticky
Návrh aplikace
60
vypnuty a uživateli je nastaven limit nedostatečného krytí. Uživatel své vServery nemůže zapnout, nemůže je rekonfigurovat a ani vytvářet nové. V případě, že do 14 dní nedojde k úhradě deficitu kreditního konta, uživatel permanentně přichází o svá data fyzickým výmazem jeho vDisků. Po uhrazení pohledávky (dobití kreditu), se uživateli navrací zpět jeho předchozí limit. Uživatelským účtům mohou být administrátorem služby kdykoliv přiřazeny různé specifické limity, jež jsou vyhrazeny smluvním partnerům a speciálním zákazníkům. Stejně tak může administrátor účet uživatele i k němu přidružená data kdykoliv smazat. Uživatelský účet nemůže být zrušen jinak, nežli rukou administrátora.
5.5
Grafické uživatelské rozhraní
5.5.1
Navigační mapa
Obrázek 21 ilustruje návrh rozpadu funkcionality v návaznosti na navigaci napříč obrazovkami aplikace BeeScale Client. Zeleně jsou označeny obrazovky hlavního pohledu aplikace. Ověření dostupnosti
Registrace
Vytvoření vServeru
Konzole vzdálené správy
Moje serverovna
Detail vServeru
Akce
Nepřipojené vDisky
Rekonfigurace
Přihlášení
Výpis plateb Můj účet Dobití kreditu
Obrázek 21 – Návrh navigační mapy aplikace (zdroj: autor)
Statistiky vServeru
Návrh aplikace
5.5.2
61
Logika ovládání
Ovládání gesty (1.) Po přihlášení uživatele do aplikace se bude možné mezi obrazovkami s detailními informacemi o uživatelském účtu, výčtu vServerů v serverovně a detailu vServeru pohybovat pomocí intuitivních tahových gest. Táhnutí vpravo přesune pohled uživatele na obrazovku po pravé straně. Tahem vlevo se uživatel dostane na obrazovku po levici. S tímto souvisí i umístění obrazovek, které soustřeďuje informace o uživatelském účtu na levé straně, seznam serverů ve virtuálním datacentru uprostřed a po pravé straně se nachází detail vServeru. Navigační pás (2.) Kromě ovládání gesty bude dostupná doplňková navigace uvnitř hlavičky obrazovky, kde se nachází logo aplikace. Navigace uvnitř tohoto pásu je realizována pomocí tlačítek s piktogramem šipky, které jsou orientovány ve směru pohybu, který reprezentují.
Obrázek 22 – Koncept ovládání aplikace (Zdroj: autor)
Kontextové menu (3.) V místech, kde je dostupné kontextové menu, neboli v místech, kde mají být dostupné kontextuální funkce využitelné pro aktuální obrazovku, tam je k dispozici navigační tlačítko, nebo tlačítka pro jmenovitý přesun mezi obrazovkami. Tlačítko zpět (4.) Tlačítko slouží pro komfortní návrat na předešlou obrazovku. Pohyb směrem zpět primárně směřuje k obrazovce datacentra. Při stisku tlačítka zpět na obrazovce datacentra je uživatel dotázán, zdali se chce z aplikace odhlásit. V případě, že je dialog potvrzen, dojde k přesunu pohledu na obrazovku přihlášení. Následný stisk tlačítka zpět ukončí aplikaci.
Návrh aplikace
5.5.3
62
Koncepty obrazovek GUI
Každá z obrazovek bude obsahovat hlavičku, kde bude uveden název aplikace s logem a verzí. V místech, kde je možné se mezi obrazovkami napřímo navigovat (směrem vpravo nebo vlevo), jsou v hlavičce zobrazena příslušná navigační tlačítka. Pro zachování aplikačního kontextu je každá obrazovka opatřena textovým pásem nesoucím název aktuální obrazovky. Ručně zhotovené konceptuální návrhy jednotlivých obrazovek aplikace BeeScale Client uvádím v Příloze C. Mimo prvek hlavičky pak už každá obrazovka nese svůj vlastní obsah, který je zpravidla tvořen seznamy, textovými poli, tlačítky nebo záložkami v místě, kde je to pro rozlišení potřeba.
Realizace návrhu
63
6 Realizace návrhu Kapitola realizace návrhu mapuje moje principiální přístupy k řešení s tím, že zajímavé úseky zdrojového kódu uvádím pro demonstraci přímo v textu. Plné znění zdrojových kódů je pro svůj mimořádně velký rozsah umístěno v příloze. Zdrojové kódy v Příloze B jsou pro snazší pochopení opatřeny in-line komentáři. Následující text popisuje stav realizace projektu k fázi verze 1.4.
6.1
Prezentační vrstva
6.1.1
Lokalizace
V návrhové části projektu bylo deklarováno, že textové řetězce, které jsou prezentovány uživateli, jsou striktně separovány od logiky aplikace. Veškeré textové řetězce jsou tedy lokalizovány prostřednictvím souboru strings.xml, který se nachází v Příloze B.
6.1.2
Realizace obrazovek GUI
Výslednou podobu realizace obrazovek, jež vychází z předešlého konceptuálního návrhu uvedeného v Příloze C, uvádím z úsporných důvodů v Příloze D. Zdrojové kódy determinující rozložení (layout) grafických prvků každé z obrazovek jsou umístěny v Příloze B. Každý layout je tvořen XML šablonou, nebo je kompozicí více vnořených šablon. Výčet hlavních XML šablon užívaných pro konstrukci GUI aplikace tvoří: ● header – hlavička provázející uživatele po celou dobu práce s aplikací. Po přihlášení do aplikace zobrazuje navigační tlačítka. ● footer – patička, kde se nachází text copyrightu a odkaz na web služby BeeScale a web vydavatele aplikace. ● blank_layout – prázdný layout, který se zobrazuje v době, kdy probíhá příprava formuláře. Například, když se uživatel přihlašuje, tak po dobu získávání dat z BeeScale API je zobrazena prázdná plocha s oknem signalizujícím probíhající akci stahování dat. ● login – layout obrazovky přihlášení uživatele.
Realizace návrhu
64
● flip_box – layout hlavní obrazovky, tedy spíše kontejneru obrazovek, který umožňuje ovládání pomocí tahových gest. V danou chvíli je možno táhnout na ty strany, které jsou vysvíceny na navigačním pásu uvnitř hlavičky aplikace. Pozor však na situaci, kdy je obrazovka převrácena naležato (landscape), kdy z důvodu úspory místa v horní části displeje lišta s hlavičkou aplikace zmizí. o account – layout první pozice flip_boxu, který se stará o skladbu obrazovky s detailem uživatelského účtu.
account_payment – rozložení položky (řádku) seznamu provedených plateb na kreditní konto.
o main – layout na druhé pozici flip_boxu. Tato pozice je výchozí, protože po proceduře přihlášení je uživatel přesměrován právě sem.
server_info_item – kompozice položky seznamu serverů uvnitř uživatelova datacentra.
footer_vm_info_lv – rozložení zápatí obrazovky s výčtem vServerů uživatele.
empty_vm_info_lv – rozložení která signalizuje prázdné datacentrum.
vnořené
obrazovky,
o details – layout na třetí pozici flip_boxu. Layout je stejně jako flip_box dalším kontejnerem, tentokráte však zaobaluje záložky s obsahem vztahujícím se k vServeru, který byl kliknutím na seznam vServerů vybrán.
server_detail_actions – rozložení dostupných pro vybraný vServer.
záložky
(tabu)
akcí
server_detail_actions_item – layout položky jednotlivé akce.
server_detail_info – layout záložky výčtu detailních informací o vServeru.
server_detail_info_dialog – rozložení akčního dialogu pro kopírování textových řetězců nebo diagnózu pomocí příkazu ping.
server_detail_statistics – layout záložky statistik vServeru. Rozložení sestává z plochy pro vykreslování grafu a přepínače jednotlivých typů statistik.
● create_mod_vm – kompozice formuláře pro vytváření nového vServeru.
Realizace návrhu
65
o platform_spinner – rozložení položky výběrového menu pro výběr požadovaného operačního systému nového vServeru. ● unused_disks_dialog – rozložení obrazovky dialogu s výčtem nepřipojených disků. o unused_disk_item – layout položky odpojeného vDisku.
6.1.3
Ovládání
Aplikace je ovládána zejména pomocí tlačítek, které reagují na poklepání na displej zařízení. Po ověření uživatele na přihlašovací obrazovce je uživatel přesměrován na výchozí pohled na své virtuální datové centrum, kde mimo „proklikové“ ovládání přichází na řadu i gestikulární ovládání, které slouží k horizontální navigaci mezi informacemi o uživatelském účtu, detailem vServeru a zmiňovaným základním pohledem na datové centrum. Třída, která se stará o implementaci tohoto druhu navigace, se nazývá MyGestureDetector. MyGestureDetector Instance třídy MyGestureDetector se užívají jako rozšíření standardního listeneru události onTouchEvent, který je iniciován při každém dotyku uživatele na daném grafickém prvku vykresleném na obrazovce. MyGestureDetector detekuje namísto prostého dotyku displeje jen matematicky popsané tahy prstem determinující směr navigace vpřed nebo vzad. Jelikož neexistuje žádná překryvová vrstva, na níž by se gesta zaznamenávala, je třeba každému grafickému prvku obrazovky, jež má být tímto způsobem ovládána, nastavit toto rozšíření. Každá události onTouchEvent každého z grafických prvků musí být předána na vyhrazenou instanci třídy MyGestureDetector, a to níže popsaným způsobem. MyGestureDetector gestureDetector = new GestureDetector( new MyGestureDetector(flipper, this)); … @Override public boolean onTouchEvent(MotionEvent event) { if (gestureDetector != null) if (gestureDetector.onTouchEvent(event)) return true; else return false; else return super.onTouchEvent(event); }
Realizace návrhu
66
Každá událost vyvolaná dotykem, jež odpovídá tahu vpravo (vpřed) nebo vlevo (zpět), je považována za odbavenou, proto je navrácena hodnota true. V opačném případě je vrácena hodnota false, což zabezpečí, že je událost dále propagována k následnému zpracování (je-li potřeba). Před odbavením právě provedeného gesta je zkontrolováno, na které obrazovce se uživatel právě nachází, a podle toho je určeno, kam je možné pohled uživatele přesunout. V případě, že se uživatel nachází na některém z dvou krajních pohledů, tak gesto, jež by mělo jít za tuto mez, je zahozeno.
6.1.4
Vlastní grafické prvky
HoldableImageButton Třída HoldableImageButton vznikla za účelem doplnění portfolia existujících druhů tlačítek platformy Android. Mimo prosté tlačítko (třída Button) a obrázkové tlačítko (třída ImageButton) bylo potřeba vytvořit tlačítko, jež bude reflektovat dobu podržení dlouhého stisku (událost LongClick). Takovýto ovládací prvek vznikl za účelem komfortního inkrementu nebo dekrementu číselné hodnoty, aniž by bylo potřeba pro každé dílčí snížení/zvýšení hodnoty zvlášť poklepat prstem uživatele. Třída je rozšířeným potomkem třídy ImageButton, tedy sdílí všechny jeho vlastnosti, akorát s tím rozdílem, že při dlouhém stisku tohoto tlačítka je s 70ms zpožděním opětovně vyvolávána událost stisku tlačítka, tedy dochází k nepřetržité iteraci, dokud uživatel stisk neuvolní. Rychlost jednotlivých iterací postupně akceleruje, takže se prodleva iterace může postupně snížit až na 30 ms. NumberPickerView Třída vznikla v reakci na potřebu jemného zadávání číselných hodnot. Tento požadavek vyvstal z negativní zkušenosti několika uživatelů. Při vytváření nového vServeru při výběru hodnoty kapacity vRAM a dodatečného datového úložiště (vStorage), kde se operuje s tří až čtyřcifernými čísly, docházelo zejména na menších displejích k nežádoucím skokovým změnám hodnot. Z tohoto důvodu byl tradiční SeekBar (posuvník) doplněn o dvojici tlačítek (viz Obrázek 23), jež v případě potřeby poskytují možnost jemné jednotkové změny. Objekty třídy NumberPickerView využívají tlačítek typu HoldableImageButton.
Obrázek 23 – Snímek grafického objektu třídy NumberPickerView (zdroj: autor)
Realizace návrhu
6.2
Aplikační vrstva
6.2.1
Komunikace s datovou vrstvou
67
HttpHelper Statická třída pro komunikaci s aplikačními rozhraními založenými na dotazování prostřednictvím protokolu HTTP nebo jeho šifrované variantě HTTPS. HttpHelper poskytuje sadu metod, které jsou uzpůsobeny speciálně pro využití k dotazování BeeScale API a v současné době i Twitter API. Tyto metody jsou ● executeHttpPost – přetížená metoda, která umožňuje odesílat na BeeScale API parametrizované (obsahují datovou oblast s parametry) a neparametrizované dotazy typu HTTP POST, PUT, DETELE, ● executeHttpGet – metoda umožňuje dotazování BeeScale API pomocí metody HTTP GET, ● executeHttpGetNoAuth – slouží obdobně jako executeHttpGet k dotazování skrze http protokol, však s tím rozdílem, že realizovaný dotaz nevyžaduje ověření tazatele. Tuto metodu využívám například pro získávání tweetů z Twitter API. Metody executeHttpPost a excuteHttpGet obsahují mechanismus pro vytváření ověřovacího klíče potřebného k identifikaci uživatele služby BeeScale a následné autorizaci HTTP dotazu. Ve skutečnosti obě tyto metody volají metodu hashPass, která nad kombinací uživatelského hesla a jména vytvoří SHA-1 hash (viz kapitola 6.2.6, Sha1), který se následně využije při ověření u BeeScale jako heslo, přičemž jméno uživatele zůstává stejné. Použití v praxi ilustruje výňatek ze zdrojového kódu pod tímto odstavcem. ... client.getCredentialsProvider().setCredentials( new AuthScope(null, -1), new UsernamePasswordCredentials(username, hashPass(username, password))); ... private static String hashPass(String user, String pass) { String hashPass = Sha1.getHash(pass + user); return hashPass; }
Realizace návrhu
68
EventListenerList Převzatá13 instancovatelná třída pro tvorbu a následnou správu seznamů zaregistrovaných listenerů událostí. Listener si je možné představit na analogii vydavatele a předplatitele, kdy listener zastává roli předplatitele. V případě BeeScale Clienta zastává roli vydavatele GetRequestController. EventListenerList byl implementován za účelem vytvoření správce předplatitelů událostí GetRequestEvent, které jsou vyvolávány na straně GetRequestControlleru. GetRequestController Třída realizuje řadič zpětnovazebných událostí navržený speciálně pro třídu RequestResultDownloader. Tento řadič pomocí EventListenerListu udržuje seznam registrovaných listenerů, kteří chtějí přijímat události v návaznosti na realizaci HTTP požadavku skrze zmíněný RequestResultDownloader. Mimo metody pro zprostředkování správy seznamu registrovaných listenerů (addEventListener, removeEventListener, removeAllEventListeners a getListenersCount) třída obsahuje vnořený interface, jež dále v kódu umožňuje snadno diskutovaný listener implementovat. Tento listener bude po své registraci pomocí metody addGetCallbackListener třídy RequestResultDownloader naslouchat událostem GetRequestEvent. Každá instance této třídy v sobě udržuje vnitřní stav, který je reprezentován textovým výčtovým typem GetReqStats. Možnými stavy jsou 4. REQ_READY – řadič je připraven, 5. REQ_STARTED – proces asynchronního dotazování byl odstartován, 6. REQ_FINISHED – proces dotazování byl dokončen (ať už s výjimkou nebo bez), 7. REQ_CANCELED – proces dotazování byl ukončen na pokyn uživatele. Tento vnitřní stav reflektuje fázi zpracování RequestResultDownloaderu, k němuž je jako řadič událostí připojen. Pomocí metody dispatchEvent, na jejímž vstupu je instance události typu GetRequestEvent, je všem registrovaným listenerům tato událost odeslána k následnému zpracování. GetRequestEvent Je rozšířením třídy EventObject. GetRequestEvent slouží k vytváření instancí asynchronních zpětnovazebných zpráv (callbacků), jež jsou nositeli datového obsahu, výjimek a jiných stavových informací, které vznikají v reakci na zpracování HTTP požadavků uvnitř instancí třídy RequestResultDownloader. 13
Metody pro přístup k datům zapouzdřeným uvnitř instancí GetRequestEventu jsou ● getLastResultCode – získává stavový kód reakce na HTTP požadavek. ● getData – získává obsah datové oblasti odpovědi na HTTP požadavek, ● getException – získává instanci zachycené výjimky, v případě, že se nějaká vyskytla v průběhu komunikace se serverem nebo při zpracování samotného požadavku. ● getStatus – získává aktuální fázi zpracování požadavku. Typem návratové hodnoty je výčtový typ GetReqStats umístěný uvnitř řadiče callbacků GetRequestController. MyRequestException Třída vznikla z nutnosti odlišit vlastní případy programových výjimek od výjimek generických. Instance této třídy užívám zejména pro přenos stavových kódů HTTP protokolu, které označují nějakou chybu. Jedná se o stavy série 4xx a 5xx, jejichž jednotlivé možné varianty uvádím níže jako výňatek ze sekce konstant uvedených ve zdrojovém kódu třídy Utils. private static final int RCODE_BAD_REQUEST = 400; public static final int RCODE_UNAUTHORISED = 401; private static final int RCODE_FORBIDDEN = 403; public static final int RCODE_NOT_FOUND = 404; private static final int RCODE_METHOD_NOT_ALLOWED = 405; private static final int RCODE_CONFLICT = 409; public static final int RCODE_LOCKED= 423; private static final int RCODE_TOO_MANY_REQUESTS = 429; private static final int RCODE_INTERNAL_SERVER_ERROR = 500; private static final int RCODE_NOT_IMPLEMENTED = 501; MyRequestException je rozšířením třídy Exception, která je předkem všech výjimek v programovacím jazyce Java. RequestResultDownloader Jedná se rozšíření třídy AsyncTask, která řeší problematiku zpracování asynchronních úloh na pozadí, tedy mimo hlavní aplikační vlákno, které řídí grafické uživatelské rozhraní. Předek RequestResultDownloaderu je rozšířen o řadič událostí GetRequestController, který má na starosti správu listenerů, kteří jsou zaregistrováni pro odběr zpětnovazebných zpráv v reakci fázi zpracování asynchronní úlohy.
Realizace návrhu
70
Obecná třída AsyncTask implementuje metody ● onPreExecute – volána před začátkem zpracování, ● onPostExecute – volána po dokončení zpracování, ● onCancelled – volána v případě přerušení zpracování následkem zavolání metody cancel, ● doInBackground – volá se při zahájení zpracování úlohy (iniciováno metodou execute). Předmět zpracování se umísťuje právě do této metody. Rozšíření RequestResultDownloaderu spočívá v tom, že zpětnovazebné metody onPreExecute, onPostExecute a onCancelled propagují prostřednictvím předem připravené instance GetRequestControlleru stav zpracování asynchronní úlohy registrovaným listenerům. Metoda doInBackgroud podle parametrů předaných instancí RequestResultDownloaderParams na vstupu provede dávku dotazů prostřednictvím příslušných akčních metod (executeHttpPost, executeHttpGet, …) třídy HttpHelper, jež slouží k dotazování BeeScale API nebo Twitter API. Díky tomu není interakce uživatele s aplikací blokující. RequestResultDownloaderParams Třída slouží jako „přepravka“ parametrů, které slouží jako podklad k vykonávání asynchronních úloh RequestResultDownloaderem. Instance této třídy obvykle nesou ověřovací údaje (login a heslo), URI adresu dotazu a HTTP metodu, která se má při dotazování příslušného cílového API použít.
6.2.2
Hlavní třídy
Třídy nosných objektů aplikace, které byly v kapitole 5.3 z konceptuálního hlediska analyzovány, jsou v této kapitole rozebrány na úrovni implementačního detailu. Třídy Payment, HardwareProfile, VmInstance, VmDisk a VmStatsRec mají více, či méně analogickou strukturu. Specifika každé ze jmenovaných tříd potom uvádím v dotyčných podkapitolách níže. Generický obsah diskutovaných tříd se skládá ze dvou částí, jež jsou: ● Mateřská třída reprezentující konstrukci dané třídy objektů, která obsahuje sadu veřejných metod pro získávání potřebných hodnot ve formátované podobě. U třídy Payment je to například getAmount, getProvider a getDate. Pro třídu VmStatsRec jsou to getTime a getValue. Ostatní třídy nabízejí analogicky pojmenované metody v návaznosti na název atributu, jež mají za úkol z třídy získat.
Realizace návrhu
71
● Veřejná vnořená statická třída, která zaobaluje kolekci objektů mateřské třídy. Název podtřídy je odvozen z množného čísla mateřské třídy – například Payments, HardwareProfiles, VmInstances, VmDisks a VmStatistics, jež se konvenci trochu vymyká. Tato statická třída pak obsahuje rozhraní, díky kterému je možné s jednotlivými objekty kolekce manipulovat. Jednotlivé generické funkce jsou zastoupeny příslušnými metodami. Jedná se například o o funkci vytvoření nového prvku kolekce – metoda createNewInstance (vytvoří novou instanci dané mateřské třídy a zařadí ji do kolekce objektů), o funkci naplnění kolekce – metoda s prefixem fill (fillVmStatistics, fillVmInstances, atp.) vygeneruje jednotlivé prvky kolekce na základě textového řetězce (XML zprávy), který byl získán z BeeScale API, o funkci výmazu kolekce – metoda s prefixem (clearListOfVmInstances, clearListOfVmStatistics, …),
clearListOf
o funkci pro získání obsahu kolekce – metoda s prefixem get (getPayments, getVmInstances, getVmDisks, …). Twitter Je instancovatelná třída, která implementuje klientskou stranu rozhraní Twitter API. Toto aplikační programovací rozhraní je na separátním vlákně dotazováno parametrizovatelnou instancí třídy DataDownloader, která stáhne výsledek dotazu ve formátu JSON, jež je nadále potřeba zpracovat. Zpracování těchto dat se děje pomocí metody getTweetsFromRawData, která ze získaného surového textového řetězce vyprodukuje seznam strukturovaných zpráv („tvítů“) s časovým razítkem. Tyto objekty jsou reprezentovány třídou Tweet. Account Instance této třídy je za běhu aplikace pouze jedna, protože v jednom okamžiku může být přihlášen právě jeden uživatel. Konstruktor třídy má za úkol přímé vytvoření nové instance uživatelského účtu na základě dat z XML řetězce získaného přímo z BeeScale API. Umístění výše popsané logiky je oproti třídám jmenovaných v úvodu nadřazené kapitoly rozdílné. U nich se uvedená procedura nachází uvnitř vnořené statické třídy udržující kolekci instancí dané nadřazené třídy pomocí metody s prefixem fill, konstruktory jmenovaných tříd tuto transformaci neprovádějí. Obsah zdrojového kódu pro transformaci vstupu je v konstruktoru třídy Account principiálně totožný se všemi fill metodami.
Realizace návrhu
72
Metoda konstruktoru nejdříve za pomoci třídy XmlDom (viz XmlDom v kapitole 6.2.6) vytvoří objekt, který v logické stromové struktuře reprezentuje data obsažená v XML zprávě získané z BeeScale API. Metody obsažené v XmlDomu potom slouží k získávání potřebných dat ze struktur XML dokumentu. U třídy Account se jedná o informace o ● aktuálním stavu uživatelského konta a spotřeby prostředků, ● aktuálním a běžném limitu uživatele, ● základních iniciálách uživatele (jméno, email). Mimo uvedené je zde dostupná i metoda pro získání URI adresy označující zdroj, kde je možné stáhnout datovou kolekci plateb uživatele (v aplikaci zastoupenou třídou Payments). Payment Třída je svým obsahem ryze generická, žádnou výraznou zvláštností nevyniká. Pro zajímavost níže uvádím způsob formátování částky, jež byla uhrazena na vrub kreditního konta uživatele služby. public String getAmount(Context ctx) { BigDecimal bd = new BigDecimal(this.amount); bd = bd.setScale(2, BigDecimal.ROUND_HALF_UP); DecimalFormat formatter = (DecimalFormat)NumberFormat .getInstance(new Locale("cs_CS"));; DecimalFormatSymbols symbols = formatter.getDecimalFormatSymbols(); symbols.setGroupingSeparator(' '); formatter.setMinimumFractionDigits(2); return formatter.format(bd.doubleValue()) + " " + ctx.getString(R.string.envCurrency); } Nejdříve je nutné částku (this.amount) typu double převést na typ desetinného čísla o dvou desetinných místech se zaokrouhlením přebytečných desetinných míst směrem nahoru. Následně se číslo naformátuje do standardního číselného formátu pro vyjádření částky v tuzemské měně. Převod se učiní tak, že se určí čárka jako desetinný rozdělovač (namísto výchozí americké tečky), přidá se mezera jako rozdělovač pro čtyřciferná čísla (například 1 123, 00 Kč) a zkratka měny, v níž je kredit na účtu veden.
Realizace návrhu
73
HardwareProfile Třída hardwarového profilu je třídě Account velice podobná. U většiny uživatelů bude v aplikaci přítomna jen jedna instance této třídy. Avšak v případě, kdy uživatel v průběhu svého životního cyklu vytvoří vServer, podle tehdy aktuálního profilu plynoucího z tehdy nastaveného uživatelského limitu, a jež je posléze převeden například na některý ze speciálních partnerských limitů, dochází stejně tak ke změně hardwarového profilu. Aby bylo možné v budoucnu vServer rekonfigurovat, musí být v aplikaci dostupná instance jak současného, tak daného historického hardwarového profilu. Výše uvedený důvod mě vedl k použití konstrukce třídy, jak ji popisuji v úvodu nadřazené kapitoly. Žádné další strukturální disproporce třída nemá. VmDisk Třída VmDisk obsahuje mimo standardní sadu „getovacích“ metod i jednu metodu pro nastavování současného stavu disku. Například pro případ, kdy uživatel zadá pokyn k jeho smazání, které je v aplikaci realizováno metodou deleteDsk. V tomto případě je potřeba vDisk uzamknout pro změny po dobu odesílání HTTP požadavku na BeeScale API. Činí se tak přepnutím disku do stavu pending. Statická třída VmDisks obhospodařuje datové kolekce vDisků různých druhů. Při plnění obsahu datových kolekcí metodou fillVmDisks je rozlišováno, zdali se jedná o vDisk, který je aktuálně připojen k nějakému vServeru, nebo se jedná o disk bez příslušnosti k vServeru, anebo vDisk slouží jako virtuální appliance, která se při vytváření nového vServeru použije jako šablona s přeinstalovaným operačním systémem. Jednotlivé kolekce jsou výmluvně pojmenovány jako listOfVmPlatforms, listOfUnusedDisks a listOfVmDisks. Nástavbovou metodou nad kolekcí připojených vDisků (listOfVmDisks) je vyhledávání konkrétní instance vDisku uvnitř kolekce na základě jeho jednoznačného identifikátoru, pod kterým je interně v rámci aplikace BeeScale veden. Tuto funkci plní metoda findVmDiskById. Metoda je využívána pro determinaci příslušnosti vDisku k určitému vServeru. Instance třídy VmInstance totiž udržují pouze zmíněné jednoznačné ID. VmStatsRec Již v konceptuálním návrhu bylo odhaleno, že VmStatsRec bude třídou, která bude generickou třídou pro dostupná statistická data o vServerech. Rozlišujeme vytížení vCPU, čerpání šířky pásma síťového připojení. Monitorování spotřeby vRAM není v BeeScale API dosud implementováno, avšak v aplikaci BeeScale Client se s eventuelní implementací dopředu počítá – příslušný zdrojový kód je zakomentovaný (není aktivní).
Realizace návrhu
74
Každá z uvedených typových variant statistik využívá této třídy, jejíž instance přechovávají pouze časové razítko záznamu a aktuální naměřenou hodnotu daného ukazatele. O rozřazení jednotlivých naměřených hodnot podle typu ukazatele rozhoduje vnořená statická třída VmStatistics. Děje se tak pomocí metody fillVmStatistics, kde je na vstupu XML řetězec získaný z BeeScale API. Po naplnění statistických kolekcí (listOfVmStatisticsCpu a listOfVmStatisticsNet) je možné ze třídy VmStatistics pomocí zavolání metody getVmStatisticsDataset získat instanci třídy XYMultipleSeriesDataset, která slouží jako podklad pro vykreslení grafu pomocí převzaté knihovny achartengine-1.0.0.0.jar14. VmInstance Nejdůležitější třídou celé aplikace je právě VmInstance, jejíž instance jsou shromažďovány uvnitř vnořené třídy VmInstances uvnitř kolekce listOfVmInstances. Mimo vnořenou sběrnou třídu VmInstances obsahuje VmInstancei další dílčí třídy, kterými jsou: ● VmAction – je předmětem kolekce dostupných operativních akcí (actions) na dotyčné instanci vServeru, jejichž spuštění je zprostředkováno zavoláním metody doAction. Metoda doAction odešle na BeeScale API HTTP dotaz v jím předepsané struktuře, přičemž následně dojde na dotyčném vServeru k vyvolání požadované úlohy. ● VmDetail – slouží jako přepravka unifikovaných detailních informací o vServeru, které jsou následně použity na vstupu datového adaptéru VmInstanceDetailsAdapter, který má za úkol přenést poskytnutou kolekci do podoby zobrazitelné uživateli pomocí příslušného ListView. Instance těchto detailních informací jsou shromažďovány uvnitř kolekce details každé VmInstance. Mimo jednu dílčí informaci o vServeru může instance VmDetailu nést i URL adresu, řetězce připravené ke zkopírování do schránky a diagnostická data. Jestli je obsah těchto atributů naplněn v závislosti na tom, jestli má mít položka seznamu s touto informací zobrazovaná uživateli nějaké dílčí kontextové funkce. Tyto kontextové funkce jsou dostupné po kliknutí na položku seznamu prostřednictvím dialogu VmInstanceDetailInfoDialog. ● VncContainer – její instance slouží jako přepravky aktuálního stavu VNC serveru, přístupového hesla, IP adresy a portu, na nichž je VNC dostupné.
14
http://code.google.com/p/achartengine/
Realizace návrhu
75
Obsah kolekce vServerů je plněn uvnitř třídy VmInstances pomocí metody fillVmInstances. Uvnitř této metody je každá dílčí informace o vServeru uvedená v XML dokumentu na vstupu zpracována pomocí metody, která umí hodnotu dotyčného atributu správně „vypreparovat“. Takto získané hodnoty jsou následně zaneseny do atributů nové instantance VmInstance. Těchto metod je celkem 8. Mezi ně dle pořadí zpracování uvnitř fillVmInstances patří 1. getVmStateDetail – aktuální stav vServer, 2. getVmCpuDetail – počet disponibilních virtuálních výpočetních jader, 3. getVmRamDetail – disponibilní kapacita virtuální operační paměti, 4. getVmDisksDetail – seznam připojených virtuálních úložišť, 5. getIpAddressDetail – seznam přidělených IP adres, 6. getVmAuthDetail – přihlašovací údaje účtu administrátora předinstalovaného operačního systému, 7. getVmVncDetail – informace o stavu VNC serveru, 8. getVmActionsArray – seznam disponibilních akcí, jež lze na konkrétním vServeru provést. Každé z těchto tříd je na vstupu předána instance seznamu VmDetailů (details), takže při každém dílčím zpracování atributu vServeru, je přidán i jeden tento VmDetail s příslušnými hodnotami a kontextuálním příslušenstvím. Při získávání seznamu připojených vDisků (VmDisků) je prováděna optimalizace datových toků. Tato optimalizace se provádí ověřením výskytu identifikátorů virtuálních disků připojených k danému vServeru v datové kolekci VmDisks. Pokud požadované ID není v kolekci nalezeno, tak je obsah třídy VmDisks aktualizován na základě nově získaných dat z BeeScale API. Část zdrojového kódu metody fillVmInstances, která tuto problematiku řeší, ilustruji níže.
Aktivity (angl. Activity) jsou podle [37 s. 35] jedním ze základních stavebních kamenů aplikací vyvíjených pro operační systém Android. Mají za úkol řídit chod dílčích částí aplikace, zachytávat a reagovat na události operačního systému a vykreslovat objekty grafického uživatelského rozhraní na obrazovku zařízení. V ideálním případě je každá obrazovka GUI produktem jedné aktivity. V aplikaci BeeScale Client tomu tak není. V aplikaci BeeScale Client se vyskytuje celá řada aktivit. Mezi ně patří ● LoginActivity – řeší obrazovku s logikou formuláře pro přihlášení uživatele do aplikace, ● MainActivity – obsluhuje hlavní obrazovku aplikace a řídí hlavní logiku aplikace včetně asynchronního obnovování datových kolekcí z BeeScale API, ● CreateVmActivity – má na starosti konstrukci formuláře pro tvorbu nového vServeru a jeho logiku, ● TabServerDetailStatisticsActivity – obrazovka záložky statistik uvnitř detailu vybraného vServeru,
Realizace návrhu
77
● TabServerDetailInfoActivity – obrazovka záložky detailních informací o vybraném vServeru, ● TabServerDetailActionsActivity – obrazovka záložky akcí uvnitř detailu vServeru. Posloupnost průchodu jednotlivými aktivitami z hlediska ovládání aplikace uživatelem ilustruje Obrázek 24.
CreateVmActivity
TabServerDetailStatisticsActivity
LoginActivity
MainActivity TabServerDetailInfoActivity
TabServerDetailActionsActivity
Obrázek 24 – Posloupnost aktivit aplikace (zdroj: autor)
Pro širší výklad problematiky aktivit a dalších stavebních kamenů aplikací platformy Android je vhodné použít diplomovou práci Ing. Jana Šestáka (viz [37]), která problematiku vývoje do elementární úrovně mapuje.
6.2.4
Vlastní dialogy
V místech, kde není bezprostředně nutné vytvářet novou aktivitu (třída Activity), proto aby bylo možné zobrazit nové okno aplikace, je možné využít customizovaného dialogového okna odvozeného rozšířením (extension) obecné třídy Dialog. Pozitivní vedlejší efekt pro uživatele aplikace je, že dialogové okno překrývá obrazovku své rodičovské aktivity jen částečně, a proto vytváří dojem kontextu. Zprvu jsem zamýšlel využít vlastního rozšíření třídy ContextMenu a vytvořit tak kontextová akční menu nativním způsobem, jenže toto řešení nesplnilo očekávání. Důvodem, proč jsem se nevydal touto cestou je, že při větvení kontextuálního menu dochází k nežádoucímu „problikávání“ obrazovky na pozadí, což nepůsobí esteticky. Nehledě na to, že Dialog je z hlediska implementace přehlednější.
Realizace návrhu
78
VmInstanceDetailInfoDialog Tento dialog (ukázka – viz Obrázek 25) slouží jako kontextuální akční nabídka, jež je zobrazena po výběru prvku ze seznamu detailních informací (vmListDetails) v před tím zvoleném vServeru ze seznamu (vmListInfo) na obrazovce serverovny. Dialog je dostupný pouze u těch položek seznamu, jež mají po své pravé straně ikonu příznaku diagnostiky nebo možnosti kopírování. Výchozím grafickým layoutem dialogu je šablona server_detail_info_dialog.xml, která obsahuje pouze kontejner, jež je dle vstupních dat naplněn příslušnými akčními tlačítky.
Vstupní data mají dvě rozdílné kategorie, a to ● copyData – pole řetězců, které si může uživatel následně uložit do schránky, ● diagData – pole řetězců IP adres, které je možné diagnostikovat (ověřit jejich dostupnost pomocí příkazu PING). UnusedVmDisksDialog Dialog (ukázka – viz Obrázek 26) nepřipojených vDisků vznikl za účelem správy těchto objektů. V budoucnu by mělo být možné odpojené vDisky prostřednictvím tohoto dialogu opětovně připojovat k vServerům. V současném stavu však tento dialog plní pouze přehledovou funkci s možností mazání. Možností opětovného připojení disku (rekonfigurací vServeru) BeeScale API není dosud vybaveno. Výchozím grafickým layoutem je šablona unused_disks_dialog.xml, která v sobě nese seznam (dskLv), jež je pomocí datového Obrázek 26 – Snímek UnusedVmDisksDialogu (Zdroj: autor) adaptéru UnusedVmDisksAdapter naplněn daty. Každý datový prvek seznamu je vykreslován podle šablony unused_disk_item.xml.
Realizace návrhu
6.2.5
79
Datové adaptéry
Datové adaptéry zastávají v aplikaci roli prostředníka věcného obsahu uvnitř datových kolekcí s výčtovými prvky grafického uživatelského rozhraní. V případě BeeScale Clienta se jedná převážně o adaptéry pro poskytování dat programově strukturovaným seznamům, jež jsou zastoupeny třídou ListView. Většina datových adaptérů vychází ze třídy ArrayAdapter, který slouží k projekci elementárních dat do seznamu. Tyto prosté adaptéry jsou rozšířeny o logiku, díky které je možné v jednom prvku seznamu uvést komplexní informaci. Adaptéry, které jsou založeny na ArrayAdapteru obsahují totožnou strukturu – konstruktor, metoda getView, metoda refill a přepravku, jejíž název končí sufixem Holder (například VmInstanceInfoHolder). Toto neplatí pro adaptér UnusedVmDisksAdapter, který je navíc rozšířen o logiku pro volání BeeScale API kvůli výmazu vybraného vDisku, jež je řešeno jako asynchronní úloha – rozšíření generického AsyncTask. Vnořené speciální třídy Holder slouží jako uchovatelé referencí objektů GUI (TextView, Button, ImageButton, …) vyskytujících se na určitém řádku seznamu (ListView). Příklad uvádí Obrázek 27.
Metoda getView slouží k mapovaní dat získaných z elementu diskové kolekce na grafické elementy řádku daného ListView. Popřípadě provádí drobné korekce obsahu před samotným vykreslením. Účel metody refill je ten, že její vyvolání vynutí překreslení seznamu v případě změny prvku připojené kolekce. Speciálním případem adaptéru je VmPlatformsAdapter, který je rozšířením třídy BaseAdapter a implementuje SpinnerAdapter. Tato kombinace umožní následné použití adaptéru jako zdroje pro Spinner, což není nic jiného než obdoba ComboBoxu v terminologii vývojáře na platformě Microsoft. Pro laika je to jednoduše výběrové menu. Struktura adaptéru je velice podobná ostatním adaptérům vyskytujících se v projektu.
Realizace návrhu
80
Každý z datových adaptérů má svoje využití, které budu níže jmenovat: ● VmInstanceInfoAdapter – zdroj dat pro výčet vServerů v serverovně uživatele, ● VmInstanceActionsAdapter – zdroj dat pro výčet možných akcí, jež lze provést na detailu vybraného vServeru, ● VmInstanceDetailsAdapter – zdroj dat pro výčet detailních informací o vybraném vServeru, ● UnusedVmDisksAdapter – zdroj dat pro dialog s výčtem nepřipojených vDisků uživatele, ● PaymentsAdapter – zdroj dat pro výčet plateb za dobití kreditu uživatele, ● VmPlatformsAdapter – zdroj dat pro výběrové menu s nabízenými operačními systémy na formuláři pro vytvoření nového vServeru.
6.2.6
Pomocné třídy
XmlDom Speciální pomocná statická třída pro transformaci surových XML zpráv z BeeScale API do podoby objektu, ze kterého lze následně pomocí přiložených metod získávat data v něm obsažená. Metoda getDomElement nejdříve převede textový řetězec na vstupu pomocí parseru15 (třída DocumentBuilder) do strukturovaného Document Object Modelu (zkráceně DOM16), který je v Javě zastoupen třídou Document. DOM pak slouží jako jednoduché rozhraní pro manipulaci s touto hierarchicky uspořádanou množinou dat. Díky rozhraní DOMu je možné z požadovaných uzlů stromu vybrat jen ty hodnoty a atributy, které programátor potřebuje získat pro chod své aplikace. XmlDom mimo getDomElement disponuje metodami pro čtení hodnot ● getValue – získává hodnotu prvního elementu uvnitř uzlu na vstupu, ● getElementValue – získává hodnotu konkrétního elementu na vstupu, ● getAttributeValue – získává hodnotu atributu elementu na vstupu.
15
16
Parser – program pro konstrukci datového modelu dokumentu a validaci syntaktické správnosti vstupu (viz [20]). DOM – jedno z možných rozhraní pro manipulaci s XML dokumenty (viz [20]). DOM je charakteristický svou hierarchickou stromovou architekturou, kdy je každý z elementů XML dokumentu zastupován jedním uzlem stromu.
Realizace návrhu
81
Důležitou součástí třídy je sada textových konstant, které identifikují jednotlivé klíčové uzly a jejich atributy Document Object Modelu kolekcí BeeScale API, které jsou pro správnou funkci aplikace nezbytné. Sha1 Převzatá17 statická třída pro vytváření Secure Hash Algorithm (SHA-1), jehož standard je popsán v publikaci [5 s. 3]. Takto vzniklý hash, čili unikátní kondenzovaná interpretace libovolné sekvence znaků, slouží v aplikaci BeeScale Client jako prostředek pro vygenerování speciálního přístupového klíče, jež je porovnáván s přístupovým klíčem uživatele na straně BeeScale API. Pokud jsou klíče totožné, uživateli je do API udělen přístup. Typickou vlastností SHA hashů je, že jsou pouze jednocestné, to znamená, že nehrozí možnost, že by se z nich dal zpětně získat obsah, na základě kterého hashe vznikly. Reference Třída Reference (odvozena z příkladu uvedeného na webu [8]) odbourává nemožnost předávání referencí na instance primitivních datových typů (String, Boolean, Integer) při volání metod v prostředí programovacího jazyka Java. Tento programovací jazyk se ke zmíněným datovým typům zachová vždy tak, že předává parametry metod v režimu tzv. „By value“, což znamená, že uvnitř volané metody se pracuje pouze s lokálními kopiemi těchto hodnot, nikoliv s referencemi. Proto v případě, kdy je potřeba předávanou hodnotu v kódu metody modifikovat, změna se k původci hodnoty nedostane. Takovéto změny je možné provádět pouze v režimu předávání parametrů tzv. „By reference“ (umožňuje například jazyk C#), kdy je metodě předána reference instance objektu, jež zaobaluje potřebný primitivní datový typ, a díky tomu je modifikace umožněna zprostředkovaně. Tento wrapper (zaobalující třídu) využívám například v třídě Settings, jejíž kód jsem chtěl izolovat od návaznosti na ostatní třídy. Příklad užití je možné nalézt ve výňatku kódu ze třídy LoginActivity.
private void loadSettings() { Reference<String> user = new Reference<String>(GVarHolder.userName); Reference<String> pass = new Reference<String>(GVarHolder.password); Reference refTim = new Reference(GVarHolder .refreshTime); Reference aLogin = new Reference(GVarHolder.autoLogin); GVarHolder.settingsObj.loadSettings(this, user, pass, refTim, aLogin); GVarHolder.userName = user.get(); GVarHolder.password = pass.get(); GVarHolder.refreshTime = refTim.get(); GVarHolder.autoLogin = aLogin.get(); }
Settings Je třídou sloužící pro načítání a ukládání dat uživatelské konfigurace, která se nachází v izolovaném úložišti aplikace v souboru s názvem settings.dat. Obsah konfiguračního souboru je tvořen sadou řádkově orientovaných záznamů, jež se skládají z páru řetězců – deskriptoru parametru a jemu přiřazené hodnoty. Pár řetězců je rozdělen sekvencí znaků „;!param:“. Momentálně aplikace udržuje 4 konfigurační parametry: uživatelské jméno, heslo (pokud má být uchováno), vypnutí/zapnutí automatického přihlášení a interval automatické aktualizace dat na pozadí. Bezpečnost souboru konfigurace, která nese citlivá data v podobě uživatelských přihlašovacích údajů, je obstarávána při jeho zápisu pomocí přepínače Context.MODE_PRIVATE, který dle [14] povoluje následné čtení nebo zápis pouze té aplikaci, z jehož iniciativy soubor vznikl. Podle [16] získává každá aplikace při své instalaci vlastní přístupový identifikátor (tzv. User ID), takže ve výsledku má každá aplikace svůj vlastní uživatelský účet, pod kterým je spouštěn samotný aplikační proces a pod nímž je možné manipulovat se soubory aplikace. Tyto soubory jsou z jiných aplikací nedostupné. GVarHolder Slouží jako statické úložiště globálních proměnných a základních globálních aplikačních konstant. Globální konstanty jsou v tomto případě URI adresy jednotlivých datových kolekcí služby. Globální proměnné umožňují snadné sdílení základních stavových hodnot aplikace napříč objekty tvořícími její aktuální obsah.
Realizace návrhu
83
Utils Poslední z řady pomocných tříd, jež poskytuje sadu statických metod, které slouží zejména k účelům transkripce textových řetězců získaných z datové a aplikační vrstvy na lokalizované řetězce, které jsou čitelné a srozumitelné uživatelem aplikace. Zdrojem lokalizovaných textových řetězců je soubor strings.xml. Mimo řetězcové lokalizační funkce třída obsahuje funkci pro převod reálných obrazovkových bodů na relativní počet obrazovkových bodů, které vyplývají z aktuálně nastavené systémové hustoty (density) zobrazení. Díky této funkci je umožněno aplikaci zachovávat grafickým prvkům stejné proporce na malých i velkých displejích, aniž by docházelo k přesahu uživatelem viditelné zobrazovací plochy a jiným deformacím. Metodu zajišťující tento převod ilustruje následující příklad. public static float getRelativePixels(Context ctx, float px) { return ctx.getResources().getDisplayMetrics().scaledDensity * px; } Dále je zde řešeno centralizované vyvolávání notifikačních hlášení a dialogů pro zobrazení probíhající operace, například úvodní synchronní (blokující uživatelskou interakci) načtení dat z datové vrstvy (BeeScale API).
Vyhodnocení dosažených výsledků
84
7 Vyhodnocení dosažených výsledků 7.1
Metodiky pro tvorbu GUI
Díky tomu, že studie metodik pro tvorbu GUI vznikala v době, kdy již část aplikace existovala, byla pravděpodobně o to výstižnější, protože jsem již věděl, že jsem pár začátečnických chyb v průběhu návrhu a implementace uživatelského rozhraní udělal. Ty se mi však více či méně podařilo napravit. Musím poznamenat, že problematika rozdílnosti parametrů mobilních zařízení není zas takový problém, protože jsem veškerou bitmapovou grafiku vytvořil pouze v jednou rozměru, a to v HDPI (viz Obrázek 14), bez jakýchkoliv dodatečných úprav. Obrazové body se mi bez sebemenších problémů na rozličných zařízeních dopočítávají. Přičítám to však tomu, že se jedná většinou o jednoduchou grafiku. V případě například fotografie by deformace byla velmi pravděpodobně znát. S ostatními tipy se nemohu jinak než plně ztotožnit. Zejména prototypování na papír je pro začátek dobrý postup, protože se není třeba zdržovat prací se softwarem, se kterým třeba ani člověk zabývající se vývojem neumí efektivně pracovat.
7.2
Vyhodnocení projektu
Projekt vývoje aplikace BeeScale Client již od prvopočátku provázely jisté začátečnické potíže, které plynuly z neúplného pochopení základních principů vývoje aplikací pro platformu Android. Po dokončení návrhové fáze jsem se chtěl co nejdříve dát do programování. Při programování sady požadavků z první vývojové fáze jsem však narazil na některé nelogičnosti a překážky, které mě, jako programátora, který vyvíjí primárně v jazyku C#, zarážely. Například mechanismus události aktivit mi přišel možná až zbytečně složitý, přičemž sám Google ve své dokumentaci přiznává, že ne vždy se lze na řízení aplikace událostmi spolehnout. Dále mi vadí postup získávání referencí na instance objektů zobrazených na GUI pomocí metody findViewById, kdy je nezbytné manuálně generovat obrovské množství kódu, který je pouze režijní a nemá prakticky žádný funkcionální přínos. Obávám se však, že vysoká režie zdrojového kódu je obecným problémem programování v Javě, tedy alespoň podle mých zkušeností. Kapitolou samu pro sebe byl návrh GUI, které musí respektovat aktuální zvyklosti, zpětnou kompatibilitu a známé i neznámé chyby, jež se v jednotlivých verzích firmwarů výrobců vyskytují. Výsledkem vývoje verze 1.1 byla aplikace, která po sérii testování v uzavřené komunitě lidí z OldanyGroup, byla podrobena velkému reengineeringu, který zapříčinil vznik
Vyhodnocení dosažených výsledků
85
mimořádné verze 1.2, která mě donutila přečíslovat verze ve zbytku harmonogramu. Aplikace doteď obsahuje některé nestandardní kusy kódu, které pravděpodobně odporují zažitým zvyklostem, ale aplikace funguje, takže nakonec nebyl důvod do tohoto kódu zasahovat. Mimo komplikace při samotném vývoji jsem se potýkal i s neochotou spolupráce ze strany vývojářů BeeScale API, kteří byli zaneprázdněni svými neodkladnými úkoly na paralelně probíhajících projektech. Následkem tohoto a výše uvedených selhání lidského faktoru došlo k nežádoucímu prodloužení termínů harmonogramu projektu. Aplikace se nyní nachází ve vývojové fázi verze 1.4 (podle harmonogramu 1.3), která měla být publikována původně 19. 02. 2013, avšak mé vytížení na zpracování textu této teze mi včasné uvolnění aplikace znemožnil. Aplikace tedy měla být publikován před odevzdání této práce, avšak konec podpory Twitter API verze 1.0 mi proces publikace opět znemožnil. Zdrojový kód nepublikované verze 1.4 tedy přikládám v Příloze B. Dříve publikovaný BeeScale Client verze 1.3 si podle dosavadních informací ze statistik Google Play nainstalovalo již 50 uživatelů, což není zrovna mnoho, ale tento stav mohu z velké části přisuzovat tomu, že se mezi zákazníky nachází spousta uživatelů s iOS. Toto tvrzení opírám o časté připomínky uživatelů, kteří si žádají aplikaci určenou pro tuto platformu. Počet instalací aplikace nikterak neovlivnil trend registrací uživatelů do služby. Umístění reklamy, která prostřednictvím webu služby BeeScale vyzývá uživatele ke stažení aplikace, vyvolalo prakticky okamžitou odezvu stávajících uživatelů disponujících mobilním zařízením s operačním systémem Android. Nezodpovězeným otazníkem dosud zůstával výsledek akceptačního testu požadavku „Minimalizace nároků na šířku pásma“. Za tímto účelem jsem provedl sledování běhu aplikace na reálném zařízení pomocí integrované statistické funkce ve vývojovém prostředí Eclipse SDK. Průběh jednotlivých aktualizačních cyklů ilustruje Obrázek 28. Celková spotřeba dat (na vstupu i výstupu) za dobu jedné hodiny při parametrech uvedených v akceptačním kritériu požadavku činila po zaokrouhlení 14,58 MB (viz Obrázek 29), takže akceptační kritérium bylo splněno.
Obrázek 29 – Počet přenesených dat za 1 hodinu běžného provozu (zdroj: autor)
Vzhledem k tomu, že o aplikaci, respektive její přizpůsobenou mutaci, jeví zájem společnosti, jako jsou Cloud4Com (C4C) a T-Mobile, tak nezbývá vyhodnotit výsledek projektu jinak, nežli že jeho dosavadní průběh byl úspěšný, protože je potenciálním zdrojem příjmů pro firmu, ve které působím.
7.3
Možnosti dalšího rozvoje aplikace
V první řadě mám v plánu pokračovat ve vývoji aplikace minimálně do verze 1.5, a potom se s vedením společnosti rozhodneme o další budoucnosti aplikace, tedy o možných nových funkcionalitách nebo o variantě rozšíření aplikace mimo platformu operačního systému Android. Konkrétně se jedná o Apple iOS a Microsoft Windows Phone, protože podle ohlasů několika nejmenovaných zákazníků by byl tento krok žádoucí. Integrace VNC klienta se jeví jako funkcionalita, které by mohla zásadně přispět ke komplexitě celé aplikace. Mimo sadu operativních akcí, které každý vServer nabízí, by bylo možné daný vServer v reálném čase obsluhovat přímo na úrovni operačního systému. Zvažuji začlenění některé z open-sourcových variant, jako například projektu TightVNC18, který by jako odrazový můstek pro takového řešení mohl posloužit.
18
http://www.tightvnc.com/
Vyhodnocení dosažených výsledků
87
V návaznosti na informaci z webu [42] o zastarání Twitter API verze 1.0 bude nutné přejít k implementaci verze 1.1, protože od 11. června 2013 přestalo API verze 1.0 definitivně fungovat. Z tohoto důvodu aplikace BeeScale Client nyní hlásí chybu komunikace serverem (viz Obrázek 30). Z důvodů, které popisuje web [43], je po 11. červnu 2013 vyžadováno ověření pomocí speciálního bezpečnostnímu mechanismu OAuth19.
Obrázek 30 – Snímek chyby Twitter API (zdroj: autor)
Další rozvoj aplikace se bude do velké míry odvíjet od toho, jakou funkcionalitu bude v budoucnu BeeScale API podporovat.
19
https://dev.twitter.com/docs/auth/oauth
Závěr
88
8 Závěr Výsledkem studie metodik jsem podle očekávání docílil formulace důležitých doporučení a postupů pro začínající programátory, kteří se chtějí zabývat návrhem a kódováním grafického uživatelského rozhraní pro mobilní zařízení. Shlédl jsem řadu odborných článků a kvalifikačních prací, a to nejlepší z nich vyústilo v poměrně vyčerpávající text kapitoly 3.3. Materiály, ze kterých jsem čerpal, byly až na drobné výjimky ve shodě. Problém těchto materiálů však spočíval v tom, že žádný z nich nebyl úplný, a to jsem se od začátku snažil odbourat. Výsledek aplikování studie v praxi shrnuje kapitola 7.1. Přes všechny peripetie, které shrnuje vyhodnocení projektu v kapitole 7.2, si nakonec dovolím hodnotit uplynulou část projektu jako zdařilou, a to zejména z toho důvodu, že mi byla hlubokým zdrojem cenných zkušeností, které snad ani nelze získat efektivnější cestou, nežli ponaučením se z vlastních chyb a neutuchajícím vzdorem proti komplikacím, které při řešení komplexních problémů časem zákonitě vyvstávají. Aplikace je v současné době stále ve vývoji, ale většinová část požadavků na aplikaci již byla splněna. Možnosti dalšího rozvoje aplikace mapuje kapitola 7.3. Obsah diplomové práce by mohl být zejména ve své realizační části o něco rozsáhlejší, což by ovšem bylo vykoupeno, dle mého názoru, znatelným překročením stanoveného rozsahu pro diplomovou práci. Z tohoto důvodu jsem se omezil pouze na základní popis řešení s tím, že přikládám materiál s největší vypovídací schopností, a tím je zdrojový kód aplikace. Výsledná aplikace může posloužit jako praktický příklad, jak vytvářet podobné aplikace v prostředí malé organizace. Jestli je to příklad dobrý, nebo špatný, nechám posoudit potenciální čtenáře. Největší přínos akademické sféře však spatřuji ve shromáždění a kritice rad a pokynů k tomu, jak správně řešit problematiku návrhu a implementace grafického uživatelského rozhraní aplikací určených pro mobilní platformu Google Android. Tato studie nakonec není pouhou kompilací teoretických textů, protože byla v průběhu návrhové a realizační fáze zmíněného projektu verifikována.
Terminologický slovník
89
Terminologický slovník Termín
Zkratka
Operační systém určený pro mobilní zařízení (smartphony, tablety, mini-počítače). Je vyvíjen společností Google a je volně dostupný. [vlastní definice autora]
Rozhraní aplikačních programů a služeb pro přístup k jejich funkcionalitě zvenčí. [vlastní definice autora]
Apiarist
Řadič virtualizované infrastruktury (cloud hypervisor) platformy BeeStack. [19 s. 5]
BeeStack
Sada technologií, jež dohromady tvoří architekturu infrastrukturního cloudu BeeScale. [vlastní definice autora]
Callback
Zpětnovazebný prvek zdrojového kódu. Jedná se o reakci na událost vyvolanou v průběhu asynchronní operace. Tato reakce je předávána jiné části kódu, která s ní podle vývojářem předepsaného programu naloží. [vlastní definice autora]
Cloud Computing
Sada modelů pro sdílené a konfigurovatelné výpočetní zdroje (sítě, servery, úložiště, aplikace a jiné služby), které jsou dostupné v uživatelem požadované míře, rychle a s co nejnižším úsilím z jakéhokoliv místa na světě. [25 s. 2]
Document Object Model
DOM
Aplikační programové rozhraní pro přístup k XML dokumentu v podobě stromové struktury. [10 s. 81]
Feature-Driven Development
FDD
Jedna z agilních metodik. „Je založena na iterativním vývoji, který je řízen užitnými vlastnostmi produktu.“ [6 s. 1]
GUI
Účelné uspořádání množiny grafických prvků v interaktivní celek, který slouží k ovládání softwaru za využití vstupních periferií zařízení. [vlastní definice autora]
Grafické uživatelské rozhraní, Graphical User Interface
Hive
Komponenta BeeStacku podřízená komponentě Apiarist. Virtualizovaný stroj, na němž jsou fyzicky provozovány virtuální servery zákazníků. [19 s. 6]
Terminologický slovník
Termín
Infrastructure as a Service
90
Zkratka
IaaS
Význam [zdroj] Cloudová služba, prostřednictvím které je zákazníkovi formou pronájmu poskytován výpočetní výkon, datové úložiště, síť a další základní ICT zdroje. [25 s. 3]
Rozložení, Rozvržení, Layout
Kompozice grafických prvků grafického uživatelského rozhraní. [vlastní definice autora]
Model-View-Controller
Návrhový vzor pro třívrstvé aplikace. Striktně odděluje vrstvy prezentační (view), datovou (model) a aplikační (controller). [vlastní definice autora]
MVC
Program pro konstrukci datového modelu dokumentu a validaci syntaktické správnosti vstupu. [20]
Parser
Secure Hash Algorithm
SHA
Algoritmus pro vytváření jednocestné kondenzované interpretace libovolné sekvence znaků. [5 s. 3] Typ aplikace, který disponuje pouze jednoduchou transformační logikou a prezentační vrstvou. Datová logika a převážná část aplikační logiky se nachází na straně serveru, ke kterému se klient připojuje. [10 s. 57]
Tenký klient, Thin client
Unified Modelling Language
UML
Objektově orientovaný modelovací jazyk. [4 s. 303]
Uniform Resource Identifier
URI
Jednoznačný identifikátor objektu uvnitř sítě Internet. Skládá se ze schématu a adresy objektu. [10 s. 440] Možnost sdílet výpočetní zdroje jednoho a více počítačů mezi jeden a více paralelně běžících operačních systémů. [31]
Virtualizace
Virtual Network Computing
eXtensible Markup Language
VNC
Client-server řešení pro ovládání grafického uživatelského rozhraní na vzdáleném počítači. [vlastní definice autora]
XML
„je značkovací jazyk, jehož aplikací na textové soubory vznikají jednotlivé XML dokumenty. Vlastní specifikace jazyka uvádí způsob zápisu struktury dokumentu, mechanismus vytváření logických struktur v dokumentu, pravidla deklarace elementů a vlastností apod.“ [10 s. 78]
Seznam literatury
91
Seznam literatury 1.
37SIGNALS, LLC. Millions of people in over 180 countries use Basecamp. 2013. URL .
2.
ANASTASIU, I. 5 Resources for Dedicated Android UI Design. iriphon. 2012-03-05. URL .
BRUCKNER, T. et al. Tvorba informačních systémů: principy, metodiky, architektury. 1. vyd. Praha : Grada Publishing, 2012. 357 s. Management v informační společnosti. ISBN: 978-80-247-4153-6.
5.
BRYSON, J., GALLAGHER, P. Secure Hash Standard (SHS). Gaithersburg : National Institute of Standards and Technology, 2012-03. Federal Information Processing Standards Publication Series. URL .
6.
BUCHALCEVOVÁ, A. Metodika feature-driven development neopouští modelování a procesy, a přesto přináší výhody agilního vývoje. In Tvorba softwaru 2005. Ostrava 01.06.2005 – 03.06.2005 : Tanger, 2005, s. 25–30. URL . ISBN: 80-86840-14-X.
7.
ČSN ISO 10006:2003. Systémy managementu jakosti - Směrnice pro management jakosti projektů. 2. vyd. Praha : Český normalizační institut, 2004.
8.
DFA. c# - Can I pass parameters by reference in Java? Stack overflow. 2009-07-01. URL .
9.
DOHNAL, T. Návrh grafického uživatelského rozhraní. 2008. Praha. 59 s. URL .
10.
GÁLA, L., POUR, J., ŠEDIVÁ, Z. Podniková informatika. 2. přeprac. a aktualiz. vyd. Praha : Grada, 2009. 496 s. Expert. ISBN: 978-80-247-2615-1.
11.
GOOGLE INC. Android Developers. 2013. URL .
12.
GOOGLE INC. Android SDK. Android Developers. 2013. URL .
13.
GOOGLE INC. Android, the world’s most popular mobile platform. Android Developers. 2013. URL .
Seznam literatury
92
14.
GOOGLE INC. Context. Android Developers. 2013. URL .
15.
GOOGLE INC. Dashboards. Android Developers. 2013. URL .
16.
GOOGLE INC. Permissions. Android Developers. 2013. URL .
17.
GREENLEE, M. The Best Approach to Android’s Design Guidelines. Dice News. 2013-01-02. URL .
18.
KAMENÍČEK, L. Použití webových technologií při vývoji mobilních aplikací na platformě Android | VŠE. 2011. Praha. 57 s. URL .
19.
KOPTA, M., ŽITNÝ, J. Dokumentace BeeStack (verze 1.0.2). 2012. Praha. 52 s.
20.
KOSEK, J. Parsery. 2001. URL .
21.
KUČERA, F. Distribuované verzovací systémy. AbcLinuxu. 2011-01-25. URL .
22.
LODL, J. ANDROID VÍTĚZÍ, ALE NENÍ JEDINÝ. Počítač pro každého. 2013-03-04, č. 6. URL .
23.
MADEJ, T. Srovnání uživatelského rozhraní mobilních telefonů s dotykovým ovládáním. 2013. Olomouc. 101 s. URL .
24.
MCDONALD, J. Mobile Design Practices For Android: Tips And Techniques. Smashing Magazine. 2012-07-26. URL .
25.
MELL, P., GRANCE, T. The NIST Definition of Cloud Computing. National Institute of Standards and Technology, 2011 [cit. 2013-03-12]. URL .
26.
MUTUAL MOBILE, INC. Android design guidelines. 2011-04. URL .
27.
OLDANYGROUP S.R.O. Jak to funguje. BeeScale | your smart way to cloud. 2013. URL .
Seznam literatury
93
28.
OLDANYGROUP S.R.O. Jen (z)virtualizovat nestačí…. 2013. URL .
29.
OLDANYGROUP S.R.O. Kolik to stojí. BeeScale | your smart way to cloud. 2013. URL .
30.
OLDANYGROUP S.R.O. Profil společnosti. OldanyGroup. URL .
PALMER, S. R., FELSING, J. M. A practical guide to feature-driven development. Upper Saddle River : Prentice Hall PTR, 2002. 271 s. The Coad series. ISBN: 0-13-067615-2.
Příloha A: Požadavky na aplikaci BeeScale Client Název
Zpětná kompatibilita
Typ
Nefunkcionální
Vyvíjená aplikace musí být zpětně kompatibilní se všemi verzemi operačního systému Android, a to až do historie verze 2.1, čili API verze 7.
Váha
Must
Cílem je pokrytí co nejširšího množství zařízení na trhu, na které bude aplikaci možné nainstalovat. Původ
Popis
Propojení Aplikaci je možné nainstalovat a spustit na všech verzích Androidu Akceptační od verze 2.1 výše bez jakékoliv znatelné deformace vykreslení GUI. kritérium
Přílohy
Obrázek 5
Definováno uvnitř manifestu aplikace (AndroidManifest.xml) pomocí tagu <uses-sdk android:minSdkVersion="7" />. Komentáře
Při tvorbě aplikace bude přihlíženo k oborovým standardům a doporučením pro tvorbu grafického uživatelského rozhraní se zacílením na mobilní platformy.
Váha
Must
Výsledná podoba GUI musí reflektovat grafické schéma (šablonu) webu služby BeeScale.
Původ
Důvodem je příjemná zkušenost uživatele plynoucí z práce s aplikací. Propojení
Akceptační kritérium
Výsledná podoba GUI není v rozporu s relevantními doporučeními uvedenými v rešerši, které je věnována kapitola 3.
Přílohy
Komentáře
Tabulka 3 – Požadavek: Respektování best-practises pro tvorbu GUI (zdroj: autor)
Studie metodik tvorby GUI mobilních aplikací
Příloha A: Požadavky na aplikaci BeeScale Client
Název
99
Přihlášení uživatele Přístup do BeeScale vyžaduje ověření uživatelského účtu, proto je třeba aplikaci opatřit přihlašovací obrazovkou. Přihlašovací údaje jsou kombinací uživatelského jména a hesla, které musí být v předepsaném formátu odeslány na BeeScale API, kde dojde k verifikaci identity uživatele.
Popis
Uživatelské údaje musí být možné uložit do paměti zařízení pro urychlení přístupu uživatele do aplikace. Výsledná podoba obrazovky bude obsahovat dvě textová pole, přepínače pro zapamatování přihlašovacích údajů a tlačítko pro přihlášení uživatele.
Typ
Funkcionální
Váha
Must
Původ
Případ užití: Přihlášení do služby
Propojení
Po stisknutí tlačítka přihlásit je uživatel přihlášen a „vpuštěn“ do aplikace, Akceptační nebo je odmítnut se zprávou o špatném uživatelském jméně nebo heslu. kritérium
Přílohy
Obrázek 32
Heslo pro ověření uživatele na BeeScale API musí být poskytnuto ve formátu heslo + uživatelské jméno, a to celé je následně Komentáře algoritmem SHA-1 proměněno v hash.
Aplikace by po svém spuštění měla zobrazit jednu nebo více aktualit ze sociální sítě Twitter (kanál BeeScale).
Váha
Could
Důvodem je upozornění uživatele na nečekané eventuality v provozu služby, aktualizace jakéhokoliv rázu, speciální nabídky pro zákazníky a jiná sdělení provozovatele služby BeeScale.
Původ
Případ užití: Zobrazení aktualit
Propojení
Požadavek: Přihlášení uživatele
Po spuštění aplikace je zřetelně vypsána poslední ze zpráv kanálu BeeScale Akceptační sociální sítě Twitter. kritérium Využít Twitter API verze 1.0, jehož implementace je naprosto triviální. Komentáře
Tabulka 5 – Požadavek: Aktuality z Twitteru (zdroj: autor)
Přílohy
Obrázek 32
Příloha A: Požadavky na aplikaci BeeScale Client
Název
101
Detail uživatelského účtu
Typ
Funkcionální
Po přihlášení by měla být dostupná obrazovka s podrobným výpisem informací o uživatelském účtu, který je veden v rámci služby BeeScale.
Váha
Must
Původ
Případ užití: Správa uživatelského účtu
Obrazovka musí zobrazovat tyto informace: Popis
jméno uživatele, e-mailovou adresu, výši kreditu, aktuální spotřebu kreditu, režim (limit) uživatelského účtu, seznam provedených plateb do kreditního systému, sumarizaci počtu vServerů a vDisků.
Důvodem této funkcionality je potřeba poskytnout uživateli informace zejména o aktuálním stavu jeho konta a aktuální spotřebě jeho finančních prostředků. Po přihlášení do aplikace je uživateli dostupná obrazovka s informacemi Akceptační o jeho uživatelském účtu (plné jméno uživatele, email, spotřeba kreditu, kritérium aktuální a běžný limit, počty pronajímaných virtuálních entit).
Dobití kreditu Aplikace by měla umožňovat uživateli provést platbu na svůj kreditní účet prostřednictvím buď platební brány, nebo pomocí API Androidu, se kterým lze například využít technologie bezkontaktních plateb nebo využít zaregistrované platební karty u společnosti Google.
Popis
Tato funkcionalita by měla značně zpříjemnit dobíjení docházejícího kreditu ve chvíli, kdy uživatel nemá k dispozici zařízení s velkým displejem. Platba tímto způsobem by byla dokonce o mnoho komfortnější, protože by vyžadovala minimum vstupů od uživatele.
Existence funkčního tlačítka „Dobít kredit“, který buď využije služeb Akceptační externí platební brány, nebo nabídne možnost dobít libovolnou částku kritérium pomocí registrované platební karty, která je přiřazena ke Google účtu daného zařízení.
Uživatel, který si stáhne aplikaci z Google Play tržiště a není registrovaný na službě BeeScale, bude mít možnost se prostřednictvím mobilní aplikace zaregistrovat díky speciálnímu formuláři, kde zadá svůj email a heslo s následnou kontrolou zadání. Popis
Důvodem je zvýšení komfortu užívání aplikace, kdy potenciální uživatel nemusí přistupovat na plnohodnotný web aplikace.
Existence tlačítka „Registrace“ na přihlašovací obrazovce aplikace Akceptační s funkcionalitou předepsanou v popisu. kritérium
Data, na jejichž základě je vykreslován obsah serverovny, je možné obnovovat ručně nebo automatizovaně v uživatelem vybraném intervalu (10, 20 nebo 30 sekund).
Původ
Případ užití: Správa virtuálního datacentra
Důvod implementace této funkcionality je ten, že výše popsaná obrazovka bude středobodem práce s objekty virtuálního datacentra.
Propojení
Po přihlášení je uživatel přesměrován na obrazovku s výpisem svých vServerů. Každá položka seznamu, jež reprezentuje jeden vServer, bude obsahovat informaci o aktuálním stavu (text a piktogram), jméno, veřejnou IP adresu nebo adresy a označení operačního systému. Popis
Existence obrazovky s parametry definovanými v popisu požadavku. Akceptační kritérium
Přílohy
Komentáře
Tabulka 9 – Požadavek: Výčet vServerů ve virtuálním datovém centru (zdroj: autor)
Obrázek 33
Příloha A: Požadavky na aplikaci BeeScale Client
105
Název
Výčet akcí vybraného vServeru
Popis
Po výběru vServeru z výčtu serverů ve virtuálním datacentru uživatele bude umožněno na vyhrazené záložce vybrat jednu z akcí, jež vServer v danou chvíli nabízí. Vyvolání každé z akcí bude předcházet dialog s potvrzením, zdali akci opravdu provést. V případě, že nějaká akce probíhá, je seznam úloh neviditelný a je na jeho místě vypisován aktuální stav výkonu dané akce.
Typ
Funkcionální
Váha
Must
Původ
Případ užití: Provést úlohu
Bez této obrazovky nebude možné s virtuálními servery operativně manipulovat. Propojení Existence záložky „Akce“ v kontextuální obrazovce detailu uživatelem Akceptační vybraného vServeru. kritérium
Přílohy
Požadavek: Výčet serverů ve virtuálním datovém centru
Obrázek 35
Seznam disponibilních akcí je determinován datovými podklady získanými z BeeScale API, čili seznam akcí je dynamicky Komentáře generován na základě tohoto vstupu.
Po výběru vServeru z výčtu serverů ve virtuálním datacentru uživatele bude umožněno na vyhrazené záložce zobrazit výčet detailních informací o vybraném vServeru.
Váha
Must
Důvodem implementace tohoto požadavku je možnost nabídnout uživateli ucelené penzum informací o vybraném vServeru determinující jeho stav a aktuální konfiguraci.
Původ
Případ užití: Zobrazení detailu vServeru
Propojení
Požadavek: Výčet serverů ve virtuálním datovém centru
Existence záložky „Detail serveru“ v kontextuální obrazovce detailu uživaAkceptační telem vybraného vServeru. kritérium
Přílohy
Obrázek 34
Seznam disponibilních detailních informací je determinován datovými podklady získanými z BeeScale API, čili seznam Komentáře detailních informací je dynamicky generován na základě tohoto vstupu.
Tabulka 11 – Požadavek: Výčet detailních informací o vybraném vServeru (zdroj: autor)
Příloha A: Požadavky na aplikaci BeeScale Client
Název
Popis
107
Grafy statistik vybraného vServeru
Typ
Funkcionální
Po výběru vServeru z výčtu serverů ve virtuálním datacentru uživatele bude umožněno na vyhrazené záložce zobrazit grafy statistik (vytížení vCPU, čerpání vRAM a spotřeba disponibilní šířky pásma síťového připojení).
Váha
Should
Důvodem je možnost poskytnutí historického vývoje sledovaných ukazatelů a umožnit uživateli z pozorovaných trendů vyvodit patřičné důsledky.
Původ
Případ užití: Zobrazit statistiky
Propojení Existence záložky „Statistiky“ v kontextuální obrazovce detailu uživatelem Akceptační vybraného vServeru. kritérium
Přílohy
V současné době není možné sledovat statistiku vRAM. Komentáře
Tabulka 12 – Požadavek: Grafy statistik vybraného vServeru (zdroj: autor)
Požadavek: Výčet serverů ve virtuálním datovém centru
Obrázek 36
Příloha A: Požadavky na aplikaci BeeScale Client
Název
108
Formulář pro tvorbu nového vServeru Aplikace bude umožňovat vytvářet nové virtuální servery z obrazovky datacentra uživatele. Proces vytváření nového serveru započne stisknutím tlačítka s piktogramem „+“. Parametry nového vServeru bude možné navolit na speciálním formuláři. Bude možné zvolit alespoň: ● název serveru,
Popis
Typ
Funkcionální
Váha
Should
Původ
Případ užití: Vytvořit nový vServer
● počet jader (vCPU), ● kapacita vRAM, ● operační systém (první disk), ● kapacitu datového disku (druhý disk).
Propojení
Důvodem je zvýšení komfortu užívání služby BeeScale. Uživatel nebude muset navštívit plnohodnotný web pro vytvoření nového vServeru. Existence formuláře s možnostmi zadávání, jak jej definuje popis Akceptační požadavku. kritérium
Přílohy
BeeScale API zatím neumožňuje vytvořit více než 2 vDisky. Komentáře
Tabulka 13 – Požadavek: Formulář pro tvorbu nového vServeru (zdroj: autor)
Obrázek 37
Příloha A: Požadavky na aplikaci BeeScale Client
Název
Popis
109
Vzdálené řízení vServeru
Typ
Funkcionální
Umožnit využití veřejné IP adresy uvedené ve výpisu detailních informací o vServeru ke vzdálenému řízení. Vzdálené řízení představuje implementaci VNC klienta uzpůsobeného pro využití na mobilním zařízení.
Váha
Could
Důvod k implementaci je ten, že správce serverů, jež se nachází na cestách a nemá k dispozici plnohodnotný terminál, bude mít možnost server pohotově vzdáleně ovládat a řešit případné provozní problémy.
Původ
Případ užití: Spustit vzdálenou správu
Propojení
Požadavek: Výčet detailních informací o vybraném vServeru
Existence tlačítka pro vyvolání VNC konzole a možnost ovládání konzole Akceptační prostřednictvím dotykového ovládání s možností vstupu pomocí kritérium softwarové klávesnice.
Přílohy
Využít některý z dostupných open-sourcových projektů. Komentáře
Tabulka 14 – Požadavek: Vzdálené řízení vServeru (zdroj: autor)
Příloha A: Požadavky na aplikaci BeeScale Client
Název
Popis
110
Diagnostika vServeru
Typ
Funkcionální
Umožnit využití veřejné IP adresy uvedené ve výpisu detailních informací o vServeru k diagnostice jeho dostupnosti pomocí příkazu PING.
Váha
Could
Když už nebude k dispozici jiný nástroj diagnostiky, tak alespoň tato jednoduchá diagnostická funkce bude moci ověřit, zdali je vServer dostupný ze sítě Internet, tedy i ověřit, zdali se právě nenachází v havarijním stavu.
Původ
Případ užití: Ověřit dostupnost
Propojení
Požadavek: Výčet detailních informací o vybraném vServeru
Existence kontextuálního tlačítka pro provedení diagnostické funkce Akceptační popsané v popisu. Výsledkem bude informace o úspěšnosti nebo kritérium neúspěšnosti diagnostické operace.
Na obrazovce výčtu serverů uživatele by mělo být dostupné tlačítko pro vyvolání obrazovky, kde uživatel bude moci spravovat vDisky, které v danou chvíli nenáleží žádnému z vServerů.
Váha
Should
Tyto disky bude možné vymazat, nebo je připojit k některému z vServerů v datacentru uživatele.
Původ
Případ užití: Správa odpojených vDisků
Mimo vServery je nutné spravovat i objekty vDisků. Disk, na kterém jsou důležitá data, by po výmazu vServeru nebyl nikterak dostupný. Tomu předchází možnost jej znovu připojit, nebo nenávratně vymazat. Disky se před odstraněním vServeru automaticky odpojují. Existence tlačítka pro vyvolání obrazovky dle popisu výše. Disky bude Akceptační možné smazat. kritérium
Propojení
Přílohy
Možnost opětovného připojení vDisku je řešena odkazem na rekonfiguraci vServeru. Komentáře
Tabulka 16 – Požadavek: Správa nepřipojených vDisků (zdroj: autor)
Požadavek: Výčet serverů ve virtuálním datovém centru
Obrázek 39
Příloha A: Požadavky na aplikaci BeeScale Client
Název
112
Rekonfigurace existujícího vServeru Po výběru jednoho z vServerů z datového centra může uživatel pomocí stisknutí tlačítka „Konfigurovat“ provést jeho rekonfiguraci. Rekonfigurační formulář bude variací formuláře pro vytvoření nového vServeru. Po zobrazení formuláře budou načteny současné parametry vServeru, které uživatel bude moci díky svým vlastním vstupům modifikovat.
Typ
Funkcionální
Váha
Should
Původ
Případ užití: Rekonfigurovat vServer
Popis Požadavek: Formulář pro tvorbu nového vServeru Propojení
Existence přístupového místa k formuláři rekonfigurace vServeru. Akceptační Existence formuláře, který je variací obrazovky pro vytváření nových kritérium vServerů.
Přílohy
BeeScale API momentálně funkcionalitu pro rekonfiguraci vServerů neimplementuje. Komentáře
Průtok dat skrze celulární síť nebo wifi nesmí překročit v klidovém režimu 30 MB za hodinu.
Váha
Must
Optimalizace je důležitá z důvodu u tuzemských mobilních operátorů.
nízkých
přenosových
limitů Původ
Popis
Propojení Průtok dat skrze celulární síť nebo bezdrátovou lokální síť nesmí být větší než 30 MB za hodinu. Směrodatný subjekt pro sledování naplnění Akceptační akceptačních kritérií je uživatel, který bude provozovat 10 vServerů kritérium a 13 vDisků. Měření se provádí na obrazovce datového centra bez jakýchkoliv zásahů ze strany uživatele.
Přílohy
Komentáře
Tabulka 18 – Požadavek: Minimalizace nároků na šířku pásma (zdroj: autor)
Příloha A: Požadavky na aplikaci BeeScale Client
Název
114
Bezpečnost aplikace
Typ
Nefunkcionální
Aplikace musí splňovat bezpečnostní standardy typické pro cloudové aplikace provozované prostřednictvím mobilní platformy.
Váha
Could
Důvodem bezpečnostního auditu je požadavek potenciálního partnera na jeho provedení. Původ
Popis
Propojení Pozitivní výsledek penetračních testů provedených nezávislou společností Akceptační se specializací na bezpečnost mobilních aplikací. kritérium
Přílohy
Komentáře
Tabulka 19 – Požadavek: Bezpečnost aplikace (zdroj: autor)
Příloha A: Požadavky na aplikaci BeeScale Client
Název
115
Umožnění lokalizace do světových jazyků Aplikace umožní snadnou lokalizaci svých textových řetězců zobrazovaných na prezentační vrstvě. Ve zdrojovém kódu se budou vyskytovat pouze jmenné reference odkazující na lokalizované textové řetězce vyvedené do separátního souboru.
Popis
Důvodem je ulehčení procesu lokalizace aplikace do jiných světových jazyků v případě expanze služby BeeScale.
Typ
Nefunkcionální
Váha
Should
Původ
Propojení Ve zdrojovém kódu aplikace se nebude vyskytovat žádný textový řetězec. Akceptační Textové řetězce zobrazované na prezentační vrstvě jsou vyvedeny kritérium do separátního XML dokumentu (strings.xml).
Přílohy
Komentáře
Tabulka 20 – Požadavek: Umožnění lokalizace do světových jazyků (zdroj: autor)
Příloha A: Požadavky na aplikaci BeeScale Client
Název
116
Usnadnění rebrandingu nebo customizace GUI Grafické uživatelské rozhraní aplikace by mělo sestávat ze sady šablon jednotlivých obrazovek. Obsah těchto šablon by měl být ze strany zdrojového kódu co nejmenší měrou generován nebo modifikován, aby byl obsah těchto šablon snadno zaměnitelný.
Popis
Důvodem pro vyčlenění modelů obrazovek je budoucí potřeba rebrandingu nebo jiné formy customizace pro potenciální a stávající partnery provozující vlastní mutaci BeeStacku.
Typ
Nefunkcionální
Váha
Should
Původ
Propojení U všech obrazovek, kde není nezbytně nutné generovat obsah ze strany Akceptační zdrojového kódu aplikace, je vyčleněna grafická šablona do separátního kritérium XML souboru nebo souborů.
Příloha B: Zdrojové kódy aplikace Z důvodu nadměrného rozsahu zdrojových kódů předmětu této diplomové práce a množství dalšího nezbytného příslušenství poskytuji kompletní aplikační projekt BeeScale Clienta verze 1.4 v elektronické podobě prostřednictvím přiloženého ZIP archivu xandt05_OG_BSC.zip. Projekt byl vyvíjen ve vývojovém prostředí Eclipse SDK verze 4.2.0. Nosná struktura projektu uvnitř archivu se skládá z následujících souborů a složek: ● achartengine-1.0.0.jar – externí knihovna pro tvorbu grafů. ● BeeScale.apk – instalační balíček pro nasazení aplikace v prostředí OS Android. ● BeeScale Monitor – kořenová složka projektu BeeScale Client (dříve Monitor). ● AndroidManifest.xml – deskriptor aplikace. Uvádí se zde úroveň oprávnění, cílová verze Android API a seznam aktivit. ● gen – složka, do níž si vývojové prostředí ukládá automaticky generovaný zdrojový kód. ● src – složka, jež obsahuje hlavní zdrojové kódy aplikační logiky. ● res – složka, jejímž obsahem je sada XML souborů a obrázků. XML soubory determinují vzhled GUI a obsah zobrazovaných textových řetězců.
Příloha C: Koncepty obrazovek GUI
Příloha C: Koncepty obrazovek GUI
Obrázek 31 – Koncept obrazovky registrace uživatele (zdroj: autor)
118
Příloha C: Koncepty obrazovek GUI
Obrázek 32 – Koncept obrazovky přihlášení uživatele (zdroj: autor)
119
Příloha C: Koncepty obrazovek GUI
Obrázek 33 – Koncept obrazovky Moje serverovna (zdroj: autor)
