 |
|
Постановочний розділ
3.9.1. У цьому розділі, який повинен мати близьку за змістом назву, здійснюється постановка задачіта обґрунтування вибраних технологій програмної інженерії, методів та алгоритмів розв’язання поставлених завдань.
3.9.2. Постановка задачі повинна чітко вказати що потрібно зробити дипломнику для досягнення якої мети.
3.9.3. Цей розділ має містити характеристику об’єкта проектування та вимоги до нього, вхідні та вихідні дані проекту.
3.9.4. Далі в розділі проводиться аналіз вимог та подається специфікація вимог. Специфікація вимог передбачаєпідготовку повного і чіткого визначення задачі; представлення документів з вимогами до системи для погодження із керівником.
3.9.5. На цьому етапі дипломник повинен скласти специфікацію вимог за нижче поданою схемою (додаток Е), використовуючи ті пункти, які необхідні для опису саме його проекту .
3.9.6. У цьому розділі також потрібно описати вибір шляхів та засобів досягнення поставленої у завданні мети, повинні бути показані переваги вибраного напряму щодо розв’язання задач за темою дипломного проекту порівняно з іншими можливими напрямами. У ньому проводиться мотивована оцінка прийнятого (розробленого) напряму як з технічного, так і економічного погляду. Тут приводиться вибір та обґрунтування технологічних засобів виконання роботи таких, як вибір архітектури програмного забезпечення (програми, пакети програм, програмні комплекси, програмні системи), вибір типу інтерфейсу і технології роботи з документами, вибір підходу до розробки (структурного чи об’єктного), вибір мови та середовища програмування.
3.9.7. Обґрунтування вибраного напряму проектування (методу, алгоритму, структурної чи функціональної схеми, необхідних інструментальних та технологічних засобів тощо) повинно використовувати інформацію та рекомендації, наведені в оглядовому огляді, з врахуванням результатів роботи, проведеної студентом. Обґрунтування вибраного напряму проектування не повинно підміняти доцільність самої роботи. Вибір напряму проектування не повинен обґрунтовуватися вимогами завдання на виконання дипломного проекту.
3.9.8. Обсяг цього розділу 4-5 сторінок.
Проектний розділ
3.10.1. У цьому розділі, який повинен мати близьку, але конкретну за змістом назву, приводяться всі основні технічні аспекти розв’язання поставленої задачі, описуються запропоновані рішення, отримані результати з розробки алгоритмічних, функціональних та програмних складових дипломного проекту.
3.10.2. Результатом проектування є детальна модель програмного забезпечення, що розробляється. Тип моделі залежить від вибраного підходу (структурний, об’єктний чи компонентний) і конкретної технологій проектування. У будь-якому випадку проектування охоплює як проектування програм (підпрограм) і визначення взаємозв’язків з ними, так і проектування даних, з якими взаємодіють ці програми (підпрограми).
3.10.3. На етапі проектування дипломник має визначити архітектуру системи, спроектувати базу даних, інтерфейс користувача та об’єктну модель програмного засобу, що розробляється. Також, на етапі проектування розробляються проектні рішення, важливі для реалізації системи.
3.10.4. Архітектура системи, як правило, базується на одному або кількох відомих архітектурних стилях, таких як багаторівнева архітектура, розподілена архітектура, модульна архітектура, конвеєрна архітектура та інші.
3.10.5. Для опису архітектури рекомендується використовувати діаграми UML з текстовими поясненнями.
3.10.6. Для представлення статичного аспекту архітектури слід використовувати діаграми компонент (логічна архітектура) та діаграми розміщення (фізична архітектура). Для кожної компоненти та вузла на цих діаграмах необхідно описати його призначення та перелічити основні відповідальності. Динамічна складова архітектури представляється за допомогою діаграм станів та діаграм діяльностей. Стани та діяльності дозволяють графічно описати бізнес-процеси та бізнес-правила, закладені в систему.
3.10.7. Значна частина проектів, які розробляються у бакалаврській дипломній роботі, спрямована на розробку і створення програмних продуктів, у рамках яких здійснюється обробка даних різної складності. Метою таких проектів є розробка і створення додатків з базами даних. Практично в усіх таких проектах вирішується завдання проектування баз даних.
Процес проектування бази даних повинен охоплювати наступні умови:
· проектування бази даних під основне бізнес-середовище системи (інтелектуальний аналіз даних, OLAP, OLTP і т.п.).
· проектування бази даних під конкретне обчислювальне середовище (архітектура «клієнт-сервер», розподілене обчислювальне середовище, паралельна архітектура).
· проектування об’єктів бази даних (таблиці, представлення, індекси, тригери, збережені процедури, функції) для відображення даних предметної області в базі даних.
· проектування інтерфейсу взаємодії з базою даних (форми, звіти і т.п.) і проектування додатків роботи з базою даних. Зауважимо, що додатки роботи з базою даних проектуються одночасно з фізичною схемою бази даних.
3.10.8. Початковими даними для вирішення завдань проектування бази даних є результати аналізу предметної області. Тому проектувальник повинен знати концепції, які лежать в основі моделювання даних предметної області, і конструкції, які утворюють сукупність цих моделей. Процес проектування бази даних може бути представлений у вигляді контекстної діаграми (рис. 1).
3.10.9. На вхід процесу проектування бази даних подаються:
· інформаційна модель предметної області бази даних : діаграми «суть-зв’язок» (ER-діаграми);
· функціональна модель предметної області бази даних: модель бізнес-процесів, діаграми потоку даних (DFD), діаграми станів, діаграми життєвих циклів сутностей, специфікації для системи (вимоги), бізнес-правила;
· загальносистемні вимоги і обмеження;
· задачі взаємодії – тут розуміється сукупність проблем, які виникають в процесі розробки додатків роботи з базою даних, їх тестування та експлуатації. Прикладом такої задачі є оптимізація запитів з метою збільшення продуктивності вибірки.
3.10.10. На виході процесу проектування бази даних формуються наступні результати:
· фізична модель бази даних, яка може бути перетворена у скрипт для створення бази даних; скрипт подається у додатку до пояснювальної записки;
· фізична база даних;
· специфікація модулів додатків бази даних;
· план тестування бази даних; подається в розділі реалізації та тестування.
За потреби може бути розроблена й інша документація.
Рис. 1. Контекстна діаграма процесу проектування бази даних
3.10.11. Основними етапами проектування бази даних є:
– збір та аналіз вхідних даних;
– побудова логічної моделі бази даних;
– створення фізичної моделі бази даних
– створення серверного коду;
– проектування модулів додатків бази даних;
– контроль якості проектування бази даних.
3.10.12. Після процесу проектування бази даних відбувається реалізація спроектованої схеми бази даних у вигляді реальної бази даних, яка отримується як результат виконання скрипта створення бази даних у вибраній СУБД (наприклад, SQL/DDL-скрипта) і внесення усіх необхідних даних. Створюється сховище даних, яке забезпечує доступ до даних додатків роботи з базою даних, а також забезпечує збереження даних після завершення роботи додатків і програмної системи загалом.
3.10.13. Графічний інтерфейс користувача представляється за допомогою схеми переходів між екранами (сторінками) та макетів для кожного екрану (сторінки). Для екранів не вимагається подання їх фінального вигляду, головним є наповнення екранів потрібними функціональними елементами управління, такими як кнопки, прапорці, списки, таблиці, тощо.
3.10.14. Об’єктна модель представляється за допомогою діаграм UML. Для цього використовуються діаграми класів (об’єктів) та діаграми взаємодій (послідовностей, комунікацій та часу). На діаграмах відображаються лише основні класи та взаємодії, характерні для даної предметної галузі та програмної системи. Другорядні та допоміжні елементи (класи колекцій, методи читання/запису властивостей, типові створення об’єктів, тощо) не розглядаються на етапі проектуванні, вони формуються безпосередньо під час програмної реалізації.
3.10.15. Для опису основних проектних рішень можна використовувати як графічну (діаграми UML) так і текстову інформацію. Рівень деталізації має бути достатнім для безпосереднього кодування рішень на мові програмування. Якщо для реалізації проектних рішень використовуються готові програмні каркаси (frameworks), це має бути зазначено.
3.10.16 Для ДП, які пов’язані з побудовою алгоритмів та розробленням відповідних структур даних, важливо у проектному розділі детально описати алгоритми і структури даних.
3.10.17. Детальну блок-схему алгоритму рекомендується оформляти окремим аркушем графічної частини проекту. При оформленні блок-схем алгоритмів доцільно дотримуватися вимог діючих стандартів та нормативів.
3.10.18 Описуючи структури даних необхідно використати текстові пояснення, схематичні зображення, відповідний математичний апарат (матриці, формули і т.п.).
3.10.19 Для графічного представлення результатів проектування рекомендується використовувати інструмент MS Visio, який містить широкий набір діаграм, схем та планів.
3.10.20. Обсяг цього розділу складає 7-10 сторінок.