24.3.2. Прийняття допущень і спрощень

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

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

24.4. Програма landlord: етап удосконалення

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

24.4.1. Встановлення діючих суб'єктів

Спочатку потрібно визначити, хто буде діючими суб'єктами? Хто вводитиме інформацію? Хто запрошуватиме? Чи буде хто-небудь ще взаємодіяти з програмою? Чи буде сама програма взаємодіяти з іншими?

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

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

24.4.2. З'ясування варіантів використання

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

• почати роботу з програмою;

• додати нового мешканця в перелік;

• ввести значення орендної плати в таблицю доходів від оренди;

• ввести значення в таблицю витрат;

• вивести перелік мешканців;

• вивести таблицю доходів від оренди;

• вивести таблицю витрат;

• вивести річний звіт.

Таким чином, діаграму варіантів використання, яка отримується внаслідок наведеного переліку дій, можна представити так, як це показано на рис. 24.4.

Рис. 24.4. Діаграма варіантів використання для програми landlord