Eng Укр Рус
На головну >> Технологія: Основні принципи: Рівні автоматизації;
Технологічні рішення
    Пошук     


Основні принципи


Рівні автоматизації

Обмеження класу задач задачами MRP, MRPII, ERP і CRM, інтенсивні процеси по їхній стандартизації, накопичений досвід і наробки в рішенні цих задач дозволили нам пройти три еволюційних етапи автоматизації процесу розробки (мал.3).


Рис.3. Рівні автоматизації процесу розробки

Приведені на рисунку три рівні автоматизації відображають еволюційних етапи розвитку процесу розробки корпоративної інформаційної системи (КІС). На першому етапі КІС розробляється шляхом створення програмного коду, що відображає логіку взаємодії програмних об'єктів і логіку бізнес-процесів, що автоматизуються КІС. Кожен новий проект по розробці КІС – це новий програмний код, що розробляється практично з нуля. Цикл розробки включає моделювання, проектування і кодування. При нагромадженні “критичної маси” програмного коду, після реалізації декількох проектів, у розробників з'являється можливість створення системи параметризованих програмних рішень (ППР) або шаблонів проектування, що інкапсулюють у собі базові методи рішення задач розробки і по суті відбивають практичний досвід розробників у рішенням цих задач.

Створення системи ППР характеризує перехід до другого еволюційного етапу автоматизації. На цьому етапі програмування заміняється конфігуруванням (настройкою) системи ППР на рішення конкретних задач. Результатом конфігурирування є логіка роботи системи ППР чи металогіка (логіка “роботи” логіки). При цьому система ППР має деякий інтерфейс конфігурування (настройки) і може бути покладена в основу Інтерпретатора металогіки, що виконує металогіку “на льоту”. Таке рішення вигідне як з погляду розробки (воно дозволяє випробувати кілька різних прототипів системи без особливих часових витрат, приклад – Tcl/tk), так і з погляду архітектури системи (воно дозволяє використовувати переваги інтернет-броузерної технології). Цикл розробки на другому рівні автоматизації включає моделювання і проектування, що по своїй суті виливається в конфігурування системи ППР мовою металогіки (наприклад, XML). Виграш за часом розробки досягається за рахунок відсутності трудомісткого повномасштабного кодування.

Досвід розробників отримує нову якість – тепер це досвід конфігурування системи ППР мовою металогіки. Згодом накопичується “критична маса” уже конфігураційного коду і з'являється можливість створення системи параметризованих конфігураційних рішень (ПКР) чи шаблонів моделювання, що інкапсулюють у собі базові принципи конфігурування системи ППР виходячи з поставлених задач. Створення системи ПКР характеризує перехід до третього еволюційного етапу автоматизації, на якому конфігурування системи ППР заміняється конфігуруванням системи ПКР. Інтерфейсом конфігурування (настройки) системи ПКР при цьому служить деяка мова моделювання (наприклад, UML). Модель, побудована в рамках цієї мови, інтерпретується Інтерпретатором моделей у файл металогіки готовий до виконання вже в Інтерпретаторі металогіки. Таким чином, на третьому рівні автоматизації досить змоделювати задачу, після чого отримується її рішення в готовому вигляді, тобто цикл розробки зводиться до моделювання, а виграш за часом розробки досягається за рахунок відсутності етапів проектування і кодування.

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

Технологічні рішення

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

1.

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

2.

Командою розроблена та відлагоджена на практиці система ППР. На основі цієї системи побудований інтерпретатор металогіки, що отримав назву Sphere Portal. У запропонованій архітектурі металогіка інтерпретується Sphere Portal-ом “на льоту”, подібно тому як інтернет-броузером інтерпретується HTML-документ. Відмінність полягає в тому, що результатом інтерпретації є повноцінний віконний інтерфейс, що реалізує всі необхідні користувачу функції: від редагування, сортування і складного пошуку до складання аналітичних звітів і створення друкованих форм.

3.

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





© 2001 RAISE Team