Побудова ДПД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5. Заключні зауваження

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

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

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

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

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

Рис. 70. Графічна мова ОМТ для об’єктно-орієнтованого проектування
прикладних систем. Опис функціональної моделі

<== попередня сторінка	\|	наступна сторінка ==>
Визначення вхідних та вихідних значень	\|	ЗАГАЛЬНА ХАРАКТЕРИСТИКА АІС «ПОДАТКИ»

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.005 сек.