Обмеження середовища реалізації

Дизайнер може зустріти багато обмежень в ході реалізації.

Типовими обмеженнями в переході від аналітичної моделі до моделі дизайну є:

· відсутність множинного наслідування;

· відсутність наслідування;

· відсутність віртуальних методів;

· відсутність складних атрибутів;

· відсутність мультимедійних типів.

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

Малюнок 7.7.1. Приклад подолання множинного наслідування.

Фізична структура системи

Одним із завдань етапу дизайну - описати фізичну структуру системи.

Вона включає:

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

· Декомпозиція системи на конкретні програми.

· Фізичний розподіл даних і програм.

Малюнок 7.8.1. Позначення фізичної структури (Booch).

Малюнок 7.8.2. Графічний опис структури апаратури.

 

Правильність і якість проекту

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

Правильний проект повинен бути:

· завершеним;

· сумісним;

· узгодженим;

· повинна зберегтися семантика позначень.

Малюнок 7.9.1. Приклад компіляції в C++.

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

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

Правильність класу і діаграм станів

Всі діаграми проекту повинні бути веріфіковані.

У верефікації діаграм класів потрібно враховувати наступне:

· ациклічні відносини узагальнення-спеціалізації,

· варіанти відносин циклічного об'єднання,

· класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється,

· введення в специфікацію методів, що мають відношення до вводу, виводу і специфікації результата.

Якість системи

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

Узгодженість

Узгодженість описує ступінь відповідності частин системи один одному і взаємини операцій. Критерії декомпозиції дуже важливі. Вони визначають вид узгодженості.

Критерії декомпозиції:

· Випадкова декомпозиція. Розділення на модулі відбувається із-за неможливості обхватити всю систему в різних завданнях.

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

· Часова декомпозиція. Компоненти працюють в однаковий час.

· Послідовна декомпозиція. Компоненти працюють в певній послідовності. Вихідні дані одного компоненту є вхідними для іншого.

· Функціональна декомпозиція. Всі компоненти потрібні для виконання однієї функції.