Версія 2

Додати конструктори по замовчуванню, ініціалізації та деструктори до всіх створених класів. Додати конструктори копіювання до всіх класів крім Годинника і Планувальника. Під час виклику кожного конструктора і деструктора повинно виводитися повідомлення, в якому вказується назва класу і тип викликаного конструктора чи деструктора. Створити об’єкти класів Планувальник і Керівник, які автоматично створюють об’єкти-атрибути, зв’язані відношенням композиції. Потрібно передбачити два режими введення даних — з клавіатури і використовуючи стандартні значення. Застосовувати конструктори ініціалізації і по замовчуванню для цих режимів відповідно.

Версія 3

Додати методи-аксесори для атрибутів усіх створених класів. Для атрибутів типу bool застосувати предикатні функції. Використати ітератори та функції утіліти. Рекомендації до виконання: використати функції-утіліти в класі Виконавець для реалізації тестування, застосувати ітератори у всіх процесах, де відбувається перелік об’єктів, наприклад, при взаємодії керівника з безліччю виконавцями.

Версія 4

Додати деякі константні та статичні атрибути до класів (або зробити константними чи статичними існуючі атрибути). Рекомендації до виконання: зробити константними всі методи get, зробити статичними та константними максимальну кількість виконавців.

Версія 5

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

Версія 6

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

Версія 7

Реалізувати множинне успадкування класів. Рекомендації до виконання: можна створити клас, який об’єднує в собі Покупця і Замовника.

Версія 8

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

Варіант 13

Версія 1

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