Лабораторна робота № 7 Побудова структурних карт Константайна та Джексона
Мета: вивчити питання проектування програмного забезпечення.
Теоретичні відомості:
Проектування – це фаза ЖЦ, на якій виробляється, як реалізуються вимоги користувача, які породжені і зафіксовані на фазі аналізу. На цьому етапі здійснюється побудова моделі реалізації (або фізичної моделі), що демонструє як система задовольнятиме вимоги, які до неї ставлять. Фактично структурне проектування є мостом між структурним аналізом і реалізацією.
На цій фазі ЖЦ насамперед необхідно визначити структурні компоненти і зв’язки між ними. Отримана в результаті структура ПЗ повинна бути представлена у вигляді структурної і/або функціональної схем і специфікації її компонентів.
Структурною називають схему, що відображає склад і взаємодію по управлінню частин проектуючого програмного забезпечення.
Хід роботи:
1. На основі технічного завдання та ескізного проекту з попередніх лабораторних робіт розробити структурну схему програмного продукту.
2. Розробити функціональну схему програмного продукту.
3. Уточнити алгоритми програм, використовуючи метод покрокової деталізації.
4. Представити структурну схему у вигляді структурних карт Константайна.
5. Представити структурну схему у вигляді структурних карт Джексона.
Контрольні питання:
1. Етапи розробки програмного забезпечення.
2. Проектування програмного забезпечення.
3. Структурний підхід до програмування.
4. Структурна і функціональна схеми.
5. Методика Константайна.
6. Методика Джексона.
Лабораторна робота № 8-9 Ознайомлення з інструментальним середовищем Врwin. Розробка sadt-моделі
Мета роботи:
Вивчити головні принципи методології IDEF0, принципи побудови моделей IDEF0, отримати загальне уявлення про процеси, діаграми, зв’язки тощо, а також набути загальні навички роботи з діаграмами IDEF0 шляхом створення нового проекту у BPwin.
Теоретичні відомості:
Стандарт IDEF0 описує методику побудови функціональної моделі предметної області. Основна ідея даної методології полягає у представленні процесу, що моделюється, у вигляді сукупності взаємопов'язаних робіт (процесів, функцій). Роботи утворюють ієрархічну структуру, коренем якої є основна функція процесу, що моделюється.
У відповідності із даним стандартом розрізняють наступні види моделей:
модель AS-IS, яка описує стан модельованої предметної області на момент створення моделі;
модель TO-BE, яка описує можливий майбутній стан предметної області, в які вона перейде у результаті оптимізації існуючої системи і впровадження нових технологій.
Моделювання ділових процесів, як правило, виконується за допомогою CASE-засобів. До таких засобів, окрім BPwin (PLATINUM technology), відносяться Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software) тощо. Функціональні можливості інструментальних засобів структурного моделювання ділових процесів будуть розглянуті на прикладі CASE - засобу BPwin.
Крім побудови моделі дане інструментальне середовище дозволяє здійснювати вартісний аналіз, заснований на роботах (Activity Based Costing, ABC) і аналіз, застований на властивостях, які визначаються користувачем (User Defined Properties, UDP). BPwin підтримує три методології моделювання: функціональне моделювання (IDEF0); опис бізнес-процесів (IDEF3); діаграми потоків даних (DFD).
Інструментальне середовище BPwin
BPwin має достатньо простий та інтуїтивно зрозумілий інтерфейс користувача. При запуску BPwin по замовчуванню з'являється головна панель інструментів, палітра інструментів (вигляд якої залежить від вибраної нотації) і, у лівій частині, навігатор моделі - Model Explorer (рис. 1).
При створенні нової моделі виникає діалог, у якому необхідно вказати, чи буде створюватись нова модель або вона буде відкрита з файлу або з репозиторію Modelmart, потім вписати назву моделі і вибрати методологію, у якій буде побудована модель (рис. 2).
Як було вказано вище, BРwin підтримує три методології - IDEF0, IDEF3 і DFD, кожна з яких вирішує свої специфічні завдання. У BРwin можлива побудова змішаних моделей, тобто модель може містити одночасно діаграми як IDEF0, так і IDEF3 і DFD. Склад палітри інструментів змінюється автоматично, коли відбувається перемикання з однієї нотації на іншу.
Рисунок 1 – Інтегроване середовище розробки моделі BPwin
Рисунок 2 – Діалог створення моделі
Модель в BРwin розглядається як сукупність робіт, кожна з яких оперує з деяким набором даних. Робота зображається у вигляді прямокутників, дані - у вигляді стрілок. Якщо клацнути по будь-якому об'єкту моделі лівою кнопкою миші, з'являється контекстне меню, кожний пункт якого відповідає редакторові певної властивості об'єкту.
Визначення властивостей моделі IDEF0
На початкових етапах створення ІС необхідно зрозуміти, як працює організація, яку збираються автоматизувати. Керівник добре знає роботу в цілому, але не в змозі вникнути в деталі роботи кожного рядового співробітника. Рядовий співробітник добре знає, що віддбувається на його робочому місці, але може не знати, як працюють колеги. Тому для опису роботи підприємства необхідно побудувати модель, яка буде адекватна предметній області і містити в собі знання всіх учасників бізнес-процесів організації.
Найзручнішою мовою моделювання бізнес-процесів є IDEF0, де система представляється як сукупність взаємодіючих робіт/процесів або функцій. Така чисто функціональна орієнтація є принциповою - функції системи аналізуються незалежно від об'єктів, якими вони оперують. Це дозволяє чіткіше змоделювати логіку і взаємодію процесів організації.
Створення моделі в стандарті IDEF0 ропочинається з діалогу створення моделі, в якому задається назва моделі і вибирається тип моделі.
Далі задаються властивості моделі (діалог Model Properties). Діалог містить наступні вкладки: Layout, ABC Units, Page Setup, Header/Footer, Shapes, Drawstyle, General, Purpose, Definition, Source, Status, Numbering, Display. Вкладка General призначена для завдання прізвища та ініціалів автора. Вкладка Purpose призначена для завдання меті моделювання (Purpose) і точки зору (Viewpoint).
Далі процес моделювання системи в IDEF0 продовжується створенням контекстної діаграми - діаграми найабстрактнішого рівня опису системи в цілому, що містить визначення суб'єкта моделювання, цілі і точки зору на модель.
Під суб'єктом розуміється сама система, при цьому необхідно точно встановити, що входить у систему, а що лежить за її межами, іншими словами, визначити, що надалі розглядатиметься як компоненти системи, а що як зовнішня дія. На визначення суб'єкта системи істотно впливатимуть позиція, з якої розглядається система, і мета моделювання - питання, на які побудована модель повинна дати відповідь. Іншими словами, на початку необхідно визначити область моделювання. Опис області як системи в цілому, так і її компонентів є основою побудови моделі. Хоча передбачається, що в процесі моделювання область може коректуватися, вона повинна бути в основному сформульована спочатку, оскільки саме область визначає напрям моделювання. При формулюванні області необхідно враховувати два компоненти - ширину і глибину. Ширина має на увазі визначення меж моделі - що розглядатиметься усередині системи, а що зовні. Глибина визначає, на якому рівні деталізації модель є завершеною. При визначенні глибини системи необхідно пам'ятати про обмеження часу - трудомісткість побудови моделі росте в геометричній прогресії із збільшенням глибини декомпозиції. Після визначення меж моделі передбачається, що нові об'єкти не повинні вноситися до модельованої системи.
Мета моделювання визначається з відповідей на наступні запитання:
Чому цей процес необхідно промоделювати?
Що повинна показувати модель?
Що може отримати клієнт?
Під точкою зору (Viewpoint)розуміється перспектива, з якої спостерігалася система при побудові моделі. Хоча при побудові моделі враховуються думки різних людей, всі вони повинні дотримуватися єдиної точки зору на модель. Точка зору повинна відповідати меті і межам моделювання. Як правило, вибирається точка зору людини, відповідальної за модельовану роботу в цілому. Існує можливість зафіксувати інші точки зору за допомогою додаткових діаграм.
IDEF0-модель припускає наявність чітко сформульованої мети, єдиного суб'єкта моделювання і однієї точки зору. Для внесення області, мети і точки зору в моделі IDEF0 в Bpwin необхідно вибрати пункт меню Model/Model Properties, що викликає діалог Model Properties (рис. 4.3). У закладці Purpose слід внести мету і точку зору, а в закладку Definition - визначення моделі і опис області.
Рисунок 3 – Діалог задання властивостей моделі
У закладці Status цього ж діалогу можна описати статус моделі (чорновий варіант, робочий, остаточний тощо), час створення і останнього редагування (надалі відстежується автоматично за системною датою). У закладці Source описуються джерела інформації для побудови моделі (наприклад, "Досвід експертів предметної області і аналіз документації"). Закладка General служить для внесення назви проекту і моделі, імені автора і тимчасових рамок моделі - AS-IS і ТО-ВЕ.
Моделі AS-IS і ТО-ВЕ.
Звичайно спочатку будується модель існуючої організації роботи - AS-IS (як є). Аналіз функціональної моделі дозволяє зрозуміти, де знаходяться найслабші місця, у чому полягатимуть переваги нових бізнес-процесів і наскільки глибоким змінам піддасться існуюча структура організації бізнесу. Деталізація бізнес-процесів дозволяє виявити недоліки організації навіть там, де функціональність на перший погляд здається очевидною. Знайдені в моделі AS-IS недоліки можна виправити при створенні моделі ТО-ВЕ (як буде) - моделі нової організації бізнес-процесів.
Технологія проектування ІС передбачає спочатку створення моделі AS-IS, її аналіз і покращення бізнес-процесів, тобто створення моделі ТО-ВЕ, і лише на основі моделі ТО-ВЕ будується модель даних, прототип, а потім і остаточний варіант ІС.
Іноді поточні AS-IS і майбутня ТО-ВЕ моделі відрізняються дуже сильно, так що перехід від початкового до кінцевого стану стає неочевидним. У цьому випадку необхідна третя модель, що описує процес переходу від початкового до кінцевого стану системи, оскільки такий перехід - це теж бізнес-процес.
Результат опису моделі можна отримати в звіті Model Report. Діалог налаштуваня звіту по моделі викликається з пункту меню Tools/Reports/Model Report.
У діалозі налаштуваня необхідно вибрати потрібні поля, при цьому автоматично відображається черговість виведення інформації у звіт (рис. 4).
Рисунок 4 – Діалогове вікно для формуання звіту по моделі
На рис. 5 представлений звіт, сформований за вищезгаданими полями.
Рисунок 5 – Попередній перегляд звіту
Побудова контекстної діаграми
Основу методології IDEF0 складає графічна мова опису бізнес-процесів. Модель в нотації IDEF0 є сукупністю ієрархічно впорядкованих і взаємопов'язаних діаграм. Кожна діаграма є одиницею опису системи і розташовується на окремому листі.
Модель може містити чотири типи діаграм:
контекстну діаграму (у кожній моделі може бути тільки одна контекстна діаграма);
діаграми декомпозиції;
діаграми дерева вузлів;
діаграми тільки для експозиції (FEO).
Контекстна діаграма є вершиною деревовидної структури діаграм і є найзагальнішим описом системи і її взаємодії із зовнішнім середовищем. Після опису системи в цілому здійснюється її розбиття на крупні фрагменти. Цей процес називається функціональною декомпозицією, а діаграми, які описують кожен фрагмент і взаємодію фрагментів, називаються діаграмами декомпозиції. Після декомпозиції контекстної діаграми проводиться декомпозиція кожного великого фрагмента системи на дрібніші і так далі, до досягнення потрібного рівня подробиці опису. Після кожного сеансу декомпозиції проводяться сеанси експертизи - експерти предметної області вказують на відповідність реальних бізнес-процесів створеним діаграмам. Знайдені невідповідності виправляються, і лише після проходження експертизи без зауважень можна приступати до наступного сеансу декомпозиції. Так досягається відповідність моделі реальним бізнес-процесам на будь-якому і кожному рівні моделі. Синтаксис опису системи в цілому і кожного її фрагмента однаковий у всій моделі.
Діаграма дерева вузлів показує ієрархічну залежність робіт, але не взаємозв'язки між роботами. Діаграм дерев вузлів може бути у моделі скільки завгодно багато, оскільки дерево може бути побудоване на довільну глибину і не обов'язково з кореня.
Діаграми для експозиції (FEO) будуються для ілюстрації окремих фрагментів моделі, для ілюстрації альтернативної точки зору, або для спеціальних цілей.
Роботи/процеси (Activity) позначають поіменовані процеси, функції або завдання, які відбуваються протягом певного часу і мають розпізнавальні результати. Роботи зображаються у вигляді прямокутників. Всі роботи повинні бути названі і визначені. Назва роботи повинна бути виражені віддієслівними іменниками, що позначають дію (наприклад, "Діяльність компанії", "Прийом замовлення" тощо). Робота "Діяльність компанії" може мати, наприклад, наступне визначення: "Це навчальні модель, що описує діяльність компанії". При створенні нової моделі (меню File/New) автоматично створюється контекстна діаграма з єдиною роботою, що зображає систему в цілому (рис. 6).
Рисунок 6 – Приклад контекстної діаграми
Для внесення назви роботи слід клацнути по роботі правою кнопкою миші, вибрати в меню Name Editor і у діалозі, що з'явився, внести назву роботи. Для опису інших властивостей роботи служить діалог Activity Properties (рис. 7).
Рисунок 7 – Редактор задання властивостей роботи
Діаграми декомпозиції
Деталізація головної функції системи здійснюється за допомогою діаграм декомпозиції, які будуються за тим самим принципом, що і контекстна, але включає більшу кількість робіт. Кожна робота, у свою чергу, може бути декомпонована.
Всі роботи у діаграмі декомпозиції зв’язуються між собою за допомогою стрілок. Зв’язки моделюють реальні процеси, що відносяться до об’єктів, які керують діями, і механізмів.
Діаграми декомпозиції
містять споріднені роботи, тобто
дочірні роботи, що мають загальну
батьківську роботу. Для
створення діаграми декомпозиції
необхідно клацнути по кнопці
на панелі інструментів.
Виникає діалог Activity Box Count (рис. 8), в якому необхідно вказати нотацію нової діаграми і кількість робіт на ній. Зупинимося на нотації IDEF0 і клацнемо на ОК. З'являється діаграма декомпозиції (рис. 9). Допустимий інтервал кількості робіт - 2-8. Декомпонувати роботи на одну роботу не має сенсу: діаграми з кількістю робіт більше восьми виходять перенасиченими і погано читаються. Для забезпечення наочності і кращого розуміння модельованих процесів рекомендується використовувати від трьох до шести блоків на одній діаграмі.
Рисунок 8 – Діалог Activity Box Count
Рисунок 9 – Приклад діаграми декомпозиції
Якщо виявляється, що кількість робіт недостатня, то роботу можна додати в діаграму, клацнувши спочатку по кнопці на палітрі інструментів, а потім по вільному місцю на діаграмі.
Роботи на діаграмах декомпозиції звичайно розташовуються по діагоналі від лівого верхнього кута до правого ніжнього.
Такий порядок називається порядком домінування. Згідно цього принципу розташування у лівому верхньому куті поміщається найважливіша робота або робота, що виконується за часом першою. Далі вправо вниз розташовуються менш важливі або роботи виконувані пізніше. Таке розміщення полегшує читання діаграм, крім того, на цьому ґрунтується поняття взаємозв'язків робіт.
Кожна з робіт на діаграмі декомпозиції може бути у свою чергу декомпонована. На діаграмі декомпозиції роботи нумеруються автоматично зліва направо. Номер роботи відображається у правому нижньому куті. У лівому верхньому куті зображається невелика діагональна межа, яка показує, що дана робота не була декомпонована. Так, на рис. 9 всі роботи ще не були декомпоновані.
Стрілки(Arrow) описують взаємодію робіт і є певною інформацією, яка виражена іменниками.(Наприклад, "Дзвінки клієнтів", "Правила і процедури", "Бухгалтерська система".)
У таблиці 1 наведені основні «бідівельні блоки» для діаграм IDEF0.
Таблиця 1.
№ |
Назва |
Опис елемента IDEF0 діаграми |
Графічне представлення |
1 |
Модуль поведінки (UOB) |
Об’єкт служить для опису функцій (процесів, процедур, робіт), які виконуються підрозділами/співробітниками підприємства. |
|
2 |
Стрілка зліва |
Стрілка описує вхідні документи, інформацію, матеріальні ресурси, необхідні для виконання функції. |
|
3 |
Стрілка справа |
Стрілка описує вихідні документи, інформацію, матеріальні ресурси, які є результатом виконання функції. |
|
4 |
Стрілка зверху |
Стрілка описує керуючі впливи, наприклад, розпорядження, нормативний документ тощо. У нотації IDEF0 кожні процедура повинна обов’язково мати не менше однієї стрілки зверху, яка відображає керуючий вплив. |
|
5 |
Стрілка знизу |
Стрілка знизу описує т.з. механізми, тобто ресурси, необхіднідля виконання процедури, але не змінює в процесі її виконання свій стан. Приклади: співробітник, верстат тощо. |
|
6 |
Стрілка вниз |
Стрілка вниз відображає зв’язок між різними діаграмами або моделями, вказуючи на деяку діаграму, де дана робота розглянута детальніше. |
|
Всі роботи і стрілки повиннні бути поіменовані.
Детальніше розглінемо типи стрілок, які використовуються у IDEF0:
Вхід (Input) - матеріал або інформація, які використовуються або перетворюються роботою для отримання результату (виходу). Допускається, що робота може не мати жодної стрілки входу. Кожний тип стрілок підходить до певної сторони прямокутника, який відображає роботу, або виходить з неї. Стрілка входу входить у ліву грань роботи. Під час опису технологічних процесів не виникає проблем з визначенням входів. Дійсно, "Дзвінки клієнтів" на рис. 4.6 - це щось, що переробляється у процесі "Діяльність компанії" для отримання результату. При моделюванні ІС, коли стрілками є не фізичні об'єкти, а дані, не все є таким очевидним. Наприклад, при "Прийомі пацієнта" карта пацієнта може бути і на вході і на виході, тим часом якість цих даних змінюється. Іншими словами, у прикладі для того, щоб виправдати своє призначення, стрілки входу і виходу повинні бути точно визначені з тим, щоби вказати на те, що дані дійсно були оброблені (наприклад, на виході - "Заповнена карта пацієнта"). Дуже часто складно визначити, чи є дані входом або керуванням. У цьому випадку підказкою може виступати інформація про те, чи переробляються /змінюються дані в роботі чи ні. Якщо змінюються, то, швидше за все, це вхід, якщо ні - управління.
Керування (Control) - правила, стратегії, процедури або стандарти, якими керується робота. Кожна робота повинна мати хоча б одну стрілку керування. Стрілка керування входить у верхню грань роботи. На рис. 6 стрілка "Правила і процедури" - керування для роботи "Діяльність компанії". Керування впливає на роботу, але не перетворюється роботою. Якщо мета роботи - змінити процедуру або стратегію, то така процедура або стратегія буде для роботи входом. У разі виникнення невизначеності у статусі стрілки (керування або вхід) рекомендується рисувати стрілку керування.
Механізм (Mechanism) - ресурси, які виконують роботу, наприклад персонал підприємства, верстати, пристрої тощо. Стрілка механізму входить в нижню грань роботи. На рис. 6 стрілка "Бухгалтерська система" є механізмом для роботи "Діяльність компанії". На розсуд аналітика стрілки механізму можуть не зображатися в моделі.
Виклик (Call) - спеціальна стрілка, яка вказує на іншу модель роботи. Стрілка виклику рисується витікаючою з нижньої грані роботи. На рис. 10 стрілка "Інша модель роботи" є викликом для роботи "Виготовлення виробу". Стрілка виклику використовується для вказання того, що деяка робота виконується за межами модельованої системи. У Bpwin стрілки виклику використовуються в механізмі злиття і розділення моделей.
Рисунок 10 – Стрілка виклику, яка з’являється при розщеплені моделі
Граничні стрілки. Стрілки на контекстній діаграмі служать для опису взаємодії системи з навколишнім світом. Вони можуть починатися біля границі діаграми і закінчуватися біля роботи, або навпаки. Такі стрілки називаються граничними.
Для внесення граничної стрілки входу необхідно:
клацнути по кнопці із символом стрілки
;
в палітрі інструментів перенести курсор до лівої сторони екрану, поки не з’явиться початкова штрихова смуга;
клацнути один раз по смузі (звідки виходить стрілка) і ще раз в лівій частині роботи зі сторони входу (де закінчується стрілка);
вернутися в палітру інструментів і вибрати опцію редагування стрілки
;
клацнути правою кнопкою миші на лінії стрілки, у спливаючому меню вибрати Name і додати назву стрілки в закладці Name діалогу IDEF0 Arrow Properties.
Стрілки керування, входу, механізму і виходу зображаються аналогічно. Назви нових стрілок (рис. 11) автоматично заносяться до словника Arrow Dictionary.
Рисунок 11 – Діалог IDEF0 Arrow Properties
ICOM-коди. Діаграма декомпозиції призначена для деталізації роботи. На відміну від моделей, що відображають структуру організації, робота на діаграмі верхнього рівня в IDEF0 - це не елемент керування роботами нижнього рівня. Роботи нижнього рівня - це те саме, що роботи верхнього рівня, але в детальнішому викладі. Як наслідок цього границі роботи верхнього рівня - це те саме, що границі діаграми декомпозиції. ICOM (абревіатура від Input, Control, Output і Mechanism) - коди, призначені для ідентифікації граничних стрілок. Код ICOM містить префікс, який відповідає типу стрілки (I, C, O або M), і порядковий номер.
Bpwin вносить ICOM-коди автоматично. Для відображення ICOM-кодів необхідно включити опцію ICOM codes на закладці Display діалогу Model Properties (меню Model/model Properties) (рис.12).
Словник стрілок редагується за допомогою спеціального редактора Arrow Dictionary Editor, в якому визначається стрілка і вноситься коментар, який стосується її (рис. 13). Словник стрілок вирішує дуже важливу задачу. Діаграми створюються аналітиком для того, щоб провести сеанс експертизи, тобто обговорити діаграму з фахівцем предметної області. У будь-якій предметній області формується професійний жаргон, причому дуже часто жаргонні вирази мають нечіткий зміст і сприймаються різними фахівцями по-різному. У той же час аналітик - автор діаграм повинен вживати ті вирази, які найзрозуміліші експертам. Оскільки формальні визначення часто складні для сприйняття, аналітик вимушений вживати професійний жаргон, а щоб не виникло неоднозначних трактувань, у словнику стрілок кожному поняттю можна дати розширене і, якщо це необхідно, формальне визначення.
Рисунок
12 –
Включення
опції
ICOM codes на
закладці
Display
Рисунок 13 – Редагування словника стрілок
Вміст словника стрілок можна роздрукувати у вигляді звіту (меню Tools/ Report /Arrow Report...) і отримати тлумачний словник термінів предметної області, який використовуються в моделі.
Незв'язані граничні стрілки (unconnected border arrow). При декомпозиції роботи її вхідні і вихідні стрілки (окрім стрілки виклику) автоматично з'являються на діаграмі декомпозиції (міграція стрілок), але при цьому не стосуються робіт. Такі стрілки називаються незв'язаними і сприймаються в Bpwin як синтаксична помилка.
На рис. 14 наведено фрагмент діаграми декомпозиції з незв'язаними стрілками, який генерується Bpwin при декомпозиції роботи "Складання настільних комп'ютерів" (див. рис. 9). Для зв’язування стрілок входу, керування або механізму необхідно перейти у режим редагування стрілок, клацнути по наконечнику стрілки і потім по відповідному сегменту роботи. Для зв’язування стрілки виходу необхідно перейти в режим редагування стрілок, клацнути по сегменту виходу роботи і потім по стрілці.
Рисунок 14 – Приклад незв’язаних стрілок
Внутрішні стрілки. Для зв'язку робіт між собою використовуються внутрішні стрілки, тобто стрілки, які не стосуються межі діаграми, починаються у однієї і кінчаються у іншої роботи.
Для рисування внутрішньої стрілки необхідно у режимі рисування стрілок клацнути по сегменту (наприклад, виходу) однієї роботи і потім по сегменту (наприклад, входу) іншої. У IDEF0 розрізняють п'ять типів зв'язків робіт.
Зв'язок за входом (output-input), коли стрілка виходу вищестоячої роботи (далі - просто вихід) прямує на вхід нижчестоячої (наприклад, на рис. 15 стрілка "Складені комп'ютери" зв'язує роботи "Складання і тестування комп'ютерів" і "Відвантаження і отримання").
Рисунок 15 – Зв’язок за входом
З
в'язок
за керуванням (output-control),
коли вихід вищестоящої роботи прямує
на керування нижчестоячою. Зв'язок за
керуванням показує домінування
вищестоящої роботи. Дані або об'єкти
виходу вищестоящої роботи не
змінюються в нижчестоячій. На рис. 16
стрілка "Замовлення клієнтів"
зв'язує роботи "Продажі і
маркетинг" і "Складання і
тестування комп'ютерів".
Рисунок 16 – Зв’язок за керуванням.
Зворотний зв'язок за входом (output-input feedback), коли вихід нижчестоячої роботи прямує на вхід вищестоящої. Такий зв'язок, як правило, використовується для опису циклів. На рис. 17 стрілка "Результати тестування" зв'язує роботи "Тестування комп'ютерів" і "Відстежування розкладу і керування складанням і тестуванням".
Рисунок 17 – Зворотний зв’язок за входом
Зворотний зв'язок за керуванням (output-control feedback), коли вихід нижчестоячої роботи прямує на керування вищестоящої (стрілка "Результати складання і тестування", рис. 18). Зворотний зв'язок за керуванням часто свідчить про ефективність бізнес-процесу. На рис. 18 об'єм продаж може бути підвищений шляхом безпосереднього регулювання процесів складання і тестування комп'ютерів (виходу) роботи "Складання і тестування комп'ютерів".
Рисунок 18 – Зворотний зв’язок по керуванню
Зв'язок вихід-механізм (output-mechanism), коли вихід однієї роботи прямує на механізм іншої. Цей взаємозв'язок використовується рідше за решту і показує, що одна робота готує ресурси, необхідні для проведення іншої роботи (рис. 19).
Рисунок 19 – Зв’язок вихід-механізм
Явні стрілки. Явна стрілка має джерелом одну-єдину роботу і призначенням теж одну-єдину роботу.
Стрілки, що розгалужуються і зливаються. Одні і ті ж дані або об’єкти, породжені однією роботою, можуть використовуватися відразу у декількох інших роботах. З іншого боку, стрілки, породжені в різних роботах, можуть бути однаковими або однорідними даними або об’єктами, які в подальшому використовуються або переробляються в одному місці. Для моделювання таких ситуацій в IDEF0 використовуються стрілки, що розгалужуються і зливаються. Для розгалуження стрілки потрібно в режимі редагування стрілки клацнути по фрагменту стрілки і по відповідному сегменту роботи. Для злиття двох стрілок виходу потрібно в режимі редагування стрілки спочатку клацнути по сегменту виходу роботи, а потім по відповідному фрагменту стрілки.
Зміст стрілок, що розгалужуються і зливаються, передається іменуванням кожної гілки стрілок. Існують певні правила іменування таких стрілок. Розглянемо їх на прикладі стрілок, що розгалужуються. Якщо стрілка іменована до розгалуження, а після розгалуження жодна з гілок не іменована, то мається на увазі, що кожна гілка моделює ті ж дані або об'єкти, що і гілка до розгалуження (рис. 20).
Рисунок 20 – Приклад іменування стрілки, що розгалужується
Якщо стрілка іменована до розгалуження, а після розгалуження будь-яка з гілок теж іменована, то мається на увазі, що ці гілки відповідають іменуванню. Якщо при цьому будь-яка гілка після розгалуження залишилася неіменованою, то мається на увазі, що вона моделює ті ж дані або об'єкти, що і гілка до розгалуження (рис. 21).
Рисунок 21 – Приклад іменування стрілки, що розгалужується
Недопустимою є ситуація, коли стрілка до розгалуження не іменована, а після розгалуження не іменована будь-яка з гілок. Bpwin визначає таку стрілку як синтаксичну помилку.
Правила іменування стрілок, що зливаються, повністю аналогічні - помилкою вважатиметься стрілка, яка після злиття не іменована, а до злиття не іменована будь-яка з її гілок. Для іменування окремої гілки стрілок, що розгалужуються і зливаються, необхідно виділити на діаграмі тільки одну гілку, після чого викликати редактор назви і присвоїти ім'я стрілці. Це ім'я відповідатиме тільки виділеній гілці.
Тунелювання стрілок.
Знову внесені граничні стрілки на діаграмі декомпозиції нижнього рівня відображаються в квадратних дужках і автоматично не з’являються на діаграмі верхнього рівня (рис. 22)
Рисунок 22 – Невизначена (unresolved) стрілка
Для їх "перетягування" вгору потрібно клацнути правою кнопкою миші по квадратних дужках граничної стрілки і в контекстному меню вибрати команду Arrow Tunnel (рис.23).
Рисунок 23 – Вибір команди з контекстного меню
З’являється діалог Border Arrow Editor (рис.24).
Якщо клацнути по кнопці Resolve Border Arrow, стрілка мігрує на діаграму верхнього рівня, якщо по кнопці Change To Tunnel - стрілка буде тунельована і не потрапить на іншу діаграму. Тунельна стрілка зображається з круглими дужками на кінці (рис. 25).
Рисунок 24 – Діалог Border Arrow Editor
Рисунок 25 – Типи тунелювання стрілок
Тунелювання може бути застосоване для зображення малозначимих стрілок. Якщо на будь-якій діаграмі нижнього рівня необхідно зобразити малозначимі дані або об’єкти, які не обробляються або не використовуються роботами на біжучому рівні, то їх необхідно направити на вищестоячий рівень (на батьківську діаграму). Якщо ці дані не використовуються на батьківській діаграмі, їх потрібно направити ще вище, і так далі У результаті малозначима стрілка буде зображена на всіх рівнях і затруднить читання всіх діаграм, на яких вона присутня. Виходом є тунелювання стрілки на найнижчому рівні. Таке тунелювання називається "не-у-батьківській-діаграмі".
Іншим прикладом тунелювання може бути ситуація, коли стрілка механізму мігрує з верхнього рівня на нижній, причому на нижньому рівні цей механізм використовується однаково у всіх роботах без виключення. (Передбачається, що не потрібно деталізувати стрілку механізму, тобто стрілка механізму на дочірній роботі іменована до розгалуження, а після розгалуження гілки не мають власного імені). У цьому випадку стрілка механізму на нижньому рівні може бути видалена, після чого на батьківській діаграмі вона може тунелюватися, а у коментарі до стрілки або у словнику можна вказати, що механізм використовуватиметься у всіх роботах дочірньої діаграми декомпозиції. Таке тунелювання називається "не-у-дочірній-роботі" (рис. 25).
Нумерація робіт і діаграм.
Всі роботи моделі нумеруються. Номер складається з префікса і числа. Може бути використаний префікс будь-якої довжини, але звичайно використовують префікс А. Контекстна (коренева) робота дерева має номер А0. Роботи i декомпозиції А0 мають номери А1, А2, A3 і так далі. Роботи декомпозиції нижнього рівня мають номер батьківської роботи і черговий порядковий номер, наприклад роботи декомпозиції A3 матимуть номери А31, А32, АЗЗ, А34 і так далі. Роботи утворюють ієрархію, де кожна робота може мати одну батьківську і декілька дочірніх робіт, утворюючи дерево. Таке дерево називають деревом вузлів, а вищеописану нумерацію - нумерацією по вузлах. Діаграми IDEF0 мають подвійну нумерацію. По-перше, діаграми мають номери по вузлу. Контекстна діаграма завжди має номер А-0, декомпозиція контекстної діаграми - номер А0, решта діаграм декомпозиції - номери по відповідному вузлу (наприклад, A1, A2, А21, А213 тощо). Bpwin автоматично підтримує нумерацію по вузлах, тобто при проведенні декомпозиції створюється нова діаграма і їй автоматично присвоюється відповідний номер. У результаті проведення експертизи діаграми можуть уточнюватися і змінюватися, отже, можуть бути створені різні версії однієї і тієї ж (з погляду її розташування у дереві вузлів) діаграми декомпозиції. Bpwin дозволяє мати у моделі тільки одну діаграму декомпозиції у даному вузлі. Колишні версії діаграми можна зберігати у вигляді паперової копії або як FEO-діаграму. (На жаль, при створенні FEO-діаграм відсутня можливість відкату, тобто з діаграми можна отримати декомпозиції FEO, але не навпаки.) У будь-якому випадку необхідно відрізняти різні версії однієї і тієї ж діаграми. Для цього існує спеціальний номер - C-number, який повинен присвоюється автором моделі вручну. C-number - це довільний рядок, але рекомендується дотримуватися стандарту, коли номер складається з буквенного префікса і порядкового номера, причому як префікс використовуються ініціали автора діаграми, а порядковий номер відстежується автором вручну, наприклад МСВ00021.
Діаграми дерева вузлів і FEO
Діаграма дерев вузлів показує ієрархію робіт у моделі і дозволяє розглянути всю модель цілком, але не показує взаємозв’язку між роботами (рис. 26). Процес створення моделі робіт є ітераційним, отже, роботи можуть міняти своє розташування у дереві вузлів багато разів. Щоб не заплутатися і перевірити спосіб декомпозиції, необхідно після кожної зміни створювати діаграму дерева вузлів. Проте, Bpwin має потужний інструмент навігації по моделі - Model Explorer, який дозволяє представити ієрархію робіт і діаграм у зручному і компактному вигляді, проте складовою стандарту IDEF0.
Рисунок 26 – Діаграма дерева вузлів
Для створення діаграми дерева вузлів необхідно вибрати в меню пункт Diagram/Add Node Tree (рис. 27). Виникає діалог формування діаграми дерева вузлів Node Tree Definition (рис.28,29).
Рисунок 27 – Вибір команди для формування діаграми дерева вузлів
Рисунок 28 – Діалог налаштування діаграми дерева вузлів (крок 1)
Рисунок 29 – Діалог налаштування діаграми дерева вузлів (крок 2)
У діалозі Node Tree Definition необхідно вказати глибину дерева - Number of Levels (по замовчуванню - 3) і корінь дерева (по замовчуванню - батьківська робота біжучою діаграми). По замовчуванню нижній рівень декомпозиції показується у вигляді списку, решта робіт - у вигляді прямокутників. Для відображення всього дерева у вигляді прямокутників необхідно вимкнути опцію Bullet Last Level. При створенні дерева вузлів необхідно вказати назву діаграми, оскільки, якщо у декількох діаграмах у якості кореня на дереві вузлів використовувати одну і ту ж роботу, всі ці діаграми отримають однаковий номер (номер вузла + постфікс N, наприклад AON) і у списку відкритих діаграм (пункт меню Window) їх можна буде розрізнити тільки за назвою.
Діаграми "тільки для експозиції" (FEO) часто використовуються у моделі для ілюстрації інших точок зору, для відображення окремих деталей, які не явно підтримуються синтаксисом IDEF0. Діаграми FEO дозволяють порушити будь-яке синтаксичне правило, оскільки по суті є просто картинками - копіями стандартних діаграм і не включаються в аналіз синтаксису. Для створення діаграми FEO необхідно вибрати пункт меню Diagram/Add FEO Diagram. У виникаючому діалозі Add New FEO Diagram слід вказати назву діаграми FEO і тип батьківської діаграми (рис. 30)
Рисунок 30 – Діалог створення FEO-діаграми
Нова діаграма отримує номер, який генерується автоматично (номер батьківської діаграми по вузлу + постфікс F, наприклад A1F).
Каркас діаграми
На рис. 31 показаний типовий приклад діаграми декомпозиції з граничними рамками, які називаються каркасом діаграми.
Рисунок 31 – Приклад діаграми декомпозиції з каркасом
Каркас містить заголовок (верхня частина рамки) і підвал (нижня частина). Заголовок каркаса використовується для відстежування діаграми в процесі моделювання. Нижня частина використовується для ідентифікації і позиціонування в ієрархії діаграми.
Зміст елементів каркаса наведено у табл.2 і 3.
Значення полів каркаса задаються в діалозі Diagram Properties (меню Diagram /Diagram Properties) - рис. 32.
Рисунок 32 – Діалог Diagram Properties
|
||||||||||||||||||||||||||
Злиття і розщеплення моделей.
Можливість злиття і розщеплення моделей забезпечує колективну роботу над проектом. Так, керівник проекту може створити декомпозицію верхнього рівня і дати завдання аналітикам продовжити декомпозицію кожної гілки дерева у вигляді окремих моделей. Після закінчення роботи над окремими гілками всі подмоделі можуть злитися в єдину модель. З іншого боку, окрема гілка моделі може бути відщеплена для використання як незалежна модель, для доопрацювання або архівації.
Таблиця 3. Поля підвалу каркаса (зліва направо) |
|
Поле |
Зміст |
Node |
Номер вузла дваграми (номер батьківської роботи) |
Title |
Ім'я діаграми. По замовчуванню - ім'я батьківської роботи |
Number |
C-Number, унікальний номер версії діаграми |
Page |
Номер сторінки, може використовуватися як номер сторінки при формуванні папки |
BPwin використовує для злиття і розгалуження моделей стрілки виклику. Для злиття необхідно виконати наступні умови:
Обидві моделі, що зливаються, повинні бути відкриті в BРwin.
Назва моделі-джерела, яке приєднують до моделі-мети, повинна співпадати з назвою стрілки виклику роботи в моделі-меті.
Стрілка виклику повинна виходити з роботи, яка не декомпонується (робота повинна мати діагональну границю у лівому верхньому кутку) (рис. 33).
Рисунок 33 – Стрілка виклику роботи "Складання і тестування комп’ютерів" моделі-цілі
Назви контекстної роботи моделі-джерела, що під'єднується, і роботи на моделі-меті, до якої ми під'єднуємо модель-джерело, повинні співпадати.
Модель-джерело повинна мати, принаймні, одну діаграму декомпозиції.
Для злиття моделей потрібно клацнути правою кнопкою миші по роботі із стрілкою виклику в моделі-меті і в спливаючому меню вибрати пункт Merge Model.
З’являється діалог, в якому необхідно вказати опції злиття моделі (рис. 34). При злитті моделей об’єднуються і словники стрілок і робіт. У разі однакових визначень можливий перезапис визначень або ухвалення визначень з моделі-джерела. Те саме відноситься до назв стрілок, сховищ даних і зовнішніх посилань. (Сховища даних і зовнішні посилання – об’єкти діаграм потоків даних, DFD, будуть розглянуті у наступних лабораторних роботах.)
Рисунок 34 – Діалог Continue with merge
Після підтвердження злиття (кнопка OK) модель-джерело під'єднується до моделі-мети, стрілка виклику зникає, а робота, від якої відходила стрілка виклику, стає декомпонованою - до неї під'єднується діаграма декомпозиції першого рівня моделі-джерела. Стрілки, що стосуються роботи на діаграмі моделі-мети, автоматично не мігрують у декомпозицію, а відображаються як недозволені. Їх необхідно тунелювати вручну.
У процесі злиття модель-джерело залишається незмінною, і до моделі-мети фактично під’єднується її копія. Не потрібно плутати злиття моделей із синхронізацією. Якщо у подальшому модель-джерело буде редагуватися, ці зміни автоматично не потраплять у відповідну гілку моделі-мети.
Розділення моделей відбувається аналогічно. Для відщеплення гілки від моделі необзідно клацнути правою кнопкою миші по декомпонованій роботі (робота не повинна мати діагональної границі у лівому верхньому кутку) і вибрати у спливаючому меню пункт Split Model. У діалозі Split Options необхідно вказати назву створюваної моделі. Після підтвердження розщеплення у старій моделі робота стане недекомпонованою (ознака - діагональна границя у лівому верхньому кутку), буде створена стрілка виклику, її назва співпадатиме з назвою нової моделі, і, нарешті, буде створена нова модель, причому назва контекстної роботи співпадатиме з назвою роботи, від якої була "відірвана" декомпозиція.
Рекомендації по створенню діаграм
Для покращення читабельності діаграм рекомендується дотримуватися наступних правил:
розташовувати роботи по діагоналі від верхнього лівого кута до нижнього правого;
підтримувати максимально можливу відстань між стрілками, що знаходяться на одній стороні роботи (Model/Model Properties/Layout/Automatically space arrows);
максимально збільшити відстань між роботами, поворотами і перетинами стрілок;
якщо дві стрілки проходять паралельно, то за можливістю їх необхідно об’єднати і назвати одним ім’ям;
зворотні зв’язки по входу рисуються знизу, а зворотні зв’язки по управлінню - зверху;
циклічні зворотні зв’язки краще не використовувати (якщо необхідність у такому зв’язку виникла, то зобразити її можна тільки в два прийоми: спочатку виконати розгалуження, а потім видалити непотрібний фрагмент);
необхідно мінімізувати кількість перетинів, петель і поворотів стрілок.
Частина з перерахованих правил підтримується системою автоматично, але майже завжди запропонований системою порядок можна порушити, що робити не рекомендується.
Проведення експертизи
Для перевірки створюваної моделі існує можливість передачі її експертові для внесення зауважень. Зауваження фіксуються безпосередньо на діаграмі і нумеруються по порядку. Номер зауваження викреслюється в списку можливих зауважень у розділі Notes у вікні побудови діаграми.
Експертиза може проводитися багато разів шляхом пересилання папки, що містить опис моделі, або в процесі усної співбесіди. Після остаточного затвердження діаграма отримує статус Publication і стає доступною для друку і розповсюдження.
Вартісний аналіз (АВС)
Вартісний аналіз дозволяє оцінити запропонований варіант функціонування об’єкту моделювання з погляду необхідних фінансових витрат. Зокрема, даний метод дає можливість вибору з декількох запропонованих варіантів моделей TO-BE.
Вартісний аналіз оперує з поняттями: об’єкт витрат, рушій витрат і центр витрат.
Об’єкт витрат - це те, заради чого функціонує об’єкт моделювання, результат роботи (деталь, виріб, документ, звіт тощр).
Рушій витрат - те, що у кожній роботі впливає на вартість об’єкту витрат (звичайно входи по управлінню і механізми, тобто ресурси, що витрачаються).
Центр витрат відповідає поняттю статті витрат.
Для проведення вартісного аналізу необхідно послідовно виконати наступні дії:
- по замовчуванню на діаграмі відображається вартість роботи, якщо потрібно змінити налаштування, то необхідно скористатися діалогом налаштування властивостей моделі (Model/Model Properties/Display – ABC Data и ABC Units);
- у діалозі Edit/Model Properties/ABC Units вибрати або задати одиниці вимірювання часу і грошей;
- описати центри витрат у діалозі Dictionary/Cost Center/Cost Center Dictionary, задати ім’я кожному центру і опис, порядок перерахування центрів витрат враховується у подальшій роботі;
- для кожної роботи на діаграмі декомпозиції в контекстному меню вибрати пункт Cost і у вікні, що з’явилося, вказати для кожного центру витрат суму витрат при одиничному виконанні роботи; вказати частоту виконання роботи (Frequency) і тривалість роботи (Duration).
Для розрахунку загальних підсумків проводиться сумовування витрат по всіх центрах. Розрахунок ведеться із врахуванням вказаної частоти, тривалості і вартості для кожної роботи. Витрати вищестоящої роботи складаються з витрат дочірних робіт. Для автоматичного проведення розрахунку необхідно встановити режим Compute from Decompositions для всіх робіт моделі.
Розглянутий варіант розрахунку можна застосувати для робіт, що виконуються послідовно. У складніших випадках підсумкові вартості робіт можна задати вручну (режим Override Decompositions).
Результати вартісного аналізу можна представити у вигляді звіту (Tools/Report/Activity Cost Report).
Властивості, які задаються користувачем
Властивості, які визначаються користувачем (User Defined Properties, UDP) призначені для оцінки робіт моделі без підсумкових підрахунків за критеріями, які витікають з особливостей модельованої предметної області.
Кожній роботі можна поставити у відповідність декілька властивостей. Список доступних властивостей зберігається у словнику (UDP Dictionary). На властивості можна посилатися за ключовим словом (словник UDP Keyword List). Одне ключове слово може відповідати декільком властивостям і одна властивість може мати декілька ключових слів.
За наслідками аналізу, який заснований на властивостях, що визначаються користувачем, можна сформувати звіт (Tools/Report/Diagram Object Report).
Користувачe пропонується 18 типів властивостей (табл. 4).
Таблиця 4
Типи властивостей
Тип |
Зауваження |
Text |
Текст до роботи або стрілки, яка щось пояснює |
Paragraph Text |
Текст з декількох рядків |
Integer |
Ціле число, наприклад, кількість балів |
Command |
Для виклику документа, наприклад, у форматі Word шляхом вказання командного рядка; виклик по кнопці, що з'являється поряд з ім'ям властивості |
Character |
Одиночний символ |
Date mm/dd/yy(yy) |
Дата |
Real Number |
Дійсне число, наприклад, споживана потужність |
Text List (Single selection) |
Значення властивості вибирається із списку, список створюється в словнику (поле Value) |
Integer List (Single selection) |
Значення властивості вибирається із списку цілих чисел, див. попереднє |
Command List |
Значення властивості вибирається із списку цілих чисел, див. попереднє |
Date List mm/dd/yy(yy) (Single selection) |
Значення властивості вибирається із списку дат, див. попереднє |
Real Number List (Single selections) |
Див. попереднє |
Character List (Single Selections) |
Див. попереднє |
Text List (Multiple Selections) |
Вибирається кілька значень вказаного типу, список значень створюється у словнику (поле Value) |
Integer List (Multiple Selections) |
Див. попереднє |
Date List (Multiple Selections) |
Див. попереднє |
Real Number List (Multiple Selections) |
Див. попереднє |
Character List (Multiple Selections) |
Див. попереднє |
Для задання нової властивості необхідно перейти до нижнього рядка словника властивостей і двічі клацнути по полю Name, ввести назву, вказати тип властивості і вибрати необхідні ключові слова.
У діалозі User Defined Property Dictionary Editor можна створювати і редагувати властивості і ключові слова. Основні види робіт: додати (Add) властивість, ключове слово або елемент списку; видалити (Delete), змінити (Update) властивість або елемент списку.
У ролі властивості можна розглядати будь-яку міру, що дозволяє якісно або кількісно оцінити роботу або зв’язок, наприклад:
- оцінка якості або щось інше шляхом вибору із списку можливих значень (дуже високе, високе, середнє, низьке, дуже низьке) тощо;
- споживана потужність або подібна кількісна оцінка;
- супроводжуюча документація, специфікації і тощо.
Створення звітів у BPwin
BРwin володіє потужним інструментарієм для генерування звітів. Звіти по моделі викликаються з пункту меню Report. Всього є сім типів звітів:
1. Model Report. Включає інформацію про контекст моделі - назву моделі, точку зору, область, мету, ім’я автора, дату створення тощо.
2. Diagram Report. Звіт по конкретній діаграмі. Включає список об’єктів (робіт, стрілок, сховищ даних, зовнішніх посилань тощо).
3. Diagram Object Report. Найповніший звіт по моделі. Може включати повний список об’єктів моделі (робіт, стрілок з вказанням їхнього типу тощо) і властивості, які визначаються користувачем.
4. Activity Cost Report. Звіт про результати вартісного аналізу. (Буде розглянуто у наступних лабораторних роботах).
5. Arrow Report. Звіт по стрілках. Може містити інформацію зі словника стрілок, інформацію про роботу-джерело, роботу-призначення стрілки і інформацію про розгалуження і злиття стрілок.
6. Data Usage Report. Звіт про результати об’єднання моделі процесів і моделі даних. (Буде розглянуто у наступних лабораторних роботах).
7. Model Consistency Report. Звіт, що містить список синтаксичних помилок моделі.
Порядок виконання роботи:
За допомогою BPWin розробити модель в стандарті IDEF0 для виданих викладачем предметних областей.
Провести вартісний аналіз та оформити звіт.
Контрольні питання:
1. Сімейство методологій IDEF. Їхнє призначення.
2. Напрямки SADT-моделювання.
3. Етапи життєвого циклу програмних засобів, для яких найефективніше використання методології SADT.
3. Переваги методології SADT.
4. Для чого призначені моделі AS-IS і TO-BE?
5. Поняття системи і моделі в IDEF0.
6. Формальне визначення моделі в IDEF0.
7. Мета моделі в IDEF0.
8. “Точка зору” моделі в IDEF0.
9. Суб’єкт моделювання в IDEF0. Принцип обмеження суб’єкта.
10. Об’єкти і функції в IDEF0.
11. Правила представлення функціональних блоків на IDEF0-діаграмі.
12. Призначення сторін функціональних блоків на IDEF0-діаграмі.
13. Принцип домінування і його представлення на IDEF0-діаграмі.
14. Призначення стрілок на IDEF0-діаграмі.
15. Опис стрілок на IDEF0-діаграмі.
16. Види відношень між об’єктами і стрілками на IDEF0-діаграмі.
17. Типи взаємозв’язків між блоками на IDEF0-діаграмі.
18. Розгалуження дуг і правила їх позначення на IDEF0-діаграмі.
19. Злиття дуг і правила їх позначення на IDEF0- діаграмі.
20. Глосарії і Словник даних.
21. C-номера. Призначення і правила запису.
22. Бланк реєстру C-номерів IDEF0.
23. Поняття діаграми-нащадка, батьківського блоку, батьківської діаграми в IDEF0-моделі.
24. Контекстна діаграма моделі.
25. Номер вузла IDEF0-діаграми. Призначення і правила запису.
26. Організація зв’язків між IDEF0-діаграмами.
27. Правила заповнення поля ”КОНТЕКСТ” IDEF0-діаграми.
3. Для чого призначені граничні стрілки і як вони будуються?
4. Як задаються властивості роботам в стрілкам?
5. Типи внутрішніх стрілок?
27. Зовнішні стрілки IDEF0-діаграми і система їх позначень.
28. Правила стикування і позначення зовнішніх стрілок діаграми-нащадка з граничними стрілками батьківського блоку.
29. “Тунелювання стрілок”. Призначення і правила позначення.
30. IDEF0-декомпозиція. Визначення, складові, послідовність застосування в IDEF0.
31. Стратегії декомпозиції в IDEF0.
32. Основні етапи процесу моделювання в IDEF0.
33. Призначення циклу автор/читач у процесі моделювання в IDEF0.
34. Роль “бібліотекаря” у процесі моделювання в IDEF0.
35. Роль “Комітету технічного контролю” у процесі моделювання у IDEF0.
36. CASE-засоби, що підтримують технологію IDEF0-моделювання.
37. Як здійснюється експертиза моделі?
38. Де і як фіксується стадія розрабки моделі?
39. Як здійснюється робота з моделлю TO-BE?
40. Як проводиться вартісний аналіз?
41. Що таке властивості, які визначаються користувачем?
42. Як здійснюється аналіз, заснований на властивостях, що визначаються користувачем?