Студопедия
Новини освіти і науки:
МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах


РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання


ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ"


ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ


Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків


Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні


Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах


Гендерна антидискримінаційна експертиза може зробити нас моральними рабами


ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ


ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів



Лекція №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. Аграрне право як галузь права, його історичні витоки та особливості.




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

<== попередня сторінка | наступна сторінка ==>
Лекція №7. SADT та IDEF | Лекція №10. Документування вимог у відповідності зі стандартами

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

  

© studopedia.com.ua При використанні або копіюванні матеріалів пряме посилання на сайт обов'язкове.


Генерація сторінки за: 0.011 сек.