Об'єктне моделювання автоматизованої системи технічної експлуатації автомобілів

Графічні конструкції та їх аналіз

Існує декілька видів графічних конструкцій (діаграм) складних систем.

Діаграми варіантів використання (прецедентів, тобто поведінок в певній ситуації) описують функціональне призначення системи або те, що система робитиме в процесі свого функціонування. Суть даної діаграми полягає в тому, що проектована система представляється у вигляді величезної кількості сутностей або акторів, які взаємодіють з системою за допомогою варіантів використання, кожен варіант використання визначає деякий набір дій, який виконується системою при діалозі з актором. Фігура «Чоловічок» на діаграмі варіантів використання — це і є актор — будь-яка сутність, що взаємодіє з системою ззовні. Актор пов’язаний з різними прецедентами і взаємодіє з системою за допомогою передачі і прийому повідомлень від варіантів використання. Окремий варіант використання відбивається на діаграмі еліпсом, у середині якого міститься його коротка назва. Додатково в діаграми можуть бути прикладені коментарі.

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

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

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

«+"операція з областю видимості типу загальнодоступний (public);

«#"операція з областю видимості типу захищений (protected);

«-"операція з областю видимості типу закритий (private).

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

відношення залежності (dependency), тобто відношення між двома або більше елементами моделі, при якому зміна одного елементу моделі може вплинути або надати інформацію, необхідну іншому елементу;

відношення асоціації (association), тобто відношення асоціації, яке відповідає наявності деякого відношення між класами;

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

система діаграма варіант використання відношення реалізації (realization), тобто відношення, яке вказує, що один з класів реалізує поведінку, специфіковану в іншому класі;

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

відношення композиції (include), тобто відношення, яке служить для виділення спеціальної форми відношення «частина-ціпе», де частини не можуть виступати у відриві від цілого.

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

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

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

synchronous, тобто повідомлення синхронне, яке застосовується, коли клієнт посилає повідомлення і чекає відповіді користувача;

return, тобто повернення повідомлення, коли одержувач повідомлення посилає і повертає фокус управління відправникові цього повідомлення;

asynchronous, тобто повідомлення асинхронне, коли клієнт посилає повідомлення сервера і продовжує свою роботу, не чекаючи підтвердження про отримання;

create, тобто створення повідомлення, коли відправник створює екземпляр класифікатора, визначений одержувачем;

destroy, тобто знищення повідомлення, коли відправник знищує одержувача;

found, тобто знайдене повідомлення, коли відправник одержувача знаходиться за зоною видимості взаємодії (використовується, коли необхідно показати отримання повідомлення без вказівки його джерела);

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

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

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

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

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

Автомат — це опис послідовності станів, через які проходить об'єкт впродовж ЖЦ, реагуючи на події, а також опис реакції на ці події. На діаграмі станів він володіє наступними графічними примітивами:

стани позначаються прямокутниками з округлими кутами, за винятком початкового стану (рисований круг) і кінцевого стану (бичаче око);

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

події записуються над переходами, які ініціюються ними.

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

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

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

Основа розробки об'єктної моделі системи TEA у відповідності з технологією ООП — це аналіз статики системи, яка проводиться шляхом побудови діаграм варіантів використання і діаграм класів.