2012_Посібник_з_дисципліни_ТКП

61

Відносини (Relational Link) пунктирна лінія, що використовується для зображення зв'язків між одиницями робіт (UOW), а також між одиницями робіт і об'єктами посилань. Робота-мета може закінчитися раніше, ніж закінчиться робота-джерело.

Рисунок 3.13 - Приклад використання Relation Link

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

Рисунок 3.144Приклад використання Object Flow

63

Рисунок 3.16 - Приклад використання перехресть типу ХОР

Об'єкти вказівники

Вказівники - це спеціальні символи, які посилаються на інші розділи опису процесу.

Вони використовуються при побудові діаграми для залучення уваги користувача до будь-яких важливих аспектів моделі.

Декомпозиція робіт.

Декомпозиція використовується для деталізації робіт.

Методологія IDEF3 дозволяє декомпозувати роботу багаторазово, тобто робота може мати безліч дочірніх робіт.

Функціонально-вартісний аналіз.

ФВА включає такі основні поняття:

об'єкт витрат - мета існування функції процесу, тобто основний вихід. Вартістю цільового технологічного процесу буде сумарна вартість всіх об'єктів витрат;

рушій витрат - входи і управління функції, що визначають її існування і впливають на термін її дії;

центри витрат - різні статті витрат.

Приклад

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

На перший погляд все вірно: спочатку договір підписує зацікавлена сторона, в даному випадку клієнт, а вже потім договір потрапляє на підпис керівнику.

.

Рисунок 3.18 - Приклад ФВА

Однак з інтерв'ю із співробітниками відділу закупівель з'ясувалося, що з боку клієнта ніколи не було розбіжностей з приводу підписання договору (або таких випадків мало). Але з боку керівництва компанії до клієнтів висуваються певні вимоги. В результаті договір може бути не підписаний. Проаналізувавши вартість цих робіт за критеріями «Кур'єрська доставка»,

65

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

В результаті проведених досліджень був зроблений висновок - про необхідність змінити порядок проходження процесів з метою зменшення витрат.

Питання для самоперевірки

1.Які основні компоненти діаграми IDEF3 ?

2.Що таке одиниця роботи ?

3.Як виконується декомпозиція в діаграмі IDEF3?

4.Яке основне призначення діаграми IDEF3?

5.З якою метою виконується функціонально-вартісний аналіз ?

Література: [15, с.27-42]; Завдання на СРС: [VI].

66

3.4Діаграми потоків даних DFD

Структура теми :

–Нотації DFD.

–Основні символи.

–Контекстна діаграма.

–Декомпозиція даних.

–Побудова діаграми.

Діаграми потоків даних (DFD - Data Flow Diagram) є основним засобом моделювання функціональних вимог проектованої системи.

1.створюються для моделювання існуючого процесу руху інформації;

2.використовуються для опису документообігу, обробки інформації.

Нотації DFD.

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

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

2.забезпечують проведення аналізу та визначення основних напрямків реінжинірингу ІВ.

Для зображення DFD традиційно використовуються дві різні нотації: Йодана (Yourdon) і Гейна-Сарсона (Gane-Sarson). Їх метою є перетворення загальних, неясних знань про вимоги до системи в точні (наскільки це можливо) визначення.

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

За допомогою DFD-діаграм вимоги до проектованої ІС розбиваються на функціональні компоненти (процеси) і представляються у вигляді мережі, пов'язаної потоками даних. Головна мета декомпозиції DFD-функцій - продемонструвати, як кожен процес перетворить свої вхідні дані у вихідні, а також виявити відносини між цими процесами.

На схемах бізнес-процесу відображаються:

–функції процесу;

–вхідна та вихідна інформація, при описі документів;

–зовнішні бізнес-процеси, описані на інших діаграмах;

–точки розриву при переході процесу на інші сторінки

Основні символи.

На діаграмах функціональні вимоги представляються за допомогою процесів і сховищ, зв'язаних потоками даних.

67

Рисунок 3.19 – Основні компоненти DFD діаграми

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

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

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

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

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

На відміну від стрілок, що описують об'єкти в русі, сховища даних зображують об'єкти в спокої.

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

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

Контекстна діаграма.

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

Кожен проект повинен мати рівно одну контекстну діаграму.

DFD першого рівня будується як декомпозиція процесу, який присутній на контекстній діаграмі.

68

Рисунок 3.20 - DFD діагарма першого рівня

Розробка контекстної діаграми включає визначення:

–суб'єкта моделювання - визначення, що входить до складу моделі, а що з неї виключено;

–мети, як критерію закінчення моделювання;

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

–обмежень, що накладаються на об'єкт;

–побудова діаграми верхнього рівня та її узагальнення.

Декомпозиція даних.

Для забезпечення декомпозиції даних до DFD додаються типи об'єктів, представлені на рис.3.21.

Рисунок 3.21 - Типи об’єків, що використовуються при декомпозиції даних

Груповий вузол. Призначений для розщеплення і об'єднання потоків.

Вузол-предок. Дозволяє пов'язувати вхідні та вихідні потоки між процесом та DFD, що деталізуються.

69

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

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

Текст у вільному форматі в будь-якому місці діаграми.

Побудова діаграми

Рекомендації при побудові моделі

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

Рекомендації при побудові моделі

Не загромаджувати діаграми несуттєвими на даному рівні деталями.

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

Вибирати ясні, що відображають суть справи, імена процесів і потоків для поліпшення розуміння діаграм, при цьому намагатися не використовувати абревіатури.

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

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

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

Етапи побудови моделі

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

2.Ідентифікація зовнішніх об'єктів, з якими система повинна бути пов'язана.

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

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

5.Вивчення попередньої контекстної діаграми і внесення до неї змін за результатами відповідей на виникаючі при цьому вивченні питання по всіх її частинах.

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

7.Формування DFD першого рівня на базі процесів попередньої контекстної діаграми

8.Перевірка основних вимог по DFD першого рівня

9.Декомпозиція кожного процесу поточної DFD за допомогою деталізуючої діаграми або специфікації процесу

10.Перевірка основних вимог по DFD відповідного рівня

11.Додавання визначень нових потоків в словник даних при кожній їх появі на діаграмах

70

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

13.Проведення ревізії після побудови двох-трьох рівнів з метою перевірки коректності та поліпшення розуміння моделі

Приклад побудови DFD діаграми

Рисунок 3.22 - Контекстна діаграма системи «Обробка замовлень клієнтів»

Рисунок 3.23 - Діаграма деталізації першого рівня системи «Обробка замовлень клієнтів»

Приклад 2 побудови DFD діаграми