Аналіз і трансформації виконуваних UML-моделей, CASE-засоби (моделювання), Програмування, статті

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

Введення

При створенні складних інженерних систем прийнято використовувати прийоми моделювання. Складність більшості створюваних сьогодні програмних систем не поступається складності багатьох інженерних споруд, тому моделювання програмних систем є досить актуальним завданням. Більш того, в таких концепціях, як MDA (Model Driven Architecture – архітектура на основі моделей) і MDD (Model Driven Development – Розробка на базі моделей), моделям відводиться центральна роль в процесі створення програмного продукту. Основною ідеєю цих концепцій є представлення процесу створення програмного продукту у вигляді ланцюжка трансформацій його вихідної моделі в готову програмну систему.

Майже у всіх інструментальних засобах, що втілюють ідеї MDD, в якості мови моделювання використовується мова UML (Unified Modeling Language – уніфікована мова моделювання), цілком або будь його частини.

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

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

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

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


  1. пошук погано спроектованих ділянок коду (моделі), для яких потрібне проведення рефакторинга;
  2. визначення рефакторинга (синтез з підтримуваних базових рефакторингов), який слід застосувати;
  3. перевірка чи доказ незмінності поведінки системи після виконання перетворень;
  4. реалізація застосування рефакторинга і, зокрема, розробка користувацького інтерфейсу і діалогів, що підтримують процес застосування рефакторинга;
  5. збереження цілісності моделі, тобто поширення проведених змін на інші частини моделі (діаграми, тести);
  6. оцінка ефекту, отриманого в результаті застосування рефакторинга.

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

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

Аналіз виконуваних UML-моделей


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

Кінцеві автомати UML можуть описувати поведінку наступних елементів виконуваних моделей:


Залежно від свого походження, всі досліджені моделі UML можна розділити на два класи:


  1. моделі, спочатку спроектовані на мові UML (наприклад, в таких програмних системах, як Rational Rose, Telelogic Tau G2, I-Logix Rhapsody, Borland Together);
  2. моделі, спочатку спроектовані на мові SDL (наприклад, в таких програмних системах, як Telelogic SDL Suite, Verilog ObjectGeode) і трансформовані в UML вручну або за допомогою спеціальних утиліт (Наприклад, Telelogic Tau G2 – Import SDL).

Виконувані UML-моделі другого класу в основному описують різного роду комунікаційні системи (тобто такі класи систем, для моделювання яких призначений мова SDL). Виконувані моделі першого класу у зв’язку з універсальністю мови UML описують набагато ширший спектр систем.

Характеристика кінцевих автоматів

Загальна статистика по дослідженим моделям представлена ​​в таблиці 1. Перераховані моделі були запозичені з реальних проектів комерційних компаній. Для збору та аналізу необхідної інформації був розроблений додатковий модуль до промислової середовищі UML-моделювання Telelogic Tau G2.


Таблиця 1. Загальна статистика по дослідженим UML-моделям.

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

1.jpg

Рис. 1. Кількість станів в кінцевих автоматах


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

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

2.jpg

Рис. 2. Кількість станів в кінцевих автоматах, що реалізують класи


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

Автомати, специфікують ієрархічні стану, склали трохи менше 2% від усіх виявлених автоматів і були знайдені лише в декількох з розглянутих моделей, що дозволяє зробити висновок про їх досить рідкісному використанні, незважаючи на їх виразну потужність. Причиною тому може служити той факт, що складові стану не були частиною мови SDL до його версії SDL-2000. Більшість великих промислових моделей SDL, згодом трансформованих в UML, було розроблено до того, як з’явився новий стандарт SDL-2000.

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

3.jpg

Рис. 3. Кількість переходів із стану


Таким чином, в середньому автомат, який реалізує клас, містить 3 стану та близько 12 переходів і 4 діаграм, при цьому близько 90% автоматів містять не більше 6 станів, і, отже, їх розуміння не повинно викликати серйозних труднощів у розробників. Однак внутрішня логіка роботи системи, як правило, реалізується залишилися 10%, серед яких зустрічаються автомати, що налічують до 30 станів. Цілком очевидно, що розумові витрати на розуміння такого автомата досить великі; відповідно, значно ускладнюється процес його модифікації, пошуку помилок та ін. Тому кошти, які зменшують складність автоматів, зберігаючи їх зовнішні властивості, дійсно затребувані на практиці.

4.jpg

Рис. 4. Розподіл кількості символів на діаграмах


Аналіз діаграм станів показав (див. рис. 4), що в середньому автомат, який реалізує клас, включає в себе 3-4 діаграми, кожна з яких містить близько 9 символів і 9 ліній, що не має в значній ступеня перешкоджати розумінню. У той же час для 10% автоматів, що описують внутрішню логіку роботи системи і містять більше 6 станів і переходів, кількість діаграм, на яких описаний автомат, зростає до п’ятдесяти, що дуже сильно ускладнює розуміння цілісної картини роботи системи.

Використовувані конструкції

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

За рахунок використання операторів розгалуження в діях, які виконуються при спрацьовуванні переходу в автоматі, один і той же перехід може в різних умовах перевести автомат в різні стани. Максимально можливе використання розгалуження означало б наявність в кожному стані не більше ніж одного переходу для будь-якого сигналу. У цьому випадку вибір стану, в який перейде автомат, відбувався б у процесі інтерпретації дій, приписаних переходу. Результати статистичного дослідження наведені на рис. 5.

5.jpg

Рис. 5. Гіллястість переходів


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

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

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

6.jpg

Рис. 6. Розподіл переходів на мітки


Розподіл кількості команд переходу на мітки дуже схоже на розподіл кількості гілок. В обох випадках найбільш прості варіанти (одна гілка і відсутність переходів на мітки) забезпечують близько 60% випадків, а наступні за складністю варіанти (дві гілки і одна команда переходу на мітку) – близько 20%, в той час як інші варіанти мають по 3-4%. Проте в автоматах зустрічалися і переходи, перевантажені командами переходу на мітки. Для деяких переходів в автоматі максимальна кількість команд переходу на мітку перевищило 20.

Щоб уникнути дублювання переходів для різних станів, можна використовувати кілька прийомів. В UML в символі стану можна перерахувати кілька імен станів, і тоді всі переходи, що виходять з цього символу, будуть ставитися до всіх перерахованих станів. Крім того, якщо в якості імені стану вказати символ “*”, то переходи, що виходять з цього символу, будуть ставитися до всіх станів автомата. Також є можливість виключити певні стани з безлічі станів, що описується символом “*”. Вміле використання цих можливостей дозволяє значно спростити опис переходів, застосовних більш ніж до одного стану. Результати статистичного дослідження показали, що символ * присутній в 12% символів стану, що свідчить про досить активному використанні цієї підстановки і необхідність більш детального вивчення варіантів її використання та можливих трансформацій з виділенням або заміною символу “*”.

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

Типові способи побудови кінцевих автоматів

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

Поліпшення структури кінцевих автоматів UML


Трансформація “виділення методу” для кінцевих автоматів UML

Ідея трансформації “Extract method” полягає в створенні нового методу і перенесення частини вихідного автомата в доданий метод. Дана трансформація багато в чому аналогічна відомому рефакторингу “Extract Method” для об’єктно-орієнтованих мов програмування, описаного в каталозі Фаулера [1]. Суть традиційної трансформації полягає у виділенні ділянки коду і переміщенні його в інший метод. Це дозволяє зробити код вихідного методу більш зрозумілим і підвищує ймовірність повторного використання виділеного методу.

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

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

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

Ідея, що лежить в основі традиційного рефакторинга “Extract method”, може бути застосована до кінцевих автоматів декількома способами.


Виділення в метод частини кінцевого автомата

Розглянемо визначення частини кінцевого автомата, представлене на рис. 7.

7.jpg

Ріc. 7. Частина автомата, що допускає виділення методу


Вибравши частину переходу разом з наступним станом, можна виділити метод, до якої увійде частина станів кінцевого автомата, починаючи з стану Y. Будемо називати таку трансформацію Extract Sub State Machine.

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

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

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

Введемо декілька позначень. Позначимо через RS (x, y) безліч, що містить всі стани автомата, в які можна потрапити зі стану y, не проходячи при цьому через стан x, включаючи y і виключаючи x. Спеціальний символ stop додається в безліч RS (x, y), якщо зі стану y за деякий кількість переходів можна дійти до дії, завершального роботу автомата (stop). Позначимо безліч всіх переходів деякого кінцевого автомата A через All_T (A), а перехід зі стану а в стан b по сигналу z – через t (a, z-> b).

Визначення 1. Безліч станів S замкнуто на безлічі переходів T, Якщо не існує переходу

t(x”,e->s)

Рис. 10. Результати застосування другого варіанту трансформації

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


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

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

Ваш отзыв

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

*

*