1. Дана публікація журналу Journal of Object Technology ( www.jot.fm ) Відкриває серію статей, присвячених...
2. Різні прикладні області
3. Моделі потоків і семантика
4. Вузли і ребра діяльності
5. дії
6. діяльність
7. Поведінка в UML 2
8. резюме
9. література

Дана публікація журналу Journal of Object Technology ( www.jot.fm ) Відкриває серію статей, присвячених моделі діяльності (activity model) у другій версії уніфікованої мови моделювання Unified Modeling Language, а також того, як вона поєднується з моделлю дій (action model). Статтю можна розглядати як доповнення до стандарту; в ній представлені відомості загального характеру, логічні обґрунтування, приклади, а також концепції, збудовані в логічному порядку. Мова також йде про причини, які спонукають переходити на нові моделі, про їх архітектурі, про основні аспекти понять діяльності та дій в UML 2 і про загальну концепцію поведінки (behavior) в цій мові [1].

До історії питання

Останнім часом фахівці, зайняті розвитком UML, зосереджують свою увагу, перш за все, на процедурах і процесах. Так, у версії UML 1.5 реалізована обумовлена потоком управління і потоком даних модель параметрезованих процедур, яка доповнює існуючі модель станів (state model) і модель взаємодій (interaction model) [2]. В UML з'явилася підтримка процедур, які можна використовувати і в якості методів об'єктів, і незалежно від об'єктів, як це буває, наприклад, при моделюванні бібліотек функцій популярних мов програмування. Крім того, ця модель полегшує роботу з UML для тих творців моделей, які працюють з об'єктно-орієнтованими технологіями лише від випадку до випадку - скажімо, для інженерів-системщиков або для розробників моделей всередині підприємств, - і дають їм можливість крок за кроком вивчати згадані технології [3]. Така здатність гнучко поєднувати об'єктно-орієнтовані технології з функціональним підходом істотно розширює сферу потенційних додатків UML і забезпечує їх інтеграцію.

Крім того, мова UML 1.5 успадкував від попередніх версій кінцеві автомати в нотаціонной формі діаграм потоків (flow diagram), іменовані тепер діаграмами діяльності (activity diagram). На жаль, семантика, що лежить в основі кінцевого автомата, обмежує виразність і заплутує користувачів. Особливо це відноситься до користувачів, які не мають досвіду роботи в об'єктно-орієнтованому середовищі, у яких виникає відчуття, що моделі діяльності UML 1.x не сприяють вирішенню їх задач. Вселяє побоювання і те, що в UML 1.5 є декілька моделей для потоків управління і даних.

З урахуванням цього досвіду, в UML 2.0 модель діяльності була перевизначена з тим, щоб наділити її роллю інтуїтивного моделювання потоків і інтегрувати її з моделлю дій UML 1.5. У цій новій моделі діяльності підтримуються потоки управління і даних процедур UML 1.5, а також деякі більш загальні можливості, такі як цикли і черги. Тим самим, діаграми діяльності UML 2 забезпечують моделювання потоків у великому числі прикладних областей, від обчислювальних до фізичних. Це робить UML ідеальним засобом специфікації систем незалежно від того, як вони реалізуються - апаратно або програмно, і незалежно від того, де проводиться межа між системою і середовищем. Нарешті, оскільки комбінація діяльності і дій зберігає притаманну UML 1.x здатність реагувати на події, мову можна використовувати, наприклад, при роботі з вбудованими системами і системами на основі агентів.

Різні прикладні області

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

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

Засоби, загальні для різних додатків, такі, як абстрактна концепція дії, потік управління / даних і введення / виведення, знаходяться в корені (базова діяльність). Звідси відносини залежності розлучаються за двома напрямками: один напрямок використовується, в першу чергу, для моделювання програмного забезпечення (структурована діяльність), а друге - для моделювання загальних процесів (проміжна і завершена діяльність). У діаграмах структурованої діяльності вводяться правильно вкладені (well-nested) конструкції, призначені для моделювання умовних значень, змінних, блоків try / catch і т.д. У діаграмах проміжної і завершеною діяльності вводяться явний паралелізм, розділи, засновані на потоках форми для обробки виняткових ситуацій і ряд конструкцій для виборчого управління потоками. Ці гілки є ортогональними, так що їх конструкції можна комбінувати. Так, структурна діяльність може перемежовуватися з проміжною діяльністю, що дозволяє в один і той же час використовувати і явний паралелізм, і структуровані умовні вирази 1 .

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

Моделі потоків і семантика

Взагалі кажучи, моделі поведінки визначають, коли слід почати ті чи інші роботи, і які їхні вхідні дані [3]. Зокрема, моделі діяльності мови UML 2 будуються в Відповідно до традиційного підходу потоків управління і даних: вкладені роботи ініціюються, коли завершуються інші роботи, і стають доступними вхідні дані. При використанні діаграм потоків управління і даних візуалізація ефекту часу виконання зазвичай досягається шляхом проходження по лініях діаграми від більш ранніх кінцевих точок до пізніших, і зображення того, що управляють і дані рухаються уздовж цих ліній. Тому для таких користувачів найзручніше семантика потоку маркерів, інспірована мережами Петрі, де «маркер» - це всього лише загальний термін для керуючих впливів і значень даних.

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

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

Вузли і ребра діяльності

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

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

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

Вузли діяльності зв'язуються спрямованими ребрами двох типів.

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

На рис. 4 представлена ​​нотація опису ребер. Ребра потоків управління і ребра потоків об'єктів розрізняються по своєму застосуванню. Ребра управління пов'язують дії безпосередньо, тоді як ребра потоків об'єктів з'єднують входи і виходи дій.

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

дії

Моделі діяльності координують дії, деякі з них можуть викликати роботи, які визначаються користувачами, включаючи іншу діяльність. Всі дії є зумовленими. Наприклад, в UML 2 є дії по створенню об'єктів, встановлення значень атрибутів, зв'язування об'єктів і викликом робіт, визначених користувачами. Дії можуть мати входи і виходи, звані «контактами» (pins), які зв'язуються ребрами потоків об'єктів і показують, як значення, що надаються одними діями і одержувані іншими, проходять через дану діяльність. У простих випадках для початку виконання дії потрібна наявність всіх його вхідних даних.

На рис. 5 представлений приклад дії зі створення нового екземпляра класу ORDER ( «замовлення»), і іншого дії, що викликає визначається користувачем роботу щодо заповнення замовлення. Дія по створенню об'єкта створює незаповнений замовлення, який заповнюється за допомогою дії FILLORDER. Вузли дій представлені у вигляді прямокутників із закругленими кутами 4 , 5 . Маленькі прямокутники, приєднані до дій у верхній частині рис. 5, являють собою вхідні і вихідні контакти дій. Тип об'єкта, що приймається в якості вхідного або наданого в якості вихідного, вказується у вигляді тексту під прямокутником контакту. Нотацію, представлену в нижній частині рис. 5, можна використовувати в тих випадках, коли типи входу і виходу збігаються. Контакти - різновид вузлів об'єктів, тому вони, крім іншого, тимчасово зберігають значення даних в потоці.

Як вже говорилося, не обов'язково потрібно використовувати саме ту нотацію, яка показана на рис. 5. Програмісти, швидше за все, віддадуть перевагу текстуальную нотацію [4], скажімо, таку:

Як показано на рис. 6, для обох нотацій засобами UML 2 можна визначити єдину модель сховища, якщо моделювати змінні текстуального мови як потоковий вміст 6 . Кожен елемент репозитария є екземпляром метаклассом, визначеного в специфікації UML; ім'я метаклассом розташовується праворуч від двокрапки. Ім'я самого екземпляра репозитария поміщається зліва від двокрапки; в разі анонімного елемента це місце залишається порожнім. У моделі показано дію CREATEOBJECTACTION, вихідний контакт якого передає своє значення вхідного контакту дії CALLBEHAVIORACTION. Дія CREATEOBJECTACTION пов'язано з призначеним для користувача класом (ORDER), примірник якого воно створює, а дія CALLBEHAVIORACTION - з обумовленою користувачем роботою (FILLORDER), яку воно викликає.

Примітивні дії зі створення об'єктів, за викликом визначаються користувачами робіт і т.д. самі по собі не є роботами з точки зору техніки, але це не концептуальне розходження, а скоріше артефакт метамоделірованіе. Фундаментальним є розходження між специфікацією динамічного ефекту і його використанням: можливі різні використання однієї і тієї ж специфікації. Наприклад, одна і та ж робота FILLORDER може викликатися в багатьох діаграмах діяльності або викликатися багато разів в одній і тій же діаграмі діяльності, але в репозитарії кожен виклик буде представлений окремим екземпляром дії CALLBEHAVIORACTION, і всі ці екземпляри будуть посилатися на одну й ту ж роботу FILLORDER. Справа в тому, що кожне використання FILLORDER відбуватиметься в окремому потоці або в різних точках одного й того ж потоку, і при кожному використанні ця робота може передувати і завершуватися різними діями. Наприклад, на рис. 6 FILLORDER передує дією CREATEOBJECTACTION, а в іншому потоці ця дія може бути відсутнім 7 .

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

діяльність

Діяльність - це визначається користувачем поведінку. Подібно до всіх різновидів робіт в UML 2, діяльність можна ініціювати за допомогою викликають дій. Діяльність містить параметри для отримання вхідних даних від зухвалої дії і надання йому вихідних даних. Параметри є частиною повторно використовуваного визначення діяльності. Параметри не є контактами, оскільки контакти використовуються для з'єднання дій в потоці, а діяльність - це робота, яка викликається дією. Однак для того щоб забезпечити доступ до значень параметрів з дій всередині діяльності, параметри діяльності моделюються як особливий вид вузлів потоків об'єктів, що використовуються для тимчасового зберігання дійсних значень параметрів, які входять в діяльність і виходять з неї. На рис. 7 представлена ​​параметрезованих діяльність з об'єктним вузлом параметра, сполученим з контактами дій. Об'єктні вузли параметрів розміщуються на кордоні діаграми, і ребра потоку об'єктів з'єднують їх з контактами. Тип об'єкта, що утримується в об'єктному вузлі, зазвичай відображається в мітці цього вузла. В даному прикладі інформація, яка використовується для заповнення замовлення, надається як вхідний параметр і передається в дію за викликом роботи FILLORDER.

Вузли керування на качана и в кінці потоку на рис. 7 - це, відповідно, вихідний и завершальній Вузли. Коли віклікається діяльність ORDERACTIVITY, керуючий маркер поміщається в початковий вузол, а маркер Даних з інформацією про замовлення - в об'єктній вузол вхідного параметра. Керуючий маркер рухається від віхідного Вузли до Дії CREATEORDER, Пожалуйста начинает Виконувати. Маркер Даних передається від відповідного параметра Дії, что віклікає FILLORDER, якому доводиться чекати до качана Виконання, поки CREATEORDER НЕ надасть Йому інші вхідні дані. После Завершення Дії FILLORDER керуючий маркер передається на кінцевій вузол, діяльність завершується, а управління возвращается елементів, Який ініціював Цю діяльність. Часткова модель сховища для рис. 7 представлена ​​нижче на Мал. 8 . Вона зв'язується з представленої на рис. 6 моделі сховища за допомогою CB1 CALLBEHAVIORACTION. Дія CREATEORDER і його потоки для стислості опускаються.

Поведінка в UML 2

В UML 2 підтримується концепція параметризрвані поведінки не тільки для діяльності, а для всіх типів робіт UML. Це означає, що кінцеві автомати, взаємодії та діяльність можуть бути параметризрвані і служити методами об'єктів або викликатися безпосередньо однаковим способом. У правій верхній частині рис. 9 показана модель діяльності для роботи DELIVERMAIL (хвилясті стрілки не є частиною нотації UML). DELIVERMAIL можна просто викликати через дію CALLBEHAVIORACTION, або як метод класу POEMPLOYEE через дію CALLOPERATIONACTION. У будь-якому випадку ця робота приймає в якості вхідних даних екземпляр KEY. Оскільки роботи можуть викликатися безпосередньо або як операції, UML 2 надає шлях до поступового засвоєння об'єктно-орієнтованого підходу [3].

В UML 2 визначаються користувачами роботи теж є класами. Всякий раз, коли виконується робота, створюється новий екземпляр часу виконання класу користувальницької роботи. При завершенні виконання роботи цей екземпляр знищується. Класи робіт, як і всі інші класи, можуть містити атрибути, асоціації, операції і навіть інші роботи, такі як кінцеві автомати. Це є загальною практикою в системах, які керують процесами, скажімо, в системах управління потоками робіт або операційних системах. У нижній частині Рис. 8 представлений клас робіт для діяльності DELIVER MAIL з атрибутом, що містить час виконання кожного примірника DELIVER MAIL, з операцією для припинення виконання і з асоціацією з використовуваним вантажівкою. Додатки можуть також поміщати в клас робіт кінцеві автомати, щоб описувати стану кожного виконання, такі як NOT_STARTED, SUSPENDED і т.д. [5, 6].

Класи робіт UML 2 дозволяють визначати стандартну функціональність управління процесами, хоча в самій мові UML 2 не визначаються такі стандартні засоби. Властивості класів робіт можуть бути визначатися на основі стандартів прикладних областей силами постачальників або груп користувачів в якості повторно використовуваних бібліотек моделей, що містять абстрактні класи робіт з нормативними атрибутами і операціями, такими як ABORT і т.д. Потім ці класи можуть бути використані як супертіпи певних користувачами робіт, таких як DELIVER MAIL на рис. 9.

резюме

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

література

1. U2 Partners, «Unified Modeling Language: Superstructure», version 2.0, 3rd revised submission to OMG RFP ad / 00-09-02, http://www.omg.org/cgi-bin/ doc? ad / 2003-04-01 , April 2003.
2. Object Management Group, «OMG Unified Modeling Language», version 1.5, http://www.omg.org/cgi-bin/doc?formal/03-03-01 , March 2003.
3. Bock, Conrad, «Three Kinds of Behavior Model», Journal of Object-Oriented Programming, 12: 4, July / August 1999.
4. Bock, Conrad, «UML Without Pictures», IEEE Software, September / October 2003.
5. Object Management Group, «Workflow Management Facility Specification», version 1.2, http://www.omg.org/cgi-bin/doc?formal/00-05-02 , May 2000.
6. Workflow Management Coalition, «Workflow Standard - Interoperability Abstract Specification», http://www.wfmc.org/standards/docs/TC- 1012_Nov_99.pdf , November 1999.

Конрад Бок ( [email protected] ) - експерт в області комп'ютерних наук Національного інституту стандартів і технології (National Institute of Standards and Technology). Керівник робочої групи з підготовки до випуску версії UML 2.

Translated from «UML 2 Activity and Action Models» by Conrad Bock in Journal of Object Technology (JOT), vol.2, No. 4, pages 43-53. Translated into Russian for Open Systems Journal under special permission of the original publisher . Copyright JOT July-August 2003. Original article at http://www.jot.fm/issues/issue_2003_07/ column3 .

1 Для того щоб модель дії відповідала діяльності, її слід будувати на основі більшої кількості блоків; поки ж вона складається лише з INTERMEDIATEACTIONS і COMPLETEACTIONS. У них містяться заздалегідь задані дії, такі, як створення об'єкта, призначення атрибутів і т.д. Абстрактне поняття дії визначається в модулі BASICACTIVITIES, оскільки він є невід'ємною частиною моделі потоків.

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

3 В мові UML немає відмінностей між об'єктами і даними; ці поняття зведені до єдиної категорії - класифікатори (classifiers).

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

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

6 При необхідності UML 1.5 і UML 2 забезпечують можливість роботи зі змінними.

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

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