21289

Відношення між класами

Лекция

Информатика, кибернетика и программирование

Відношення між класами Вступ Крім внутрішнього пристрою або структури класів на відповідній діаграмі вказуються різні відносини між класами. Базовими відносинами або зв'язками в мові UML є: Відношення залежності dependency relationship Ставлення асоціації association relationship Відношення узагальнення generalization relationship Ставлення реалізації realization relationship Кожне з цих відносин має власне графічне подання на діаграмі яке відображає взаємозв'язки між об'єктами відповідних класів. На діаграмі класів дане...

Украинкский

2013-08-02

407 KB

47 чел.

Лекція 4. Відношення між класами

Вступ

  Крім внутрішнього пристрою або структури класів на відповідній діаграмі вказуються різні відносини між класами. При цьому сукупність типів таких відносин фіксована в UML і зумовлена семантикою цих типів відносин. Базовими відносинами або зв'язками в мові UML є:

• Відношення залежності (dependency relationship)

• Ставлення асоціації (association relationship)

• Відношення узагальнення (generalization relationship)

• Ставлення реалізації (realization relationship)

  Кожне з цих відносин має власне графічне подання на діаграмі, яке відображає взаємозв'язки між об'єктами відповідних класів.

1. Відношення залежності

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

  Відношення залежності графічно зображується пунктирною лінією між відповідними елементами зі стрілкою на одному з її кінців ("->" або "<-"). На діаграмі класів дане відношення пов'язує окремі класи між собою, при цьому стрілка спрямована від класу-клієнта залежно до незалежного класу або класу-джерела (рис. 5.3). На даному малюнку зображені два класи: Класс_А і Кяасс_Б, при цьому Класс_Б є джерелом певної залежності, а Класс_А - клієнтом цієї залежності.

Рис. 5.3. Графічне зображення відношення залежності на діаграмі класів

  Як класу-клієнта і класу-джерела залежності можуть виступати цілі безлічі елементів моделі. У цьому випадку одна лінія зі стрілкою, що виходить від джерела залежності, розщеплюється в деякій точці на кілька окремих ліній, кожна з яких має окрему стрілку для класу-клієнта. Наприклад, якщо функціонування Класса_С залежить від особливостей реалізації Класса_А і Класса_Б, то дана залежність може бути зображена наступним чином (рис. 5.4).

Рис. 5.4. Графічне представлення залежності між класом-клієнтом (Класс_С) і класами-джерелами (Класс_А і Класс_Б)

  Стрілка може позначатися необов'язковим, але стандартним ключовим словом у лапках і необов'язковим індивідуальним ім'ям. Для відносини залежності зумовлені ключові слова, які позначають деякі спеціальні види залежностей. Ці ключові слова (стереотипи) записуються в лапках біля стрілки, яка відповідає даній залежності.

  Приклади стереотипів для відносини залежності представлені нижче:

• "access" - служить для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів;

• "bind" - клас-клієнт може використовувати певний шаблон для своєї подальшої параметризації;

• "derive" - атрибути класу-клієнта можуть бути обчислені за атрибутами класу-джерела;

• "import" - відкриті атрибути та операції класу-джерела стають частиною класу-клієнта, як якщо б вони були оголошені безпосередньо в ньому;

• "refine" - вказує, що клас-клієнт служить уточненням класу-джерела в силу причин історичного характеру, коли з'являється додаткова інформація в ході роботи над проектом.

2. Відношення асоціації

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

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

  Як приклад відносини бінарної асоціації розглянемо відношення між двома класами - класом «Компанія» і класом «Співробітник» (рис. 5.5). Вони пов'язані між собою бінарної асоціацією «Робота», ім'я якої вказано на малюнку поруч з лінією асоціації. Для даного відносини визначено порядок проходження класів, першим з яких є клас «Співробітник», а другим - клас «Компанія». Окремим прикладом чи примірником даного відношення може бути пара значень (Петров І. І., "Фірма"). Це означає, що співробітник Петров І. І. працює в компанії "Фірма".

Рис. 5.5. Графічне зображення відношення бінарної асоціацію між класами

  Тернарних асоціація та асоціації більш високої арності в загальному випадку називаються N-арной асоціацією. Така асоціація пов'язує деяким ставленням 3 і більше класів, при цьому один клас може брати участь в асоціації більш ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказано на діаграмі. Кожен екземпляр N-арной асоціації є N-арний кортеж значень об'єктів з відповідних класів. Бінарна асоціація є окремим випадком N-арной асоціації, коли значення N = 2, і має своє власне позначення.

  N-арная асоціація графічно позначається ромбом, від якого ведуть лінії до символів класів даної асоціації. У цьому випадку ромб з'єднується з символами відповідних класів суцільними лініями. Зазвичай лінії проводяться від вершин ромба чи то з середини його сторін. Ім'я N-арной асоціації записується поряд з ромбом відповідної асоціації.

  Порядок класів в N-арной асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромбу пунктирною лінією. Це означає, що даний клас забезпечує підтримку властивостей відповідної N-арной асоціації, а сама N-арная асоціація має атрибути, операції та / або асоціації. Іншими словами, така асоціація, у свою чергу, є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом мови UML - асоціацією-класом (Association Class). N-арная асоціація не може містити символ агрегації ні для якої зі своїх ролей. Як приклад конкретної тернарних асоціації розглянемо відношення між трьома класами: "Футбольна команда", "Рік" і "Гра". Дана асоціація вказує на наявність відношення між цими трьома класами, яка може представляти інформацію про ігри футбольних команд в національному чемпіонаті протягом кількох останніх років (рис. 5.6).

  Як вже згадувалося, окремий клас асоціації має власну роль у відношенні. Ця роль може бути зображена графічно на діаграмі класів. З цією метою в мові UML вводиться в розгляд спеціальний елемент - кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше решт асоціації. Найбільш важливі властивості асоціації вказуються на діаграмі поряд з цими елементами асоціації і повинні перемішатися разом з ними.

Рис. 5.6. Графічне зображення тернарних асоціацію між трьома класами

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

  Наступний елемент позначень - кратність окремих класів, які є кінцями асоціації. Кратність окремого класу позначається у вигляді інтервалу цілих чисел, аналогічно кратності атрибутів і операцій класів. Інтервал записується поряд з кінцем асоціації і для N-арной асоціації означає потенційне число окремих примірників або значень кортежів цієї асоціації, які можуть мати місце, коли інші N-1 примірників або значень класів фіксовані.

  Так, для розглянутого раніше прикладу (див. рис. 5.5) кратність "1" для класу "Компанія" означає, що кожен працівник може працювати тільки в одній компанії. Кратність "1 ..*" для класу "Співробітник" означає, що в кожній компанії можуть працювати декілька співробітників, загальне число яких заздалегідь невідомо і нічим не обмежена. Зауважимо, що замість кратності "1 ..*" записати тільки символ "*" не можна, оскільки останній означає кратність "0 ..*". Для даного прикладу це означало б, що окремі компанії можуть зовсім не мати співробітників у своєму штаті. Але така кратність цілком прийнятна в інших ситуаціях, як це видно з розглянутого вище прикладу (мал. 5.6).

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

  Окремим випадком відносини асоціації є так звана виключає асоціація (Xor-association). Семантика даної асоціації вказує на той факт, що з кількох потенційно можливих варіантів цієї асоціації в кожен момент часу може використовуватися тільки один її примірник. На діаграмі класів виключає асоціація зображується пунктирною лінією, що з'єднує дві і більше асоціації, поряд з якою записується рядок-обмеження "{хог}".

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

Рис. 5.7. Графічне зображення виключає асоціацію між трьома класами

  Спеціальною формою або окремим випадком відносини асоціації є відношення агрегації, яке, у свою чергу, теж має спеціальну форму - відношення композиції. Оскільки ці відносини мають свої спеціальні позначення і відносяться до базових понять мови UML, розглянемо їх послідовно.

3. Відношення агрегації

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

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

  Примітка

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

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

  Як приклад відносини агрегації розглянемо взаємозв'язок типу "частина-ціле", яка має місце між сутністю "Вантажний автомобіль" і такими компонентами, як "Двигун", "Шасі", "Кабіна", "Кузов". Не претендуючи на точну відповідність термінології даної предметної області, неважко уявити собі, що вантажний автомобіль складається з двигуна, шасі, кабіни і кузова. Саме це відношення між класом "Грузовой_автомобіль" і класами "Двигун", "Шасі", "Кабіна", "Кузов" описує ставлення агрегації.

  Графічно відношення агрегації зображується суцільною лінією, один з кінців якої представляє собою не зафарбований всередині ромб. Цей ромб вказує на той з класів, який являє собою "ціле". Решта класи є його "частинами" (рис. 5.8).

Рис. 5.8. Графічне зображення відношення агрегації в UML

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

Рис. 5.9. Діаграма класів для ілюстрації відносини агрегації на прикладі ПК

4. Відношення композиції

  Відношення композиції, як вже згадувалося раніше, є окремим випадком відносини агрегації. Це відношення служить для виділення спеціальної форми відносини "частина-ціле", при якій складові частини в деякому сенсі знаходяться всередині цілого. Специфіка взаємозв'язку між ними полягає в тому, що частини не можуть виступати у відриві від цілого, тобто зі знищенням цілого знищуються і всі його складові частини.

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

  Графічно відношення композиції зображується суцільною лінією, один з кінців якої представляє собою зафарбований всередині ромб. Цей ромб вказує на той з класів, який представляє собою клас-композицію або "ціле". Решта класи є його "частинами" (рис. 5.10).

Рис. 5.10. Графічне зображення відношення композиції в UML

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

Рис. 5.11. Діаграма класів для ілюстрації відносини композиції на прикладі класу вікна програми

  Даний приклад може ілюструвати та інші особливості розроблюваної комп'ютерної програми, які не вказувалися в явному вигляді при описі цього прикладу Так, зокрема, вказівку кратності 1 поряд з класом "Рабочая_область" характерно для однодокументних додатків.

5. Відношення узагальнення

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

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

Рис. 5.12. Графічне зображення відношення узагальнення у мові UML

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

Рис. 5.13. Приклад графічного зображення відношення узагальнення класів

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

Рис. 5.14. Варіант графічного зображення відношення узагальнення класів для випадку об'єднання окремих ліній

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

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

  В якості обмежень можуть бути використані наступні ключові слова мови UML: • {complete} - означає, що в даному відношенні узагальнення специфіковані всі класи-нащадки, і інших класів-нащадків у даного класу-предка бути не може. Приклад - клас Кліент_банка є предком для двох класів: Фізіческое_ліцо і Компанія, і інших класів-нащадків він не має. На відповідній діаграмі класів це можна вказати явно, записавши поруч з лінією узагальнення даний рядок-обмеження; • {disjoint} - означає, що класи-нащадки не можуть містити об'єктів, які одночасно є екземплярами двох або більше класів. У наведеному вище прикладі це умова також виконується, оскільки передбачається, що ніяке конкретне фізична особа не може бути одночасно і конкретною компанією. У цьому разі поряд із лінією узагальнення можна записати цей рядок-обмеження; • {incomplete} - означає випадок, протилежний першому. А саме, передбачається, що на малюнку, є не всі класи-нащадки. У подальшому можливо заповнити їх переліку не змінюючи вже побудовану діаграму. Приклад - діаграма класу "Автомобіль", для якої вказівка всіх без винятку моделей автомобілів порівнянно зі створенням відповідного каталогу. З іншого боку, для окремого завдання, такий як розробка системи продажу автомобілів конкретних моделей, в цьому немає необхідності. Але вказати неповноту структури класів-нащадків все ж таки слід; • {overlapping} - означає, що окремі екземпляри класів-нащадків можуть належати одночасно кільком класам. Приклад - клас "Багатокутник" є класом-предком для класу "Прямокутник" та класу "Ромб". Однак існує окремий клас "Квадрат", екземпляри якого одночасно є об'єктами перших двох класів. Цілком природно таку ситуацію вказати явно за допомогою цього рядка-обмеження.

  З урахуванням можливості використання рядків-обмежень діаграма класів (рис. 5.14) може бути зображена без крапок і без втрати інформації (рис. 5.15).

Рис. 5.15. Варіант графічного зображення відношення узагальнення класів з використанням рядка-обмеження

  Щоб проілюструвати особливості використання відношення узагальнення, перетворимо один із розглянутих раніше прикладів зображення класів в графічну нотацію мови UML. В якості такого прикладу розглянемо ієрархію вкладеності класів для абстрактного класу "Автомобіль" (див. рис. 1,2, 2.7). Як неважко помітити, відношення між окремими класами на цих малюнках є саме ставлення узагальнення, яке у мові UML має спеціальне графічне позначення. З урахуванням цієї графічної нотації, фрагмент семантичної мережі для подання ієрархії класу "Автомобіль" (див. рис. 2.7) може бути представлений у вигляді наступної діаграми класів (рис. 5.16).

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

Рис. 5.16. Фрагмент діаграми класів з відношенням узагальнення для подання ієрархії класів "Автомобіль" з розглянутого раніше прикладу (див. рис. 2.7)

  Примітка

  Як вправи для закріплення розглянутого матеріалу можна спробувати побудувати діаграми класів або хоча б їх фрагменти для бібліотек стандартних класів MFC (Microsoft) і VCL (Borland / Inprise) з використанням графічної нотації мови UML. Можна припустити, що в недалекому майбутньому довідкові посібники з відповідним середах програмування будуть мати саме такі діаграми класів, а можливо, і деякі інші.

6. Інтерфейси

  Інтерфейси є елементами діаграми варіантів використання і були розглянуті в розділі 4. Однак при побудові діаграми класів окремі інтерфейси можуть уточнюватися і в цьому випадку для їх зображення використовується спеціальний графічний символ - прямокутник класу з ключовим словом або стереотипом "interface" (рис. 5.17). При цьому секція атрибутів у прямокутника відсутня, а вказується тільки секція операцій.

Рис. 5.17. Приклад графічного зображення інтерфейсу на діаграмі класів

7. Об'єкти

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

  Для графічного зображення об'єктів використовується такий же символ прямокутника, що і для класів. Відмінності проявляються при вказівці імен об'єктів, які в разі об'єктів обов'язково підкреслюються (рис. 5.18). При цьому запис імені об'єкта є рядком тексту "ім'я об'єкта: ім'я класу", розділену двокрапкою (рис. 5.18 а, б). Назва об'єкту може бути відсутнім, в цьому випадку передбачається, що об'єкт є анонімним, і двокрапку вказує на дану обставину (рис. 5.18, г). Відсутні може й ім'я класу. Тоді вказується просто ім'я об'єкта (рис. 5.18, в). Атрибути об'єктів приймають конкретні значення.

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

Рис. 5.18. Приклад графічного зображення об'єктів на діаграмах мови UML

8. Шаблони або параметризрвані класи

  Шаблон (template) або параметризованих клас (parametrized class) призначений для позначення такого класу, який має один (або більше) нефіксований формальний параметр. Він визначає ціле сімейство або безліч класів, кожен з яких може бути отриманий зв'язуванням цих параметрів з дійсними значеннями. Зазвичай параметрами шаблонів служать типи атрибутів класів, такі як цілі числа, перерахування, масив рядків і ін У більш складному випадку формальні параметри можуть представляти і операції класу.

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

Рис. 5.19. Графічне зображення шаблона на діаграмі класів

  Шаблон не може бути безпосередньо використаний як класу, оскільки містить невизначені параметри. Найчастіше в якості шаблону виступає деякий суперклас, параметри якого уточнюються в його класах-нащадках. Очевидно, в цьому випадку між ними існує відношення залежності з ключовим словом "bind", коли клас-клієнт може використовувати певний шаблон для своєї подальшої параметризації. У більш окремому випадку між шаблоном і формується від нього класом має місце відношення узагальнення зі спадкуванням властивостей шаблону (мал. 5.20). У даному прикладі відзначений той факт, що клас "Адреса" може бути отриманий з шаблону Связний_спісок на основі актуалізації формальних параметрів "S, k, l" фактичними атрибутами "вулиця, будинок, квартира".

  Цей самий шаблон може використовуватися для завдання (інстанціювання) іншого класу, скажімо, класу "Точкі_на_плоскості". У цьому разі клас "Точкі_на_плоскості" актуалізує ті ж формальні параметри, але з іншими значеннями, наприклад, "ЬтсГ <коордінати_точкі, х, у>. Концепція шаблонів є досить потужним засобом в ООП, і тому її використання в мові UML дозволяє не тільки скоротити розміри діаграм, але і найбільш коректно керувати спадкуванням властивостей і поводження окремих елементів моделі.

Рис. 5.20. Приклад використання шаблону на діаграмі класів

9. Рекомендації з побудови діаграм класів

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

  Такий стереотипний підхід дозволяє істотно скоротити терміни реалізації проекту, однак прийнятний лише в тому випадку, коли новий проект концептуально і технологічно не надто відрізняється від попередніх. В іншому випадку платою за скорочення строків проекту може стати його реалізація на застарілій технологічній базі. Що стосується власне об'єктної структуризації предметної області, то тут доречно дотримуватися тих рекомендацій, які накопичені в ООП. Вони широко висвітлені в літературі [1, 2, 4, 10, 13, 18, 20] і тому тут не розглядаються.

  При визначенні класів, атрибутів та операцій і завданні їхніх імен і типів перед вітчизняними розробниками завжди встає мимовільний питання: яку з мов використовувати як природного, російську або англійську? З одного боку, використання рідної мови для опису моделі є найбільш природним способом її подання та найбільшою мірою відображає комунікативну функцію моделі системи. З іншого боку, розробка моделі є лише одним з етапів розробки відповідної системи, а застосування інструментальних засобів для її реалізації в абсолютній більшості випадків вимагає використання англомовних термінів. Саме тому виникає характерна неоднозначність, з якою, мабуть, зовсім незнайома англомовна аудиторія.

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

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

  Більш того, використання CASE-інструментаріїв для автоматизації ООАП, найчастіше, накладає свої власні вимоги на мову специфікації моделей. Саме з цієї причини більшість прикладів у літературі даються в англомовному поданні, а при їх перекладі на російську може бути втрачена не лише точність формулювань, але і семантика відповідних понять.

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


 

А также другие работы, которые могут Вас заинтересовать

76722. Развитие лесного дела в период правления Петра І 130.51 KB
  Сведения о лесах встречаются в разных великокняжеских и царских грамотах некоторых других исторических и географических документах. Рыболовство в лесных озерах и реках охота и бортничество привлекало людей именно в леса.
76723. Индикаторы и динамика устойчивого экономического развития 3.74 MB
  В качестве наиболее общим индикаторов устойчивого развития принят интегральный показатель устойчивого развития, который основан на индексе развития человеческого потенциала. Система индикаторов устойчивого развития включает как общесистемные индикаторы, так и индикаторы...
76724. Вооруженные силы Московского государства в первой половине XVII века. «Полки нового строя» Алексея Михайловича 52.86 KB
  Во время войны они выступали с великим князем или с воеводами а в мирное время являлись помещиками и получали за службу земли в условное держание. В результате вассалитет князей и бояр был преобразован в государевых служилых людей за службу в условное держание реже в вотчину получавших поместья.
76725. Влияние и последствия применения допинга в большом спорте 38.13 KB
  Допинг – это лекарственные препараты, которые применяются спортсменами для искусственного, принудительного повышения работоспособности в период учебно-тренировочного процесса и соревновательной деятельности.
76726. Газопровод Саратов – Москва 81.7 KB
  История развития газовой отрасли в Саратовской области начинает свой отсчет с далекого 1906го года. В то время открытия месторождений газа как правило происходило совершенно случайно. Сын купца студент Рижского политехнического института понял что из скважины произошло выделение газа.
76727. Процесс развития личности и факторы, влияющие на него. Взаимовлияние внутренних и внешних, стихийных и управляемых факторов 103 KB
  Каждый человек проходит младенческую стадию развития, когда он учиться двигаться, говорить, мыслить. Точно так же каждый индивид развивается, как личность Формируется его мировоззрение и понимание мира. От этого будет зависеть его последующая роль в жизни общества.
76728. Трудовые ресурсы, персонал и трудовой потенциал организации 95 KB
  Современный трудовой коллектив представляет собой сложную социальную систему, где отдельные личности и группы людей взаимодействуют на принципах, весьма далеких от формально предписанных.
76729. Техника плавания способом кроль на спине 59.64 KB
  Славяне со свойственной им смекалкой с целью обмануть противника ложатся на дно реки навзничь и дышат держа во рту длинные нарочно для этого просверленные внутри камыши концы которых выходят на поверхность воды. Плечевой пояс расположен немного выше таза таз и бедра у поверхности воды.
76730. Брачно-семейные отношения 74.5 KB
  Личные и имущественные отношения супругов. Свойство – отношения между людьми возникающие вследствие брачного союза: отношения между супругом и родственниками другого супруга а также между родственниками супругов. Семейного Кодекса РФ: государственная защита семьи материнства отцовства; недопустимость произвольного вмешательства в дела семьи; беспрепятственное осуществление членами семьи своих прав; возможность судебной защиты этих прав; признание брака заключенного только в органах записи актов гражданского состояния; ...