5.6.4 Побудова інформаційної моделі системи

Здійснюється побудова інформаційної (логічної та фізичної) моделей системи, згідно до методології IDEF1X. Для створення фізичної моделі можна скористатись будь-якою реляційною СУБД, наприклад, Access.

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

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

5.7 Визначення вимог до проектованої системи

"Вчений, ти пояснюєш нам науку, але хто пояснить

нам твоє пояснення?"

Дж. Байрон

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

- глосарій проекту повинен мати вигляд таблиці і зберігатися в окремому файлі;

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

5.7 Аналіз варіантів використання системи

“Теоретика розуміють, але йому не довіряють.

Експериментатора не розуміють, але йому вірять”.

Відомий жарт

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

5.8 Проектування архітектури системи

"Ідея була настільки простою, що не могла не

виявитися правильною."

Дж. Уотсон

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

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

5.9 Проектування елементів системи

"Якщо в них немає ніякого сенсу, - сказав Король, - то це, знаєте,

полегшує справу, бо тоді і сенсу шукати не треба".

"Аліса в країні чудес"

Опис проектних класів системи, згрупованих по пакетам: відповідальність класу та опис атрибутів і операцій у вигляді таблиці; діаграми зв’язків проектних класів системи; діаграма станів з описом поведінки екземплярів одного з класів, діаграма діяльностей, що моделює реалізацію операцій одного з класів; опис однієї підсистеми: опис операцій інтерфейсу, діаграми класів і діаграма послідовностей з описом реалізації однієї з операцій інтерфейсу; схема бази даних системи