Тема №46. Основні компоненти ІС Miracle V

Запитання для самоперевірки

1. Яка класифікація форм вихідної інформації?

2. Яка методика побудови форм вихідної інформації?

Література:Л1с.378-380

План:

1. Основні компоненти Miracle V.

Опис компонентів Miracle V наведено нижче (рис. 9.15).

Рис. 9.15. Miracle V – компоненти

9.3.2.1 Repository

Repository — центральний компонент Miracle V. У ньому зберігаються усі визначення, правила та описи (включаючи зв’язки та відношення між ними самими). Repository являє собою різні аспекти інформаційної системи (рис. 9.16), які контролюють і визначають роботу виконавчої системи Miracle V. Інструменти Miracle V використовують інформацію з Repository та зберігають її у ньому. Його можна описати як «вихідний код» для всіх прикладних програм.

Рис. 9.16. Різні аспекти інформаційної системи

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

Як і в усіх компонентах Miracle V, включаючи й виконавчу систему, в Repository суворо дотримані принципи об’єктно-орієн­тованого програмування. В Repository визначаються базові класи. Від них походять усі інші класи, наприклад, від класу «Основні дані (Trunk data)» походить клас «Адреси». Таким чином, не тіль­ки Miracle V, а й уся бізнес-модель є об’єктноорієнтованою. На даний момент розроблені такі базові класи: основні дані, процеси, документи, журнали, форми, вибірки, запити, дозволи на доступ, організаційні структури (рис. 9.17).Усі окремі класи в моделі можуть поєднуватися один з одним — вільно асоціюватися або тісно пов’язуватися. Ці зв’язки полягають не просто в спеціалізації та ієрархії наслідування (наприклад, нова адреса приєднується до форми адреси, яка, в свою чергу, приєднується до запиту). Усі класи з їхніми відношеннями складають бізнес-модель. Вона є робочою моделлю Miracle V.

Наводимо діаграму, яка описує конструкцію Repository.

Рис. 9.17. Схема Repository

Цей приклад роз’яснює викладені вище думки. Компанії «Байк Інк» потрібно вводити адреси, де вказується більш ніж одна контактна особа. Існує клас «адреса», похідний від базового класу «основні дані». Атрибути — це поля для необхідних даних про адресата (назва компанії, прізвище, ім’я, відділ і т. ін.). Обираються методи «створити», «змінити» та «вилучити».

За допомогою компоненти Miracle V Form Designer (дизайнер форм) генерується форма для адреси. Дизайнер форм «знає» про атрибути (поля) та методи (функції) з класу «Адреса». Форма
адреси є породженням форм базового класу. Клас «Адреса» поєднаний з відповідною формою, що дозволяє їй управляти адресами. Окрім того, клас «Адреса» пов’язаний з класом «населений пункт» (похідним від базового класу «Основні дані»), котрий містить усі населені пункти та відповідні індекси. Метод «внесення населеного пункту», який дозволяє обирати індекс, також доступний класу «адреса». Для вказання контактної особи створюється клас «контактна особа», похідний від класу «адреса». Далі визначається взаємозв’язок між двома класами, в даному випадку 1:n (це означає, що одній адресі можуть відповідати одна або декілька контактних осіб). Контактна особа, проте, відповідає лише одній адресі. «Байк Інк» не потрібно здійснювати операції з наведеного прикладу, оскільки все це вже введене в довідковій моделі. Проте, можливо, буде необхідним внесення певних уточнень.

9.3.2.2. Інструментарій для побудови бізнес-процесів

Усі інструменти Miracle V, прямо пов’язані з процесами, називаються інструментарієм бізнес-процесів. До нього належать: Business Process Modeler, Business Process Executer, Business Process Analyzer та Business Process Simulator. Modeler визначає процеси на різних рівнях абстракції. Під час моделювання процеси відкриваються та виконуються додатком Executer. Уся інформація, зібрана під час роботи, може бути вивчена за допомогою компонента Analyzer. Simulator створює сценарії типу «що—якщо для усіх процесів або їхніх частин.

Опис перелічених інструментів для побудови бізнес-процесів наводиться нижче.

l Business Process Modeler

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

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

Рис. 9.18. Рівні абстракції у Process Modeler

У бібліотеці довідкової моделі містяться декілька різних процесів однієї спрямованості. Це дозволяє підприємству обирати процес(и), який(і) підходить(ять) найбільше. Це зменшує потребу в модифікації процесів (рис. 9.19).

Рис. 9.19. Загальний вигляд процесу «Замовлення»

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

Рис. 9.20. Етап роботи процесу

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

Рис. 9.21. Етап роботи — операційні кроки (дії)

Різні завдання прив’язуються до функціональних робочих місць (рис. 9.22):

Рис. 9.22. Компонент Organigram Designer

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

Рис. 9.23. Business Process Modeler

Як показано вище, Process Modeler також виробляє повну документацію. За допомогою системи підтримки користувачі завж­ди знають, де саме у процесі вони знаходяться. Допоміжна інформація видається автоматично, залежно від того, з якого зав­дання її викликали.

l Business Process Executer

Додаток Business Process Executer виконує усі процеси та правила, визначені у Business Process Modeler. Він відповідає за всі види завдань, їх цілісність, опрацювання у правильній послідовності та нагляд за їх виконанням. Business Process Executer координує комплекс завдань системи та управління і розподіл окремих завдань (рис. 9.24).

Рис. 9.24. Система завдань

Далі описується робота Business Process Executer. Після його активації з робочого місця (WorkPlace) Executer відшукує бажаний процес і запускає перше його завдання. Системні дії виконання для цього завдання здійснюються у порядку, визначеному у Modeler. Коли дія виконана, викликається наступна (відповідно до правил, визначених у Modeler). Ця процедура триває доти, доки завдання не буде виконане повністю. Звичайно потім Exe­cuter передає наступне завдання до Task Manager, який надсилає відповідне повідомлення для наступного відповідального працівника (або групи). Передана задача належить групі доти, доки один із членів групи не приймає її. Розподіл задач здійснюється під контролем системи управління задачами. Окрім того, задачі можуть бути вільно визначені та автоматично передані відповідно до органіграми.

Продовжимо розгляд прикладу — опрацювання вхідного рахунка-фактури у компанії «Байк Інк». Усі вхідні рахунки-фак­тури спочатку вводяться, потім передаються відповідній особі для перевірки, підтвердження та сплати. За допомогою ярлика на робочому місці (Miracle V WorkPlace) активується завдання «введення рахунків-фактур». Перша дія завантажує форму для введення рахунка-фактури та інші необхідні компоненти. Наступна дія, власне введення рахунка-фактури, являє собою взаємодію з користувачем. Коли користувач закінчує дію (введення рахунка-фактури), вона успішно завершується. Це є остання дія, отже, завдання «введення рахунків-фактур» також успішно завершується. Task manager потім генерує нове завдання для робочого місця відповідальної особи. З викликом цією особою «підтвердження» виконуватимуться усі дії завдання «підтвердження». Коли і воно завершиться, буде створене нове завдання для відділу рахунків (на їхньому робочому місці). Якщо завдання відміняється, усі дії автоматично і коректно будуть повернуті у вихідний стан системою.

l Business Process Analyzer

Уся інформація, згенерована під час виконання завдань, записується компонентом Business Process Analyzer, наприклад, інформація про те, які завдання, як і ким були виконані, скільки часу було витрачено і яким шляхом пішов процес. Ці та інші дані опрацьовуються додатком Analyzer, а результати надаються влас­никові процесу та керівництву (в разі потреби).

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

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

l Business Process Simulator

Немає потреби наголошувати, що у комплексному продук-
ті, як-от Miracle V, обов’язковою є можливість здійснювати симулювання. Business Process Simulator дозволяє моделюва-
ти та симулювати окремі процеси та їхні частини. Результуючий стан середовища генерується на основі статистичних методів.

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

9.3.2.3 Робочі місця (WorkPlace)

Робоче місце Miracle V — це інтегроване робоче середовище та головне вікно для прикладних програм Miracle V. Формат, поведінка та інтуїтивність WorkPlace стандартні для ОС Windows 95 та NT. По суті WorkPlace — це інтерфейс між Miracle V та кін­цевим користувачем. На робочому місці користувачі знаходять усі об’єкти, необхідні для виконання своїх задач, — об’єкти бізнес-процесів, об’єкти запитів, а також окремі адреси та документи (рис. 9.25).

Рис. 9.25. Робоче місце Miracle V

Користувач та ергономічність для користувача були в центрі уваги під час розробки Miracle V. Це чітко видно по WorkPlace, яке може бути повністю індивідуально настроєне кожним користувачем згідно з мірою його відповідальності та правами доступу. WorkPlace поводить себе залежно від того, яке завдання виконується. Наприклад, на документи про зарплату у WorkPlace можуть бути створені ярлики для подальшого опрацювання. Користувачі, котрі не мають права на доступ до даних про зарплату, не можуть запустити на виконання ці запити або відкрити інші завдання, що пов’язані із зарплатою.

WorkPlace містить такі елементи, як папки, посилання, ярлики, меню, контекстні меню, лінійки інструментів та стану. Тут наявні певні суттєві відмінності від робочих середовищ Win­dows 95/NT, котрі певною мірою є статичними. Наприклад, папка, де багато користувачів створюють та вилучають файли, не буде автоматично обновлюватися. Або ж ярлик прикладної програми може залишатися навіть після того, як сама програма була вилучена. Все це не стосується Miracle V. Багато об’єктів Mi­racle V мають короткий життєвий цикл, наприклад задачі у пе-
реліку незробленого або ярлик до документа. Якщо завдання надсилається усій групі і приймається членом групи, його треба негайно вилучити з переліку задач решти. Наведемо інший приклад: якщо згаданий вище документ вилучається, ярлик до нього також повинен бути вилучений. WorkPlace відповідає за автоматичне створення та вилучення цих типів об’єктів.

9.3.2.4. OO Model Studio

Більша частина інструментарію Miracle V, за винятком інструментарію бізнес-процесів, згрупована в об’єктно-орієнтованій студії моделей (Object Oriented (OO) Model Studio). Це дозволяє швидко і безпосередньо змінювати структури даних, форми, документи тощо відповідно до потреб підприємства. Деякі з компонентів OO Model Studio описані нижче.

l Class Master

Додаток Class Master — це центральний інструмент визначення класів. За його допомогою із використанням модифікацій від базових класів усі класи розміщуються в Repository і пов’язують­ся між собою. Засадничі класи були описані в розділі 9.3.2.1 — Repository.

У Class Master здійснюється створення та зміна атрибутів і методів класу. Для деяких специфічних завдань Class Master використовує інші інструменти, наприклад, для модифікування методу Class Master переключається прямо в систему розробки. Як уже зазначалося, класи пов’язуються і поєднуються між собою у різні способи. Ці зв’язки легко створюються і вилучаються у Class Master. Клас також можна утворити від іншого. Новий клас тоді успадкує усі атрибути, методи та зв’язки материнського класу. Ці наслідувані методи можна ігнорувати за допомогою макромови Miracle V. Класи також можуть бути пов’язані за допомогою асоціювання та поєднання. Таким чином утворюється їх надійна мережа.

l Transaction Processor

Додаток Transaction Processor відповідає за те, щоб реєстрація та інформаційні потоки відповідали певним правилам. Інформаційні потоки вводяться та зберігаються як «документи». Це не обов’язково повинні бути типи документів, які друкуються, але можуть бути й такі. Кожна операція має системний статус документа. Так, введення елемента запасів є операцією і, отже, документом. Операції є важливою частиною кожної інформаційної системи. Критично важливою є можливість зміни поведінки та правил інформаційних потоків відповідно до нових умов і потреб. Кожна операція генерує інформаційний потік. «Майстри» (wizards) Miracle V підтримують моделювання операцій.

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

Операції (або документи) фіксуються у журналах. Деякі документи можуть бути зареєстровані в декількох журналах. Який документ має бути зареєстрований та якому журналі, — це визначається користувачем. Журнали є основою для вибірок. Журнали і вибірки є дублюючими інформаційними потоками. Отже, існує можливість складати та модифікувати їх після здійснення операцій.

l Concentrator

Додаток Concentrator є інструментом, тісно пов’язаним з Tran­saction Processor. Він дозволяє здійснювати безпосередній доступ до таких даних, як баланси, звіти про рух запасів тощо. Дублювання у формі вибірок є необхідним. Воно і є завданням компонента Concentrator. Залежно від пріоритетності вибірок вони можуть бути створені в режимі безпосереднього доступу, за гра­фіком або «на вимогу».

l Система запитів

Здійснення запитів даних є центральною функцією будь-якої інформаційної системи. Система запитів формулює усі запити до бази даних. Вона тісно співпрацює з Mask Designer і здатна створювати багато типів запитів. Система запитів перетворює (заснований на об’єктах) запит на розширений вираз SQL і автоматично виконує його. Результати можуть бути передані до генератора звітів або до будь-якої іншої прикладної програми Miracle V.

Система запитів Miracle V дозволяє створювати складні запити і користувачам, які мають поверхові знання щодо баз даних та програмування або взагалі їх не мають (рис. 9.26).

Рис. 9.26. Система запитів

l Mask Designer

За допомогою Mask Designer можна створювати нові форми та модифікувати існуючі. За необхідності кожен користувач може мати свої індивідуальні форми. За своїм спектром можливостей інструмент розробки форм відповідає таким добре відомим і розповсюдженим продуктам, як Visual Basic, Delphi, Access і т. ін. Будь-яка особа, що вже використовувала ці засоби, одразу зможе ефективно працювати з Miracle V Mask Designer.

Наявні усі стандартні елементи управління. Якщо їх виявиться недостатньо, можна легко створити нові. Mask Designer тісно інтегрований із системою запитів, що дозволяє без зайвих зусиль вбудовувати запити у форми. Оскільки ергономічність перебувала у центрі уваги під час розробки Miracle V, то Mask Designer відіграє ключову роль у наданні користувачам саме тих форм, яких вони потребують, незалежно від характеру їхньої роботи та конкретних завдань (рис. 9.27).

Рис. 9.27. Mask Designer

l Система розробки

Для забезпечення максимально можливої гнучкості Miracle V була розроблена його власна макромова. Вона являє собою 32-бітну мову програмування, що повністю підтримує багатопоточність та засоби автоматизації OLE-2. Можливості й синтаксис цієї мови порівнювані з Visual Basic. Наявний також інтегрований наладчик, який дозволяє здійснювати віддалене налагодження.

l Генератор списків

Miracle V надає у розпорядження користувача потужний генератор звітів. До системи включений добре відомий і популярний продукт ReportSmith.

9.3.2.5. Інтерфейс бази даних

l Інтерфейс бази даних

Нижче зображена взаємодія між виконавчою системою Mi­racle V та заснованою на SQL базою даних (рис. 9.28).

Рис. 9.28. Інтерфейс бази даних

Інтерфейс поділений на два рівні. Це дозволяє підтримувати різні SQL-бази даних. Компонент вищого рівня інтерфейсу перекладає специфічні об’єктно-орієнтовані вирази Miracle V у стандартні вирази SQL.

l Communication Manager

Miracle V підтримує стандартні інтерфейси — MAPI та TAPI. Це дозволяє надсилати електронну пошту або передавати повідомлення на пейджер. Здійснюється це за допомогою Communi­cation Manager.

Дата добавления: 2014-12-07