Лабораторна робота 3 на тему Доповнення моделей процесів прийняття рішень діаграмами DFD та WorkFlow (IDEF3) з курсу Управління вимогами в ІТ проектах
« Назад Лабораторна робота № 3
Доповнення моделей процесів прийняття рішень діаграмами DFD та WorkFlow (IDEF3) Мета роботи:
1. Діаграми потоків даних (Data Flow Diagrams) Ці діаграми представляють мережу пов'язаних між собою блоків. Їх зручно використовувати для опису документообігу та обробки інформації. DFD описує:
Для побудови діаграм DFD в BPWin використовується нотація Гейна-Сарсона. Таблиця 3.1 Нотація Гейна – Сарсона
Потоки даних є механізмами, що використовуються для моделювання передачі інформації (або фізичних компонентів) з однієї частини системи в іншу. Потоки зображуються на діаграмі іменованими стрілками, орієнтація яких вказує напрямок руху інформації. Стрілки можуть підходити до будь-якої грані прямокутника блоку і можуть бути двонаправленими для опису взаємодії типу «команда-відповідь». Призначення процесу полягає в продукуванні вихідних потоків із вхідних у відповідності з дією, що задається ім'ям процесу. Кожен процес повинен мати унікальний номер для посилань на нього всередині діаграми. Цей номер може використовуватися спільно з номером діаграми для отримання унікального індексу процесу у всій моделі. Сховище даних дає змогу на певних ділянках визначати дані, які будуть зберігатися в пам'яті між процесами. Фактично сховище представляє «зрізи» потоків даних у часі. Інформація, яку воно містить, може використовуватися в будь-який час після її визначення, при цьому дані можуть вибиратися в будь-якому порядку. Ім'я сховища має ідентифікувати його вміст. У випадку, коли потік даних входить у сховище або виходить з нього і його структура відповідає структурі сховища, він повинен мати те ж саме ім'я, яке немає необхідності відображати на діаграмі. Зовнішня сутність являє сутність поза контекстом системи, що є джерелом або приймачем даних системи. Передбачається, що об'єкти, представлені такими вузлами, не повинні брати участь ні в якій обробці. Зовнішні сутності зображуються у вигляді прямокутника з тінню і зазвичай розташовуються по краях діаграми. Одна зовнішня сутність може бути використана багаторазово на одній або декількох діаграмах. Рис. 3.1. Зовнішня сутність Для доповнення моделі IDEF0 діаграмою DFD потрібно в процесі декомпозиції в діалозі Activity Box Count вказати тип діаграми DFD.
2. Діаграми IDEF3Діаграми IDEF3 також називають WorkFlow diagramming – методологією моделювання, що використовує графічний опис інформаційних потоків, взаємовідносин між процесами обробки інформації та об'єктів, що є частиною цих процесів. Діаграми WorkFlow використовуються для аналізу процедур обробки інформації. Мета IDEF3 – дати аналітикам опис послідовності виконання процесів, а також об'єктів, що беруть участь спільно в одному процесі. IDEF3 може бути також використаний як метод створення процесів. IDEF3 доповнює IDEF0 і містить все необхідне для побудови моделей, які можуть бути використані для імітаційного моделювання. Діаграми Діаграма є основною одиницею опису в IDEF3-моделі. Організація діаграм в IDEF3 є найбільш важливою, якщо модель редагується кількома людьми. У цьому випадку розробник повинен визначати, яка інформація буде входити в ту чи іншу модель. Одиниці блоку – Unit of Work (UOW), також звані блоками, є центральними компонентами моделі. У IDEF3 блоки зображуються прямокутниками і мають ім'я, що означає процес дії та номер (ідентифікатор). У ім'я зазвичай включається основний результат блоку (наприклад, приготування обіду). Зв'язки Показують взаємини блоків. Усі зв'язки в IDEF3 є односпрямованими. Старша (Precedence) лінія – суцільна лінія (), що зв'язує блоки. Вимальовується зліва направо або зверху вниз. Показує, що блок-джерело повинен закінчитися раніше, ніж блок-мета почнеться. Лінія відношень (Relation Link) – пунктирна лінія (----), використовується для зображення зв'язків між одиницями блоків, а також між одиницями блоків і об'єктами посилань. Потоки об'єктів (Object Flow) – стрілка з двома наконечниками (), застосовується для опису використання об'єкта у двох або більше одиницях блоку, наприклад коли об'єкт породжується в одному блоці і використовується в іншому. Перехрестя (Junction) – використовується для відображення логіки взаємодії стрілок при злитті і розгалуженні або для відображення подій, які можуть або повинні бути завершені перед початком наступного блоку. Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fanout Junction) стрілок. Перехрестя не може використовуватися одночасно для злиття і для розгалуження. Для внесення перехрестя служить кнопка Таблиця 3.2 Типи перехресть
Об'єкти-посилання – є спеціальними символами, які посилаються на зовнішні частини опису процесу. Вони додаються на діаграму для того, щоб звернути увагу редактора на що-небудь важливе, що не можна пов'язати зі стрілкою, роботою або перехрестям. Для внесення об'єкта-посилання служить кнопка . Об'єкт-посилання відображено у вигляді прямокутника. Об'єкти-посилання повинні бути пов'язані з одиницями блоків або перехрестями пунктирними лініями. При внесенні об'єктів-посилань необхідно вказати їх тип. Таблиця 3.3 Типи об'єктів-посилання
3. Приклад 3.1. Діаграми DFD Діаграми DFD можна використовувати як доповнення до діаграм IDEF0 для опису документообігу та обробки інформації. Розглянемо роботу «Обробка запитів клієнта» з лабораторної роботи № 1. Запити в систему надходять від користувачів, тому запити від кожної категорії будуть оброблятися окремо. Виділимо зовнішні сутності діаграми згідно кожної категорії користувачів, визначаючи потоки даних, якими вони обмінюються з системою. Отримаємо діаграму, зображену на рис. 3.3. Відповідно до опису системи проведемо декомпозицію отриманих блоків (рис. 3.4 - 3.7). Всі процеси обробки запитів контролюються і виконуються монітором системи, тому стрілка-механізм «Монітор системи» буде повторюватися на декомпонованих діаграмах. Точка зору моделі, яка визначена в лабораторній роботі № 1, не вимагає розгляду внутрішніх особливостей функціонування системи, тому затунелюємо стрілку «Монітор системи» з тим, щоб не переносити її на діаграми нижнього рівня. Проведемо аналіз отриманих діаграм. Розглядаючи діаграму, зображену на рис. 3.3, необхідно відзначити наявність у ній зайвих блоків «Опрацювати запит адміністратора». При складанні першого варіанту діаграми блоки були визначені виходячи з категорій користувачів. Це призвело до виникнення конфлікту з функціями системи і з точкою зору на модель. Адміністратор не обслуговується системою як звичайний клієнт, він забезпечує її моніторинг. Адміністратор може додавати паролі, змінювати рівень доступу до системи, додавати нового користувача і т. д. З точки зору клієнта системи, діяльність адміністратора є другорядною, тому на всіх діаграмах відсутній опис функцій адміністратора, представляючи його вплив як «механізм» для інших функцій. Тому приймаємо рішення видалити роботу «Опрацювати запит адміністратора». Рис. 3.3. DFD-декомпозиція блоку «Виконання запиту» Рис. 3.4. Декомпозиція блоку «Опрацювати запит студента» Перейдемо до аналізу діаграми декомпозиції блоку «Опрацювати запит студента». Згідно рис. 2.13, що описує процес обробки запиту, після виконання запиту відбувається генерація звіту вибраної користувачем форми й тільки потім перегляд отриманих даних. На діаграмі «Опрацювати запит студента» функція починається зі слова «переглянути». Виникає протиріччя. У процесі обробки запиту студента дані повинні бути знайдені в БД і передані іншому модулю, генеруючи звіти. Змінимо назву блоку на діаграмі, уточнивши при цьому потоки даних, що складають дугу «Знайдена інформація». Отримаємо другий варіант діаграми (рис. 3.9). Рис. 3.5. Декомпозиція блоку «Опрацювати запит деканату» Аналогічне протиріччя спостерігається і в діаграмі на рис. 3.5. Крім того, зі сховищ, що зображують БД виходить стрілка «Знайдена інформація», в той час як ця стрілка повинна виходити прямо з блоків, передаючи дані для генерації звіту. Звернення до БД потрібно у випадку, коли інформація необхідна для виконання функції усередині блоку. Скорегуємо діаграму, отримавши новий варіант (рис. 3.10). Перейдемо до наступної діаграмі - «Опрацювати запит експерта» (рис. 3.7). Коригувань ця діаграма не вимагає, крім уточнення назви функцій. Перед проведенням експертної оцінки експерт повинен вибрати студента. Термін «визначити» може мати на увазі втручання експерта, при якому він на підставі будь-яких переваг вибирає студента для проведення оцінки. Насправді студент просто вибирається із загального списку. Рис. 3.6. Декомпозиція блоку «Опрацювати запит фірми» Хоча тут можуть існувати зовнішні чинники, наприклад вимога фірми на складання експертної оцінки для студента. Ця ситуація повинна відображатися на діаграмі «Опрацювати запит фірми», тобто необхідно внести додатковий блок «Знайти експертні оцінки студента». Причому якщо такі оцінки не знайдені, то необхідно генерувати запит для експерта на їх складання. Рис. 3.7. Декомпозиція блоку «Опрацювати запит експерта» Крім зазначених недоліків, діаграма «Опрацювати запит фірми» має ще декілька. Можна об'єднати блоки «Скласти запрошення» і «Надіслати студенту» в один блок «Скласти та надіслати запрошення», спростивши діаграму. Проведемо аналіз варіантів діаграми «Виконання запиту», зображених на рис. 3.8 та 3.12, за методикою, описаною в лабораторній роботі № 2. У другому варіанті скоротилося число блоків, спростивши діаграму. Таким чином, зменшився коефіцієнт. Рис. 3.8. DFD-декомпозиція блоку «Виконання запиту» (варіант 2) Рис. 3.9. Декомпозиція блоку «Опрацювати запит студента» (Варіант 2) Рис. 3.10. Декомпозиція блоку «Опрацювати запит декана» (Варіант 2) Розрахуємо і порівняємо коефіцієнти збалансованості діаграм. Для першого варіанту: для другого варіанту Рис. 3.11. Декомпозиція блоку «Опрацювати запит фірми» (Варіант 2) Рис. 3.12. DFD-декомпозиція блоку «Виконання запиту» (Варіант 2) Зменшення коефіцієнта свідчить про більш рівномірний розподіл потоків даних між блоками моделі.
3.2. Діаграми IDEF3 За допомогою діаграм IDEF3 зазвичай моделюють послідовності блоків, що мають технологічні та тимчасові зв'язки. До таких моделей можна віднести проект розробки системи служби зайнятості, який і буде розглянуто в даному прикладі. Перед початком моделювання необхідно створити ієрархічну структуру блоків, що описує процес розробки системи. Розробка технічного завдання.
Аналіз.
Створення запитів до системи. Розробка модульної структури.
Проектування БД.
Рис. 3.13. Декомпозиція блоку «Опрацювати запит експерта» (Варіант 3) Згідно зі створеною структурою блоків визначимо діаграми, додавши на них взаємозв'язок між блоками. Рис. 3.14. Діаграма «Розробка системи служби зайнятості» На стадії розробки технічного завдання замовник системи грає важливу роль, забезпечуючи розробників необхідною інформацією для створення системи. Тому на діаграмі показаний відповідний об'єкт-посилання, що впливає на блок «Розробка технічного завдання». Проведемо декомпозицію блоків зі створення служби зайнятості, орієнтуючись на створену структуру блоків. Рис. 3.15. Декомпозиція блоку «Розробка технічного завдання» Отримані діаграми описують процес створення системи служби зайнятості на основі структури блоків по процесів. Зазвичай для більш точного опису проекту створюють декілька структур. У даному випадку корисно створити структуру «по підсистемам», описавши блоки, необхідні для створення конкретних підсистем служби зайнятості. Рис. 3.16. Декомпозиція блоку «Аналіз» Рис. 3.17. Декомпозиція блоку «Розробка модульної структури» Структура блоків по підсистемах: Розробка технічного завдання.
Розробка підсистеми професійних і психологічних тестів.
Розробка підсистеми обробки запитів. Визначення міжсистемних угод.
Розробка підсистеми експертних оцінок.
Розробка підсистеми контролю успішності студентів.
Розробка архітектури всієї системи. Об'єднання підсистем.
Рис. 3.18. Декомпозиція блоку «Проектування БД» При формуванні структури операцій «по підсистемах» виявилася можливість створення типового фрагмента проектування підсистеми, що включає один і той самий перелік блоків. Такий підхід часто спрощує опис проектів, дозволяючи формувати проекти будь-якої складності з невеликих фрагментів. Виділимо отриманий типовий фрагмент в окрему діаграму (рис. 3.22). Створимо пакет діаграм, що відповідає структурі блоків «по підсистемах». Рис. 3.19. Діаграма «Розробка системи служби зайнятості» Рис. 3.20. Декомпозиція блоку «Розробка технічного завдання» Рис. 3.21. Декомпозиція блоку «Об'єднання підсистем» Рис. 3.22. Типовий фрагмент «Розробка підсистеми»
4. Завдання
5. Контрольні питання
З повагою ІЦ "KURSOVIKS"! |