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

Криворізький технічний університет

Методичні вказівки

до виконання курсового проекту з дисципліни «Організація та проектування баз даних».

для студентів спеціальності 8.0914.01

усіх форм навчання

Кривий Ріг

2007

УДК 681.3.07

ББК 32.973

Б

Рецензенти: професор каф. ЕМОМЗ, Криворізького металургійного факультету НМА України Г.І. Корнілов

к.т.н., доцент каф ІАСУ КТУ О.І. Савицький

Методичний вказівки до виконання курсового проекту з дисципліни «Організація та проектування баз даних» для студентів спеціальності 8.0914.01 усіх форм навчання. / Укладачі П.В. Бурнасов, С.В. Пересунько – Кривий Ріг: КТУ, 2007.

Укладач: Бурнасов Павло Вікторович

Пересунько Світлана Вікторівна

Відповідальний за випуск: В. М. Назаренко,

академік Міжнародної Академії

комп’ютерних наук і систем,

проф., докт. техн. наук

Зміст

1. Основи проектування програмних систем 4

2. Мета та завдання курсового проекту 9

2.1. Етапи виконання курсового проекту 9

3. Опис програмного проекту 10

3.1. Постановка задачі 10

3.1.1. Опис задачі 10

3.1.2. Вимоги до програмно-апаратного комплексу 11

3.1.3. Вибір СУБД 12

3.1.4. Розробка тестової задачі 17

3.2. Проектування задачі 17

3.2.1. Проектування бази даних 18

3.2.2. Проектування форм 21

3.2.3. Проектування звітів 22

3.2.4. Проектування меню додатку 23

4. Вимоги до оформлення пояснювальної записки 25

5. Література 29

6. Додатки 31

Додаток А 31

Форма титульного аркуша курсового проекту (роботи) 31

Додаток Б 32

Форма титульного аркуша курсового проекту (роботи) 32

Додаток В 33

Форма подальших аркушів пояснювальної записки 33

1.Основи проектування програмних систем

До основних стадій розвитку програмної системи відносяться наступні:

• постановка задачі,

• розробка і проектування,

• реалізація (програмування),

• випробування й експлуатація системи,

• виведення з експлуатації.

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

Структурний аналіз.

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

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

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

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

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

Реалізація й випробування.

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

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

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

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

Процес проектування системи включає:

• визначення різних потоків даних (вхідних, проміжних, вихідних),

• формалізацію процедур обробки, які виконуються над цими потоками,

• вибір методів обробки потоків, послідовних або паралельних,

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

Потік даних у системі визначаються відповідно до наступних правил:

1. Кожному джерелу даних відповідає один вхідний потік.

2. Якщо є сукупність наборів даних, які одержують з декількох джерел, ці набори розподіляються по групах оброблюваних спільно потоків даних.

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

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

Після того як визначені потоки даних, необхідно визначити процеси, що оперують цими потоками:

1. Якщо потоки даних обробляються порізно, для кожного з них потрібно окремий процес.

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

3. Якщо деякі з проміжних потоків даних необхідно зберігати з метою їхнього наступного використання, повинні бути передбачені:

   • процес, за допомогою якого здійснюється їхнє запам'ятовування,

   • процес для супроводу таких потоків (якщо буде потрібно коректування)

   • процес для пошуку й обробки даних.

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

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