
- •1. Системний підхід при створення інформаційно-управляючих систем (іус)
- •1.1. Загальні відомості про автоматизовані системи управління та інформаційно-управляючі системи
- •Вхід вплив вихід
- •Автоматизовані системи управління та інформаційно-управляючі системи
- •1.2 Основні принципи створення асу (іус)
- •Основний виробничий
- •Допоміжний виробничий
- •Контроль і аналіз
- •1.3. Підходи до створення іус
- •2. Інструментальні засоби концептуального проектування
- •2.1. Загальні відомості про case
- •2.2. Методологія функціонального моделювання idef0
- •2.2.1 Моделі idef0
- •2.2.3 Межі і зв'язки
- •2.2.4 Тунелі
- •2.3 Побудова моделей idef0
- •2.3.1 Діаграми
- •2.3.2 Цикл "експерт-аналітик"
- •2.3.3 Побудова моделей
- •2.3.4 Точка зору
- •2.3.5 Розгалуження і сполучення моделей
- •2.3.6 Межі моделювання
- •2.3.7 Вибір найменування контекстного блоку
- •2.2.8 Визначення стрілок на контекстній діаграмі
- •2.3.9 Нумерація блоків і діаграм
- •2.3.10 Зв'язок між діаграмою і її батьківським функціональним блоком
- •2.3.11 Два підходи до початку моделювання ("завширшки" і "в глибину")
- •2.3.12 Завершення моделювання
- •2.3.13 Інші діаграми idef0
- •3. Методологія опису процесів бізнесу idef3
- •3.1. Призначення діаграм idef3
- •3.2. Два типи діаграм в idef3
- •3.3. Синтаксис і семантика моделей idef3
- •3.3.1 Моделі idef3
- •3.3.2.Типи зв'язків
- •3.3.3 З'єднання та розгалуження
- •3.3.4 Покажчики
- •3.3.5 Вимоги idef3 до опису процесів бізнесу
- •4. Структурний аналіз потоків даних (dfd — data flow diagrams)
- •4.1. Призначення діаграм потоків даних
- •4.2. Синтаксис і семантика діаграм потоків даних
- •4.2.1 Функціональні блоки
- •4.2.2 Зовнішні сутності
- •4.2.3 Стрілки (потоки даних)
- •4.2.4 Сховища даних
- •4.2.5 Галуження і об'єднання
- •4.3 Побудова діаграм потоків даних
- •4.3.1 Два підходи до побудови dfd-моделей
- •4.3.2 Нумерація об'єктів
- •Використані джерела інформации
2.3.7 Вибір найменування контекстного блоку
Рекомендованою послідовністю дій при побудові моделі "з нуля" є:
формулювання мети моделювання,
вибір точки зору,
визначення меж моделювання.
Найменування контекстного блоку — функціонального блоку найвищого рівня — узагальнює визначення меж моделювання.
Правила підбору імені для контекстного блоку в цілому не відрізняються від загальних правил найменування функціональних блоків, тому для них звичайно підбирають узагальнюючі назви, типу "Управління відділом по роботі з клієнтами", "Обробка замовлень" і т.п.
2.2.8 Визначення стрілок на контекстній діаграмі
Стрілки діаграм IDEF0 звичайно простіше проектувати в наступному порядку: вихід, вхід, механізм виконання, управління. Кожен функціональний блок позначає окрему функцію, і ця функція часто має ясно і стисло описувані результати роботи. Наявність незрозумілостей при аналізі виходів того або іншого функціонального блоку — можливий сигнал необхідності проведення реінжинірінга даного процесу бізнесу.
Визначення виходів. Після ідентифікації можливих виходів корисно провести аналіз моделі на предмет покриття нею всіх можливих сценаріїв поведінки процесу. Це означає, що якщо існує вірогідність виникнення тієї або іншої ситуації в ході процесу, модель відображає можливість виникнення такої ситуації. Багато аналітиків-початківців забувають відобразити негативні результати роботи функціональних блоків. Наприклад, блок "Провести екзамен з водіння" безумовно проведе потік водіїв, які тільки що отримали права, але цілком правомірно чекати і потоку осіб, що не склали іспит. Негативні результати часто використовуються як зворотні зв'язки, аналіз на їх наявність повинен проводитися для кожного блоку. Важливою також є необхідність включення в модель спірних стрілок, ухвалення рішення про наявність яких в моделі цілком можна перекласти на плечі тих, що рецензують модель експертів.
Визначення входів. Входи можна розглядати як особливим образом перетворювані функціональними блоками для виробництва виходу сировину або інформацію. У виробничих галузях визначити як вхідна сировина перетвориться в готову продукцію звичайно досить просто. Проте при моделюванні інформаційних потоків вхідний потік даних може представлятися не споживаним і не оброблюваним взагалі. Випадки, коли стрілки, що входять, і стрілки, що виходять, називаються в точності однаково, вкрай рідкісні і в основному указують на даремність даного блоку для системи в цілому або на некоректний вибір імені для стрілки, що витікає. Рішенням може служити застосування докладнішого опису для вхідних і вихідних потоків даних. Наприклад, вхід може мати назва "Попередній діагноз пацієнта", а вихід — "Уточнений діагноз пацієнта".
Визначення механізмів виконання. Після створення входів і виходів можна приступити до розгляду механізмів виконання, або ресурсів, що відносяться до функціонального блоку. У поняття механізму виконання входять персонал, устаткування, інформаційні системи і т.п. Наприклад, функціональний блок "Зібрати деталь" може зажадати використання якого-небудь устаткування, наприклад, гайкового ключа. При прийомі іспитів на водійські права механізмом виконання є інспектор ДАІ. Як правило визначити механізми виконання для функціональних блоків досить просто.
Визначення управління. Повинне бути визначене управління, що контролює хід роботи функціонального блоку. Всі функціональні блоки в IDEF0 повинні мати хоч би одне управління. У випадках, коли не ясно, чи відносити стрілку до входу або до управління, слід її визначати як управління. Важливо пам'ятати, що управління можна розглядати як особливу форму входу функціонального блоку. Коли контекстна діаграма представляється завершеною, спробуйте поставити наступні питання:
• Чи узагальнює діаграма модельований бізнес-процес?
• Чи узгоджується діаграма з межами моделювання, точкою зору і метою моделювання?
• Чи підходить вибраний рівень деталізації стрілок для контекстного блоку? (Звичайно на контекстній діаграмі рекомендується рисувати не більше шести стрілок кожного типа.)