Семестровий модуль 2 Створення та тестування програмних класів

Змістовий модуль 6. Створення діаграми програмних класів. Визначення методів та параметрів

Лекція 10. Визначення методів

Література:1 [90-100]; 2[285-307]

Загальні положення. Облсті видимості (за допомогою атрибутів, за допомогою параметрів, локальна, глобальна). Призначення діаграм класів. Визначення методів.

Загальні положення

На етапі завершення побудови діаграм взаємодії корисно мати повну картину використовуваних у діаграмах класів

- Діаграма програмних класів (design class diagram) відображає специфікації програмних класів і інтерфейсів (методи й дані), а також зв'язки між ними.

На відміну від діаграм класів з моделі предметної області, діаграми програмних класів при проектуванні відображають програмні сутності, а не поняття предметної області.

Області видимості

Області видимості забезпечують здатність одного об'єкта бачити інший об'єкт або посилатися на нього.

Якщо деякий об'єкт посилає повідомлення іншому об'єкту, об'єкт-одержувач повинен бути видний об'єкту-відправникові.

Існує чотири основних способи забезпечення видимості об'єкта В об'єктом А.

1. За допомогою атрибутів. Об'єкт В є атрибутом об'єкта А.

2. За допомогою параметрів. Об'єкт В є параметром методу об'єкта А.

3. Локальна видимість. Об'єкт В оголошений як локальна змінна в методі об'єкта А.

4. Глобальна видимість. Об'єкт В якимось образом видний глобально, тобто об'єкт В є глобальним стосовно А.

Визначення класів для RTS-системи

Першим кроком на шляху створення діаграми класів є ідентифікація класів, які мають брати участь у програмному рішенні. Для цього потрібно вивчити всі діаграми взаємодії й вибрати згадані в них класи. В RTS-програмі ми знаходимо: Booking_office, Register, Oder, Payment, Tariff, StationSpecification, Station, Itinerary, Way, Time_table, Train, Map_seat.

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

Визначення методів

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

При заповненні діаграм класів методами необхідно керуватися наступними міркуваннями:

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

Методи доступу до даних класу часто виявляються дуже численними. У загальному випадку для N даних членів класу можна запропонувати 2*N методів. Тому методи доступу на діаграмах класів також часто не вказуються.

На діаграмах класів можна відображати інформацію про типи атрибутів, параметри методів і значення, що повертаються. При цьому варто виходити з наступного:

• якщо генерація коду буде виконуватися автоматично з використанням CASEзасобів, то на діаграмі класів необхідно відобразити повну й вичерпну інформацію;

• якщо діаграмі класів створюється для програмістів, то надлишкові деталі можуть захаращувати діаграму.

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

1. Для чого потрібна діаграма програмних класів, що на ній відображається?

2. Які існують способи забезпечення видимості?

3. Як реалізується видимість за допомогою атрибутів?

4. Як реалізується видимість за допомогою параметрів?

5. Як реалізується локальна видимість?

6. Як реалізується глобальна видимість?

7. Які засоби пропонує UML для визначення видимості?

8. Яку інформацію у діаграмах взаємодії потрібно аналізувати для визначення методів, що належать певному класу?

9. Які існують особливості відображення методів Create і методів доступу до даних?

Приклад створення сукупності програмних класів для RTS системи.

На рис. 10.1 наведено сукупність програмних класів з вказівкою методів, отриманих на підставі аналізу розглянутих раніше діаграм взаємодії для RTS системи.

Рис. 10.1 Програмні класи RTS системи

Лекція 11. Визначення даних-членів класу

Література: 1 [90-100]; 2[285-307]

Визначення даних-членів класу. Правила визначення даних-членів класу.

Відображення асоціацій та залежностей на діаграмах класів.

Визначення даних – членів класу

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

Визначимо дані класу Register. Почнемо з операції NewOrder. На рис. 11.1 зображена діаграма цієї операції.

Рис. 11.1 Аналіз операції NewOrder

Скористаємося рядом правил для визначення даних-членів класу на підставі діаграм взаємодії.

Правило перше. Якщо деякий клас створює об'єкт іншого класу, то цей клас має дане типу створеного об'єкта.

На підставі цього правила потрібно включити o:Order у клас Register.

Правило друге. Якщо в породженому повідомленні класу з'являється параметр, якого не було у відповідному вихідному повідомленні, то клас повинен містити дане, відповідне цьому параметру.

Друге правило визначає посилання на класи StationSpecification (ss) і Itinerary (i) як дані класу Register.

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

Правило четверте. Якщо у входному повідомленні класу є деякий параметр, якого немає в породженому повідомленні, то в класі повинне бути дане, відповідне цьому параметру.

У результаті застосування наведених правил можна побудувати діаграму класу

Register (рис. 11.2).

Рис. 11.2 Діаграма класу Register

Правило п'яте. Якщо породжене повідомлення класу повертає деяке значення, а вихідне повідомлення цього значення не має, то в клас варто включити дане, відповідне цьому значенню.

Відображення асоціацій на діаграмах класів

Асоціації на діаграмі програмних класів указують на зв'язок між класами. Ґрунтуючись на діаграмах взаємодії, відображаються ті асоціації, які відповідають вимогам видимості й пам'яті.

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

У мові UML існує позначення для відношення залежності, яке вказує, що один елемент (будь-якого типу, включаючи класи, прецеденти й т.д.) знає про інший елемент. Таке відношення відображається пунктирною лінією зі стрілкою. Це значить, що залежність утворена не за допомогою атрибутів.

Позначення UML для детальної інформації про члени класу

Позначення для детальної інформації про члени класу наведені в наступній таблиці.

Таблиця 11.1 Додаткова інформація про члени класу

Для атрибутів класу:	Для методів класу:
+ відкритий атрибут - закритий атрибут a:t=2 – атрибут з початковим значенням	+ відкритий метод - закритий метод x():t метод, який повертаэ значення x(p1:t1, p2:t2) метод з параметрами x(p1, p2) метод з параметрами

Оскільки процес проектування класів ітераційний, у результаті тестування класів можливе внесення змін у текст класу. У цьому випадку бажано відобразити ці зміни й у відповідних діаграмах класів. При використанні CASE-засобів можливо виконувати зворотне проектування – генерування діаграм класів на основі коду програми.

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

1. Яку інформацію у діаграмах взаємодії потрібно аналізувати для визначення данихчленів певного класу?

2. Які правила аналізу діаграм взаємодії для визначення даних-членів класу ви знаєте?

3. Для чого відображають асоціації на діаграмі програмних класів?

4. Як відображаються асоціації на діаграмі програмних класів?

5. Як відображаються залежності на діаграмі програмних класів?

6. Яка інформація про члени класу може відображатися на діаграмі програмних класів?

Приклад побудови діаграми програмних класів.

На рис. 11.3 представлена діаграма класів застосування RTS з асоціаціями й відносинами залежності.

Рис. 11.3 Діаграма класів з асоціаціями й залежностями