6.3. Обмеження

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

6.4. Функціональна модель банківської мережі

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

• визначити вхідні та вихідні значення;

• побудувати ДПД, яка показує функціональні залежності;

• описати функції;

• описати обмеження;

• сформулювати критерії оптимізації;

• уточнити набір операцій в об’єктній моделі.

Виконаємо всі ці кроки, щоб побудувати функціональну модель банківської мережі (АТМ).

Визначення вхідних та вихідних значень

Ці значення є параметрами подій між системою і навколишнім світом. Вхідні та вихідні значення банківської мережі наведено на рис. 67 (пунктирна лінія показує межі системи).

Рис. 67. Вхідні та вихідні значення банківської мережі

Оскільки всі взаємодії між зовнішнім світом та системою відбуваються через АТМ (чи касовий термінал, який тут не розглядається), усі вхідні та вихідні значення є параметрами подій, які пов’язані з об’єктом «АТМ (банкомат)».

Побудова дпд

ДПД звичайно будується за рівнями. На верхньому рівні, як правило, показують один єдиний процес або, як у нашому прикладі (рис. 68), процес введення, основний процес обчислення розглядуваних значень та процес виведення. Вхідні та вихідні дані на цій діаграмі поставляються та використовуються зовнішніми об’єктами («клієнт», «картка»).

Рис. 68. Процеси верхнього рівня в системі обслуговування банківської мережі

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

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

Рис. 69. ДПД процесу «виконати проведення» в системі обслуговування банківської мережі

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

Опис функцій.

Після того як ДПД складена, необхідно побудувати опис кожної функції з ДПД. Методика опису функції викладена в п. 6.2, а приклад опису функції наведено на рис. 66. Ми не наводимо інших прикладів опису функцій банківської мережі з огляду на їх тривалість.

Опис обмежень.

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

У банківській мережі можна ввести такі обмеження:

«рахунок не може мати негативного балансу»;

«негативний баланс кредитованого рахунку не може бути більшим за ліміт кредитування для цього рахунку».

Визначення критеріїв оптимізації.

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

Оптимізаційні критерії для банківської мережі:

мінімізувати кількість фізичних пересилань між різними вузлами зв’язку;

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

Операції вводяться на різних стадіях розробки моделі системи, яка проектується (див. раніше):

при розробці об’єктної моделі;

при визначенні подій;

при визначенні дій та активностей;

при визначенні функцій.

На заключному етапі розробки моделі проектованої системи всі введені операції вводяться в її об’єктну модель.

До перелічених операцій додають операції, зв’язані із зовнішньою поведінкою об’єктів класів, які розглядаються: ці операції визначаються природою об’єктів, а не властивостями розроблюваної системи. Такі операції розширюють визначення об’єкта, виводячи його за рамки безпосередніх вимог зі сторони конкретної системи. Приклади таких операцій для банківської мережі такі: «закрити рахунок», «створити ощадний рахунок», «створити банківську картку» і т. ін. З погляду системи ці операції не мають сенсу, але вони відбивають реальні властивості класів «рахунок» та «картка» і можуть згодитися при використанні цих класів в інших системах.

Насамкінець потрібно дослідити об’єктну модель на предмет спрощення операцій її класів. Приклад банківської мережі не настільки складний, щоб продемонструвати це.