Лабораторна робота 2 на тему Моделювання прийняття рішень за допомогою функціонального підходу (методологія IDEF0) з курсу Управління вимогами в ІТ проектах
« Назад
Лабораторна робота № 2
Моделювання прийняття рішень за допомогою функціонального підходу (методологія IDEF0) Мета роботи:
Описання системи за допомогою IDEF0 називається функціональною моделлю. Функціональна модель призначена для описанняу існуючих бізнес-процесів, в якому використовуються як природні, так і графічні мови. Для передачі інформації про конкретну систему джерелом графічної мови є сама методологія IDEF0. Методологія IDEF0 передбачає побудову ієрархічної системи діаграм – одиничних описанняів фрагментів системи. Спочатку проводиться описання системи в цілому та її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція – система розбивається на підсистеми і кожна підсистема описанняується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається на більш дрібні і так далі до досягнення потрібного ступеня розбиття. Кожна IDEF0-діаграма містить блоки і дуги. Блоки зображують функції модельованої системи. Дуги пов'язують блоки разом і відображають взаємодії і взаємозв'язкок між ними. Функціональні блоки (блоку) на діаграмах зображуються прямокутниками, які дають зрозуміти пойменовані процеси, функції або завдання, які відбуваються протягом певного часу і мають розпізнавані результати. Ім'я функціональних блоків має бути виражене віддієслівним іменником, що позначає дію. IDEF0 вимагає, щоб у діаграмі було не менше трьох і не більше шести блоків. Ці обмеження підтримують складність діаграм і моделі на рівні, доступному для читання, розуміння і використання. Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку призначена для входів, верхня – для управління, права – для виходів, нижня – для механізмів. Таке позначення відображає певні системні принципи: входи перетворюються у виходи, управління обмежує або наказує умови виконання перетворень, механізми показують, що і як виконує функція. Блоки в IDEF0 розміщуються за ступенем важливості, як її розуміє автор діаграми. Цей відносний порядок називається домінуванням. Домінування розуміється як вплив, який один блок надає на інші блоки діаграми. Наприклад, самим домінуючим блоком діаграми може бути або перший з необхідної послідовності функцій, або плануюча або контролююча функція, що впливає на всі інші. Найбільш домінуючий блок зазвичай розміщується у верхньому лівому куті діаграми, а найменш домінуючий – у правому кутку. Розташування блоків на сторінці відображає авторське визначення домінування. Таким чином, топологія діаграми показує, які функції надають більший вплив на інші. Щоб підкреслити це, аналітик може перенумерувати блоки відповідно до порядку їх домінування. Порядок домінування може позначатися цифрою, розміщеною у правому нижньому кутку кожного прямокутника: 1 буде вказувати на найбільше домінування, 2 – на наступне і т. д. Взаємодія функціональних блоків із зовнішнім світом і між собою описанняується у вигляді стрілок, зображуваних одинарними лініями зі стрілками на кінцях. Стрілки являють собою якусь інформацію і іменуються іменниками. В IDEF0 розрізняють п'ять типів стрілок. Вхід – об'єкти, що використовуються і перетворені функціональними блоками для отримання результату (виходу). Допускається, що функціональні блоки можуть не мати жодної стрілки входу. Стрілка входу малюється як вхідна в ліву грань блоку. Управління – інформація, що управляє діями блоку. Зазвичай керуючі стрілки несуть інформацію, яка вказує, що повинна виконувати функціональний блок. Кожний блок повинен мати хоча б одну стрілку управління, яка зображується як вхідна у верхню межу блоку. Вихід – об'єкти, в які перетворюються входи. Кожний блок повинен мати хоча б одну стрілку виходу, яка малюється як вихідна з правої грані функціонального блоку. Механізм – ресурси, які виконують роботу. Стрілка механізму малюється як вхідна в нижню межу блоку. На розсуд аналітика стрілки механізму можуть не зображуватися на моделі. Виклик – спеціальна стрілка, що вказує на іншу модель функціонального блоку. Стрілка виклику малюється як вихідна з нижньої частини блоку і використовується для вказівки того, що деяка робота виконується за межами модельованої системи. Рис. 2.1. Стрілка виклику У методології IDEF0 потрібно тільки п'ять типів взаємодій між блоками для описанняу їх відносин: управління, вхід, зворотний зв'язок з управління, зворотній зв'язок по входу, вихід-механізм. Зв'язки з управління і входу є простими, оскільки вони відображають прямі впливи, які інтуїтивно зрозумілі і дуже прості. Рис. 2.2. Зв'язок по виходу Рис. 2.3. Зв'язок по управлінню Відношення управління виникає тоді, коли вихід одного блоку безпосередньо впливає на блок з меншим домінуванням. Зворотній зв'язок з управління та зворотній зв'язок по входу є більш складними, оскільки являють собою ітерацію або рекурсію. А саме виходи з одного блоку впливають на майбутнє виконання інших блоків, що згодом вплине на вихідний блок. Зворотній зв'язок з управління виникає тоді, коли вихід деякого блоку впливає на блок з великим домінуванням. Зв'язки «вихід-механізм» зустрічаються нечасто. Вони відображають ситуацію, при якій вихід однієї функції стає засобом досягнення мети для іншої. Рис. 2.4. Зворотній зв'язок по входу Рис. 2.5. Зворотній зв'язок по управлінню Зв'язки «вихід-механізм» характерні при розподілі джерел ресурсів (наприклад, необхідні інструменти, навчений персонал, фізичний простір, обладнання, фінансування, матеріали). В IDEF0 дуга рідко зображує один об'єкт. Зазвичай вона символізує набір об'єктів. Так як дуги представляють набори об'єктів, вони можуть мати множину початкових точок (джерел) і кінцевих точок (призначень). Тому дуги можуть розгалужуватися і з'єднуватися різними способами. Вся дуга або її частина може виходити з одного або кількох блоків і закінчуватися в одному або декількох блоках. Розгалуження дуг, зображуване у вигляді розбіжних ліній, означає, що весь вміст дуг або його частина може з'явитися в кожному відгалуженні. Дуга завжди позначається до розгалуження, щоб дати назву цілому набору. Крім того, кожна гілка дуги може бути позначена або не позначена у відповідності з наступними правилами:
Злиття дуг у IDEF0, які зображуються як сходження разом ліній, вказує, що вміст кожної гілки йде на формування мітки для дуги, що є результатом злиття вихідних дуг. Після злиття результуюча дуга завжди позначається для вказівки нового набору об'єктів, що виник після об'єднання. Крім того, кожна гілка перед злиттям може позначатися або не позначатися у відповідності з наступними правилами: Рис. 2.6. Зв'язок вихід-механізм
1. Кількісний аналіз діаграм Для проведення кількісного аналізу діаграм перерахуємо показники моделі:
Даний набір чинників відноситься до кожної діаграмі моделі. Далі будуть перераховані рекомендації щодо бажаних значень факторів діаграми. Необхідно прагнути до того, щоб кількість блоків на діаграмах нижніх рівнів була б нижчою кількості блоків на батьківських діаграмах, тобто зі збільшенням рівня декомпозиції зменшувався б коефіцієнт . Таким чином, спадання цього коефіцієнта говорить про те, що в міру декомпозиції моделі функції повинні спрощуватися , отже, кількість блоків повинна спадати. Діаграми повинні бути збалансовані. Це означає, що в рамках однієї діаграми не повинно відбуватися ситуації, зображеної на рис. 2.7: у блоці 1. вхідних стрілок і стрілок управління значно більше, ніж вихідних. Слід зазначити, що дана рекомендація може не виконуватися в моделях, що описанняують виробничі процеси. Наприклад, при описанняі процедури складання в блок може входити велике число стрілок, що описанняують складові виробу, а виходити одна стрілка – готовий виріб. Рис. 2.7. Приклад незбалансованої діаграми Введемо коефіцієнт збалансованості діаграми. Необхідно прагнути, щоб був мінімальний для діаграми. Крім аналізу графічних елементів діаграми необхідно розглядати найменування блоків. Для оцінки імен складається словник елементарних (тривіальних) функцій, що моделюються. Фактично в цей словник повинні потрапити функції нижнього рівня декомпозиції діаграм. Наприклад, для моделі БД елементарними можуть бути функції «знайти запис», «додати запис в БД», в той час як функція «реєстрація користувача» вимагає подальшого описанняу. Після формування словника і складання пакету діаграм системи необхідно розглянути нижній рівень моделі. Якщо на ньому виявляться збіг назв блоків діаграм і слів зі словника, то це говорить, що достатній рівень декомпозиції досягнутий. Коефіцієнт, кількісно відображає даний критерій, можна записати як L×C – розбиття рівня моделі на число збігів імен блоків зі словами з словника. Чим нижчий рівень моделі (більше L), тим цінніші збіги.
2. Інструментарій BP Win При запуску BPWin за замовчуванням з'являється основна панель інструментів, палітра інструментів і Model Explorer. Функціональність панелі інструментів доступна з основного меню BPWin (табл. 2.1). Таблиця 2.1
Описанняання елементів управління основної панелі інструментів BPWin
При створенні нової моделі виникає діалог, в якому слід вказати, чи буде створена модель заново, або вона буде відкрита з ModelMart, внести ім'я моделі та вибрати методологію, в якій буде побудована модель (рис. 2.8). BPWin підтримує три методології – IDEF0, IDEF3 і DFD. У BPWin можлива побудова змішаних моделей, тобто модель може містити одночасно як діаграми IDEF0, так і IDEF3 і DFD. Склад палітри інструментів змінюється автоматично, коли відбувається перемикання з одної нотації на іншу. Модель в BPWin розглядається як сукупність блоків, кожна з яких оперує з деяким набором даних. Якщо клацнути по будь-якому об'єкту моделі лівою кнопкою миші, з'являється спливаюче контекстне меню, кожен пункт якого відповідає редактору якої-небудь властивості об'єкта. Рис. 2.8. Діалог створення моделі Для побудови діаграм у BPWin використовується три панелі інструментів для кожного типу діаграм. Діаграми IDEF0 – кнопка для додавання блоку на діаграму. – проведення нового зв'язку. – інструмент редагування об'єктів. – декомпозиція діаграми. Діаграми DFD – додавання в діаграму зовнішнього посилання. – додавання стрілки потоку даних у діаграму. – декомпозиція діаграми. – додавання сховища даних. – посилання на іншу сторінку. Цей інструмент дозволяє направити стрілку на будь-яку діаграму.
Діаграми IDEF3 – «Старший» зв'язок. – перехрестя. – об'єкт посилання.
3. Приклад Побудова моделі системи повинно починатися з вивчення всіх документів, що описанняують її функціональні можливості. Одним з таких документів є технічне завдання, а саме розділи «Призначення розробки», «Цілі і завдання системи» і «Функціональні характеристики системи». Після вивчення вихідних документів і опитування замовників і користувачів системи необхідно сформулювати мету моделювання та визначити точку зору на модель. Розглянемо технологію її побудови на прикладі системи «Служба зайнятості в рамках вузу», основні можливості якої були описанняані в лабораторній роботі № 1. Сформулюємо мету моделювання: описанняати функціонування системи, що було б зрозуміло її користувачеві, не вдаючись у подробиці, пов'язані з реалізацією. Модель будемо будувати з точки зору користувачів (студент, викладач, адміністратор, деканат, фірма). Почнемо з побудови контекстної IDEF0-діаграми. Відповідно до описанняу системи основною функцією є обслуговування її клієнтів за допомогою обробки запитів, що від них надходять. Таким чином, визначимо єдину роботу контекстної діаграми як «Обслужити клієнта системи». Далі визначимо вхідні і вихідні дані, а також механізми і управління. Для того щоб обслужити клієнта, необхідно зареєструвати його в системі, відкрити доступ до БД і обробити його запит. В якості вхідних даних будуть використовуватися «ім'я клієнта», «пароль клієнта», «вихідна БД», «запит клієнта». Виконання запиту веде або до отримання інформації від системи, або до зміни вмісту БД (наприклад, при складанні експертних оцінок), тому вихідними даними будуть «звіти» і «змінена БД». Процес обробки запитів буде виконуватися монітором системи під контролем адміністратора. Таким чином, визначимо контекстну діаграму системи (рис. 2.9). Проведемо декомпозицію контекстної діаграми, описанняавши послідовність обслуговування клієнта:
Отримаємо діаграму, зображену на рис. 2.10. Рис. 2.9. Контекстна діаграма системи Закінчивши декомпозицію контекстної діаграми, переходять до декомпозиції діаграми наступного рівня. Зазвичай при розгляді третього і більш нижніх рівнів моделі повертаються до батьківських діаграм і коригують їх. Рис. 2.10. Декомпозиція блоку «Обслуговування клієнта системи» Проводимо декомпозицію послідовно всіх блоків отриманої діаграми. Першим етапом при визначенні рівня доступу в систему є визначення категорії користувача. На ім'я клієнта здійснюється пошук в базі користувачів, визначаючи його категорію. Відповідно до визначеної категорії з'ясовуються повноваження, надані користувачеві системи. Далі проводиться процедура доступу в систему, перевіряючи ім'я і пароль доступу. Об'єднуючи інформацію про повноваження і рівні доступу в систему, для користувача формується набір дозволених дій. Таким чином, визначення рівня доступу в систему буде виглядати як показано на рис. 2.11. Рис. 2.11. Декомпозиція блоку «Визначення рівня доступу в систему» Після проходження процедури доступу до системи монітор аналізує запит клієнта, вибираючи підсистему, яка буде обробляти запит. Декомпозиція блоку «Звернення до підсистеми» не відповідає меті і точці зору моделі. Користувача системи не цікавлять внутрішні алгоритми її блоку. У даному випадку йому важливо, що вибір підсистеми буде виконано автоматично, без його втручання, тому декомпозиція звернення до підсистеми тільки ускладнить модель. Проводимо декомпозицію функціонального блоку «Обробка запиту клієнта», що виконується підсистемою обробки запитів, визначення категорій та повноважень користувачів. Перед здійсненням пошуку відповіді на запит необхідно відкрити БД (підключитися до неї). У загальному випадку БД може знаходитися на віддаленому сервері, тому може знадобитися встановлення з'єднання з нею. Визначимо послідовність блоків:
Після відкриття БД необхідно повідомити системі про встановлення з'єднання з БД, після чого виконати запит і згенерувати звіти для користувача (рис. 2.12). Необхідно відзначити, що в «Виконання запиту» включається блок різних підсистем. Наприклад, якщо запит включає в себе тестування, то його буде виконувати підсистема професійних і психологічних тестів. На етапі виконання запиту може знадобитися зміна вмісту БД, наприклад при складанні експертних оцінок. Тому, на діаграмі необхідно передбачити таку можливість. Рис. 2.12. Декомпозиція блоку «Обробка запиту клієнта» При аналізі отриманої діаграми виникає питання, за якими правилами відбувається генерація звітів? Необхідна наявність заздалегідь сформованих шаблонів, за якими буде проводитися вибірка з БД, причому ці шаблони повинні відповідати запитам і повинні бути заздалегідь визначені. Крім того, клієнту повинна бути надана можливість вибору форми звіту. Скорегуємо діаграму, додавши в неї стрілки «Шаблони звітів» і «Запити на зміну БД» і тунельну стрілку «Клієнт системи». Тунелювання «Клієнта системи» застосовано для того, щоб не виносити стрілку на діаграму верхнього рівня, так як функція вибору форми звіту не є досить важливою для відображення її на батьківській діаграмі. Зміна діаграми потягне за собою коригування всіх батьківських діаграм (рис. 2.13 - 2.15). Декомпозицію блоку «Виконання запиту» доцільно провести за допомогою діаграми DFD (лабораторна робота № 3), так як методологія IDEF0 розглядає систему як сукупність взаємопов'язаних блоків, що погано відображає процеси обробки інформації. Перейдемо до декомпозиції останнього блоку «Зміна БД». З точки зору клієнта, дані системи розташовуються в одній БД. Реально в системі присутні шість БД:
Рис. 2.13. Декомпозиція блоку «Обробка запиту клієнта» (Варіант 2) Відповідно до мети моделювання клієнтові важливо розуміти, що дані які надійшли не відразу оновлюються в системі, а проходять додатковий етап обробки і контролю. Алгоритм зміни можна сформулювати наступним чином:
Дану модель реалізувати іншим способом, надавши можливість оновлення БД безпосередньо за запитами, минаючи процес контролю даних. У цьому випадку необхідно забезпечити контроль цілісності БД для запобігання її ушкодження. У цьому випадку діаграма буде виглядати наступним чином (рис. 2.17). Проведення подальшої декомпозиції «Зміни БД» буде ускладнювати модель, пояснюючи, як здійснюється фізична зміна БД в системі. При цьому користувач не отримає ніякої додаткової інформації про роботу системи служби зайнятості. Декомпозицію цієї блоку доцільно проводити в процесі проектування БД системи на етапі створення логічної моделі БД. Рис. 2.14. Декомпозиція блоку «Обслуговування клієнта системи» (Варіант 2) Рис. 2.15. Контекстна діаграма системи (варіант 2) Декомпозиція блоку «Виконання запиту» буде проведена в наступній лабораторній роботі, ілюструючи застосування діаграм DFD для описанняу процесів обробки інформації. Проведемо кількісний аналіз моделей, зображених на рис. 2.12 та 2.13, згідно вищеописанняаною методикою. Розглянемо поведінку коефіцієнта у цих моделях. У батьківській діаграмі «Обробка запиту клієнта» коефіцієнт дорівнює 4/2 = 2, а у діаграмі декомпозиції 3/3 = 1. Значення коефіцієнта спадає, що говорить про спрощення описанняу функцій з пониженням рівня моделі. Розглянемо зміну коефіцієнта у двох варіантах моделі. Рис. 2.16. Декомпозиція блоку «Зміна БД» Рис. 2.17. Декомпозиція блоку «Зміна БД» (варіант 2) Для першого варіанту, зображеного на рис. 2.12, , для другого варіанту . Коефіцієнт не змінює свого значення, отже, збалансованість діаграми не змінюється. Будемо вважати, що рівень декомпозиції розглянутих діаграм достатній для відображення мети моделювання, і на діаграмах нижнього рівня в якості найменувань блоків використовуються елементарні функції (з точки зору користувача системи). Підводячи підсумки розглянутого прикладу необхідно відзначити важливість розгляду декількох варіантів діаграм при моделюванні системи. Такі варіанти можуть виникати при коригуванні діаграм, як це було зроблено з «Обробкою запиту клієнта» або при створенні альтернативних реалізацій функцій системи (декомпозиція блоку «Зміна БД»). Розгляд варіантів дозволяє вибрати найкращий і включити його в пакет діаграм для подальшого розгляду.
4. Завдання
5. Контрольні питання
З повагою ІЦ "KURSOVIKS"! |