Функціональне моделювання інформаційних систем 

Стислий огляд 

Малюнок 4-1 - типова потокова діаграма. 

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

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

Схематичне зображення потоків даних головним чином пов'язано з розвитком програмних додатків, тому що воно і створено для тієї цілі. Особливі представлення у вигляді прямокутника,  використовані в прикладах були обрані Крісом Ганом і Трішом Сарсоном, авторами методу DFD Гана і Сарсона. Процеси подані як прямокутники з округленими кутами. Опис також  відноситься і до методу DFD Йордона/ДеМарко, у якому кола (також що називаються кульками) представляють процеси. Метод DFD Йордона/ДеМарко був винайдений Эдвардом Иоурдоном і Томом ДеМарко.

Синтаксис і Семантика Моделі DFD

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

Ділова Система. Число (малюнок) 4-2 - типова потокова діаграма контексту.

Додавання зовнішніх об'єктів не змінює фундаментальну вимогу.

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

Малюнок 4-2. Типова контекстна потокова діаграма.

Процес ДІАГРАМИ ПОТОКІВ ДАНИХ подає функцію, що опрацьовує або перетворює входи у виходи. Як правило намальовані у вигляді прямокутників із закругленими кутами процеси в діаграмах потоків даних синонімічні з процесами в IDEF0 і IDEF3. Подібно процесам IDEF3, процеси ДІАГРАМИ ПОТОКІВ ДАНИХ мають входи і виходи, але не підтримують засоби керування або механізми у вигляді стрілок, як у IDEF0. У деяких реалізаціях діаграм потоків даних Гана і Сарсона, IDEF0 механізми змодельовані як ресурси і зображені в основі прямокутника (Малюнок 4-3).

Малюнок 4-3.  Приклад потокового схематичного зображення Гана і Сарсона

Зовнішні Сутности

Зовнішні сутности забезпечують входи у систему, і/або приймають виходи.

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

Малюнок 4-4. Приклад зовнішньої сутності.

Стрілки (Потік даних)

Стрілки описують рух об'єктів від однієї частини системи до іншої. Оскільки сторони прямокутника процесу ДІАГРАМИ ПОТОКІВ ДАНИХ не мають виділеної функції ( як у IDEF0, де кожна сторона прямокутника має визначене значення), стрілки можуть виходити з будь-якої частини процесу. Діаграми потоків даних також використовують двунаправлену стрілку, щоб показувати скоординований діалог команда - відповідь між двома процесами, між процесом  і зовнішньою сутністю, і між зовнішніми сутностями. Наприклад малюнок 4-5 ілюструє двунаправлену стрілку, що представляє

Скоординований обмін між Комп'ютерною Системою Розпізнавання письма Ділова Система і Клієнт.  

Малюнок 4-5.  Двунаправлена стрілка, що з'єднує процес і зовнішній об'єкт.

Сховище Даних  

Приймаючи до уваги, що потоки подають об'єкти в русі, сховища даних подають об'єкти в стані спочинку.

У системі переробки сховище даних - це місце, де незавершені роботи інвентаризуються - типу черги, у системі обробки даних сховище даних наводять будь-який механізм, за допомогою якого дані зберігаються для наступного опрацювання. Малюнок 4-6 ілюструє типове сховище даних. 

Малюнок 4-6. Приклад сховища даних.

Розгалуження і З'єднання  

Стрілка ДІАГРАМИ ПОТОКІВ ДАНИХ може бути розбита (розгалужена), і сегменти стрілки можуть бути повторно пойменовані, щоб показувати декомпозицію даних, що пройшли по потоку.  Малюнок 4-7 показує приклад декомпозиції стрілки інформації клієнта на три окремі стрілки. 

Малюнок 4-7. Стрілка, що показує декомпозицію даних.   

Стрілки можуть також об'єднуватися (приєднуватися), щоб формувати складові об'єкти. Малюнок 4-8 показує приклад.

Малюнок 4-8.    Приклад стрілок, що об'єднуються, що формують складений об'єкт. 

Побудова ДІАГРАМИ ПОТОКІВ ДАНИХ  

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

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

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

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

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

Сховища Даних додані, щоб моделювати дані, які необхідно пам'ятати між подіями. Потоки додані, щоб підключити інші елементи, і діаграма перевіряється моделлю навколишнього середовища на логічність. 

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

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

Об'єктна Нумерація 

У ДІАГРАМІ ПОТОКІВ ДАНИХ, кожний номер процесу може включати префікс, номер батьківської діаграми, і номер об'єкта. Малюнок 4-9 показує приклад. Номер об'єкта унікально ідентифікує процес на діаграмі.  Номер батьківської діаграми і номер об'єкта разом унікально идентифікує кожний процес у вашій моделі. 

Малюнок 4-9.   Компоненти номера процесу ДІАГРАМИ ПОТОКІВ ДАНИХ. 

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

Кожний номер сховища даних може включати префікс D і унікальний номер сховища 

Малюнок 4-10.   Нумерація сховища даних ДІАГРАМИ ПОТОКІВ ДАНИХ. 

Точно так само кожне зовнішнє посилання може включати префікс E і унікальний зовнішній номер об'єкта (Малюнок 4-11)

Малюнок 4-11.   Зовнішня нумерація об'єкта ДІАГРАМИ ПОТОКІВ ДАНИХ . 

Вартість, заснована на процесах і методика виконання 

Стислий огляд 

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

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

Числення, засноване на процесах

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

Модель Вартості, заснованої на процесах 

Проект системи АВС, відобразить операції компанії, тому що він заснований на процесах. Оскільки може бути дорого реалізувати систему АВС, важливо зосередитися на істотних витратах, що несе компанія.

Метод моделювання функції IDEF0 

Короткий огляд IDEF0 

Моделювання діяльності IDEF0 – методика для аналізу цілих систем, як набору взаємозв'язаних діяльностей або функцій. Це чисто функціональний напрямок: функції (дієслова) системи проаналізовані незалежно від об'єкта/об'єктів. Ідея полягає в тому, що компанування функцій в межах системи може бути виконане як частина нового процесу проектування, але невідповідна, і можливо, навіть, як помилкова частину аналізу. 

Малюнок 3-1. Типова діаграма IDEF0. 

IDEF0 краще пристосований до аналізу та методики логічного проектування. Як такий, метод взагальному використовується на ранніх стадіях проекту, передуючи IDEF3 моделюванню для збору даних та AS-IS моделюванню процесу. Аналіз, що використовує IDEF0 моделювання сприяє процесу проектування.

З повагою ІЦ "KURSOVIKS"!