Концепція системи комплексної автоматизації "Оберон"

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

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

І що нам для цього потрібно?

Необхідна гнучкість

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

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

Насамперед він повинен забезпечувати роботу з базою даних. При цьому ми усвідомлюємо, що в різних випадках це будуть дуже різні бази даних - і за обсягом даних, і за частотою оновлення, і за вимогами до безпеки, і за характером превалюючих запитів, і за допустимими вимог до обслуговуючого персоналу. Тобто наш інструмент повинен давати можливість взаємодіяти з базами даних під керуванням різних систем керування базами даних (СУБД).

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

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

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

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

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

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

Відділення інструментального рівня

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

І в той же час нам, як творцям СКА "Оберон", не хочеться апріорі відмовлятися від жодних можливостей. Ми залишаємо за собою право та можливість повернутися і до екранних, і до тригерних "рюшечкам".

Просто в інший час. "Є час збирати каміння і є час розкидати каміння". Працюючи з прикладним фахівцем, ми хочемо розмовляти його мовою.

Для цього потрібно відокремити мух від котлет, а інструментальний рівень прикладного рішення – від прикладного.

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

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

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

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

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

Метадані

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

Модифікація метаданих здійснюється за допомогою двох програм-дизайнерів, умовно названихАРМом Технолога и АРМом Адміністратора. В АРМе Технолога описуються сутності системи, їх реквізитний склад та взаємозв'язок між ними. (Детальніше з термінами, які застосовуються в контексті СКА "Оберон", можна ознайомитись в розділі "Термінология"). АРМ Адміністратора призначений для опису екранів системи, їх взаємного співвіднесення та меню, що з'являється на кожному з них.

Метадані системи використовуються на етапі проектування, прототипування, для побудови SQL-скрипту для створення бази даних системи, і вони ж інтерпретуються та використовуютьсяуніверсальним АРМом користувачапід час експлуатації системи.

Версійність

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

І весь цей час вона змінюється.

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

На місцевості" це означає, що у будь-який момент часу існує версія метаданих системи (з Універсального АРМу Користувача номер версії можна побачити з пункту меню "Різне" -> "Про систему" головного вікна будь-якого АРМа). Нова версія автоматично створюється, коли натискається кнопка "Зберегти" на головному екрані АРМа Технолога.

Крім цього, АРМ Технолога містить спеціальний режим порівняння версій метаданих, який, крім власне порівняння версій, має режим генерації SQL-скрипту для коректного переходу прикладної системи від однієї версії до іншої. Зрозуміло, SQL-скрипт будується для будь-якої підтримуваних СКА "Оберон" СУБД.

Ну і, зрозуміло, до складу ядра прикладної системи, побудованої з використанням СКА "Оберон" входить механізм автоматичної зміни версій. Він включає: централізовану розсилку нової версії на віддалені вузли розподіленої системи; завантаження нової версії до бази даних вузла; виконання SQL-скриптів для зміни структури бази даних та перенесення даних у нову структуру; звірку при кожному запуску Універсального АРМу Користувача версії, що зберігається в базі даних, з тією, що встановлена на робочому місці користувача та оновлення за необхідності локальної версії програми на комп'ютері користувача.

Бізнес-логіка

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

Іншою подією для початку роботи бізнес-логіки системи є прямі дії користувача, який виконує деякі дії, передбачені творцями прикладної системи. Наприклад, на якомусь екрані (ймовірно, на головному, але зовсім не обов'язково) АРМа користувача підсистеми, призначеної для розрахунку заробітної плати працівникам організації повинна бути кнопка (пункт меню, важіль, педаль нарешті), що ініціює власне розрахунок. Для реалізації таких можливостей служить механізм процедурних точок входу в систему.

Як у процедурних, так і в тригерних точках входу працюють макрозавдання, створені однією з інтерпретованих («скриптових») мов, що застосовуються СКА Оберон. Ці мови, особливо «рідні» для операційних систем мова MS Windows VisualBasic, і мають необмежені можливості для організації взаємодії СКА "Оберон" із зовнішніми системами - від електронної пошти до офісних програм. Там же, де цих можливостей не вистачає чи їх використання надмірно складно, можливості цих мов значно розширено засобами власне ядра СКА "Оберон".

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

Масштабованість

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

При цьому саме собою прикладне рішення, виконане з використанням СКА "Оберон" є повністю незалежним від СУБД. Допускається використовування різних СУБД на різних вузлах однієї і тієї ж прикладної системи, у тому числі і на вузлах, ідентичних за використовуваним функціоналу. В розділі "Рішення" описано прикладне рішення Національного депозитарію України, в рамках єдиної системи депочитарного обліку якого частина вузлів зберігачів цінних паперів працює під управлінням СУБД MS SQL (від 2000 до 2008), а частина - під керуванням СУБД Oracle (від 8i до 10g).

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

Покрокова обробка

Бізнес-логіка прикладної системи, пов'язана з об'єктами сутностей, здебільшого прив'язана до базових подій цих сутностей. Так, створення в системі об'єкта сутності "Проведення" завжди тягне негайні зміни в об'єктах сутності "Залишок на рахунку". Видалення об'єкта Сутність "Проведення" також тягне зміни - зворотні. Для реалізації такого функціоналу ідеально підходять тригерні входи в систему, про які згадувалося раніше./p>

У складніших випадках, коли, наприклад, документ складського обліку може бути спочатку просто введений, потім багаторазово скоригований, "розцінений", завізований і лише потім проведений (відповідно до нього реквізитами, створено один або більше об'єкт сутності "Проведення"), відстеження виконаних над таким документом операцій, а також відстеження документів, обробка яких не завершена, вводиться окремий атрибут сутності - стан: "Введено", "Завізовано", "Проведено" і т.п.

Іноді для зберігання переліку можливих станів об'єкта деякої сутності достатньо перерахування (Див. розділ " Термінологія"). (Див. розділ "

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

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

Можливо, на словах це дуже складно і віддає псевдонауковій чортівньою, але насправді це дуже просто і прозоро. Складний алгоритм обробки об'єктів сутності розбивається на фрагменти, кожен з яких яких відносно простий і реалізується цей фрагмент. Кожен фрагмент алгоритму виконується над об'єктом, який опинився в деякому стані (довідник станів, у яких може бути об'єкт, описується у разі як досить проста самостійна сутність системи). Після виконання цього фрагмента об'єкт перетворюється на одне з наступних станів. Наприклад, зі стану документа "Введено" фрагмент алгоритму може, залежно від реквізитів документа, перевести його у стан "Потребує візування" або відразу в стан "Готов до проводки". Из стану "Потребує візування" уповноважений співробітник може перевести його в стан "Готов до проводки" (завізувати) або "Відхилено". Документ у стані "Готов до проводки" проводиться (хоч би що означав цей термін стосовно цього документа) незалежно від того, відправлявся він на візування і пройшов його - чи минув цей етап обробки.

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

Активний крок виконується негайно під час переходу об'єкта у відповідний стан (наприклад, крок, який виконується на стані "Готовий до проводки" у наведеному вище прикладі).

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

Інтерактивний крок виконується користувачем. Прикладом такого кроку є крок візування у наведеному вище прикладі. Як правило, він реалізується як екранне вікно типу "Грід"(Список) з кількома кнопками, що означають прийняте користувачем рішення ("Дозволити", "Відхилити", "Повернути на доопрацювання" тощо).

Графи переходів станів об'єктів конкретних сутностей прикладних систем може бути досить складними, циклічними, незв'язними. Все залежить від предметної галузі. Жодних обмежень на можливий граф переходу станів СКА Оберон не накладає.

Найчастіше для побудови прикладної системи цілком достатньо однієї сутності, на якій реалізовано механізм покрокової обробки. Однак і тут Система комплексної автоматизації "Оберон" жодних обмежень не накладає. Наприклад, в описаному у розділі "Рішення" системі канцелярського документообігу, самостійні графи переходів станів побудовані для кількох сутностей: "Документ", "Вузол маршруту", "Історія", "Справа". В описі Біржової електронної торгової системи власні графи переходів станів мають дві сутності - "Заявка" та "Угода".

Розподілена обробка

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

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

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

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

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

Кожна із систем розподіленої обробки має свої переваги, обидві вони реалізовані у закінчених проектах (так, на системі реплікацій побудовано Біржову електронну торговельну систему "Оберон-БЛІЦ", а на електронний документообіг - Система депозитарного обліку Національного депозитарію України - див. розділ"Рішення"). Вибір тієї чи іншої системи розподіленої обробки здійснюється в залежності від особливостей предмета автоматизації.

Захист

Захист – дуже багатогранне поняття. В кожному з прикладних рішень є свої особливості. Ми лише нагадаємо, що автори системи довгий час працювали над створенням банківського програмного забезпечення забезпечення, де питанням захисту приділяється особлива, на межі параної, увага, і коротко зупинимося на деяких аспектах захисту прикладних систем, створених з використанням СКА "Оберон"./p>

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

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

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

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

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

Збережені процедури, що генеруються АРМом Технолога для доступу до об'єктів будь-якої з сутностей, обов'язково містять програмний код для детального протоколювання дії користувача: хто, коли, який об'єкт створював/змінював/видаляв, які поля змінював, які значення на які значення замінив. Оскільки користувач засобами СУБД позбавлений прямого доступу до таблиць бази даних, то протоколювання ведеться і в тому випадку, якщо доступ до бази даних буде здійснено минаючи ядро системи. Система, зрозуміло, включає засоби аудиту, що дозволяють розібратися, хто і що накоїв із даними.

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

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

Розширюваність

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

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

Детальне освітлення механізму плагінів виходить за рамки цього опису. На завершення додамо, що плагіни репрезентують собою динамічні бібліотеки (DLL) спеціальної структури, що розміщуються у певну директорію та автоматично "підіймаються" ядром Системи комплексної автоматизації "Оберон". Доступ же до їхнього функціоналу здійснюється за допомогою пунктів меню окремого типу, що описуються при в АРМі Адміністратора, або з макрозавдання, за допомогою виклику функції RunDisp.

Переклад, мови

Базовою мовою СКА "Оберон" є англійська, а не українська. Це пов'язано з тим, що англіська мова присутня на всіх комп'ютерах./p>

Прикладне рішення, розроблене за допомогою СКА "Оберон", може бути перекладено будь-якою мовою або будь-якими мовами.

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

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

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