Версія 2
Додати конструктори по замовчуванню, ініціалізації та деструктори до всіх створених класів. Додати конструктори копіювання до всіх класів крім Годинника і Планувальника. Під час виклику кожного конструктора і деструктора повинно виводитися повідомлення, в якому вказується назва класу і тип викликаного конструктора чи деструктора. Створити об’єкти класів Планувальник і Банк, які автоматично створюють об’єкти-атрибути, зв’язані відношенням композиції. Потрібно передбачити два режими введення даних — з клавіатури і використовуючи стандартні значення. Застосовувати конструктори ініціалізації і по замовчуванню для цих режимів відповідно.
Версія 3
Додати методи-аксесори для атрибутів усіх створених класів. Для атрибутів типу bool застосувати предикатні функції. Використати ітератори та функції утіліти. Рекомендації до виконання: використати функції-утіліти в класі Банківський комп’ютер для реалізації розташування інформації про рахунки у базі даних і перевірки мандату (credentials), застосувати ітератори у всіх процесах, де відбувається перелік об’єктів, наприклад, при пошуці даних про клієнта у базі даних.
Версія 4
Додати деякі константні та статичні атрибути до класів (або зробити константними чи статичними існуючі атрибути). Рекомендації до виконання: зробити константними всі методи get, зробити статичними та константними максимальний розмір рахунку клієнта і максимальний розмір кредиту.
Версія 5
Реалізувати перевантаження операторів для деяких функцій та дружні функції. Рекомендації до виконання: перевантажити операції доступу до рахунку, перевантажити операції інкрементації та присвоєння класу Годинник.
Версія 6
Реалізувати просте успадкування класів. Рекомендації до виконання: створити класи Кредитна картка і Дебетова картка. Успадкувати ці класи від класу Банківська картка.
Версія 7
Реалізувати множинне успадкування класів. Рекомендації до виконання: створити клас Картка з дозволеним овердрафтом успадкуванням від класів Кредитна і Дебетова картка.
Версія 8
Реалізувати оброблення виключних ситуацій. Рекомендації до виконання: під час здійснення проводки можуть бути збої в роботі апаратури, або клієнт передумав отримувати гроші. Тоді слід відмінити проводку, що розпочалася. В цьому випадку всі рахунки та звітні документи мають бути відновлені в тому стані, в якому вони були до початку проводки (відкат). Для реалізації відкату здійснюється ведення записів про зміни, що вносяться в базу даних банка під час проводки.
Варіант 6
Версія 1
Здійснити об’єктно-орієнтований аналіз та об’єктно-орієнтоване проектування програми, що моделює роботу касира по продажі залізничних квитків. Моделююча програма
включає годинник, який на початку моделювання встановлюється в 0, а потім відраховує такти
часу до моменту завершення процесу моделювання. Планувальник програми моделює такі
процеси. Пасажир замовляє певну кількість квитків на певний потяг і певну дату. Касир робить
запит про наявність квитків, вводячи відповідні дані до комп’ютера. Запит з термінального
комп’ютера касира поступає до центрального комп’ютера (сервер застосувань) звідки
формується запит до сервера бази даних. Якщо запит задовольняється, то касир бачить відповідь
про наявність чи відсутність місць. За згодою пасажира касир оформлює квитки, задаючи
паспортні дані, та отримує гроші, які потрапляють до каси. Дані про продані місця поступають до серверу бази даних з метою унеможливити повторний їх продаж. В реальній системі
непередбачений відкат. На бажання розробника системи можна такий відкат реалізувати.
Планувальник програми має виводити на екран повідомлення про події, що відбуваються у
системі, що моделюється. Результати об’єктно-орієнтованого аналізу подати у вигляді сценарію
роботи фізичного об’єкту та переліку іменників, дієслів, що претендують на назви класів,
атрибутів і методів класів; результати об’єктно-орієнтованого проектування подати у вигляді
діаграм прецедентів, об’єктів і класів. Згенерувати код інтерфейсів класів, побудувати проект (на
кожний клас – по два файли: заголовний та срр), додати до проекту код згенерованих класів.