Завдання 1. Визначення вимог до графу (1 бал)

Прочитайте псевдокод path-finder (шукача шляху) і опис формату файлу тестового скрипта, що наведені нижче, та перелічити усі операції, що алгоритм path-finder і тестові файли здійснюють на графах. Перечисліть ці операцій в lab4/answers/problem1.txt.

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

Завдання 2. Пишемо специфікацію для Graph (4 бали)

Спроектуйте абстрактний тип даних, що представляє напрямлений граф з навантаженими вершинами. Спершу розгляньте методи та операції, які ви відчуваєте, що повинні включити у вашу абстракцію графу (див. розділ підказки). Почніть зі списку вимог, які ви сформулювали у попередньому пункті. Ви також можете знайти припущення про те, як вибирати операцій для абстрактних типів даних у книзі Барбари Лісков у розділах 5.1 та 5.1.1 (стор. 79-83). (Специфікації вашого графу не повинна мавпувати формат файлу тестового сценарію, який має інше призначення. Наприклад, якщо ваша специфікація графів включає ім'я графа, то щось не так з вашим дизайном.)

Створіть специфікацію для кожного методу, який ви вирішите підтримувати, використовуючи формат та позначення прийнятими у цьому курсі (зокрема, не забудьте включити підрозділи requires/effects/modifies у ваші Javadoc коментарі). Якщо ви маєте сумніви стосовно того, як писати і створювати Javadoc коментарі, зверніться до відповідної документації або викладача. Після завершення вашої специфікації, хорошою практикою є написання порожніх реалізацій усіх операцій, що ви вирішите підтримувати (так звані заглушки), тож ви зможете написати клієнтський код і тести для графу, перш ніж насправді його реалізуєте.

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

Крім того, абстракція графу не повинна робити жодних припущень стосовно типу об’єктів, що представляють вершини. По суті, операції графу повинні працювати з вершинами. будь-якого типу, в тому числі Object, ви повинні використати систему універсальних типів Java (Generics), для досягнення цієї мети.

Будь ласка, включіть у ваш проект обґрунтування вибору (від одне-два речення для кожної операції), ваших операцій та чому ви вважаєте, що вони складають достатній інтерфейс графу. Збережіть це у lab4/answers/problem2.txt.

Підказка: Ми не рекомендуємо оголошувати сильніший метод equals ніж метод, визначений у класі Object (який перевіряє ідентичність об'єктів); ні у ця лабораторна робота, а ні майбутні не вимагатимуть від вас порівняти графи між собою.