Рекомендована структура для виконання дипломної роботи 2 страница

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

Механізм отримання і відправки даних забезпечує з'єднання з джерелом даних (часто опосередковано). Він повинен "знати", куди йому звертатися і який протокол обміну використовувати для забезпечення двонаправленого потоку даних.

Механізм внутрішнього подання даних є ядром програми баз даних. Він забезпечує зберігання отриманих даних у додатку і надає їх на вимогу інших частин програми.

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

Бізнес-логіка додатки являє собою набір реалізованих в програмі алгоритмів обробки даних.

Між додатком і власне базою даних знаходиться спеціальне програмне забезпечення (ПЗ), що зв'язує програму і джерело даних і управляє процесом обміну даними. Це ПЗ може бути реалізовано найрізноманітнішими способами, в залежності від обсягу бази даних, що вирішуються системою завдань, числа користувачів, способами з'єднання програми та бази даних. Проміжне ПЗ може бути реалізовано як оточення додатки, без якого воно взагалі не буде працювати, як набір драйверів і динамічних бібліотек, до яких звертається додаток, може бути інтегроване в сам додаток. Нарешті, це може бути окремий віддалений сервер, обслуговуючий тисячі додатків.

Кілька років тому книгу по Delphi 2 або 3 треба було починати з азів об'єктно-орієнтованого програмування (ООП). Багато хто тільки переходили до Delphi з DOS, багато хто використовував Borland Pascal for Windows і працювали з Windows API безпосередньо. Об'єкти ще були в дивину, і повне роз'яснення нових принципів було просто обов'язково.

Але і зараз писати про це цілком актуально. Звичайно, виросло покоління програмістів, які "з молоком матері" ввібрали нові поняття. Але від розуміння об'єктів до їх грамотного використання - дистанція величезного розміру. Для створення більш-менш складних додатків потрібні навички об'єктно-орієнтованого дизайну, а для додатків в свою чергу - чітке знання можливостей вашого середовища програмування. Тому в цьому розділі ми постараємося акцентувати увагу читача на застосування ООП в середовищі Delphi 7.

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

Для розміщення компонентів доступу до даних в додатку баз даних бажано використовувати спеціальну "форму" - модуль даних (клас TDataModule). Зверніть увагу, що модуль даних не має нічого спільного із звичайною формою додатка, адже його безпосереднім предком є ​​клас TComponent. У модулі даних можна розміщувати тільки невізуальні компоненти. Модуль даних доступний розробнику, як і будь-який інший модуль проекту, на етапі розробки. Користувач додатка не може побачити модуль даних під час виконання.

Для створення модуля даних можна скористатися Репозиторієм об'єктів або головним меню Delphi. Значок модуля даних Data Module розташований на сторінці New.

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

Для створення структури (моделі, діаграми) даних, з якою працює додаток, можна скористатися можливостями, наданими сторінкою Diagram Редактора коду. Будь-який елемент з ієрархічного дерева компонентів модуля даних можна перенести на сторінку діаграми і задати зв'язки між ними.

За допомогою кнопок можна задавати між елементами діаграми відносини синхронного перегляду і головний / підлеглий. При цьому проводиться автоматичне налаштування властивостей відповідних компонентів.

У Репозиторії Delphi відсутній окремий шаблон для програми баз даних. Тому, як і будь-яке інше додаток Delphi, додаток баз даних починається із звичайної форми. Безумовно, це виправданий підхід, т. К. Додаток баз даних має користувальницький інтерфейс. І цей інтерфейс створюється з використанням стандартних і спеціалізованих візуальних компонентів на звичайних формах.

Візуальні компоненти відображення даних розташовані на сторінці Data Controls Палітри компонентів. У більшості вони являють собою модифікації стандартних елементів управління, пристосованих для роботи з набором даних.

Додаток може містити довільне число форм і використовувати будь-який інтерфейс (MDI або SDI). Зазвичай одна форма відповідає за виконання групи однорідних операцій, об'єднаних загальним призначенням.

В основі будь-якої програми баз даних лежать набори даних, які являють собою групи записів (їх зручно представити у вигляді таблиць в пам'яті), переданих з бази даних в додаток для перегляду і редагування. Кожен набір даних инкапсулирован в спеціальному компоненті доступу до даних. У VCL Delphi реалізований набір базових класів, що підтримують функціональність наборів даних, і практично ідентичні за складом набори дочірніх компонентів для технологій доступу до даних. Їх загальний предок - клас TDataSet.

Для забезпечення зв'язку набору даних з візуальними компонентами відображення даних використовується спеціальний компонент TDataSource. Його роль полягає в управлінні потоками даних між набором даних і пов'язаними з ним компонентами відображення даних. Цей компонент забезпечує передачу даних у візуальні компоненти і повернення результатів редагування в набір даних, відповідає за зміну стану візуальних компонентів при зміні стану набору даних, передає сигнали керування від користувача (візуальних компонентів) в набір даних. Компонент TDataSource розташований на сторінці Data Access Палітри компонентів.

Таблиця 2.1

Компонент	Піктограма	Панель компонентів	Опис
Edit (вікно редагування)		Standard	Відображення, введення та редагування однорядкових текстів. Є можливість оформлення об'ємного бордюру. Основна властивість — Text.
Label (позначка)		Standard	Відображення тексту, який не з-змінюється користувачем. Ніякого оформлення тексту не передбачено, крім кольору позначки та тексту. Основна властивість — Caption.
Button (командная кнопка)		Standard	Використовується для створення кнопок, якими користувач виконує команди у додатку.
GroupBox (групове вікно)		Standard	Є контейнером, що об’єднує групу пов'язаних органів управління, таких, як радіокнопкі RadioButton, контрольні індикатори Checkbox і т.д.
CheckBox (контрольний індикатор з прапорцем)		Standard	Дозволяє користувачеві вмикати та вимикати опції програми.
PaintBox (вікно для малювання)		System	Використовується для створення на формі деякої області, в якій можна малювати.
ColorBox (список цветов)		Additional	Спеціальний варіант ComboBox для вибору одного з системних кольорів.
ComboBox (редактируемый список)		Standard	Об’єднує функції ListBox та Edit. Користувач може або ввести текст, або вибрати його із списку.
Timer (таймер)		System	Використовується длязапуску процедур, функцій та подій у вказані інтервали часу.
MainMenu (головне меню)		Standard	Дозволяє конструювати та створювати смугу головного меню форми та випадаючі меню. Компонент не-візуальний.
OLEContainer (контейнер OLE)		System	Використовується при створенні області клієнта для об'єкта OLE.

SQL - це легкий для розуміння мову і в той же час універсальне програмне засіб управління даними.

Успіх мови SQL принесли наступні його особливості:

• незалежність від конкретних СУБД;

• переносимість з однієї обчислювальної системи на іншу;

• наявність стандартів;

• схвалення компанією IBM (СУБД DB2);

• підтримка з боку компанії Microsoft (протокол ODBC);

• реляційна основа;

• високорівнева структура, що нагадує англійську мову;

• можливість виконання спеціальних інтерактивних запитів:

• забезпечення програмного доступу до баз даних;

• можливість різного представлення даних;

• повноцінність як мови, призначеного для роботи з базами даних;

• можливість динамічного визначення даних;

• підтримка архітектури клієнт / сервер.

Всі перераховані вище фактори стали причиною того, що SQL став стандартним інструментом для управління даними на персональних комп'ютерах, мінікомп'ютерах і великих ЕОМ. Нижче ці чинники розглянуті більш докладно. [3,18 ].

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

Постачальники СУБД пропонують програмні продукти для різних обчислювальних систем: від персональних комп'ютерів і робочих станцій до локальних мереж, міні-комп'ютерів і великих ЕОМ. Програми, створені за допомогою SQL і розраховані на однокористувацькі системи, в міру свого розвитку можуть бути перенесені в більші системи. Інформація з корпоративних реляційних баз даних може бути завантажена в бази даних окремих підрозділів або в особисті бази даних. Нарешті, додатки для реляційних баз даних можна спочатку змоделювати на економічних персональних комп'ютерах, а потім перенести на дорогі багатокористувацькі системи.

RAD (від англ. швидкої розробки додатків -. Швидка розробка додатків) - концепція створення засобів розробки програмних продуктів, що приділяє особливу увагу швидкості і зручності програмування, створенню технологічного процесу, що дозволяє програмісту максимально швидко створювати комп'ютерні програми. З кінця XX століття RAD набула широкого поширення і схвалення. Концепцію RAD також часто пов'язують з концепцією візуального програмування.

Основні принципи RAD

Інструментарій повинен бути націлений на мінімізацію часу розробки.

Створення прототипу для уточнення вимог замовника.

Циклічність розробки: кожна нова версія продукту грунтується на оцінці результату роботи попередньої версії замовником.

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

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

Управління проектом має мінімізувати тривалість циклу розробки.

Концепція RAD стала відповіддю на незграбні методи розробки програм 1970-х і початку 1980-х років, такі як «модель водоспаду» (англ. Водоспад модель). Ці методи передбачали настільки повільний процес створення програми, що часто навіть вимоги до програми встигали змінитися до закінчення розробки. Засновником RAD вважається співробітник IBM Джеймс Мартін, який у 1980-х роках сформулював основні принципи RAD, ґрунтуючись на ідеях Баррі Бойм і Скотта Шульца. А в 1991 році Мартін опублікував відому книгу, в якій детально виклав концепцію RAD і можливості її застосування. В даний час RAD стає загальноприйнятою схемою для створення засобів розробки програмних продуктів. Саме засоби розробки, засновані на RAD, мають найбільшу популярність серед програмістів.

Середовища розробки, що використовують принципи RAD

Borland Delphi

Borland C + + Builder

Microsoft Visual Studio

Macromedia Flash

Macromedia Authorware

Macromedia Director

Omnis Studio

Visual DataFlex

IntraWeb

Швидка розробка додатків

Швидка розробка додатків (RAD) - це життєвий цикл процесу проектування, створений для досягнення більш високих швидкості розробки та якості ПЗ, ніж це можливо при традиційному підході до проектування

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

Найбільш суттєвими з них є:

- висока швидкість розробки;

- низька вартість;

- високу якість.

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

Коли застосовується RAD

Застосування технології RAD доцільно, коли:

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

нечітко визначено вимоги до ПЗ. У більшості випадків замовник дуже приблизно уявляє собі роботу майбутнього програмного продукту і не може чітко сформулювати всі вимоги до ПЗ. Вимоги можуть бути взагалі не визначені до початку проекту або можуть змінюватися по ходу його виконання.

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

інтерфейс користувача (GUI), є головний фактор. Немає сенсу змушувати користувача малювати картинки. RAD технологія дає можливість продемонструвати інтерфейс в прототипі, причому досить скоро після початку проекту.

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

ПО не має велику обчислювальною складністю.

Сучасні засоби швидкої розробки вікна-при-ложений, так звані радий-засоби (рад розшифровується як швидка розробка додатків), мають в тій чи іншій мірі майже всіма можливостями реалізації в додатках подібних інтерфейсних елементів. Багато з них дозволяють здійснювати доступ до баз даних, у тому числі і до серверних БД. Borland Delphi (як версія 1.0, так і версія 2.0), на погляд автора, є в цьому відношенні найбільш простим і зручним у використанні засобом.

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

Принципи RAD технології спрямовані на забезпечення трьох основних її переваг - високій швидкості розробки, низької вартості і високої якості. Досягти високої якості програмного продукту досить непросто і одна з головних причин виникаючих труднощів полягає в тому, що розробник і замовник бачать предмет розробки (ПО) по-різному.

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

Основні принципи RAD можна сформулювати наступним чином:

Робота ведеться групами. Типовий склад групи - керівник, аналітик, два програміста, технічний письменник. Якщо проект складний, то для нього може бути виділено кілька RAD-груп. Розробка проекту виконується в умовах тісної взаємодії між розробниками та Замовником.

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

Ітераційне прототипування. Розробка системи і пред'явлення її замовнику здійснюється у вигляді послідовності розвиваються прототипів. Будь-який з прототипів реалізує певну частину функціональності, необхідної від кінцевого продукту. При цьому кожний наступний прототип включає всю функціональність, реалізовану в попередньому прототипі, з додаванням нової. Число прототипів визначається на основі врахування різних параметрів - розміру проекту, аналізу ризиків, побажань замовника і т. д. Традиційно для проектів ПО середньої складності розробляються три прототипи. Перший містить весь призначений для користувача інтерфейс з нульовою функціональністю. Він дає можливість зібрати зауваження замовника і після їх усунення затвердити у нього екранні і звітні форми. Другий прототип містить реалізовану на 70-80% функціональність системи, третій - повністю реалізовану функціональність. Підставами для чергової ітерації є:

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

Деталізація. Виконується програмування нереалізованої частини системи відповідно до складеного плану.

Аналіз результатів програмування. Виправляються помилки, підвищується ефективність програмного коду і т. д.

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

Якщо проект складний, то для нього може бути виділено кілька RAD груп. Великі системи розбиваються на підсистеми. Кожна підсистема розробляється незалежною групою. Ключ успіху - правильне розбиття системи на підсистеми. Команди повинні використовувати загальні стандарти. Обов'язково фінальне тестування повної системи.

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

Принципи RAD застосовуються не тільки при реалізації, але і поширюються на всі етапи життєвого циклу, зокрема на етап обстеження організації, побудови вимог, аналіз і дизайн.

Розмірковуючи про «ідеологічну сумісності" Free Pascal та Delphi, необхідно віддати належне проекту Лазаря, в рамках якого і реалізується ідеологія швидкого візуального програмування. В основі проекту лежить бібліотека візуальних компонентів Lazarus (LCL), для якої декларується сумісність з візуальними компонентами VCL з Delphi. Бібліотека LCL є платформо незалежність і затверджується, що вихідні коди додатків можуть бути експортовані на будь-яку з підтримуваних платформ.

Сучасні засоби швидкої розробки вікна-додатків, так звані радий-засоби (рад розшифровується як швидка розробка додатків), мають в тій чи іншій мірі майже всіма можливостями реалізації в додатках подібних інтерфейсних елементів. Багато з них дозволяють здійснювати доступ до баз даних, у тому числі і до серверних БД. Borland Delphi (як версія 1.0, так і версія 2.0), на погляд автора, є в цьому відношенні найбільш простим і зручним у використанні засобом.

Лінійка VS.NET включатиме випуски академічний, професійний і дві версії Enterprise (архітектор і розробник). Обговорення конкретних варіантів поставок краще відкласти до офіційного оголошення продукту.

Об'єктна модель середовища розробки (IDE), базується на кореневому об'єкті Засоби розробки розширення (DTE), який знаходиться в просторі імен EnvDTE бібліотек классов.NET Framework. Через нього можна отримати посилання на всі безліч об'єктів, що відповідають окремим елементам IDE, таким, як Вікна, документи, рішення, проекти, відладчика і події.

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

Процедура розробки інтерфейсу засобами RAD зводиться до послідовного виконання трьох операцій:

- розміщення компонентів інтерфейсу в потрібному місці.

- завдання моментів часу їх появи на екрані.

- настройка пов'язаних з ними атрибутів і подій.

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

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

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

Технологія RAD забезпечує:

- швидкість просування програмного продукту на ринок;

- інтерфейс, що влаштовує користувача;

- легку адаптованість проекту до мінливих вимог;

- простоту розвитку функціональності системи.

методологія RAD

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є що отримала останнім часом широкого поширення методологія швидкої розробки додатків RAD (Швидка розробка додатків). Під цим терміном звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

- невелику команду програмістів (від 2 до 10 осіб);

- короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);

- повторюваний цикл, при якому розробники, у міру того, як додаток починає набувати форму, запитують і реалізують у продукті вимоги, отримані через взаємодію з замовником.

Команда розробників повинна представляти із себе групу професіоналів, які мають досвід в аналізі, проектуванні, генерації коду і тестуванні ПЗ з використанням ДІЛО-засобів. Члени колективу повинні також вміти трансформувати в робочі прототипи пропозиції кінцевих користувачів.

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

- фаза аналізу і планування вимог;

- фаза проектування;

- фаза побудови;

- фаза впровадження.

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

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

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

Після закінчення робіт кожної окремої команди розробників проводиться поступова інтеграція даної частини системи з іншими, формується повний програмний код, виконується тестування спільної роботи даної частини програми з іншими, а потім тестування системи в цілому. Завершується фізичне проектування системи:

- визначається необхідність розподілу даних;

- виробляється аналіз використання даних;

- виробляється фізичне проектування бази даних;

- визначаються вимоги до апаратних ресурсів;

- визначаються способи збільшення продуктивності;

- завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

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

Методологія RAD непридатна для побудови складних розрахункових програм, операційних систем або програм управління космічними кораблями, тобто програм, що вимагають написання великого обсягу (сотні тисяч рядків) унікального коду. [11]

3. РЕАЛІЗАЦІЯ ПРОЕКТУ (ЗАДАЧІ)

3.1 Проведення нормалізації БД

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

Дата добавления: 2015-07-13