Змістовий модуль. 5. Застосування діаграм взаємодії та основних шаблонів конструювання

Лекція 8. Побудова діаграм взаємодії для RTS-системи.

Література: [81-89]; 2[253-285]

Вибір класу-контролера. Проектне рішення newOrder. Проектне рішення isItinarary. Проектне рішення isTrain. Проектне рішення isSeat.

Вибір класу-контролера

Спочатку потрібно вибрати контролер для обробки повідомлень системної операції newOrder і наступних системних операцій. Відповідно до патерна Controller, як контролер може виступати клас, що задовольняє одній з наступних умов:

• клас представляє всю систему в цілому, пристрій або підсистему (зовнішній контролер);

• клас є одержувачем або оброблювачем всіх системних подій для деякого сценарію прецеденту (контролер прецеденту).

Якщо кількість системних операцій невелика, як у нашому випадку, то краще вибрати зовнішній контролер, наприклад, Register.

Проектне рішення: newOrder

Для створення нового екземпляра Order скористаємося шаблоном Creator, відповідно до якого створювати нові екземпляри повинен клас, що містить, агрегує або записує інформацію про створювані класи.

З аналізу моделі предметної області випливає, що запис інформації про продаж квитків може виконувати об'єкт Register («реєстр» означає журнал, де розташовують записи про продажі). Тому об'єкту Register доцільно доручити створення екземплярів об'єктів Order. На рис 8.1 представлена діаграма взаємодії, яка реалізує проектне рішення newOrder. 7.3 Проектне рішення: newOrder

Рис. 8.1 Реалізація операції newOrder

Проектне рішення: isItinerary

Системна операція isItinerary ініціюється в той момент, коли касир передає в систему замовлення на квиток. Екземпляр Register має зв'язок з об'єктом класу StationSpecification і з колекцією Itinerary Тому об'єкт Register доручає StationSpecification визначити існування станцій stD і stA, а колекції Itinerary знайти маршрут (маршрути) між станцією відправлення stD і станцією призначення stA. Результат операції – структура itDA. Якщо маршрут існує, то станції й обрані маршрути передаються в об'єкт Order. Після цього потрібно створити екземпляр класу Way для зберігання обраних маршрутів.

Рис. 8.2 Реалізація операції isItinerary

Відповідна діаграма взаємодії наведена на рис. 8.2.

Отримане рішення для операції isItinerary не буде найкращим, якщо враховувати реалізацію наступних операцій. Тому краще передати завдання визначення маршруту класу Order. 7.5

Проектне рішення : isTrain

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

Інформація про поїзди зберігається в класі Train. Об'єкт Register знає про існування екземпляра t класу Train. Відповідно до шаблона Інформаційний експерт йому можна доручити визначення поїздів. Однак об'єкт Register не має інформації про обрані маршрути. Цю інформацію зберігає об'єкт класу Order. Тому обов'язок знаходження поїздів передається класу Order. У свою чергу клас Order передав дані про маршрути класу Way.

Проектне рішення: isSeat

Системна операція isSeat виконується касиром, коли встановлено, що між двома зазначеними станціями на зазначену дату є поїзд (поїзди) зазначеного класу. Після цього варто визначити наявність місця.

Інформація про квитки зберігається в класі Map_Seat. Об'єкт Register знає про існування екземпляра m класу Map_Seat, що являє собою карти місць для кожного поїзда й для кожної дати.

Відповідно до шаблона Інформаційний експерт об'єкту Register можна доручити визначення місць. Однак об'єкт Register не має інформації про обрані поїзди. Цю інформацію зберігає об'єкт класу Order. Тому обов'язок знаходження місць передається класу Order.

Контрольні запитання

1. Що розуміють під розподілом обов’язків?

2. Які типи обов’язків ви знаєте?

3. Як визначити системні операції?

4. З яких умов обрано контролер для прецеденту «Продаж квитка» для RTS-системи?

5. Чому клас Register створює об’єкт Order?

6. Як сформулювати Проектне рішення isItinerary?

7. Чому не треба надавати класу Register обов’язків перевірки наявності станцій, пошуку маршруту тощо?

8. Для чого був створений клас Way, якого не було передбачено у концептуальній моделі?

9. Як сформулювати Проектне рішення isSeat ?

Лекція 9. Побудова діаграм взаємодії для RTS-системи (продовження).

Література: [81-89]; 2[253-285]

Проектне рішення getPrice. Проектне рішення makePayment. Проектне рішення startUp.

Проектне рішення: getPrice

Системна операція getPrice виконується при натисканні касиром відповідної кнопки після одержання даних про наявність місця.

Якщо завдання не зводиться до створення об'єкта або вибору контролера, то використовується шаблон Information Expert. Відповідно до цього шаблона завдання можна покласти на клас Order, тому що він має необхідні дані для виконання розрахунку (станція відправлення й прибуття, класність поїзда й місця, посилання на об'єкт Way для обчислення відстані). Однак використання для цієї мети об'єкта Order приведе до появи нових зв'язків і функцій у цього об'єкта, що суперечить шаблонам Low Coupling і High Cohesion. Разом з тим, об'єкт Payment спеціалізується на розрахунках, має посилання на об'єкт Tariff і йому легко передати з об'єкта Order всю відсутню для розрахунку інформацію. Тому розрахунок вартості проїзду покладаємо на об'єкт Payment.

Використовуючи шаблон Information Expert, функцію обчислення відстані між станціями доручаємо об'єкту Way, який містить обраний шлях проходження, а визначення правила обчислення вартості – екземпляру Tariff , який містить тарифи оплати.

Рис. 9.1 Реалізація операції getPrice

Проектне рішення: makePayment

Системна операція makePayment виконується при натисканні касиром відповідної кнопки після одержання від клієнта грошей на оплату квитка.

Обчислення решти відповідно до шаблона Information Expert потрібно доручити об'єкту Payment, який містить дані про вартість квитка.

Відомості про продані квитки повинні заноситися в журнал реєстрації.

Як інший варіант можна вибрати клас, що реалізує традиційне бухгалтерське поняття, наприклад, гросс . Однак уводити додаткові об'єкти має сенс тільки при істотному розростанні системи, коли клас Booking_office перестане мати властивість високого зачеплення. В нашому випадку зупинимося на об'єкті Booking_office, якому передаємо для реєстрації ім'я екземпляру Order.

Реалізація запуску програми

Практично всі системи включають прецедент Запуск системи (StartUp) і деяку вхідну операцію, пов'язану із запуском програми користувача.

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

Як запускається програма?

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

У нашій RTS-системі системна операція StаrtUp буде виконуватися при включенні менеджером відповідного сервера. Будемо вважати, що вхідному об'єкту предметної області керування не передається. Воно передається на рівень графічного інтерфейсу користувача. Тоді діаграма взаємодії системної операції StartUp повинна містити лише передачу повідомлення create() для створення вихідного об'єкта.

Який клас треба вибрати як вхідний об'єкт? У нашому випадку вибираємо клас Booking_office.

Об'єкти з бази даних

Екземпляри Itinerary, Train, Map_seat, Station_Specification, Time_table мусять зберігатися в базі даних. У процесі операції StartUp вони можуть завантажуватися в оперативну пам'ять (якщо їх не дуже багато).

Проектне рішення: Booking_office – create()

Нам необхідно виконати ініціалізацію для наступних об'єктів: Booking_office , Register, Itinerary, Train, Map_seat, Station_Specification, Time_table, Tariff. Ухвалені рішення відображені на рис. 9.2.

Рис. 9.2 Створення вхідного об'єкта предметної області

Контрольні запитання

1. Як сформулювати Проектне рішення getPrice?

2. Як сформулювати Проектне рішення makePayment ?

3. Чому Проектне рішення StartUp реалізується останнім?

4. Як сформулювати Проектне рішення StartUp ?

5. Чому саме клас Booking_office ініціалізує інші класи?

6. Як сформулювати Проектне рішення Booking_office – create() ?