Основи Системного Аналізу Об'єктів і Процесів Компютеризації:Іспит

Матеріал з USIC Wiki

Ця стаття відноситься до групи довідкових статей для студентів ФІН.

• Портал:Інформаційні науки

Перелік питань для самостійної підготовки

Зміст 1 Матеріали 2 [7] Концепція єдиного інформаційного простору 3 [11] Сутність електронної комерції 4 [12] Форми електронної комерції 5 [15] Вимоги споживачів до електронної комерції 6 [17] Ключові сфери ЕК, в яких необхідна стандартизація 7 [18] Пластикові картки та засоби електронних платежів 8 [19] Схеми обслуговування пластикових карток 9 [25] Віртуальний магазин для роздрібної торгівлі в WWW-мережі 10 [26] Захист і безпека електронної комерції 11 [39] Роль сучасних інформаційних систем у різних сферах діяльності. Підприємство з міжмережною структурою. Кіберкорпорація та її стратегічна перевага. 12 [40] Інформаційні технології та глобалізація діяльності. Реорганізація ділових процесів під впливом ІТ та досягнення конкурентної переваги. 13 [41] Атрибути інформаційної якості ІТ. 14 [43-44] Класифікація ІС для операцій та менеджменту. 15 [45] Види інтелектуальних консультантів. 16 [48] Засоби та заходи підтримки електронного офісу. 17 [50] АРМи та корпоративні інформаційні системи 18 [53] Цикл розробки КІС. Фактори дослідження КІС на підприємстві. Сфери системного аналізу КІС. 19 [54] Задача концептуального моделювання предметних областей. Три джерела знань про предметну область 20 [58] Каскадна модель життєвого циклу програмної системи 21 [63] Прототипування за спіральною моделлю життєвого циклу 22 [70] Етапи створення корпоративних ІС. Методи обстеження та проектування концептуальної моделі. 23 [73,75,78] Семантична мережа. Види вершин-понять та дуг-відношень. Фрейми, ієрархії, процедурні допо-внення. 24 [82] ER-модель «сутність-зв’язок». 25 [86] Порівняння семантичних мереж і ER-моделей як концептуальних моделей. 26 [88] Чотири фази накопичення (надбання) знань. Задачі надбання знань. 27 [90] Схема надбання знань за моделями правил. 28 [92-95] Задача поновлення правил із дослідних даних та алгоритми навчання на прикладах 29 [28] Способи добування фахового досвіду. 30 [29] Класифікація методів добування знань від експертів (прямі та непрямі). 31 [110] Одинадцять рекомендацій щодо вибору механізмів розв’язання задач стосовно способів абстрагування та методів дослідження простору рішень у різних ПрО. 32 [116] Парні та множинні порівняння як методи одержання якісних оцінок 33 [118] Ранжування, гіпервпорядкування, вектори переваг, класифікація як методи одержання якісних оцінок 34 [119-121] Методи кількісного оцінювання (безпосередня числова оцінка та метод Чорчмена-Акофа) 35 [122] Добування колективного досвіду у експертному аналізі. Проблема компетентності експертів. Метод комісії. Метод суду. Мозкова атака. Метод Делфі. Розв’язувальні матриці Г.Поспелова. 36 [126] Порівняння прогнозного графу В.Глушкова та систем ПАТТЕРН і ПРОФАЙЛ; ПЕРТ, ГЕРТ і МКШ. 37 [156] Формула повного подання объекта в OMT. Приклади об’єктів. 38 [160] Залежності між класами (відношення БД). Характеристики залежностей. 39 [164] Агрегація як відношення ціле-частина. Узагальнення підклас-суперклас. Абстрактні класи. 39.1 Агрегація 39.2 Узагальнення і спадкування 39.3 Абстрактні класи 40 [164] Спадкування суперклас-підклас. Множинне Спадкування 41 [169] Співвідношення між об’єктами у ОМТ та базами даних. Метадані, тиражування екземплярів, ключі об’єктів або залежностей, обмеження, похідні об’єкти, зв’язки, атрибути 42 [173] Етапи побудови об’єктної моделі. 42.1 Визначення класів 42.2 Підготовка словника даних 42.3 Визначення залежностей 42.4 Уточнення атрибутів 42.5 Подальше дослідження й удосконалювання моделі 43 [187] Динамічна модель. Події, сценарії та траси подій 44 [190] Стани та діаграми станів. Умови, активності та дії, синхронізація дій у динамічній моделі 45 [194] Діаграми потоків даних (функціональна .модель). Процеси, потоки даних, активні об’єкти (акто-ри), сховища даних, потоки управління 46 [196] Дослідження вхідних та вихідних значень, рівнів процесів, описів функцій, обмежень на значення об’єктів, критеріїв оптимізації. Врахування архітектури прикладних систем. 47 [198] Сім рівнів OSI-моделі взаємодії відкритих систем. Протокол як сутність телекомунікації. 48 [223] Риси відкритих систем щодо розподіленої обробки: незалежність від постачальника, мобіль-ність, інтероперабельність 49 48. Системи на основі WWW-мереж. Веб-сервер, веб-броузер, гипертекстові та гипермедійні БД 50 [227] Корпоративні мережі Інтранет/Екстранет. Web-браузери та сервери, система протоколів TCP/IP, Web-публікації, гипермедiйне відображення HTML-документів i баз даних 51 50. Співставлення двох технологій розподіленого обробки клієнт-серверної архітектури на основі OSI-моделі та TCP/IP. 52 51. Поняття дволанкових, триланкових та багатоланкових розподілених застосувань клієнт-серверної архітектури. 53 [231] Сервери у мережах: сервер телекомунікацій, сервер застосувань, диско-сервер, файл-сервер, сервер баз даних, принт-сервер 54 [233] Види розподіленої обробки: однорангова мережна, централізована і кооперативна обробка, обслуговування черги повідомлень 55 [232-234] Взаємодія компонентів розподілених засто¬су¬¬вань. Виклик віддалених процедур (RРС). Відси-лання запита (request раssing) для вико¬нан¬ня методів. Роль стандарту СОRВА. 56 [236] Виклик віддалених процедур. Взаємодія через інтерфейс на мовах RРС, АРІ, ІDL. 57 [237] Задача маршалінгу розподілених застосувань. 58 57. Системна архітектура клієнт-сервер з програмними компонентами розподілених застосувань: подання функцій вводу і відображення даних; специфічні прикладні функції ПрО; доступ до ін-формаційних ресурсів зі зберіганням і управлінням даними. 59 58. Моделі архітектури клієнт-сервер: сервер баз даних та сервер застосувань. 60 [246] Сервер БД. Взаємодія між клієнтськими і серверними частинами. Протокол віддаленого виклику процедур. Типовий розподіл функцій між клієнтами і серверами. Розподілена компіляція запитів. Іменування об’єктів і розподілений каталог. Резервне копіювання (тіньовий сервер). 61 [261] Сервери корпоративних БД – сервери робочих груп. Застосування робочих груп (календар, потік робіт, розклад, електронний документообіг). Організація сумісних робіт, різновиди електронних конференцій. 62 61. Сервери корпоративних БД – сервери робочих груп. Прикладні сервіси для застосувань клієнт-серверної архітектури; комунікаційні сервери (віддалений доступ і маршрутизація); Iнтернет; доступ до розподіленої інформації; сервіс локальних мереж (розподіл файлів/ принтерів); управління системою/ дистанційне управління; електронна пошта. 63 [264] Оцінка завантаження сервера. Тести ТРС. 64 [269] Обробка даних у сховищах (Data Warehоuse). Типи БД: оперативні, аналітичні, виділені, зовнішні бази даних, інформаційні сховища та бази даних кінцевих користувачів. 65 64. Оперативні ІС з режимом OLTP. Аналітичні ІС та ОLAP-технологія у системах забезпечення прийняття рішень (СЗПР). 66 65. Типи сховищ даних: віртуальне, централізоване, розподілене. Data mart або "інформаційна віт-рина". 67 66. Родові ознаки DW (за Інмоном). Орієнтація на об’єкти. Інтегральність та інваріантність даних. Стабільність інформації 68 67. Три етапи добування даних для DW. 69 68. Етапи побудови DW. Стратегічний аналіз. Розробка плану реалізації проекту. Побудова моделі даних DW. Оцінка і вибір засобів побудови DW. Експлуатація готової системи. 70 [282] Типи закономірностей Data Mining’а: асоціація (близькість), послідовність дій, класифікація, кла-стеризація, прогнозування 71 [284] DM-методи: виведення правил асоціації, нейронні мережі, дерева рішень, k-найближчий окіл, комітетні та генетичні алгоритми, візуалізація даних 72 [290] Успішні приклади OLAP & Data Mining. 73 [291] OLAP & Data Mining. Співставлення можливостей на прикладі однієї задачі. 74 [318] Типи інтерфейсів Еталонної моделі POSIX-OSE: API та EEI. Категорії служб POSIX-OSE. 75 74. Цільові установки POSIX-OSE. Інтероперабельність; мобільність (даних, користувача, приклад-них програм); узгодженість зі стандартами; узгодженість з новими технологіями ІС; розширюва-ність прикладної платформи; розширюваність розподілених систем; прозорість реалізації; функ-ціональність вимог користувача. 76 75. Переваги POSIX-OSE: інтеграція компонентів від множини постачальників; ефективна розробка і реалізація; раціональне перенесення прикладних програм 77 76. Еталонна модель POSIX-OSE. Інтерфейси типу EEI: людина/ комп’ютер HCI; інформаційних служб ISI; комунікаційних служб CSI. Категорії служб POSIX-OSE. 78 [325] Еталонна модель служби мовної підтримки POSIX-OSE. 79 [332] Еталонна модель служби Системного ядра POSIX-OSE 80 [341] Еталонна модель комунікаційних служб POSIX-OSE 81 [351] Еталонна модель служби підтримка баз даних POSIX-OSE 82 [363] Еталонна модель служби обміну даними POSIX-OSE 83 [369] Еталонна модель служби обробки транзакцій POSIX-OSE 84 [375] Еталонна модель служби командного інтерфейсу користувача POSIX-OSE 85 [379] Еталонна модель служби символьно-орієнтованого інтерфейсу користувача POSIX-OSE 86 [382] Еталонна модель служби поліекранного відображення POSIX-OSE 86.1 Еталонна модель віконної системи 86.2 Сервіс API 86.3 Сервіс EEI 86.4 Стандарти, специфікації і недокументовані послуги 86.5 Перехресна категорія служб POSIX-OSE 87 [391] Еталонна модель служби підтримки графіки POSIX-OSE 87.1 Еталонна модель 87.2 Сервіс і глосарій термінів графіки 87.3 Стандарти, специфікації і недокументовані послуги 88 [398] Еталонна модель служби підтримки розробки застосувань 89 [401] Служби інтернаціоналізації POSIX-OSE. Обслуговування наборів символів/ подання даних 89.1 Сервіс інтернаціоналізації 90 [403] Служби інтернаціоналізації POSIX-OSE. Обслуговування культурних домовленостей 91 [404] Служби інтернаціоналізації POSIX-OSE. Обслуговування природномовної взаємодії 92 [408] Служби системної безпеки POSIX-OSE 92.1 Сервіс безпеки 92.2 Стандарти і специфікації 93 [411]. Служби системного адміністрування POSIX-OSE 94 [419] Поняття профілю. Мета профілю. Типи профілів: одностандартний, профіль платформи, AEP 95 94. Профілі стандартів для суперкомп’ютерних обчислень 96 95. Профілі стандартів для систем реального часу 97 96. Роль вертикальних профілів на прикладі GOSIP США та Великої Британії, NetBIOS, MAP, TOP

Матеріали

[7] Концепція єдиного інформаційного простору

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

За визначенням ЮНЕСКО, інформаційна технологія – це комплекс взаємопов’язаних, наукових, технологічних, інженерних дисциплін, що вивчають методи ефективної організації праці людей, зайнятих обробкою та зберіганням інформації; комп’ютерну техніку і методи організації та взаємодії з людьми і виробничим обладнанням, їхнє практичне застосування, а також пов’язані з усім цим соціальні, економічні та культурні проблеми. Динамічна взаємодія машинних ІС разом з телекомунікаціями створює становий хребет IТ. Самі ІТ вимагають складної підготовки, великих початкових ви¬трат і наукоємної техніки. Їхнє запровадження починається зі створення математичного забезпечення, формування інформаційних потоків та підготовки фахівців. Рівень розвитку інформаційного простору передусім впливає на економіку, обороноздатність та політику. Від нього залежить поведінка людей, інвестиційний клімат, формування суспільно-політичних рухів та соціальна стабільність. Метою інформатизації у всьому світі є якнайповніше задоволення інформаційних потреб суспільства в усіх сферах діяльності. Єдиний інформаційний простір (ЄІП) – це сукупність баз даних, технологій їхнього ведення та використання, інформаційно-телекомунікаційних систем та мереж, що функціонують на основі єдиних принципів і за спільними правилами, забезпечують інформаційну взаємодію організацій та громадян, а також задоволення їх інформаційних потреб. Суттєва роль у формуванні ЄІП відводиться створенню громадських телекомунікаційних мереж, що об’єднують різні мережі, системи та комплекси засобів зв’язку, забезпечуючи користувачам доступ до відповідних територіально-розподілених інформаційних ресурсів, обмін інформацією у різних режимах пересилання даних.

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

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

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

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

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

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

[11] Сутність електронної комерції

Великою популярністю користуються такі послуги Iнтернет-комерції, як продаж книг і продуктів харчування, бронювання квитків і туристичних турів. Світовий торговий обіг в Iнтернет наприкінці 2000 ріку оцінювався у $31-33 млрд. (у 2001 році $50 млрд.), половина угод здійснювалася між компаніями, половина - між споживачами. Відомості з практики США та Японії про цінність Інтернету для бізнесу свідчать про такий розподіл прибутків:

• 35% заощадження на витратах;
• 32% обслуговування клієнтів;
• 18% збільшення обороту;
• 13% точніший маркетинг;
• 2% інше.

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

1. Можливе суттєве заощадження витрат, оскільки ведення ділових операцій в Інтернеті за допомогою прикладного ПЗ i Інтернет-технологiй обходиться дешевше, тому що витрати на його розробку, використання та підтримку менші, ніж на використання традиційних систем.
2. Розробка та використання корпоративного програмного забезпечення для Iнтранету дешевші за традиційні системи з використанням майнфреймів або систем клiєнт-сервер.
3. Інтернет i WWW-мережі використовуються для інтерактивного маркетингу та обслуговування клієнтів.
4. Одержання прибутків в результаті використання Інтернету через прикладні програми електронної комерції.

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

1. віртуальний електронний магазин;
2. магнітні картки та електронні гроші;
3. оренда та продаж ПЗ, передплата на бази даних;
4. продаж нерухомості, аукціони;
5. електронні банки, які надають клієнтам фінансові послуги;
6. фірми, що утримують Iнтернет-моли, або компанії-оператори з продажу товарів.

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

Цикл ЕК складають 5 процесів:

1. доступ до інформації;
2. замовлення;
3. оплата товару;
4. виконання замовлення;
5. післяпродажне обслуговування і підтримка зв’язку з клієнтом.

Для системи операцій ЕК існують різні сценарії. Так, багато провідних фірм (Microsoft, Netscape, CyberCash, Verifone, Cisco Systems, Amazon, Onsale, BidnAsk и Virtual Vineyards) пропонують широкий діапазон програмного забезпечення для вирішення задач ЕК: на основі Web-технології, XML-технології (Extensible Markup Language), яка витісняє зараз EDI-стандарт (Electronic Data Interchange) електронного обміну даними) і стає основним засобом проведення on-line ЕК-операцій.

Модель на рис. 1.1 демонструє роботу бізнес-процесів, що охоплюють замовлення та платежі. Кодування змісту транзакцій має такі позначення дій:

1. вигляд товарів, ціни;
2. обговорення ціни, розміру платежу, партії товару (елементи даних отримують власника, патентуються, шифруються за стандартом);
3. ідентифікація;
4. пропозиції продавця;
5. замовлення покупця;
6. прийняття замовлення;
7. платіжне доручення продавець - покупцю;
8. інструкції про оплату - покупець банку;
9. платіжне доручення – банк продавцю;
10. відвантаження товару;
11. (с) застосування криптографії (ідентифікація, аутентифікація, підпис, перевірка підпису, перевірка сертифікату);
12. (р) надання відповідних прав власності на елементи даних;
13. (s) часткова вимога стандартизації елементів даних.

У ЕК застосовуються ІТ зв'язку та Інтернету; що спираються на шість рівнів технології:

• прикладні послуги;
• керування БД й розподіл даних;
• інтерфейснi послуги;
• безпечна передача інформації;
• проміжне забезпечення midleware;
• інфраструктура мережі.

Ці технології мають інтегруватися у систему ЕК-компанiї. У минулому це було важко здійснити з причин несумісності систем, які постачалися різними фірмами. Тепер технологічні стандарти в Інтернеті призвели до жаданого переходу до відкритих систем, надійного зв'язку та операційної сумісності ЕК-технологiй. Отже, Інтернет став каталізатором i підґрунтям для розповсюдження ЕК і надає компаніям, підприємцям та інвесторам можливість скористатися повністю відкритою економічною моделлю ЕК; наведемо її головні характеристики:

• низькі вхідні перешкоди;
• чисельні ринкові ніші;
• багато джерел доходів;
• ніхто не панує на Iнтернет-ринку.
• однакові технології доступні для всіх.
• Інтернет доступний скрізь i для всіх.

Сфера ЕК щодо вимог бізнесу визначається як споживання наявної і майбутньої інформації та технологій зв'язку у підтримці бізнесу з метою розвитку фреймворка, що потрібний для розгортання ЕК і містить об'єктивні оцінки ідентифікації ринків і обмежень бізнесу. Більшість відомих аналітичних оглядів ЕК не досягло кінцевої мети, тому що вони розглядали специфічні питання підтримки бізнесу або його вплив на успіх окремих ІТ. Два підходи можуть допомогти у кращому передбачення майбутнього розгортання ЕК. Перший підхід вплинув на утворення комітету з інформації Computer and Communications Policy of the OECD, у звіті якого “Значення електронної комерції” [OECD/GD(97)] наведено загальний опис значення ЕК і проаналізовані дані про поточний стан і майбутні напрямки ЕК. Висновки OECD-підходу щодо визначення послуг у сфері ЕК:

1. ЕК знаходиться у початковому стані, а технологія і динаміка ринку визначають її основний вигляд;
2. поки обсяг ЕК виду бізнес-бізнес набагато перевищує передбачені обсяги бізнес-споживач через невирішеність або недостатній розвиток:
   • адаптації комерційних бізнес-застосувань;
   • спрощення потоків бізнес-даних через кордони держав;
   • угод про нові способи укладання контрактів і аутентифікацію учасників, коригування угод (цифровий підпис, сертифікація);
3. без процесів бізнес-споживач підтримка ЕК - це забава. З одного боку, не усі вимоги або послуги будуть сприйняті людьми або владою, з іншого, - для розвитку новаторських сервісів і техніки щодо електронних платежів для невеличких рахунків необхідна on-line сертифікація, техніка аутотенфікації, саморегуляція;
4. на ринку процесів бізнес-споживач ПЗ, сервіс пересилання даних і фінансів залишаються головними у реалізації ЕК-застосувань. Це означає, з одного боку, врегулювання захисту споживача, з іншого, - розвиток рішень для власника або захист сервісу провайдера (авторське право і боротьба з піратством).

У другому підхіді за сприяння Єврокомісії вивчалися соціальні проблеми і була прийнятта ЕК-концепції NICT-споживачів (New Information and Communication Technologies) як громадян усього Євросоюзу. Щодо інтересу до нових послуг, зокрема ЕК, за результатами 16 тисяч інтерв'ю у всіх країнах Євросоюзу оцінювалися три подібних технології: інформаційна (ІТ), TV-цифрова, телефонна. У висновках обґрунтований розвиток в Європі саме телефонної комерції, яка має потенційний ринок до 20% всього населення Євросоюзу. З нових послуг і застосувань всіх приваблює електронний доступ до адміністрації.

[12] Форми електронної комерції

На множині вузлів Інтернет-мережі вводяться такі форми ЕК, тобто типи транзакцій:

1. бізнес-бізнес;
2. бізнес–державна адміністрація;
3. приватна особа–бізнес;
4. приватна особа–державна адміністрація;
5. державна адміністрація–державна адміністрація;

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

[15] Вимоги споживачів до електронної комерції

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

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

Легкість використання. ЕК має бути легка у користуванні для всіх груп споживачів; цьому допомагають ергономічні принципи підтримки користувацького інтерфейсу.
Елементи користувацького інтерфейсу повинні бути послідовними (узгодженими) і важли¬ві для методів обробки, збереження, доступу. Такий інтерфейс досягається, коли:

1. всі компоненти користувацького інтерфейсу однакові (вимога стандартизації);
2. інтерфейс адаптується до користувача так, що він завжди має індивідуальний інтерфейс.
   

Спроможність до адаптації. Система має забезпечити вихідний формат і крок, що покриє індивідуальні вимоги. Це є шлях досягнення консенсусу для всіх користувачів. Цей принцип застосовується до захищеного доступу до системи у разі зростання споживчого інтересу.
Забезпечення інформаційного статусу системи, завжди досяжного для користувача.
Толерантність до помилок і стабільність системи. Система має попереджати про помилки виконання операцій. Система буде стійкої навіть, якщо користувач спробує довідатися про послуги, яких потім складно позбутися, або зробить зайвий вибір продукції чи послуг.
Мінімізація користувацьких вимог до запам'ятовування системних операцій. Система має графічно зображувати діалогові елементи, наприклад, меню, яке дає змогу досягти мети.
Можливість вивчення забезпечує система, заохочуючи користувача вмикати її функції без зайвого побоювання.
Реалізація для усіх. Стандарт ЕК підтримує цей принцип, важливий для людей із широким спектром можливостей. Індивідуальні вимоги кодуються стандартним засобом так, що до них адаптується користувацький інтерфейс.
Функціональність рішень. Стандартна підтримка ЕК забезпечує вимоги різних користувацьких груп і різноманітних задач. Культурні аспекти враховуються щодо географічних, соціальних та етнічно-релігійних зон.
Лінгвістичні аспекти враховуються діючими стандарти і за потреби мають з'являтися нові.
Термінологія, застосовувана у користувацькому інтерфейсі (включаючи брошури, інструкції, інформацію, надану системою), не повинна бути спеціальної, а має відбивати загальні вимоги.
Інтероперабельність. Різноманітні послуги мають бути доступні через будь-яку мережу за допомогою будь-якого терміналу. Сумісність має забезпечуватися так, щоб нові версії системи були сумісні з попередніми версіями систем і компонентів, які розроблені і постачаються різними фірмами.
Конфіденційність має забезпечуватися системою індивідуально.
Безпека інформації має забезпечуватися при її пересиланні, збереженні, одержанні, знищенні. Рівень безпеки в точності буде співвіднесений із користувачем, а засоби криптографії стануть елементами стандартизації.
Ціна прозорості. Система має бути прозорої щодо своєї собівартості. Інформаційні витрати треба подавати стандартно, тобто первинні витрати користувача на підєднання і наступні витрати щодо роботи у мережах або використанні help'ів і on-line-режиму мають чітко фіксуватися. Від'єднання від ЕК-засобу слід звільнити від витрат.
Достовірність інформації має забезпечуватися системою.
Якість сервісу і надійність системи повинні мати засіб визначення й подання, чим визначається розвиток індикаторів подання інформації щодо продажу товарів.
Рейтинг і градація системи. Стандарти ЕК розглядають застосування з їхніми оцінюванням і градацією. Необхідно розвивати стандарти щодо оцінювання і презентації систем для легкого застосування, надійності системної й інформаційної взаємодії.
Участь споживачів у розвитку системи забезпечується через усі фази стандартизації процесів, щоб підтримувати дружній інтерфейс системи. Це включає планування робіт зі стандартизації, встановлення пріоритетів і участь у технічних розробках.
Екологічні аспекти. В екологічному плані наукові й об'єктивні методи необхідно підтверджувати середовищем дружніх продуктів і ІТ впродовж їхнього життєвого циклу.

Ідентифіковані ключові сфери ЕК, в яких необхідна стандартизація:

1. користувацькі інтерфейси: створення образів об’єктів (зображень); принципи організації діалогу; профілі покупців.
2. базові ЕК-функції: протоколи торгівлі; системи і методи платежів; механізми безпеки; ідентифікація і автентифікація; аудит, збереження записів;
3. визначення і кодування даних і об’єктів: IT-придатність чинних стандартів; техніка для визначення семантики повідомлень; національно-культурна локалізація; авторизація реєстрації клієнтів; домени значень (предметні області), необхідні в ЕК.

Введені такі пріоритети вимог :

• High (H) – вищий; розглядає суттєве для глобального використання ЕК;
• Medium (M) - середній; важливий для прискорення впровадження ЕК;
• Low (L) - низький; nice to have (мати задоволення).

Поки всі наведені вимоги мають пріоритети Н і М, хоч не чисельні чинні міжнародні стандарти переважно відносяться до сфери А. Щодо ІТ-придатності стандартів з’ясувалася необхідність перегляду більше 40 чинних стандартів про коди валют, країн, мов та товарів з позицій комп’ютерної обробки. Існування різних схем кодування, що відрізняються правилами кодування та довжиною і вмістом полів форматування, недоцільне щодо потреб ЕК у реалізації прозорих і детермінованих процедур обробки даних. Так, за стандартами ISO 3166 і ISO 4217 треба враховувати багато чисельні факти щодо кодуванні валют та цінних паперів:

• країна (колонія) не має власної валюти і використовує валюту іншої країни;
• країна має більше однієї валюти, тобто власну й іншої країни;
• країна має код як валюти, так і цінних паперів;
• ряд країн колективно поділяють і використовують валюту, яка не має країни-емітента, наприклад, євро;
• валюта не пов’язана з жодною країною чи організацією, наприклад, цінні метали платина чи золото;
• валюта не має числового коду за ISO 3166, а тільки 3-alpha код за ISO 4217, наприклад, золотий франк.

[17] Ключові сфери ЕК, в яких необхідна стандартизація

Ідентифіковані ключові сфери ЕК, в яких необхідна стандартизація:

1. користувацькі інтерфейси: створення образів об’єктів (зображень); принципи організації діалогу; профілі покупців.
2. базові ЕК-функції: протоколи торгівлі; системи і методи платежів; механізми безпеки; ідентифікація і автентифікація; аудит, збереження записів;
3. визначення і кодування даних і об’єктів: IT-придатність чинних стандартів; техніка для визначення семантики повідомлень; національно-культурна локалізація; авторизація реєстрації клієнтів; домени значень (предметні області), необхідні в ЕК.

[18] Пластикові картки та засоби електронних платежів

Банки використовують досить широкий спектр систем автоматичної обробки готівкових коштів: банкомати, авто­ма­тичні обмінні пункти та елект­ронні депозитарії. Як різновид інтерактивних послуг клієнтам пластикові картки (ПЕК) замінили розрахунки готівкою. Шматок пластика фіксованих роз­мірів з магнітною смугою і/чи мікросхемою відріз­няється потенційною універсальністю застосу­вання платіжного інструмента завдяки стандарти­зації інтерфейсів обміну.

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

До магнітних карток разом з магніт­ною смугою прилашто­вано видавлений текст з основними відо­мос­тями про власника, банк-емітент, номер рахунку клієнта. Кожний клієнт має відомий тільки йому РIN-код, що автоматично ідентифікується платіжною системою. Чіпова картка має замість магнітної смуги мікросхему для проведення основних операцій з карткою через електронні канали. За стандартом розташування самої мікросхеми і контактів строго лімітова­но щодо забезпечен­ня різних платіжних систем. Розрізняють картки з пам’яттю, що збільшує обсяг збереженої інформації порівняно з магнітною смугою, і мікропроцесорні смарт-картки (Smart Cards) з вмонтованим процесором, який забезпечує значно вищий рівень захисту на основі криптографічних методів. Звісно, смарт-картки коштують набагато дорожче за магнітні.

Зараз поширилися комбіновані картки, на яких разом з мікросхемою нанесена магнітна смуга. Таку карт­ку можна використовува­ти як чіпову у замкнених регіонах і як магнітну у мандрівках до великих міст, де переважно розвинута інфра­струк­тура магнітних карток. Щодо регламенту обслуговування ПЕК поділяються на дебетові, кредитні та електронні гаманці. Якщо на заході в основному поширені кредитні картки з різноманітними схемами застави, допус­тимого кредиту (овердрафт) і комісійних, то у нас переважно викорис­товуються дебетові картки. Необхідно попередньо внести на картрахунок певну суму, а платежі і зняття грошей у банкоматі проводяться у межах внесеної суми або залишку, що не знімався

Потенційний інтерес в Україні мають електронні гаманці; щодо малих міст схема безго­тів­кових розрахунків з викорис­танням ПЕК дозволяє побудувати суцільну систему розрахунків. При цьому банки за вимогою поповнюють електронний гаманець у межах залишку на рахунку клієнта і обмежень на залишок. В точках оплати (роint of sasale – POS) в межах одного міста розраховуються за картками з використанням спеціального обладнання, а їх інкасація проводиться електронним способом за допомогою приблизно такої ж картки або спеціального обладнання.

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

Сьогодні ПЕК знаходять нове застосування. Телефон і метро, про­даж бензину і газового палива, медицина і страхування, пен­сій­не забез­пе­чення – це далеко не повний перелік використання ПЕК. Власне вони забезпечують користувача ідентифікаційним номером у конкрет­ній сис­темі регламен­тації надання продуктів і послуг, яка гарантована банком або іншим емітентом.

[19] Схеми обслуговування пластикових карток

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

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

1. кожного вузла цієї мережі POS-терміналами урахування платежів, що можуть вбудовуватися в касові апарати нарівні зі зчитувальниками штрих-кодів і проводити інкасацію електронних платежів;
2. кожного вузла цієї мережі приймачами звітів про поточну зміну правил обслуговування (гарячі списки неплатоспроможних карток, зміна розміру комісійних і знижок, модифікація коду інкасації тощо);
3. станції друку для графічної персоналізації ПЕК; складається з ПК, цифрової відеокамери зі спалахом або кольоровим сканером, відеоплати обробки зображень і принтера для друкування ПЕК; включає кодувальний пристрій для запису (перезапису) на магнітну смугу або чіп картки;
4. процесінгового центру, що виконує функції емітенту карток (випуск для нових клієнтів і поновлення для старих), контролю за їхнім використанням (упорядкування гарячих списків), інкасації виторгу в кожному вузлі мережі і контролю угод з функціонуванню мережі (розміри комісійних, знижок, пільг, квот тощо), ведення БД про клієнтів, вузли мережі, надходження засобів тощо.

Проте для комплексного функціонування устаткування в складі такої системи електронних розрахунків потрібні засоби телекомунікації, хоча б електронна пошта для всіх чотирьох компонентів, що забезпечує пересилання повідомлень у режимі off-line (рис. 1). Цей режим має переваги з шифрування інформації, достатньо дешевий і надійний, а головне – потребує на обслуговування мінімальних зусиль персоналу.

Обсяг ПЗ для обслуговування устаткування всіх компонентів можна оцінити в 10-12 тисяч рядків таких мов, як С++ і Java. Потрібний також сервер БД. Група з 5-7 програмістів може виконати таку роботу за 10-12 місяців з одночасною наладкою устаткування і навчанням персоналу. Причому ПЗ варто відразу розробляти як інструментальну оболонку, що спроможна адаптуватися до правил функціонування системи електронних розрахунків і тому допускає використання в інших проектах.

Крім клієнта і точки обслуговування ПЕК, суб’єктами є:

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

Платіжна система схематично наведена на рис. 2. Розраховуючись у торговій точці за покупку або послугу, клієнт пред’являє ПЕК. Касир візуально (за зовнішнім виглядом ПЕК, фотографією, підписом клієнта), а також за допомогою POS-пристрою здійснює авторизацію картки, тобто визначає її придатність до платежу і наявність на картрахунку потрібної суми. Можливий голосовий запит у процесінговий центр. У разі позитивної авторизації оформляються платіжні документи і клієнт розписується у них. Далі за схемою, передбаченою платіжною системою, списується сума платежу і комісійних за обслуговування з картрахунку клієнта на користь торгової точки і банка.

Високі вимоги пред’являються до комутаційного центру, який має забезпечувати:

• відмовостійку роботу у будь-який час;
• високу продуктивність обробки потоку операцій (транзакцій);
• нарощуваність без перерви у роботі системи;
• відкритість протоколів взаємодії;
• захищеність транзакцій;
• простоту експлуатації і обслуговування:
• цілісність даних.

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

Банківські ПЕК найчастіше використовують для зняття готівки через банкомати або АТМ (automatic taller machine). Технологія проста: ПЕК вставляється в АТМ, запитується PIN-код і далі вибирається потрібна операція (зняття грошей, обмін валюти, довідка тощо). Розглянемо ПЗ банківської мережі (рис. 3), до складу якої входить центральний комп’ютер, що належить консорціуму банків, комп’ютери банків, до яких безпосередньо (обминаючи центральний комп’ютер) приєднані касові термінали, що обслуговуються касирами, і мережа терміналів для клієнтів банку (банкоматів).

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

Проводка – це узгоджена зміна даних на рахунках клієнта і звітної документації банка, що зберігаються у БД банка за даними проводки. Проводка включає перевірку права клієнта на доступ до його рахунків на момент проводки (перевірка безпеки) і перевірку відповідності суми, що вимагається клієнтом, поточному стану його рахунка. Якщо перевірки пройшли успішно, клієнт отримує з ATM потрібну суму грошей і квитанцію, інакше він отримує тільки квитанцію. Під час проводки можуть трапитися збої у роботі апаратури чи клієнт роздумає отримувати гроші і відмінить вже розпочату проводку. Тоді всі рахунки і звітні документи мають відновитися у тому стані, в якому вони були до початку проводки. Для реалізації відкочування використовується служба ведення записів про зміни, що вносяться у БД банка, коли виконується проводка. Усі дії, пов’язані з виконанням проводки (зокрема протоколювання і підтримка безпеки проводки), здійснюються ПЗ системи управління банківською мережею.

Комп’ютер банку підтримує рахунки клієнтів, тобто зберігає їх у своїй БД і виконує над ними проводки за запитами з ATM (віддалена проводка) або з касових терміналів (проводка касира банку).

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

[25] Віртуальний магазин для роздрібної торгівлі в WWW-мережі

Віртуальний магазин (скорочено Web-магазин) – це окремий Web-сайт невеликої фірми або цілий Web-вузол WWW-мережі для універмагів, супермаркетів чи мережі торгівельних закладів. У Web-магазині є каталог товарів, візок покупця, засоби оплати. Web-вузол треба якісно проектувати i забезпечувати легкий доступ, простоту здійснення операцій закупівлі та продажу, основою чого є використання потужного серверу i надійних елементів зв'язку. Головна задача Web-вузла – потужна реклама товарів та послуг у вітринах і на розкладках, для чого використовується розмаїття програмістських прийомів образно-графічного і текстового подання інформації.
Персоналiзацiя клієнтів Web-магазину обов’язкова. Клієнт може безпосередньо реєструватися на багатьох вузлах або через заповнену анкету особистих інтересів його проводять до частин вузла, до яких він виявив інтерес.
Спілкування лояльне до клієнтів, які підключаються в реальному часі; їхня цінність для компанії зростає, якщо вони мають змогу приєднатися до якоїсь групи людей з однаковим способом мислення. Web-вузол влаштовує для покупців привабливі віртуальні розкладки товару, для чого залучаються цікаві новітні способи із звуковими ефектами, мультиплікацією та образною графікою.
Заохочування покупців купувати більше i заходити частіше – це стратегія Web-магазину. Зазвичай для цього використовуються купони, знижки, спеціальні пропозиції та ваучери на інші Web-послуги. На деяких вузлах налаштовані електронні гаманці, до яких можна складати купони на майбутнє, чеки та інформацію про кредитну картку. Перебуваючи в ролі відвідувача Web-магазину, клієнт має впевнитися, що його кредитна картка, особиста інформація i подробиці торгівельних операцій надійно захищені щодо уникнення несанкціонованого використання.
Відносини з іншими підприємствами, необхідні для виробництва i продажу товару, складають мережу бізнесових зв’язків у системі постачань. З впровадженням обміну електронними даними, зокрема з обов’язковим штрихкодуванням продукції, реорганізовано i раціоналізовано процеси традиційної системи постачань. Сучасна управлінська концепція поєднує процеси керування системою постачань і має на меті:

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

[26] Захист і безпека електронної комерції

Основні заходи ЕК-безпеки містять:

1. шифрування (скремблювання) даних, якими обмінюються клієнт i продавець;
2. шифрування інформаційного обміну між клієнтом та компанією стосовно проведення операції з використанням кредитної картки;
3. доступ до секретної інформації у автономному (off-line) режимі.

Щодо електронної комерції відомі такі методи забезпечення безпеки.
Протокол захищених сокетiв (SSL) автоматично шифрує дані, якими обмінюються Web-браузер клієнта i сервер торгівельної компанії. Електронний гаманець потребує додавання програм безпеки до Web-браузера, яким користується клієнт. Після цього Web-браузер може шифрувати дані про кредитну картку клієнта таким чином, що їх бачитиме тільки банк, який за запитом торгівельного агента затверджує операцію клієнта з використанням цієї картки.
Безпечна електронна операція (SET) вимагає, щоб відповідна програма зашифрувала електронний конверт електронних посвідчень, в яких вказується подробиці щодо кожної операції закупівлі товару.
Оф­лайн-метод ще безпечніший, тому що клієнт, скориставшись безкош­товним дзвінком, відкриває рахунок, який міститиме інформацію про кре­дит­ну картку та електронну адресу. Відтепер кожного разу перед затверд­женням i здійсненням операції клієнту надішлють запит електрон­ною поштою, чи він згоден сплатити за певний товар або послугу.
Системи мікроплатежів застосовуються для створення елект­ронних грошей або жетонів, так званої електронної готівки для платежів, які занадто малі для операцій із кредитною карткою. Генеруються ряди даних, які обробляються з використанням певних методів шифрування та засвідчення особи покупця; в подальшому ця інформація використо­вується як звичайні гроші для невеликих виплат готівкою. Iнтернет і інформаційна безпека несумісні за самою природою цієї мережі. Народившись як чисто корпоративна мережа, у наш час за допомогою стека протоколів TCP/IP і єдиного адресного простору Iнтернет об'єднує не тільки корпоративні і відомчі мережі (освітні, державні, комерційні, військові), що за визначенням є мережами з обмеженим доступом, але і звичайних користувачів, що мають змогу одержати прямий доступ у Iнтернет із своїх домашніх комп'ютерів за допомогою модемів і телефонної мережі.
Існує три типи обмеження прав доступу користувача.

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

Обмеження за ім'ям користувача і паролем. Важливий засіб безпеки – паролі. Перед отриманням доступу до інформаційних ресурсів користувач має ідентифікувати себе передаючи своє ім’я та пароль. Програма автентифікації перевіряє, чи є в локальній базі користувачів відповідний запис, і коли такий запис відшукується, користувач отримує доступ до інформаційних ресурсів, інакше йому буде відмовлено. База даних про дозволених користувачів розміщується локально (на тому самому комп'ютері, до якого звертається користувач), тому зрозуміло, що ця база (у багатьох випадках це просто один файл) зберігається у зашифрованому вигляді.
Існує велика кількість різних методів шифрування цих файлів, кожний з який має власний набір характеристик. Наприклад, у Unix здебільшого використовують односторонній DES-алгоритм шифрування (Data Encription Standard) для шифрування паролів, що потім зберігаються зазвичай у файлі /etc/passwd або рідше у /etc/shadow. Коли користувач намагається зареєструватися, усе, що він набирає, знову шифрується і порівнюється з вмістом файлу, у якому зберігаються паролі. Хоча DES є двостороннім (можна закодувати, а потім розкодувати повідомлення, даючи вірний ключ), здебільшого використовують односторонній варіант. Це означає, що неможливо на підставі вмісту файлу /etc/passwd (або /etc/shadow) провести розшифрування для одержання паролів.

Шифрування з використанням відкритого ключа здійснюється шляхом кодування тексту. У традиційних системах шифрування один і той самий ключ використовується для шифрування і розшифрування тексту. У сучасних системах із відкритим ключем (асиметричних) використовуються парні ключі: один для шифрування, інший – для розшифровування повідомлення. У такій системі кожний володіє унікальною парою ключів. Один відкритий ключ (public key) поширюється і використовується для кодування повідомлень. Інший особистий ключ (private key) зберігається як таємниця і використовується для розшифрування повідомлень, що надходять. При такій системі сторона, що посилає повідомлення, може закодувати його за допомогою відкритого ключа, що належить адресату. Таке повідомлення можна розшифрувати тільки тому, хто має секретний ключ, що запобігає розшифруванню при перехопленні. Така ж система використовується для створення електронних підписів.

Системи шифрування в Інтернет здебільшого використовують комбінацію сучасної асимет­ричної і традиційної симетричної систем шифрування. Шифрування з відкритим ключем використо­ву­ється для передачі симетричного ключа, що використовується при шифруванні переданої інформації. Оскільки корпорації відчувають гостру потребу у безпечній передачі даних, активно розробляються схеми шифрування даних для передачі між браузером і сервером. Запропоновані стандарти SSL, SHTTP для шифрування даних і перевірки користувача Web-публікацій. Кожен з них потребує для роботи поєднання підтримуючих його браузера і серверу, і тому поки що жодний з них не є універсальним розв'язком проблеми безпечної передачі даних. Протокол SSL (Secure Socket Layer) компанія Netscape Communications запропонувала як схему шифрування на низькому рівні в разі кодування транзакцій протоколів вищого рівня HTTP, NNTP і FTP. Протокол SSL підтримує перевірку серверу (підтвердження ідентичності сервера для клієнта), шифрування даних при передачі і можливість перевірки клієнта (підтвердження автентичності клієнта для сервера). Зараз SSL реалізований у різноманітних браузерах (наприклад, Secure Mosaic і MS Internet Explorer). Деталі див. за адресою: http://home.netscope.com/newsref/std/SSL.htm/ Схема SHTTP (Secure HTTP) запропонована CommerceNet’s, як протокол вищого рівня працює тільки з HTTP і поширеніша за SSL. Деталі див. http://www.eit/com/creations/s-http/ Стандарт шифрування S/MIME (Secure /Multipurpose Internet Mail Extension) використовується в електронній пошті та інших типах Інтернет-повідомлень (див. http://home/netscape.com/assist/security/smime/overview.htm/ ).
Програми SSH і stelnet дозволяють зареєструватися на віддаленому сервері і мати шифроване з'єднання; використовуються з криптографією відкритого ключа для шифрування з'єднання між двома комп’ютерами, а також для автентифікації користувачів; див.: http://www.cs.hut.fi/ssh

[39] Роль сучасних інформаційних систем у різних сферах діяльності. Підприємство з міжмережною структурою. Кіберкорпорація та її стратегічна перевага.

[40] Інформаційні технології та глобалізація діяльності. Реорганізація ділових процесів під впливом ІТ та досягнення конкурентної переваги.

[41] Атрибути інформаційної якості ІТ.

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

Фактор часу. У бізнесі вчасність подачі інформації становить критичний елемент. Вона достовірна, точна та актуальна тільки протягом певного періоду часу. Згідно з цим ІС має розроблятися так, щоб забезпечувати інформацію щодо одного або кількох часових вимірів: доповідь за вимогою (коли інформація потребується), виняткова доповідь (коли виникають певні умови) або періодична доповідь (через регулярні інтервали часу).

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

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

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

[43-44] Класифікація ІС для операцій та менеджменту.

Класифікація ІС для операцій та менеджменту здійснюється за типом підтримки, яку вони забезпечують корпорації:
1. Системи забезпечення операцій,
1.1.Системи обробки операцій (СОО),
1.2. Автоматизовані системи управління технологічними процесами (АСУТП),
1.3. Системи співробітництва на підприємстві (ССП),
2. Системи забезпечення менеджменту,
2.1. Інформаційні менеджерські системи (ІМС),
2.2. Системи забезпечення прийняття рішень (СЗПР),
2.3. Управлінські інформаційні системи (УІС), насамперед з правничих знань.

1. Системи забезпечення операцій обробляють дані, які генеруються i використовуються у бізнес-операціях, і відіграють важливу роль у таких трьох галузях.

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

2. Системи забезпечення менеджменту допомагають менеджерам у прийнятті рішень і розподіляються на три види:

• IМС як система менеджменту виробляє звіти заздалегідь визначеної тематики, періодично або за запитом подає дані та результати вжитих заходів.
• УIС має додаткові можливості для керівництва: аналіз даних, електронна пошта та інструменти підвищення продуктивності праці.
• СЗПР використовує моделі прийняття рішення, базу даних i особисті міркування особи для інтерактив¬ного аналізу, забезпечує моделювання правил і стратегії бізнесу та інтелектуальний доступ до неструктурованої інформації, ґрунтуючись на технологіях штучного інтелекту з двома різновидами виведення, заснованого на правилах і прецедентах (за аналогією).

[45] Види інтелектуальних консультантів.

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

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

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

Інформаційні консультанти. Пошукові консультанти допомагають користувачу знайти файли та БД, відшукати інформацію, пропонують нові типи інформаційного продукту, мультимедiйнi засоби, а також ресурси. Інформаційні брокери надають комерційні послуги, щоб знайти та розробити інформаційні ресурси, які підходять для бізнесу або задовольняють особисті потреби користувача. Фільтрувальники отримують, знаходять, фільтрують, відкидають непотрібне, зберіга-ють, спрямовують інформацію, а також повідомляють користувачів про отримані або бажані комп’ютерні послуги.

[48] Засоби та заходи підтримки електронного офісу.

[50] АРМи та корпоративні інформаційні системи

[53] Цикл розробки КІС. Фактори дослідження КІС на підприємстві. Сфери системного аналізу КІС.

[54] Задача концептуального моделювання предметних областей. Три джерела знань про предметну область

[58] Каскадна модель життєвого циклу програмної системи

[63] Прототипування за спіральною моделлю життєвого циклу

[70] Етапи створення корпоративних ІС. Методи обстеження та проектування концептуальної моделі.

[73,75,78] Семантична мережа. Види вершин-понять та дуг-відношень. Фрейми, ієрархії, процедурні допо-внення.

[82] ER-модель «сутність-зв’язок».

[86] Порівняння семантичних мереж і ER-моделей як концептуальних моделей.

[88] Чотири фази накопичення (надбання) знань. Задачі надбання знань.

[90] Схема надбання знань за моделями правил.

[92-95] Задача поновлення правил із дослідних даних та алгоритми навчання на прикладах

[28] Способи добування фахового досвіду.

[29] Класифікація методів добування знань від експертів (прямі та непрямі).

[110] Одинадцять рекомендацій щодо вибору механізмів розв’язання задач стосовно способів абстрагування та методів дослідження простору рішень у різних ПрО.

[116] Парні та множинні порівняння як методи одержання якісних оцінок

[118] Ранжування, гіпервпорядкування, вектори переваг, класифікація як методи одержання якісних оцінок

[119-121] Методи кількісного оцінювання (безпосередня числова оцінка та метод Чорчмена-Акофа)

[122] Добування колективного досвіду у експертному аналізі. Проблема компетентності експертів. Метод комісії. Метод суду. Мозкова атака. Метод Делфі. Розв’язувальні матриці Г.Поспелова.

[126] Порівняння прогнозного графу В.Глушкова та систем ПАТТЕРН і ПРОФАЙЛ; ПЕРТ, ГЕРТ і МКШ.

[156] Формула повного подання объекта в OMT. Приклади об’єктів.

[160] Залежності між класами (відношення БД). Характеристики залежностей.

[164] Агрегація як відношення ціле-частина. Узагальнення підклас-суперклас. Абстрактні класи.

Агрегація

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

Важлива властивість агрегації - транзитивність: якщо A є частиною B, а B є частиною C, то A є частиною C. Рис. 6.14 показує, що документ складається з кількох речень. Відно­шення агрегації антисиметричне: якщо A є частиною B, то B не є частиною A. Частину властивос­тей цілого можна перенести і на його частини, можливо, із несуттєвими змінами. Наприклад, контекст кожного оператора деякої функції збігається з внутрішнім контекстом усієї функції.

Агрегація (1)

Узагальнення і спадкування

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

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

Іноді в підкласі необхідно перевизначити операцію, визначену в одному з його суперкласів. Для цього операція, яку можна одержати із суперкласу в результаті спадкування, визначається й у підкласі. Таке повторне визначення "заступає" визначення операції в суперкласі, так що в підкласі застосовується не успадкована, а перевизначена в ньому операція. Нагадаємо, що кожна операція визначається своєю сигнатурою; отже, сигнатура перевизначення операції повинна збігатися із сигнатурою операції із суперкласу, що довизначається цією операцією. Так, у прикладі на рисунку у класі персональний_комп'ютер можна для зручності перевизначити операцію звертання до рахунку клієнта суперкласу касовий_термінал.

Крім зручності, перевизначення може переслідувати одну з цілей:

• розширення; нова операція розширює успадковану з огляду на вплив атрибутів підкласу;
• обмеження; нова операція обмежується виконанням лише частини дій успадкованої операції, використовуючи специфіку об'єктів підкласу;
• оптимізація; із використанням специфіки об'єктів підкласу спрощується і пришвидшується відповідний метод. Наприклад, перевизначивши операцію max класу IntegerSet у його підкласі SortedIntegerSet, можна спростити її, використовуючи упорядковані множини.

Доцільно дотримуватися семантичних правил спадкування, які рідко підтримуються ОО-мовами програмування:

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

Абстрактні класи

На цьому малюнку розглянута операція підрахунок_виплат щодо категорій службовців: тимчасових із погодинною оплатою праці, постійних із потижневою оплатою і керівників. Кожна категорія служ­бов­ців подана своїм підкласом класу служить, від якого вони успадковують атрибут річний_при­буток і операцію підра­хунок_ви­плат. Але підрахунок виплат для кожної категорії службовців прова­дить­ся з урахуванням значень їх власних (неуспадкованих) атрибу­тів; тому в кожному з підкласів операція підрахунок_виплат перевизначається. Отже, у суперкласі операція підрахунок_виплат може визначатися довільно, оскільки ніколи не виконується. У той же час сигнатури всіх операцій підрахунок_виплат у суперкласі й у підкласах повинні бути однаковими (інакше це будуть різні операції). Отже, у суперкласі можна задати тільки сигнатуру операції підрахунок_виплат, це забезпечить однакові сигнатури цієї операції у всіх підкласах. Методи реалізації операції підрахунок_виплат достатньо визначити тільки в підкласах класу службовець.

Суперклас, у якому задані тільки атрибути і сигнатури опера­цій, але не визначені методи, що реалізують його операції, зветься абстрактним класом. Методи реа­лі­за­ції операцій абстрактного кла­су визначаються в його підкласах, що звуться конкретними класами.

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

[164] Спадкування суперклас-підклас. Множинне Спадкування

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

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

У множинному спад­ку­ванні від класів, що не пере­ти­наються, на рис. 6.19 влас­тивості, успадко­ва­ні від різ­них предків, доповнюють одна одну. Вкладене просте спад­кування показане на рис. 6.20, делегування з агрегацією ролей – на рис. 6.21. Делегу­ванням зветь­ся механізм реалі­за­ції, коли об'єкт, відповідаль­ний за операцію, пересилає (делегує) цю операцію іншому об'єкту. У ОО-мовах делегуван­ня реалізується через приєд­нання методів безпосе­ред­ньо до об'єктів, а не до класів. На рис. 6.21 операції класів опла­та_праці і пенсійне_забезпе­чення делегуються об'єктам класу служ­бо­вець, що можна розглядати як результат агрегації класів опла­та_праці і пенсійне_забезпечення.

Інший спосіб делегування для множинного спадкування пока­за­ний на рис. 6.22. Тут супер­клас, найбільш суттєвий за передачею своїх властивостей, залишається єдиним суперкла­сом аналізованого підкласу, а властивості інших суперкласів делегуються об'єктам цього підкласу. Щодо вибору способу заміни множинного спадкування керуються такими правилами: якщо підклас має кілька суттєвих суперкласів, доцільне делегування (рис. 6.21);

• якщо найбільш суттєвим є тільки один із суперкласів, а інші не так важливі, краще реалізувати множинне спадкування через прос­те спадкування і делегування (рис. 6.22);
• якщо число можливих комбі­націй груп властивостей, що успадкову­ються, невелике, можна використову­вати вкладене просте спадкування (рис. 6.20); у випадку великого числа комбінацій цей засіб не рекомендується;
• якщо один із суперкласів пере­дає підкласу більше число властивостей за інші, варто зберегти спадкування цим шляхом (рис. 6.20 і 6.22);
• якщо необхідне вкладене просте спадкування, то на перший рівень вкладеності поміщається найбільш суттєвий за передачею властивостей суперклас, потім найбільш суттєвий із суперкласів, що залишилися, і т.д. ; варто уникати вкладеного простого спадкування (рис. 6.20), якщо це веде до дублювання достатньо великих частин програми;
• варто пам'ятати, що тільки вкладене просте спадкування (рис. 6.20) забезпечує повну тотожність множинному спадкуванню.

[169] Співвідношення між об’єктами у ОМТ та базами даних. Метадані, тиражування екземплярів, ключі об’єктів або залежностей, обмеження, похідні об’єкти, зв’язки, атрибути

[173] Етапи побудови об’єктної моделі.

Процес побудови об'єктної моделі включає етапи:

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

Визначення класів

Аналіз зовнішніх вимог до проектованої системи дозволяє визначити об'єкти і класи об'єктів, пов'язані з ПрО.

Всі класи мають інтерпретацію у цій ПрО;

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

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

Далі список можливих класів має аналізуватися з метою видалення з нього непотрібних класів. Такими класами є:

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

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

Підготовка словника даних

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

Визначення залежностей

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

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

Потім варто викинути непотрібні або неправильні залежності за такими критеріями:

• залежності між виключеними класами треба викинути або переформулювати в термінах класів, що залишилися;
• нерелевантні залежності і залежності, що пов'язані з реалізацією, треба викинути;
• щодо дій залежність повинна описувати структурні властивості ПрО, а не малосуттєві;
• щодо тернарних залежностей: велику частину залежностей між трьома або більшим числом класів можна розкласти на декілька бінарних залежностей, використовуючи в разі потреби кваліфікатори. Зрідка таке розкладання здійснити не вдається. Так, тернарну залежність Професор читає курс в аудиторії 628 неможливо розкласти на бінарні без втрати інформації;
• щодо похідних залежностей: треба виключити залежності, які можна висловити через інші, через їхню надмірність. У разі викидання надлишкових (похідних) залежностей потрібна обережність, оскільки не всі надлишкові залежності між класами дублюють одна одну.

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

Викинувши надлишкові залежності, слід уточнити семантику залежностей, що залишилися:

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

Уточнення атрибутів

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

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

Щодо уточнення атрибутів зважають на такі критерії.

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

• Кваліфікатори. Якщо значення атрибута залежить від конкретного контексту, його варто зробити кваліфікатором.

• Імена. Іменам зазвичай краще відповідають кваліфікатори, ніж атрибути об'єктів; якщо ім'я дозволяє зробити вибір з об'єктів певної множини, його варто зробити кваліфікатором.

• Ідентифікатори об'єктів пов'язані з їхньою реалізацією. На ранніх стадіях проектування їх не варто розглядати як атрибути.

• Атрибути зв'язків. Якщо певна властивість характеризує не об'єкт, а його зв'язок з іншим об'єктом (об'єктами), те це - атрибут зв'язку, а не атрибут об'єкта.

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

• Несуттєві деталі. Атрибути, що не впливають на виконання більшої частини операцій, рекомендується опустити.

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

Подальше дослідження й удосконалювання моделі

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

Ознаки пропущеного об'єкта (класу):

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

Ознаки непотрібного (зайвого) класу - недостача атрибутів, операцій і залежностей у певного класу; для виправлення помилки необхідно подумати про вилучення такого класу.

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

Ознаки непотрібних (зайвих) залежностей :

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

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

Ознаки неправильного розміщення атрибутів. Немає потреби доступу до об'єкта за значен­нями одного з атрибутів; для виправлення помилки слід розглянути, чи потрібна ця залежність.

[187] Динамічна модель. Події, сценарії та траси подій

[190] Стани та діаграми станів. Умови, активності та дії, синхронізація дій у динамічній моделі

[194] Діаграми потоків даних (функціональна .модель). Процеси, потоки даних, активні об’єкти (акто-ри), сховища даних, потоки управління

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

[198] Сім рівнів OSI-моделі взаємодії відкритих систем. Протокол як сутність телекомунікації.

[223] Риси відкритих систем щодо розподіленої обробки: незалежність від постачальника, мобіль-ність, інтероперабельність

48. Системи на основі WWW-мереж. Веб-сервер, веб-броузер, гипертекстові та гипермедійні БД

[227] Корпоративні мережі Інтранет/Екстранет. Web-браузери та сервери, система протоколів TCP/IP, Web-публікації, гипермедiйне відображення HTML-документів i баз даних

50. Співставлення двох технологій розподіленого обробки клієнт-серверної архітектури на основі OSI-моделі та TCP/IP.

51. Поняття дволанкових, триланкових та багатоланкових розподілених застосувань клієнт-серверної архітектури.

[231] Сервери у мережах: сервер телекомунікацій, сервер застосувань, диско-сервер, файл-сервер, сервер баз даних, принт-сервер

[233] Види розподіленої обробки: однорангова мережна, централізована і кооперативна обробка, обслуговування черги повідомлень

[232-234] Взаємодія компонентів розподілених засто¬су¬¬вань. Виклик віддалених процедур (RРС). Відси-лання запита (request раssing) для вико¬нан¬ня методів. Роль стандарту СОRВА.

[236] Виклик віддалених процедур. Взаємодія через інтерфейс на мовах RРС, АРІ, ІDL.

[237] Задача маршалінгу розподілених застосувань.

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

58. Моделі архітектури клієнт-сервер: сервер баз даних та сервер застосувань.

[246] Сервер БД. Взаємодія між клієнтськими і серверними частинами. Протокол віддаленого виклику процедур. Типовий розподіл функцій між клієнтами і серверами. Розподілена компіляція запитів. Іменування об’єктів і розподілений каталог. Резервне копіювання (тіньовий сервер).

[261] Сервери корпоративних БД – сервери робочих груп. Застосування робочих груп (календар, потік робіт, розклад, електронний документообіг). Організація сумісних робіт, різновиди електронних конференцій.

61. Сервери корпоративних БД – сервери робочих груп. Прикладні сервіси для застосувань клієнт-серверної архітектури; комунікаційні сервери (віддалений доступ і маршрутизація); Iнтернет; доступ до розподіленої інформації; сервіс локальних мереж (розподіл файлів/ принтерів); управління системою/ дистанційне управління; електронна пошта.

[264] Оцінка завантаження сервера. Тести ТРС.

[269] Обробка даних у сховищах (Data Warehоuse). Типи БД: оперативні, аналітичні, виділені, зовнішні бази даних, інформаційні сховища та бази даних кінцевих користувачів.

64. Оперативні ІС з режимом OLTP. Аналітичні ІС та ОLAP-технологія у системах забезпечення прийняття рішень (СЗПР).

65. Типи сховищ даних: віртуальне, централізоване, розподілене. Data mart або "інформаційна віт-рина".

66. Родові ознаки DW (за Інмоном). Орієнтація на об’єкти. Інтегральність та інваріантність даних. Стабільність інформації

67. Три етапи добування даних для DW.

68. Етапи побудови DW. Стратегічний аналіз. Розробка плану реалізації проекту. Побудова моделі даних DW. Оцінка і вибір засобів побудови DW. Експлуатація готової системи.

[282] Типи закономірностей Data Mining’а: асоціація (близькість), послідовність дій, класифікація, кла-стеризація, прогнозування

[284] DM-методи: виведення правил асоціації, нейронні мережі, дерева рішень, k-найближчий окіл, комітетні та генетичні алгоритми, візуалізація даних

[290] Успішні приклади OLAP & Data Mining.

Data Mining ідентифікує і характеризує взаємозв’язки у багатовимірних (складених з множини змінних/атрибутів) даних.

Пошук інформації не вимагає від користувача фор­мування спеціальних запитів. Комп’ютер шукає тренд і кореляції по всьому рядку [реляційної таблиці] і відмічає некорисну та потенційно важливу інфор­ма­цію. Оскільки Data Mi­ning знаходить невідому інформацію і правила, а не доводить чи відки­дає гіпотези, він становить засіб дослідження даних.

OLAP використовується для перевірки таких складних, побудо­ва­­них людиною чи комп’ютером гіпотез на множині

вимірів DW (не біль­ше 3-4 реляційних відношень), як: "Який був продаж щодо плану по міся­цях і областях на протязі останніх трьох років". Результат OLAP - інфор­ма­ційний звіт-огляд у вигляді таблиць або діаграм. Звіти OLAP не від­міча­ють незвичні взаємозв’язки. Аналогічно конкретним запитам, OLAP – метод перевірки знань, скоріше засіб верифікації, ніж пошуку даних.

Data Mining може проводитися окремо від вихідної БД після добування цільового набору даних (extract) чи безпосередньо у середовищі СКБД (non-extract). Ідея невиділення (non-extract) полягає у тому, що багато задач Data Mining (відбір, зразки, агрегація, піктограми, де/кодування, трансформація, денормализація і чистка даних) працюють у самих СКБД і мають такі переваги:

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

На думку Алана Паллера з Data Warehousing Institute, керування DW стане простішим завдяки вдосконалення OLАP-технології, яка за­без­печує вибірку даних зі сховищ. OLАP-системи зберігають у багатови­мірних БД зарані сформовані відповіді на тисячі питань. Якщо на запит є готові відповідь, то вона обробляється миттєво, інакше система реагує повільніше. Тому аналітики вважають за перспективні нові ROLAP-засоби реляційної оперативної аналітичної обробки, які на відміну від OLAP не зберігають інформацію у спеціальній багатовимірній БД, а дозволяють використовувати для цього стандартну реляційну СКБД з такими її можливостями, як резервне копіювання і відновлення, захист даних, засоби доступу. ROLAP-продукти за продуктивністю досягли рівня популярних OLAP-систем (Essbase фірми Arbor, IRI Express компанії Oracle, SAS/Application Facility от SAS Institute). Це передусім Axsys компанії Information Advantage, DSS/Server фірми MicroStrategy, ProdeaBeacon Server от Prodea і MetaCube виробництва Informix.

[291] OLAP & Data Mining. Співставлення можливостей на прикладі однієї задачі.

Основна відміна і основна проблема OLAP і Data Mining легко вба­ча­ються на прикладі розв’язання будь-якої задачі. Нехай існує таблиця Товар/Колір/Партія/Прибуток. Треба з’ясувати, що впливає на Прибуток.

Основні кроки Data Mining полягають у наступному.

1) Вибираємо рядок таблиці, де Прибуток високий.

2) Оцінюємо всі стовпчики таблиці щодо серед­нього значення і варіації. Наприклад, у цій групі сильніше всього виражено Колір = Синій і Партія > 1000. Це наша гіпотеза.

3)Перевіряємо по всій таблиці, що це сполу­чен­ня веде скоріше до прибутку, ніж до збитків.

Думаємо, що знайшли правильне сполучення.

Основні кроки OLAP такі.

1) Вибираємо апріорно 2-3 стовпчики таблиці, наприклад, Колір і Партія.

2) Будуємо розподіл прибутку по всій таблиці, згрупований за конкретними значеннями Колір/Партія. Отримуємо таблицю.

3) Аналізуємо таблицю, наприклад, вибираємо максимум прибутку.

Думаємо, що знайшли правильне сполучення Кольору і Партії.

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

[318] Типи інтерфейсів Еталонної моделі POSIX-OSE: API та EEI. Категорії служб POSIX-OSE.

74. Цільові установки POSIX-OSE. Інтероперабельність; мобільність (даних, користувача, приклад-них програм); узгодженість зі стандартами; узгодженість з новими технологіями ІС; розширюва-ність прикладної платформи; розширюваність розподілених систем; прозорість реалізації; функ-ціональність вимог користувача.

75. Переваги POSIX-OSE: інтеграція компонентів від множини постачальників; ефективна розробка і реалізація; раціональне перенесення прикладних програм

76. Еталонна модель POSIX-OSE. Інтерфейси типу EEI: людина/ комп’ютер HCI; інформаційних служб ISI; комунікаційних служб CSI. Категорії служб POSIX-OSE.

[325] Еталонна модель служби мовної підтримки POSIX-OSE.

[332] Еталонна модель служби Системного ядра POSIX-OSE

[341] Еталонна модель комунікаційних служб POSIX-OSE

[351] Еталонна модель служби підтримка баз даних POSIX-OSE

[363] Еталонна модель служби обміну даними POSIX-OSE

[369] Еталонна модель служби обробки транзакцій POSIX-OSE

[375] Еталонна модель служби командного інтерфейсу користувача POSIX-OSE

[379] Еталонна модель служби символьно-орієнтованого інтерфейсу користувача POSIX-OSE

[382] Еталонна модель служби поліекранного відображення POSIX-OSE

Система керування поліекранним відображенням

Керування поліекранним відображенням (служба віконних систем – Windowing System Services) – сучасний засіб прямої взаємодії з користувачем. Донедавна більшість ОС інтерпретували команди, що вводилися з клавіатури алфавітно-цифрового терміналу. Лише CAD/CAM -застосування завжди підтримували інтерфейс користувача за допомогою меню чи візуальних командах, планшетів і світлових пер. Доступність дешевих растрових графічних станцій і ПК призвела до швидкого поширення графічного інтерфейсу користувача GUI, технологій віконної обробки, групових команд (наприклад, file, save, save as, new) і методів вибору за допомогою миші, кульки керування (track ball), планшета (tablet) тощо. Для цих технологій з'явилися де-факто стандарти, що зафіксували вимоги корис­тувачів і виробників щодо ба­зо­вого подання та пове­дінки графічних поліекран­них систем для різних платформ.

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

Стандарти інтерфейсу графічних віконних систем покривають широку область у межах від розкладки клавіатур до керування екраном:

• протоколи для керування поліекранним відображенням (вікнами) на локальному чи віддаленому пристрої відображення;
• API для визначених протоколів;
• керування графічними віконними системами з визначеною підмножиною "look and feel"; тобто вид, позиціонування екрану і поведінка об'єктів усередині вікон на графічному екрані;
• API-специфікації відповідних мовних прив'язок і відображення, маніпулювання і керування взаємодіючими об'єктами усередині вікон;
• інтерфейс командної мови, що забезпечує користувацький ввід-вивід в інтерактивному режимі чи одержання із збереженої процедури;
• API-специфікації і мовні прив'язки для підтримки символьних (нерастрових) терміналів, трансляції, маніпулювання і керування командними інструкціями (чи повідомленнями).

Еталонна модель віконної системи

Об'єкти та інтерфейс приклад­ної програми, що використовує графічну віконну систему, зображені на рис. 9.18.

EEI стосується взаємодії користувача через фізичні пристрої графічної віконної системи (клавіатура, миша, екран дисплея тощо) і мобільності даних для різних прикладних платформ. Робоча група IEEE P1201.2 визначила мінімальний набір спільних рис графічних віконних систем, що усувають такі проблеми:

• помилки, що викли­кають несумісність;
• неправильна обробка (сприйняття) резуль­татів дій користувача;
• несумісність у моделі користувача високого рівня категорій або метафор;
• зайві ускладнення або численні рухи руки.

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

API стосується відображення семантики застосування у графічній віконній системі і визначений насамперед як інтерфейс між прикладним ПЗ і прикладною платформою, на підтримку мобільності застосування. Сервіс забезпечують функції для створення і маніпулювання візуальними відображуваними об'єктами типу меню, кнопок (buttons), смуг прокручування і діалогових вікон (dialog boxes). Через ці функції інформація про дії користувача (тобто події) передається до прикладного ПЗ; наприклад, при виборі користувачем елемента меню. Іншими словами, основний цикл подій - зв'язок з діалоговим вікном прикладної програми, тобто вікном, яке чекає на вибір користувача і щодо якого застосування викликає для виконання необхідну операцію.

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

Елементи прикладного ПЗ обслуговуються такими об’єктами прикладної платформи.

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

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

• зміна розмірів вікна і зменшення візуального подання вікна до піктограми чи іконки;
• переміщення вікна і розташування/виштовхування вікна поверх/униз вікон;
• звуковий чи відео ввід-вивід;
• підтримка безпеки.

Робочий стіл (Desktop) чи графічна оболонка віконної системи – це візуальний аналог POSIX-оболонки або специфікація робочої поверхні графічної віконної системи. Робочий стіл надає користувачу візуальний інтерфейс до ресурсів системи типу пристроїв, файлів та методів запуску застосувань та до часто використовуваних утиліт (календар, записник тощо).

Локальні і віддалені застосування (Local and Remote Applications) – це клієнти, яким надаються послуги для виконання специфічних задач користувача.

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

Сервіс API

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

Основні віконні послуги (Basic Window Services) можуть викликатися з клієнтських застосувань з інтерфейсом користувача, що ґрунтується на віконній системі за моделлю клієнт-сервер. Головні функції:

• керування вікнами і робочим столом;
• обробка подій і помилок;
• комунікації між клієнтами;
• керування пристроями вводу даних: клавіатура, координатно-вказівний пристрій;
• керування екраном і підключенням сервера;
• керування пріоритетами (привілеями) користувача.

Наступні функції доступні з кожної перерахованої функції.

Керування вікнами передбачає:

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

Керування робочим столом передбачає:

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

Обробка подій (Event Handling) потрібна скоріше для підтримки відповідей прикладної програми на дії користувача, ніж примусу користувача до відповідей прикладній програмі у жорсткій, послідовній манері. Тому програма має вибирати одну з альтернатив:

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

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

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

Обробка помилок (Error Handling) здійснюється за допомогою функцій:

• одержання повідомлення про помилки;
• одержання опису помилки;
• установка стандартної програми обробки події помилки.

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

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

Функції для зв'язку між клієнтами, включають:

• керування властивостями вікна (список, видалення, зміна, одержання);
• установка й одержання вибірки;
• керування буферами обміну (cut buffers).

Керування пристроями вводу даних включає:

• одержання вводу з клавіатури та подій через кнопки пристроїв позиціонування;
• одержання керування винятково клавіатурою чи курсором-покажчиком;
• відстеження курсору-покажчика;
• зміна відображення клавіатур на всіх серверах;
• установка й одержання пріоритетів клавіатури та пристроїв позиціонування.

Керування екраном (Screen Management) здійснюється за допомогою функцій:

• керування кольором через палітру (копіювання, зміна, установка, зняття, установка за промовчанням);
• одержання, відображення та керування відображенням растрових зображень (bitmapped screen images);
• збереження екрана (screen saver), тобто гасіння екрана у разі простою;
• відновлення відображуваної інформації (значення за промовчанням палітри кольорів, число площин відображення, ширина і висота екрану).

Керування пріоритетом користувача здійснюється через послуги та структури даних, що використовуються для керування пріоритетом (привілеями) користувача (User Preferences Management) за допомогою параметрів, що можуть зчитуватися та поєднуватися:

• значення за промовчанням, встановлені користувачем та збережені у властивостях адміністратора ресурсів користувача кореневого вікна;
• значення за промовчанням, встановлені користувачем та збережені у файлі, зазначеному користувачем за промовчанням;
• значення за промовчанням прикладних програм;
• параметри, обумовлені у разі запуску прикладної програми (наприклад, параметри командного рядка).

Для керування пріоритетом (привілеями) користувача доступні функції установки та одержання даних пріоритету (привілеїв).

Керування підключенням сервера здійснюється через:

• керування доступом до сервера (додавання/занесення комп'ютера до списку доступу ACL, блокування ACL);
• підключення/роз'єднання клієнта і сервера та відображень, керованих сервером;
• одержання інформації про реалізацію сервера;
• напрямок (Flush) буфера виводу на сервер та очікування обробки сервером усіх запитів у буфері виводу.

Сервіс віконного інструментарію (Toolkit Window Services) забезпечує механізм доступу до бібліотеки візуальних об'єктів безпосередньо під час виконання програми. Візуальний об'єкт – графічний об'єкт відображення (тобто об'єкт взаємодії) з пов'язаним ПЗ, що одержує введені дані від користувачів (зазвичай через клавіатуру та пристрій позиціонування) та пов'язаний з застосуванням і ПЗ інших візуальних об'єктів. Графічне подання візуального об'єкта може змінюватися для відображення результатів обробки застосування. Приклади візуальних об'єктів1 – графічні командні кнопки (push buttons), перемикачі (check boxes) та рядок вводу (editing boxes).

Послуги віконного інструментарію передбачені для:

• безпосереднього використання візуальної бібліотеки об'єктних модулів прикладним ПЗ;
• створення та додавання у «widget»-бібліотеку специфічних для прикладних програм візуальних об'єктів.

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

• ініціалізації/виходу з інструментарію;
• установки ресурсів візуальних об'єктів;
• створення/видалення візуальних об'єктів;
• відображення візуальних об'єктів;
• додавання/видалення специфічних для застосування стандартних програм, що викликаються візуальними об'єктами (подія зворотного виклику – callbacks);
• відновлення/зміни стану візуального об'єкта;
• переспрямування керування інструментарію для обробки вводу користувача.

ПЗ візуальних об'єктів може користуватися снрвіслм віконного інструментарію для:

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

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

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

• віконний сервіс надається для ініціалізації віконних послуг, створення і видалення вікна з визначеними зв'язаними візуальними об'єктами і маніпулювання курсором, щоб прикладна програма могла безпосередньо зв'язатися з користувачем через модальні (modal) чи немодельні (modeless) вікна;
• сервіс маніпулювання візуальними об'єктами надає послуги для звертання до розробленого застосування графічної віконної системи, для відображення визначених нею візуальних об'єктів і зіставлення їх із пов'язаними застосуваннями вводу-виводу;
• сервіс керування подіями надає послуги, що дозволяють застосуванні визначати набори подій і оброблювачі подій, що переключаються одним із двох способів:
  • чекати появи якоїсь події, обробляючи викликані події по одній з вхідної черги (керований подіями метод);
  • прикріплювати до кожної події функцію, автоматично виконувану у разі виклику події (метод зворотного виклику – callback).

Сервіс EEI

Підтримка EEI фактично стосується елементів, що фізично взаємодіють з користувачем:

• "look and feel" віконної системи забезпечує опис подання і поведінки візуальних об'єктів, визначення командної мови (синтаксис і семантика) і специфі­кації щодо клавіатури, пристроїв вибору, звукового і відео вводу-виводу;
• віконний інформаційний інтерфейс надає специфікацію форматів даних ресурсу користувача, що містять інформацію подання і дії, що стосується візуальних об'єктів відображення;
• протоколи мережного інтерфейсу обслуговують протоколи для транспортування даних, переважно нижніми шістьма рівнями OSI-моделі.

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

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

Стандарти, специфікації і недокументовані послуги

FIMS-система керування інтерфейсом відеоформ описана у розробленому Комітетом CODASYL ISO/IEC 11730:1994 для FIMS, який визначає інтерфейс між мовою програмування і будь-якою формою заміни застосування на екрані термінала чи комп'ютера.

ISO/IEC 9995:1994 у восьми частинах визначає розкладку клавіатури для текстових і офісних систем.

ISO 9241 у 17 частинах визначає ергономічні вимоги для офісної роботи з терміналами візуального відображення, зокрема з клавіатурою, відображенням, кольором і вимогами зручності та простоти використання.

ANSI-комітет розробив стандарти для процесу проектування, подання інформації, форм-базованих діалогів і віконної взаємодії.

Робоча група IEEE P1201.1 розробляє стандарти, що уніфікують API для GUI-застосувань, мобільних уздовж мультивіконних систем, та інструментарій інтерфейсів користувача виду OSF/Motif, Microsoft Windows, OS/2 Presentation Manager і Apple Macintosh.

Робоча група IEEE P1201.2 розробила набір рекомендацій з керування графічного інтерфейсу користувача з несуперечливими характеристики HCI, що забезпечують легкість переходу користувачів від одного "look and feel" прикладної платформи до іншого з мінімальним втручанням, помилками, незручностями, перенавчанням і перекваліфікацією.

Загальні специфікації – це де-факто стандарти віконних систем. Під егідою Консорціуму X разом з X/Open розроблені X-протокол обробки вікон у X Window, Xlib-специфікації функціонального інтерфейсу та інструментарію X Toolkit. Віконна системаX Window, заснована на мережній обробці двовимірної (2-D) графіки, використовує модель клієнт-сервер. Клієнт і сервер можуть розташовуватися на одній або різних платформах. Клієнт як прикладна програма виконується десь у мережі і підтримується звертанням до Xlib-бібліотеки для генерації X-протоколів, які приймає X-сервер і обробляє для відображення. X-протокол визначає кодування потоку даних між сервером і клієнтом як стандартний інтерфейс застосувань, що функціонують у розподіленому гетерогенному чи нерозподіленому середовищі. Зараз мережні протоколи TCP/IP і DECnet підтримані в X-серверах.

Cі-мовний Х-інтерфейс Xlib надає загальний компонент X Window як бібліотека двовимірної (2-D) графіки з графічними примітивами (точка, лінія і дуга). Хоча фундаментальне визначення X ґрунтується на мережних протоколах, прикладні програмісти не взаємодіють безпосередньо з X-протоколом. Для цього використовується Xlib-бібліотека, яка допускає модифікацію таких графічних атрибутів, як вид і ширина лінії, колір і тип шрифту.

Недокументовані послуги:

• формат файлу визначення об'єктів, оскільки відсутні стандарти на формат опису "look and feel" об'єктів графічної віконної системи;
• обслуговування інструментарію (Toolkit services);
• діалогові послуги і взаємодія міжпрограмних об'єктів.

Перехресна категорія служб POSIX-OSE

До підтримки безпеки графічних віконних систем входять:

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

[391] Еталонна модель служби підтримки графіки POSIX-OSE

Підтримка графіки

Ця служба POSIX-OSE відіграє важливу роль, оскільки ілюстративна графіка забезпечує більш інтуїтивний інтерфейс і тим полегшує взаємодію людини з комп'ютером. Зараз графіка стала стандартом "look and feel" інтерфейсу користувача за допомогою вікон і піктограм, зменшивши час на вивчення комп'ютера.

Еталонна модель

Розроблені протягом 90-х років графічні стандарти, збігаючись у понят­тях, мають різні базові моделі, чим обмежується ступінь сумісності стандартів. Зі створенням ISO/IEC 11072:1992 на Еталонну модель комп'ютерної графіки (CGRM - Computer Graphics Reference Model) визначена основа для зв'язку чинних і майбутніх стандартів комп'ютерної графіки (рис. 9.19). Комп'ютерну графіку визначено у термінах п'яти абстрактних рівнів середовищ: конструювання, віртуального, перегляду, логічного і реалізації. Для графічного виводу визначені операції на елементах відображуваних даних, що складають надані операторові примітиви, а вхідні лексеми накопичуються у відповідній для прикладної програми формі.

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

CGRM включена в Еталонну модель POSIX-OSE у поданому на рис. 9.20 вигляді, з графічними послуги як компонентами повного POSIX-OSE, доступного прикладній програмі через API. Об'єктами-сутностями є:

• прикладне ПЗ – це застосування типу CAD/CAM/ CAE, застосування візуалізації, електронного редагування й оформлення документів;
• прикладна платформа надає графічні середовища, реалізо­вані як графічні бібліотеки типу GKS і PHIGS;
• зовнішнє середовище склада­єть­ся з зовнішніх об'єктів: користува­чів, що обмінюються інформацією з прикладною платформою, та об'єктів інформаційного обміну, іденти­фіко­ваних у контексті CGRM як метафайл збору даних і об'єкти метафайлу контрольного сліду.

Інтерфейс поділено на:

• API, що стандартизує концептуальну мо­дель, яка визначає послідовність, функції і синтаксис, використовуваний у розробці графічної прикладної про­гра­ми. Кожен стандарт API має стандарт прив'язки до мов програмування, підтримує мобільність застосу­вання, ізолюючи програміста від більшості апаратних особливостей, і полегшує реалізацію властивостей мови на різних платформах. Приклади API підтримки графіки - GKS, PHIGS тощо;
• EEI; у підтримці графіки системне ПЗ використовується для комунікації між незалежними і залежними від пристроїв функціями, протоколами і форматами файлів. Термін HCI використовується тут як еквівалент терміна "інтерфейс оператора" CGRM.

Сервіс і глосарій термінів графіки

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

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

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

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

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

• конвеєрного перетворення чи тонування;
• утримуваних і неутримуваних структур;
• графічних режимів і віконних систем.

Збереження/архівація потребує форматів даних для збереження відображуваних чи тонованих зображень.

Графічний сервіс можна узагальнити на підставі можливостей:

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

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

Вибір графічного стандарту для використання API залежить від зовнішніх факторів: профілю застосування, повної архітектури системи, доступного устаткування, наявної взаємодії БД із прикладною програмою, розуміння ефективності системи, вимог інтерфейсу користувача, стратегії керування тощо. Метою створення сумісного набору графічних стандартів у GKS, GKS-3D, PHIGS, PHIGS PLUS тощо є уможливлення робити такий вибір найгнучкіше.

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

Стандарти, специфікації і недокументовані послуги

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

PHIGS програміста ієрархічної графіки (Рrоgrаммеr's Hierarchical Interactive Graphics Standard) описано у трьох частинах ISO/IEC 9592:1997. У частині 1 описані функції PHIGS, у частині 2 – формат архівних файлів, а в частині 3 – специфікація відкритого кодування текстів для архівних файлів. Прив'язки до основних мов програмування в ISO/IEC 9593 стосуються Фортрану, Ади і Сі. Як функціональна специфікація інтерфейсу з прикладною програмою PHIGS надає:

• високий ступінь взаємодії;
• багаторівневе ієрархічне структурування графічних даних;
• засоби простої модифікація графічних даних і співвідношень між даними;
• тривимірний (3-D) і двовимірний (2-D) графічний ввід-вивід;
• автономне збереження (пошук) графічних даних.

Керуючи організацією і відображенням даних у централізованій базі даних, PHIGS дає змогу програмістам визначати й організовувати графічні дані у найзручнішій формі для прикладної програми. Такий ієрархічний підхід – перевага, відсутня в іншому стандарті GKS. Об'єкти визначені в графічній базі даних PHIGS послідовністю елементів, разом з елементами відображення, атрибутами, перетворенням та ініціюванням інших об'єктів і описів об'єктних частин. Елементи згруповані в об'єкти-структури. Як наслідок, структуроване визначення графічних даних зменшує проблеми зв’язності та повторюваності. Повторне використання складових об'єктів і зв'язків між ними може автоматично стати частиною, що визначає об'єкт.

PHIGS не включає високорівневі примітиви типу кривих, поверхонь і методів підсвічування і затінення. Розширення PHIGS, яке специфікує застосування цих примітивів стандартним способом, сумісним із загальною філософією PHIGS, назване PHIGS PLUS і надає:

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

Системне графічне ядро GKS визначають чотири частини ISO/IEC 7942, що з'явилися внаслідок перегляду попередньої версії цього стандарту 1985 року. Мовні прив'язки визначені у ISO 8651 для Фортрану, Паскалю, Ади і Сі. Зараз розробляється прив'язка до мови Лісп.

Двовимірна (2-D) графічна система GKS (Graphical Kernel System) не підтримує тривимірну (3-D) графіку. API захищає програміста від відмінностей комп'ютерів і графічних пристроїв і, на потребу мобільності графічних застосувань, стандартизує базові графічні функції, методи і синтаксис їхнього виклику. GKS підтримує групування логічно зв'язаних примітивів типу ліній, багатокутників, ниток і їхніх атрибутів сукупно, які звуться сегментами і не можуть бути вкладеними. GKS підтримує ряд графічних пристроїв вводу-виводу типу монохромних і кольорових дисплеїв, принтерів, графопобудовувачів, мишей, планшетів даних, джойстиків і дигітайзерів.

Тривимірне системне графічне ядро GKS-3D визначає ISO 8805:1988; а ISO/IEC 8806 – прив'язку до мови Сі. GKS-3D дає змогу отримувати інформацію про тривимірні каркасні об'єкти з пристроїв вводу даних і видаляти невидимі лінії/поверхні. Проте не забезпечуються функції керування методами подання типу світлового джерела, затінення, текстурування.

Графічний інтерфейс CGI визначають шість частин ISO/IEC 9636:1991; прив'язки до мови Ада описані в ISO/IEC 9638-3:1994, кодування – у ISO/IEC 9637. CGI (Computer Graphics Interface) визначає стандартну функціональну і синтаксичну специфікацію керування й обміну даними між незалежним від пристроїв графічним ПЗ і одним або більше залежними від пристроїв драйвером графічних пристроїв. На відміну від графічних обговорених стандартів, CGI обробляє ввід-вивід (а не один ввід як CGM) і визначає інтерфейс на рівні швидше мобільного та інтероперабельного драйвера пристрою, ніж прикладної програми.

Архівні файли PHIGS описані у частинах 2 і 3 ISO/IEC 9592. Формат архівного файлу для збереження і передачі структур PHIGS структурує мережні описи з централізованого сховища структур (CSS – Central Structure Store), а кодування тексту виконується аналогічно CGM.

Обробка зображень і взаємообмін IPI (Image Processing and Interchange) визначена в ISO/IEC 12087, мовні прив'язки до API – в ISO/IEC 12088-4:1995, принципи кодування для обміну зображеннями (IIF) – в ISO/IEC 12089:1997. IPI-специфікація визначає об'єкти даних, примітивні операції й Еталонну модель.

Середовище подання PREMO для мультимедіа-об’єктів визначають чотири частини ISO/IEC 14478. PREMO (Presentation Environment for Multimedia Objects) – обчислювальне середовище для обробки і візуалізації мультимедіа-об’єктів.

Мова моделювання вірту­альної реальності визначена лише у першій частині ISO/IEC 14772, у якій розглянуті функціональні специфікації й однобайтне UTF-кодування текстових фрагментів (написів) зображень динамічних мультимедіа-об’єктів.

Тестування відповідності реалізацій графіки до стандартів згідно з ISO/IEC 10641:1993 специфікує методи встановлення відповідності стандарту певному виробу. Тестування відповідності стандартам комп'ютерної графіки спричиняє розвиток:

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

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

• не спрямовані на об'ємне моделювання тривимірного об'єкта (solid modeling);
• не забезпечують підтримки «drag-and-drop» динамічно зв'язаних даних, що циркулюють між застосуваннями;
• не дозволяють незмінним графічним методам здійснювати підсвічування і затінення.

Відкриті проблеми, що стосуються підтримки графіки, полягають у наступному:

• застосування мають різну поведінку для подібних функцій, що створює перешкоди мобільності ко­рис­тувача;
• не з’ясовано зв'язок між віконними стандартами і CGRM;
• відсутні шляхи для вирізання (cut) і вставки (paste) між застосуваннями.

[398] Еталонна модель служби підтримки розробки застосувань

Служба розробки прикладних програм

Ця служба дає змогу фізично розробляти і виконувати прикладне ПЗ на прикладній платформі. Більшість комп'ютерів постачається з можливістю розробки застосувань традиційними інструмен­та­ми: текстовими редакторами, трансляторами і лінкувальниками (редакторами зв'язків). Середовище розробки застосувань SDE часто має непрості можливості з визначення, планування, відстеження, розробки, перевірки і підтримки надзвичайно великих і ускладнених програмних проектів протягом повного життєвого циклу ПЗ. Інтерфейс для розробки прикладного ПЗ, що підтримує сервіс, який впливає на мобільність чи інтероперабельність застосувань, показано на рис. 9.21. Ця Еталонна модель не суперечить, а розширює Еталонну модель POSIX-OSE на рис.9.1.

Сервіс API дозволяє приклад­ній програмі звертатися до всіх по­слуг, доступних користувачеві в EEI.

Сервіс EEI дозволяє розробляти традиційні застосування.

Послуги супроводу оригіналів текстів програм потрібні розробнику у створенні і підтримці застосування для:

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

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

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

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

• налагодження прикладної програми: виконанням застосування під повним керуванням налагоджувальника; прикріплення інструмента налагодження до застосування під час виконання чи збою застосування; друк перехресних посилань змінних, підпрограм, структур даних тощо;
• дослідження ефективності виконання програми (наприклад, при профілюванні): підпрограм чи головного блоку та окремих його рядків.

Стандарти. ISO/IEC 9945-2:1993 описує обмежений інструментарій розробку прикладних програм, зокрема із стандартним інтерфейсом до обраних трансляторів і утиліт розробки ПЗ.

ISO/IEC 13719:1998 у чотирьох частинах описує мобільне загальне інструментальне середовище PCTE (Portable Common Tool Environment). У частині 1 задані абстрактні специфікації PCTE; з попередньою версією 1995 року цієї частини стандарту гармонізований ДСТУ 3947-1–2000 (ISO/IEC 13719-1:1995, ДСТ 30717.1-2000). У частинах 2-4 описані прив'язки до мов Сі, Ада і IDL.

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

• синтаксично кероване редагування текстів програм;
• підтримка кодування стилю;
• керування конфігурацією;
• супровід оригіналів програм;
• виконання застосування;
• інтероперабельність середовищ розробки ПЗ.

X/Open XPG4 і OSF AES-OSC забезпечують специфікації для недокументованих служб.

Проводяться роботи із SDE-стандартизації . Один з форумів NIST скеровує зусилля на стандартизацію SDE як ISEE-середовища проектування інтегрованого ПЗ (Integrated Software Engineering Environments). Інший напрямок SDE-стандартизації – це PCTE в межах ECMA і під егідою JTC1 ISO/IEC.

[401] Служби інтернаціоналізації POSIX-OSE. Обслуговування наборів символів/ подання даних

Служба інтернаціоналізації

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

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

Здатність категорій служб POSIX-OSE до підтримки багатьох природних мов та основних культурних угод є двохетапним процесом, що складається з інтернаціоналізації та локалізації. Спочатку інтерфейс між категоріями служб узагальнюється і не враховує вимоги жодної природної мови чи набору культурних угод (інтернаціоналізація). Потім надаються засоби вибору користувачем бажаної природної мови та культурних угод (локалізація). У такому контексті культурні угоди – це різні аспекти надання інформації користувачу. Забезпечуваний POSIX-OSE інтерфейс надає інформацію користувачу у відповідному форматі і відповідною природною мовою.

На рис. 2.5 наведена схема ключових компонентів КІС з виділеною нижньою частиною, де показана локалізована прикладна платформа, репозитарій якої наповнений культурними елементами, потрібними для організації інтерфейсу користувача на певній території.

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

• POSIX-OSE має забезпечити засоби коригування виводу функцій та утиліт на підтримку різних природних мов, культурних угод та наборів символів;

користувач повинен мати змогу вибирати національно-культурне середовище з певним набором характеристик подання даних, культурних угод, наборів символів та місцевою мовою;

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

Інтернаціоналізація як перехресна категорія впливає на всі служби POSIX-OSE.

Сервіс інтернаціоналізації

Служба інтернаціоналізації POSIX-OSE зосереджена на підтримці й обробці:

• наборів символів та подання даних;
• культурних угод;
• підтримці природної мови.

Набори символів та подання даних. Набір символів англійської мови задається ISO 646:1991 та використовує семибітне кодування для унікальної ідентифікації кожного з 95 доступних символів. Крім англійської мови, для мов Європи та Америки число локальних символів набагато більше. Для тисяч піктограм далекосхідних мов потрібно додавати зовсім іншу розмірність у правила та методи кодування.

Різні стандарти спрямовані на методи кодування для унікальної ідентифікації локальних репертуарів символів. У той час як заміна рідко вживаних символів у 7-ми бітному кодуванні, крім англійської мови, дозволяє підтримувати ще одну додаткову мову, 8-ми бітні схеми кодування використовуються для одночасної підтримки багатьох мов, призначаючи (додаючи) до доступного репертуару додаткові 96 графічних символів. ISO/IEC 8859 – приклад підтримки мов Європи, Америки, Австралії й Аравії. Японія, Китай, Корея у національному реперту­арі мають так багато символів, що необхідні 16 чи навіть більше бітів для точної ідентифікації.

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

Загальний сервіс для підтримки наборів символів та подання даних у локалізованому культурно-національному середовищі орієнтований на таке.

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

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

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

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

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

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

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

[403] Служби інтернаціоналізації POSIX-OSE. Обслуговування культурних домовленостей

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

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

• форматів дат та часу, пов'язаних з конкретним культурним об'єктом. Так, у США дата виражена у форматі «місяць/день/рік», у Європі – "рік-місяць-день", в Україні – "день-місяць-рік", а Японія рахує роки з часу коронування імператора. Години від 00.00 до 24.00, розповсюджені в Європі, у США використовуються тільки у військових колах, а терміни "am" і "pm" при позначенні ранку та пополудні уживані широкою публікою;
• нумерація дня та тижня. У Європі тиждень починається в понеділок; у США – у неділю;
• форматування числових полів. Прикладна платформа має визначати символи-роздільники десяткового дробу (кома, крапка), число десяткових знаків перед роздільником десяткового дробу, подання від’ємних величин тощо;
• позначення грошової одиниці та довжина поля. Обробки позначень грошової одиниці у різних культурах повинне забезпечуватися загальними службами інтернаціоналізації. Позначення грошової одиниці може мати довжину більш одного символу та знаходитися до чи після поля грошової одиниці. Формат полів грошової одиниці може відрізнятися від таких самих числових полів; наприклад, у Португалії знак «$» використовується як десяткова точка. Інформація щодо угод повинна зберігатися у репозитарії та використовуватися прикладною платформою для локального форматування полів грошової одиниці. Не обов'язково вводити службу, але важливо зрозуміти старанність у регулюванні довжини поля різних валют. Крім того, деякі валюти не мають десяткових дробів (італійська ліра);
• формату паперу для друку. Так, формат «quarto» переважає в США, ISO стандартизував A-формати для Європи, Кореї, Гонконгу та Японії.

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

Правила упорядкування, щоб прикладна платформа сортувала дані за локальними правилами з репозитарію. Приклад культурно-залежних правил зіставлення – обробка «umlauts» (умляут); в Австрії упорядкування ведеться с початку абетки за основними символами латиниці, а у Швеції – з кінця абетки. Складність збільшується у разі упорядкування одного символу з двох літер (німецька "sharp's" як "sz" в Австрії та "ss" у Німеччині) або двох символів як одного тощо.

[404] Служби інтернаціоналізації POSIX-OSE. Обслуговування природномовної взаємодії

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

Служби для підтримки природної мови включають наступне.

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

Обмін повідомленнями природною мовою, щоб прикладна платформа повинна бути здатна подавати (на дисплеї, в роздруковці) повідомлення, меню, форми й інтерактивну документацію обраною користувачем мовою, одночасно підтримувати свої мови для різних користувачів, дозволяти їм перемикати мови, правильно обробляючи такі аспекти:

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

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

Культурні угоди підтримуються таким сервісом:

• виклик культурних угод як здатність прикладної платформи для кожної прикладної програми викликати культурні угоди з депозитарію, зокрема за промовчанням;
• зміна культурних угод як здатність прикладної платформи динамічно заміняти уживану культурну угоду за запитом прикладної програми чи користувача;
• надання локальних значень як здатність платформи за запитом прикладної програми повертати локальні формати часу, дат, календаря, числових полів тощо;
• локальне упорядкування та порівняння як здатність платформи за запитом прикладної програми порівнювати та впорядковувати дані за локальними правилами, визначеними у репозитарії культурних угод.

Підтримка природної мови:

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

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

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

[408] Служби системної безпеки POSIX-OSE

Служба системної безпеки

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

Відносно високого ступеня захисту комп'ютерних систем можна досягти правильно конфігуруючи і підтримуючи системи адміністраторами згідно рекомендованого керівного принципу захисту і практичного досвіду, як це описано у Настановах із захисту X/Open (X/Open Security Guide). Однак додаткові засоби безпеки має підтримувати система для розширення захисту проти невеликого відсотка зломів. Намір розширення безпеки щодо основного стандарту POSIX-інтерфейсу зводяться до підтримки:

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

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

З позицій ефективності служба безпеки надає захист різної глибини, якщо один рівень захисту порушений, то наступні – обмежать чи попередять про несанкціоновані чи ненавмисні дії усередині системи. Стратегія безпеки системи (SSP - System Security Policy) формує вбудовування базового захисту у життєвий цикл системи. Один з аспектів SSP полягає в обов'язковій (мандатній) відповідності з розширеннями POSIX-безпеки. Еталонна модель POSIX-OSE виділяє у API і EEI сукупність послуг, кожна з яких може мати компоненти безпеки, що функціонують незалежно чи разом. Наприклад, ідентифікація користувача та операція автентифікації можуть включати елементи служб інтерфейсу користувача, комунікації і підтримки баз даних.

Сервіс безпеки

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

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

До інших цільових функцій безпеки належать:

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

Сервіс API. Нині сфера дії інтерфейсу безпеки обмежена розширеннями для інтерфейсу, визначеного ISO/IEC 9945-1:1996. Задачі, поза інтерфейсом безпеки, включають забезпечення захисту специфічної не інтерфейсної архітектури і розподілених чи мережних систем. Зазначимо, що звичайне надання послуг безпеки не робить систему "безпечною".

До інтерфейсу POSIX-безпеки входять контроль, пріоритети користувача чи програми, керування довільним (DAC - discretionary access control) і обов'язковим доступом (MAC - mandatory access control) та інформаційні позначки (IL - information labels).

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

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

Інтерфейс DAC підтримує накладення високого ступеня деталізації на конкретний контроль доступу користувача до об'єктів. Інтерфейс DAC за допомогою списків доступу (ACLs - Access Control Lists) доповнює user-group-other біти дозволу, що задіяні усередині POSIX-сумісних систем згідно з ISO/IEC 9945-1:1996.

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

Сервіс EEI знаходяться поза інтерфейсом POSIX-безпеки. Однак служба безпеки розподіленої системи стосується:

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

Ідентифікатор користувача (user ID), наданий системою прикладній програмі (навіть вилученій), має розглядатися обов’язково, інакше прикладна програма порушує безпеку.

Стандарти і специфікації

ISO/IEC 9594-8:1998 (попередня версія стандарту 1990 року) визначає загальні стандарти заснованої на ключах ідентифікації для служб каталогу X.500. У ECMA 138 визначено сервіс та опис даних для безпеки у відкритих системах. ISO 7498-2:1989 дає загальний опис служб і зв'язаних механізмів безпеки, забезпечуваних Еталонною моделлю OSI.

IEEE P1003.6 як Робоча група має на меті розширення безпеки інтерфейсу, визначеного в API POSIX-систем (ISO/IEC 9945-1:1996 та ISO/IEC 9945-2:1993).

ODA-безпека визначена у ISO/IEC 8613 для архітектури офісних документів.

Загальні специфікації. Департамент США за критеріями оцінки довіри до безпеки комп'ютерних систем описав у документі DOD 5200.28-STD, відомому як "Оранжева книга", вимоги безпеки для захищених систем. ITSEC-критерії оцінки захисту ІТ – це європейсь­кий еквівалент DOD 5200.28-STD.

[411]. Служби системного адміністрування POSIX-OSE

[419] Поняття профілю. Мета профілю. Типи профілів: одностандартний, профіль платформи, AEP

94. Профілі стандартів для суперкомп’ютерних обчислень

95. Профілі стандартів для систем реального часу

96. Роль вертикальних профілів на прикладі GOSIP США та Великої Британії, NetBIOS, MAP, TOP