Використання UML при моделюванні складних систем реального часу, Комерція, Різне, статті

Анотація

Вбудовувані системи реального часу, що зустрічаються в таких прикладних областях, як телекомунікації, аерокосмічні та оборонні програми, зазвичай мають тенденцію бути великими і складними. Вирішальним для таких систем є те, що вони повинні бути розроблені відповідно до розумної архітектурою. Гарна архітектура не тільки спрощує створення первісної системи, а й, що більш важливо, забезпечує адаптивність системи до змін, що викликаються постійною появою нових вимог. У цій статті ми описуємо набір конструкцій, що полегшують проектування архітектур для програм з цих предметних областей. Конструкції, отримані з підтверджених практикою концепцій спочатку описані в мові моделювання ROOM (Real-Time Object-Oriented Modeling – об’єктно-орієнтоване моделювання систем реального часу), специфіковані з використанням стандарту UML (Unified Modeling Language – універсальна мова моделювання). Зокрема, ми демонструємо, як ці архітектурні конструкції можуть бути отримані з більш загальних концепцій моделювання UML шляхом використання потужних механізмів розширення UML.

Введення

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

Предметна область додатків

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

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

 

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

 

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

 

Використання UML

 

Як згадувалося вище, UML використовувався для відображення цих конструкцій. Ми виявили, що він відмінно пристосований для цих цілей, так що нові для UML концепції моделювання не знадобилися. З великим успіхом були застосовані стандартні механізми настроювання UML, засновані на використанні стереотипів, приєднаних значень і обмежень. Наприклад, центральна для ROM концепція “actor” (актор) відображалася за допомогою стереотипу “capsule” (капсула) – спеціалізації більш загальної концепції класу з UML. Цей стереотип додав додаткову предметно-орієнтовану семантику до різних аспектів, пов’язаних з поняттям класу в UML (наприклад, кінцеві автомати, взаємодії тощо). Можливість використання стереотипів забезпечила простий і короткий шлях інтерпретації набору правил правильного формування конструкцій, що описують цю семантику.

 

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

 

Конструкції моделювання та нотація

 

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

 

Моделювання структур

 

Структура системи ідентифікує модельований сутності та взаємозв’язку між ними (наприклад, комунікаційні взаємозв’язку, відносини вкладеності і т.п.). UML надає два фундаментальних взаємодоповнюючих типу діаграм для опису структури систем: діаграми класів і діаграми взаємодій (collaboration). Діаграми класів описують універсальні відносини між класами – ці відносини існують між екземплярами класів в будь-якому контексті. Діаграми взаємодій відображають відносини, які існують тільки в конкретному контексті – шаблон використання для конкретних цілей, який не успадковується власне класом. Отже, в діаграмах взаємодії розрізняється використання різних примірників одного і того ж класу. Це розрізнення відображається до концепції ролі. У підході до моделювання, описаному тут, присутній строгий акцент на використанні діаграм взаємодій UML виключно для представлення взаємозв’язків між архітектурними елементами. Зазвичай, цілісна специфікація структури складної системи реального часу виходить комбінацією діаграм класів і діаграм взаємодій.

 

Конкретно ми виділяємо три основні конструкції для моделювання структур:

 

 

 

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

 

Порт – Фізична частина реалізації капсули, яка є посередником у взаємодії капсули із зовнішнім світом – це об’єкт, який реалізує специфічний інтерфейс. Кожен порт капсули грає конкретну роль у взаємодії капсули з іншими об’єктами. Для відображення складної семантики цих взаємодій порти асоційовані з протоколом, який визначає коректний потік інформації (сигналів) між сполученими портами капсул. У цьому сенсі протокол відображає контрактні угоди, які існують між капсулами. Більш детально протоколи обговорюються в розділі, присвяченому моделювання поведінки (2.2.1). Обмеживши взаємодії між капсулами так, щоб вони виконувалися тільки за допомогою портів, стає можливим повністю відокремити їх (капсул) внутрішню реалізацію від будь-якого безпосереднього знання про оточення. Це забезпечує високу повторне використання капсул.

 

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

 

Функціональність простий капсули безпосередньо реалізується кінцевим автоматом, асоційованим з капсулою. Більш складні капсули об’єднують кінцевий автомат з внутрішньою мережею взаємодіючих капсул нижнього рівня (sub-capsules), з’єднаних коннекторами. Ці капсули нижнього рівня є повноправними капсулами і в свою чергу можуть бути піддані декомпозиції на капсули нижнього рівня. Така декомпозиція може тривати до необхідної глибини, дозволяючи моделювати виключно складні структури на основі тільки цього базового набору конструкцій для моделювання структур. Кінцевий автомат (Який необов’язковий для складових капсул), капсули нижнього рівня та їх мережа зв’язків представляють частині реалізації капсули і приховані від зовнішнього спостерігача.

 

Порти

 

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

 

Хоча порти є граничними об’єктами, які ведуть себе як інтерфейси, вони не повністю відповідають інтерфейсів в UML. Інтерфейси в UML – це виключно поведінкові абстракції, що не мають реалізують їх структур. Порт, з іншого боку, включає і структуру і поведінку. Це композитна частина капсули, а не просто обмеження на її поведінку. Порт реалізує архітектурний шаблон, який ми можемо назвати “Явний інтерфейс” (manifest interface).

 

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

 

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

 

Релейні порти

 

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

 

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

 

Кінцеві порти

 

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

 

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

 

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

 

Моделювання в UML

 

У термінах UML, порти моделюються за допомогою стереотипу “port”, стереотипу концепції Class в UML. Як зазначалося раніше, тип порту визначається протокольної роллю, виконуваної цим портом. Так як протокольні ролі – це абстрактні класи, реальні класи пов’язані з цього примірника, є реалізаціями протокольної ролі, пов’язаної з портом. В UML відношення між портом і протокольної роллю відображається як реалізує ставлення. Як нотації для цього використовується пунктирна лінія з заповненим трикутником для вістря стрілки на спеціфіціруемий кінці. Це форма генералізації, де вихідний елемент – Порт – успадковує тільки специфікацію поведінки цільової протокольної ролі, але не її структуру.

 

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

На рис. 1 показаний приклад порту, пойменованого b, та належить класу капсул CapsuleClassA. Цей порт реалізує роль master визначену в класі протоколів ProtocolA. Зверніть увагу, що реальний клас портів PortClassX, є класом реалізації, який може варіюватися від реалізації до реалізації, що зазвичай не представляє інтересу для розробника до початку стадії реалізації. Замість того, інформація, яка становить інтерес, – це протокольна роль, виконувана портом. З цієї причини і для зручності нотації, нотація, показана на рис. 1, зазвичай не використовується і замінюється більш компактною формою, описаної в наступних розділах.

 

Нотація

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

Всі зовнішні порти (релейні порти і публічні кінцеві порти) мають публічну видимість, тоді як внутрішні порти мають захищену видимість (наприклад, порт b2 на рис. 2). Протокольна роль (тип) порту зазвичай ідентифікується іменем шляху, тому що ім’я протокольної ролі унікально лише в рамках області визначення даного протоколу. Наприклад, на рис. 2 порт b грає роль master, визначену в класі протоколів з ім’ям ProtocolA. Для дуже поширеного випадку бінарних протоколів використовується більш проста нотація: суффіксний символ тильда (“~”) використовується для ідентифікації підлеглої (за визначеннями для цих термінів зверніться до розділу 2.2.1) протокольної ролі (наприклад, порт b2) в той час як ім’я базової ролі використовується неявно без спеціальної нотації (порт b1). Порти з множинністю відмінною від 1, включають коефіцієнт мультиплікації в квадратних дужках. Наприклад, порт b1 [3] має коефіцієнт мультиплікації рівно 3, тоді як порт позначений b5 [0 .. 2] має змінне число примірників, не перевищує 2.

На рис. 2 показано, як порти відображаються на діаграмі класів. Вони також відображаються на діаграмах взаємодії, які описують внутрішню декомпозицію капсули. На цих діаграмах об’єкти представляються відповідними ролями класифікаторів – капсули нижнього рівня за допомогою ролей капсул і порти за допомогою ролей портів. Для зменшення графічної перевантаженості, ролі портів в основному показуються у вигляді піктограм, маленькими чорними або білими квадратами. Публічні порти представляються піктограмою ролі порту, яка перетинається кордоном ролі відповідної капсули, як показано на рис. 3. Ця скорочена нотація дозволяє їм бути пов’язаними як зсередини, таки зовні капсули, без непотрібного перетину ліній і також ідентифікує їх як граничні об’єкти.

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

Для бінарних протоколів використовуються піктограми додаткового стереотипу: порт, який грає підлеглу роль, зображується білим (замість чорного) квадратом. У цьому випадку ім’я протоколу і суфікс тильда достатні для ідентифікації протокольної ролі як підлеглої, а ім’я протокольної ролі надмірно і може бути опущено. Подібно до цього, використання імені протокольної ролі самого по собі для чорного квадрата вказує на базову роль в протоколі. Наприклад, якщо роль “master” в протоколі ProtQ (Мал. 3) оголошена як базова, тоді діаграми на Рис. 3 та Рис. 4 еквівалентні. Ця угода полегшує можливість бачити, що додаткові ролі протоколу пов’язані.

Порти з коефіцієнтом мультиплікації більше одного можуть бути також зображені графічно з використанням стандартної нотації UML для множинних об’єктів, як це показано на рис. 5. Це не обов’язково (Мітки із зазначенням множинності достатньо), але це підкреслює можливість існування безлічі екземплярів порту.

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

У цьому випадку піктограма кінцевого порту зображується з’єднаної з невеликим прямокутником із закругленими кутами, що служить пиктографическим відображенням кінцевого автомата капсули. Наприклад, порт x1 публічний (підлеглий) кінцевий порт, а порт x3 захищений кінцевий порт. (Зауважте, що хоча на діаграмі взаємодії присутні кілька піктограм кінцевих автоматів, у капсули не може бути більше одного кінцевого автомата. Кінцеві порти можуть бути з’єднані з єдиною піктограмою кінцевого автомата, але часто в цьому випадку графічні зв’язку будуть сплутані, так що піктограма кінцевого автомата може дублюватися.) Релейні порти ідентифікуються фактом свого зв’язку з портом капсули нижнього рівня (наприклад, порт x2). Порти, не приєднані ні до піктограмі кінцевого автомата, ні до порту капсули нижнього рівня, є недетерміновані. Це значить, їх класифікація в якості кінцевих або релейних портів відкладена і зазвичай дозволяється на рівні підкласів, або вони можуть просто залишатися не приєднаними.

 

Коннектори

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

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

 

Моделювання в UML

В UML коннектори моделюються за допомогою асоціацій і оголошуються через роль асоціації на діаграмі взаємодії капсули. Ця асоціація існує між двома або більше портами відповідних класів капсул. (Для розвинених додатків, в яких коннектори мають фізичні властивості, використовується клас асоціацій, так як в дійсності, коннектор – це об’єкт із станом і індивідуальністю. Як і у випадку порту, реальний клас, який використовується для реалізації коннектора – це питання стадії реалізації.) Відношення з підтримуваним протоколом виражається неявно через приєднані порти. Тому для подання конекторів не потрібно розширення UML.

 

Нотація

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

Коннектори для тримісних протоколів і протоколів більш високих порядків представляються з використанням стандартної нотації UML для n-арних асоціацій – у вигляді ромба. Так як протоколи високих порядків не були реалізовані в ROOM, то деякий досвід роботи з ними все ще необхідний.

 

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*