 |
|
|
Архитектура Астрономия Аудит Биология Ботаника Бухгалтерский учёт Войное дело Генетика География Геология Дизайн Искусство История Кино Кулинария Культура Литература Математика Медицина Металлургия Мифология Музыка Психология Религия Спорт Строительство Техника Транспорт Туризм Усадьба Физика Фотография Химия Экология Электричество Электроника Энергетика |
Діаграма класів (class diagram)
Діаграма класів (class diagram) призначена для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відображати, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти і підсистеми, а також описує їх внутрішню структуру і типів відношень. На даній діаграмі не вказується інформація про часові аспекти функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи. Діаграма класів є деякий граф, вершинами якого є елементи типу "класифікатор", які зв'язані різними типами структурних відношень. Діаграма класів може також містити інтерфейси, пакети, відношення і навіть окремі екземпляри, такі як об'єкти і зв'язки. Діаграму класів прийнято вважати графічним представленням таких структурних взаємозв'язків логічної моделі системи, які не залежать (інваріантні) від часу. Діаграма класів складається з множини елементів, які в сукупності відображають декларативні знання про предметну область. Ці знання інтерпретуються в базові поняття мови UML, такі як класи, інтерфейси і відношення між ними і їх складовими компонентами. При цьому окремі компоненти цієї діаграми можуть утворювати пакети для представлення більш загальної моделі системи. Якщо діаграма класів є частиною деякого пакету, то її компоненти повинні відповідати елементам цього пакету, включаючи можливі посилання на елементи з інших пакетів. У загальному випадку пакет статичної структурної моделі може бути представлений у вигляді однієї або декількох діаграм класів. Декомпозиція деякого представлення на окремі діаграми виконується з метою зручності і графічної візуалізації структурних взаємозв'язків предметної області. При цьому компоненти діаграми відповідають елементам статичної семантичної моделі. Модель системи, у свою чергу, має бути узгоджена з внутрішньою структурою класів, яка описується на мові UML. 5.1. Клас Клас (class) в мові UML призначений для позначення множини об'єктів, які володіють однаковою структурою, поведінкою і відношеннями з об'єктами інших класів. Графічно клас зображається у вигляді прямокутника, який додатково може бути розділений горизонтальними лініями на розділи або секції (мал. 5.1). У цих розділах можуть вказуватися ім'я класу, атрибути (змінні) і операції (методи).
Мал. 5.1. Графічне зображення класу на діаграмі класів Обов'язковим елементом позначення класу є його ім'я. На початкових етапах розробки діаграми окремі класи можуть позначатися простим прямокутником з вказанням лише імені відповідного класу (мал. 5.1, а). У міру опрацювання окремих компонентів діаграми опису класів доповнюються атрибутами (мал. 5.1, би) і операціями (мал. 5.1, в). Остаточний варіант діаграми містить якнайповніший опис класів, які складаються з трьох розділів. Інколи в позначеннях класів використовується додатковий четвертий розділ (секція), в якому приводиться семантична інформація довідкового характеру або явно вказуються виняткові ситуації. Навіть якщо секція атрибутів і операцій є порожньою, в позначенні класу вона виділяється горизонтальною лінією, щоб відразу відрізнити клас від інших елементів мови UML. Приклади графічного зображення класів на діаграмі класів наведені на мал. 5.2. У першому випадку для класу "Прямокутник" (мал. 5.2, а) вказані лише його атрибути – точки на координатній площині, які визначають його розташування. Для класу "Вікно" (мал. 5.2, би) вказані лише його операції, секція атрибутів залишена порожньою. Для класу "Рахунок" (мал. 5.2, в) додатково зображена четверта секція, в якій вказано вийняток – відмову від обробки простроченої кредитної картки.
Мал.5.2. Приклади графічного зображення класів на діаграмі Ім'я класу Ім'я класу має бути унікальним в межах пакету, який описується деякою сукупністю діаграм класів (можливо, однією діаграмою). Воно вказується в першій верхній секції прямокутника. Ім'я класу записується по центру секції імені напівжирним шрифтом і повинно починатися із заголовної букви. Рекомендується як імена класів використовувати іменники, записані з практичних міркувань без пропусків. Необхідно пам'ятати, що саме імена класів утворюють словник предметної області при ООАП. У першій секції позначення класу можуть бути посилання на стандартні шаблони або абстрактні класи, від яких утворений даний клас і, відповідно, від яких він успадковує властивості і методи. У цій секції може бути інформація про розробника даного класу і статус стану розробки, а також можуть записуватися і інші загальні властивості цього класу, що мають відношення до інших класів діаграми або стандартних елементів мови UML. Прикладами імен класів можуть бути такі іменники, як "Співробітник", "Компанія", "Керівник", "Клієнт", "Продавець", "Менеджер", "Офіс" і багато інших, що мають безпосереднє відношення до модельованої предметної області і функціонального призначення проектованої системи. Клас може не мати екземплярів або об'єктів. У цьому випадку він називається абстрактним класом, а для позначення його імені використовується похилий шрифт (курсив). У мові UML прийнята загальна домовленість про те, що будь-який текст, який має відношення до абстрактного елементу, записується курсивом. Атрибути класу У другій зверху секції прямокутника класу записуються його атрибути (attributes) або властивості. У мові UML прийнята певна стандартизація запису атрибутів класу, згідно деяких синтаксичних правил. Кожному атрибуту класу відповідає окремий рядок тексту, який складається з квантора видимості атрибуту, імені атрибуту, його кратності, типу значень атрибуту і, можливо, його початкового значення: <квантор видимості><імя атрибуту>[кратність]: <тип атрибуту> = <початкове значення>{ рядок-властивість} Квантор видимості може приймати одне з трьох значень і, відповідно, зображається за допомогою спеціальних символів:
Квантор видимості може бути опущений. В цьому випадку його відсутність просто означає, що видимість атрибуту не вказується. Ця ситуація відрізняється від прийнятих за замовчуванням домовленостей у традиційних мовах програмування, коли відсутність квантора видимості трактується як public або private. Замість умовних графічних позначень можна записувати відповідне ключове слово: public, protected, private. Примітка. Оскільки мова UML інваріантна відносно реалізації своїх конструкцій в конкретних мовах програмування, семантика окремих кванторів видимості не є строго фіксованою. Значення цих кванторів повинні додатково уточнюватися текстом пояснення на природній мові або домовленістю по використанню відповідних програмно-залежних синтаксичних конструкцій. Ім'я атрибуту є рядком тексту, який використовується як ідентифікатор відповідного атрибуту і тому має бути унікальним у межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення атрибуту. Кратність атрибуту характеризує загальну кількість конкретних атрибутів даного типу, які входять до складу окремого класу. У загальному випадку кратність записується у формі рядка тексту в квадратних дужках після імені відповідного атрибуту: [нижня_межа1 .. верхня_межа1, нижня_межа2 .. верхня_межа2, …, нижня_межаk .. верхня_межаk], де нижня_межа і верхня_межа є позитивними цілими числами, кожна пара яких призначена для позначення окремого замкнутого інтервалу цілих чисел, в якому нижня (верхня) межа дорівнює значенню нижня_межа (верхня_межа). Дане умовне позначення кратності відповідає теоретико-множинному об'єднанню відповідних інтервалів. Як верхня_межа може використовуватися спеціальний символ "*", який означає довільне позитивне ціле число. Іншими словами, це означає необмежене зверху значення кратності відповідного атрибуту. Якщо кратність вказується одним число, то кратність атрибуту дорівнює даному числу. Якщо ж вказується єдиний знак "*", то це означає, що кратність атрибуту може бути довільним позитивним цілим числом або нулем. {Як приклад розглянемо наступні варіанти задання кратності атрибутів. •[0..1] означає, що кратність атрибуту може набувати значення 0 або 1. При цьому 0 означає відсутність значення для даного атрибуту. •[0..*] означає, що кратність атрибуту може набувати будь-якого позитивного цілого значення більше або рівніше 0. Ця кратність може бути записана коротше у вигляді простого символу - [*]. •[1.:*] означає, що кратність атрибуту може набувати будь-якого позитивного цілого значення більше або рівніше 1. •[1..5] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, 4, 5. •[1..3,5,7] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, 5, 7. •[1..3,7.. 10] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, 7, 8, 9, 10. •[1..3,7..*] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, а також будь-яке позитивне ціле значення більше або рівніше 7.} Якщо кратність атрибуту не вказана, то за замовчуванням її значення рівне 1. Типом атрибуту є вираз, семантика якого визначається мовою специфікації відповідної моделі. У нотації UML тип атрибуту інколи визначається залежно від мови програмування, яку передбачається використовувати для реалізації даної моделі. {Можна навести наступні приклади задання імен і типів атрибутів класів: •колір: Соlоr - тут колір є ім'ям атрибуту, Color - ім'ям типу даного атрибуту. Вказаний запис може визначати традиційно використовувану RGB-модель (червоний, зелений, синій) для представлення кольору. В цьому випадку ім'я типа Color якраз і характеризує семантичну конструкцію, яка застосовується у більшості мов програмування для представлення кольору. •имя_сотрудника [1..2] : String - тут имя_сотрудника є ім'ям атрибуту, який призначений для уявлення інформації про ім'я, а можливо, і по батькові конкретного співробітника. Тип атрибуту String (Рядок) якраз і вказує на той факт, що окреме значення імені є рядком тексту з одного або двох слів (наприклад, "Кирило" або "Дмитро Іванович"). Оскільки в багатьох мовах програмування існує тип даних String, використання відповідного англомовного терміну не викликає непорозуміння у більшості програмістів. Проте, хоча в мові UML всі терміни даються в англомовній виставі, використання як тип атрибуту Рядок в даній ситуації не виключається і визначається лише міркуваннями зручності. •видимость:Boolean - тут видимість є ім'я абстрактного атрибуту (курсив тут не випадковий), який може характеризувати наявність візуального представлення відповідного класу на екрані монітора. В цьому випадку тип Boolean означає, що можливими значеннями даного атрибуту є одне з двох логічних значень: істина (true) або брехня (false). При цьому значення істина може відповідати наявності графічного зображення на екрані монітора, а значення брехня - його відсутності, про що додатково вказується в тексті пояснення. Оскільки кратність атрибуту видимість не вказана, вона набуває значення 1 за умовчанням. У цій ситуації англомовне ім'я типа атрибуту цілком виправдане наявністю відповідного базового типа в мовах програмування. Абстрактний характер даного атрибуту позначається курсивним текстом в записі даного атрибуту. •форма:Многоугольник - тут ім'я атрибуту форма може характеризувати такий клас, який є геометричною фігурою на плоскості. В цьому випадку типа атрибуту Багатокутник вказує на той факт, що окрема геометрична фігура може мати форму трикутника, прямокутника, ромба, п'ятикутника і будь-якого іншого багатокутника, але не кола або еліпса. Цілком очевидно, що в даній ситуації використання відповідного англомовного терміну навряд чи доцільно, оскільки тип Багатокутник не є базовим для мов програмування.} Початкове значення призначене для задання деякого початкового значення для відповідного атрибуту у момент створення окремого екземпляра класу. Тут необхідно дотримуватися правила приналежності значення типові конкретного атрибуту. Якщо початкове значення не вказане, то значення відповідного атрибуту не визначене на момент створення нового екземпляра класу. Конструктор відповідного об'єкту може перевизначати початкове значення в процесі виконання програми, якщо в цьому виникає необхідність. {Як приклади вихідних значень атрибутів можна привести наступні доповнені вище варіанти завдання атрибутів: •цвет:Соlоr = (255, 0, 0) - в RGB-модели кольору це відповідає чистому червоному кольору як вихідне значення для даного атрибуту. •имя_сотрудника[1..2]:String = Іван Іванович - можливо, це нетиповий випадок, який, швидше, відповідає ситуації имя_руководителя[2]:81пп§ = Іван Іванович. •видимость:Вооlеаn = істина - може відповідати ситуації, коли у момент створення екземпляра класу створюється видиме на екрані монітора вікно, відповідне даному об'єкту. •форма:Многоугольник = прямокутник - навряд чи вимагає коментарів, оскільки тут йдеться про геометричній формі створюваного об'єкту. } При заданні атрибутів можуть бути використані дві додаткові синтаксичні конструкції – це підкреслення рядка атрибуту і текст пояснення у фігурних дужках. Підкреслення рядка атрибуту означає, що відповідний атрибут може приймати підмножину значень з деякої області значень атрибуту, визначуваної його типом. Ці значення можна розглядати як набір однотипних записів або масив, які в сукупності характеризують кожен об'єкт класу. Наприклад, якщо деякий атрибут заданий у вигляді форма: Прямокутник. то це означає, що всі об'єкти даного класу можуть мати декілька різних форм, кожна з яких є прямокутником. Іншим прикладом може бути задання атрибуту у вигляді номер_рахунку:Integer, що може означати для об'єкту Співробітник наявність деякої підмножини рахунків, загальна кількість яких заздалегідь не фіксується. Рядок-властивість призначений для задання значень атрибуту, які не можуть бути змінені в програмі при роботі з даним типом об'єктів. Фігурні дужки позначають фіксоване значення відповідного атрибуту для класу в цілому, яке повинні приймати всі новостворювані екземпляри класу без винятку. Це значення береться за початкове значення атрибуту, яке не може бути перевизначене в подальшому. Відсутність рядка-властивості за замовчуванням трактується так, що значення відповідного атрибуту може бути змінене в програмі. Наприклад, рядок-властивість в записі атрибуту заработна_плата:Currency = {$500} призначений для позначення фіксованої заробітної плати для кожного об'єкту класу "Співробітник" певної посади в деякій організації. З іншого боку, запис даного атрибуту у вигляді заробітна_плата: Currency = $500 означає вже щось інше, а саме – при створенні нового екземпляра Співробітник (аналогія – прийом на роботу нового співробітника) для нього встановлюється за замовчуванням заробітна плата в $500. Проте для окремих співробітників можуть бути зроблені винятки як у більшу, так і в меншу сторону, про що необхідно подбати додатково у програмі. Операція У третій зверху секції прямокутника записуються операції або методи класу. Операція (operation) є деяким сервісом, що надає кожен екземпляр класу на певну вимогу. Сукупність операцій характеризує функціональний аспект поведінки класу. Запис операцій класу в мові UML також стандартизовано згідно з певними синтаксичними правилами. При цьому кожній операції класу відповідає окремий рядок, який складається з квантора видимості операції, імені операції, типу результату і, можливо, рядок-властивість даної операції: <квантор видимості><імя операції>(список параметрів): <тип результату>{ рядок-властивість} Квантор видимості, як і у разі атрибутів класу, може приймати одне з трьох можливих значень і, відповідно, відображується за допомогою спеціального символу. Символ "+" позначає операцію з областю видимості типа загальнодоступний (public). Символ "#" позначає операцію з областю видимості типа захищений (protected). І, нарешті, символ "-" використовується для позначення операції з областю видимості типа закритий (private). Квантор видимості для операції може бути опущений. В цьому випадку його відсутність просто означає, що видимість операції не вказується. Замість умовних графічних позначень також можна записувати відповідне ключове слово: public, protected, private. Примітка. Для конкретних мов програмування можуть бути визначені додаткові квантори видимості. В цьому випадку подібні доповнення є розширенням базової нотації і вимагають відповідних пояснень у формі тексту на природній мові або у вигляді рядка-властивості. Ім'я операції є рядком тексту, який використовується як ідентифікатор відповідної операції і тому має бути унікальною в межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення операції. Список параметрів є переліком розділених комами формальних параметрів, кожен з яких може бути представлений в наступному вигляді: <вид параметру><імя параметру>:<тип>=<значение параметра за замовчуванням>. Тут вид параметру – є одне з ключових слів in, out або inout із значенням in за замовчуванням, у випадку якщо вид параметру не вказується. Ім'я параметру є ідентифікатор відповідного формального параметра. Тип є залежною від конкретної мови програмування специфікацією типу результату для відповідного формального параметру. Значення за замовчуванням у загальному випадку є вираз для значення формального параметру, синтаксис якого залежить від конкретної мови програмування з прийнятими в ній обмеженнями. Тип результату також є залежний від мови реалізації. Двокрапка і тип результату можуть бути опущені, якщо операція не повертає жодного значення. Рядок-властивість призначений для вказівки значень властивостей, які можуть бути застосовані до даного елементу. Рядок-властивість не є обов'язковим, він може бути відсутнім, якщо жодні властивості не специфіковані. Операція із областю дії на весь клас вказується підкресленням імені і типу. За замовчуванням під областю дії операції є об'єкт класу. У цьому випадку ім'я і тип операції не підкреслюються. Операція, яка не може змінювати стан системи і, відповідно, не має жодного побічного ефекту, позначається рядком-властивістю "{ запит}" ("{query}"). Інакше операція може змінювати стан системи, хоча немає жодних гарантій, що вона буде це робити. Для підвищення продуктивності системи деякі операції можуть виконуватися паралельно (одночасно), а інші – тільки послідовно. У цьому випадку для вказівки паралельності виконання операції використовується рядок-властивість вигляду "{concurrency = ім'я}", де ім'я може приймати одне з наступних значень: послідовна (sequential), паралельна (concurrent), така, що охороняється (guarded). При цьому дотримуються наступної семантики для даних значень: •послідовна (sequential) - для даної операції необхідно забезпечити її єдине виконання в системі, одночасне виконання інших операцій може привести до помилок або порушень цілісності об'єктів класу. •паралельна (concurrent) - дана операція через свої особливості може виконуватися паралельно з іншими операціями в системі, при цьому паралельність повинна підтримуватися на рівні реалізації моделі. •що охороняється (guarded) - всі звернення до даної операції мають бути строго впорядковані в часі з метою збереження цілісності об'єктів даного класу, при цьому можуть бути прийняті додаткові заходи контролю виняткових ситуацій на етапі її виконання. З метою скорочення позначень допускається використання одного імені як рядок-властивість для вказівки відповідного значення паралельності. Відсутність даного рядка-властивості означає, що семантика паралельності для операції не визначена. Тому слід передбачити гірший з точки зору продуктивності випадок, коли дана операція вимагає послідовного виконання. Поява сигнатури операції на найвищому рівні оголошує цю операцію на весь клас, при цьому дана операція успадковується всіма нащадками даного класу. Якщо в деякому класі операція не виконується (тобто деякий метод не застосовується), то така операція може бути помічена як абстрактна "{abstract}". Інший спосіб показати абстрактний характер операції - записати її сигнатуру курсивом. Підлегла поява запису даної операції без властивості {абстрактна} вказує на той факт, що відповідний клас-нащадок може виконувати дану операцію як “свій” метод. Якщо для деякої операції необхідно додатково вказати особливості її реалізації (наприклад, алгоритм), то це може бути зроблено у формі примітки, записаної у вигляді тексту, який приєднується до запису операції у відповідній секції класу. Якщо об'єкти класу приймають і реагують на деякий сигнал, то запис даної операції позначається ключовим словом "сигнал" ("signal"). Це позначення рівнозначне позначенню деякої операції. Реакція об'єкту на прийом сигналу може бути показана у вигляді деякого автомата. Окрім інших випадків ця нотація може бути використана, щоб показати реакцію об'єктів класу на помилки (виключні ситуації), які можуть моделюватися як сигнали або повідомлення. Поведінка операції може бути додатково вказана у формі приєднаної до операції примітки. У цьому випадку текст примітки береться в дужки, якщо він є формальною специфікацією на деякій мові програмування і відповідає елементу "семантичне обмеження мови UML". Список формальних параметрів і тип результату можуть не вказуватися. Квантор видимості атрибутів і операцій може бути вказаний у вигляді спеціального значка або символу, які використовуються для графічного представлення моделей в деякому інструментальному засобі. Імена операцій, так само як і атрибутів, записуються з рядкової (малою) букви, а їх типи - із заголовної (великий) букви. При цьому обов'язковою частиною рядка запису операції є наявність імені операції і круглих дужок. Як приклади запису операцій можна привести наступні позначення окремих операцій: · +створити() – може позначати абстрактну операцію для створення окремого об'єкту класу, яка є загальнодоступною і не містить формальних параметрів. Ця операція не повертає жодного значення після свого виконання. · +намалювати(форма: Багатокутник = прямокутник, колір_заливки: Color = (Про, Про, 255)) – може позначати операцію для зображення на екрані прямокутної області синього кольору, якщо не вказуються інші значення як аргументи даної операції. · запросить_счет_клиента(номер_рахунку:Integer):Currency – позначає операцію по встановленню наявності засобів на поточному рахунку клієнта банку. При цьому аргументом даної операції є номер рахунку клієнта, який записується у вигляді цілого числа (наприклад, "123456"). Результатом виконання цієї операції є деяке число, записане в прийнятому грошовому форматі (наприклад, $1,500.00). · видати_повідомлення():{"Помилка ділення на нуль"} – смисл даної операції не вимагає пояснення, оскільки воно міститься в рядку-властивості операції. Дане повідомлення може з'явитися на екрані монітора в разі спроби ділення деякого числа на нуль. ·
5.2. Відношення між класами Окрім структури класів на відповідній діаграмі вказуються різні відношення між класами. При цьому сукупність типів таких відношень фіксована в мові UML і зумовлена семантикою цих типів відношень. Базовими відношеннями у мові UML є: · •Відношення залежності (dependency relationship) · •Відношення асоціації (association relationship) · •Відношення узагальнення (generalization relationship) · •Відношення реалізації (realization relationship) Кожне з цих відношень має власне графічне представлення на діаграмі, яке відображає взаємозв'язки між об'єктами відповідних класів. Відношення залежності Відношення залежності в загальному випадку вказує деяке семантичне відношення між двома елементами моделі або двома множинами таких елементів, яке не є відношенням асоціації, узагальнення або реалізації. Воно стосується лише самих елементів моделі і не вимагає множини окремих прикладів для пояснення свого сенсу. Відношення залежності використовується в такій ситуації, коли деяка зміна одного елементу моделі може потребувати зміни іншого залежного від нього елементу моделі. Відношення залежності графічно зображається пунктирною лінією між відповідними елементами із стрілкою на одному з її кінців ("- >" або "<-"). На діаграмі класів дане відношення зв'язує окремі класи між собою, при цьому стрілка направлена від класу-клієнта залежності до незалежного класу або класу-джерела (мал. 5.3). На даному малюнку змальовано два класи: Класс_А і Класс_Б, при цьому Класс_Б є джерелом деякої залежності, а Класс_А - клієнтом цієї залежності.
Мал. 5.3. Графічне зображення відношення залежності на діаграмі класів Як клас-клієнт і клас-джерело залежності може бути множина елементів моделі. У цьому випадку одна лінія із стрілкою, що виходить від джерела залежності, розщеплюється в деякій точці на декілька окремих ліній, кожна з яких має окрему стрілку для класу-клієнта. Наприклад, якщо функціонування Класс_С залежить від особливостей реалізації Класс_А і Класс_Б, то дана залежність може бути зображена таким чином (мал. 5.4).
Мал. 5.4. Графічне представлення залежності між класом-клієнтом (Класс_С) і класами-джерелами (Класс_А і Класс_В) Стрілка може позначатися необов'язковим, але стандартним ключовим словом в лапках і необов'язковим індивідуальним ім'ям. Для відношення залежності є ключові слова, які позначають деякі спеціальні види залежностей. Ці ключові слова (стереотипи) записуються у лапках поряд із стрілкою, яка відповідає даній залежності. Приклади стереотипів для відношення залежності є: · "access" - призначений для позначення доступності відкритих атрибутів і операцій класу-джерела для класів-клієнтів; · "bind" - клас-клієнт може використовувати деякий шаблон для своєї подальшої параметризації; · "derive" - атрибути класу-клієнта можуть бути обчислені за атрибутами класу-джерела; · "import" - відкриті атрибути і операції класу-джерела стають частиною класу-клієнта, ніби вони були оголошені безпосередньо в ньому; · "refine" - вказує, що клас-клієнт є уточненням класу-джерела через причини історичного характеру, коли з'являється додаткова інформація в ході роботи над проектом. Примітка. Відношення залежності є найбільш загальною формою відношення в мові UML. Всі інші типи відношень можна вважати частковими випадками даного відношення. Відношення асоціації Відношення асоціації відповідає наявності деякого відношення між класами. Дане відношення позначається суцільною лінією з додатковими спеціальними символами, які характеризують окремі властивості конкретної асоціації. Як додаткові спеціальні символи можуть використовуватися ім'я асоціації, а також імена і кратність класів-ролей асоціації. Ім'я асоціації є необов'язковим елементом її позначення. Якщо воно задане, то записується із великої букви поряд з лінією відповідної асоціації. Найбільш простий випадок даного відношення - бінарна асоціація. Вона зв'язує точно два класи і, як виняток, може зв'язувати клас з самим собою. Для бінарної асоціації на діаграмі може бути вказаний порядок слідування класів з використанням трикутника у формі стрілки поряд з ім'ям даної асоціації. Напрям цієї стрілки вказує на порядок класів, один з яких є першим (з боку трикутника), а інший - другим (з боку вершини трикутника). Відсутність даної стрілки поряд з ім'ям асоціації означає, що порядок слідування класів в даному відношенні не визначений. Як простий приклад відношення бінарної асоціації розглянемо відношення між двома класами - класом "Компанія" і класом "Співробітник" (мал. 5.5). Вони зв'язані між собою бінарною асоціацією Робота, ім'я якої вказане на малюнку поряд з лінією асоціації. Для даного відношення визначений порядок слідування класів, першим з яких є клас "Співробітник", а другим - клас "Компанія". Екземпляром даного відношення може бути пара значень (Петров І. І., "Рога&копита"). Це означає, що співробітник Петров І. І. працює в компанії "Рога&копита".
Мал. 5.5. Графічне зображення відношення бінарної асоціації між класами Асоціація вищої арності зв'язує деяким відношенням 3 і більше класи, при цьому один клас може брати участь в асоціації більше одиного разу. Така асоціація у загальному випадку називається N-арною асоціацією. Кожен екземпляр N-арної асоціації є N-арний кортеж значень об'єктів з відповідних класів. N-арна асоціація графічно позначається ромбом, від якого ведуть лінії до символів класів даної асоціації. В цьому випадку ромб з'єднується з символами відповідних класів суцільними лініями. Зазвичай лінії проводяться від вершин ромба або від середини його сторін. Ім'я N-арної асоціації записується поряд з ромбом відповідної асоціації. Порядок класів у N-арній асоціації на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, асоціація має атрибути, операції і асоціації. Така асоціація є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом мови UML – асоціацією-класом (Association Class). N-арная асоціація не може містити символ агрегації ні для якої зі своїх ролей. Як приклад тернарної асоціації розглянемо відношення між трьома класами: "Футбольна команда", "Рік" і "Гра". Дана асоціація вказує на наявність відношення між цими трьома класами, яке може представляти інформацію про ігри футбольних команд в національному чемпіонаті протягом декількох останніх років (мал. 5.6). Окремий клас асоціації має власну роль у відношенні. У мові UML є спеціальний елемент – кінець асоціації (Association End), який графічно відповідає точці з'єднання лінії асоціації з окремим класом. Кінець асоціації є частиною асоціації, але не класу. Кожна асоціація має два або більше кінців асоціації. Найважливіші властивості асоціації вказуються на діаграмі поряд з цими елементами асоціації.
Мал. 5.6. Графічне зображення тернарної асоціації між трьома класами Одним з таких додаткових позначень є ім'я ролі окремого класу, який входить в асоціацію. Ім'я ролі є рядком тексту поряд з кінцем асоціації для відповідного классу. Ім'я ролі не є обов'язковим елементом і може бути відсутнім на діаграмі. Наступний елемент позначень – кратність окремих класів, що є кінцями асоціації. Кратність окремого класу позначається у вигляді інтервалу цілих чисел, аналогічно кратності атрибутів і операцій класів. Так, для розглянутого раніше прикладу (див. мал. 5.5) кратність "1" для класу "Компанія" означає, що кожен співробітник може працювати лише в одній компанії. Кратність "1..*" для класу "Співробітник" означає, що в кожній компанії можуть працювати декілька співробітників, загальне число яких заздалегідь невідоме і нічим не обмежено. Відмітимо, що замість кратності "1..*" записати лише символ "*" не можна, оскільки останній означає кратність "0..*". Для даного прикладу це означало б, що окремі компанії можуть зовсім не мати співробітників в своєму штаті. Але така кратність цілком прийнятна в інших ситуаціях, як це видно з розглянутого вище прикладу (мал. 5.6). Окремим випадком відношення асоціації є xor-асоціація (Xor-association). Семантика даної асоціації вказує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожен момент часу може використовуватися лише один її екземпляр. На діаграмі класів xor-асоціація зображається пунктирною лінією, яка сполучає дві і більше асоціації, поряд з якою записується рядок-обмеження "{ хог}". Наприклад, рахунок у банку може бути відкритий для клієнта, який може бути фізичною особою (індивідум) або компанією, що зображається за допомогою xor-асоціації (мал. 5.7).
Мал. 5.7. Графічне зображення xor-асоціації між трьома класами Окремим випадком відношення асоціації є відношення агрегації, яке має спеціальну форму – відношення композиції. Оскільки ці відношення мають свої спеціальні позначення і відносяться до базових понять мови UML, розглянемо їх. Відношення агрегації Відношення агрегації має місце між декількома класами у тому випадку, якщо один з класів є деякою сутністю, яка включає як складові частини інші сутності. Це відношення має фундаментальне значення для опису структури складних систем, оскільки застосовується для представлення системних взаємозв'язків типу "частина-ціле". Відношення агрегації показує, з яких компонентів складається система і як вони зв'язані між собою. Це відношення за своєю сутю описує декомпозицію або розбиття складної системи на простіші складові частини, які також можуть бути піддані декомпозиції, якщо в цьому виникне необхідність в подальшому. Очевидно, що поділ системи на складові частини є деякою ієрархією її компонентів, проте дана ієрархія принципово відрізняється від ієрархії, що породжується відношенням узагальнення. Відмінність полягає у тому, що частини системи ніяк не зобов'язані успадковувати її властивості і поведінку, оскільки є самостійними сутностями. Частини цілого володіють своїми власними атрибутами і операціями, які істотно відрізняються від атрибутів і операцій цілого. Приклад. Вантажний автомобіль складається з двигуна, шасі, кабіни і кузова. Саме це відношення між класом "Вантажний_автомобіль" і класами "Двигун", "Шасі", "Кабіна", "Кузов" описує відношення агрегації. Графічно відношення агрегації зображається суцільною лінією, один з кінців якої є незафарбованим усередині ромбом. Цей ромб вказує на той з класів, який є "цілим". Решта класи є його "частинами" (мал. 5.8).
Мал. 5.8. Графічне зображення відношення агрегації в мові UML Ще одним прикладом відношення агрегації може бути поділ персонального комп'ютера на складові частини: системний блок, монітор, клавіатуру і мишу. Використовуючи позначення мови UML, компонентний склад ПК можна представити у вигляді відповідної діаграми класів (мал. 5.9), яка в даному випадку ілюструє відношення агрегації.
Мал. 5.9. Діаграма класів для ілюстрації відношення агрегації на прикладі ПК Відношення композиції Це відношення призначене для виділення спеціальної форми відношення "часть-целое", при якій складники в деякому розумінні є всередині цілого. Специфіка взаємозв'язку між ними полягає в тому, що частини не можуть виступати у відриві від цілого, і зі знищенням цілого знищуються і всі його складові частини. Приклад – вікно інтерфейсу програми, яке може містити заголовок, кнопки управління, смуги прокрутки, головне меню, робочу області і стрічку стану. Неважко зрозуміти, що подібним вікном є клас, а його компоненти є як класами, так і атрибутами або властивостями вікна. Графічно відношення композиції зображається суцільною лінією, один з кінців якої є зафарбованим ромбом. Цей ромб вказує на той з класів, який є класом-композицією або "ціле". Решта класи є його "частинами" (мал. 5.10).
Мал. 5.10. Графічне зображення відношення композиції в мові UML Для відношень композиції і агрегації можуть використовуватися додаткові позначення, вживані для відношення асоціації. А саме, кратність класу асоціації і ім’я даної асоціації, які не є обов'язковими. Стосовно описаного вище прикладу класу "Вікно_програми" його діаграма класів може мати наступний вигляд (мал. 5.11).
Мал. 5.11. Діаграма класів для ілюстрації відношення композиції на прикладі класу вікна програми Даний приклад може ілюструвати і інші особливості комп'ютерної програми, які не вказувалися в явному вигляді при описі цього прикладу. Вказівка кратності 1 поряд з класом "Рабочая_область" характерно для однодокументних застосувань. Відношення узагальнення Відношення узагальнення є відношенням між більш загальним елементом (батьком або предком) і частковим або спеціальним елементом (дочірним або нащадком). Дане відношення може використовуватися для представлення взаємозв'язків між пакетами, класами, варіантами використання і іншими елементами мови UML. На діаграмах класів дане відношення описує ієрархічну будову класів і наслідування їх властивостей і поведінки. На діаграмах відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців (мал. 5.12). Стрілка вказує на більш загальний клас (клас-предок або суперклас).
Мал. 5.12. Графічне зображення відношення узагальнення в мові UML На діаграмі може вказуватися декілька ліній для одного відношення узагальнення у випадку розбиття більш загального класу на підкласи одним відношенням. Наприклад, клас Геометрична_фігура_на_площині (курсив позначає абстрактний клас) може виступати як суперклас для підкласів відповідних геометричних фігур: Прямокутник, Коло, Еліпс і ін. Даний факт може бути представлений графічно у формі діаграми класів наступного вигляду (мал. 5.13).
Мал. 5.13. Приклад графічного зображення відношення узагальнення класів Для спрощення позначень на діаграмі класів сукупність ліній, які позначають одне відношення узагальнення, може бути об'єднана в одну лінію, де окремі лінії зображаються такими, що сходяться до єдиної стрілки, яка має з ними спільну точку перетину (мал. 5.14).
Мал. 5.14. Зображення відношення узагальнення класів для випадку об'єднання окремих ліній Поряд із стрілкою узагальнення може розміщуватися рядок тексту, вказуючий на деякі додаткові властивості цього відношення. При цьому текст слід розглядати як обмеження, і записувати у фігурних дужках. Як обмеження можуть бути використані наступні ключові слова мови UML: · {complete} - означає, що в даному відношенні узагальнення специфіковані всі класи-нащадки, і інших класів-нащадків у даного класу-предка бути не може. Приклад - клас Клієнт_банкe є предком для двох класів: Фізична_особа і Компанія, і інших класів-нащадків він не має. На діаграмі класів це можна вказати явно, записавши поряд з лінією узагальнення дане обмеження; · {disjoint} - означає, що класи-нащадки не можуть містити об'єктів, які одночасно є екземплярами двох або більше класів. У наведеному вище прикладі ця умова також виконується, оскільки передбачається, що жодна конкретна фізична особа не може бути одночасно і конкретною компанією. В цьому випадку поряд з лінією узагальнення можна записати дане обмеження; · {incomplete} - означає що на діаграмі вказані не всі класи-нащадки. У подальшому можливо поповнити їх перелік не змінюючи вже побудовану діаграму. Приклад – діаграма класу "Автомобіль", для якої перелік всіх без вийнятку моделей автомобілів рівнозначно створенню відповідного каталога. З іншого боку, для окремого завдання, такого як розробка системи продажу автомобілів конкретних моделей, в цьому немає необхідності. Але вказати неповноту структури класів-нащадків все ж слід; · {overlapping} - означає, що окремі екземпляри класів-нащадків можуть належати одночасно декільком класам. Приклад - клас "Багатокутник" є класом-предком для класу "Прямокутник" і класу "Ромб". Проте існує окремий клас "Квадрат", екземпляри якого одночасно є об'єктами перших двох класів. Таку ситуацію можна вказати явно за допомогою даного обмеження. З урахуванням можливості використання обмежень діаграма класів (мал. 5.14) може бути зображена без трикрапок і без втрати інформації (мал. 5.15).
Мал. 5.15. Графічне зображення відношення узагальнення класів з використанням обмеженнь Приклад. Розглянемо ієрархію класів для абстрактного класу "Автомобіль", яка може бути представлена у вигляді наступної діаграми класів (мал. 5.16). У даному прикладі всі класи верхніх рівнів є абстрактними, тобто не можуть бути представлені своїми екземплярами. Саме тому їх імена записані курсивом. Класи нижнього рівня є конкретними, оскільки можуть бути представлені своїми екземплярами, у якості яких виступають виготовлені автомобілі відповідної моделі з унікальним заводським номером.
Мал. 5.16. Фрагмент діаграми класів з відношенням узагальнення для ієрархії класів "Автомобіль" Інтерфейси. При побудові діаграми класів окремі інтерфейси можуть уточнюватися і в цьому випадку для їх зображення використовується прямокутник класу з ключовим словом або стереотипом "interface" (мал. 5.17). При цьому секція атрибутів відсутня, а вказується лише секція операцій.
Мал. 5.17. Приклад графічного зображення інтерфейсу на діаграмі класів Об'єкти Об'єкт (object) є окремим екземпляром класу, який створюється на етапі виконання програми. Він має своє власне ім'я і конкретні значення атрибутів. Може виникнути необхідність показати взаємозв'язки не лише між класами моделі, але і між окремими об'єктами, що реалізують ці класи. В даному випадку може бути розроблена діаграма об'єктів, яка, хоча і не є канонічною у мові UML, але має самостійне призначення. Для зображення об'єктів використовується прямокутник, як і для класів. Відмінністю є імена об'єктів, які у об'єктів обов'язково підкреслюються (мал. 5.18). Запис імені об'єкту є рядком тексту "ім’я_об’єкту:ім’я класу", розділеним двокрапкою (мал. 5.18 а, в). Ім'я об'єкту може бути відсутнім, у цьому випадку об'єкт є анонімним, і двокрапка вказує на дану обставину (мал. 5.18, г). Бути відсутнім може і ім'я класу. Тоді вказується просто ім'я об'єкту (мал. 5.18, б). Атрибути об'єктів приймають конкретні значення. При зображенні діаграми об'єктів потрібно пам'ятати, що кожним об'єктом є екземпляр відповідного класу, а відношення між об'єктами описуються за допомогою зв'язків (links), які є екземплярами відповідних відношень. При цьому всі зв'язки зображаються суцільними лініями.
Мал. 5.18. Приклад графічного зображення об'єктів на діаграмах мови UML Шаблони або класи, що параметризуються Шаблон (template) або клас (parametrized class), що параметризується, призначений для позначення такого класу, який має один (або більше) нефіксований формальний параметр. Він визначає цілу множину класів, кожен з яких може бути отриманий зв'язуванням цих параметрів з дійсними значеннями. Зазвичай параметрами шаблонів є типи атрибутів класів, такі як цілі числа, перелічення, масив стрічок і ін. Формальні параметри можуть представляти і операції класу. Графічно шаблон зображається прямокутником класу, до верхнього правого кута якого приєднаний маленький прямокутник з пунктирних ліній (мал. 5.19). У верхньому прямокутнику вказується список формальних параметрів для тих класів, які можуть бути отримані на основі шаблону. У верхній секції шаблону записується його ім'я за правилами запису імен для класів.
Мал. 5.19. Графічне зображення шаблону на діаграмі класів Шаблон не може бути безпосередньо використаний як клас, оскільки містить невизначені параметри. Найчастіше як шаблон виступає деякий суперклас, параметри якого уточнюються в його класах-нащадках. У цьому випадку між ними існує відношення залежності з ключовим словом "bind", коли клас-клієнт може використовувати деякий шаблон для своєї подальшій параметризації. У більш загальному випадку між шаблоном і формованим від нього класом має місце відношення узагальнення із наслідуванням властивостей шаблону (мал. 5.20). У даному прикладі відмічено той факт, що клас "Адреса" може бути отриманий з шаблону Зв’язний_список на основі актуалізації формальних параметрів "S, k, l" фактичними атрибутами "вулиця, будинок, квартира". Цей же шаблон може використовуватися для завдання іншого класу "Точка_на_площині". У цьому випадку клас "Точка_на_площині" актуалізує ті ж формальні параметри, але з іншими значеннями, наприклад, “bind”<координати_точки, х, у>. Концепція шаблонів є досить потужним засобом в ООП, і тому її використання в мові UML дозволяє не лише скоротити розміри діаграм, але і найкоректніше управляти наслідуванням властивостей і поведінки окремих елементів моделі.
Мал. 5.20. Приклад використання шаблону на діаграмі класів Рекомендації по побудові діаграм класів Процес розробки діаграми класів займає центральне місце в ООАП складних систем. Від уміння правильно вибрати класи і встановити між ними взаємозв'язки часто залежить не лише успіх процесу проектування, але і продуктивність виконання програми. Як показує практика ООП, кожен програміст в своїй роботі прагне використовувати вже накопичений особистий досвід при розробці нових проектів. Це обумовлено бажанням звести нове завдання до вже вирішених, щоб мати можливість використовувати не лише перевірені фрагменти програмного коду, але і окремі бібліотеки компонентів. Такий стереотипний підхід дозволяє істотно скоротити терміни реалізації проекту, проте прийнятний лише у тому випадку, коли новий проект концептуально і технологічно не дуже відрізняється від попередніх. Інакше платою за скорочення термінів проекту може стати його реалізація на застарілій технологічній базі. При визначенні класів, атрибутів і операцій і заданні їх імен і типів перед вітчизняними розробниками завжди постає питання: яку з мов використовувати? Після розробки діаграми класів процес ООАП може бути продовжений у двох напрямах. З одного боку, якщо поведінка системи тривіальна, то можна приступити до розробки діаграм кооперації і компонентів. Проте для складних динамічних систем поведінка представляє найважливіший аспект їх функціонування. Деталізація поведінки здійснюється послідовно при розробці діаграм станів, послідовності і діяльності.
Поиск по сайту: |
