Термінологія

В рамках Системи комплексної автоматизації "Оберон" склалася деяка терміноголія, розуміння якої спростить і розуміння системи загалом.

Сутність

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

Система може одночасно оперувати необмежену кількість сутностей. Сутності описуються в АРМі Технолога. З часом кількість сутностей та їх набори атрибутів (реквізитний склад) можуть змінюватись.

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

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

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

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

Атрибут (поле) сутності

Атрибут, чи поле, чи реквізит сутності описує одне із параметрів об'єкта (примірника) сутності, якими він може відрізнятися від інших об'єктів тієї ж сутності. Кожна сутність може мати необмежену кількість атрибутів.

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

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

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

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

Значення обчислюваних атрибутів автоматично обчислюються системою за допомогою макрозавдання тригерного входу.

Ккожна сутністьОБОВ'ЯЗКОВО та має поле з типом значення "Ціле число" з ідентифікатором "0" та мнемонічним ім'ям "Id". Це поле при створення екземпляра сутності слід залишати порожнім, його значення буде автоматично присвоєно системою, і міститиме унікальний (у рамках сутності та в рамках вузла системи) ідентифікатор об'єктів. При пересиланні об'єкта з вузла на вузол система вживає спеціальних заходів для перекодування ідентифікатором об'єктів з метою їхнього коректного використання на всіх вузлах системи.

Грід

У простому випадку грід служить для представлення переліку екземплярів сутності. Фізичним поданням гріда в базі даних є представлення (view), яке автоматично генерується АРМом Технолога по мета-даним прикладної системи. Створюючи уявлення, АРМ Технолога здійснює зв'язування сутностей відповідно до правил, описаними за допомогою механізму лукапів, таким чином, поля уявлення відповідають не тільки збереженим, але й лукапним полям.

По суті може бути описано необмежену кількість грідів. В кожному конкретному гріді нічого не винні бути присутніми всі поля сутності.

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

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

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

Форма сутності. Панель

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

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

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

Крім полів форми, пов'язаних із полями сутності, бувають ще два типи полів. Перший - це квазі-поля, що описують "декоративні" Елементи екранної форми: лінії, малі літерали, панельки.

Другий - це міні-гріди, в які виводяться міні-гріди пов'язаних сутностей.

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

Ієрархія сутностей

Сутності системи може бути пов'язані між собою зв'язком типу " Один до багатьох " . При цьому може виявитися, що ці зв'язки вибудовуються в ланцюжок, наприклад, сутності "Область", "Район", "Населений пункт", "Вулиця" є класичний ланцюжок, що поступово деталізує адресу.

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

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

У деяких випадках ефективним є використання в екрані типу "Ієрархія" навіть ієрархій, що складаються лише з двох сутностей.

Рекурсія

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

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

Користувальницький діалог

Користувальницькі діалоги описуються в АРМі Технолога, у окремому режимі. Зовні вони мають багато спільного з екранною формою об'єкта, але не припускають зв'язку екранної форми з об'єктом бази даних.

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

Внутрішнім уявленням користувальницького діалогу є об'єкт Dialog, експортована в макромову виконуючим ядром СКА "Оберон".

Перелік

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

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

Переліки описуються в Переліки описуються в АРМі Технологата зберігаються у файлах формату XML разом з іншими метаданими прикладної системи.

Активний звіт

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

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

Поля розділу активного звіту мають візуальне подання у рамках графічної моделі розділу. Змінні звіти заповнюються на етапі випуску звіту та фіксуються в такому стані на час виконання користувача діалогу над його екранним представленням.

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

Внутрішнім поданням активного звіту є об'єкт ActRep, експортована в макромову виконуючим ядром СКА "Оберон".