PrIS

171

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

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

Модель, виконана в IDEF3, може містити елементи, які розглянемо далі.

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

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

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

зв'язок відношення (Relational) – показує зв'язок між двома роботами чи між роботою й об'єктом посилання; позначається пунктирною лінією;

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

173

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

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

BPwin має зручний інструмент для навіґації по рівнях декомпозиції моделі. Це Model Explorer, що за організацією дуже схожий на провідник Windows. Роботи IDEF0 показуються в Model Explorer зеленим кольором, DFD – жовтим і IDEF3 – синім. Клацаючи мишкою по кожній з робіт, поданих у провіднику, користувач може переходити на діаграму, що містить обрану роботу. У версії BPwin 4.0 провідник моделі пропонує користувачу

174

інтерфейс, що містить у собі нову вкладку об'єктів (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). Діаграма дерева вузлів має вигляд традиційного ієрархічного дерева, де верхній вузол (прямокутник) відповідає роботі з контекстної діаграми, а наступні нижні вузли являють собою нижні рівні декомпозиції. Можна також створити діаграму дерева вузлів лише для деякої

175

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

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

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

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

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

176

Діаграми сценаріїв 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, показує, як система буде працювати після реорганізації. Деталізація

177

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

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

178

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 має два рівні подання моделі — логічний і фізичний. Логічний рівень — це абстрактний погляд на дані, коли дані

подаються так, як виглядають у реальному світі, і можуть називатися так, як вони називаються у реальному світі, наприклад "Постійний клієнт",

179

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

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

Документування моделі

Багато СКБД мають обмеження на іменування об'єктів (наприклад, обмеження на довжину імені таблиці або заборона використання спеціальних символів — пропуску і т. ін.). Часто розробники ІС мають справу з нелокалізованими версіями СКБД. Це означає, що об'єкти БД можуть називатися короткими словами, тільки латинськими символами і без використання спеціальних символів (тобто не можна назвати таблицю, використовуючи речення — її можна назвати лише одним словом). Крім того, проектувальники БД нерідко зловживають "технічними" назвами, в результаті таблиця і колонки отримують назви типу RTD_324 або CUST_A12 тощо. Отриману в результаті структуру можуть зрозуміти тільки фахівці (а найчастіше — тільки автори моделі), її неможливо обговорювати з експертами предметної області. Поділ моделі на логічну і фізичну дозволяє вирішити цю проблему. На фізичному рівні об'єкти БД можуть називатися так, як того вимагають обмеження СКБД. На логічному рівні можна цим об'єктам дати синоніми — імена, зрозуміліші неспеціалістам, у тому числі на кирилиці і з використанням спеціальних символів. Наприклад, таблиці CUST_A12 може відповідати сутність Постійний клієнт. Така відповідність дозволяє краще документувати модель і дає можливість обговорювати структуру даних з експертами предметної області.

Масштабування

180

Створення моделі даних, як правило, починається з розроблення логічної моделі. Після опису логічної моделі проектувальник може вибрати необхідну СКБД, і ERwin автоматично створить відповідну фізичну модель. На основі фізичної моделі ERwin може згенерувати системний каталог СКБД або відповідний SQL-скрипт. Цей процес називається прямим проектуванням (Forward Engineering). Тим самим досягається масштабованість — створивши одну логічну модель даних, можна зґенерувати фізичні моделі під будь-яку підтримувану СКБД ERwin. З іншого боку, ERwin здатний за вмістом системного каталога або SQL-скриптом відтворити фізичну і логічну модель даних (Reverse Engineering). На основі отриманої логічної моделі даних можна згенерувати фізичну модель для іншої СКБД і потім створити її системний каталог. Отже, ERwin дозволяє вирішити завдання з перенесення структури даних з одного сервера на інший. Наприклад, можна перенести структуру даних з Oracle на Informix (або навпаки) або перенести структуру dbf-файлів в реляційну СКБД, тим самим полегшивши перехід від файл-серверної до клієнт-серверної ІС. Проте, формальне перенесення структури "пласких" таблиць на реляційну СКБД зазвичай неефективне. Щоб отримати вигоди від переходу на клієнтсерверну технологію, структуру даних треба модифікувати.

Обчислення розміру БД

ERwin дозволяє розрахувати приблизний розмір БД загалом, а також таблиць, індексів і інших об'єктів через певний період часу після початку експлуатації ІС. Розрахунок будується на основі таких параметрів: початкова кількість рядків; максимальна кількість рядків; приріст кількості рядків у місяць. Результати розрахунків зводяться у звіт.

Пряме і зворотне проектування

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

Зворотним проектуванням називається процес ґенерування логічної моделі з фізичної БД. Зворотне проектування дозволяє конвертувати БД з однієї СКБД в іншу. Після створення логічної моделі БД шляхом зворотного проектування можна перемкнутися на інший сервер і здійснити пряме проектування.

Окрім режиму прямого і зворотного проектування, програма забезпечує синхронізацію між логічною моделлю і системним каталогом СКБД впродовж всього життєвого циклу створення ІС.

Ґенерування коду клієнтської частини за допомогою ERwin