Об’єктна модель системи. Класи: спадкування та інкапсуляція (до другого розділу курсової роботи)

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

Перерахуємо основні етапи побудови об’єктної моделі:

§ визначення об’єктів та класів;

§ підготовка словника даних;

§ визначення відношень між об’єктами;

§ визначення атрибутів об’єктів та зв’язків;

§ організація та спрощення класів під час використання спадкування;

§ дослідження та вдосконалення моделі надалі.

Визначення класів. Аналіз зовнішніх вимог до прикладної системи на етапі проектування дозволяє виділити об’єкти та класи об’єктів. Усі класи (узагальнені) мають бути сформульовані в термінах предметної області, класів, пов’язаних з комп’ютерною реалізацією (таких як стек, список і т.д.) на цьому етапі вводити не потрібно.

Визначення класів слід почати з письмової постановки прикладної задачі (технічного завдання та іншої документації). Це дуже важливий етап проектування, від нього залежить подальша доля проекту.

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

Далі список можливих класів аналізується на наявність непотрібних класів. Такими класами є:

§ надлишкові класи: якщо два або декілька класів визначають одну інформацію, тоді треба зберігати тільки один з них;

§ нерелевантні класи (що не мають прямого відношення до проблеми): для кожного імені можливого класу оцінити необхідність в майбутній системі;

§ нечітко визначені (з точки зору проблемної задачі) класи;

§ атрибути (деяким іменникам краще відповідають не класи, а атрибути, наприклад, вік, стать і т.і.);

§ операції, деяким іменникам більше відповідають операції, а не класи (наприклад, телефонний виклик);

§ ролі, деякі іменники визначають імена ролей в об’єктній моделі (наприклад, керівник, водій, службовець і т.д. – все це ролі одного класу - людина);

§ конструкції реалізації (не потрібно вводити на даному етапі класи для позначення понять з алгоритмізації та програмування).

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

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

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

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

Потім потрібно прибрати непотрібні або неправильні відношення, використовуючи наступні критерії:

§ відношенння між виключеними класами мають бути знищені або переформульовані у термінах тих класів, що залишилися;

§ нерелевантні відношення і відношення, пов’язані з реалізацією, повинні бути виключені;

§ тернарні відношення – більшу частину відношень між трьома та більшим числом класів можна розкласти на декілька бінарних відношень;

§ похідні відношення – потрібно виключити відношення, які можна виразити через інші відношення, оскільки вони надлишковими.

Уточнення атрибутів. Цей етап передбачає уточнення системи атрибутів: корегуються атрибути класів, вводяться за необхідності інші, нові атрибути. Атрибути виражають властивості об’єктів класу або визначають їх поточний стан. Атрибути зазвичай відповідають іменникам, наприклад, колір авто, позиція курсору і т.і. Атрибути зазвичай слабко впливають на структуру об’єктної моделі.

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

§ заміна атрибутів на об’єкти, якщо наявність деяких сутностей важливіше, ніж їхнє значення, то це об’єкт, якщо важливіше значення – то це атрибут;

§ кваліфікатори, якщо значення атрибута залежить від конкретного контексту, то його треба вважати кваліфікатором;

§ ідентифікатори, ідентифікатори об’єктів пов’язані з їх реалізацією, на ранніх стадіях проектування їх не потрібно розглядати як атрибути;

§ атрибути зв’язків, якщо деяка властивість характеризує не сам об’єкт, а його зв’язок з іншим об’єктом чи об’єктами, то це атрибут зв’язку, а не атрибут об’єкту;

§ внутрішні значення, атрибути, що визначають лише внутрішній стан об’єкта треба виключити з розгляду;

§ несуттєві деталі, атрибути, що не впливають на виконання більшої частини операцій, варто опустити.

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

Узагальнення – це відношення між більш загальною сутністю, яка називається суперкласом, та її конкретним втіленням, яке називають підкласом. Іноді узагальнення називають відношенням типу «являється, є», маючи на увазі, що одні сутності (наприклад: коло, квадрат, трикутник) є втіленням більш загальної сутності (наприклад: геометрична фігура). При цьому, всі атрибути та операції суперкласу, незалежно від модифікаторів видимості, входять у склад підкласу.

Узагальнення часто називають спадкуванням. На діаграмах воно позначається не зафарбованою трикутною стрілкою (рис. 5). Для того, щоб ефективно виділити спадкування Греді Буч [20] рекомендує:

1) знайдіть атрибути, операції та обов‘язки, загальні для двох і більше класів з даної сукупності – це дозволяє позбавитися непотрібного дублювання структури та функціональності об‘єктів,

2) внесіть ці елементи в деякий загальний суперклас, я якщо такого не існує, то створіть новий клас,

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

Наведемо приклад застосування спадкування (рис. 6):

На перший погляд дивно, що клас «Точка» не має ніяких атрибутів, а коло має тільки радіус. Прямокутник визначений шириною і висотою. Але пояснити це можна так: положення фігури можна визначити за допомогою пари чисел, для точки – це єдині характеристики, для кола і прямокутника – це точка їх центру, таким чином утворився суперклас «Фігура», що має загальні атрибути Х та Y – координати центру фігури. Інші класи, що спадкуються від класу фігура потрібно довизначити: для кола це атрибут «радіус», для прямокутника – «ширина» та «висота». Операції для цих класів визначаються подібно атрибутам.

Інкапсуляція при визначенні атрибутів та операцій класів. Приховування від користувача (від дійсного користувача, чи від програміста, який використовує готовий клас) внутрішнього влаштування об‘єктів називається інкапсуляцією. За офіційним визначенням [20], інкапсуляція – це захист окремих елементів об‘єкту, що не зачіпають його суттєвих характеристик як цільного елементу. Інкапсуляція використовується не тільки для того, щоб створити ілюзію простоти для користувача, а й для захисту самого об‘єкту. Розглянемо інкапсуляцію на прикладі телевізора, зовні нам цей прилад здається дуже простим, оскільки для роботи з ним ми використовуємо простий інтерфейс – пульт дистанційного керування. Для того, щоб збільшити гучність, потрібно натиснути відповідну кнопку з «+», а для перемикання на інший канал – натиснути кнопку з номером каналу. Як телевізор влаштований усередині, ми не знаємо, більш того, якби не було пульта керування, це було б незручним і небезпечним для нас, а також небезпечним і для телевізора. (Збільшувати гучність, наприклад, за допомогою паяльника – незручний і небезпечний спосіб). Тому, пульт телевізора захищає від нас внутрішню будову телевізора – так в реальному світі реалізується інкапсуляція.

У програмуванні інкапсуляція забезпечується дещо по-іншому – за допомогою так званих модифікаторів видимості. За їх допомогою можна обмежити доступ до атрибутів та операцій об‘єкту з боку інших об’єктів. Якщо атрибут чи операція помічені модифікатором private, то доступ до них можливо отримати тільки з операції, визначеної у тому ж класі. Якщо ж атрибут чи операція помічені модифікатором видимості public, то до них можна отримати доступ з будь-якої частини програми. Модифікатор protected дозволяє доступ тільки з операцій цього ж класу та класів, що створюються на його основі (спадкуються). У мовах програмування можуть зустрічатися модифікатори видимості, які обмежують доступ на більш високому рівні, наприклад, до класів чи їх груп, однак суть інкапсуляції від цього не змінюється. У UML атрибути і операції з модифікаторами доступу позначаються спеціальними символами, що розміщуються зліва від їхніх імен:

 

Символ	Значення
+	public – відкритий доступ
–	private– доступ тільки з операцій того ж класу
#	protected– доступ тільки з операцій того ж класу і класів, що створені на його основі

На прикладі з телевізором можна побудувати узагальнений клас (на найвищому рівні абстракції), який буде виглядати, як зображено на рис. 7.