ЗМІСТ
ЗМІСТ 1
ВСТУП 1
1. Проектування модулів прикладних програм баз даних 2
1.1 Розглядається процес складання специфікацій модулів застосувань бази даних і початкова підготовка їх до тестування. 2
1.2 Аналіз функціональної моделі предметної області бази даних 3
1.3 Визначення функцій 5
1.4 Відображення функцій в модулі 6
1.5 Системні модулі 13
1.6 Розміщення логіки обробки 13
2. Загальні принципи розробки специфікацій модулів 16
3. Проектування процесу тестування модулів застосувань 20
ВИСНОВКИ 28
СПИСОК ЛІТЕРАТУРИ 28
ВСТУП
Навіть добре спроектована база даних нічого не коштує без застосувань, які забезпечують її життєдіяльність, переводячи її з одного актуального стану в інше і тим самим задовольняючи потреби користувачів в інформації. При цьому користувачі чекають програм, які допомагали б їм вирішувати їх завдання швидко і мали широкі можливості пошуку і обробки інформації. Тому проектувальникові бази даних слід також звернути увагу на проектування модулів застосувань, які доповнюватимуть базу даних.
Як вже відзначалося вище, на етапі аналізу аналітики іТ-проекту розробляють функціональну модель предметної області. Ця модель є вхідними даними для етапу проектування модулів застосувань бази даних.
1. Проектування модулів прикладних програм баз даних
1.1 Розглядається процес складання специфікацій модулів застосувань бази даних і початкова підготовка їх до тестування.
Елементи функціональної моделі дозволяють описати функції обробки даних, організувати їх відповідно до бізнес-вимог і, отже, побудувати відображення цих функцій в набір визначень модулів застосувань. При цьому слід дотримуватися наступних двох правив: уникати створення дублюючого коду і прагнути не створювати великих модулів із складною логікою.
Як правило, проектування модулів застосувань виконується паралельно з проектуванням фізичної структури бази даних. Ці два завдання взаємозв'язані. Практично будь-яке рішення в моделюванні даних майже завжди вигідно для одних модулів і створює проблеми для інших.
Приклад. Припустимо, що при пошуку одного виду структурованого документу, розміщеного в таблиці бази даних, використовуються два ідентифікатори: внутрішній номер організації, генерований системою, і абревіатура організації (коротке найменування). Наявність в базі даних цих колонок є проектне рішення. На екранній формі пошуку (модуль застосування) в таких документах використовуються два списки, що розкриваються. Один список сформований по номеру організації, а інший - по її абревіатурі.
Підтримка двох ідентифікаторів, що фактичних визначають однозначно одну і ту ж організацію, створює наступну проблему для модуля введення документу : при помилці в наборі абревіатури одна і та ж організація матиме два короткі найменування. Щоб уникнути такої ситуації, в модулі введення документу має бути передбачений код, який забезпечує введення абревіатур через список, що розкривається, а в модулі введення даних про організації передбачено, щоб поле абревіатури було не порожнє.
Тому проектувальник бази даних повинен враховувати наслідки вибираних ним рішень і вибирати компромісний варіант.
1.2 Аналіз функціональної моделі предметної області бази даних
Щоб спроектувати модулі застосувань, необхідно знати, як працюватиме інформаційна система з базою даних. Таку інформацію можна отримати з функціональної моделі предметної області бази даних. Для проектування модулів застосувань проектувальникові бази даних потрібний набір специфікацій функцій, які задають необхідні вимоги до обробки бізнес-даних, а також набір залежностей між різними бізнес-функціями.
Фактично це означає, що входом для вирішення завдання проектування модулів застосувань бази даних є ієрархія функцій. На виході проектувальник повинен отримати опис (специфікацію) модулів застосувань, а в процесі проектування модулів проектувальник будує відображення бізнес-вимог в специфікації модулів.
Алгоритм дій проектувальника бази даних полягає в наступному: спочатку проектувальник намагається сформулювати бізнес-вимоги (функції) в найзагальнішому вигляді, а потім виконує декомпозицію кожній такій бізнес-функції до тих пір, поки не буде отримана деяка функція, яку можна вважати атомарною функцією. Критерієм атомарності функції є отримання відповіді на питання, чи має сенс виконати тільки частину функції.
Приклад. Розглянемо фрагмент ієрархії функцій для обробки заяв про виплату страхового відшкодування. На спрощеній схемі рис. 1 показана функція "2. Обробити заяву". Виконання цієї функції включає виконання чотирьох функцій наступного рівня : "2.1. Зареєструвати заяву", "2.2. Прийняти рішення за заявою", "2.3. Провести платіж за заявою", "2.4. Закрити заяву".
На рис. 1 показана подальша декомпозиція функції "2.2. Прийняти рішення за заявою". Отримана на цьому етапі функція "2.2.5. Дозволити ремонт" є атомарною функцією. Ремонт дозволяється або не дозволяється.
2.2.1 Поліс діє
2.2.2 Заяву забезпечено
2.2.3 Отримати попередню суму відшкодування
2.2.4 Отримати ціни на ремонт
2.2.5 Дозволити ремонт
Рис. 1. Ієрархія функції для обробки заяв про виплату страхового відшкодування
При розгляді ієрархії функцій проектувальникові бази даних слід звернути увагу на наступні моменти:
у функціональній моделі бази даних описуються бізнес-функції, і не усі вони безпосередньо підтримуватимуться застосуванням бази даних;
при розгляді ієрархій нерідко виникає ситуація, коли екземпляри однієї і тієї ж функції матимуть різні номери.
Якщо в першому випадку додаткову інформацію про те, які бізнес-функції будуть реалізовані в системі, можна отримати від керівника проекту, то в другому випадку проектувальник бази даних, найімовірніше, має справу з помилкою аналітика у визначенні функції.