24.2.6. Перехід від варіантів використання до класів

Коли визначено всі діючі суб'єкти і варіанти використання, то процес розроблення плавно переходить з етапу удосконалення у етап побудови програми. Це означає, що визначилася тенденція якогось зрушення у бік розробників від користувачів. З цього моменту їх тісна співпраця припиняється, оскільки вони починають розмовляти на різних мовах. Першою проблемою, яку нам потрібно вирішити, це створення і удосконалення класів, які входитимуть у програму.

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

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

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

Процес розроблення програм краще описувати з використанням будь-якого конкретного прикладу, тому зараз ми звернемося до розгляду процесу розроблення реальної програми. Але Ви все-таки читаєте навчальний посібник, а це не компакт-диск, тому програму довелося зробити настільки маленькою, що, взагалі кажучи, спірним питанням є доцільність формалізації процесу її розроблення. Та все ж навіть такий приклад повинен допомогти привідкрити завісу таємниці над поняттями, які ми ввели вище.

24.3. Предметна область програмування

Програма, яку ми створюватимемо в нашому прикладі, називається landlord – ДОМОВЛАСНИК. Ви можете поважати або не поважати свого домовласника, але необхідно цілком уявляти собі ті дані, з якими йому доводиться працювати: плата за житло і витрати. Ось такий нехитрий бізнес. Його ми і описуватимемо в нашій програмі.

Уявіть собі, що Ви є незалежним експертом з ведення домашнього господарства і з мови програмування C++, і до Вас зайшов замовник на ім'я Степан Полатайко. Полатайко – дрібний власник, у його веденні знаходиться будівля по вул. Левандівка, що складається з 12 кімнат, які він здає в оренду студентам. Він хоче, щоб Ви написали програму, яка спростила б його нелегку працю з реєстрації даних і друкування звітів про свою фінансову діяльність. Якщо Ви зможете домовитися із Степаном Полатайком про ціну, терміни і загальне призначення програми, то можете вважати, що Ви задіяні до процесу розроблення ПЗ.