Загальна характеристика приміщення

Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Национальный технический университет Украины «Киевский политехнический институт»

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

5_Пояснювальна записка.docx

Скачиваний:

Добавлен:

12.05.2015

Размер:

2.52 Mб

Скачать

☆

1 / 31 2 3 > Следующая >>>

ПЕРЕЛІК СКОРОЧЕНЬ

ОС – операційна система

UI (User Interface) – інтерфейс користувача

XAML (eXtensible Application Markup Language) – розширювана мова розмітки для додатків

XML (eXtensible Markup Language) – розширювана мова розмітки

HTML (HyperText Markup Language) – мова гіпертекстової розмітки

SDK (Software Development Kit) – набір інструментальних засобів розробки програм

COM (Component Object Model) – стандарт від компанії Microsoft, призначений для створення програмного забезпечення на основі взаємодіючих компонентів

API (Application Programming Interface) – інтерфейс програмування додатків

ATL (Active Template Library) – набір шаблонних класів мови C++, розроблених компанією Microsoft для спрощення написання COM-компонентів

БД – база даних

SQL (Structured Query Language) – формальна непроцедурна мова програмування, що застосовується для створення, модифікації та управління даними в довільній реляційній базі даних

REST (Representational State Transfer) – стиль побудови архітектури розподіленого додатку

UML (Unified Modeling Language) – мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення

ВСТУП

В сучасному світі додатки для мобільних платформ витісняють свої аналоги на настільних операційних системах. Все частіше такі програми переорієнтовуються та пристосовуються до управління дотиком. Наразі видніється чітка грань між персональним комп’ютером та мобільним пристроєм – перший застосовується для створення контенту, а другий – для його споживання.Дійсно, розробити програму на сенсорному екрані без можливості під’єднання миші та клавіатури дуже проблемно, а споживати контент, інформацію на планшеті чи смартфоні легше, аніж на персональному комп’ютері.

Мобільні пристрої все частіше використовуються для навчання. Прикладом таких програм є різноманітні додатки для вивчення іноземних мов. На планшеті чи смартфоні також дуже зручно читати документи. Актуальним для нашої країни зараз є найголовніший документ – Конституція України. Все більше людей апелює до Основного Закону, тому важливо знати і розуміти його. Написання додатку, що надасть оперативний та зручний доступ до Конституції України, дозволить підвищити обізнаність населення з законами України.

ОГЛЯД ІСНУЮЧИХ СЕРВІСІВ ДЛЯ ЧИТАННЯ КОНСТИТУЦІЇ УКРАЇНИ ТА ІНСТРУМЕНТІВ РОЗРОБКИ ДОДАТКІВ
1. Огляд існуючих програмних рішень

В двадцять першому столітті важливою галуззю програмного забезпечення є розробка додатків для мобільних пристроїв. Такі пристрої з кожним роком стають все розумнішими, надаючи більше можливостей як користувачеві, так і програмісту, збільшуючи свої варіанти взаємодії. На даний момент для різних мобільних платформ існує безліч додатків на різноманітну тематику – починаючи з програм, що дозволяють читати новини з різних ресурсів, закінчуючи програмами-асистентами, що допомагають розпланувати день, взаємодіючи з користувачем через мікрофон та динамік, та мобільних соціальних мереж. Прогресивні навчальні заклади створюють мобільні додатки для взаємодії учнів з учителями та студентів з викладачами/деканатом, великі демократичні країни – додатки для доступу до державних документів, наприклад, відкриті дані державних закупівель. В деяких країнах планується проводити референдуми та вибори на спеціальних веб-сайтах та за допомогою мобільних додатків. Для звичайних громадян важливим є доступ до кодексів та законів держави, серед яких найважливішим є збірка основних законів держави – Конституція. Такі додатки можна віднести до особливої категорії – «Урядові додатки». Наразі така категорія представлена найменш широко порівняно з іншими на всіх мобільних платформах.

Основний спосіб розповсюдження мобільних програм – це так звані «магазини додатків», які мають на кожній платформі свою назву. Найбільш популярні платформи – App Store (для ОС iOS), Google Play (для ОС Android), Windows Phone Store (для ОС Windows Phone) та Windows Store (для ОС Windows 8 та вище). Платформи розташовані в порядку спадання кількості додатків. Після проведення огляду та аналізу категорії «Урядові додатки» виявилось, що кількість та якість додатків для перегляду основних законів країни не залежить від розповсюдженості платформи та кількості програм у магазині. Для ілюстрації аналізу можна створити таблиці, в яких будуть продемонстровані найякісніші та найбільш популярні програми для перегляду Конституції, а також основні функції для таких програм (вибрані статті для швидкого доступу та читання без підключення до Інтернету). Для зменшення множини результатів з усіх додатків було вибрано лише ті, що надають доступ до Конституції України.

Результати аналізу для кожної платформи наведені в табл.1.1.

Таблиця 1.1. Результати аналізу додатків

Платформа	Назва програми	Функції
Платформа	Назва програми	Вибране	Офлайн-доступ до статей
iOS	Конституція України for iPhone and iPad	+	+
Android	Конституция Украины byOleksandrKotyuk	+	+
	Конституция Украины by Feofanix	-	+
	Конституция Украины by Voltage Software	-	+
Windows Phone	Конституція України by WP7PUBLISH	-	+
Windows Phone	Конституція України by Sergiy Baydachnyy	-	+

Додаток для ОС iOS – єдиний, що в повному обсязі надає для читання Конституцію України. Перевагою цього додатку є також версія як для смартфону (iPhone), так і для планшету (iPad). Коштує така програма 0.99$.

Вибрані програми для ОС Android мають спрощений інтерфейс, що полегшує доступ до інформації, але відсутність можливості позначити статті як вибрані може стати перепоною до комфортного застосування додатку. Результати для ОС Windows Phone дублюють результати ОС Android: простота інтерфейсу, мінімум функцій, максимум інформації, але ні в одному додатку не було реалізовано можливість вибирати статті для швидкого доступу.

Для ОС Windows8та вище небуло знайдено жодного додатку для читання Конституції України.

Аналіз недоліків існуючих додатків

Можна виділити декілька основних недоліків вищезгаданих додатків для усіх платформ:

Жорстке недотримання guidelines – збірки правил, що притаманні операційній системі для додержання загальної стилістики усіх програм. Такі правила не є обов’язковими для виконання. Їх недотримання буде виділяти додаток з-поміж стандартних, але це виділення, як правило, погано впливає на зручність використання та загальний дизайн програми. Таке виділення доцільно використовувати,якщо розроблювальна програма повинна бути піддана брендуванню.
До недотримання guidelinesтакож можна віднести використання різного типу шрифтів. В більшості платформ використовується одне задане сімейство шрифтів (Windows – Segoe UI, Android – Droid, iOS - Helvetica), тож використання інших шрифтів не вітається (виключення – все ті ж брендовані програми). Вибір із декількох шрифтів, як в деяких розглянутих додатках, також не підвищує рівень комфорту читання інформації, а навпаки – спантеличує користувача різноманітністю інтерфейсів та шрифтів.
Наявність можливості зберігати інформацію у спеціальний розділ «Вибране» - важлива складова успішного та зручного інформаційного додатку. Його відсутність, як у більшості розглянутих додатків, може ускладнити роботу з додатком, особливо якщо інформації в цьому додатку багато і вона слабко структурована.
Досліджувані додатки мають також один спільний мінус – зберігання тексту Конституції України в пам’яті пристрою. Таке рішення,звичайно, зменшує навантаження на мережу та зменшує кількість завантажених з Інтернету даних, але після прийняття Верховною Радою змін до Конституції України розробнику буде необхідно оновити додаток, а так як процес оновлення та сертифікації додатку (процес, що передує опублікуванню програми і проводиться виключно стороною, яка володіє магазином додатків) займає великий обсяг часу, користувачі не будуть отримувати свіжу інформацію протягом 1-2 тижнів.

Формулювання вимог до розроблюваного додатку

Розробка додатку для ознайомлення з Конституцією України повинна включати в себе вирішення усіх недоліків, що перераховані в підрозділі 1.2. На основі вирішення усіх недоліків можливо виділити два основних напрями формалізації вимог – інформаційний та технічний. До технічного напрямку входять усі можливості, що дозволяє платформа – інтеграція будь-яким чином у операційну систему, використання інформування користувача засобами операційної системи, тобто, усі можливості, що надає саме платформа для вирішення поставлених цілей. В інформаційному напрямку можна виділити подання інформації, способи такого подання, структуризація інформації та можливості при роботі з нею.

Формулювання вимог до технічних можливостей додатку

Додаток повинен бути розроблений як для смартфону, так і для планшету, що дозволятиме користувачеві використовувати одну і ту ж програму з однаковими можливостями, незважаючи на пристрій в руках. При цьому додаток повинен мати ідентичний дизайн як на смартфоні, так і на планшеті для зручності користувача.
Як зазначалося в підрозділі 1.2, проблемою існуючих додатків є зберігання статей і розділів у пам’яті пристрою. Розроблюваний додаток повинен позбутися цього недоліку і завантажувати Конституцію України з спеціально розробленої серверної частини, що дозволятиме розробнику оновлювати та редагувати статті в залежності від редакції Конституції України Верховною Радою України. Також за допомогою серверної частини необхідно розробити синхронізацію планшетної та смартфонної версії, а саме синхронізацію настроювань та статей, що були додані в категорію «Вибране».
Попередній пункт може викликати труднощі у користувачів вже існуючих додатків при переході на розроблюваний додаток через звичку до користування Конституцією в режимі без підключення до Інтернету. Також труднощі можуть бути викликані через високу вартість передачі даних на території України або закордоном. Вирішенням проблеми може стати можливість завантаження цілої Конституції в пам’ять пристрою, але при наявності з’єднання з мережею Інтернет необхідно перевіряти наявність змін на серверній частині.
Оскільки основним призначенням мобільного додатку є надання можливості користувачу доступу до інформації, що цей додаток містить, в будь-який час та в будь-якому місці, необхідно передбачити функцію пошуку по статтям Конституції. Ця функція дозволить користувачу швидко та зручно отримати всю необхідну інформацію з Основного Закону щодо тих питань, що зацікавили користувача в певний момент, без необхідності ручного пошуку в самому додатку. Реалізація пошукового механізму як по заголовкам статей, так і по їх тексту дозволить користувачу з найбільшою вірогідністю знайти саме ту статтю, яка йому необхідна. Необхідно створити два різні алгоритми пошуку - якщо Конституція вже завантажена на пристрій, то необхідно реалізувати пошук у вже завантаженому матеріалі; якщо ж користувач вибрав тільки онлайн-доступ, то пошук повинен проходити на серверній стороні.
Популярною частиною Інтернет-дозвілля є соціальні мережі, причому вони вже не є повністю розважальними – це вже інструмент передавання інформації від користувача до користувача. Додаток повинен надавати можливість користувачеві ділитися вибраною статтею через доступні соціальні мережі, що є інструментом до розповсюдження дії додатку на користувачів, які не встановили або не можуть встановити розроблюваний додаток.
Розділ «Вибране» повинен бути невід’ємною частиною додатку, що обов’язково синхронізується між усіма пристроями користувача, чи то це смартфон, чи це планшет. Треба організувати алгоритм, залучаючи серверну частину, при якому статті з розділу «Вибране» синхронізуються без втрат, незважаючи на кількість та різність вибраних статей на різних пристроях.
Додаток має дозволяти користувачеві зручно змінювати параметри додатку. Серед таких параметрів можна виділити:

Дозвіл на завантаження Конституції в пам’ять пристрою, що дозволить перегляд матеріалів без підключення до мережі Інтернет
Необхідно реалізувати дві контрастні теми для перегляду додатку – темну та світлу, що підходять до різних чинників, будь то час доби чи побажання користувача. Разом з цим необхідно забезпечити коректне та зручне відображення усіх елементів додатку в залежності від вибраної теми.
Дозвіл на синхронізацію даних між пристроями, яких у користувача може бути не один. Для цієї функції буде використовуватись серверна частина та ідентифікація користувача для запису на серверній стороні.

Формулювання вимог до інформаційних можливостей додатку

Основною вимогою інформаційних можливостей є повнофункціональність, тому додаток повинен надавати доступ до всіх без виключення розділів та статей Конституції України у зручному вигляді за допомогою рідних для вибраної платформи елементів керування. Додаток має надавати можливість вибрати на головному екрані розділ, що цікавить, а потім по вибраному розділу на наступному екрані шукати статті.
Додатковою функціональністю повинна бути розділ «Випадкова стаття», що буде відображатися на головному екрані в спеціальній області. Такий розділ буде показувати нову статтю при кожному запуску додатку.

Огляд існуючих технологій, що можуть бути використані для розробки мобільного додатку
1. Архітектура додатків різних платформ

На даний момент в світі, як згадувалось вище, найбільш популярні ОС – це Android, iOS та Windows/Windows Phone. Вони ж є найбільш гнучкими платформа для розробки великого спектру різноманітних додатків, що використовують всі можливості пристроїв.

Одною із найважливіших задач є створення додатку як на планшет, так і на смартфон. Для кожної операційної системи є свій шлях розробки таких гнучких додатків:

В ОС Androidмагазин додатків є спільним як для планшетів, так і для смартфонів. Розробка додатку повинна проходити з оглядкою на різні розміри екрану, всі візуальні елементи програми повинні без проблем підлаштовуватися під усі доступні розміри та розподільні здатності. При публікації додатку розробник вказує, для яких пристроїв буде доступна програма для завантаження – це дозволяє випустити програму тільки для смартфонів або тільки для планшетів, якщо це звучало в технічному завданні або розробник не впевнений в коректній роботі на якомусь пристрої.
В ОС iOS існує спеціальний тип додатків – «Універсальні додатки». При створенні проекту в середовищі розробки треба вказати про те, що програма буде універсальною. Для створення різних екранів для різних пристроїв необхідно створювати нові файли, тобто, для відображення однієї і тої ж сторінки треба створити два файли інтерфейсу та два файли логіки відображення цього інтерфейсу. По-перше, це збільшує кількість коду та файлів у проекті, а по-друге – при переході на сторінку треба перевіряти на якому з пристроїв (планшет iPad чи смартфонiPhone)запущений додаток. До недоліків такого підходу можна віднести неможливість використання універсальних додатків на настільній ОС від Apple – OS X, що зменшує область використання такого додатку та збільшує час на розробку ще й настільного аналогу. Плюсом такого підходу є те, що під час виконання програми iOS може сама визначати розмір дисплею та підставляти потрібні зображення (дуже актуально на цій платформі через наявність розподільної здатності Retina високої чіткості). При цьому розробнику не треба перевіряти на якому саме дисплеї було запущена програма.
В сімействі операційних систем Windows (ОС Windows 8 і вище та ОС Windows Phone) універсальні додатки з’явились порівняно недавно. Такий вид додатків дозволяє створювати програми для Windows 8.1 та Windows Phone 8.1. Можливості таких додатків дещо ширші в порівнянні із конкурентами:

Допускається використання одного файлу інтерфейсу для обох платформ. При цьому 95% елементів управління збігаються, так як з випуском останнього оновлення для обох ОС вони стали базуватися на одній і тій же платформі – WinRT. Необхідно підкреслити, що спільними для обох платформ при розробці додатку може бути практично будь-який файл, який є однаковим як для Windows, так і для Windows Phone.
У випадку, якщо програма платна, або містить in-app purchase – інтегровані в додаток покупки, які дозволяють купувати додаткову функціональність ,– купівля програми або її елементу означає покупку одразу для двох платформ. Така можливість є дуже привабливою для користувача.

Архітектуру додатку можна зобразити на рисунку 1.1.

Рис 1.1. Архітектура універсальних додатків Windows

Після створення рішення в ньому створюється 3 проекти:

Проект Windows містить сторінки та код XAML, орієнтовані на платформу Windows 8.1.
Проект Windows Phone містить сторінки та код XAML, орієнтовані на платформу Windows Phone 8.1.
Проект Sharedєконтейнером длякоду,що працюєнаобохплатформах.Вмістпроекту"Shared"автоматичновходитьв проектиWindows PhoneтаWindows. Сам проект "Shared" немаєвихідних данихзбірки.

Проект Shared на етапі компіляції ділиться на дві частини – Windows і Windows Phone – та компілюються разом з однойменними додатками. Тобто, в результаті компіляції створюються два додатки. Файл App.xaml та App.xaml.cs, що є корінними файлами для додатків сімейства ОС Windows, знаходиться в проекті Shared, що дозволяє використовувати спільні частини коду для зменшення часу та ресурсів на розробку. Якщо ж необхідно використовувати специфічні інструкції для однієї із платформ, то використовується директива #IF_WINDOWS_APP (для Windows-додатків) #IF_WINDOWS_PHONE_APP (для Windows Phone-додатків).

Середовище розробки та мова програмування для різних мобільних платформ

Під час розробки мобільних додатків 95% часу проводиться у середовищі розробки. Це – важливий елемент будь-якого проекту. Від його надійності та зручності залежить час, витрачений на розробку додатку. Для найпопулярніших платформ використовуються різні середовища (табл. 1.2):

Для ОС Android використовується програма Eclipse з плагіном Android SDK. На зміну їй приходить програма Android Studio, яка вже містить усі інструменти для створення додатків ОС Android, але вона знаходиться на стадії відкритого бета-тестування. Також можлива робота в нерідних програмах. Рідна мова програмування для Android–Javaта XMLдля розмітки екранів. Допускається також використання C#, C++.
Для ОС iOSвикористовується програма Xcode,причому розробка для платформи iOSможе вестись повноцінно лише на комп’ютері Apple.Присутня можливість використовувати сторонні середовища програмування. Рідна мова програмування для iOS – Objective-C та XML для розмітки екранів. Допускається також використання C#,C++.
Для ОС сімейства Windowsвикористовується середовище VisualStudioіз уже вбудованими інструментами для розробки мобільних додатків. Рідна мова програмування для сімейства Windows – C# + XAML або JavaScript+HTML5. Допускається також використання C++.

Існує декілька середовищ, в яких можна розробляти додатки відразу для декількох платформ на одній і тій же мові. Серед таких – Xamarin Studio (C#), QtCreator (C++) та інші менш популярні середовища.

Таблиця 1.2. Результати аналізу платформ

Платформа	Наявність універсальних додатків	Мова програмування		Середовище
Android	+/-	Java	C#, C++	Android Studio, Eclipse+SDK	Xamarin Studio, QtCreator
iOS	+	Objective-C		Xcode
Windows/Windows Phone	+	Javascript		Visual Studio

Огляд технологій побудови серверної сторони

Серверна частина – важлива складова будь-якого успішного сервісу. Наявність швидкісного сервісу дозволить користувачеві на стороні клієнта швидше та якісніше працювати, отримувати інформацію. В даний момент існує декілька технологій побудови серверних частин додатків:

«Сервер удома». Для забезпечення роботи такого серверу розробник повинен встановити свій власний сервер, самотужки закупивши для нього потрібні компоненти, встановивши потрібне програмне забезпечення, налаштувавши та запрограмувавши на правильну роботу. Перевагою такого підходу є повна контрольованість та цілодобовий доступ до серверу. В будь-який момент розробник може змінити компонент серверу, інсталювати оновлення програмного забезпечення. Але у такого підходу є декілька очевидних недоліків. По-перше, розробник не може гарантувати професійне встановлення серверу у спеціальному місці – серверній. Такий сервер може знаходитись будь-де, навіть біля відкритого джерела води. По-друге, сервер можуть обслуговувати непрофесіонали. Ці два фактори можуть привести до того, що сервер може зупинити роботу і, що гірше, вийти з ладу, а це – тимчасове припинення роботи і клієнтської частини також. Ще одна проблема – це проблема технічного плану. Так звана «проблема харду» полягає в тому, що сервер повинен надавати безперебійний доступ до інформації, що на ньому зберігається. Кількість користувачів на успішному проекті збільшується кожен день, а отже треба кожен день збільшувати пропускну можливість цього серверу. Вихід один – купувати компоненти серверу «із запасом». Це створює додаткові проблеми розробнику, який повинен вираховувати кількість користувачів наперед. Фінансова сторона цієї проблеми також негативна – на ранніх етапах проекту треба купувати дороге обладнання, не маючи достатнього фінансування. Графічно «проблему «проблему харду» можна відобразити на рис.1.2

Рис. 1.2. «Проблема харду»

Хостінг. Наразі дуже популярний спосіб розміщення серверу. Суть полягає в тому, що розробник користується послугами компанії, що надає йому виділений сервер. Ці послуги платні та виплачуються кожен місяць/рік, але існують безкоштовні тарифні плани, які, втім, є ознайомчими і не підходять до серйозного сервісу. Перевагами над власним сервером є професійне встановлення та обслуговування серверів. Якщо сервер вийшов з якихось причин з ладу, працівники компанії швидко усунуть несправність. Недоліком є часткова неконтрольованість – розробник не зможе інсталювати оновлення програмного забезпечення самостійно. Також актуальною залишається згадана раніше «проблема харду» з додатковими нюансами – у розробника тепер є тарифні плани з різною ціною і різними технічними можливостями серверу. Якщо серверу не буде вистачати максимального тарифного плану – треба домовлятися з компанією задля забезпечення додаткових потужностей.
Хмарні технології. В даний час цей спосіб розміщення серверу швидко набирає популярність. Виділяють чотири типи різних хмар:

Приватна хмара (англ. private cloud) - це хмарна інфраструктура, яка призначена для використання виключно однією організацією, що включає декілька користувачів (наприклад, підрозділів). Приватна хмара може перебувати у власності, керуванні та експлуатації як самої організації, так і третьої сторони (чи деякої їх комбінації).
Публічна хмара (англ. public cloud) - це хмарна інфраструктура, яка призначена для вільного використання широким загалом. Публічна хмара може перебувати у власності, керуванні та експлуатації комерційних, академічних (освітніх та наукових) або державних організацій (чи будь-якої їх комбінації). Публічна хмара перебуває в юрисдикції постачальника хмарних послуг.
Громадська хмара (англ. community cloud) - це хмарна інфраструктура, яка призначена для використання конкретною спільнотою споживачів із організацій, що мають спільні цілі (наприклад, місію, вимоги щодо безпеки, політику та відповідність різноманітним вимогам). Громадська хмара може перебувати у спільній власності, керуванні та експлуатації однієї чи більше організацій зі спільноти або третьої сторони (чи деякої їх комбінації). Така хмара може фізично знаходитись як в, так і поза юрисдикцією власника.
Гібридна хмара (англ. hybrid cloud) - це хмарна інфраструктура, що складається з двох або більше різних хмарних інфраструктур (приватних, громадських або публічних), які залишаються унікальними сутностями, але з’єднанні між собою стандартизованими або приватними технологіями, що уможливлюють переносимість даних та прикладних програм (наприклад, використання ресурсів публічної хмари для балансування навантаження між хмарами).

Декілька організацій створюють спеціальні операційні системи, що містять безліч функцій для спрощеного доступу до даних у хмарі. Також до таких функцій відносяться push-нотифікація, створення хмарних віртуальних машин, хостінг сайтів та інше.

ВИСНОВКИ ДО РОЗДІЛУ

В результаті проведеного в розділі аналізу ринку мобільних додатків в усіх популярних магазинах програм було виявлено, що додатків для читання Конституції України існує дуже мало, а для платформи Windowsвони відсутні взагалі. Також в усіх існуючих додатках присутня одна із нагальних проблем: або відсутність розділу «Вибране», або незручність його використання.

Був проведений аналіз існуючих мобільних операційних систем, для яких можна розробляти додатки, а також можливості створення універсальних додатків для кожної з розглянутих платформ. Було досягнуто висновку, що усі популярні платформи мають інструменти для створення додатків універсального типу, причому кожен із них має свої переваги і недоліки.

Також у розділі був проведений аналіз щодо серверної частини – був розглянутий кожен тип серверу за розміщенням та за публічністю.

ВИБІР РІШЕНЬ ДЛЯ СТВОРЕННЯ ДОДАТКУ ТА РОЗРОБКА ЙОГО СТРУКТУРИ
1. Вибір платформ для створення додатку

Серед усього різноманіття платформ для створення функціональних додатків після процесу аналізу існуючих рішень необхідно вибрати ті, які якнайбільше задовольняють потреби розробника. Для створення додатку «Конституція України» необхідно вибрати платформи:

Цільова операційна система – та ОС, користувачі якої зможуть користуватись розроблюваним додатком.
Інструменти програмування – це, насамперед, середовище розробки; також сюди входять усі рішення, що допомагають безпосередньо у процесі розробки.
Інструменти БД – вибір місця перебування та збереження інформації, з якою буде працювати додаток.

Вибір цільової операційної системи

Перед розробкою треба визначитись, для якої операційної системи буде створюватись додаток. Для такого рішення необхідно керуватися власними навичками, популярністю платформи, наявністю конкуруючих рішень. З таблиці 1.1. першого розділу можна зробити аналіз доцільності розробки на ту чи іншу платформу. Опираючись на дані про операційні системи та аналіз вимог до розроблюваного додатку можна дійти висновку, що найдоцільніше розробляти додаток «Конституція України» для операційних систем Windows та Windows Phone. Останні версії цих систем – Windows 8.1 та Windows Phone 8.1. Розробляти додаток для молодших версій цих систем немає сенсу, так як в більш молодших версіях не підтримується створення універсальних додатків для обох платформ, що є найважливішою вимогою до розроблюваного додатку. Зворотня сумісність з більш старими операційними системами не підтримується.

Важливо наголосити, що для платформи Windows буде розроблений додаток не формату .exe, а формату .appx. Основна різниця між цими форматами полягає в тому, що .exe-застосунок запускається у віконному середовищі і є найкращим рішенням для роботи з мишею та ідеальним інструментом для створення контенту, а .appx-застосунок запускається у спеціальному touch-орієнтованому середовищі, що дозволяє запускати повноекранні додатки із спеціальним доступом до системи. Такі додатки створюються з унікальним дизайном, що полегшує споживання контенту, насамперед – інформації.

Додаток для Windows 8.1 та Windows Phone 8.1 повинен створюватись по канонам Modern UI. Стиль Modern UI заснований на принципах дизайну швейцарського стилю. Основними принципами Modern UI є акцент на гарній типографіці і великому тексті, який відразу кидається в очі. Основні принципи такого дизайну:

Легкий, простий, відкритий, швидкий (безжалісне спрощення). Спрощення повинно стосуватися не тільки інтерфейсу, який повинен максимально позбуватись усіх об’ємних елементів, а також градієнтів та інших візуальних ефектів, що не стосуються споживання інформації, а також і сам додаток повинен бути максимально спрощений – там, де у традиційної програми була нагромадження меню, у новому додатку повинно бути елегантне та компактне рішення(рис 2.1).

Рис.2.1. Меню програми OneNote 2013 – Ribbon-інтерфейс та меню програми OneNote у Windows 8.1 – кільцеподібне меню з основними функціями.

Контент. Користувач повинен приділяти увагу лише контенту. Інтерфейс, як зазначалося вище, повинен позбутись усіх елементів, що перешкоджають або не сприяють споживанню інформації (рис 2.2).

Рис. 2.2. Справа – типовий інтерфейс Modern UI. Користувач сфокусований на полях вводу інформації. Зліва – довільний інтерфейс. Увага розсіюється на непотрібні елементи інтерфейсу.

Типографіка. Необхідне використання шрифтів одного сімейства, але різної форми для подання структурованої інформації. В якості основного шрифту використовуються шрифти з сімейства шрифтів Segoe, розробленого Стівом Меттсон з Agfa Monotype та ліцензованого Microsoft. Для Windows Phone було розроблено сімейство шрифтів «Segoe WP». Для Windows 8 також була створена спеціальна версія з тією ж назвою Segoe UI. Всі ці шрифти в основному відрізняються тільки незначними деталями. Найбільш очевидні відмінності між Segoe UI і Segoe WP видно в цифрових символах. Версія Segoe UI, використовувана в Windows 8, схожа на Segoe WP . Символи з помітним друкарськими змінами в цій версії включають 1, 2, 4, 5, 7, 8, а також I і Q.
Рух.Велику роль відіграє анімація. Microsoft рекомендує плавні переходи і взаємодію з користувачем на основі реальних рухів (таких як натискання або переміщення). Це створює у користувача враження «живого» і чуйного інтерфейсу з «доданим відчуттям глибини».
По-справжньому цифровий. Існує два типи дизайну – іконографічний та інфографічний. Принцип іконографічного дизайну полягає у перенесенні дизайну реальних об’єктів у операційну систему. Такий принцип використовується в операційних системах AndroidтаiOS (рис 2.3). Так, наприклад, інтерфейс додатку для читання книжок для iOSзображується у вигляді книжкової полиці.

Рис.2.3. Приклади використання іконографічного дизайну.

У Windowsта WindowsPhoneвикористовується інфографічний стиль, головним у якого є подання інформації, а не перенесення об’єктів реального світу. Саме тому і було обране таке сімейство операційних систем як цільове для створення додатку, що надає доступ до Конституції України.

Перевагою створення додатку для Windows8.1та WindowsPhone8.1є також використання цими платформами технології WindowsRuntime.WindowsRuntime,або WinRT – це нова (станом на 2011 рік) модель програмування від Microsoft, що є основою для розробки додатків в стилі Метро в новій операційній системі Windows 8.1 та WindowsPhone8.1. WinRT підтримує розробку на C++ ( звичайно з використанням розширення мови Component Extensions, C++/CX ) , керованих мовах C # і VB.NET, а також JavaScript.

WinRT по суті є API на основі технології COM. Через свою COM- подібної основи, WinRT дозволяє відносно легко звертатися до нього з різних мов програмування, як це відбувається в COM, але це, по суті, некерований, рідний API. Визначення API зберігаються в .winmd файлах, закодованих у форматі метаданих ECMA 335, який використовується в .NET з деякими змінами. Цей загальний формат метаданих дозволяє значно зменшити накладні витрати при виклику WinRT з .NET додатків в порівнянні з P/Invoke, маючи при цьому набагато простіший синтаксис. Нова мова C++/CX (Component Extensions), який запозичує деякі елементи синтаксису з C++/CLI , дозволяє створювати і використовувати WinRT - компоненти з меншою кількістю видимої для програміста роботи порівняно з класичним програмуванням COM в C++, і в той же час накладає менше обмежень у порівнянні з C++/CLI на змішання типів. Звичайний С++ (з COM- специфічними вимогами) також може бути використаний для програмування з компонентами WinRT. Це можливо за допомогою нової бібліотеки шаблонів Windows Runtime C++ Template Library (WRL), яка аналогічна за своєю метою того, що бібліотека ATL забезпечує для COM. Документація MSDN проте рекомендує використовувати C + + / CX замість WRL.

Також перевагою створення додатку для Windows є можливість глибокої інтеграції в операційну систему за допомогою «чудо»-кнопок (рис 2.4) та живих тайлів (live tiles) (рис 2.5)

Рис. 2.4. «Чудо»-кнопки (справа)

Рис. 2.5. Live Tiles

«Чудо»-кнопки допомагають розробнику інтегрувати додаток в операційну систему чотирма способами:

Пошук (рис 2.6)

Рис 2.6. Пошук

Даний метод інтеграції дозволяє користувачу через стандартне вікно пошуку системи шукати важливу інформацію в додатку. У розробника є можливість також видавати користувачеві підказки вводу.

Поділитися (рис 2.7)

Рис 2.7. Поділитися

Даний метод інтеграції дозволяє користувачу через стандартне вікно поділитися інформацією з додатку у інші програми, які це підтримують. Наприклад, посиланням з браузера можна поділитися у програму Facebook без запуску цього додатку та копіювання посилання.

Пристрої (рис 2.8)

Рис 2.8. Пристрої

Даний метод інтеграції дозволяє користувачу через стандартне вікно передати інформацію на інші підключені пристрої. Наприклад, програвання фільму на підключеному телевізорі або можливість передачі зображення на другий монітор.

Налаштування (рис 2.9)

Рис. 2.9. Налаштування

Даний метод інтеграції дозволяє користувачу через стандартне вікно змінити налаштування програми.

Перевагою саме такої інтеграції через спеціальні кнопки є те, що користувач при бажанні змінити налаштування додатку або пошукати інформацію не повинен шукати відповідну кнопку чи сторінку, досить тільки визвати панель із «чудо»-кнопками та обрати дію.

Живі тайли допомагають додатку взаємодіяти з користувачем, видаючи на іконці програми важливу інформацію, оновлюючи її через заданий проміжок часу. Наприклад, додаток, що дозволяє переглядати погоду, може транслювати погоду наразі, а додаток для прослуховування музики – поточну композицію.

Вибір інструментів розробки

Так як цільовою платформою для розробки є сімейство операційних систем Windows та Windows Phone, доцільно використовувати «рідні» інструменти для розробки – Visual Studio 2013, що дозволяє створювати універсальні додатки для вибраних платформ. Основною мовою програмування доцільно використовувати С#.

Вибір інструментів БД

Серед усіх варіантів розміщення бази даних було обрано варіант розміщення у хмарі Azure. Переваги такого рішення були розглянуті у підпункті 1.4.3. Windows Azure повністю реалізує дві хмарні моделі - платформи як сервісу (Platform as a Service, PaaS) та інфраструктури як сервісу (Infrastructure as a Service, IaaS). Працездатність платформи Windows Azure забезпечує мережа глобальних дата-центрів Microsoft.

Основні особливості даної моделі:

оплата тільки спожитих ресурсів;
загальна, багатопотокова структура обчислень;
абстракція від інфраструктури.

В основі роботи Microsoft Azure лежить запуск віртуальної машини для кожного екземпляра додатка . Розробник визначає необхідний обсяг для зберігання даних і необхідні обчислювальні потужності (кількість віртуальних машин) , після чого платформа надає відповідні ресурси. Коли первісні потреби в ресурсах змінюються , відповідно до нового запитом замовника платформа виділяє під додаток додаткові або скорочує невикористовувані ресурси дата -центру.

Windows Azure як PaaS забезпечить не тільки всі базові функції операційної системи, але й додаткові: виділення ресурсів на вимогу для необмеженого масштабування, автоматичну синхронну реплікацію даних для підвищення відмовостійкості, обробку відмов інфраструктури для забезпечення постійної доступності та багато іншого.

Windows Azure також реалізує інший тип сервісу - інфраструктуру як сервіс. Модель надання інфраструктури (апаратних ресурсів) реалізує можливість оренди таких ресурсів, як сервери, пристрої зберігання даних та мережеве обладнання. Управління всією інфраструктурою здійснюється постачальником, споживач управляє тільки операційною системою і встановленими додатками. Такі сервіси оплачуються за фактичним використанням і дозволяють збільшувати або зменшувати обсяг інфраструктури через спеціальний портал, що надається постачальниками. У даній сервісній моделі можуть бути запущені практично будь-які додатки , встановлені на стандартні образи ОС.

У доступній відразу галереї образів доступні образи наступних операційних систем : Windows Server, OpenSUSE, CentOS, Ubuntu, SUSE.

Практично всі сервіси Microsoft Azure мають API, побудоване на REST, що дозволяє розробникам використовувати « хмарні» сервіси з будь операційною системи, пристрої і платформи.

Microsoft Azure надає набір сервісів , що покривають широкий спектр сценаріїв:

Cloud Services :

Web-роль - веб-ролі в Microsoft Azure мають особливе призначення: надання виділеного веб-сервера служб IIS для розміщення інтерфейсних веб-додатків.
Worker-роль - додатки, розміщені в робочих ролях, можуть виконувати асинхронні, тривалі або безперервні завдання незалежно від дій користувачів.
Web Sites - веб-сайти підтримують ASP.NET, Java, Node.js або PHP( або CMS - WebMatrix, Joomla, Drupal, WordPress, DotNetNuke, Umbraco тощо) і розгортати за секунди з використанням FTP, Git, TFS, Mercurial і Dropbox . Є можливість безкоштовного використання з деякими обмеженнями. За замовчуванням веб - сайти знаходяться в стані Free, тобто потужності діляться між веб- сайтами, але при необхідності можна збільшити кількість примірників і перевести веб-сайт в режим резервування ресурсів. З червня 2013 сервіс Web Sites офіційно підтримує користувальницькі сертифікати SSL (раніше підтримувалися тільки сертифікати , пропоновані Microsoft) як за IP- адресою, так і на базі SNI.

Data Management - нереляційні сховища даних: таблиці , диски , черги , зберігання двійкових об'єктів + реляційне сховище даних у вигляді SQL Database.

Таблиці - сховище таблиць використовується додатками, які зберігають великі обсяги даних з додатковими вимогами до структурування. У таблиці зберігаються структуровані дані, між якими не встановлюються відносини .
Черги - черги забезпечують надійний і безперервний обмін повідомленнями між додатками.
Блоб - сховище BLOB-об'єктів - це найпростіший спосіб зберігання великих обсягів неструктурованих текстових або двійкових даних, таких як відео, музичні файли та зображення.
SQL Database - реляційна база даних - це високодоступна масштабована хмарна служба бази даних, побудована на основі технологій SQL Server.
SQL DataSync - хмарна служба синхронізації даних, що забезпечує як односпрямовану, так і багатоспрямовану синхронізацію. Служба DataSync дозволяє легко обмінюватися даними між SQL в Azure і локальними базами даних SQL Server, а також між декількома базами даних SQL Databases (SQL Azure);
Backup - цей сервіс пропонує можливість організації захищеної інфраструктури збереження резервних копій Windows Server в хмарі.

Performance :

Content Delivery Network - мережа кешуючих серверів (мережа CDN) підвищує продуктивність додатків шляхом кешування контенту ближче до клієнтів і користувачам, наприклад, мережа CDN дозволяє доставляти фрагменти мультимедійних файлів для динамічного адаптивного відтворення мультимедіа поверх HTTP -контенту.
Caching - розподілений кеш - розподілений кеш в пам'яті, за допомогою якого замість повільного дискового сховища додатка отримують високошвидкісний доступ до даних, що зберігаються в оперативній пам'яті, з можливістю масштабування;
Media Services - служби мультимедіа включають в себе хмарні версії багатьох існуючих технологій платформи мультимедіа Microsoft і багатьох партнерів, в тому числі для перегляду, кодування, перетворення формату і захисту контенту, а також потокової передачі за запитом і в реальному часі.
Mobile Services - пропонує хмарну інфраструктуру для всіх популярних мобільних платформ: Windows 8, Windows Phone, iOS і Android. На основі сервісу можна побудувати хмарний бекенд, на який перенести завдання по зберіганню даних, аутентифікації і Push-повідомлень. Підтримується Xamarin.

Identity - служба ідентифікації забезпечує управління посвідченнями та доступом до додатків , за допомогою служби Microsoft Azure Active Directory (колишній Access Control Service ) можна забезпечити єдиний вхід , підвищену безпеку і просте взаємодія з уже розгорнутими в Active Directory додатками , а також виконати інтеграцію з іншими провайдерами аутентифікації ( Live ID , Google , Facebook і т. п.).

Connectivity :

Messaging :

Service Bus - інтеграційна шина надає можливості ретрансляції і безпечного обміну повідомленнями і дозволяє створювати розподілені і слабкозв'язані додатки в хмарі, а також гібридні додатки, розміщені одночасно в приватних і загальнодоступних хмарних службах.
BizTalk Services - сервіс, який призначений для вирішення завдань інтеграції різнорідних оточень на рівні підприємства і хмари, пропонуючи можливості Business-to -Business і Enterprise Application Integration взаємодій.

Networking :

Virtual Network - сервіс для з'єднання хмарних інфраструктур з локальними методом Site-To-Site VPN і Point-To-Site VPN.
Traffic - диспетчер трафіку забезпечує балансування навантаження по вхідному трафіку між декількома розміщеними службами Windows Azure незалежно від того, чи працюють вони в одному центрі обробки даних або розподілені по всьому світу.

Так як у аналізі вимог стоїть завдання розробити мобільний додаток з використанням доступу до даних, тому слід розглянути Mobile Services та SQL Databases.

Windows Azure SQL Databases - це хмарний сервіс від корпорації Microsoft, що надає можливість зберігання і обробки реляційних даних, а також генерації звітності. Надає функціональність для різних сценаріїв синхронізації даних (локальна інфраструктура <=> хмара , хмара <=> хмара).

Windows Azure SQL Databases заснований на Microsoft SQL Server , але надає тільки підмножина типів даних. Підтримуються основні типи: точні і приблизні числа, символьні рядки (у тому числі Юнікод), дата і час, просторові, двійкові та інші типи даних.

Використовується заснований на XML формат для передачі даних. Так само як і Microsoft SQL Server , Windows Azure SQL Databases використовує T- SQL в якості мови запитів. Потоку табличних даних (TDS) використовується як протокол для доступу до сервісу через Інтернет.

Користувач може посилати Transact-SQL запити за протоколом TDS до сервісу Windows Azure SQL Databases, і це ж дозволяє додаткам використовувати Windows Azure SQL Databases так , як вони використовують локальний SQL Server. Однак, оскільки Windows Azure SQL Databases є сервісом, його адміністрування має свої особливості. На відміну від адміністрування локального SQL Server , Windows Azure SQL Databases розділяє логічний і фізичний аспекти адміністрування. Клієнт продовжує адмініструвати БД, управляти логінами, користувачами і ролями, однак про обладнання піклується Microsoft. В результаті, Windows Azure SQL Databases надає масштабований багатокористувацький сервіс баз даних з високим ступенем доступності, розширюваності, безпеки і самовідновлення.

Mobile Services – це технологія, що входить у Windows Azure і дозволяє розробнику створювати цілий хаб з управління мобільним додатком. Можливості такої технології:

API – існує можливість створення API для доступу до БД чи push notification. В такий спосіб можна значно розширити можливості Mobile Services.
Push Notification – доступ до оповіщення клієнтів або множини клієнтів з важливою інформацією (наприклад, нове повідомлення).
Створення таблиць. Таблиці використовується для зберігання великих обсягів даних з додатковими вимогами до структурування. У таблиці зберігаються структуровані дані, між якими не встановлюються відносини.
Служба ідентифікації, що дозволяє відкрити доступ в додатку до аутентифікації через популярні соціальні мережі в один клік (як для розробника, так і для клієнта) без необхідності реєстрації на сторонніх ресурсах.

ВИСНОВКИ ДО РОЗДІЛУ

У даному розділі було вибрано інструменти та засоби створення додатку. З-поміж усіх можливих варіантів було обрано Windows- та .NET-орієнтовані рішення, так як якість та взагалі присутність програм для читання конституції на цій платформі катастрофічно низька.

В якості серверної частини було обрано технологію від компаніїMicrosoft,що дозволяє легко розгортати та надавати інформацію за запитами. Перевагою такого вибору є простота, а також легка розширюваність – в будь-який момент можна створити додаток і для інших операційних систем, взагалі не змінюючи серверну частину.

В якості клієнтської операційної системи було обрано ОС Windows та Windows Phone. Цей вибір був зроблений, як наголошувалося раніше, через низьку присутність в магазині додатків програм, що дозволяють читати Конституцію України, а також через можливості інтеграції у саму операційну систему.

Проектування та створення додатку та серверної частини
1. Проектування та створення серверної частини
  1. Проектування та створення БД

Як наголошувалося раніше, база даних є невід’ємною частиною архітектури розроблюваного додатку. Перед тим, як створювати таблиці і наповнювати їх даними, необхідно провести аналіз вимог до цієї бази даних. Як говорилося раніше, в розділі 1, п.1.2 «Аналіз вимог до розроблюваного додатку», програма повинна являти собою універсальний додаток для платформ Windows та Windows Phone, тому треба зробити наголос на уніфікації збережуваних даних для того, щоб пристрої на цих операційних системах отримували однакові дані в однаковому вигляді. Але, як відомо, в останньому релізі цих ОС ядро систем стало спільним, і тому доступ до тих чи інших функцій задовольняється одними і тими ж інструментами. Тобто, якщо комп’ютер чи планшет під управлінням Windows правильно отримає інформацію від бази даних, то і смартфон під управлінням Windows Phone також отримає таку ж інформацію і обробить її також правильно.

Також в аналізі вимог наголошувалось на необхідності реалізації функції «Вибране», але зберігання вибраних статей необхідно проводити не на пристрої, а на серверній частині додатку. Через це необхідно створити спеціальну таблицю «Favorites»(англ. «вибране») для зберігання номерів статей, що читачі хочуть відкласти на прочитання. Але при такому варіанті вибрані статті будуть спільними, що не дуже сподобається користувачам. Тому необхідно реєструвати користувачів спеціальним ідентифікатором зі сторони клієнту, а також створити спеціальну таблицю БД «Users» (англ. «користувачі») для зберігання інформації про користувача. Такий спосіб, по-перше, дозволить клієнтам вибирати ті статті, які вони хочуть, персонально, а по-друге – легко проводити статистику активних користувачів додатку на стороні сервера.Так як є необхідність створювати організацію синхронізації вибраних статей між пристроями, яких у користувача може бути навіть більше двох, потрібно створити таблицю, що міститиме в собі список пристроїв, що потребують синхронізації.

Отже, необхідно створити такі таблиці:

Sections (англ. «розділи») – таблиці для зберігання розділів. Якщо відкрити Конституцію України у вільному доступі в мережі Інтернет чи в друкованому вигляді, стане зрозуміло, що розділи не містять у собі багато інформації, тому можна обмежитись всього двома полями:

ID–поле для зберігання номеру розділу відповідно до поточної редакції Конституції. Це поле є обов’язковим та первинним ключем.
Title–поле для зберігання тексту (або назви) відповідного розділу

Articles (англ. «статті») – таблиця для зберігання усіх розділів Конституції України. В цій таблиці вже більше даних, аніж у таблиці для зберігання розділів. Також необхідно створити зв’язок по зовнішньому між цією таблицею та таблицею для зберігання розділів для того, щоб знати до якого розділу відноситься та чи інша стаття. Отже, потрібно додати такі поля:

ID–поле для зберігання номеру статті відповідно до поточної редакції Конституції. Це поле є обов’язковим та первинним ключем.
Title–поле для зберігання назви поточної статті. Це поле є також обов’язковим, так як не буває статей без назви.
Text–поле, що служить для зберігання повного тексту поточної статті. Це поле, як і вище, є обов’язковим.
SectionID – поле, що зберігає ідентифікатор (в даному випадку номер) розділу, до якого належить. За допомогою цього поля забезпечується зв’язок між таблицями для зберігання статей та розділів – один до багатьох, тобто «один розділ – багато статей». Можливий також варіант, коли в розділі присутня всього одна стаття, але такої ситуації в поточній редакції Конституції України не існує.

Users (англ. «користувачі») – таблиця для зберігання усіх користувачів. Як зазначалось вище, необхідно ідентифікувати клієнтів однозначно для того, щоб правильно синхронізувати потім між пристроями користувачів вибрані статті. Так як додаток, згідно розділу 2, п.2.1 розробляється для операційних систем сімейства Windows, то таким однозначним ідентифікатором може бути так званий MicrosoftID, який можна легко отримати з будь-якого пристрою під управлінням ОС Windows/Windows Phone. Отже, полями для цієї таблиці будуть:

UserID–автоматично збільшуваний ідентифікатор запису користувача. Обов’язкове поле та первинний ключ для цієї таблиці.
MicrosoftID – як зазначалось вище, поле для зберігання унікального ідентифікатору користувача для правильної подальшої синхронізації вибраних статей. Дане поле не може бути первинним ключем таблиці, хоч і є унікальним, так як MicrosoftID–це випадковий набір цифр та літер, що представлений у строковому вигляді.Поле є обов’язковим.
FirstName – поле для зберігання інформації про ім’я користувача.
LastName–поле для зберігання інформації про прізвище користувача. Це поле, як і попереднє, служить для більш чемного та приємного спілкування з користувачем додатку.

«Device»(англ. «пристрій») – таблиця для зберігання інформації про пристрої користувачів. Створення необхідне для збору статистики про пристрої активних користувачів, правильної синхронізації вибраних статей та для забезпечення управління власними пристроями користувача з розділу налаштувань додатку. Така таблиця повинна містити такі поля:

DeviceID–автоматично збільшуваний ідентифікатор запису пристрою користувача. Обов’язкове поле та первинний ключ для цієї таблиці.
DeviceName – поле для зберігання імені пристрою для зрозумілого подання користувачеві в розділі налаштувань. Поле є обов’язковим.
UserID–поле для пошуку користувача пристрою. Є зовнішнім ключем, що забезпечує зв’язок між даною таблицею та таблицею користувачів. За допомогою цього зовнішнього ключа ці дві таблиці утворюють зв’язок «один до багатьох» - один користувач – один чи більше пристроїв.

Favorites(англ. «вибране») – спеціальна «транзитна» таблиця для зв’язку між таблицями користувачів та статей. Зв’язок між цими таблицями – «багато до багатьох» (одна стаття може бути у декількох користувачів в улюблених, а також один користувач може додати безліч статей у вибране). У цій таблиці нема власних значущих ключів, лише зовнішні ключі та ідентифікатор:

FavoritesID–автоматично збільшуваний ідентифікатор запису для пари користувач-стаття. Обов’язкове поле та первинний ключ для цієї таблиці.
UserID–поле для пошуку користувача, що додав відповідну статтю собі до вибраного. Є зовнішнім ключем, що забезпечує зв’язок між даною таблицею та таблицею користувачів.
ArticleID–поле для пошуку статті, що додав собі відповідний користувач. Є зовнішнім ключем, що забезпечує зв’язок між даною таблицею та таблицею статей.

Для зображення повної діаграми бази даних можна використати нотацію Crow's Foot. Дана нотація була запропонована Гордоном Еверестом (англ. Gordon Everest) під назвою Inverted Arrow («перевернута стрілка»), однак зараз частіше звана Crow's Foot («вороння лапка») або Fork («вилка»).

Згідно даної нотації, сутність зображується у вигляді прямокутника, що містить її ім'я, яке виражається іменником. Назва суті має бути унікальним в рамках однієї моделі. При цьому, ім'я сутності – це ім'я типу, а не конкретного екземпляра даного типу. Екземпляром сутності називається конкретний представник даної суті.

Зв'язок зображується лінією, яка пов'язує дві сутності, що беруть участь в відношенні. Ступінь кінця зв'язку вказується графічно, множинність зв'язку зображується у вигляді «вилки» на кінці зв'язку. Модальність зв'язку так само зображується графічно - необов'язковість зв'язку позначається кружком на кінці зв'язку. Іменування зазвичай виражається одним дієсловом в дійсного способу теперішнього часу: «Має», «Належить» і т. д.; або дієсловом з пояснюючими словами: «Включає в себе», і т.д. Найменування може бути одне для всієї зв'язку або два для кожного з кінців зв'язку. У другому випадку, назва лівого кінця зв'язку вказується над лінією зв'язку, а правого – під лінією. Кожне з назв розташовуються поруч з сутністю, до якої воно відноситься.

Атрибути сутності записуються усередині прямокутника, що зображує сутність і виражаються іменником в однині (можливо, з уточнюючими словами). Серед атрибутів виділяється ключ сутності - ненадлишкових набір атрибутів, значення яких в сукупності є унікальними для кожного екземпляра сутності.

Повна діаграма бази даних приведена в ілюстративному матеріалі.

Проектування та створення API

Розроблюваний мобільний додаток повинен мати зв’язок з базою даних. Цей зв’язок можна реалізувати напряму, але цей зв’язок буде сильно впливати на автономність мобільного пристрою та на кількість переданих даних. Також такий зв’язок є неймовірно нестабільним. Тому необхідно реалізувати деякий набір RESTAPI-функцій, що реалізують доступ до потрібних таблиць та записів до них в зручному поданні.

REST – це стиль архітектури програмного забезпечення для розподілених систем, таких як WWW, який, як правило, використовується для побудови веб-служб. Термін REST був введений у 2000 році Роєм Філдінгом, одним з авторів HTTP-протоколу. Системи, що підтримують REST, називаються RESTful-системами.

У загальному випадку REST є дуже простим інтерфейсом управління інформацією без використання якихось додаткових внутрішніх прошарків. Кожна одиниця інформації однозначно визначається глобальним ідентифікатором, таким як URL. Кожна URL в свою чергу має строго заданий формат.

Для того, щоб розробити API-функції в інтерфейсі Windows Azure, необхідно перейти на сторінку створеної мобільної служби та вибрати пункт «API». Далі створюється натисканням клавіші «Створити» нова функція у спеціальному вікні (рис 3.1), де можна задати:

Ім’я функції
Дозволи на проведення функцій.

Дозволи на проведення функцій – важлива складова приватностісерверноїчастини.Тут можна дозволити або заборонити доступ до тих чи інших функцій. Буває чотири типи дозволів:

Всі – загальний доступ до функції. Таку функцію можна викликати з будь-якого місця, програми ба навіть з браузеру.
Всі з ключем додатку – обмежений доступ. Таку функцію можна запустити тільки тоді, коли з запитом на сервер пересилається секретний ключ додатку. Такий метод можливий, якщо використовувати бібліотеки для доступу до Azure від компанії Microsoft та інші схожі бібліотеки.
Адміністратори – найбільш обмежений тип. Доступ до функцій тільки для адміністраторів серверної частини. Має місце при внутрішньосерверному використанні функції.
Тільки ті, що пройшли перевірку – дозвіл на користування функцією видається адміністраторами тільки довіреним користувачам, наприклад, при альфа- чи бета- тестуванні.

Рис. 3.1. Створення REST API-функції

Після створення функції можна побачити тестовий код для зрозумілості для операцій GET та POST (рис 3.2). Запити пишуться на мові JavaScriptз використанням технологій Node.js.

Рис. 3.2. Створена функція

Для розроблюваного додатку необхідно створити такі RESTAPI-функції:

getarticle–функція для отримання статті/статей. В якості параметра можуть виступати як і номери статей, так і номери розділів. Якщо параметром запиту є номер або номери розділів, то у відповідь надаються усі статті перерахованих розділів. Якщо параметром запиту є номера статей, то у відповідь надаються усі запитані статті масивом.
getsectiontitles–функція для надання списку назв розділів. Такий список необхідний при формуванні головного екрану додатку. Функція не приймає параметрів
getrandomarticle – функція для надання випадкової статті. Передає в якості відповіді одну статтю, що є випадковою.
searcharticle–функція для пошуку статті за ключовим словом/словами, переданими в якості параметру. Для цього на серверній стороні шукається у всіх статтях та розділах ключове слово. Статті, у яких присутнє це слово, видається масивом в якості відповіді.
registeruser – реєстрація користувача. Вхідні параметри – прізвище, ім’я та вищезгаданий MicrosoftID для однозначної ідентифікації користувача. Під час виконання функції перевіряється, чи є вже присутнім такий користувач в таблиці. Якщо ні – реєстрація, якщо так – пропуск.
registerdevice – функція для реєстрації пристрою. За своїм алгоритмом схожа на registeruser.
addtofavorites–функція для додавання статті у розділ «Вибране» поточного користувача. Перед додаванням перевіряється наявність статті у цього користувача.
getfavorites–функція для завантаження усіх статей, що були обрані поточним користувачем у розділ «Вибране»
getdevices–функція для завантаження усіх пристроїв користувача для подальшого відображення їх у розділі налаштувань.

Алгоритми функцій RESTAPIнаведені у ілюстративному матеріалі, а лістинг – у додатку А.

Проектування та створення додатку
1. Проектування додатку

Згідно аналізу вимог додатку, приведеному в розділі 1, п.1.2, розроблюваний додаток повинен виконувати наступний перелік функцій:

Відображення випадкової статті для того, щоб у користувача було бажання знову і знову заходити у додаток для вивчення нових статей
Відображення усіх розділів поточної редакції Конституції України
Відображення усіх статей поточної редакції Конституції України
Пошук по статтям
Підтримка функції «Вибране» з синхронізацією між пристроями користувача для більш зручного доступу до більш потребуваних статей
Забезпечення офлайн-доступу до повної поточної редакції
Відповідність усім специфікаціям дизайну операційної системи вибраної платформи

Для задоволення цих вимог необхідно розробити 3 сторінки з зв’язками для відображення інформації:

Головна сторінка додатку – сторінка для відображення заголовка (назви додатку), а також для випадкової статті та списку розділів Конституції. Область випадкової статті повинна відрізнятись від інших елементів сторінки візуально, але не привертати усю увагу.
Сторінка деталей – сторінка для відображення списку статей вибраного розділу та вибраної там же статті. Така сторінка повинна надавати легкий доступ до листання статей обома руками (особливо у випадку планшета).
Сторінка пошуку. Для вибраних платформ підходи в пошуку дещо різняться. В платформі Windows пошук можна вбудувати в додаток на рівні системи так, щоб потім можна було шукати у ньому через інтерфейс самої операційної системи (за допомогою вже згаданих в розділі 2 «чудо»-кнопок), тому створити необхідно лише сторінку результатів пошуку, в якій відображаються релевантні статі, а по натисканню на одну з них відкриється сторінка деталей з уже вибраною статтею. А от у платформі Windows Phone такого механізму в поточному релізі немає, тому необхідно реалізовувати динамічно змінювану сторінку, в якій спершу відображається поле для уведення слова/словосполучення, а потім після запиту відображаються знайдені статті. Після натискання, як і у платформі Windows, відкривається сторінка деталей з уже вибраною статтею.
Налаштування. Тут така ж ситуація, як і у попередньому випадку – платформою Windows передбачено створення механізму налаштувань на рівні ОС, а у платформі Windows Phone необхідно створювати самостійно. В налаштуваннях необхідно передбачити такі настройки:

Зміна теми оформлення – вибір між світлою та темною темами
Вмикання та вимикання офлайн доступу
Управління синхронізуємими пристроями
Управління аккаунтом

Графічно структуру розроблюваного додатку подано на рис.3.3.

Рис. 3.3. Структура додатку

Проектування механізму синхронізації додатку

Як зазначалось вище, розділ «Вибране» - це одна із ключових можливостей додатку, крім основної – читання Конституції, а також функція, яка вигідно відрізняє додаток від конкурентів. Саме тому необхідно розробити новий механізм синхронізації між пристроями, що візуально схожий на поточні рішення, пов’язані з синхронізацією даних між пристроями користувачів, для того, щоб не вводити користувача в сум'яття через незрозумілі алгоритми і методи. Ця синхронізація повинна бути максимально простою, але з тим максимально функціональною, надійною та швидкою.

Для синхронізації розділу «Вибране» необхідно розробити таблиці БД для зв’язку між користувачами та статтями, що було розроблено. Схема синхронізації наведена на рис. 3.4 і представляє собою діаграму послідовностей UML.

Розглянемо більш детально схему синхронізацію в рис 3.4. В схемі присутні два клієнти, які почергово приєднуються до серверу. На схемі показано життєвий цикл однієї статті, яка була додана у «Вибране» користувача. Послідовність така:

Користувач на першому пристрої читає статтю з розділу і вирішив додати статтю у «Вибране» для швидкого доступу з цього та іншого пристрою, який є у наявності у користувача. Після додавання додаток надсилає два повідомлення: одне на сервер для оповіщення його про додавання поточним користувачем поточної статті у «Вибране», друге – повідомлення самому собі для запам’ятання того, що стаття уже додана у «Вибране».
Користувач на першому пристрої читає статтю з розділу і вирішив додати статтю у «Вибране» для швидкого доступу з цього та іншого пристрою, який є у наявності у користувача. Після додавання додаток надсилає два повідомлення: одне на сервер для оповіщення його про додавання поточним користувачем поточної статті у «Вибране», друге – повідомлення самому собі для запам’ятання того, що стаття уже додана у «Вибране».

Рис 3.4. Схема послідовностей для синхронізації додатку.

Після успішного додавання статті у «Вибране» додаток отримує асинхронну відповідь із серверу про успішність додавання статті. З цього моменту користувач може побачити цю статтю у швидкому доступі з будь-якого пристрою, що і показано далі.
Користувач за якихось причин закриває додаток на першому пристрої та відриває на другому. Відразу ж додаток посилає асинхронний запит на завантаження вибраних статей.
Через деякий час додаток отримує відповідь із серверу з переліком статей, що знаходяться у «Вибраному» поточного користувача. В цьому переліку буде знаходитись і стаття, що була додана на кроках 1-3.

Створення додатку для вибраних платформ.

Для створення додатку, як зазначалося вище, використовується середовище програмування VisualStudio2013.Так як додаток з вимог повинен бути універсальним, створення додатку буде виглядати так (рис 3.5):

Рис 3.5. Створення додатку

Після натискання клавіші «ОК» буде створений додаток, структура якого подана на рис. 3.6.

Рис 3.6. Структура проекту

MainPage.xaml – файли головної сторінки додатку. Такий файл може бути винесений в спільну область обох додатків (App4.Shared), якщо дизайн додатків для обох платформ повторюється (така можливість надається завдяки спільним бібліотекам і спільному ядру). Додаток не може, як правило складатись лише з головної сторінки, тому наприкінці розробки таких файлів буде декілька. Також для цього файлу визначений так званий code-behind MainPage.xaml.cs – файл з кодом цієї сторінки. В цьому файлі можна присвоювати дані якомусь елементу управління на сторінці, змінювати їх властивості і т.і.
App.xaml – подібний файл до MainPage.xaml. Основна різниця полягає в тому, що цей файл не має візуального представлення – у xaml-файлі можуть зберігатися різноманітні стилі та шаблони, що потім використовуються при створенні дизайну сторінок додатку. Code-behind цього додатку є вхідною точкою програми – тут ініціалізується сам додаток, створюються допоміжні засоби, ініціалізується екран додатку і т.і.
Package.appxmanifest – файл-маніфест додатку. В цьому файлі можна:

Дозволяти/забороняти використання додатку в вибраних орієнтаціях пристрою
Змінювати назву додатку та ім’я розробника
Змінювати версію додатку
Змінювати мову за замовчуванням та список мов
Дозволяти/забороняти доступ до певних функцій та можливостей ОС.

References–посилання на бібліотеки з можливістю видалення та додавання.
Properties – властивості проекту.
Під час створення додатку необхідно виконати такі кроки:
Необхідно створити класи для зберігання завантажених статей та розділів. Такі класи називаються моделлю даних.
Необхідно створити класи, що дозволяють отримати дані із серверу та представити їх у зручному та правильному вигляді. Такі класи називаються джерелами даних. Для того, щоб отримати інформацію із серверу, існують два методи: звертання за спеціальним посиланням чи використання спеціальних бібліотек від Microsoft. Ось приклад такого звернення для отримання назв усіх розділів Конституції України:

MobileServiceClient mobileSevice = new MobileServiceClient(new Uri("https://constituion.azure-mobile.net/"), "hbGqLkMxUuZYZCpAxYYNqWwTddhvgw88");

jsonText = (await mobileSevice.InvokeApiAsync("getsectiontitles", System.Net.Http.HttpMethod.Get, null)).ToString();

Необхідно створити дизайн сторінки так, щоб він відповідав усім guidelines. Для цього додатку є доцільним використання спеціального елементу управління Hub, що дозволяє подати усю інформацію у вигляді галереї(рис 3.7)

Рис 3.7. Приклад додатку з Hub

Для створення дизайну необхідно, щоб вигляд додатку однієї платформи практично виглядав так само, як і для іншої платформи. Для цього необхідно використовувати спільні елементи управління.

Вигляд додатку, що відповідає вищезазначеним пунктам та вимогам до додатку, наведені у розділі 1, наведений на рис 3.8-3.11.

Рис. 3.8. Головний екран Windows-додатку

Рис. 3.9. Головний екран Windows-додатку

Рис. 3.10. Головний екран Windows Phone-додатку

Рис. 3.11. Головний екран Windows Phone-додатку

ВИСНОВКИ ДО РОЗДІЛУ

В даному розділі було розглянуті способи створення та проектування серверної та клієнтської частини, вже вибраних у розділі 2.

Було визначено усі таблиці БД в хмарі та їх призначення, створені усі функції RESTAPIдля доступу до цих даних. Після створення серверної частини будв розроблений додаток, що відповідає усім вимогам, висунутим у розділі 1.

Основний акцент у розробленому додатку був на інтеграції програми у операційну систему. Для цього бів реалізований інтерфейс «Поділитися» та дизайн програми відповідав усім вимогам до дизайну від компанії Microsoft.

Охорона праці
1. Загальна характеристика приміщення

Конституцією України, Законом України «Про охорону праці», іншими нормативно-правовими актами закріплюється державна політика в області охорони праці, що базується на пріоритеті життя і здоров'я працівників, повної відповідальності роботодавця за створення безпечних і здорових умов праці, соціального захисту працівників, повного відшкодування збитків особам, які потерпіли від нещасних випадків на виробництві та професійних захворювань, використання економічних методів управління, виконання нормативів охорони праці незалежно від форм власності і видів діяльності підприємства.

Робоче місце – це оснащений технічними засобами (засобами відображення інформації, органами управління, допоміжним обладнанням) простір, де здійснюється діяльність користувача (користувачів).

Організацією робочого місця називається система заходів щодо оснащення робочого місця засобами і предметами праці і розміщення їх у визначеному порядку.

Необхідним для цього дипломного проекту є проведення аналізу умов праці в приміщенні лабораторії, де розробляється система на ПЕОМ. Співробітники, працюючи в цій лабораторії, можуть стикатися з впливами таких факторів, як підвищений рівень шуму, відсутнє або погане природне чи штучне освітлення, підвищена чи низька температура середовища, а також ймовірність ураження струмом. В приміщенні встановлений комп’ютер Acer Aspire 7750G та один БФП Epson CX4900.

Кількість робочих місць – 1. План приміщення розміщено на рисунку 4.1. Характеристики приміщення подані в таблиці 4.1.

Таблиця 4.1. Характеристики приміщення

Довжина	4,5 м
Ширина	3,5 м
Висота	2,7 м
Загальна площа	15,75 м²
Загальний об’єм	42,525 м³
Кількість робочих місць	1
Площа на робоче місце	15,75 м²
Об’єм на робоче місце	42,525 м³
Кількість вікон	3
Кількість батарей центрального водного опалення	1

Згідно НПАОП 0.00-1.31-2010 та ДСанПіН 3.3.2.007-98 при створенні робочих місць з ПЕОМ має враховуватися відстань між робочими столами з відеомоніторами, яка має бути не менше 2 м, а відстань між бічними поверхнями відеомоніторів – не менше 1,2 м. Приміщення, де знаходяться комп'ютери, повинні бути достатньо просторими і добре провітрюваними. Мінімальна площа на одне робоче місце – 6 м², мінімальний об'єм – 20 м³.

Параметри приміщення задовольняють вимогам.

Кожне робоче місце включає в себе: системний блок, монітор, принтер та інші периферійні пристрої, які необхідні оператору. Під матричні принтери потрібно підкладати вібраційні килимки для гасіння вібрації та шуму.

Рис.4.1. Схема кімнати

Кожний програміст який працює за персональним комп'ютером, піддається впливу наступних факторів:

освітлення;
мікроклімат;
шум і вібрації;
електромагнітні випромінювання;
статична електрика та ін.

Освітлення приміщення

Необхідно провести розрахунок освітлення для кімнати площею 32 м ^2, ширина якої 4 м, довжина 8 м, висота - 3 м. Визничимо показники методом світлового потоку.

Для визначення кількості світильників визначимо світловий потік, падаючий на поверхню за формулою:

(4.1)

Де Fл - розраховується світловий потік, Лм; Е - нормована мінімальна освітленість; S - площа освітлюваного приміщення; Z - відношення середньої освітленості до мінімальної ; К - коефіцієнт запасу, враховує зменшення світлового потоку лампи в результаті забруднення світильників у процесі експлуатації ; n - коефіцієнт використання, (виражається відношенням світлового потоку, що падає на розрахункову поверхню, до сумарного потоку всіх ламп і обчислюється в частках одиниці; залежить від характеристик світильника, розмірів приміщення, фарбування стін і стелі, якi характеризуються коефіцієнтами відображення від стін (Р _С) і стелі (Р _П))_, значення коефіцієнтів Р _С і Р _П були зазначені вище: Р _С = 50%, Р _П = 75%. Значення n визначимо по таблиці коефіцієнтів використання різних світильників. Для цього обчислимо індекс приміщення по формулі :