PrIS

121

Coad Process Notation» і «Gane and Sarson Process Notation».

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

Зовнішня сутність позначається прямокутником із тінню (рис. 7.1), всередині якого вказується її назва. При цьому як назву рекомендується використовувати іменник в називному відмінку. Іноді зовнішню сутність називають також термінатором.

Рис. 7.1.Символи зовнішніх сутностей.

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

7.1.2. Процеси

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

122

встановленої на комп'ютері, спеціальним логічним пристроєм тощо.

Процеси на діаграмі потоків даних зображуються так, як показано на рис.7.2.

Рис. 7.2.Символи процесів.

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

(рис. 7.3).

Рис. 7.3. Зображення підсистеми на діаграмі потоків даних.

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

123

адресу одержувача», «акцептувати рахунок». Інформація на нижньому полі символа процесу вказує, який підрозділ організації, співробітник, програма або апаратний пристрій виконує цей процес. Якщо таке поле відсутнє, то подібна інформація може вказуватися в текстовій примітці.

7.1.3. Накопичувачі даних

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

Найчастіше символи накопичувачів даних зображаються так, як на рис.7.4.

1 сховище

Рис. 7.4. Символи накопичувачів даних.

Всередині символа вказується його унікальнп в рамках цієї моделі назва, яка найточніше, з погляду аналітика, відображає інформаційну сутність вмісту, наприклад, «Угода», «Клієнти», і т.ін. Символи накопичувачів даних як додаткові елементи ідентифікації можуть містити порядкові номери.

7.1.4. Потоки даних

Потік даних визначає інформацію, що передається через якесь підключення (кабель, поштовий зв'язок, кур'єр) від джерела до приймача. На DFD-діаграмах потоки даних зображаються лініями зі стрілками, що

124

показують їх напрямок. Кожному потоку даних присвоюється назва, що відображає його зміст.

7.2. Методологія побудови DFD.

Мета побудови ієрархічно взаємозв'язаних DFD - зробити вимоги до системи зрозумілими на кожному рівні деталізації. Для цього треба користуватися такими рекомендаціями:

на кожному рівні від 15.6 процесів і не більше;

не захаращувати діаграму неважливими елементами на заданому рівні деталізації;

декомпозицію процесів і потоків здійснювати паралельно;

вибирати зрозумілі імена для всіх об'єктів DFD;

одноразово визначати функціонально ідентичні процеси (в інших місцях просто посилатися на цей процес, де успадкування відбувається не автоматично);

використовувати DFD для технічних процесів, які можна за допомогою неї описати.

Побудову DFD-можна звести до таких кроків:

декомпозиція вимог на основні функції груп;

ідентифікація зовнішніх об'єктів (по відношенню до системи);

ідентифікація інформації, яка перетікає між процесами;

розроблення контекстної діаграми;

контроль контекстної діаграми й уточнення, якщо це потрібно;

формування DFD першого рівня, де відображені основні функції системи;

125

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

здійснити ревізію всіх рівнів з метою з'ясування некоректності, якщо некоректності виявлені - усунути.

Графічне зображення елементів DFD у різних нотаціях подано у таблиці 7.1.

Таблиця 7.1. Графічне зображення елементів DFD.

126

процес)

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

128

Висновки

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

2.Основними елементами діаграм даних є сутності, процеси, сховища даних, потоки даних.

3.Нотації DFD: Йордона, Ґейна-Сарсона, SADT, SAG.

Контрольні запитання

1.Призначення діаграм потоків даних.

2.Основні елементи діаграм потоків даних.

3.Особливості побудови діаграм потоків даних.

4.Нотації діаграм потоків даних.

129

РОЗДІЛ 8. Діаграми "сутність-зв'язок", атрибутів, категоризації

Призначення діаграм «сутність-зв’язок»

Деталізація сутностей

Методологія IDEF1

Урозділі описано методологію побудови діаграм «сутність-зв’язок», а також діаграм деталізації сутностей.

8.1.Діаграма «сутність-зв’язок»

Діаграми «сутність-зв'язок» – entity-relation diagram (ERD) – призначені для розроблення моделей даних і забезпечують стандартний спосіб визначення даних і відношень між ними. Фактично за допомогою ERD здійснюється деталізація сховищ даних проектованої системи, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для предметної області, властивостей цих об'єктів (атрибутів) і їх відношень з іншими об'єктами (зв'язків).

Ця нотація була введена Ченом (Chen) і одержала подальший розвиток у роботах Баркера (Barker).

Нотація Чена надає багатий набір засобів моделювання даних, включаючи власне ERD, а також діаграми атрибутів і діаграми декомпозиції. Ця діаграмна техніка використовується, перш за все, для проектування табличних моделей даних (хоча також може з успіхом застосовуватися і для моделювання як ієрархічних, так і мережевих моделей даних) [133].

130

Сутність – множина екземплярів реальних або абстрактних об'єктів (людей, подій, станів, ідей, предметів тощо), що мають загальні атрибути або характеристики. Будь-який об'єкт системи може бути поданий тільки однією сутністю, яка має бути унікально ідентифікована. При цьому назва сутності повинна відображати тип або клас об'єкту, а не його конкретний екземпляр (наприклад, Аеропорт, а не Львівський).

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

Відношення (зв’язок) в найзагальнішому вигляді є зв'язком між двома і більше сутностями. Іменування відношення здійснюється за допомогою граматичного обороту дієслова (МАЄ, ВИЗНАЧАЄ, МОЖЕ МАТИ тощо). Прикладами зв'язків можуть бути споріднені відношення типу "батько-син" або виробничі відношення типу "керівник-підлеглий". Інший тип зв'язків задається відношеннями "мати у власності" або "володіти властивістю".

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

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

використання цієї інформації різними застосуваннями.