• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Лекція №8. Модель предметної області. Онтологія. Особливості онтологічного стандарту IDEF5

МОДУЛЬ нумбер ту

Основною складовою об’єктно-орієнтованого аналізу (або дослідження) є декомпозиція проблеми на окремі класи понять (концептуальні класи) або об’єкти. Модель предметної області – це візуальне представлення концептуальних класів або об’єктів реального світу у термінах предметної області. Крім того, такі моделі ще називають концептуальними моделями, моделями об’єктів предметної області або об’єктними моделями аналізу. На мові UML модель предметної області представляється у вигляді набору діаграми класів. Модель предметної області може відображати наступне:

· об’єкти предметної області або концептуальні класи

· асоціації між концептуальними класами

· атрибути концептуальних класів

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

Концептуальний клас – це представлення ідеї або об’єкту (поняття із реального світу).

Методи виявлення концептів:

1) використання списку категорій концептуальних класів

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

2) метод виділення іменників

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

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

Неформально онтологія являє собою деякий опис погляду на світ стосовно конкретної області інтересів. Цей опис складається із термінів та правил використання цих термінів, котрі обмежують їх значення у рамках конкретної області. Відповідно, онтологію можна представити у вигляді трійки О = { X, R, F }, де X – множина понять, R – множина зв’язків між поняттями, F – інтерпретація понять (словник, наприклад); X = { X1, X2...}.

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

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

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

Схемки стандарту IDEF5:

a) Діаграма класифікації – забезпечує механізм для логічної систематизації знань, накопичених при вивченні системи. Існує два типи таких діаграм:

ü діаграма суворої класифікації;

ü діаграма природної (видової) класифікації.

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

c) Діаграма взаємозв’язків – дозволяє розробникам візуалізувати і вивчити взаємозв’язки між класами об’єктів у системі.

d) Діаграма стану об’єкта – дозволяє документувати той чи інший процес з точки зору зміни стану об’єкта.

Лекція №9. Значення специфікації вимог до програмного забезпечення. Визначення, базовий зміст та використовувані метрики

Способи представлення вимог:

1. Документування – створення документації, у якій використовується чітко структурована та акуратно використовувана природна мова.

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

3. Формальні специфікації – у них вимоги визначаються за допомогою математично точних та формальних логічних мов.

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

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

ü клієнтам, особливо із відділу маркетингу та спеціалістам із продажу

ü менеджерам проекту – за даними специфікації розраховуються графіки витрат та ресурси

ü команді розробників – отримує представлення про створюваний продукт

ü групі тестувальників – на основі специфікації вони складають плани тестування, варіанти використання та процедури

ü спеціалістам по обслуговуванню та підтримці – отримують представлення про функціональність кожної складової частини продукту

ü укладачам документації – створюють інструкції для користувачів та довідкову службу на базі специфікації вимог

ü спеціалістам, що відповідають за інструктування (навчання) персоналу – розробляють навчальні матеріали на основі SRS

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

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

1) функціональні можливості

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

3) продуктивність (яка швидкодія, час відгуку, час відновлення та інше)

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

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

Грамотно складена специфікація вимог до ПЗ надає наступні основні можливості:

o для замовників – точний опис того, що замовник хоче отримати

o для розробника – однозначне тлумачення та розуміння того, що хоче отримати замовник

Мета розробки специфікації вимог – надати замовнику, розробнику та іншим учасникам проекту ряд переваг:

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

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

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

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

5.полегшення розгортання та тиражування системи = SRS робить більш простою передачу системи новим користувачам та її установку

6.служить у якості основи для розширення = оскільки у специфікації вимог обговорюється сама система, то відповідна дана SRS служить основою для подальшого розширення готової системи

Читайте також:

1. G2G-модель електронного уряду
2. I. Особливості аферентних і еферентних шляхів вегетативного і соматичного відділів нервової системи
3. OSI - Базова Еталонна модель взаємодії відкритих систем
4. VI.3.3. Особливості концепції Йоганна Гайнріха Песталоцці
5. VI.3.4. Особливості концепції Йоганна Фрідриха Гербарта
6. А. Особливості диференціації навчального процесу в школах США
7. Абстрактна модель
8. Абстрактна модель
9. Абстрактна модель оптимального планування виробництва
10. Агітація за і проти та деякі особливості її техніки.
11. Аграрне виробництво і його особливості
12. Аграрне право як галузь права, його історичні витоки та особливості.

Переглядів: 1872