Дистанційна система навчання «Moodle»
Варіанти використання призначені в першу чергу для визначення функціональних вимог до системи і управляють усім процесом розробки. Всі основні види діяльності такі як аналіз, проектування, тестування виконуються на основі варіантів використання. Під час аналізу і проектування варіанти використання дозволяють зрозуміти як результати, які хоче отримати користувач впливають на архітектуру системи і… Читати ще >
Дистанційна система навчання «Moodle» (реферат, курсова, диплом, контрольна)
Вступ
moodle друкарня дистанційний програма
Технічні досягнення знаходять застосування в навчальному процесі, і персональний комп’ютер (ПК) в цьому сенсі не є винятком. Використання обчислювальної техніки дозволяє істотно підвищити ефективність процесу навчання, поліпшити облік і оцінку знань, забезпечити можливість індивідуальної допомоги викладача кожному студенту у вирішенні окремих завдань, полегшити створення і постановку нових курсів.
Дистанційне навчання це нова форма навчального процесу, в якій використовуються традиційні та інноваційні способи навчання. Дистанційне навчання засноване на нових методах представлення даних і навчальних матеріалів в електронному вигляді (гіпертекстова розмітка документів, звук і відео вбудовані в електронний документ, інтерактивність при роботі з даними) та використання Internet технологій для доставки електронних навчальних матеріалів учням.
Дистанційне навчання розвивається дуже динамічно. Загальна кількість курсів дистанційного навчання у світі зростає більш ніж на 40% щорічно.
Дистанційна система навчання Moodle, добре справляється з поставленим завданням. Ця система відноситься до вільно поширюваного програмного забезпечення (Офіційний Internet сайт http://moodle.org).
Використання системи MOODLE не жадає фінансових витрат на придбання додаткових програмних продуктів і ми отримаємо ліцензійно чисте і на 100% легальне програмне забезпечення для організації дистанційного навчання. Легальність використання гарантується відкритою ліцензійною угодою GNU General Public License. Мета GNU GPL — надати користувачеві права використовувати, копіювати, модифікувати і поширювати програми.
Тому надзвичайно актуальною є тема доробки модуля адміністрування корпоративної інформаційної дистанційної системи керування навчанням Moodle, яка б вирішувала задачі дистанційного навчання персоналу, а також доробка модулю адміністрування, розширення можливостей адміністратора.
Модуль, який планується розробити буде надавати можливість створювати комітети, створювати різноманітні події (наприклад засідання), а також можливо управлінні повістками дня. Розробка модулю буде виконуватися для його подальшого впровадження в типографії «Добробут», а також при наступному вдосконаленні в інших організаціях.
1. Аналіз об'єкта проектування
1.1 Коротка характеристика підприємства
Поліграфічна промисловість — одна з небагатьох, що стабільно розвиваються сьогодні в нашій країні галузей. Тому до поліграфії звертається все більше людей, які шукають найбільш раціональні сучасні методи розмноження інформації - від одно барвистих бланків та листівок до багатоколірних журналів, буклетів, проспектів, листівок та іншої високоякісної поліграфічної продукції.
Базою практики була обрана друкарня «Добробут «. Основним видом діяльності є надання послуг з друку різної продукції. Друкарня має розвинену структуру й складається з декількох відділів. Організаційна структура друкарні «Добробут» відображена на рис. 1.1. Очолює фірму директор. Йому підкоряються наступні відділі:
1. Відділ збуту;
2. Бухгалтерія;
3. Планово-єкономічний відділ;
4. Виробничий відділ;
5. Складский відділ;
6. Склад;
Велика увага друкарня приділяє розвитку цифрового друку. Передові технології дозволять отримувати зверстані шпальти по комп’ютерних мережах, відразу переносити їх на форму і вносити корективи по суте в процесі друку. Іншими словами, друкарня, повністю оснащена обладнанням фірми Heidelberg, який має переваги електронних засобів інформації з друкованими.
Основними напрямками діяльності друкарні є:
— друк високоякісної рекламно-представницької продукції: журнали, буклети, брошури, листівки, плакати, папки, флаєри, візитки, листівки;
— друк бланкової продукції великими тиражами, тиражування на дуплікаторах, ксерокопіювання, виготовлення методичних посібників, брошур, книг у твердій та м’якій палітурці, інструкцій, каталогів;
З усіх підрозділів типографи «Добробут» навчанням персоналу займається Планово-економічний відділ.
Він забезпечує не тільки економічне планування на підприємстві, направлене на організацію раціональної господарської діяльності, виявлення і використання резервів виробництва з метою досягнення найбільшої економічної ефективності, але також і навчання персоналу, підвищення його кваліфікації і обізнаністю в цілому. Структура відділу показана на рис. 1.2.
Рис.
Рис. 1.2. Схема організаційної структури планово-економічного відділу
1.2 Аналіз предметної області
Безперервний розвиток Інтернет-технологій змушує підприємства переходити до більш ефективних методів Рішення задач. Не обходить цей процес і сферу поліграфічної промисловості. Особливої уваги заслуговує впровадження Інтернет-технології дистанційного навчання при вирішенні проблеми підвищення кваліфікації персоналу. Оскільки від обізнаності і кваліфікації персоналу залежить робота підприємства в цілому. Чим більше кваліфікація персоналу тим вище їх рівень, та рейтинг підприємства.
Пропонується встановити систему дистанційного навчання Moodle. Це програмне забезпечення подане як простий статичний HTML сторінка, так і складними системами управління навчанням, та навчальним контентом (Learning Content Management Systems), що буде реалізовувати функції бізнес-процесу «адміністрування». Бізнес-процес охоплює ряд функцій, які в комплексі ефективно вирішує поставлену задачу:
— налаштування повідомлень;
— налаштування зовнішнього вигляду; ;
— управління реєстрацією користувачів;
— створення звітів;
— налаштування мережевої взаємодії;
— налаштування сервера;
— створення комітетів;
Схема бізнес-процесу зображена на рис. 1.4. В табл. 1.1 наведена характеристика бізнес-процесу.
Таблиця 1.1. Характеристика бізнес-процесу «Створення комітету»
Назва характеристики | Значення характеристики | |
Ім'я бізнес-процесу | Створення комітету | |
Основні учасники | Адміністратор, президент комітету, член, сопредсідатель | |
Вхідна подія | Створення нового комітету | |
Вхідні документи | Розпорядження про створення нового комітету | |
Вихідна подія | Формування комітету | |
Вихідні документи | Розпорядження про створення комітету | |
Клієнт бізнес-процесу | Адміністратор | |
Рис. 1.3. Діаграма «Дерево функцій»
Рис. 1.4. Схема бізнес-процесу «Створення комітету»
1.3 Аналіз існуючих програмних продуктів, що реалізують функції предметної області
Метою допрацювання модуля адміністрування дистанційної системи навчання Moodle, є поєднання можливостей програмних продуктів, які можуть вирішувати задачі такого роду, при цьому модуль буде вирішувати тільки поставлену задачу.
Аналогами розроблюваної програми можуть бути такі програмні продукти: «Learning Space 5.0», «ДОЦЕНТ» та «Moodle».
1.3.1 «Learning Space 5.0»
Learning Space 5.0 (Lotus / IBM) — програмна освітнє середовище, яка поєднує в собі можливості «класичного» навчання з сучасними інформаційними технологіями, заснованими на автоматизації взаємодії викладача зі студентами. Інтерфейс програми приведений на рис. 1.5.
Рис. 1.5. Інтерфейс програми Learning Space
Learning Space 5.0, дає можливість вчитися і викладати в асинхронному режимі (звертаючись до матеріалів курсів у зручний час), також брати участь в on-line заняттях в режимі реального часу. Користувач може створювати зміст курсу в будь-яких додатках і потім розміщувати створений матеріал в Learning Space 5.0. Програма має гнучку систему редагування та адміністрування курсу, дозволяє вибирати різні режими викладання і стежити за поточними результатами роботи учнів. Learning Space 5.0, робить навчання незалежним від місця знаходження його учасників. Для участі в навчальному процесі необхідно мати тільки доступ в Інтернет.
Learning Space 5.0 виконує:
— гнучкість — можливість навчання в потрібному вам темпі;
— групове співробітництво — можливість індивідуального або групового навчання. Простота — призначений для користувача інтерфейс допомогає легко переходити від одного модуля до іншого;
— практичний досвід — курси засновані не на «лекціях», а на практичних заняттях;
1.3.2 «СДН Доцент»
СДН «Доцент» являє собою комплекс програмно-методичних засобів для автоматизації процесу дистанційного навчання, підвищення кваліфікації і визначення рівня компетенції персоналу. Дана система використовує сучасні Інтернет-технології і методики навчання, комп’ютерні навчальні програми та комп’ютерні тестуючи системи, технології дистанційного навчання і дистанційного консультування. А так само підтримує очну, очно-заочну та заочну форми навчання для різних схем організації навчального процесу.
При очному навчанні СДО «Доцент» може використовуватися:
— на етапі попереднього тестування — з метою формування груп з однорідним за складом рівнем підготовки учнів;
— на етапі проведення навчання — для доступу до інформаційних ресурсів, навчальним програмам і тестуючими системам з робочих місць у комп’ютерних навчальних класах;
— на етапі зберігання інформації - для статистичної обробки даних, контролю за безперервністю і періодичністю навчання та формування персональної статистики по кожному слухачеві;
Очно-заочна форма навчання, для якої за кордоном використовується термін змішане навчання (blended learning), у всьому світі визнається найефективнішою формою організації навчального процесу у великих корпораціях. У цьому випадку до перерахованих вище варіантів використання СДН «Доцент» додаються:
— доступ до навчальних інформаційних ресурсів з робочих місць слухачів;
— можливість обміну повідомленнями електронною поштою між викладачем та слухачами;
— можливість проведення дистанційних консультацій та конференцій;
Інтерфейс програми приведений на рис. 1.6.
Рис. 1.6. Вікно «Каталог навчальних курсів»
Заочна форма навчання і самонавчання припускає, також як і інші форми навчання, доступ до навчальних матеріалів загального користування. Цей доступ організується в СДН «Доцент» за допомогою «Каталогу навчальних курсів» приведений на рис. 1.7.
Рис. 1.7. Вікно «Каталог навчальних курсів»
1.3.3 Система дистанційного навчання «Moodle»
Простими словами «Moodle», це система, яка містить в собі всі курси дисциплін і кожен студент може входити в цю систему і працювати з тим чи іншим курсом. Moodle розповсюджується безкоштовно як Open Source-проект, за ліцензією GNU GPL (іншими словами: Вам дозволяється копіювати, використовувати й змінювати програмний код). Інтерфейс програми приведений на рис. 1.8.
Рис. 1.8. Головне вікно системи дистанційного навчання «Moodle»
В системі студент має доступ до всіх наявних в наявності курсів, на яких він зареєстрований. Він може вивчати теорію, виконувати практичні роботи, здавати тести та контролювати свої результати, спілкуватися зі студентами своєї групи і викладачем за допомогою внутрішньої електронної середовища спілкування або електронною поштою. Студент самостійно вивчає навчально-методичні матеріали при періодичної допомогу й контролю з боку мережевого викладача.
Викладач закріплюється за кожним курсом. Основним завданням мережевого викладача є супроводження навчального процесу на основі вже підготовлених навчальних матеріалів. Мережевий викладач може переглядати результати тестів свого курсу та успішність студентів, які його вивчають. Студент може спілкуватися зі своїм викладачем за допомогою як вбудованої в систему електронної пошти, так і інших наявних засобів спілкування.
Блок Управління містить іконки і посилання на елементи редагування й адміністрування курсу.
Посилання і іконка Редагувати переводить систему в режим редагування курсу, що дозволяє вносити зміни в існуючі елементи, додавати, видаляти і переміщати блоки, ресурси і елементи курсу приведено на рис. 1.9.
Рис. 1.9. Вікно зміни налаштувань курсу Розглянуті програми у повній мірі вирішують задачу дистанційного навчання (табл. 1.2). Та слід сказати, що системи «Learning Space 5.0», СДН «Доцент» є комерційними й дозволяють вирішувати дуже великий спектр задач, що позначається на ціні даних пакетів. Також з цими програмами може працювати лише спеціаліст.
З проведеного аналізу можна зробити висновки про основний функціонал, котрим наділені всі програмні продукти, та реалізувати його у своїй розробці. Найбільш функціональним рішенням з розглядаємих програмних продуктів є «Moodle». Бажано розробити інтерфейс для користувача з правами «Адміністратор» який буде реалізувати різні налаштування системи.
Таблиця 1.2. Порівняльна характеристика програмних продуктів
Фірма-розробник | Geolink technologies | Вінницький національний технічний університет | «Moodle» | |
Назва програмного продукту | «Learning Space 5.0» | СДН «Доцент» | «Moodle» | |
Версії продукту | 5.0 | 1.5.3 | 2.0 | |
Функціональність | 1) Розподіленість — можливість навчатися в будь-якому місці і в будь-який час; 2) Гнучкість — можливість навчання в потрібному вам темпі; 3) Групове співробітництво — можливість індивідуального або групового навчання; 4) Вибір викладачів — можливість навчання у досвідчених експертів; | 1) автоматизована система дистанційного навчання, перепідготовки і тестування слухачів; 2) інструментальні засоби створення навчальних і контролюючих програм; 3) графічна оболонка для створення та генерації індивідуальних тестів заданої складності; | 1. Здачу завдань 2. Дискусійні форуми 3. Завантаження файлів 4. Оцінювання 5. Обмін повідомленнями 6. Календар подій 7. Новини та анонси подій (для різніх рівнів: сайт, курс, навчальна група) 8. Он-лайн Тестування | |
Можливість географічної прив’язки данних | Зручний Web-інтерфейс користувач з великою кількістю налаштувань | Зручний Webінтерфейс з мінімальною кількістю налаштувань | Зручний Web-інтерфейс користувач з великою кількістю налаштувань | |
Допомога користувачу | Покрокове керівництво користувача | Керівництво користувача | Покрокове керівництво користувача | |
2. Розроблення вимог до програмного забезпечення
2.1 Глосарій проекту
Глосарій — це словник основних використовуваних термінів. Цей документ є найпершим результатом концептуального аналізу предметної області. Глосарій можна розглядати як документ, що засвідчує спільне розуміння основної термінології Замовником і Розробником.
Глосарій проекту представлений у табл. 2.1.
Таблиця 2.1 Глосарій проекту
Термін | Опис терміну | |
1. Основні поняття та категорії предметної області та проекту | ||
СДН «Moodle» | середа дистанційного навчання Moodle. | |
Курс | навчальний простір в СДН Moodle, що включає набір вчителів або асистентів, студентів і учбових матеріалів. Курси створює адміністратор або творець курсів, призначаючи там вчителів або асистентів. | |
Категорії курсів | деревоподібна структура категорій і підкатегорій, що допомагає структурувати курси в СДН Moodle. | |
Модуль | Програмне розширення СДН Moodle, що додає нову функціональність. СДО Moodle підтримує наступні види модулів: — Елемент курсу; — Тип завдання; — Тип питання; — Блок; — Фільтр; — Формат курсу; — Тема оформлення; | |
LAMS | елемент курсу, що дозволяє завантажувати в СДН Moodle завдання створені в LAMS (Learning Activity Management System) — системі розробки завдань, які припускають спільну діяльність, і управляти ними | |
Таблиця
Ресурс | Елемент курсу, що дозволяє включити в курс практично будь-який цифровий (текстовий або графічний) матеріал. Ресурси бувають наступних типів: — Пояснення; — Текстова сторінка; — Веб-сторінка; | |
Управління | назва блоку, що надає вчителеві доступ до різних настроювань курсу, файлової області | |
Фільтр | Модуль, що дозволяє автоматично перетворювати введений текст в інші, більш складні форми | |
2. Користувачі системи | ||
Адміністратор | роль, що надає користувачеві повний набір привілеїв по настройці СДО Moodle, а також у всіх курсах | |
Учитель | роль, що дозволяє користувачеві редагувати матеріали курсу і вести курс (управляти списком студентів, перевіряти роботи, виставляти оцінки) | |
Студент | роль, що надає користувачеві можливість навчатися на курсі | |
3. Вхідні та вихідні документи | ||
2.2 Розроблення варіантів використання
Мета варіантів використання полягає в тому, щоб визначити закінчений аспект або фрагмент поведінки деякої сутності без розкриття внутрішньої структури цієї сутності. В якості такої сутності може виступати вихідна система або будь-який інший елемент моделі, який володіє власною поведінкою, подібно підсистемі або класу в моделі системи.
Варіанти використання призначені в першу чергу для визначення функціональних вимог до системи і управляють усім процесом розробки. Всі основні види діяльності такі як аналіз, проектування, тестування виконуються на основі варіантів використання. Під час аналізу і проектування варіанти використання дозволяють зрозуміти як результати, які хоче отримати користувач впливають на архітектуру системи і як повинні себе вести компоненти системи, для того щоб реалізувати потрібну для користувача функціональність.
2.2.1 Розроблення діаграми варіантів використання
Діаграма використання (use case diagram) призначена для відображення зовнішнього функціонування систем, що проектується та її взаємодії із зовнішнім світом користувачів. Головна задача діаграм використання — специфікація вимог до системи на початкових етапах проектування, коли вирішуються найбільш загальні задачі, пов’язані з призначенням системи, що розробляється.
Діаграма складається з наступних елементів:
— зовнішні користувачі (actors) — це такі дії, які передають або отримують інформацію для системи, це можуть бути фізичні об'єкти різної природи від людей і механізмів до програмних систем, один фізичний об'єкт може описуватися декількома користувачами, якщо він взаємодіє з різними функціями;
— блоки використання (use case) — це такі групи функцій системи, які об'єднуються в єдине ціле для зовнішнього користувача;
— зв'язки між блоками використання і зв’язки між блоками використання та зовнішніми користувачами.
У нашій системі будуть працювати наступні користувачі:
— учень;
— вчитель;
— адміністратор.
На рис. 2.1 та рис. 2.2 відображені основні користувачі системи, а також основні завдання, які вони будуть виконувати під час роботи з системою.
Основними задачами учня є:
— вхід в систему;
— реєстрація в системі;
— реєстрація на курсі;
Основними задачами вчителя є:
— вхід в систему;
— створення курсу;
— редагування курсу;
Основними задачами адміністратора є:
— вхід в систему;
— створення комітетів;
— налаштування сайту;
— робота зі списком користувачів системи;
— створення, видалення та редагування інформації про користувачів.
Рис. 2.1. Узагальнена діаграма варіантів використання
2.2.2 Специфікація варіантів використання
Описи варіантів використання системи подані у табл. 2.2 — табл. 2.8.
Таблиця 2.2. Варіант використання «Вхід у систему»
Контекст використання | Використовується на початку роботи з програмним продуктом | |
Діюча особа | Еколог-аналітик | |
Передумова | Лаборант ПК надіслав дані про кількісні показники забруднення води | |
Тригер | Запуск системи | |
Сценарій | Працівник отримує інформацію, входить у систему, вводить свій логін та пароль | |
Постумова | Користувач зареєстрований у системі | |
Таблиця 2.3. Варіант використання «Внесення інформації до бази даних»
Контекст використання | Використовується для додавання нових даних та редагування існуючих | |
Діюча особа | Еколог-аналітик | |
Передумова | Еколог-аналітик отримав данні, які потребують занесення до бази даних, або існуючі дані потребують корегування | |
Тригер | Отримання нових даних з ПК або зміни у існуючих | |
Сценарій | Працівник отримує дані, запускає програмний продукт, вводить свій логін та пароль, додає новий запис до БД або редагує вже існуючі дані. | |
Постумова | Користувач має права на редагування даних БД | |
Таблиця 2.4. Варіант використання «Робота зі списком користувачів системи»
Контекст використання | Використовується для додавання, видалення та редагування інформації про користувачів системи | |
Діюча особа | Адміністратор | |
Передумова | Адміністратор отримав данні про нового користувача, або необхідно видалити чи редагувати вже існуючих даних | |
Тригер | Запит на додавання чи видалення користувача | |
Сценарій | Адміністратор отримує запит на додавання чи видалення користувача, входить у систему, додає, видаляє чи редагує дані користувачів | |
Постумова | Користувач аутентифікований у системі | |
Таблиця 2.5. Варіант використання «Обслуговування БД»
Контекст використання | Використовується для підтримки продуктивності та захисту БД | |
Діюча особа | Адміністратор | |
Передумова | Необхідність підтримки БД у надійному стані та за захисті інформації БД | |
Тригер | Перевірка продуктивності БД | |
Сценарій | Адміністратор заходить в систему, вводить свій логін та пароль, виконує операції по обслуговуванню БД | |
Постумова | Користувач аутентифікований у системі | |
Таблиця 2.6. Варіант використання «Створення резервних копій БД»
Контекст використання | Використовується для створення резервних копій БД, щоб уникнути втрати диних | |
Діюча особа | Адміністратор | |
Передумова | Необхідність створення резервних копій ПД | |
Тригер | Планове створення копій бази даних | |
Сценарій | Адміністратор заходить в систему, вводить свій логін та пароль, створює резервні копії БД | |
Постумова | Користувач аутентифікований у системі | |
Таблиця 2.7. Варіант використання «Створення звітів»
Контекст використання | Використовується для створення звітів про екологічний стан поверхневих вод Харківської області | |
Діюча особа | Еколог-аналітик | |
Передумова | Користувач зібрав інформацію у повному обсязі, необхідну для створення звітів | |
Тригер | Отримання запиту на створення звіту | |
Сценарій | Користувач входить в систему, вводить свій логін та пароль, вводить необхідні запити до БД на основі яких будуть створюватися звіти | |
Постумова | Користувач аутентифікований у системі | |
Таблиця 2.8. Варіант використання «Аналіз стану поверхневих вод»
Контекст використання | Використовується для аналізу показників забруднюючих речовин і поверхневих водах Харківської області | |
Діюча особа | Еколог-аналітик | |
Передумова | Був отриманий та сформований набір даних, необхідних для аналізу | |
Тригер | Плановий аналіз інформації для подальшого створення звітів про стан поверхневих вод Харківської області | |
Сценарій | Користувач входить в систему, вводить свій логін та пароль, вводить необхідні запити до БД для аналізу існуючої інформації | |
Постумова | Користувач аутентифікований у системі | |
2.3 Специфікація функціональних та не функціональних вимог
Специфікація вимог до програмного забезпечення (SRS) — це повний опис поведінки системи що розробляється. Він включає набір прецедентів, що описують всі взаємодії користувача з системою. Прецеденти також відомі як функціональні вимоги. На додачу до прецедентів, SRS також містить нефункціональні (чи додаткові вимоги). Нефункціональні вимоги є вимогами які накладають обмеження на проект, чи реалізацію (такі як вимоги інженерії продуктивності, стандарти якості, чи обмеження проектування).
Специфікація функціональних вимог до системи приведена у табл. 2.9.
Таблиця 2.9. Специфікація функціональних вимог
Ідентифікаторвимоги | Назвавимоги | Атрибути вимог | |||
Пріоритет | Контакт | Трудність | |||
FR-UC-01 | Додавання даних моніторингу | Обов’язкове | Еколог-аналітик | Середня | |
FR-UC-02 | Редагування даних моніторингу | Обов’язкове | Еколог-аналітик | Середня | |
FR-UC-03 | Видалення даних моніторингу | Рекомендоване | Еколог-аналітик | Середня | |
FR-UC-04 | Побудова графіків по результатам моніторингу | Опційне | Еколог-аналітик | Середня | |
FR-UC-05 | Додавання каристувачів | Обов’язкове | Адміністратор | Середня | |
FR-UC-06 | Редагування даних про користувачів | Рекомендоване | Адміністратор | Середня | |
FR-UC-07 | Видалення користувачів | Опційне | Адміністратор | Середня | |
FR-UC-08 | Створення звітів | Обов’язкове | Еколог-аналітик | Середня | |
FR-UC-09 | Вхід в систему | Обов’язкове | Адміністратор | Середня | |
FR-UC-10 | Збереження звітів | Опційне | Еколог-аналітик | Середня | |
Специфікація не функціональних вимог до розроблюваної системи представлена у табл. 2.10.
Таблиця 2.10. Специфікація не функціональних вимог
Ідентифікаторвимоги | Назвавимоги | Атрибути вимог | |||
Пріоритет | Контакт | Трудність | |||
1. Застосовність | |||||
SUPP-01 | Час завантаження системи — не більше 5 сек. | Обов’язкове | Оператор | Середня | |
SUPP-02 | Швидкість роботи мережевого обладнання — 100 Mbit/s | Рекомендоване | Оператор | Низька | |
SUPP-03 | Зручний і функціональний інтерфейс користувача | Обов’язкове | Оператор | Середня | |
SUPP-04 | Легкість обслуговування системи | Обов’язкове | Оператор | Висока | |
SUPP-05 | Час відгуку серверу — не більше 30 сек | Рекомендоване | Оператор | С2ередня | |
2. Надійність | |||||
SUPP-06 | Не велика кількість збоїв у роботі системи | Обов’язкове | Оператор | Висока | |
SUPP-07 | Стійкість до збоїв, можливість продовжувати роботу з системою у випадку збою | Рекомендоване | Оператор | Висока | |
3. Робочі характеристики | |||||
SUPP-08 | Можливість одночасного обслуговування великої кількості клієнтів без зниження продуктивності. | Рекомендоване | Оператор | Низька | |
SUPP-09 | Час обробки запиту на пошук даних — не більше 3 сек. | Обов’язкове | Оператор | Висока | |
4. Експлуатаційна придатність | |||||
SUPP-10 | Дотримання стандартів W3C при проектуванні системи | Рекомендоване | Оператор | Середня | |
Таблиця
5. Проектні обмеження | |||||
SUPP-11 | Мова програмування РНР | Обов’язкове | Оператор | Середня | |
SUPP-12 | СУБД — МуSQL | Обов’язкове | Оператор | Середня | |
6. Вимоги до призначеної для користувача документації і до системи допомоги | |||||
SUPP-13 | Вивід повідомлень з попередженням про помилку | Рекомендоване | Оператор | Середня | |
SUPP-14 | Наявність додаткової інформації, пов’язаної з системою | Обов’язкове | Оператор | Низька | |
7. Куповані компоненти | |||||
SUPP-15 | Сумісність з браузерами Opera, Chrome, FireFox та Internet Explorer | Обов’язкове | Оператор | Середня | |
8. Інтерфейси | |||||
8.1. Інтерфейси користувача | |||||
SUPP-16 | Єдине оформлення усіх сторінок системи | Обов’язкове | Оператор | Середня | |
SUPP-17 | Зручний інтерфейс для роботи з БД | Обов’язкове | Оператор | Середня | |
8.2. Апаратні інтерфейси | |||||
SUPP-18 | 512 Мбайт ОЗП і вище | Обов’язкове | Оператор | Низька | |
SUPP-19 | 100 Мбайт вільного дискового простору; | Обов’язкове | Оператор | Низька | |
SUPP-20 | Відеокарта з підтримкою роздільної здатності не менше 800×600 і можливістю відображення не менше 256 кольорів; | Обов’язкове | Оператор | Низька | |
SUPP-21 | Монітор SVGA; | Обов’язкове | Оператор | Низька | |
SUPP-22 | Процесор 800 МГц, або вище. | Обов’язкове | Оператор | Низька | |
SUPP-23 | Мережевий адаптер 200 Мбіт/с | Обов’язкове | Оператор | ||
Таблиця
8.3. Програмні інтерфейси | |||||
SUPP-24 | Наявність операційної системи Windows | Обов’язкове | Оператор | Низька | |
SUPP-25 | Наявність усіх компонентів для нормальної роботи в Inetrnet | Обов’язкове | Оператор | Середня | |
8.4. Комунікаційні інтерфейси | |||||
SUPP-26 | Протокол обміну муж клієнтом і сервером здійснюється шляхом підключення до серверу БД — ТСР. | Обов’язкове | Оператор | Середня | |
SUPP-27 | Наявність постійного високошвидкісного підключення до Inetrnet | Обов’язкове | Оператор | Середня | |
9. Вимоги до ліцензування | |||||
SUPP-28 | Використання одної ліцензії на одне робоче місце | Обов’язкове | Оператор | Середня | |
10. Застереження щодо питань, пов’язаних з авторськими правами | |||||
SUPP-29 | Авторські права захищені законом | Обов’язкове | Оператор | Середня | |
11. Вживані стандарти | |||||
SUPP-30 | Стандарт якості програмного продукту ISO9001 | Обов’язкове | Оператор | Середня | |
3. Проектні та технічні рішення
3.1 Математична постановка задачі
У комплексі задач автоматизованого модуля «Система обліку забруднення поверхневих вод Харківської області» є задачі, які належать до класу розрахункових.
Розрахунок перевищення концентрації забруднюючої речовини у воді від комунально-побутової норми ГДК буде виконуватися наступним чином:
де — перевищення комунально-побутової норми концентрації i-тої
забруднюючої речовини,
— поточна концентрація i-тої забруднюючої речовини у воді,
— коефіцієнт комунально-побутової норми ГДК i-тої
забруднюючої речовини.
Розрахунок перевищення концентрації забруднюючої речовини у воді від рибогосподарської норми ГДК буде виконуватися наступним чином:
де — перевищення рибогосподарської норми концентрації i-тої
забруднюючої речовини,
— поточна концентрація i-тої забруднюючої речовини у воді,
— коефіцієнт рибогосподарської норми ГДК i-тої забруднюючої речовини.
Розрахунок даних показників необхідний для подальшої побудови графіків перевищення ГДК i-тої забруднюючої речовини від комунально-побутової та рибогосподарської норми ГДК.
Процес розрахунку показників та побудові на їх основі графіків відбувається у наступній послідовності:
— користувач системи (еколог аналітик, лаборант, звичайний відвідувач) заходить в систему;
— обирає розділ «Огляд стану забруднення поверхневих вод»;
— у даному розділі спочатку обирає звітний рік, а потім звітний місяць;
— далі будуються графіки забруднення поверхневих вод за звітний рік та місяць. Графіки містять показники ГДК, кількість забруднюючої речовини та перевищення даної кількості від ГДК.
3.2 Проектування структури бази даних
3.2.1 Опис вхідної та вихідної інформації
«Система обліку забруднення поверхневих вод Харківської області» автоматизує фунції лаборанта пункту спостереження та еколога аналітика, а саме:
— функції обліку забруднюючих речовин у воді;
— функції аналізу стану забрудення поверхневих вод Харківської області.
Кожна з цих функції має свій загальний та окремий набір вхіжних та вихідних документів, при чому вихідні документи вирішення однієї задачі стають вхідними для іншої.
Документи, які використовуються при вирішенні задачі «Облік забруднюючих речовин у воді» наведені в табл. 3.1.
Таблиця 3.1. Інформаційний список документів задачі «Облік забруднюючих речовин у воді»
Код документу | Назва | Вхідний/вихідний | |
DC-01 | Показники поверхневих вод | Вхідний | |
DC-02 | Список водних об'єктів та пунктів контролю, закріплених за ними | Вхідний | |
DC-03 | «Показники забруднюючих речовин у воді» | Вихідний | |
Документи, які використовуються при вирішенні задачі «Облік забруднюючих речовин у воді» наведені в табл. 3.2.
Таблиця 3.2. Інформаційний список документів задачі «Аналіз стану забрудненості поверхневих вод Харківської області»
Код документу | Назва | Вхідний/вихідний | |
DC-04 | «Санітарні правила і норми охорони поверхневих вод від забруднення. СанПіН 4630−88» | Вхідний | |
DC-05 | Звіт про стан поверхневих вод Харківської області за <�місяць> <�рік> року | Вихідний | |
На основі інформації вхідних і вихідних документів були сформовані списки реквізитів, на основі яких буде проектуватися структура бази даних.
Список реквізитів, які були отримані на основі вхідних документів, поданий у табл. 3.3.
Таблиця 3.3. Список реквізитів вхідних документів
№ п.п. | Найменування реквізиту | Фактичний/ Розрахунковий | Призначення реквізиту | |
Код пункту контролю | Фактичний | Описує сутність «Пункти контролю» | ||
Назва ПК | Фактичний | |||
Координата Х ПК | Фактичний | |||
Координата У ПК | Фактичний | |||
Назва відомства | Фактичний | |||
Місце розташування ПК | Фактичний | |||
Код водного об'єкта | Фактичний | Описує сутність «Водні об'єкти» | ||
Назва ВО | Фактичний | |||
Назва населеного пункту | Фактичний | |||
Код показника | Фактичний | Описує сутність «Забруднюючі речовини» | ||
Назва показника | Фактичний | |||
Одиниця вимірювання | Фактичний | |||
ГДК комунально-побутове | Фактичний | |||
ГДК рибогосподарське | Фактичний | |||
Список реквізитів, які були отримані на основі вихідних документів представлений у табл. 3.4.
Таблиця 3.4. Список реквізитів вихідних документів
№ п.п. | Найменування реквізиту | Фактичний/ Розрахунковий | Призначення реквізиту | |
Дата | Фактичний | Для формування масиву для занесення інформації моніторингу та оперативного масиву | ||
Рік | Фактичний | |||
Місяць | Фактичний | |||
Код ПК | Фактичний | |||
Назва ПК | Фактичний | |||
Назва ВО | Фактичний | |||
Код показника | Фактичний | |||
Одиниця вимірювання | Фактичний | |||
Кількість | Фактичний | |||
ГДК комунально-побутове | Фактичний | |||
ГДК рибогосподарське | Фактичний | |||
Перевищення ГДК к-п | Розрахунковий | |||
Перевищення ГДК рг | Розрахунковий | |||
3.2.2 Словник даних
У табл. 3.5 приведений повний перелік елементів, які будуть використовуватися для автоматизації функцій обліку та аналізу забруднення поверхневих вод та описувати базу даних системи.
Таблиця 3.5 Словник даних
№ п.п. | Найменування елемента | Ідентифікатор | Тип та довжина | Призначення елемента | |
Адреса ел. пошти користувачі | user_mail | varchar (30) | Атрибут сутності «users» (Користувачі) | ||
ГДК (к-п) забруднюючої речовини | agent_com_gdk | float | Атрибут сутності «agents» (Забрудюючі речовини) | ||
ГДК (рг) ЗР | agent_fish_gdk | float | Атрибут сутності «agents» | ||
Дата внесення інформації моніторингу | date | date | Атрибут сутності «monitoring» (Моніторинг) | ||
Звітний місяць | month | enum ('Січень', 'Лютий', 'Березень', 'Квітень', 'Травень', 'Червень', 'Липень', 'Серпень', 'Вересень', 'Жовтень', 'Листопад', 'Грудень') | Атрибут сутності «monitoring» | ||
Звітний рік | year | year (4) | Атрибут сутності «monitoring» | ||
Ім'я користувача | user_n | varchar (30) | Атрибут сутності «users» | ||
Ім'я користувача системи для входу | username | varchar (255) | Атрибут сутності «users» | ||
Кількість забруднюючої речовини | value | float | Атрибут сутності «monitoring agents» (Результати моніторингу) | ||
Код відомства | inst_id | int (5) | Атрибут сутності «institution» (Відомства) | ||
Код водного об'єкта | water_id | int (5) | Атрибут сутності «waters» (Водні об'єкти) | ||
Код ЗР | agent_id | int (5) | Атрибут сутності «agents» | ||
Код користувача | userid | varchar (255) | Атрибут сутності «users» | ||
Код населеного пункту | loc_id | int (5) | Атрибут сутності «locality» (Населені пункти) | ||
Код одиниці вимірювання | unit_id | int (3) | Атрибут сутності «units» (Одиниці вимірювання) | ||
Код пункту контролю | cp_id | varchar (15) | Атрибут сутності «control points» (Пункти контролю) | ||
Контактний телефон | user_phone | varchar (13) | Атрибут сутності «users» | ||
Координата У ПК | cp_y | flo | Атрибут сутності «control points» | ||
Координата Х ПК | cp_x | float | Атрибут сутності «control points» | ||
Назва ВО | water_name | varchar (25) | Атрибут сутності «waters» | ||
Назва ЗР | agent_name | varchar (30) | Атрибут сутності «agents» | ||
Назва НП | loc_name | varchar (25) | Атрибут сутності «locality» | ||
Назва ОВ | unit_name | varchar (25) | Атрибут сутності «units» | ||
Назва ПК | cp_name | varchar (50) | Атрибут сутності «control points» | ||
Номер запису результату моніторингу | record_id | int (5) | Атрибут сутності «monitoring agents» | ||
Номер проведення моніторингу | rec_id | int (6) | Атрибут сутності «monitoring» | ||
Опис ПК | cp_desc | varchar (100) | Атрибут сутності «control points» | ||
Пароль користувача | password | varchar (255) | Атрибут сутності «users» | ||
По-батькові користувача | user_ln | varchar (30) | Атрибут сутності «users» | ||
Повна назва відомства | inst_name | varchar (50) | Атрибут сутності «institution» | ||
Посада користувача | user_pos | varchar (30) | Атрибут сутності «users» | ||
Права користувача | permission | enum ('admin', 'ecolog') | Атрибут сутності «users» | ||
Прізвище користувача | user_fn | varchar (30) | Атрибут сутності «users» | ||
Скорочена назва відомства | inst_short | varchar (10) | Атрибут сутності «institution» | ||
Скорочена назва ОВ | unit_short | varchar (10) | Атрибут сутності «units» | ||
Характеристика відомства | inst_desc | varchar (100) | Атрибут сутності «institution» | ||
Характеристика ВО | water_desc | varchar (50) | Атрибут сутності «waters» | ||
Характеристика НП | loc_desc | varchar (100) | Атрибут сутності «locality» | ||
Характеристика ЗР | agent_desc | varchar (50) | Атрибут сутності «agents» | ||
3.2.3 Проектування моделей даних для функцій, що автоматизуються
У нашій системі для автоматизації функцій обліку та аналізу забруднення поверхневих вод буде використовуватися один набір сутностей та атрибутів, оскільки аналіз забруднення опирається на дані обліку забруднюючих речовин. Система має наступні сутності, необхідні для вирішення задач:
«agents» — містить інформацію про забруднюючі речовини;
«control_points» — містить інформацію про пункти контролю;
«institution» — містить інформацію про відомства;
«locality» — містить інформацію про населені пункти;
«monitoring» — містить інформацію про внесення даних моніторингу;
«monitoring agents» — містить дані моніторингу;
«units» — містить інформацію про одиниці вимірювання;
«water» — містить інформацію про водні об'єкти Харківської області.
Схема зв’язків сутностей і атрибутів системи наведена на рис. 3.1.
Для кожної із сутностей у табл. 3.6 — табл. 3.13 охарактеризовані обмеження цілісності.
Рис. 3.1. Сутності, які використовуються для автоматизації функцій обліку та аналізу забруднання вод Таблиця 3.6. Обмеження атрибутів сутності «agents»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
agent_id | int | 0.9 | Первісний ключ | |||||
agent_name | varchar | А…Я, A. Z, 0.9 | ||||||
unit_id | int | 0.9 | ||||||
agent_desc | varchar | А…Я, A. Z, 0.9 | ||||||
agent_com_gdk | float | 0.9 | >=0 | |||||
agent_fish_gdk | float | 0.9 | >=0 | |||||
Таблиця 3.7. Обмеження атрибутів сутності «units»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
unit_id | int | 0.9 | Первісний ключ | |||||
unit_name | varchar | А…Я, A. Z, 0.9 | ||||||
unit_short | varchar | А…Я, A. Z, 0.9 | ||||||
Таблиця 3.8. Обмеження атрибутів сутності «control_points»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
cp_id | varchar | А…Я, A. Z, 0.9 | Первісний ключ | |||||
cp_name | varchar | А…Я, A. Z, 0.9 | ||||||
loc_id | int | 0.9 | ||||||
water_id | int | 0.9 | ||||||
inst_id | int | 0.9 | ||||||
cp_desc | varchar | А…Я, A. Z, 0.9 | ||||||
cp_x | float | 0.9 | >0 | |||||
cp_y | float | 0.9 | >0 | |||||
Таблиця 3.9. Обмеження атрибутів сутності «institution»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
inst_id | int | 0.9 | Первісний ключ | |||||
inst_name | varchar | А…Я, A. Z, 0.9 | ||||||
inst_short | varchar | А…Я, A. Z, 0.9 | ||||||
inst_desc | varchar | А…Я, A. Z, 0.9 | ||||||
Таблиця 3.10. Обмеження атрибутів сутності «locality»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
loc_id | int | 0.9 | Первісний ключ | |||||
loc_name | varchar | А…Я, A. Z, 0.9 | ||||||
loc_desc | varchar | А…Я, A. Z, 0.9 | ||||||
Таблиця 3.11. Обмеження атрибутів сутності «water»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
water_id | int | 0.9 | Первісний ключ | |||||
water_name | varchar | А…Я, A. Z, 0.9 | ||||||
water_desc | varchar | А…Я, A. Z, 0.9 | ||||||
Таблиця 3.12. Обмеження атрибутів сутності «monitoring»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
rec_id | int | 0.9 | Первісний ключ | |||||
year | year | 0.9 | xxxx | |||||
month | enum | 'Січень', 'Лютий', 'Березень', 'Квітень', 'Травень', 'Червень', 'Липень', 'Серпень', 'Вересень', 'Жовтень', 'Листопад', 'Грудень' | ||||||
date | date | 0.9 | хх.хх.хххх | |||||
cp_id | varchar | А…Я, A. Z, 0.9 | ||||||
Таблиця 3.13. Обмеження атрибутів сутності «monitoring agents»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
record_id | int | 0.9 | Первісний ключ | |||||
rec_id | int | 0.9 | ||||||
agent_id | int | 0.9 | ||||||
value | float | 0.9 | >=0 | |||||
Обмеження кортежів сутності «monitoring» системи наведене у табл. 3.14.
Таблиця 3.14. Обмеження кортежів сутності «monitoring»
№ п/п | Група атрибутів | Обмеження | |
year, date | year in date and year are same | ||
Обмеження унікальності сутностей системи описані у табл. 3.15 — табл.3.22.
Таблиця 3.15. Обмеження унікальності в сутності «agents»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «agents» | |
agents.agent_id agents.unit_id | Всіх екземплярів сутності «agents» | ||
Таблиця 3.16. Обмеження унікальності в сутності «units»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «units» | |
units.unit_id | Всіх екземплярів сутності «units» | ||
Таблиця 3.17. Обмеження унікальності в сутності «control_points»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «control_points» | |
control_points.cp_id control_points.loc_id control_points.water_id control_points.inst_id | Всіх екземплярів сутності «control_points» | ||
Таблиця 3.18. Обмеження унікальності в сутності «institution»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «institution» | |
institution.inst_id | Всіх екземплярів сутності «institution» | ||
Таблиця 3.19. Обмеження унікальності в сутності «locality»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «locality» | |
locality.loc_id | Всіх екземплярів сутності «locality» | ||
Таблиця 3.20. Обмеження унікальності в сутності «water»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «water» | |
water.water_id | Всіх екземплярів сутності «water» | ||
Таблиця 3.21. Обмеження унікальності в сутності «monitoring»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «monitoring» | |
monitoring.rec_id monitoring.cp_id | Всіх екземплярів сутності «monitoring» | ||
Таблиця 3.22. Обмеження унікальності в сутності «monitoring agents»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «monitoring agents» | |
monitoring agents. record_id monitoring agents. rec_id monitoring agents. agent_id | Всіх екземплярів сутності «monitoring agents» | ||
Динамічні обмеження деяких атрибутів сутностей системи наведені в табл. 3.23 — 3. 29.
Обмеження посилкової цілісності сутностей подані в табл. 3.30 — 3.33.
Таблиця 3.23. Динамічні обмеження сутності «agents»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
agent_id | agent_id= agent_id+1 | ||
Таблиця 3.24. Динамічні обмеження сутності «units»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
unit_id | unit_id= unit_id+1 | ||
Таблиця 3.25. Динамічні обмеження сутності «institution»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
inst_id | inst_id= inst_id+1 | ||
Таблиця 3.26. Динамічні обмеження сутності «locality»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
loc_id | loc_id= loc_id+1 | ||
Таблиця 3.27. Динамічні обмеження сутності «water»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
water_id | water_id= water_id+1 | ||
Таблиця 3.28 Динамічні обмеження сутності «monitoring»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
rec_id | rec_id= rec_id+1 | ||
Таблиця 3.29. Динамічні обмеження сутності «monitoring agents»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
record_id | record_id = record_id +1 | ||
Таблиця 3.30. Правила посилкової цілісності сутності «agents»
№ п/п | Батьківська сутність | Дочірня сутність | Правило видалення | Інші правила | |
units | agents | Каскадне | |||
Таблиця 3.31. Правила посилкової цілісності сутності «control_points»
№ п/п | Батьківська сутність | Дочірня сутність | Правило видалення | Інші правила | |
location | control_points | Каскадне | |||
waters | control_points | Каскадне | |||
institution | control_points | Каскадне | |||
Таблиця 3.32
Правила посилкової цілісності сутності «monitoring»
№ п/п | Батьківська сутність | Дочірня сутність | Правило видалення | Інші правила | |
control_points | monitoring | Каскадне | |||
Таблиця 3.33
Правила посилкової цілісності сутності «monitoring agents»
№ п/п | Батьківська сутність | Дочірня сутність | Правило видалення | Інші правила | |
monitoring | monitoring agents | Каскадне | |||
agents | monitoring agents | Каскадне | |||
У нашій системі окрім функцій обліку та аналізу забруднення поверхневих вод також автоматизуються функції роботи зі списком користувачів системи. На рис. 3.2 зображена структура сутності «users».
Рис. 3.2. Сутність для забезпечення функцій для роботи зі списком користувачів У табл. 3.34 описані обмеження атрибутів сутності «users».
Таблиця 3.34. Обмеження атрибутів сутності «users»
№ п/п | Ім'я атрибуту | Тип | Розмір | Границі або допустимі значення | Структура (формат) | Умова | Значення за замовчуванням | |
user_id | varchar | А…Я, A. Z, 0.9 | Первинний ключ | |||||
user_name | varchar | А…Я, A. Z, 0.9 | ||||||
password | varchar | А…Я, A. Z, 0.9 | ||||||
permission | enum | 'admin', 'ecolog' | ||||||
user_n | varchar | А…Я, A. Z, 0.9 | ||||||
user_fn | varchar | А…Я, A. Z, 0.9 | ||||||
user_ln | varchar | А…Я, A. Z, 0.9 | ||||||
user_mail | varchar | А…Я, A. Z, 0.9 | ||||||
user_pos | varchar | А…Я, A. Z, 0.9 | ||||||
user_phone | varchar | А…Я, A. Z, 0.9 | ||||||
Обмеження унікальності в сутності «users» приведене у табл. 3.35.
Таблиця 3.35. Обмеження унікальності в сутності «users»
№ п/п | Атрибут чи група атрибутів | Унікальне серед атрибутів сутності «users» | |
users. user_id | Всіх екземплярів сутності «users» | ||
Динамічні обмеження сутності приведені у табл. 3.36.
Таблиця 3.36. Динамічні обмеження сутності «users»
№ п/п | Атрибут чи група атрибутів | Обмеження | |
user_id | user_id = user_id +1 | ||
3.2.4 Опис СУБД-орієнтованої моделі даних
В ході проектування бази даних були створені наступні сутності: «agents», «units», «control_points», «waters», «location», «institution», «monitoring», «monitoring agents», «users». Вони необхідні для найбільш зручної роботи з додатком, котрий цілком відповідає предметній області. Для забезпечення мінімальної надмірності повторювана інформація була винесена до окремих довідників. Посилкова цілісність забезпечується за допомогою зовнішніх ключів та функцій бази даних каскадного видалення та оновлення.
Сутність «agents» використовується для зберігання інформації про забруднюючі речовини. Сутність має зовнішній ключ з сутності «units», для вибору одиниці вимірювання.
Сутність «units» використовується для збереження інформації про одиниці вимірювання. Містить код, назву, та скорочення одиниці вимірювання. Є батьківською сутністю для сутності «agents».
Сутність «control_points» використовується для зберігання інформації про пункти контролю. Містить код, назву, опис ПК, а також зовнішні ключі з сутностей «location», «institution» та «waters», які вказують на зв’язок ПК з населеним пунктом, водним об'єктом та відомством.
Сутність «waters» використовується для зберігання інформації про водні об'єкти Харківської області. Містить код, назву та описання водойми. Є батьківською для сутності «control_points», що вказує на те, що один водний об'єкт може мати декілька пунктів спостереження.
Сутність «location» використовується для збереження інформації про населені пункти, на території яких знаходяться ПК. Містить код, назву та опис населеного пункту. Є батьківською для сутності «control_points», що вказує на те, що один населений пункт може мати декілька ПК.
Сутність «institution» використовується для збереження інформації про відомства, яким підпорядковується пункт контролю. Містить код, назву, скорочену назву та опис відомства. Є батьківською сутністю для «control_points», що свідчить про те, що одному відомству може підпорядковуватися декілька пунктів контролю.
Сутність «monitoring» використовується для збереження інформації про проведення екологічного моніторингу. Містить наступну інформацію моніторингу: рік, місяць та дату проведення моніторингу, а також код запису та код ПК, який проводить моніторинг. Сутність «monitoring agents» використовується як проміжна таблиця для усунення зв’язку багато-до-багатьох між сутностями «monitoring» та «agents». Містить інформацію про кількісні показники забруднюючих речовин, які були отримані під час моніторингу. Сутність «users» використовується для зберігання інформації про користувачів системи та для обмеження доступу до системи. Містить інформацію про логін, пароль, прізвище, ім'я та по-батькові, посаду, контактний телефон, та посилання на роль користувача. Словник ролей використовується для розмежування доступу до різних функцій програми між екологом-аналітиком та адміністратором системи. На рис. 3.4 приведена глобальна фізична модель бази даних системи.
Рис. 3.3. Глобальна фізична модель бази даних «Системи обліку забруднюючих речовин Харківської області»
У додатку, А поданий SQL-скрипт з командами генерації та внесення інформації до описаних вище об'єктів зберігання інформації.
3.3 Опис архітектури додатку. Розгортання програмного продукту
3.3.1 Мінімальні системні характеристики
У цьому пункті наведені вимоги до апаратного забезпечення клієнтської частини. Для нормального функціонування системи необхідна наступна мінімальна конфігурація персонального комп’ютера:
— 512 Мбайт ОЗП і вище;
— 100 Мбайт вільного дискового простору;
— відеокарта з підтримкою дозволу не менше 800×600 і можливістю відображення не менше 256 кольорів;
— монітор SVGA;
— процесор 800 МГц або вище;
— мережевий адаптер 100 М/біт.
Вимоги до апаратного забезпечення серверної частини:
— процесор Intel Pentium 4 або аналогічний з рейтингом 1.8 ГГц або вище;
— 1 Гбайт ОЗП;
— 1 Гбайт вільного дискового простору;
— відеокарта з роздільною здатністю не менше 800×600 і можливістю відображення не менше 256 кольорів;
— мережевий адаптер 1 Г/біт.
3.3.2 Вимоги до програмного забезпечення
На комп’ютері користувача системи попередньо повинне бути встановлене таке програмне забезпечення:
— операційна система Windows XP, або Windows Vista, або Windows 7;
— Інтернет-браузер (Google Chrome, Mozila FireFox, Internet Explorer, Opera).
Вимоги до програмного забезпечення серверної частини:
— операційна система Linux CentOS 5.4;
— Web-сервер Apache 2.2;
— СУБД MySQL 5.6;
— РНР-інтерпретатор 5.3.
3.3.3 Спосіб виклику програми, запуск програми
Оскільки було розроблено додаток з Web-інтерфейсом, то для його запуску необхідно запустити Інтернет-браузер та перейти по наступній URL-адресі: http:/www.gidro-kharkiv.ho.ua.
3.3.4 Спосіб установки системи
Для того, щоб встановити додаток необхідно завантажити скрипти програмного продукту в кореневий каталог веб-серверу, внести відповідні налаштування до файлу конфігурації config. php, запустити скрипт завантаження дампу бази даних.
Висновки
У результаті виконання даного дипломного проекту було розроблено спеціалізований програмний продукт. На основі аналізу предметної області були розроблені функціональні та не функціональні вимоги, діаграма варіантів використання та діаграма станів, а також була спроектована база даних що вказує на повноту виконання поставленої задачі.
Завдяки розробці даної спеціалізованої системи, яка на даному етапі може бути впроваджена лише у відділі підключення клієнтів у підприємствах з надання послуг доступу до мережі Інтернет, було автоматизовано такі бізнес-процеси як ведення реєстру договорів та ведення реєстру підключення та перепідключення клієнтів, що значно скорочує час та трудовитрати на дані бізнес-процеси підприємства.
Дана версія продукту може бути впроваджена у відділ підключення у підприємствах з надання послуг доступу до мережі Інтернет.
Результати роботи були представлені на «Міжнародній науково-практичній конференції молодих вчених, аспірантів та студентів на тему „Актуальні проблеми науки та освіти молоді: теорія, практика, сучасні рішення“» та.
Наступні версії продукту будуть направлені на автоматизацію інших бізнес-процесів підприємств з надання послуг доступу до Інтернет для повної автоматизації їх роботи.