Робота з редактором Workflow

1 1 1 1 1 1 1 1 1 1 Рейтинг 0.00 (0 Голоса)

Лекція 7. Робота з редактором Workflow

Визначення Workflow

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

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

Workflow можна назвати “ангелом-охоронцем” що веде користувача через всі необхідні етапи в Workflow Job та забороняє користувачу робити помилки.

·  Простий Workflow

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

·  Складний Workflow

Складний Workflow також може бути створений в ArcCadastre. Це може містити такі пункти, як в простому Workflow, але з розширеними функціями. Прикладом складного Workflow є процес, в якому деякі операції повинні бути завершені в даній послідовності або іншим способом перед продовженням процесу. Workflow може бути розширений з блоком, написаним в будь-якій COM-complient мові, такій, як Visual Basic. Розширення може, наприклад, бути створено для завершення деяких етапів автоматично. При застосуванні COM-complient мови також можливо зв’язуватись з іншими зовнішніми додатками. Якщо, наприклад, одна з дій написана протоколом Word, розширення Workflow повинно відкрити Word, створити новий документ, користувач запише необхідну інформацію та зберігти це у визначеній директорії. Workflow звичайно створюється спеціалістом наладчиком за допомогою редактора Workflow, що міститься в пакеті ArcCadastre. Редактор зберігає інформацію про Workflow в форматі XML.

Побудова Workflow

Workflow створений та змінений за допомогою редактора Workflow в ArcCadastre. Користувач ArcCadastre може створювати Workflow з комплексною функціональністю. Workflow файл додається до шаблону Job та всіх Jobs, створених з шаблону, і буде використовувати цей Workflow. Предполагаемый метод для наладчиків – це використання білої дошки та так званої post-it наклейки коли визначається їх Workflow/процес. Після цього Workflow буде перевірено редактором Workflow, також будуть перевірені діаграми станів на законність та на відсутність небезпечних конструкцій.

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

Редактор Workflow

Користувач застосовує редактор Workflow для створення діаграм станів зі станами, переміщеннями, подіями та умовами. Редактор є інструментом інтерактивного компонування діаграм станів. Редактор Workflow використовує діалог Workflow. Редактор Workflow найбільш важливі завдання створює в XML файлі для опису Workflow. Читання XML файлу, перевірка незаконних та небезпечних конструкції та створення коду робиться компонентами ArcCadastre.

Редактор Workflow може генерувати основу коду для розширення Workflow. Генерування коду має в першій версії концепцію “генерування один раз”. Якщо внесені деякі зміни до коду, вони не можуть бути внесені до коду, в разі, якщо генерація коду зроблена знов для діаграм станів.

Компоненти діаграм станів (state diagram)

Діаграми станів – це UML діаграми, що створені для опису workflow, що включає стани, переміщення, події, умови та нижчі діаграми (subdiagrams), а також як події та умови впливають на стан через деякий час. Основна діаграма станів має декілька елементів, але при цьому вона дуже потужна та гнучка.

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

Стани (States)

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

Діаграми станів повинні мати одну стартову точку (початковий стан) та принаймні одну кінцеву точку (кінцевий стан). Кінцевий стан також має модель, що може бути завершена або перервана. Ця модель застосовується для попередження в job якщо workflow був завершений або перерваний. Ця модель має сенс тільки для workflow найвищого рівня.

Переміщення (Transition)

Transition є зв’язком між двома станами, що свідчать про перехід job від першої стадії до другої, коли трапляються точно визначені події та виконуються точно визначені умови. Transition має одне джерело стану та одну ціль стану. Стан може мати декілька transition до однієї або більше цілей стану. Transition має логічне ім’я та унікальний внутрішній номер (id) в workflow. В UML діаграмах, transition зображуються як стрілки, що зв’язують стани. Transition має OnTransition дію (назва зі структури workflow в розширенні Workflow).

Transition можуть бути ручні (manual), обумовлені (conditioned) та автоматичні (automatic).

Ручні (з або без умов):

Події приєднані до станів transition. Transition виконується, коли трапляються події.

Обумовлені:

Якщо умови приєднані до станів transition, transition буде підсвічено (will fire) коли умови стають вірними (true)/

Автоматичні:

Transition стану звичайно має подію або умову, приєднану до нього, але це не є необхідним.

Віртуальна (Virtual) transition (переміщення)

Віртуальна transition відображається в діалозі workflow, але не існує в UML діаграмі. Віртуальна transition застосовується для взаємних особливих умов в transition. Віртуальна transition може комбінувати умови або/та події з інших transition. Це також може включати умови та події, що не з’єднані з іншими transition в діаграмі.

Умови

Умова є логічним виразом; вона має логічне ім’я та унікальний внутрішній (id) номер у workflow. Умови будуть приєднані до transition. Вони можуть бути ручні та автоматичні.

Ручні умови показуються в вікні перевірки, де вони можуть бути перевірені вручну.

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

Ручні умови мають процес Умови клацання (Condition Click action). Автоматичні умови обчислюється в дії в Умовах обчислення. Автоматичні умови, якщо перевіряються, можуть бути зроблені автоматично. Звичайний інтервал часу виражається в мілісекундах (msec). Значення, що присвоюється по умовчанню (default value) є 10000. Якщо умова приєднана до деяких можливих transition з поточного стану це буде перевірено з цим часовим інтервалом. Якщо значення дорівнює 0, воно ніколи не буде перевірено. Для автоматичного інтервалу значення по умовчанню складає 6000, для інтервалу transition значення по умовчанню дорівнює 4000.

Події

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

Події мають логічне ім’я та унікальний внутрішній номер (id) в workflow.

Події будуть прив’язані до transition.

Нижчі діаграми workflow

Workflow може містити інші workflow. Існує тільки один workflow верхнього рівня, але може існувати кілька workflow нижнього рівня (діаграми нижнього рівня - subdiagrams).

Subdiagrams можуть бути використані, наприклад, коли необхідно розглядати workflow з різних рівнів абстракції/деталізації. Можна також знову використовувати деякі загальні завдання імпортуванням існуючих subdiagrams до workflow.

В UML-діаграмах стани, що мають subdiagrams, зображуються як прямокутники зі округленими кутами та двома еліпсами.

Компоновка workflow

Вручну, з використанням миші:

Стани та переміщення (transition) в Редакторі Workflow можна переміщувати коли відкрито діалог Edit Position. Для переміщення елементу необхідно лівою клавішею миші в нажатому стані перемісти обраний елемент стану або переміщення. Виділення декількох станів або переміщень здійснюють натисканням клавіші ctrl та лівої клавіші миші. Таким же чином відміняється виділення. Натиснувши клавішу shift, коли обрані стани/переміщення можна лише виділити їх або відмінити виділення. В той же час це дає можливість натиснути та тримати кнопку міші для переміщення елементів. Такі ж дії можна здійснювати з діалогу Створити Стани (Create State) або Редагувати Стани (Edit State). При створенні станів також можливо точно вказувати позицію стану замість натискання кнопок миші.

Обґрунтування (Validation)

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

Можливі помилки:

·  Створення 2-х transition з станів без установочних параметрів у transition; після цього workflow не зможе йти двома шляхами.

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

·  Стан без підтримки, якщо стан створено та при цьому забуто визначити переміщення до стану.

Конфлікт при обробці даних:

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

Як вирішити цей конфлікт?

Конфліктуючі дані демонструються користувачу, який в інтерактивному режимі повинен зробити вибір між існуючими переміщеннями. Звичайно. Найкращим рішенням буде створення workflows, де не виникне жодних конфліктів.

Моделювання

Після створення workflow та перевірки його на помилки, необхідно виявити як це буде з’являтися для користувача та протестувати можливі взаємодії користувачів. Редактор Workflow може моделювати workflow з використанням діалогу workflow. Це моделює та показує, як діалогу workflow буде з’являтися для кінцевого користувача в процесі роботи з ArcCadastre. При роботі з користувачем діалог workflow буде з’являтися і користувач буде виконувати всі необхідні дії при роботі з workflow та тестувати це.

Розширення Workflow

Після закінчення всіх етапів створення workflow (створення, перевірка, моделювання та кінцева ухвалена версія) необхідно створити основу коду для workflow в порядку додавання до перероблених процедур та функцій. Через редактор workflow модна автоматично генерувати VB (Visual Basic) проекти workflow, застосовуючи розширення workflow.

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

Зміна коду (Code refactoring)

Коли workflow створено, генерування коду для розширення workflow часто робиться на початку процесу. На протязі роботи з діаграмами станів вони звичайно, змінюються декілька разів перед узгодженням. Команда Code refactoring переробляє існуючий код згідно зі змінами в діаграмі станів.

Установочні параметри Workflow (Workflow settings)

Можна змінити установочні параметри та властивості workflow з меню редагування (Edit menu) –властивості. В діалозі Властивості (Properties) знаходяться п’ять таблиць, що визначають всі властивості workflow.

Ці таблиці такі:

Таблиця проекту (Project tab) – містить опис та інформацію стосовно того, хто і чому створив workflow. Вона задумана як заду коментовані мета дані workflow. Також містить необхідне кодування для xml файлу.

Таблиця діаграм (Diagram tab) – Хоча workflow має опис, також кожна діаграма (нагадаємо, що workflow складається з декількох діаграм) може мати власний опис. Коли відкривається діалог властивостей активної діаграми, тільки одна таблиця установок діаграми буде введена.

Таблиця компоновки (Layout tab) – містить установки компоновки: виміри діаграми, використані кольори та шрифти для відображення на екрані та для друку.

Таблиця моделювання (Simulate tab) – містить установки для моделювання workflow.

Таблиця авто збереження (Auto save tab) – містить установки для здійснення авто збереження для workflow.