Документация_Оригинал / Пояснювальна_записка_Диплом_Оригинал_1
.pdf35
Продовження табл. 2.7.
1 |
|
2 |
3 |
4а |
5 |
|
|
|
|
|
|
|
|
Режими зниженої |
|
|
|
PR-03 |
|
продуктивності: середня |
Обов. |
Середня |
Розробник |
|
|
швидкодія– 2 сек. |
|
|
|
|
|
4. Експлуатаційна придатність |
|
||
|
|
|
|
|
|
ОR-01 |
|
Система повинна бути |
|
|
Розробник |
|
|
розрахована на |
|
|
|
|
|
експлуатацію в складі |
Рекомендо- |
|
|
|
|
програмно-техніческого |
Низька |
|
|
|
|
вано |
|
||
|
|
комплекса замовника і |
|
|
|
|
|
|
|
|
|
|
|
враховувати специфіку ІТ |
|
|
|
|
|
інфраструктури замовника |
|
|
|
ОR-02 |
|
Для нормальної |
|
|
Розробник |
|
|
експлуатації |
|
|
|
|
|
розроблюваної системи |
Обов’язково |
Висока |
|
|
|
має бути забезпечено |
|
||
|
|
|
|
|
|
|
|
безперебійне Інтернет |
|
|
|
|
|
з'єднання. |
|
|
|
|
|
|
|
|
|
|
|
5. Проектні обмеження |
|
|
|
|
|
|
|
|
|
РR-01 |
|
Мови програмування – С# |
Обов. |
Середня |
Мови |
|
|
|
|
|
програмування |
|
|
|
|
|
– С# |
РR-02 |
|
Інструментальні засоби |
Реком. |
Середня |
Інструментальн |
|
|
розробки – Visual Studio |
|
|
і засоби |
|
|
2013 |
|
|
розробки – |
|
|
|
|
|
Visual Studio |
|
|
|
|
|
2013 |
РR-03 |
|
Сайт parse.com |
Реком. |
Висока |
parse.com |
|
|
|
|
|
|
|
|
6. Вимоги до документації |
|
|
|
|
|
|
|
|
|
DR-01 |
|
Керівництво користувача |
Реком. |
Низька |
Розробник |
|
|
|
|
|
|
DR-02 |
|
Керівництво програміста |
Обов. |
Низька |
Розробник |
|
|
|
|
|
|
DR-03 |
|
Довідка |
Необов’язков |
Низька |
Розробник |
|
|
|
о |
|
|
|
7. Куповані компоненти. Купованих компонентів не передбачено |
||||
|
|
|
|
|
|
|
|
8. Інтерфейси |
|
|
|
|
|
|
|
|
|
36
Продовження табл. 2.7.
8.1. Інтерфейси користувача
IU-01 |
Єдине оформлення всіх |
Обов. |
Низька |
Розробник |
|
вікон і повідомлень |
|
|
|
|
системи. |
|
|
|
IU-02 |
Перегляд звітів |
Реком. |
Низька |
Розробник |
|
відбувається в окремому |
|
|
|
|
вікні. |
|
|
|
IU-03 |
Підтвердження або відмова |
Обов. |
Низька |
Розробник |
|
виконання різних дій в |
|
|
|
|
системі здійснюється |
|
|
|
|
шляхом натискання на |
|
|
|
|
відповідні кнопки |
|
|
|
IU-04 |
Обмежень на дозвіл екрану |
Реком. |
Середня |
Розробник |
|
немає, проте |
|
|
|
|
рекомендована роздільна |
|
|
|
|
здатність становить |
|
|
|
|
1024х768, як найбільш |
|
|
|
|
зручна |
|
|
|
IU-05 |
Додавання, редагування |
Обов. |
Середня |
Розробник |
|
даних здійснюється |
|
|
|
|
шляхом заповнення полів |
|
|
|
|
на сайті parse.com |
|
|
|
IU-06 |
Формування запитів |
Опц. |
Низька |
Розробник |
|
здійснюється шляхом |
|
|
|
|
вибору даних |
|
|
|
IU-07 |
Обмежень на розрішення |
Реком. |
Середня |
Розробник |
|
екрану немає |
|
|
|
|
8.2. Апаратні інтерфейси |
|
|
|
|
|
|
|
|
IH-01 |
Протокол обміну даними |
|
|
Розробник |
|
між клієнтами і сервером – |
Обов. |
Середня |
|
|
ТСР |
|
|
|
IH-02 |
Мережеве обладнання |
|
|
Розробник |
|
підтримує всі протоколи |
|
|
|
|
обміну даними, |
Реком. |
Середня |
|
|
передбачені стандартами |
|
||
|
|
|
|
|
|
Fast Ethernet і |
|
|
|
|
встановленими ОС |
|
|
|
|
8.3. Програмні інтерфейси |
|
|
|
|
|
|
|
|
IS-01 |
Система взаємодіє з сайтом |
Реком. |
Середня |
Розробник |
|
parse.com. |
|
|
|
37
Продовження табл. 2.7.
1 |
|
2 |
3 |
4а |
5 |
|
|
|
|
|
|
|
|
8.2. Апаратні інтерфейси |
|
|
|
|
|
|
|
|
|
IH-01 |
|
Протокол обміну даними |
|
|
Розробник |
|
|
між клієнтами і сервером – |
Обов. |
Середня |
|
|
|
ТСР |
|
|
|
|
|
8.3. Програмні інтерфейси |
|
|
|
|
|
|
|
|
|
IS-01 |
|
Система взаємодіє з сайтом |
Реком. |
Середня |
Розробник |
|
|
parse.com. |
|
|
|
|
|
8.2. Апаратні інтерфейси |
|
|
|
|
|
|
|
|
|
IH-01 |
|
Протокол обміну даними |
|
|
Розробник |
|
|
між клієнтами і сервером – |
Обов. |
Середня |
|
|
|
ТСР |
|
|
|
|
|
|
|
|
|
IH-02 |
|
Мережеве обладнання |
|
|
Розробник |
|
|
підтримує всі протоколи |
|
|
|
|
|
обміну даними, |
Реком. |
Середня |
|
|
|
передбачені стандартами |
|
||
|
|
|
|
|
|
|
|
Fast Ethernet і |
|
|
|
|
|
встановленими ОС |
|
|
|
8.3. |
|
|
|
|
|
Програм |
|
|
|
|
|
ні |
|
|
|
|
|
інтерфей |
|
|
|
|
|
си |
|
|
|
|
|
IS-01 |
|
Система взаємодіє з сайтом |
Реком. |
Середня |
Розробник |
|
|
parse.com. |
|
|
|
IS-02 |
|
Взаємодія з ПЗ MS Office |
Реком. |
Висока |
Розробник |
|
|
Word 2003/2007/2010/2013. |
|
|
|
IS-03 |
|
Підтримка xml-файлів. |
Реком. |
Висока |
Розробник |
|
|
|
|
|
|
9. Вимоги до ліцензування |
|
|
|
||
|
|
|
|
|
|
LR-01 |
|
Додаток розповсюджуєтся |
|
|
Розробник |
|
|
безкоштовно, при умові що |
Реком. |
Середня |
|
|
|
замовник не висуває вимог |
|
||
|
|
|
|
|
|
|
|
до ліцензування |
|
|
|
|
|
|
|
|
|
38 |
|
|
|
|
|
Закінчення табл. 2.7. |
|
1 |
|
|
2 |
3 |
4а |
5 |
|
|
|
|
|
|
|
|
10. Застереження щодо питань, пов'язаних з авторськими правами |
|||||
|
|
|
|
|
|
|
СR-01 |
|
|
Авторські права належать |
Обов. |
Середня |
Розробник |
|
|
|
розробнику програми |
|
||
|
|
|
|
|
|
|
|
|
|
11. Вживані стандарти |
|
|
|
|
|
|
|
|
|
|
SU-01 |
|
|
Стандарти основ юзабіліті |
|
|
Розробник |
|
|
|
Рекомендо-вано |
Реком. |
Середня |
|
|
|
|
Середня |
|
|
|
SU-02 |
|
|
Якості коду, як дизайну так |
|
|
Розробник |
|
|
|
і логіки написання |
Обов. |
Середня |
|
|
|
|
функцій. |
|
|
|
SU-03 |
|
|
Доступність для пристроїв |
Реком. |
Низька |
Розробник |
|
|
|
|
|
||
|
|
|
|
|
|
|
SU-04 |
|
|
Стандарти управління |
Реком. |
Низька |
Розробник |
|
|
|
сайтом |
|
||
|
|
|
|
|
|
|
2.4.Висновки
Урозділі 2 були сформовані функціональні й не функціональні вимоги щодо додатку а також глосарій проекту з термінами, що використовуються у проекті та побудована діаграма варіантів використання.
39
Розділ 3
Проектні та технічні рішення
3.1.Логічна постанова задачі
Поставлена задача не має математичного формулювання, і тому надається опис логіки послідовних операцій у вигляді функцій обробки інформації, що виконуються.
Додаток буде викладений у Windows Phone Store, та буде безкоштовним. Для того, щоб завантажити його на свій смартфон необхідно зайти до магазину на ввести у поле пошуку: ―Quiz‖ та нажати клавішу вводу. Для логотипу використовується велика літера Q. Після входу у вікторину ви бачите поле входу де вам потрібно авторизуватися або зареєструватися, якщо ви цього ще не робили. На головному меню відображається вибір теми, вибір одно-користувальницького режиму, вибір одно-користувальницького режиму та таблиця рекордів. Натиснувши на вибір одно-користувальницького режиму відкриється можливість вибрати його режим - введення вручну та вибір відповіді. Для того щоб додаток працював і можна було грати у вікторину потрібне постійне з’єднання з Інтернетом.
3.2.Проектування структури бази даних
Створення бази даних слід починати з її проектування. У результаті проектування має бути визначена структура бази, тобто склад таблиць, їхня структура та логічні зв'язки .
Структура реляційної таблиці визначається складом стовпців, їхньою послідовністю, типом даних кожного стовпця та їхнім розміром, а також ключем таблиці. Процес проектування можна здійснювати двома підходами. За першого підходу спочатку визначають основні задачі, для розв'язання яких створюється база, та потреби цих задач у даних. За другого підходу визначають предметну область (сферу), здійснюють аналіз її даних і встановлюють типові об'єкти предметної області. Найбільш раціональним підходом проектування бази даних є поєднання обох підходів.
3.2.1. Опис вхідної та вихідної інформації, що обробляється в рамках автоматизованих функцій
Інформаційний перелік вхідних та вихідних документів автоматизованої задачі наведено в табл. 3.1.
40
|
Таблиця 3.1 |
|
Інформаційний перелік документів |
||
|
|
|
Найменування документа |
Вхідний /вихідний |
|
Питання вікторини |
Вхідний |
|
Темі вікторини |
Вхідний |
|
Відповіді на питання |
Вхідний |
|
Результати проведення вікторини |
Вихідний |
|
Отримана інформація про вхідні та вихідні документи, дозволить побудувати модель відображення простору реквізитів вхідних та вихідних документів (табл. 3.2).
|
|
|
Таблиця 3.2 |
|
|
Перелік реквізитів документів |
|||
|
|
|
|
|
№ |
Найменування елементу |
Фактичний |
Призначення елемента |
|
п/п |
або обліковий |
|||
|
|
|||
|
|
|
|
|
1 |
2 |
3 |
4 |
|
1 |
ИД_питання |
Обліковий |
Зберігає ид питання |
|
2 |
Питання |
Фактичний |
Зберігає питання |
|
3 |
Відповідь_1 |
Фактичний |
Зберігає 1й варіант відповіді |
|
4 |
Відповідь_2 |
Фактичний |
Зберігає 2й варіант відповіді |
|
5 |
Відповідь_3 |
Фактичний |
Зберігає 3й варіант відповіді |
|
6 |
Відповідь_4 |
Фактичний |
Зберігає 4й варіант відповіді |
|
7 |
Правильна_відповідь |
Фактичний |
Зберігає правильний варіант |
|
|
|
|
відповіді |
|
8 |
Ид_теми |
Обліковий |
Зберігає ид теми |
|
9 |
Назва_теми |
Фактичний |
Зберігає назву теми |
|
10 |
ИД_БК_гри |
Обліковий |
Зберігає ид одно- |
|
|
|
|
користувальницького режиму гри |
|
11 |
Набрані_бали_К1 |
Фактичний |
Зберігає набрані бали першим |
|
|
|
|
користувачем |
|
12 |
Набрані_бали_К2 |
Фактичний |
Зберігає набрані бали другим |
|
|
|
|
користувачем |
|
13 |
Ид_користувача |
Обліковий |
Зберігає ид користувача |
|
14 |
Логін |
Фактичний |
Зберігає логін користувача |
|
15 |
Пароль |
Фактичний |
Зберігає пароль користувача |
|
16 |
ИД_ОК_гри |
Обліковий |
Зберігає ид одно- |
|
|
|
|
користувальницького режиму гри |
|
17 |
Кількість_пр_відповідей |
Фактичний |
Зберігає кількість відповідей на які |
|
|
|
|
користувач відповів правильно |
|
41
|
|
|
Закінчення табл. 3.2 |
1 |
2 |
3 |
4 |
18 |
Ид_виду |
Обліковий |
Зберігає ид виду вікторини |
19 |
Назва_виду |
Фактичний |
Зберігає назву виду вікторини |
20 |
Ид_користувача |
Обліковий |
Зберігає ид користувача |
21 |
Колькость_Очок |
Фактичний |
Зберігає кількість очок що набрав |
|
|
|
гравець |
3.3.2 Концептуальне інфологічне проектування Інфологічний рівень являє собою інформаційно-логічну модель (ІЛМ)
предметної області, в якій виключена надмірність даних і відображені інформаційні особливості об’єкту управління, без урахування особливостей і специфіки конкретної СУБД [25].
Мета інфологічного проектування — створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється інформаційно-логічна модель, яка має відповідати таким вимогам:
1)Коректність схеми БД
2)простота і зручність використання на наступних етапах проектування, тобто ІЛМ має легко відображатися в моделі БД, що підтримується відомими СУБД (сіткові, ієрархічні, реляційні);
3)ІЛМ має бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам.
Основною складовою інфологічної моделі є атрибути, які потрібно проаналізувати і деяким чином згрупувати для подальшого зберігання в БД. Сутність інфологічного моделювання полягає у виокремленні інформаційних об’єктів (таблиць), які підлягають зберіганню в БД, а також визначенні характеристик об’єктів і зв’язків між ними. Характеристиками чи властивостями об’єктів є атрибути [26].
Словник даних, що містяться у таблицях бази даних, наведений у табл. 3.3.
|
|
|
Таблиця 3.3 |
|
|
Словник даних |
|
|
|
|
|
№ |
Найменування |
Тип і довжина |
Призначення елемента |
п |
елемента |
|
|
/п |
|
|
|
1 |
2 |
3 |
4 |
|
|
|
|
1 |
ИД питання |
Int |
Зберігає ид питання |
2 |
Питання |
Varchar(100) |
Зберігає питання |
42
|
|
|
|
|
|
Закінчення табл. 3.3 |
||
1 |
2 |
|
3 |
4 |
|
|
|
|
3 |
Відповідь 1 |
|
Varchar(20) |
Зберігає 1й варіант відповіді |
||||
4 |
Відповідь 2 |
|
Varchar(20) |
Зберігає 2й варіант відповіді |
||||
5 |
Відповідь 3 |
|
Varchar(20) |
Зберігає 3й варіант відповіді |
||||
6 |
Відповідь 4 |
|
Varchar(20) |
Зберігає 4й варіант відповіді |
||||
7 |
Правильна |
|
Varchar(20) |
Зберігає |
правильний |
варіант |
||
|
відповідь |
|
|
відповіді |
|
|
|
|
8 |
Ид теми |
|
Int |
Зберігає ид теми |
|
|
||
9 |
Назва теми |
|
Varchar(15) |
Зберігає назву теми |
|
|
||
10 |
ИД |
|
Int |
Зберігає |
|
|
|
ид |
|
багатокористувальни |
|
багатокористувальницького |
режиму |
||||
|
цької гри |
|
|
гри |
|
|
|
|
11 |
Набрані |
бали |
Int |
Зберігає |
набрані |
бали |
першим |
|
|
користувачем 1 |
|
|
користувачем |
|
|
|
|
12 |
Набрані |
бали |
Int |
Зберігає |
набрані |
бали |
другим |
|
|
користувачем 2 |
|
|
користувачем |
|
|
|
|
13 |
Ид користувача |
|
Int |
Зберігає ид користувача |
|
|||
14 |
Логін |
|
Varchar(15) |
Зберігає логін користувача |
|
|||
15 |
Пароль |
|
Varchar(15) |
Зберігає пароль користувача |
|
|||
16 |
ИД |
|
Int |
Зберігає ид однокористувальницького |
||||
|
однокористувальниц |
|
режиму гри |
|
|
|
|
|
|
ької гри |
|
|
|
|
|
|
|
17 |
Кількість |
|
Int |
Зберігає кількість відповідей на які |
||||
|
правильних |
|
|
користувач відповів правильно |
|
|||
|
відповідей |
|
|
|
|
|
|
|
18 |
Ид виду |
|
Int |
Зберігає ид виду вікторини |
|
|||
19 |
Назва виду |
|
Varchar(25) |
Зберігає назву виду вікторини |
|
|||
20 |
Ид користувача |
|
Int |
Зберігає ид користувача |
|
|||
21 |
Колькость очок |
|
Int |
Зберігає кількість очок що набрав |
||||
|
|
|
|
гравець |
|
|
|
|
3.2.3 Проектування глобальної логічної моделі даних Структура логічної моделі даних (рис. 3.2) відображає структуру
елементів які знаходяться у базі даних.
Вона описує семантику предметної області і не враховує особливості конкретної СУБД. За даною логічною схемою побудована фізична модель (рис. 3.3), в якій враховані такі особливості СУБД, як припустимі типи і найменування полів.
Основна перевага реляційної моделі – порівняльна простота інструментальних засобів її підтримки. Реляційна даталогічна модель містить набір відносин або записів, явно не зв'язаних між собою. Зв'язки виражаються в наявності однакових атрибутів у різних відносин, які
43
(атрибути) дозволяють при виконанні операції природного об’єднання відносин одержати цільну картину даних про об'єкт бази даних.
Розроблена реляційна схема даних не вимагає подальшої нормалізації. Отримана модель бази даних є основою для генерації структур даних, індексів і тригерів на фізичному етапі проектування. Враховано цілісність даних, тобто стійкість збережених даних до руйнування й знищення, пов'язаних з несправністю технічних засобів, системними помилками й помилковими діями користувачів, яка передбачає: відсутність неточно введених даних або двох однакових записів про один і той самий факт, захист від помилок при оновленні бази даних, каскадне видалення зв’язаних даних різних таблиць та збереження даних при відмовах і збоях техніки (відновлення даних).
Ефективність забезпечена вибором комплексу технічних засобів, вибором СУБД, проектуванням оптимальної логічної й фізичної моделі даних в процесі фізичного проектування БД.
|
|
|
|
|
Таблиця 3.4 |
|
|
Обмеження унікальності |
|||
|
|
|
|
|
|
№ |
Атрибут або група |
|
|
Серед яких примірників, якої сутності |
|
п/п |
атрибутів |
|
|
|
або зв'язку має місце унікальність |
1 |
Користувач.Ид_користува |
|
Для всіх примірників сутності «Користувач» |
||
|
ча |
|
|
|
|
|
|
|
|
|
|
2 |
Багатокористувальницьки |
|
Для всіх примірників сутності |
||
|
й_режим.ИД_БК_гри |
|
«Багатокористувальницький_режим» |
||
3 |
Однокористувальницький |
|
Для всіх примірників сутності |
||
|
_режим.ИД_ОК_гри |
|
«Однокористувальницький_режим» |
||
4 |
Тема_вікторини.ИД_теми |
|
Для всіх примірників сутності «Тема_вікторини» |
||
5 |
Питання_вікторини.ИД_п |
|
Для всіх примірників сутності «Питання_вікторини» |
||
|
итання |
|
|
|
|
6 |
Вид_вікторини.ИД_виду |
|
Для всіх примірників сутності «Вид_вікторини» |
||
|
|
|
|
|
Таблиця 3.5 |
|
Динамічні обмеження |
||||
|
|
|
|
|
|
№ |
Група атрибутів |
|
|
|
Обмеження |
п/п |
|
|
|
|
|
1 |
Користувач.Ид_користувача |
|
Ид_користувача = Ид_користувача +1 - |
||
|
|
|
|
|
значення атрибута курс може лише |
|
|
|
|
|
збільшуватися на одиницю. |
|
|
|
|
||
2 |
Багатокористувальницький_режим. |
|
ИД_БК_гри = ИД_БК_гри +1 - значення |
||
|
ИД_БК_гри |
|
|
|
атрибута курс може лише збільшуватися на |
|
|
|
|
|
одиницю. |
|
|
44 |
|
|
Закінчення табл. 3.5 |
3 |
Однокористувальницький_режим.И |
ИД_ОК_гри = ИД_ОК_гри +1- значення |
|
Д_ОК_гри |
атрибута курс може лише збільшуватися на |
|
|
1. |
|
Тема_вікторини.ИД_теми |
ИД_теми = ИД_теми +1 - значення |
4 |
|
атрибута курс може лише збільшуватися на |
|
|
одиницю. |
5 |
Питання_вікторини.ИД_питання |
ИД_питання = ИД_питання +1 - значення |
|
|
атрибута курс може лише збільшуватися на |
|
|
одиницю. |
6 |
Вид_вікторини.ИД_виду |
ИД_виду = ИД_виду +1 - значення |
|
|
атрибута курс може лише збільшуватися на |
|
|
одиницю. |
3.2.4. Проектування фізичної моделі даних Фізична модель була побудована за допомогою програмного продукту
Erwin 7. Побудована база володіє усіма властивостями баз даних, такими як: функціональна повнота; мінімальна надмірність; цілісність бази; узгодженість; актуальність; безпека; відновлюваність; логічна та фізична незалежність; ефективність.
Структура фізичної моделі даних відображена на рис. 3.4.
3.3.Розроблення архітектури програмної системи
3.3.1. Діаграми класів.
Діаграма класів відображає основні класи системи.
У розроблюваному додатку є 3 основних класи для питань з варіантами відповідей, для рекордів, для користувачів.
Діаграма основних класів, які виконують важливі функції у системі представлено на рис. 3.2.
Рис.3.2. Діаграма основних класів 3.3.2. Структура фізичної та логічної моделі даних.