- •5.4. Висновки 182
- •1.1. Основні означення менеджменту знань
- •1.1.1. Структура менеджменту знань
- •Маркетинґ Проектування Підготовка виробництва Виробництво Збут.
- •1.1.2. Формування знань
- •1.1.3. Введення даних
- •1.1.4. Адміністрування
- •1.1.5. Мотивація
- •1.1.6. Особливості впровадження мз
- •1.2. Менеджмент знань
- •1.3. Базові поняття менеджменту знань
- •1.3.1. Видобування знань
- •1.3.2. Системи пізнання
- •1.3.3. Організація доступу до знань
- •1.3.4. Інновації в області автоматизації
- •1.3.5. Менеджмент знань та інформації
- •1.3.6. Менеджмент знань та Інтернет
- •1.4. Онтологічний інжиніринґ
- •1.4.1. Системи керування знаннями
- •1.4.2. Онтологія
- •1.5. Висновки
- •9. Базові поняття менеджменту знань.
- •2.1. Поле знань
- •2.1.1. Мова опису поля знань
- •2.1.3. «Піраміда» знань
- •2.2. Стратегії одержання знань
- •2.3. Теоретичні аспекти видобування знань
- •2.3.1. Психологічний аспект
- •2.3.2. Лінгвістичний аспект
- •2.3.3. Гносеологічний аспект видобування знань
- •2.4. Теоретичні аспекти структурування знань
- •2.4.1. Історична довідка
- •2.4.2. Ієрархічний підхід
- •2.4.3. Традиційні методології структуризації
- •2.4.4. Об'єктно-структурний підхід (осп)
- •3.1. Класифікація методів практичного видобування знань
- •3.2. Комунікативні методи
- •3.2.1. Пасивні методи
- •3.2.2. Активні індивідуальні методи
- •3.2.3. Активні групові методи
- •3.3. Текстологічні методи
- •3.3.1. Методи структурування
- •3.3.2. Еволюція систем одержання знань
- •4.1. Латентні структури знань і психосемантика
- •4.1.1. Семантичні простори і психологічне градуювання
- •4.1.2. Методи багатовимірного градуювання
- •4.1.3. Використання метафор для виявлення «прихованих» структур знань
- •4.2. Метод репертуарних решіток
- •4.2.1. Основні поняття
- •4.2.2. Методи виявлення конструктів. Метод мінімального контексту
- •4.2.3. Аналіз репертуарних решіток
- •4.2.4. Автоматизовані методи
- •4.3. Керування знаннями
- •4.3.1. Що таке «керування знаннями»?
- •4.3.2. Керування знаннями і корпоративна пам'ять
- •4.3.3. Системи omis
- •4.3.4. Особливості розроблення омis
- •4.4. Візуальне проектування баз знань як інструмент пізнання
- •4.4.1. Від понятійних карт до семантичних мереж
- •4.4.2. База знань як пізнавальний інструмент
- •4.5. Проектування гіпермедіа бд і адаптивних навчальних систем
- •4.5.1. Гіпертекстові системи
- •4.5.2. Від мультимедіа до гіпермедіа
- •4.5.3. На шляху до адаптивних навчальних систем
- •5.1. Важливість правильної класифікації
- •5.1.1. Класифікація й об’єктно-орієнтовне проектування
- •5.1.2. Труднощі класифікації
- •5.2. Ідентифікація класів і об'єктів
- •5.2.1. Класичний і сучасний підходи
- •5.2.2. Об’єктно-орієнтований аналіз
- •5.3. Ключові абстракції й механізми
- •5.3.1. Ключові абстракції
- •5.3.2. Ідентифікація механізмів
- •5.4. Висновки
- •6.1. Поняття онтології
- •6.2. Моделі онтології й онтологічної системи
- •6.3. Методології створення і «життєвий цикл» онтології
- •6.4. Мови опису онтологій
- •6.4.1. Види owl
- •6.4.2. Структура онтологій
- •7.1. Онтологія як засіб формалізації та алгоритмізації знань в інтелектуальній системі
- •7.1.1. Аналіз підходів до навчання онтологій
- •7.1.2. Загальні принципи проектування онтологій
- •7.1.3. Формати та стандарти подання інформації
- •7.1.4. Засоби для створення онтології
- •7.2. Технологія розроблення онтологій в редакторі Protégé
- •7.2.1. Еволюція Protégé
- •7.2.2. Protégé-owl. Мова Web онтологій owl
- •7.2.3. Основні терміни та поняття у Protégé-owl
- •7.2.4. Методика розроблення онтології засобами Protégé
- •Створення й експлуатація онтології
- •7.2.5. Створення онтології
5.3.2. Ідентифікація механізмів
Як знайти механізми? У попередньому обговоренні ми називали механізмами структури, за допомогою яких об'єкти взаємодіють один з одним і поводяться так, як потрібно. Як при розробленні класу фактично визначається поведінка окремих об'єктів, так само й механізми служать для задання поведінки сукупності об'єктів. Отже, механізми відображають шаблони поведінки.
Розглянемо вимогу, яка ставиться до автомобіля: натискання на акселератор має приводити до збільшення обертів двигуна, а відпускання акселератора — до їх зменшення. Як це відбувається, водієві зовсім байдуже. Може бути використаний будь-який механізм, який забезпечує потрібну поведінку, і його вибір — справа смаку розробника. Наприклад, припустимо кожне із запропонованих нижче інженерних рішень:
механічний зв'язок між акселератором і карбюратором (звичайне рішення);
під педаллю ставиться давач тиску, що з'єднується з комп'ютером, який керує карбюратором (механізм керування через дроти);
карбюратора немає; бак із пальним розташований на даху автомобіля й паливо вільно тече у двигун; потік палива регулюється затискачем на трубці; натискання на педаль акселератора послабляє затискач (дуже дешево).
Яку саме реалізацію вибере розробник, залежить від таких параметрів, як вартість, надійність, технологічність тощо.
Ключові абстракції визначають словник предметної області, механізми визначають суть проекту. У процесі проектування розробник має придумати не тільки наповнення класів, але й те, як об'єкти цих класів будуть взаємодіяти один з одним. Механізм взаємодії розкладається на методи класів. У підсумку протокол класу буде відображати поведінку його об'єктів і роботу механізмів, в яких вони беруть участь.
Отже, механізми являють собою стратегічні рішення в проектуванні, подібно до проектування структури класів. З іншого боку, проектування інтерфейсу якогось одного класу — це швидше тактичне рішення. Стратегічні рішення повинні виконуватися явно, інакше ми отримаємо неорганізований набір об'єктів, що кидаються виконувати роботу, розштовхуючи один одного. У найелегантніших, найстрункіших і найшвидших програмах втілені ретельно розроблені механізми.
Механізми відображають лише один із шаблонів, які ми знаходимо в структурованих системах. Так, на нижньому кінці своєрідної біологічної піраміди перебувають ідіоми. Наприклад, в CLOS не прийнято використовувати підкреслення в іменах функцій або змінних, хоча в Ada ця справа звична. Вивчаючи мову, доводиться вчити її ідіоми, які зазвичай передаються у формі фольклору. Однак, ідіоми відіграють важливу роль в кодифікації шаблонів низького рівня. Багато звичних програмістських дій ідіоматичні і тому розпізнавання таких ідіом дозволяє використовувати конструкції C++ для вираження функціональності поза самою цією мовою зі збереженням ілюзії, що вони є частиною мови.
Місце на верху піраміди займає середовище розроблення. Середовище розроблення — це набір класів, призначених для певної прикладної ситуації. Середовище дає готові класи, механізми й послуги, якими можна відразу користуватися або пристосовувати для своїх потреб.
Якщо ідіоми становлять частину програмістської культури, то середовища розроблення — комерційний продукт. Наприклад, Apple MacApp і його спадкоємець Bedrock — середовища, написані на C++ і призначені для побудови ІС зі стандартним інтерфейсом користувача Macintosh. Аналогічну роль для Windows відіграють Microsoft Foundation Classes і ObjectWindows корпорації Borland.