Технологія створення програмних продуктів

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Вступ

програма автоматний моделювання графічний

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

При створенні програмних систем звичайно виділяють наступні фази:

1. Постановка завдання - збір вимог і створення прототипу програми.

2. Проектування - розробка проектної документації, що відбиває структурні і поведінкові особливості створюваної системи.

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

4. Тестування - налагодження коду та перевірка відповідності реалізації поставленої задачі.

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

1. Реалізація системи не відповідає проектній документації зважаючи неформальній зв'язку фаз проектування та реалізації.

2. Перевірка відповідності реалізації проектної документації (верифікація) може бути виконана тільки вручну.

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

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

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

1. Технологія проектування та розробка об'єктно-орієнтованих програм

Останнім часом для підвищення рівня абстракції для розробників розвивається напрям програмної інженерії, який називається «Інженерія, керована моделями» (Model-Driven Engineering, MDE).

Цей напрямок включає в себе «Розробку, керовану моделями» (Model-Driven Development, MDD), яке може бути названо також «Проектування на базі моделей» (Model-Driven Design). Варіантом MDD є «Архітектура, керована моделями» (Model-Driven Architecture, MDA), запропонована і розвивається консорціумом Object Management Group (OMG).

При застосуванні MDA моделі програмних систем представляються за допомогою «Уніфікованого мови моделювання» (уніфікована мова моделювання, UML).

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

Моделювання динамічних аспектів програм на мові UML утруднено у зв'язку з відсутністю в стандарті на цю мову формального і однозначного опису правил інтерпретації (операційної семантики) поведінкових діаграм.

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

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

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

Зазначимо дві тенденції, що активно розвиваються в даний час:

1. Виконуваний UML. На поточний момент UML застосовується, основному, як мова специфікації моделей систем. Існуючі UML-засоби дозволяють будувати різні діаграми і автоматично створювати по діаграмі класів «Скелет» коду на цільовому мовою програмування (наприклад, мови Java і C #). Деякі з цих коштів також надають можливість автоматично генерувати код поведінки програми по діаграмах станів. Проте в даний час зазначена функціональність існує лише в «зародковому стані», так як відомі інструменти не дозволяють повною мірою ефективно пов'язувати генерований код з моделлю поведінки, яку можна описувати за допомогою чотирьох типів діаграм (cтанів, діяльностей, кооперації або послідовностей). Відсутність однозначної операційної семантики при традиційному написанні програм призводить до розбіжності опису поведінки в моделі і в програмі, а також до довільної інтерпретації поведінкових діаграм програмістами. Більш того, опис поведінки в моделі часто носить неформальний характер. Можлива і протилежна ситуація, коли будується формальна модель, а її реалізація виконується евристично. Часто формальна модель поведінки будується архітектором, а програміст при написанні програми її не використовує, а пише вихідний текст програми, як вважає за потрібне. Поява операційної семантики зафіксує однозначність розуміння діаграм і дозволить створити виконуваний UML, для якого код (у звичному розумінні цього слова) може не генеруватися. Це можливо за рахунок безпосередньої інтерпретації моделі.

2. Процес розробки ПЗ повинен бути активним. Існуючі засоби розробки вимагають тривалого часу для їх вивчення. Тому вони повинні передбачати дії розробника і пропонувати варіанти вирішення виниклих проблем в залежності від поточного контексту. Зазначимо, що подібний підхід реалізований в багатьох сучасних середовищах розробки (наприклад, Borland JBuilder, Eclipse, IntelliJ IDEA) для текстових мов програмування, але не для мови UML.

1.1 Реактивні системи

Широким класом програмних систем є реактивні системи - системи, що виконують певні дії у відповідь на зовнішні події.У роботах Д. Харела показано, що для моделювання таких систем добре підходить розширення графів переходів кінцевих автоматів, назване «діаграми станів» (Statechart), які дозволяють зручно і компактно описати реакцію системи на події.

Для побудови діаграм станів і генерації коду за ним створені інструментальні засоби.

У цій роботі, зокрема, згадані такі інструменти як I-Logix Statemate (http://ilogix.com/sublevel.aspx? id=74), XJTek AnyState (http://www.xitek.com/anystates/), Statesoft ViewControl (http://www. Statesoftie/products.html), SCOPE (http://www.itu.dk/~wasowski/proiects/область/), IAR Systems VisualState (http://www.iar.COM/р1014/р1014_en g.php), компілятора State Machine (http://smc.sourceforge.net/).

Існують також і інші інструменти для генерації коду за цими діаграмами.

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

1.2 Класифікація автоматних підходів

Зазначені в попередньому розділі інструменти для автоматно-орієнтованої розробки програм, можуть бути класифіковані за такими ознаками:

1. цільової клас автоматних моделей:

· про імітаційне моделювання для дослідження властивостей фізичних об'єктів; про програми для вбудованих систем (логічні контролери та мікроконтролери);

· про програми для мобільних пристроїв (наприклад, для стільникових телефонів); про прикладні програми (компілятори, ігри, системи автоматизації бізнес-процесів);

2. спосіб завдання та реалізація автомата:

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

· таблиця переходів записується в структурований файл (наприклад, у форматі XML), який обробляється інтерпретатором;

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

3. спосіб отримання коду з графічно представлених графів переходів:

· вручну;

· автоматично;

4. спосіб перевірки коректності (верифікації) графа переходів:

· вручну;

· автоматично;

5. спосіб документування поведінкової моделі системи:

· вручну;

· автоматично;

6. спосіб налагодження автоматною програми:

· в термінах цільової мови програмування; в термінах автоматів;

1.3 Гібридні автомати

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

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

1.4 Автоматною програмування вбудованих систем

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

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

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

Деякі фірми створили інструментальні засоби програмування логічних контролерів на основі графів переходів. Наприклад, фірма General Electrics створила засіб State Logic.

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

Для опису поведінки реактивних систем Д. Харель в роботі, як було зазначено вище, запропоновано використовувати діаграми Statechart, що є розширенням графа переходів. Ці діаграми були використані в якості мови специфікації поведінки реактивних систем в інструментальному засобі Statemate компанії I-Logix. Ця компанія також використовує зазначені діаграми в складі більш сучасного пакету для розробки вбудованих систем на базі моделей Rhapsody. Компанія I-Logix увійшла до складу компанії Telelogic, яка, в свою чергу, входить до складу корпорації IBM.

Для моделювання реактивних систем фірмою Mathworks створено засіб Stateflow, яке тісно інтегровано з такими відомими пакетами, як MATLAB і Simulink.

Крім підходу для побудови реактивних систем, запропонованого Д. Харель, для їх створення розроблений і інший підхід, заснований на використанні систем взаємопов'язаних графів переходів, що є різновидом SWITCH-технології.

Діаграми переходів почали застосовуватися також і для програмування мікроконтролерів. Так, наприклад, фірмою IAR Systems створено засіб VisualState.

В роботі описана методологія, названа співробітництва Deisgn. Вона орієнтована на спільне проектування апаратної та програмної частин вбудовуваної системи з використанням кінцевих автоматів. Для верифікації побудованої системи використовується бібліотека ВІС.

1.5 Використання автоматного підходу при реалізації прикладних програм

Історично першою областю програмування, в якій використовувалися автомати, були компілятори.

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

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

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

При переході до об'єктно-орієнтованого програмування досліджувалися різні підходи до обміну автоматів та об'єктів. Так, зокрема, одним з підходів до реалізації автоматів, є створення бібліотек, що реалізують набір базових класів. Наслідуючи від цих класів, програміст пише програму в «автоматному» стилі. До таких бібліотекам можна віднести, наприклад, Werken Blissed і підвищення: FSM, перша з яких призначена для створення програм мовою Java, а друга - на мові С++. Особливість застосування таких бібліотек полягає в тому, що опис структури автомата виконується на цільовому мовою програмування.

Більш досконалі бібліотеки надають користувачеві можливість описувати автомат в текстовому файлі, який потім перетвориться в код на цільовому мовою програмування. До таких бібліотеками відносяться, наприклад, Нінні FSM генератора, машини кінцевих станів створення програмного забезпечення, FSM, компілятора State Machine, CHSM.

Формати текстового опису варіюються: від таблиці переходів автомата Мура до XML-опису змішаного автомата.

Компілятора State Machine по текстового опису графа переходів генерує код на мовах Java, C++, C #, VB. Net, який реалізує паттерн держави. Перевірку коректності заданого автомата дана бібліотека не виробляє. Бібліотека має можливість генерувати графічне представлення автомата за заданим опису, але дану функціональність не можна вважати обгрунтованою, тому що при моделюванні поведінки системи графічне представлення автомата повинно є первинним.

При використанні бібліотеки, на першому етапі текстовий опис автомата перетворюється на бінарне подання, а потім воно передається інтерпретатору.

При створенні додатків із графічним інтерфейсом користувача останнім часом все ширше використовується патерн Model-View-Controller. Його основна ідея полягає в поділі програми на модель даних, контролер і подання даних. Модель даних повідомляє контролер про зміну даних. При цьому контролер оновлює подання даних. У цьому випадку виявляється зручним реалізовувати контролер за допомогою кінцевого автомата, тому що контролер виконує оновлення представлення даних на основі їх поточного стану - аналізуючи, наприклад, яке вікно в даний момент відкрито. На сайті наведено список програмних продуктів, що реалізують описаний підхід. Серед них виділимо ViewControl компанії Statesoft. Цей продукт орієнтований на розробку Інтернет-додатків на основі платформи J2EE і дозволяє створювати графи переходів, використовуючи UML-нотацію діаграми станів і власний графічний редактор.

На закінчення розділу відзначимо, що на початку 90-х років в Мічиганському університеті Ю. Гуревичем розроблена теорія машин абстрактних станів (ASM - Abstract State Machine). Надалі під його керівництвом в компанії Microsoft на основі цієї теорії була розроблена мова виконуваних специфікацій AsmL (Abstract State Machine Language), який в даний час використовується тільки для верифікації.

2. Програмні продукти для графічного моделювання кінцевих автоматів

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

Бібліотека кінцевих станів ядра Творця надає користувачеві графічний інтерфейс для редагування таблиць переходів кінцевих автоматів.

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

На сайті наведено список компаній і їх продуктів, призначених для створення моделей на мові UML. Крім продуктів, зазначених на цьому сайті, слід відзначити також UML-редактор Real.

UML-редактори надають кошти для моделювання, як статичної структури програми, так і її поведінки. Для опису поведінки програм можуть використовуватися різні діаграми, у тому числі і зазначені вище діаграми станів.

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

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

Тут також слід зазначити, що можливість запуску поведінкових UML-діаграм за допомогою генерації коду для них або за допомогою їх інтерпретації призвело до появи нового напряму, названого Виконуваний UML. Серед програмних продуктів, що реалізують ідеї цього напрямку зазначимо інструмент ядра UML Suite компанії прискореної технології та інструмент iUML компанії Кеннеді Картер.

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

У зазначеній вище специфікації обмеження описуються за допомогою мови об'єктних обмежень (Object Constraint Language). Передбачається, що UML-редактори повинні перевіряти правильність побудови діаграм з урахуванням цих обмежень. Існує ряд програмних продуктів, орієнтованих на перевірку обмежень OCL. Проте в роботі показано, що деякі з обмежень, описаних у специфікації на мову, суперечать один одному. У цій роботі також показано на прикладі популярних UML-редакторів, що дуже мало обмежень реально перевіряється. Зазначимо, що специфікація UML допускає присутність в діаграмах станів суперечливих переходів і неповноту безлічі вихідних зі стану переходів.

Ще одним недоліком UML є відсутність повного формального опису операційної семантики для діаграм станів, правил їх виконання. Усуненню цього недоліку присвячені такі роботи як і стандарт Рекомендація МСЕ-Т Z.109.

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

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

Інструментальним засобом для підтримки SWITCH-технології є програма Visio2Switch, яка дозволяє перетворювати графи переходів, створені в Microsoft Visio, в код мовою C.

Далі описані приклади програмних продуктів, що дозволяють створювати графи переходів автоматів.

2.1 Машини кінцевих станів редактор

Редактор машини кінцевих станів редактор використовує ряд ідей з SWITCH-технології та реалізує редактор для графа переходів кінцевого автомата. Граф переходів може бути перетворений в код на мовах C++ або Python.

Перерахуємо недоліки даного продукту:

* використання власної нотації для представлення графа переходів;

* використання тільки компілятивного підходу;

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

* відсутність вкладених автоматів;

* відсутність автоматичної перевірки коректності графа переходів.

2.2 Середовище розробки Флора

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

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

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

2.3 XJTek AnyState

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

До особливостей даного продукту можна віднести:

* використання UML-нотації діаграми станів;

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

* перевірка виконання деяких обмежень. Інформація про знайдені помилки записується безпосередньо в код;

Недоліком є незручний графічний редактор.

2.4 IAR Systems VisualState

Інструмент IAR Systems VisualState призначений для створення додатків для мікроконтролерів. Цей продукт реалізує:

* редактор графа переходів автомата у вигляді UML-діаграми станів;

* перевірку правильності побудови графа переходів за допомогою власного алгоритму;

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

* генерацію програмного коду;

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

Недолік продукту - відсутність методології проектування вбудованих додатків.

2.5 Telelogic TAU2

Інструментальний засіб Telelogic TAU2 є редактором діаграм, що підтримує стандарт UML версії 2. Засіб дозволяє перевіряти коректність побудованої моделі і запускати її. При запуску існує можливість використовувати вбудований відладчик.

При створенні діаграм станів існує можливість описувати дії, що виконуються на переходах і в станах з допомогою як внутрішнього С-подібного мови, так і на цільових мовах програмування, в які входять C, C++ і Java.

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

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

До недоліків слід віднести обмежену підтримку мови Java, відсутність можливості вилученого налагодження моделі і незручний графічний редактор. Перевірка коректності моделі виконується не під час редагування, а при запуску моделі, що також є недоліком.

2.6 Borland Together архітектор

Пакет Borland Together Архітектор є одним з найбільш популярних і зручних інструментів для створення UML-моделей. У ньому існує можливість генерації коду по діаграмі класів для мов Java, C++ і С# і зворотна генерація - створення діаграми класів за кодом. Обидві ці можливості разом називаються туди і назад, і в зазначеному інструменті вони працюють синхронно - при зміні коду відразу змінюється модель, а при зміні моделі - код.

Також даний пакет дозволяє створювати діаграми послідовності за кодом методу класу і, навпаки, створювати код методу класу по діаграмі послідовності.

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

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

3. Виконуваний UML та SWITCH-технологія

3.1 Виконуваний UML

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

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

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

Серед промислових розробок ідея виконуваного UML реалізована в проекті Telelogic TAU2. Однак оскільки цей проект є закритим, то дуже важко виконати аналіз рішень, прийнятих при його створенні. Також закритими є і інструментальні засоби IBM Rational Rose і Borland Together.

3.2 SWITCH-технологія

В роботі був запропонований метод проектування програм з явним виділенням станів, названий «SWITCH-технологія» (http://ru.wikipedia.org/wiki/Switch-технологія) або «автоматної програмування» (http://ru.wikipedia.org/wiki/Автоматное програмування). Надалі цей метод був розвинений для подієвих систем, а потім і для об'єктно-орієнтованих.

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

SWITCH-технологія визначає для кожного автомата два типи діаграм (схема зв'язків та граф переходів) та їх операційну семантику. При наявності декількох автоматів запропоновано також будувати схему їх взаємодії. Для кожного типу діаграм запропонована відповідна нотація (http://is.ifmo.ru/? i0=science&i=minvuz2).

Висновок

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

2. Зазначений недолік усунуто в SWITCH-технології, яка вводить в процес проектування діаграму зв'язків автомата, для опису його інтерфейсу - вхідних і вихідних впливів. В UML-нотації таку діаграму зручно представляти у вигляді діаграми класів.

3. На підставі викладеного та виконаного огляду можна сформулювати завдання, вирішення яких актуально в даний час:

* розробка методології моделювання поведінки програмних систем на основі спільного застосування SWITCH-технології та мови UML;

* розробка інструментального кошти для підтримки SWITCH-технології з використанням нотації UML;

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

* розробка підходів до створення компільованих і інтерпретуються виконуваних моделей поведінки;

* реалізація методів верифікації створюваних моделей;

* розробка засобів налагодження моделей в термінах автоматів.

Список літератури

1. Соммервмлл І. Інженерія програмного забезпечення. М.Вільямс, 2002.

2. Грехем І. Об'єктно-орієнтовані методи. Принципи та практика. М.: Вільямс, 2004. 3. Буч Г. Об'єктно-орієнтований аналіз та проектування з прикладами додатків на С++. СПб.: Невський діалект, 2001.

4. Ларман К. Застосування UML і шаблонів проектування. М.: Вільямс, 2001.

5. Коуд П., Норт Д., Мейфшлд М Об'єктні моделі. Стратегії, шаблони та програми. М.: Лорі, 1999.

6. Harel D., Politi M. Modelling Reactive Systems with Statecharts. NY: McGraw-Hill, 1998.

7. Harel D. Statecharts: A Visual Formalizm for Complex Systems Science of Computer Programming. 1987. №8, pp.231-274.

8. Harel D. et al. STATEMATE: A Working Environment for the Development of Complex Reactive Systems IEEE Transactions on Software Engineering. 1990. №4, pp. 234 - 252.

9. Кузнєцов С. Обіцянки і прорахунки UML 2.0 Відкриті системи. 2006. №2, с. 75-79.

10. 1st European Conference on Model-Driven Software Engineering. Germany. 2003.

11. International Workshop «e-Business and Model Based in System Design». IBM EE/A. SPb ETU, 2004.

12. OMG Model Driven Architecture.

13. Frankel D. Model Driven Architecture: Applying MDA to Enterprise Computing. NJ: Wesley, 2003.

14. Буч Г., Рамбо Г., Якобсон І. UML. Керівництво користувача. М.: ДМК, 2000.

Размещено на Allbest.ru