Примітка

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

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

Рис. 8.7. Діаграма "сутність-зв'язок" для загального прикладу компанії

Таблиця 8.1. Об’єкти ERD у різних методологіях

	Чена	Баркера	SADT	SAG
Незалежна сутність
Залежна сутність
Зв'язок
Арність зв’язків:
1:1
1:N
N:N
Можли-вість під-тримки ієрархічності зв’язків	–	–	–	так
Необов’язковий зв’язок
Категоризація сутності
Відображення ключо-вих атрибутів	–	–	PK- первинний FK- зовнішній.	i
Можли-вість авто-матичної генерації схеми	–	так	так	так

8.5. Методологія IDEF1

Метод IDEF1, розроблений Т.Ремей (T.Ramey), також заснований на підході П.Чена і дозволяє побудувати модель даних, еквівалентну реляційній моделі в третій нормальній формі. На даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X. IDEF1X розроблена з врахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються разом з поширеними CASE-засобами (зокрема, ERwin, Design/IDEF) (будуть розглянуті у наступних розділах).

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

Кожній сутності присвоюється унікальна назва і номер, що розділяються косою рискою "/" і розміщується над блоком.

Зв'язок може додатково визначатися за допомогою вказання мірі або потужності (кількості екземплярів сутності-нащадка, яка може існувати для кожного екземпляра сутності-батька). У IDEF1X можуть бути виражені наступні типи зв'язків:

¨ кожен екземпляр сутності-батька може мати нуль, один або більше пов'язаних з ним екземплярів сутності-нащадка;

¨ кожен екземпляр сутності-батька повинен мати не менше одного пов'язаного з ним екземпляра сутності-нащадка;

¨ кожен екземпляр сутності-батька повинен мати не більше одного пов'язаного з ним екземпляр суті-нащадка;

¨ кожен екземпляр сутності-батька пов'язаний з деякою фіксованою кількістю екземплярів сутності-нащадка.

Якщо екземпляр сутності-нащадка однозначно визначається своїм зв'язком з сутностію-батьком, то зв'язок називається ідентифікуючим, інакше - неідентифікуючим.

Ідентифікуючий зв'язок між сутністю-батьком і сутністю-нащадком зображається суцільною лінією (рис. 8.9). Сутність-нащадок у ідентифікуючому зв'язку є залежною від ідентифікатора сутністю. Сутність-батько у ідентифікуючому зв'язку може бути як незалежною, так і залежною від ідентифікатора сутністю (це визначається її зв'язками з іншими сутностями).

Рис. 8.9. Ідентифікуючий зв’язок.

Пунктирна лінія зображає неідентифікуючий зв'язок (рис. 8.10). Сутність-нащадок у неідентифікуючому зв'язку буде незалежною від ідентифікатора, якщо вона не є також нащадком деякого ідентифікуючого зв'язку.

Атрибути зображають у вигляді списку імен всередині блока сутності. Атрибути, що визначають первинний ключ, розміщаються нагорі списку і відокремлюються Від інших атрибутів горизонтальною рисою (рис. 8.11).

Рис.8.10. Неідентифікуючий зв’язок.

Рис. 8.11. Атрибути і первинні ключі.

Сутності можуть мати також зовнішні ключі (Foreign Key), котрі можуть використовуватися у якості частини або цілого первинного ключа або неключового атрибуту. Зовнішній ключ зображається за допомогою розміщення в середині блока сутності імен атрибутів, після яких слідують букви FK у дужках (рис. 8.12).

Рис. 8.12. Приклади зовнішніх ключів.

Висновки

1. Діаграми «сутність-зв'язок» призначені для розроблення моделей даних і забезпечують стандартний спосіб визначення даних і відношень між ними. Фактично за допомогою ERD здійснюється деталізація сховищ даних проектованої системи, а також документуються сутності системи і способи їх взаємодії, включаючи ідентифікацію об'єктів, важливих для предметної області, властивостей цих об'єктів (атрибутів) і їх відношень з іншими об'єктами (зв'язків).

2. Є такі нотації ERD: Чена, Баркера.

3. Для кращого розкриття діаграм «сутність-зв’язок» доцільно використовувати діаграми атрибутів та категоризації.

Контрольні питання

1. Призначення діаграм «сутність-зв’язок».

2. Базові нотації ERD.

3. Призначення діаграм атрибутів.

4. Призначення діаграм категоризації.

5. Типи зв’язків у методології IDEF1X.

РОЗДІЛ.9. Діаграми переходів станів

à Призначення діаграм переходів станів

à Типи керуючих потоків

à Принципи побудови діаграм переходів станів

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

9.1. Основні елементи

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

STD (State Transition Diagram) — діаграма переходів станів. На STD відображуються стани, у яких може перебувати система, і можливі переходи з одного стану до іншого. Згідно з діаграмою проектується інтерфейс користувача.

За допомогою STD можна моделювати подальше функціонування системи на основі її попереднього і поточного функціонування. Модельована система в будь-який заданий момент часу перебуває точно в одному з кінцевої множини станів. З часом вона може змінити свій стан, при цьому переходи між станами повинні бути точно визначені.

STD складається з наступних об'єктів.

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

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

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

Ця подія зазвичай складається з керуючого потоку (сигналу), що виникає як у зовнішньому світі, так і всередині модельованої системи при виконанні певної умови (наприклад, ЛІЧИЛЬНИК = 999 або КНОПКА натискання).

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

Таким чином, Умова – це подія (або події), що викликають перехід та ідентифікуються назвою переходу. Якщо в умові бере участь вхідний керуючий потік керуючого попереднього процесу, то назва потоку повинна бути записана в лапки, наприклад, "ПАРОЛЬ" = 555, де ПАРОЛЬ – вхідний потік.

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

9.2. Типи керуючих потоків

Є такі типи керуючих потоків:

а) Т-потік (triggerflow). Є потоком керування процесом, який може викликати виконання процесу. При цьому процес ніби включається однією короткою операцією. Це – аналог вимикача світла, єдиним натисканням якого "запускається" процес горіння лампи.

б) А-потік (activator flow). Є потоком керування процесом, що може змінювати виконання окремого процесу. Використовується для забезпечення безперервності виконання процесу до тих пір, поки потік "включений" (тобто тече безперервно), з "виключенням" потоку виконання процесу завершується. Це - аналог перемикача лампи, яка може бути як включена, так і вимкнена.

в) E / D-потік (enable / disable flow). Є потоком керування процесом, який може перемикати виконання окремого процесу. Перебіг по Е-лінії викликає виконання процесу, яке продовжується до тих пір, поки не починається процес по D-лінії. Це - аналог вимикача з двома кнопками: одна - для включення світла, інша – для його вимкнення. Відзначимо, що можна використовувати 3 типи таких потоків: Е-потік, D-потік, E / D-потік.

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

Крім того, для специфікації А-, Т-, E / D-потоків назва запускаючого або перемикаючого процесу також має братися в лапки, наприклад:

Фактично умова є певною зовнішньою або внутрішньою подія, яку система здатна виявити і на яку вона повинна відреагувати певним чином, змінюючи свій стан. При зміні стану система зазвичай виконує одну або більше дій (здійснює висновок, видає повідомлення на термінал, виконує обчислення).

Таким чином, дія є відгуком, що посилається в зовнішнє оточення, або обчислення, результати якого запам'ятовуються в системі (зазвичай у сховищах даних на DFD), для того, щоб забезпечити реакцію на деякі з планованих у майбутньому подій. На STD стани представляються вузлами, а переходи – дугами (рис. 9.1).

Рис. 9.1. Символи STD

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

9.3. Принципи побудови

При побудові STD рекомендується виконувати такі правила:

¨ будувати STD на якомога більш високому рівні деталізації DFD;

¨ будувати як можна більш прості STD;

¨ по можливості деталізувати STD;

¨ використовувати ті ж принципи іменувань станів, подій та дій, що і при іменуванні процесів і потоків.

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

¨ чи всі стани визначені і мають унікальні назви?

¨ чи всі стани досяжні?

¨ чи всі стани мають вихід?

¨ (для кожного стану) реагує чи система відповідним чином на всі можливі умови (особливо на ненормальні)?

¨ чи всі вхідні (вихідні) потоки керуючого процесу відображені в умовах (дії) на STD?

У ситуації, коли число станів і / або переходів велике, для проектування специфікацій управління можуть використовуватися таблиці і матриці переходів станів. Обидві ці нотації дозволяють зафіксувати ту ж саму інформацію, що і діаграми переходів станів, але в іншому форматі. Як приклад таблиці переходів станів наведена таблиця 9.1.

Таблиця 9.1. Переходів станів

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

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

Таблиця 9.2. Символи STD у різних методологіях.

	Гейна-Сарсона	Йордона	SAG	SADT
Стан				---
початковий стан				---
перехід				----

Висновки

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

2. Діаграми переходів станів складаються з таких об’єктів: стан, початковий стан, перехід, умова.

3. Основні нотації діаграм переходів станів: Гейна-Сарсона, Йордона.

Контрольні питання

1. Призначення діаграм переходів станів.

2. Нотації для діаграм переходів станів.

3. Основні принципи побудови діаграм переходів станів

РОЗДІЛ. 10. Структурне проектування на етапі проектування програмного забезпечення

à Призначення структурних карт Константайна

à Призначення структурних карт Джексона

У розділі описано методологію побудови структурних карт Константайна та Джексона.

10.1. Структурні карти Константайна

Методика структурних карт використовується на етапі проектування програмного забезпечення для того, щоб продемонструвати, яким чином програмний продукт виконує системні вимоги. При цьому найчастіше застосовуються дві техніки: структурні карти Константайна (Constantine), призначені для опису зв’язків між модулями, і структурні карти Джексона (Jackson), призначені для опису внутрішньої структури модулів [39].

Структуру програмної системи складають модулі, які на будь-якій мові програмування мають наступні спільні властивості:

¨ модуль має назву, за якою до нього можна звертатися як до єдиного фрагмента;

¨ модуль складається з набору операторів мови програмування, записаних послідовно;

¨ модуль може приймати і/або передавати дані як параметри у певній послідовності або зв'язувати дані через певні параметри.

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

Модуль є базовим елементом структурної карти. Розрізняють наступні типи модулів (див. рис. 10.2):

¨ модуль (рис. 10.2, а);

Рис. 10.1. Елементи структурних карт

а – модуль; б – виклик модуля; в – зв'язок з даними;с - зв'язок з функціями

¨ підсистема – деталізований модуль або програма. Може використовуватися повторно будь-яку кількість разів (рис. 10.2, б);

¨ бібліотека – сукупність підпрограм, розміщених в модулі окремо від заданої системи (рис. 10.2, в);

¨ область даних – описує модулі, що містять виключно області глобальних/розподілених даних (рис. 10.2, г).

Рис. 10.2. Типи модулів

Окремі частини програмної системи (програми, підпрограми) можуть викликатися послідовно, паралельно або як співрограми (див. рис. 10.3).

Для моделювання умовних і циклічних викликів застосовуються наступні вузли (рис. 10.3):

Рис. 10.3. Типи викликів модулів

¨ умовний вузол застосовується для моделювання конструкцій IF-THEN-ELSE (на діаграмі з вузла виходять два потоки) і IF-THEN (з вузла виходить один потік). Умовний вузол зображається у вигляді ромба, потоки – альтернативні виклики зображаються такими, що виходять з нього;

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

Якщо необхідно показати, що підлеглий модуль викликається одноразово, це здійснюється вказанням цифри "1" поряд зі стрілкою, що позначає виклик модуля-спадкоємця (рис 10.4).

Рис. 2.12. Умовні і циклічні виклики модулів

а - циклічний; б - умовний; в - одноразовий

Зв'язки за даними і управлінням між модулями (що передаються як параметри) позначають стрілками, паралельними дузі виклику, які показують напрями зв'язків (рис. 10.5).

Рис. 10.5. Зв'язки а – за даними і б – за керуванням

Приклад 10.1. Розробити структурну карту Константайна для задачі сортування одновимірного масиву за допомогою алгоритмів бульбашки, прямого вибору і Шелла.

Програма складається з модулів Меню, Методів сортування, і Виведення результату. Користувач вибирає потрібний метод, вводить масив і отримує у результаті відсортований масив.

Результат наведений на рис. 10.6.

10.2. Структурні карти Джексона

Техніка структурних карт Джексона базується на методі структурного програмування Джексона, який виявляє відповідність між структурою потоків даних і структурою програми [39]. Основна увага у методі сконцентрована на відповідності вхідних і вихідних потоків даних. Структури на діаграмах Джексона будуються з чотирьох основних компонентів, поданих на рис. 10.7:

Рис.10.6. Приклад структурної карти Константайна

¨ операція – блок кодів, що має один вхід і один вихід (рис 10.7, а);

¨ проходження – послідовне виконання операцій зліва направо (рис 10.7, б);

¨ вибір – виконання однієї з операцій залежно від виконання умови (рис 10.7, в);

¨ ітерація – багатократне виконання блоку (рис 10.7, г).

Рис. 10.7. Елементи структурних діаграм Джексона.

Приклад 10.2. У менеджера торгівельної фірми є файл, що містить записи про принтери з наступними полями: фірма-виробник, марка, швидкість друку, вартість, кількість одиниць на складі. Ці поля утворюють структуру вхідних даних. По запиту менеджера програма видає відомості про потрібні покупцеві принтери відповідно до критерію пошуку. Критерієм може бути: ціна, швидкість або фірма-виробник. Вихідними даними є список, що містить назву вибраних принтерів.

З точки зору структурного програмування Джексона алгоритм програми буде наступним:

Програма

Цикл-пока не кінець файлу

Прочитати запис

Порівняти задані поля з критерієм пошуку

Якщо назви співпали

Зберегти у вихідний список

Кінец-якщо

Кінець-цикл

Виведення результуючого списку

Кінець-програма

Отримана структурна карта Джексона приведена на рис. 10.8.

Рис 10.8. Структурна карта Джексона

Таблиця. 10.1. Позначення елементів структурних карт

	Константа-йна	SAG	SADT (fefo)	Джексон
модуль				---
підсистема (підпрограма)			---	---
бібліотека (бібл. модуль)			---	----
виклик модуля
зв’язок за даними		+ опис секції	---	---
зв’язок з функцією		висячі вершини виконуються прогр. модулями	через механізм наслідування	---

Висновки

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

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

Контрольні питання

1. Призначення структурних кар Джексона.

2. Призначення структурних карт Константайна.

РОЗДІЛ 11. Засоби створення діаграм

à Призначення CASE-технологій

à Програмний засіб BPWin

à Програмний засіб ERWin

à Програмний засіб Visio

У розділі описано призначення CASE-технологій та основні програмні засоби для проектування систем.

11.1. Призначення CASE-технологій

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

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

При створенні великомасштабних і складних ІС, реінжинерінгу бізнес-процесів все частіше користуються засобами САSЕ-технологій або їх елементами. Сучасні САSЕ-технології (табл. 3.1) підтримують основні етапи життєвого циклу ІС (ЖЦ ІС) [34], забезпечують перевірку результатів проектування.

Системи автоматизації розподіленого проектування ПЗ на основі CASE-технологій дозволяють внести значні удосконалення в процес розробки.

Проектування і реалізація ІС [78] здійснюється за допомогою різних технологій виконання проектних робіт:

¨ оригінальне проектування ІС;

¨ типове проектування ІС;

¨ засоби комп'ютерної підтримки процесу розробки ІС — CASE-технології (Computer Aided System Engineering).

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

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

При створенні великомасштабних і складних ІС, реінжинерінгу бізнес-процесів все частіше користуються засобами САSЕ-технологій або їх елементами. Сучасні САSЕ-технології (таблиця 11.1) підтримують основні етапи ЖЦ ІС [34], забезпечують перевірку результатів проектування.

Таблиця 11.1. Характеристика CASE-технологій

Системи автоматизації розподіленого проектування ПЗ на основі CASE-технологій дозволяють внести значні удосконалення в процес розробки.

Як показують практичні дослідження (таблиця 11.2), застосування таких систем істотно змінюють розподіл трудозатрат по фазах розробки ПЗ [], скорочуючи загальний час проектування. При використанні CASE-технології час на аналіз та проектування ПЗ збільшується у два рази, але істотно зменшується час, затрачений на кодування та тестування ПЗ.

Таблиця 11.2. Порівняльна характеристика технологій

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

11.2. Інструментальний засіб BPwin

BPwin є могутнім інструментом для створення моделей, що дозволяють аналізувати, документувати і планувати зміни складних бізнесів-процесів. Иепер він входить у програмний пакет AllFusion Modeling Suite. BPwin пропонує засіб для збору всієї необхідної інформації про роботу підприємства і графічного зображення цієї інформації у вигляді цілісної і несуперечливої моделі.

BPwin підтримує три методології: IDEF0, DFD і IDEF3, що дозволяють аналізувати бізнес із трьох ключових точок зору:

З погляду функціональності системи. У рамках методології IDEF0 (Integration Definition for Function Modeling) бізнес-процес представляється у виді набору елементів-робіт, що взаємодіють між собою, а також показуються інформаційні, людські і виробничі ресурси, які споживаються кожною роботою.

З погляду потоків інформації (документообігу) у системі. Діаграми DFD (Data Flow Diagramming) можуть доповнити те, що уже відбито в моделі IDEF3, оскільки вони описують потоки даних, дозволяючи простежити, яким чином відбувається обмін інформацією між бізнес-функціями усередині системи. У той же час діаграми DFD залишають без уваги взаємодію між бізнес-функціями.

З погляду послідовності виконуваних робіт. І ще більш точну картину можна одержати, доповнивши модель діаграмами IDEF3. Цей метод привертає увагу до черговості виконання подій. У IDEF3 включені елементи логіки, що дозволяє моделювати й аналізувати альтернативні сценарії розвитку бізнес-процесу.

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

11.2.1. IDEF0

Основною із трьох методологій, які підтримує BPwin, є IDEF0. IDEF0, відноситься до сімейства стандартів IDEF, які з'явились наприкінці шістдесятих років за назвою SADT (Structured Analysis and Design Technique). IDEF0 може бути використана для моделювання широкого класу систем. Для нових систем застосування IDEF0 має своєю метою визначення вимог і вказання функцій для наступного розроблення системи, що відповідає поставленим вимогам і реалізує виділеним функціям. Стосовно до вже існуючих систем IDEF0 може бути використана для аналізу функцій, які виконуються системою, і відображення механізмів, за допомогою яких ці функції виконуються. Результатом застосування IDEF0 до деякої системи є модель цієї системи, що складається з ієрархічно упорядкованого набору діаграм, тексту документації та словників, зв'язаних один з одним за допомогою перехресних посилань. Двома найважливішими компонентами, з яких будуються діаграми IDEF0, є функції чи роботи (представлені на діаграмах у вигляді прямокутників) і дані й об'єкти (подані у вигляді стрілок), що зв'язують між собою роботи. При цьому стрілки, у залежності від того в яку грань прямокутника роботи вони входять чи з якої грані виходять, поділяються на п'ять видів.

¨ Стрілки входу (входять у ліву грань роботи) – зображують дані чи об'єкти, що змінюються в ході виконання роботи.

¨ Стрілки керування (входять у верхню грань роботи) – зображують правила й обмеження, згідно з якими виконується робота.

¨ Стрілки виходу (виходять із правої грані роботи) – зображують дані чи об'єкти, що з'являються у результаті виконання роботи.

¨ Стрілки механізму (входять у нижню грань роботи) – зображують ресурси, які необхідні для виконання роботи, але не змінюються в процесі роботи (наприклад, пристрої, людські ресурси...)

¨ Стрілки виклику (виходять з нижньої грані роботи) – зображують зв'язки між різними діаграмами чи моделями, вказуючи на деяку діаграму, де задана робота розглянута детальніше.

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

Продоменструємо діаграми IDEF0 для розроблення системи визначення кредитоспроможності клієнта банку (рис. 11.1).

Рис 11.1. Приклад контекстної діаграми в нотації IDEF0.

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

Рис. 11.2 Приклад діаграми декомпозиції в нотації IDEF0

Опис кожної підсистеми проводиться аналітиком разом з експертом предметної області. Зазвичай експертом є людина, відповідальна за цю підсистему і, тому досконально обізнана про всі її функції. Таким чином, уся система розбивається на підсистеми до потрібного рівня деталізації, і виходить модель, що апроксимує систему з заданим рівнем точності. Одержавши модель, що адекватно відображає поточні бізнес-процеси (так звану модель AS IS – як є), аналітик з легкістю може побачити усі найуразливіші місця системи. Після цього, з урахуванням виявлених недоліків, можна будувати модель нової організації бізнесів-процесів (модель TO BE – як має бути).

Аналіз інформації про фізичну ососбу показано на рис. 11.3.

Рис. 11.3. Аналіз інформації про фізичну особу

Аналіз інформації про юридичну особу показано на рис. 11.4.

Після прийняття рішення про надання кредиту за специфічними ознаками і у разі позитивного рішення проходить аналіз кредитоспроможності за спільними для двох груп ознаками (рис. 11.5.)

Остаточним рішенням визначаєься можливість наданя кредиту, а також надається інформація про позичальників банкам-пертнерам за їхнім запитом.

11.2.2. DFD

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

Рис. 11.4. Аналіз інформації про юридичну особу

Рис. 11.5. Аналіз інформації за спільними ознаками.

Усього DFD використовує чотири важливих елементи:

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

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

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

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

Приклад побудови діаграм в нотації DFD для автоматизації ЖЕК подано на рис. 11.6 – 11.7.

Контекстну діаграму системи автоматизації ЖЕКу показано на рис. 11.6.

Рис. 11.6 Контекстна діаграма у нотації DFD

Діаграма потоків даних першого рівня показана на рис. 11.7.

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

11.2.3. IDEF3

Наявність у діаграмах DFD елементів для опису джерел, приймачів і сховищ даних дозволяє точно описати процес документообігу. Однак для опису логіки взаємодії інформаційних потоків модель доповнюють діаграмами ще однієї методології – IDEF3, так званої workflow diagramming. Методологія моделювання IDEF3 дозволяє графічно описати і задокументувати процеси, фокусуючи увагу на послідовності цих процесів і на зв’язках між процесами і важливими об'єктами, що є частинами цих процесів.

Рис. 11.7. Діаграма потоків даних першого рівня у нотації DFD

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

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

Модель, виконана в IDEF3, може містити такі елементи:

¨ Одиниці роботи (Unit of Work) - основний компонент діаграми IDEF3 близький за змістом до роботи IDEF0.

¨ Зв'язки (Links) - зв'язки, зображені стрілками, показують взаємозв’язки між роботами. У IDEF3 розрізняють три типи зв'язків:

¡ Зв'язок передування (Precedence) – показує, що перш ніж почнеться робота-приймач, повинна завершитися робота-джерело. Позначається суцільною лінією.

¡ Зв'язок відношення (Relational) - показує зв'язок між двома роботами чи між роботою й об'єктом посилання. Позначається пунктирною лінією.

¡ Потік об'єктів (Object Flow) – показує участь деякого об'єкта у двох чи більше роботах. Позначається двосторонньою стрілкою.

¨ Розгалуження (Junctions) - використовуються для того, щоб показати розгалуження логічної схеми модельованого процесу й альтернативні шляхи розвитку процесу, які виникають під час його виконання. Розрізняють два типи розгалужень:

¡ Розгалуження злиття (Fan-in Junction) – вузол, що збирає декілька стрілок в одну, вказуючи на необхідність умови завершеності робіт-джерел стрілок для продовження процесу (рис. 11.8).

Рис.11.8. Приклад діаграми IDEF3 для моделювання визначення можливості надання соціальної допомоги

¡ Розгалуження розгалуження (Fan-out Junction) – вузол, у якому єдина вхідна в нього стрільця розгалужується, показуючи, що роботи, які виходять за розгалуженням, виконуються паралельно чи альтернативно.

¨ Об'єкти посилань (Referents) - служать для вираження ідей і концепцій без використання спеціальних методів, таких як стрілки, чи розгалуження роботи.

11.2.4. Інші діаграми BPWin

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

Застосування універсальних графічних мов бізнес-моделювання IDEF0, IDEF3 і DFD забезпечує логічну цілісність і повноту опису, необхідну для досягнення точних і несуперечливих результатів. За допомогою набору графічних інструментів для відображення дій і об'єктів, BPwin дозволяє легко побудувати схему процесу, на якій показані вихідні дані, результати операцій, ресурси, необхідні для їхнього виконання, що керують впливи, взаємні зв'язки між окремими роботами. Інтерактивне виділення об'єктів забезпечує постійний візуальний зворотний зв'язок при побудові моделі. Врwіn підтримує цілісність зв’язків, не допускаючи визначення некоректних посилань.

BPwin має зручний інструмент для навігації по рівнях декомпозиції моделі. Це Model Explorer, що по організації дуже схожий на провідник Windows. Роботи IDEF0 показуються в Model Explorer зеленим кольором, DFD – жовтим і IDEF3 – синім. Клацаючи мишкою по кожній з робіт, представлених у провіднику, користувач може переходити на діаграму, що містить обрану роботу. У версії BPwin 4.0 провідник моделі пропонує користувачу інтерфейс, що містить у собі нову вкладку об'єктів (Objects), і дороблену вкладку діаграм (Diagrams). За допомогою вкладки об'єктів можна методом Drag&Drop розміщати об'єкти зі словника на будь-який діаграму. За допомогою вкладки діаграм можна переглядати усю ієрархію діаграм, включаючи Organization Chart, Node Tree, Swim Lane, FEO, і IDEF3 Scenario, про які мова йтиме пізніше.

Можна підтримувати словники для наступних об'єктів:

¡ роботи;

¡ стрілки;

¡ сховища даних;

¡ зовнішні посилання;

¡ розгалуження;

¡ об'єкти посилань;

¡ атрибути;

¡ центри витрат;

¡ сутності;

¡ ресурси;

¡ ролі;

¡ групи ролей;

¡ властивості, обумовлені користувачем (UDP);

¡ ключові слова UDP.

Окрім IDEF0, DFD і IDEF3, BPwin підтримує ще цілий ряд допоміжних діаграм таких як:

Діаграми дерева вузлів (Node Tree Diagram). До моделі BPwin можна додавати дерево вузлів, що показує ієрархію всіх робіт моделі на одній діаграмі (рис. 11.9). Діаграма дерева вузлів має вид традиційного ієрархічного дерева, де верхній вузол (прямокутник) відповідає роботі з контекстної діаграми, а наступні нижні вузли являють собою нижні рівні декомпозиції. Можна також створити діаграму дерева вузлів лише для деякої частини моделі, тоді верхнім вузлом діаграми буде та робота декомпозиції, з яким ви захочете почати.

У версії BPwin 4.0 з'явилася можливість відображати діаграми дерева вузлів не тільки з діагональними, але і з прямими лініями зв'язку і змінювати властивості робіт безпосередньо із самої діаграми.

Усі задачі, подані на рис. 11.1. – 11.5, можна подати у вигляді дерева цілей, зображеному на рис. 11.9.

Рис. 11.9. Дерево цілей

Діаграми тільки для показу (For Exposition Only {FEO} Diagram). До моделі завжди можна додати діаграму FEO. Найчастіше це робиться для того, щоб проілюструвати різні сценарії розвитку процесу, показати модель з інших точок зору, вирізувати важливий шматок зі складної діаграми, не псуючи при цьому саму діаграму. До будь-якої діаграми моделі в BPwin, чи контекстної диаграми, чи однієї з діаграм декомпозиції, можна додавати FEO діаграми. FEO діаграми характерні тим, що вони не підлягають синтаксичній перевірці з боку BPwin, оскільки вони можуть бути лише частиною синтаксично правильної діаграми.

Діаграми сценаріїв IDEF3 (IDEF3 Scenario). У BPwin 4.0 є можливість додавати до моделі діаграми сценаріїв IDEF3.

Схеми організації (Organization Charts). Для того, щоб наочно представити структуру організації, до будь-якої моделі в BPwin 4.0 можна додати схему організації. Схеми організації BPwin мають традиційну деревоподібну ієрархічну структуру, на вершині якої знаходиться один прямокутник, від якого йдуть розгалуження до декількох прямокутників нижнього рівня. Кожен прямокутник у схемі організації відповідає конкретній ролі чи посаді, наприклад президента чи віце-президента.

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

Swim Lane Diagrams. Swim Lane діаграми можна додавати до будь-якої моделі в BPwin для більш наочного зображення проходження процесу. Ці діаграми використовують методологію IDEF3 і показують горизонтальні смуги, що представляють участь у процесі ролей.

11.2.5. Моделі AS IS і TO BE

Як уже говорилося вище, при реорганізації бізнесів-процесів вже існуючої системи будуються дві моделі: AS IS і TO BE. Модель AS IS покликана показати, як система функціонує у цей момент і є свого роду фотографією системи. А модель TO BE, що будується виходячи з результатів аналізу моделі AS IS, показує, як система буде працювати після реорганізації. Деталізація бізнесів-процесів дозволяє виявити недоліки організації навіть там, де функціональність на перший погляд здається очевидною. Ознакою неефективної діяльності можуть бути марні, некеровані роботи і роботи, що дублюються, неефективний документообіг (потрібний документ не виявляється в потрібному місці в потрібний час), відсутність зворотних зв'язків по керуванню (на проведення роботи не впливає її результат) і входу (об'єкти чи інформація використовуються нераціонально) і т.д. Крім того, BPwin містить ряд засобів, що допомагають аналітику аналізувати і виправляти модель AS IS. Насамперед, мова йде про те, що BPwin вказує на синтаксичні помилки в моделі, що можуть бути викликані неправильною організацією системи. Коли всі такі помилки будуть виправлені, перед аналітиком повинна постати задача оптимізації, а для коректної постановки цієї задачі, як відомо, необхідний критерій. BPwin дає аналітику метрику - вартісний аналіз, заснований на роботах (Activity Based Costing, ABC) і властивості, обумовлені користувачем (User Defined Properties, UDP).

Вбудований у BPwin механізм обчислення вартості дозволяє оцінювати й аналізувати витрати на здійснення різних видів ділової активності. Механізм обчислення витрат на основі виконуваних дій (Activity-Based Costing, ABC) - це технологія, яка використовується для оцінки витрат і ресурсів. Вона допомагає розпізнати і виділити найдорожчі операції для подальшого аналізу. АВС є широко розповсюдженою методикою, використовується міжнародними корпораціями і державними організаціями (у тому числі Департаментом оборони США) для ідентифікації джерел найбільших витрат в організації.

BPwin тісно інтегрується з відомими продуктами Computer Associates і інших компаній. Серед цих продуктів:

¨ Інструмент моделювіання ERWin (CA/Logic Works). У версії BPwin 4.0 інтерфейси експорту й імпорту синхронізовані з Erwin 4.0. Крім того, з'явилася можливість асоціювання сутностей і атрибутів зі сховищами даних.

¨ Система керування і зберігання проектів ModelMart (CA/Logic Works), яка надає репозитарій для колективної розробки моделей. ModelMart гарантує погодженість моделей, розмежування доступу до них, підтримку версій і багато інших засобів, що так важливі при командній розробці моделей. Сервер додатків для програмних продуктів CA ModelMart підтримує могутній набір інструментальних програмних засобів, що забезпечують спільне (групове) проектування і розробку програмних систем, включаючи механізми об'єднання моделей і аналізу змін, контроль версій, можливість створення "компонент" моделі і т.д. Для організації сховища моделей у ModelMart використовуються СКБД на платформах Oracle, Sybase, Informix чи SQL Server. Крім того, підтримуються прямі зв'язки ModelMart з ERwin і BPwin.

11.3. ERwin

11.3.1. Основні властивості

ERwin має два рівні представлення моделі — логічний і фізичний.

Логічний рівень — це абстрактний погляд на дані, коли дані представляються так, як виглядають у реальному світі, і можуть називатися так, як вони називаються на реальному світі, наприклад "Постійний клієнт", "Відділ" або "Прізвище співробітника". Об'єкти моделі, що представляються на логічному рівні, називаються сутностями та атрибутами. Логічна модель даних може бути побудована на основі іншої логічної моделі, наприклад на основі моделі процесів. Логічна модель даних є універсальною і ніяк не пов'язана з конкретною реалізацією СКБД. Для створення моделей даних в ERwin можна використовувати дві нотації: IDEFIX і IE (Information Engineering). ERwin має декілька рівнів відображення діаграми: рівень сутностей, рівень атрибутів, рівень визначень, рівень первинних ключів і рівень ікон, перемикання між ними здійснюється за допомогою кнопок панелі інструментів.

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

Поиск по сайту: