9.3.2. Основні компоненти інформаційної системи 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 (це означає, що одній адресі можуть відповідати одна або декілька контактних осіб). Контактна особа, проте, відповідає лише одній адресі. «Байк Інк» не потрібно здійснювати операції з наведеного прикладу, оскільки все це вже введене в довідковій моделі. Проте, можливо, буде необхідним внесення певних уточнень.