1. Інформаційні технології та інформаційні системи

7. Моделі життєвого циклу програмних засобів.

1. Waterfall («водоспад», каскадна модель)

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

2. Прототипування

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

3. Ітераційна модель

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

4. Життєвий цикл «спіраль»

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

1. Інформаційні технології та інформаційні системи

8. ER–модель.

ER–модель - Інформаційна модель концептуального рівня (ІМКР) призначена для формального опису предметної області з урахуванням різноманітних точок зору на дані, які мають різні користувачі або задачі. Важливо зауважити, що ІМКР не залежить від конкретної СУБД, чи апаратної платформи, на якій реалізована база даних. Однією з найбільш часто вживаних модельних мов для опису ІМКР є ЕR-модель (Entity-Relationship model), яка була запропонована Ченом (P.Chen) у 1976 році, та її модифікації.

Розглянемо базові засоби ЕR-моделі, основу концепції якої складають такі поняття як тип об’єкту, тип зв’язку, атрибут та ключ.

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

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

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

Згідно з типом відображення зв’язки поділяються на три групи. Зв’язки з типом відображення 1:1 (один до одного) одному примірнику одного типу об’єкта ставлять у відповідність точно один примірник іншого типу об’єкта. Прикладом такого зв’язку є зв’язок між об’єктами завідувач відділу та відділ. У графічному представленні такий зв’язок має вигляд, показаний на мал. 1.5.1:

Зв’язки з типом відображення 1: N (один до багатьох) одному примірнику одного типу об’єкта ставлять у відповідність кілька (зокрема 0) примірників іншого типу об’єкта. Прикладом такого зв’язку є зв’язок між об’єктами співробітник та відділ. У графічному представленні такий зв’язок має вигляд, показаний на мал. 1.5.2:

Зв’язки з типом відображення M : N (багато до багатьох) багатьом примірникам одного типу об’єкта ставлять у відповідність кілька примірників іншого типу об’єкта. Прикладом такого зв’язку є зв’язок між об’єктами співробітник та тема, у виконанні якої він бере участь. У графічному представленні такий зв’язок має вигляд, показаний на мал. 1.5.3:

Відзначимо певні семантичні аспекти використання наведених зв’язків:

1. Зв’язок “очолює”(1:1) означає, що кожен відділ очолює один (і тільки один) завідувач і що кожен завідувач очолює тільки один відділ. Немає завідувачів без очолюваних відділів, і немає відділів без завідувачів.

2. Зв’язок “працює” (1:N) означає, що кілька співробітників можуть працювати у одному відділі, але кожен співробітник працює не більш ніж у одному відділі. Взагалі кажучи, можуть бути співробітники, які не відносяться до жодного відділу. У деяких модифікаціях моделі такі ситуації необхідно відзначати специфікацією об’єкту по певному зв’язку як обов’язковий (mandatory), або необов’язковий (optional), але по класиці береться останній, більш загальний варіант.

3. Зв’язок “виконує” означає, що кілька співробітників беруть участь у виконанні теми, і один і той же співробітник може брати участь у виконанні кількох тем. Можлива ситуація (як і у попередньому пункті), що деякий співробітник не виконує жодної теми, або є теми, що ніким не виконуються.

Відзначимо, що попередні визначення і приклади наводилися для випадку бінарних зв’язків; для зв’язків більших арностей – визначення аналогічні.

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

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

ТЕМА

№	Назва атрибуту	Домен	Примітки
1.	Номер теми	Код1
2.	Назва теми	рядок літер
3.	Дата початку	дата
4.	Дата завершення	дата
5.	Кошторис	число
6.	Категорія	Код2

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