Размещено на http://www.allbest.ru/

Міністерство освіти і науки України

Харківський національний університет радіоелектроніки

Факультет КОМП'ЮТЕРНІ НАУКИ

Кафедра ПРОГРАМНА ІНЖЕНЕРІЯ

АТЕСТАЦІЙНА РОБОТА (ПРОЕКТ)

Пояснювальна записка

БАКАЛАВР

Мобільний додаток підтримки ведення нотаток путівника TouristGames

Виконав: студент 4 курсу, групи ПІ-12-4

6.050103 Програмна інженерія

Дорожан С.В.

Керівник Широкопетлєва М.С.

Рецензент

Допускається до захисту

Зав. кафедри ___________ Дудар З.В.

2016 р.

Харківський національний університет радіоелектроніки

Факультет комп'ютерні науки

Кафедра програмна інженерія

Освітньо-кваліфікаційний рівень бакалавр

Напрям підготовки 6.050103 Програмна інженерія

ЗАТВЕРДЖУЮ:

Зав. кафедри ______________

(підпис)

«_____»________________ 20 ___ р.

ЗАВДАННЯ

НА АТЕСТАЦІЙНУ РОБОТУ (ПРОЕКТ)

Студентові Дорожану Сергію Валерійовичу

1. Тема роботи (проекту)_ Мобільний додаток підтримки ведення нотаток путівника TouristGames

___________________________________________________

затверджена наказом по університету від "_16_"__травня___2016 р. № __535Ст_______

2. Термін подання студентом роботи (проекту) ____09.06.2016_______________________

3. Вихідні дані до роботи (проекту) розробити мобільний додаток підтримки ведення нотаток путівника. Використовувати технології Java, Android SDK, Kotlin, Firebase, NoSQL, Google maps API.

4. 3міст пояснювальної записки (перелік питань, що потрібно розробити) вступ, аналіз користувальницьких і розробка функціональних вимог до програмного продукту, опис прийнятих проектних рішень, методи та алгоритми, що використовувались, структура бази даних, опис роботи застосування, тестування ПЗ та аналіз дослідної експлуатації. Додатки: а) слайди презентації, б) приклади програмних кодів, в) електронні матеріали до проекту на CD.

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

6. Консультанти розділів роботи (проекту)

Найменування розділу	Консультант (посада, прізвище, ім'я, по батькові)	Позначка консультанта про виконання розділу
		підпис	дата
Спец. частина	Ст. викл. Широкопетлєва М. С.

7. Дата видачі завдання “__18__” квітня 2016р.

КАЛЕНДАРНИЙ ПЛАН

№	Назва етапів дипломного проекту	Термін виконання етапів проекту (тиждень)	Примітка
1	Аналіз предметної галузі	18-04-16	Виконано
2	Розробка специфікації ПЗ	25-04-16	Виконано
3	Об'єктний аналіз поставленої задачі	28-04-16	Виконано
4	Створення коду програми	03-05-16	Виконано
5	Тестування і налагодження програми	12-05-16	Виконано
6	Підготовка пояснювальної записки:	15-05-16	Виконано
7	Підготовка презентації та доповіді	25-05-16	Виконано
8	Нормоконтроль, рецензування	03-06-16	Виконано
9	Попередній захист	06-06-16	Виконано
10	Занесення диплома в електронний архів	06-06-16	Виконано
11	Допуск до захисту у зав. кафедри	06-06-16	Виконано

Студент ___________________________________

Kepiвник роботи (проекту) ____________ ст.викл. Широкопетлєва М.С.

РЕФЕРАТ / ABSTRACT

Пояснювальна записка до роботи містить: 58 с., 23 рис., 1 табл., 3 дод., 20 джерел.

Метою роботи є проектування, розробка та тестування мобільного додатку підтримки ведення нотаток путівника TouristGames.

Методи проектування та розробки базуються на технологіях: Java, Android SDK, Kotlin, Firebase, NoSQL, Google maps API.

У результаті роботи здіи?снено програмну реалізацію мобільного додатку, який дає змогу полегшити процес обробки нотаток путівника, зробити його більш зрозумілим; проглянути список відвіданих місць на карті та дозволяє поділитися цими записами. Проаналізовані етапи подальшого розвитку додатку та оцінені його конкуренти.

JAVA, ANDROID, НОТАТОК, FIREBASE, KOTLIN, ПУТІВНИК, NOSQL.

The aim - the design, development and testing of an application for managing tourist notes.

Methods of designing and developing technologies based on: Java, Android SDK, Kotlin, Firebase, NoSQL, Google maps API.

Results - the analysis is performed and the program realization of an application that allows to facilitate the process of creating tourist notes, show visited places on the map and share notes. Evaluated stages of further development and the competitors of the system.

JAVA, ANDROID, NOTE, FIREBASE, KOTLIN, TOURIST, NOSQL.

ЗМІСТ

Вступ

1. Аналіз предметної області

1.1 Актуальність системи

1.2 Аналіз існуючих систем

1.3 Постановка задачі

2. Моделювання системи

2.1 Опис Use Сase діаграми

2.2 Опис діаграми компонентів

2.3 Опис діаграми послідовності

2.4 Опис діаграми розгортання

2.5 Опис NoSQL бази даних

3. Архітектура програмної системи та обрані технології

3.1 Загальні відомості про засоби розробки

3.2 Мова програмування Kotlin

3.3 Backend as a service

3.4 Патерн проектування MVP

3.5 Патерн ViewHolder

3.6 Патерн Adapter

3.7 Структури обміну даними

3.8 Опис SOLID

3.9 Git та Bitbucket

3.10 Методології розробки

4. Опис розробленої програмної системи

5. Тестування

5.1 Тестування мобільних пристроїв

5.2 Функціональне тестування

Висновки

Перелік посилань

Додаток А. Текст програми

Додаток Б. Слайди презентації

ВСТУП

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

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

Багато країн перейшли на так зване «інформаційне суспільство» [1], деякі - в процесі переходу, в залежності від факторів, що впливають на ту чи іншу частину населення. Все менше приділяється уваги друкованим виданням: вчені говорять про те, що через 30 років газети, журнали, книги зникнуть з прилавків.

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

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

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

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

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

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

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

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

Метою роботи є програмна реалізація мобільного додатку ведення нотаток путівника з використанням технологій та бібліотек Java.

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Актуальність системи

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

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

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

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

Надійність, масштабованість, гнучкість та легкість впровадження змін в програмній реалізації продукту теж є неабиякою перевагою системи, що розробляється. Передбачається наявність мобільного додатку, яка взаємодіє з сервісом Firebase, що надає хмарну NoSQL БД. Дані в базі даних Firebase зберігається у вигляді JSON. Даний сервіс надає потужний API для розробників, що дозволяє синхронізувати дані програми між клієнтами і зберігати їх в хмарі FireBase. Плюсами використання цієї технології є автоматичне масштабування додатку та функції безпеки користувачів - всі дані передаються через захищене з'єднання SSL з 2048-бітовим сертифікатом. Доступ до баз даних і перевірки контролюється на детальному рівні, використовуючи гнучкі security rules.

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

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

1.2 Аналіз існуючих систем

програмування проектування мобільний пристрій

В інтернеті є безліч туристичних програм призначених для створення нотаток. Розглянемо найбільш популярну програму у Playmarket, програма «Evernote» [2], головна сторінка якої наведено на рис. 1.1.



Рисунок 1.1 - Головна сторінка застосуванняEvernote

Головна сторінка відображає інформацію про записники. Реалізовано пошук стосовно створених записників. У кожного записника є список записів (рис. 1.2).

Рисунок 1.2 - Сторінка записника з записами

Також додаток має докладний опис запису у розгорнутому вигляді (рис. 1.3), який можна редагувати (до запису можна прикріпити мультимедійні файли окрім тексту) та поділитися через соціальні мережі.

Рисунок 1.3 - Сторінка з детальною інформацією

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

Також у Play market існує програма World Tourism[3]. Застосування має собі опис основних туристичних місць для кожної з країн, приклад тому головна сторінка (рис. 1.4) та сторінка з описом (рис. 1.5)



Рисунок1.4 - Головна сторінка застосування World Tourism

Рисунок 1.5 - Сторінка досягнень застосування World Tourism

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

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

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

1.3 Постановка задачі

У роботі необхідно спроектувати та реалізувати мобільний додаток, що дозволить управляти нотатками для путівника.

Необхідно забезпечити сервіс-орієнтовану архітектуру використовуючи існуючі BaaS та розробити клієнт для Android.

Вимоги до функціоналу:

— відображення країн та туристичних місць;

— відображення відвіданих туристичних об'єктів на карті;

— можливість авторизації;

— можливість створення та перегляд нотатків;

— можливість шарінгу туристичних місць;

— зручний інтерфейс користувача;

— перегляд кількості відвіданих місць;

— перегляд інформації користувача.

2. МОДЕЛЮВАННЯ СИСТЕМИ

UML є графічною мовою для візуалізації, опису параметрів, конструювання та документування різних систем, програм зокрема. Діаграми створюються за допомогою спеціальних CASE засобів, наприклад Rational Rose і Enterprise Architect. На основі технології UML будується єдина інформаційна модель. UML [4] дозволяє також досягти угоди в графічних позначеннях для подання загальних понять (таких як клас, компонент, узагальнення (generalization), об'єднання (aggregation) і поведінка) і орієнтована на проектування та архітектуру програмного продукту.

Будь-яка мова складається зі словника і правил комбінування слів для отримання осмислених конструкцій. Так, зокрема, влаштовані мови програмування, таким є і UML. Відмінною його рисою є те, що словник мови утворюють графічні елементи. Кожному графічному символу відповідає конкретна семантика, тому модель, створена одним розробником, може однозначно бути зрозуміла іншим, а також програмним засобом, що інтерпретує UML. Звідси, зокрема, випливає, що модель програмної системи, представлена ??на UML, може автоматично бути переведена на об'єктно орієнтовані мови програмування (такі, як Java, C++, VisualBasic), тобто, при наявності хорошого інструментального засобу візуального моделювання, що підтримує UML, побудувавши модель , ми отримаємо і заготовку програмного коду, що відповідає цій моделі.

Слід підкреслити, що UML - це саме мова, а не метод. Вона пояснює, з яких елементів створювати моделі і як їх читати, але нічого не говорить про те, які моделі і в яких випадках слід розробляти. Щоб створити метод на базі UML, треба доповнити його описом процесу розробки програмної системи.

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

2.1 Опис Use Case діаграми

Діаграми варіантів використання (use case diagrams) представляють собою графічне представлення взаємодії користувача і комп'ютерної системи. Кожен варіант використання охоплює деяку очевидну для користувачів функцію системи і вирішує деяку дискретну задачу користувача. Побудуємо діаграму виділивши при цьому основні дії користувача в системі та зв'язок користувача і системи загалом (рис. 2.1). Діаграма варіантів використання - діаграма, на якій відображені відносини, що існують між акторами і варіантами використання (прецедентами). Основна ідея Use Case-діаграми - надати узагальнений вид системи, що дає можливість замовнику, кінцевому користувачеві і розробнику спільно обговорювати функціональність і поведінку системи.



Рисунок 2.1 - Діаграма Use Case

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

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

- редагування персонального профіля;

- управління нотатками;

- шарінг нотатків;

- перегляд місць на карті.

2.2 Опис діаграми компонентів

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

Рисунок 2.2 - Component діаграма

На діаграмі зображені 2 основних компоненти:

- мобільний клієнт (Android 4.2+);

- back-end as a service (Firebase).

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

2.3 Опис діаграми послідовності

Діаграма послідовності (Sequence diagram) [5] відображає взаємодії об'єктів впорядкованих за часом. Зокрема, така діаграма відображає задіяні об'єкти та послідовність відправлених повідомлень між ними.

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

Рисунок 2.3 - Sequence діаграма

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

2.4 Опис діаграми розгортання

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

Рисунок 2.4 - Deployment діаграма

Сервіс Firebase буде розташований на серверах Google, що відповідатиме всім нефункціональним вимогам: безпека, швидкість, продуктивність та надає дуже зручний інтерфейс для користування та управління базами даних. Завдяки цим властивостям доступ до бази даних займатиме декілька секунд, що насамперед зручно для користувача системи.

Мобільний додаток заплановано розгорнути на пристроях з операційною системою Android версії 4.2 та вище. Також планується завантаження додатку до Google Play Market, що дозволить безпосередньо завантажувати додаток до свого мобільного маючи інтернет-з'єднання.

В даному розділі проведено аналіз та моделювання основних модулів системи. Розглянуто які класи необхідно застосовувати при роботі з даними сервісу та те, як система буде розгорнута.

2.5 Опис NoSQL бази даних

NoSQL - ряд підходів, спрямованих на реалізацію сховищ баз даних, що мають суттєві відмінності від моделей, що використовуються в традиційних реляційних СУБД з доступом до даних засобами мови SQL.

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

Інформація в SQL зберігається в таблицях, що в свою чергу уповільнює доступ до інформації. Схема бази даних зі зберіганням даних у вигляді «ключ-значення» наведена на рисунку 2.5:



Рисунок 2.5 - Схема бази даних

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

3. АРХІТЕКТУРА ПРОГРАМНОЇ СИСТЕМИ ТА ОБРАНІ ТЕХНОЛОГІЇ

3.1 Загальні відомості про засоби розробки

В якості основної мови розробки мобільного клієнта була обрана мова Java -- об'єктно-орієнтована мова програмування, випущена компанією Sun Microsystems у 1995 році як основний компонент платформи Java [6]. Зараз мовою займається компанія Oracle, яка придбала Sun Microsystems у 2009 році. Синтаксис мови багато в чому схожий на C та C++. У офіційній реалізації, Java програми компілюються у байт-код, який при виконанні інтерпретується віртуальною машиною для конкретної платформи. Oracle надає компілятор Java та віртуальну машину Java, які задовольняють специфікації Java Community Process, під ліцензією GNU General Public License.

Java має декілька характерних особливостей: простота, об'єктно-орієнтованість, надійність, безпека, незалежність від архітектури комп'ютера, високопродуктивність.

Мобільним клієнтом був вибраний Android, тому Java як не найкраще підійшла для написання коду. При використанні компонентів AndroidSDK [7] було вирішено використовувати набір бібліотек, який вже реалізує часткову функціональність. Такими бібліотеками являються: Google Maps API, Google Location API, що надають дані та сервіси для виявлення місцезнаходження на картах [8].

3.2 Мова програмування Kotlin

Крім Javaбуло прийняте рішення використовувати Kotlin (Котлін) - статично типізовану мову програмування, що працює поверх JVM і розробляється компанією JetBrains [9]. Деякі переваги мови:

- сумісність з Java;

- статичні гарантії коректності;

- швидкість компіляції;

- лаконічність.

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

Під час компіляції коду на статично типізованій мові відбувається безліч перевірок, що гарантують, що ті чи інші помилки не відбудуться під час виконання. Наприклад, компілятор Java гарантує, що об'єкти, на яких викликаються ті або інші методи, «вміють» їх виконувати, тобто що у відповідних класах ці методи реалізовані. На жаль, крім цієї дуже важливої властивості, Java майже нічого не гарантує. Це означає, що успішно скомпільовані програми завершуються з помилками часу виконання (викликають виняткові ситуації). Яскравим прикладом є нульове посилання, при якому під час виконання викликається виняток типу NullPointerException. Важливою вимогою до нової мови є посилення статичних гарантій. Це дозволить виявляти більше помилок на етапі компіляції і, таким чином, скорочувати витрати на тестування.

Статичні перевірки спрощують програмування, але уповільнюють компіляцію, і тут необхідно домогтися певного балансу. Досвід створення мов з потужною системою типів (найбільш яскравим прикладом є Scala) показує, що такий баланс знайти непросто: компіляція часто стає неприйнятно довгою. Взагалі, така характеристика мови, як час компіляції проекту, може здатися другорядною, однак в умовах промислової розробки, коли обсяги коду, що компілюється дуже великі, виявляється, що цей фактор дуже важливий - адже поки код компілюється, програміст часто не може продовжувати роботу. Зокрема, швидка компіляція є одним з важливих переваг Java в порівнянні з C++, і Kotlin зберігає ці переваги.

Відомо, що програмісти часто витрачають більше часу на читання коду, ніж на його написання, тому важливо, щоб конструкції, доступні в мові програмування, дозволяли писати програми коротко і зрозуміло. На жаль, суворі методи оцінювання мов з точки зору їх лаконічності розвинені досить слабо, але є непрямі критерії; один з них - можливість створення бібліотек, робота з якими близька до використання предметно-орієнтованих мов (Domain-Specific Language, DSL). Для створення таких бібліотек необхідна певна гнучкість синтаксису в сукупності з конструкціями вищих порядків; найбільш поширені функції вищих порядків, тобто функції, які беруть інші функції в якості параметрів.

3.3 Backend as a service

Backend as a service - модель забезпечення розробників різними інфраструктурними функціями, такими як хмарне сховище, інтеграція з соціальними мережами, пуш-повідомлення, управління користувачами і т.п. BaaS значно спрощує створення додатків, пропонуючи вже готові функції і можливості розробникам, залишаючи їм можливість зосередитися на функціоналі додатків.

Спочатку планувалося використати сервіс Parse, так як протягом останніх років набув найбільшої популярності на світовому ринку за рахунок своєї простоти використання та інтеграції з Facebook. На початку 2016 року було зупинено підтримку цього сервісу. До уваги бралися конкуренти: AWS Mobile Hub та Firebase. Перший сервіс дає можливість тестувати додатки на реальних пристроях в хмарі, має легку у користуванні консоль управління та швидку інтеграцію push-повідомлень, дозволяє вимірювати і аналізувати метрики використання і монетизації додатків для оцінки їх прибутковості.

AWS Mobile Hub дозволяє зберігати ресурси додатків, такі як файли мультимедіа, в хмарі, а також завантажувати і кешувати їх в додатку. Мережа доставки контенту забезпечує мінімальну затримку і високу швидкість передачі при наданні контенту користувачам.

Firebaseмає базу даних, яка змінюється в реальному часі і зберігає дані в JSON-форматі. Будь-які зміни в базі даних відразу синхронізуються між усіма клієнтами, або девайсами, які використовують одну і ту ж базу даних. Іншими словами, оновлення в Firebase відбуваються миттєво [10].

Разом зі сховищем, Firebase також надає призначену для користувача аутентифікацію, і тому всі дані передаються через захищене з'єднання SSL. Можна вибрати будь-яку комбінацію email і пароля для аутентифікації, будь то Facebook, Twitter, GitHub, Google, або щось інше.

Окрім AndroidSDK, у Firebase є SDK для iOS і JavaScript. Всі платформи можуть використовувати одну базу даних. ТакожFirebase з усіма цими функціями являється бюджетним рішенням в порівнянні з іншими.

Проаналізувавши бекенд-сервіси для розробки мобільних додатків, було прийнято рішення скористатися бюджетним, але не менш функціональним сервісом Firebase.

3.4 Патерн проектування MVP

MVP (Model View Presenter) -- патерн, що є похідним від відомого паттерна MVC (Model View Controller), стає все більш значущим при розробці Android додатків.

Шаблон MVP дозволяє відокремити рівень представлення від рівня логіки, для того що б поведінка програми не залежала від його конкретного зовнішнього вигляду. В ідеалі, використовуючи MVP ми доб'ємося того, щоб одна і та ж логіка могла мати зовсім різні, а головне взаємозамінні UI уявлення.

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

Шаблон проектування MVP поділяється на три частини: Model, View, Presenter (рис. 3.2)

Рисунок 3.2 - Схема MVP патерну

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

Як правило це activity, fragment або android.view, що містить посилання на presenter. В ідеалі, додавання presenter-а здійснюється за допомогою механізму впровадження залежностей, таких як Dagger [11], в іншому випадку в view повинен бути створений об'єкт presenter-а. Єдине, що view робитиме - це викликати методи presenter-а, кожен раз коли відбувається взаємодія з графічним інтерфейсом (натискання кнопок, свайпи і т.д).

У додатку з багаторівневої архітектурою, model є точкою доступу до даних або бізнес логіки. Можна розглядати model як постачальника даних для view.

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

3.5 Патерн ViewHolder

Суть шаблону ViewHolder - уникнути постійно шукати елементи в списку при його заповненні за допомогою методу findViewById (), який споживає чимало системних ресурсів. Для цього створюється спеціальний статичний внутрішній клас ViewHolder [12], який постійно містить посилання на потрібні елементи. Замість того, щоб постійно «смикати» findViewById (), це можна зробити один раз і зберегти посилання в ViewHolder (рис. 3.3)

Рисунок 3.3 - Приклад патерну ViewHolder

Патерн ViewHolder, за деякими даними, дозволяє збільшити продуктивність списку ListView на 15-20%, що є дуже актуальним для великих масивів даних [13]. Цей патерн має місце бути, тому що в основі головного екрану буде список з елементами - туристичними об'єктами, що може досягати великих обсягів контенту.

3.6 Патерн Adapter

Adapter необхідний для організації використання функцій об'єкта, недоступного для модифікації, через спеціально створений інтерфейс. Система підтримує необхідні дані і поведінку, але має невідповідний інтерфейс [14]. Найчастіше шаблон Адаптер застосовується якщо необхідно створити клас, що походить від визначеного або вже існуючого абстрактного класу (рис. 3.4)

Рисунок 3.4 - Схема патерну Adapter

Цей патерн необхідний для створення нестандартних списків у Android системі. Саме завдяки йому з'являється можливість кастомізувати об'єкти у списку та додати необхідний функціонал для їх відображення.

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

3.7 Структури обміну даними

Сьогодні прийнято використовувати REST - (скор. від англ. Representational State Transfer - «передача репрезентативного стану») - метод взаємодії компонентів розподіленого додатка в мережі Інтернет [15], при якому виклик віддаленої процедури являє собою звичайний HTTP-запит, а необхідні дані передаються як параметри запиту (рис. 3.5).

Рисунок 3.5 - Метод REST

У свою чергу HTTP -- протокол передачі даних, що використовується в комп'ютерних мережах. Назва скорочена від Hyper Text Transfer Protocol, протокол передачі гіпер-текстових документів.

HTTP -- протокол прикладного рівня, схожими на нього є FTP і SMTP. Обмін повідомленнями йде за звичайною схемою «запит-відповідь». Для ідентифікації ресурсів HTTP використовує глобальні URI. На відміну від багатьох інших протоколів, HTTP не зберігає свого стану. Це означає відсутність збереження проміжного стану між парами «запит-відповідь». Компоненти, що використовують HTTP, можуть самостійно здійснювати збереження інформації про стан, пов'язаний з останніми запитами та відповідями. Браузер, котрий посилає запити, може відстежувати затримки відповідей. Сервер може зберігати IP-адреси та заголовки запитів останніх клієнтів. Проте, згідно з протоколом, клієнт та сервер не мають бути обізнаними з попередніми запитами та відповідями, у протоколі не передбачена внутрішня підтримка стану й він не ставить таких вимог до клієнта та сервера.

Кожен запит/відповідь складається з трьох частин:

- стартовий рядок;

- заголовки;

- тіло повідомлення, що містить дані запиту, запитаний ресурс або опис проблеми, якщо запит не виконано.

Методу REST необхідно наступне:

- клієнт-серверна архітектура;

- сервер не зобов'язаний зберігати інформацію про стан клієнта;

- у кожному запиті клієнта повинно явно міститися вказівка про можливість кешування відповіді і отримання відповіді з існуючого кеша;

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

- уніфікований програмний інтерфейс сервера.

Завдяки використанню REST наш продукт набув таких якостей:

- надійність (за рахунок відсутності необхідності зберігати інформацію про стан клієнта, яка може бути загублена);

- продуктивність (за рахунок використання кеша);

- масштабованість;

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

- простота інтерфейсів;

- портативність компонентів;

- здатність еволюціонувати, пристосовуючись до нових вимог;

- легкість внесення змін.

Для зв'язку з сервісом на клієнті використовується класс «ServerData». Методи цього класу конструюють URL для зв'язку по HTTP-протоколу, що в залежності від необхідної інформації формують вірне посилання. Механізм взаємодії з сервером працює на основі API, що надає Firebase. Також методи, що належать даному класу виконують запити та отримують відповіді за допомогою контейнера даних формату JSON.

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

3.8 ПринципиS.O.L.I.D

S (The Single Responsibility Principle) - принцип єдиної відповідальності. Іншими словами, необхідно змінювати і підтримувати клас тільки для однієї мети. Якщо це модель класу, то вона повинна строго являти собою одну функцію або дію. Це дасть можливість вносити зміни в майбутньому, без впливу змін на інші об'єкти.Кожен об'єкт повинен мати один обов'язок і бути повністю інкапсульований в клас. Всі його сервіси повинні бути спрямовані виключно на забезпечення цього обов'язку.SRP - це спосіб пошуку прихованих абстракцій, досить складних, щоб їм відвели окрему іменовану сутність і сховали в їхніх надрах всі деталі. Поділ класів на складові диктується не «осями змін», а здоровим глуздом і спробою впоратися з наростаючою складністю системи.

O (The Open-Closed Principle) - принцип відкритості та закритості. Програмні сутності (класи, модулі, функції і т.п.) повинні бути відкриті для розширення, але закриті для зміни. Це означає, що класи повинні бути розроблені таким чином, щоб для підлаштування класу до даних конкретних умов застосування, досить розширити клас і перевизначити деякі функції. Таким чином, система повинна бути гнучкою і працювати в умовах, що змінюються без зміни вихідного коду. Закритість модулів означає стабільність інтерфейсу і можливість використання класів/модулів клієнтами. Відкритість модулів означає можливість внесення змін у поведінці, шляхом зміни реалізації або ж шляхом перевизначення поведінки в спадкоємцях. Реалізується за допомогою інкапсуляції, яка дозволяє змінювати реалізацію без зміни інтерфейсу і за допомогою наслідування, що дозволяє замінити реалізацію, яка не зачепить існуючих клієнтів базового класу.

L (The Liskov Substitution Principle) - принцип заміщення Барбари Лісков. Замість базового типує можливість підставити будь-який його підтип. Спадкування і поліморфізм є ключовим інструментом розробника при боротьбі зі складністю, для отримання простого і розширюваного рішення. Принцип підстановки Лісков покликаний допомогти в коректній реалізації успадкування, а також відмовитися від спадкування, якщо його коректна реалізація неможлива. Якщо подивитися на опис принципу підстановки в працях Барбари Лісков, то можна виявити, що воно повністю засноване таких поняттях, як передумови, постумови і інваріанти. Іншими словами, опис цього принципу повністю заснований на принципах проектування за контрактом:

- похідні класи не повинні посилювати передумови (не повинні вимагати більшого від своїх клієнтів);

- похідні класи не повинні ослаблювати постумови (повинні гарантувати, як мінімум те, що і базовий клас);

- похідні класи не повинні порушувати інваріантів базового класу (інваріанти базового класу і спадкоємців підсумовуються);

- похідні класи не повинні генерувати виключення, не описані базовим класом.

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

I (Interface Segregation Principle) - принцип поділу інтерфейсів. Клієнти не повинні вимушено залежати від методів, якими не користуються. Клас повинен надавати зручний інтерфейс з точки зору його різноманітних клієнтів.

ISP відрізняється від інших принципів з сімейства SOLID тим, що дивлячись лише на клас або модуль не можна сказати, порушується принцип чи ні. Потрібно знати контекст використання класу, і якщо різні клієнти цікавляться різними аспектами даного класу чи модуля, то виділення додаткових інтерфейсів зроблять такий поділ більш очевидним.Якщо ж інтерфейс класу незрозумілий, то клас не просто порушує ISP, він порушує SRP і повинен пройти етапи рефакторінгу і спрощення.

D (The Dependency Inversion Principle) - принцип інверсії залежностей. Модулі верхнього рівня не повинні залежати від модулів нижнього рівня. І ті й інші повинні залежати від абстракцій. Абстракції не повинні залежати від деталей. Деталі повинні залежати від абстракцій. Суть принципу інверсії залежностей проста: замінити композицію агрегацією. Тобто замість створення безпосередньо залежностей, клас повинен вимагати їх у більш високого рівня через аргументи методу або конструктора. При цьому залежність повинна передаватися не у вигляді екземплярів конкретних класів, а у вигляді інтерфейсів або абстрактних класів [16].

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

3.9 Git та Bitbucket

Git - розподілена система контролю версій файлів, створена під керівництвом Лінуса Торвальдса. Системи контролю версій дозволяють зберігати кілька версій одних і тих же файлів з можливістю повернення до старого варіанту, перегляду змін, їх авторів і т.д.

Розподілена система контролю версій не потребує центрального серверу, що зберігає версії, вся історія зберігається на кожному локальному комп'ютері і при необхідності синхронізується з аналогічним сховищем іншого комп'ютера. У цьому відмінність Git від, наприклад, SVN - можна встановити Git тільки на локальний комп'ютер і зберігати всі версії у себе, чи не дублюючи на сервер. Однак в разі командної роботи все ж зручно мати сервер, який зберігає версії. Такий сервер також можна сприймати як бекап всіх актуальних файлів і їх версій, доступний з будь-якої точки світу.

Bitbucket - це хостинг для Mercurial і Git репозиторіїв. Найближчий аналог і прямий конкурент - github. За популярністю Bitbucket відстає, проте у нього є пара помітних функцій в порівнянні з github - це підтримка Mercurial і можливість створити скільки завгодно приватних репозиторіїв на безкоштовному акаунті, однак дати доступ можна максимум п'яти користувачам (у github взагалі немає приватних репозиторіїв для безкоштовних акаунтів).

Для написання роботи було прийнято рішення створити приватний репозиторій, використовуючи веб-сервіс Bitbucket, що дозволить в подальшому розвивати додаток, знаючи, що код не буде в публічному доступі.

3.10 Методології розробки

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

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

Існує кілька методик, що відносяться до класу гнучких методологій розробки, зокрема екстремальне програмування, DSDM, Scrum, FDD.

Було прийнято рішення використати методологію FDD (Feature driven development). Розробка ведеться короткими ітераціями, в кожній з яких додається нова функція. На відміну від інших Agile методологій більше уваги приділяється попередньому моделюванню: схемам та графікам.

FDD включає в себе п'ять базових видів діяльності:

- розробка загальної моделі;

- складання списку необхідних функцій системи;

- планування роботи над кожною функцією;

- проектування функції;

- реалізація функції.

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

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

4. ОПИС РОЗРОБЛЕНОЇ ПРОГРАМНОЇ СИСТЕМИ

TouristGames -- додаток, що надає інструменти для управління нотатками путівника. Розроблена мобільна програма підтримується операційною системою Android.

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

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

Рисунок 4.1 - Сторінка авторизації

Якщо користувач вперше користується додатком, йому пропонується зареєструватися у системі (рис. 4.2). Сторінка має відмінності зі сторінкою авторизації за наявністю додаткового поля для іменування користувача.

Рисунок 4.2 - Сторінка реєстрації

Після успішної авторизації користувач потрапляє до однієї з основних частин додатку - сторінки з країнами (рис. 4.3). Тут користувачу доступна інформація про список туристичних місць, надається можливість створювати власні місця. Також тут є швидкий доступ до кожного місця, який реалізовується через пошук.



Рисунок 4.3 - Сторінка з країнами

Верхнє меню має кнопки для виходу із системи, додавання нового місця та перегляду всіх місць на карті.

Натиснувши на кнопку додавання з'явиться можливість створити нове туристичного місце(рис. 4.4). Пропонується вибрати картинку з галереї, ввести назву та опис об'єкту та додати місцеположення.

Рисунок 4.4 - Сторінка створення туристичного місця

Вибравши елемент на сторінці з країнами користувач потрапляє до детальної інформації про туристичний об'єкт (рис. 4.5).

Рисунок 4.5 - Сторінка з описом туристичного місця

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

У верхній частині екрану зображена кнопка для редагування об'єкту. Екран не відрізняється від екрану створення об'єкту, тільки має введені дані про туристичне місце (рис. 4.6).



Рисунок 4.6 - Сторінка редагування туристичного місця

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

Рисунок 4.7 - Сторінка з вибором місцеположення об'єкту

Якщо користувач був у цьому місці, то маркер на карті зображений зеленим кольором, в іншому випадку має червоний.

Такий підхід використовується і для відображення загального числа туристичних об'єктів на карті (рис. 4.8).

Рисунок 4.8 - Сторінка з картою загального числа об'єктів

Натиснувши на маркер можна побачити точні координати туристичного місця, зображеного на карті.

5. ТЕСТУВАННЯ

Тестування програмного забезпечення - перевірка відповідності між реальною і очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому сенсі, тестування - це одна з технік контролю якості, що включає в себе активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Верифікація (Verification) - це процес оцінки системи або її компонентів з метою визначення чи задовольняють результати поточного етапу розробки умов, сформованим на початку цього етапу. Тобто чи виконуються наші цілі, терміни, завдання по розробці проекту, визначені на початку поточної фази.

Валідація (Validation) - це визначення відповідності розроблюваногопрограмного забезпечення очікуванням і потребам користувача, вимогам до системи.

Тестування ПЗ може проводитися на будь-якому етапі розробки, але найчастіше це відбувається по закінченню процесу кодування.

5.1 Тестування мобільних пристроїв

Мобільне тестування - це складний процес: десятки різних розмірів екрану, апаратні відмінності, різні типи підключення до інтернету, раптові обриви зв'язку [17]. Характеристики комп'ютера та телефонах, на яких виконується тестування, можуть вплинути на результати тесту. Щоб визначити, чи відповідає продуктивність вашого застосування вимогам сертифікації, було проведено тестування на різних пристроях , включаючи відмінні розміри екранів та версій операційних систем. Тестування проводилось як на реальних пристроях, так і на емуляторі Genymotion. Основні девайси, на яких було протестовано даний додаток:

- Motorola Moto G2 (Android 4.4, 720 x 1280 pixels);

- Nexus 5 (Android 5.0, 1080 x 1920 pixels);

- Nexus 6 (Android 6.0, 1440 x 2560 pixels).

Під час тестування жоден з пристроїв не показав збоїв у системі. Затрати по використаній оперативній пам'яті та інтернет трафіку були незначними.

5.2 Функціональне тестування

Функціональне тестування є одним з ключових видів тестування, завдання якого - встановити відповідність розробленого програмного забезпечення вихідним функціональним вимогам замовника [18]. Тобто проведення функціонального тестування дозволяє перевірити здатність інформаційної системи в певних умовах вирішувати завдання, потрібні користувачам.

Залежно від ступеня доступу до коду системи можна виділити два типи функціональних випробувань:

- тестування black box (чорний ящик) - проведення функціонального тестування без доступу до коду системи;

- тестування white box (білий ящик) - функціональне тестування з доступом до коду системи.

Тестування black box проводиться без знання внутрішніх механізмів роботи системи і спирається на зовнішні прояви її роботи. При цьому при тестуванні перевіряється поведінка програмного забезпечення при різних вхідних даних і внутрішніх станів системи.

У випадку тестування white box створюються тест-кейси, засновані переважно на коді системи ПО. Також існує розширений тип black-box тестування, що включає в себе вивчення коду, - так званий grey box (сірий ящик).

Функціональне тестування - це перевірка ПЗ на правильність функціонування в ідеальних умовах, на відміну від не функціонального, де або умови неідеальні (тестування навантаження), або проводиться тестування не на правильність функціонування, а щось інше (тестування зручності користування або структура програми) [19].

Щоб провести повне тестування програми, потрібно перевірити правильність її поведінки при всіх можливих комбінаціях вхідних даних і у всіх можливих внутрішніх станах. Це неможливо за величезного числа комбінацій навіть у найпростіших випадках. Тому на практиці відбираються тільки найбільш важливі тести, використовуючи різні методи [20].

В таблиці вказані деякі тест-кейси, що були створені та пройдені на етапах тестування (табл. 5.1).

Таблиця 5.1 - Перелік тест-кейсів

Номер	Варіант тестування	Опис сценарію	Результат що очікується
1	2	3	4
1	Додавання туристичного місця	Натиснути на кнопку «+» на верхній панелі меню на сторінці з туристичними місцями.

Подобные документы

• База даних "Каталог мобільних телефонів"

  Характеристика категорій користувачів баз даних. Проектування інформаційної системи: концептуальне (інфологічне), даталогічне та фізичне. Опис бази даних "Каталог мобільних телефонів": принципи створення таблиць, запитів та форм. Інструкція користувача.
  
  курсовая работа [63,2 K], добавлен 14.12.2010
  

• Розробка програмного комплексу ведення бази даних товарів продовольчого магазину

  Теоретичні відомості про пакет ІЗВП Borland Delphi та СУБД MS Access, оцінка їх функціональних особливостей. Опис структури бази даних. Проектування інтерфейсу програми, опис її логічної структури та функцій. Контроль коректності вхідних, вихідних даних.
  
  курсовая работа [4,5 M], добавлен 03.01.2014
  

• Інформаційна система "Відділення банку"

  Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.
  
  курсовая работа [3,5 M], добавлен 28.11.2011
  

• Мобільне застосування "Газові заправки України"

  Android, iOS та Windows як основні платформи для розробки додатків для мобільних пристроїв. Перелік вимог до програмної системи. Основні вимоги, які є критичними для працездатності мобільного додатку. Аналіз основних напрямків розвитку системи.
  
  курсовая работа [1,1 M], добавлен 19.08.2016
  

• Бази даних

  Основи проектування мобільного додатку для операційної системи Android з використанням хмарної бази даних Cloud Firestore. Аналіз основних труднощів, які виникають під час розробки додатків. Визначення основних переваг та недоліків хмарних баз даних.
  
  статья [195,3 K], добавлен 07.02.2018
  

• База даних інформаційної системи "Лікарня"

  Виявлення основних сутностей предметної області. Побудова схеми реляційної бази даних. Вбудовані процедури і тригери. Опис архітектури програмної системи і концептуальної моделі бази даних, програмної реалізації та інтерфейсу користувача додатку.
  
  курсовая работа [4,3 M], добавлен 05.12.2012
  

• Розроблення модуля для проведення вікторини на базі мобільних технологій

  Коротка характеристика об’єктів управління "Nix Solutions". Розроблення варіантів використання, специфікація функціональних та не функціональних вимог. Проектування структури бази даних, елементи. Тестування додатку та розгортання програмного продукту.
  
  дипломная работа [1,5 M], добавлен 01.07.2015
  

• Архітектура програмної системи

  Опис основних етапів розробки архітектури програмної системи: структурування системи, моделювання управління, декомпозиція підсистем. Ознайомлення із кроками створення інтерфейсу користувачів як однієї із фаз проектування програмного забезпечення.
  
  реферат [20,7 K], добавлен 24.11.2010
  

• Поняття про інтегровану базу даних як одну із складових програмних забезпечень АРМ

  Поняття та переваги реляційної бази, автоматизація аналізу даних. Опис основних компонентів сховища даних AS/400. Процес перетворення оперативних даних в інформаційні. Багатовимірні бази даних (MDD). Опис даних і створення файлів в інтеграційних базах.
  
  реферат [36,8 K], добавлен 14.01.2012
  

• Інформаційна система торгівельного закладу

  Створення інформаційної системи для спортивного магазину харчування. Обґрунтування вибору мови програмування. Текстуальний опис алгоритму. Проектування бази даних. Комп'ютеризація торгівельних закладів, отримання необхідних даних в автоматичному режимі.
  
  дипломная работа [1,3 M], добавлен 12.05.2015
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам