2. Особливості стандарту idef5.

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

Онтологію можна представити наступною формулою 0={X,R,F}X- множина понять R – множина відношень F – інтерпретація (словник один із прикладів інтерпретації).

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

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

Види схем та діаграм IDEF 5:

- Діаграма класифікації

§ Діаграма суворої класифікації

§ Природної класифікації

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

- Схема взаємозв’язки – дозволяє розробникам візуалізувати і вивчати взаємозв’язки між різними класами об’єктів системи (оформлення акту повернення товару).

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

3. Сутність специфікації вимог до програмного забезпечення.

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

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

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

Основні питання що розглядаються специфікаціями вимог

1. Функціональні можливості майбутньої системи

2. Зовнішній інтерфейс (зазначається як ПЗ буде взаємодіяти з користувачем, апаратними засобами та іншим ПЗ)

3. Продуктивність (визначає яка швидкодія, час відліку та час відновлення різних функцій ПЗ)

4. Атрибути (яка мобільність, правильність, зручність супроводження та захищеність ПЗ)

5. Можливі проектні обмеження(стандарти, політика по збереженню цілісності, обмеження ресурсів та операційне середовище)