Rational Rose - Інформатика, програмування

2.1.1 Rational Rose

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

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

Методика побудови так званих «бізнес-моделей», що міститься в додатковому наборі рекомендацій або методики RUP, що супроводжує пакет Rational Rose, пропонує діаграми Use Case та Activity для опису бізнес-процесів. Дуги Use Case та Activity діаграм не мають смислових типів, а образно показують логічний зв'язок. Синтаксичні угоди, що диктуються системою при розробці Use Case і Activity-діаграм, мають набори перерахованих функцій, які дають інформацію про процеси, що відбуваються на підприємстві. З цієї причини користувачам Rational Rose при розробці Use Case та Activity-діаграм доводиться вигадувати свої оригінальні синтаксичні угоди та давати свою інтерпретацію, щоб відобразити всю суттєву для аналізованого процесу інформацію. Діаграми не об'єднані у закінчену та зрозумілу систему; цим діаграмам (що, мабуть, головне) не дається жодної інтерпретації, яка пояснює, як їх застосовувати під час моделювання. Це означає, що два процеси з'єднані стрілкою - просто послідовність їх виконання або, наприклад, те, що другий процес обробляєдеякі результати діяльності першого, а можливо, навпаки, для першого процесу необхідна якась інформація, яку готує другий? Тому користувачеві Rational Rose необхідно розробляти свої формалізми для отримання методики побудови моделей та аналізу бізнес-процесів. Rational Rose ґрунтується на стандартах UML, але не підтримує жодну з відомих методологій моделювання та аналізу бізнес-процесів.

Аналізу та реорганізації бізнес-процесів, компанія Logic Works, пропонує проводити із застосуванням CASE – засоби верхнього рівня – BPwin, що підтримує методології IDEF0 (функціональна модель), IDEF3 (WorkFlow Diagram) та DFD (DataFlow Diagram). Функціональна модель призначена для опису існуючих бізнес-процесів на підприємстві (так звана модель AS-IS) та ідеального стану речей - того, чого потрібно прагнути (модель TO-BE).

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

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

Усі роботи та стрілки пойменовані. Перша діаграма в ієрархії діаграм IDEF0 завжди зображує функціонування системи загалом.

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

Одним із недоліків BPWin називають обмеження за кількістю об'єктів на діаграмі. Однак досвід реальних проектів показує, що для проекту, результати якого можна реально використати (критерій – доступність для огляду), кількість об'єктів у моделі BPWin становить 150-300. Це означає, що при 8 об'єктах на одній діаграмі, загальна кількість діаграм (аркушів) у моделі становитиме 20-40. Моделі BPWin, що містять понад 500 об'єктів, практично неможливо використовувати. Слід підкреслити, що модель створюється виділення та аналізу проблем, тобто. потрібен детальний опис найбільш складних, проблемних сфер діяльності, а не тотальний опис усіх процесів.