Лекція №5. Специфікація вимог до програмного забезпечення

· Кожен варіант використання для бізнес-процесів супроводжується специфікацією, в якій міститься:

· найменування;

· короткий опис варіанту;

· цілі і результати;

· опис сценаріїв (основного і альтернативних);

· спеціальні вимоги (час і вартість);

· розширення (виняткові ситуації);

· зв'язки;

· діаграми діяльності (для опису сценаріїв).

Приклад:

· Найменування - Пройти реєстрацію.

· Короткий опис - Процес реєстрації пасажира на рейс.

· Цілі - Отримати посадочний талон і здати багаж.

· Основний сценарій:

1. Пасажир стає у чергу до стійки реєстратора.

2. Пасажир пред'являє квиток реєстраторові.

3. Реєстратор підтверджує правильність квитка.

4. Реєстратор оформляє багаж.

5. Реєстратор резервує місце для пасажира.

6. Реєстратор друкує посадочний талон.

7. Реєстратор видає пасажирові посадочний талон і квитанцію на багаж.

8. Пасажир йде від стійки реєстратора.

· Альтернативні сценарії:

2а. Квиток неправильно оформлений - реєстратор посилає пасажира до агента з перевезень.

4а. Багаж перевищує встановлену вагу - реєстратор оформляє доплату.

· Спеціальні вимоги - Час реєстрації не повинен перевищувати 1 хвилини.

Зверніть увагу на нумерацію у сценаріях. Альтернативний сценарій 2а. Квиток неправильно оформлений виникає на 2-му етапі основного сценарію, 4а. Багаж перевищує встановлена вага - на 4-му.

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

При уточненні бізнес-процесу сукупність його сценаріїв може бути промодельована на діаграмі діяльності:

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

Проектування реалізації бізнес-процесів полягає у створенні моделі бізнес-аналіза (business analysis model, яку називають також business object model). За реалізацію бізнес-процесів відповідає інший виконавець у рамках RUP: бізнес-розробник.

Модель бізнес-аналізу - це об'єктна модель, елементами якої є виконавець (business worker) і бізнес-сутність (business entity). Business worker - клас є абстракцією працівника або посадової особи, діючої у рамках підприємства. Він має зв'язки взаємодії з іншими виконавцями і маніпулює бізнес-сутностями, беручи участь в реалізаціях business use-case. Представляється на діаграмах як клас або екземпляр класу із стереотипом «business worker».

Business entity - пасивний клас (або об'єкт), який не ініціює ніяких взаємодій, він може брати участь у багатьох різних business use-case -реалізаціях і є предметом різних маніпуляцій з боку business workers. На діаграмах він представлений класом із стереотипом «business entity».

Модель бізнес-аналіза включає діаграми різних видів:

· Діаграми класів VOPS (view of participating classes - класи-учасники реалізації даного бізнес-процесу), які зображають зв'язки між виконавцями, зв'язки між бізнес-сутностями і зв'язками вигляду «виконавець-сутність», вказуючи з якою сутністю має справу виконавець. (Приклад показує, що в реалізації бізнес-процесу Пройти реєстрацію беруть участь два виконавці: Реєстратор і Координатор багажу; вони взаємодіють один з одним; реєстратор маніпулює сутністю Багаж і Багажна бірка, тобто зважує багаж, друкує бірку і прикріплює її; Координатор багажу маніпулює тільки багажем, тобто отримує його для вантаження в літак; сутності Багаж і Багажна бірка зв'язані між собою, оскільки кожна бірка прикріплена до конкретного багажу, а кожен багаж повинен мати бірку).

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

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

Мал. Діаграма станів для бізнес-сутності Багаж.

У ході бізнес-процесів можуть виникати критичні події або так звані бізнес-події, кожна з яких характеризується тим, що:

· є важливим, нетривіальним;

· виникає у непередбачуваний момент часу;

· не залежить від інших бізнес-подій;

· вимагає негайної реакції.

Бізнес-розробник зобов'язаний уточнити модель бізнес-аналізу, додавши на діаграми класів бізнес події. Наприклад:

Цей фрагмент діаграми класів відноситься до діяльності торгового підприємства і зображає зв'язки бізнес-подій Inventory Low ( недостатня кількість продукту) з бізнес-сутностями і виконавцями. Вказано, що подія пов'язана з сутністю Product; вона має атрибути: склад і асортимент; виявляє недостатню кількість продукту (тобто «посилає» цю подію) заготівельник, а реагувати на неї повинен постачальник (тобто він «приймає» подію і заповнює нестачу продукту).

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

· правила-обмеження;

o управляючі дії і реакції на дії;

o операційні обмеження (передумови і постумови);

o структурні обмеження;

· правила виведення;

· правила обчислень.

Облік управляючих дій і операційних обмежень відбивається на діаграмах діяльності. Наприклад, операційне обмеження: «Доставити замовлення клієнтові тільки за наявності адреси доставки» повинно бути відбите при складанні діаграми діяльності постачання товару, а саме, потрібно врахувати, що адреса може бути невідомою і необхідні дії з її з'ясування:

Структурні обмеження встановлюють потужності зв'язків між бізнес-класами. Наприклад, структурне обмеження: «Замовлення містить принаймні одну позицію» відбивається на діаграмі класів:

Правила виведення пояснюють, як виводяться ті або інші факти, наприклад, як визначається статус покупця: «Покупець має статус «хороший», тільки в тому випадку, якщо всі свої рахунки він оплачує протягом 30 днів». Відповідно до такого правила на діаграмі діяльності повинне з'явитися галуження і можлива примітка або посилання на піддіаграму, де вказано як саме перевіряється умова галуження (тут бізнес-правило визначає галуження good/bad customer):

Правила обчислень встановлюють як ведуться розрахунки, наприклад: Ціна нетто = ціна продукту * (1 + відсоток податку/100). За наявності такого правила необхідно встановити зв'язки на діаграмі класів, які дозволяють виконавцеві отримати всі потрібні значення для підстановки у формулу (тут виконавець бере ціну продукту за маршрутом Замовлення -> Продукт, а відсоток податку - Профіль клієнта -> Профіль регіону).

Структуризація моделі бізнес-аналізу здійснюється за допомогою таких елементів як реалізація бізнес-процесу (кооперація із стереотипом «business use case realization») і бізнес-система (пакет із стереотипом «business system»). Реалізація бізнес-процесу відноситься до конкретного бізнес процесу і включає діаграми взаємодії, які відносяться до його сценаріїв, і його діаграму класів VOPC. Бізнес-система об'єднує бізнес-об'екти (business workers, business entities), які відносяться до одного підрозділу, зв'язки між ними. Бізнес системи можуть містити в собі інші бізнес-системи (які відповідають підлеглим відділам підрозділу). Наприклад, аеропорт може бути розбитий на залежні одна від одної бізнес-системи:

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

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

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

· статичне представлення - діаграму класів;

· динамічне представлення - діаграми діяльності.

Приклад. Бізнес-зразок «Зайнятість».

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

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

Сукупність учасників

Статичне представлення (структурні зв’язки)

Інша методика бізнес-моделювання розроблена Еріксоном і Пенкером. Метод Ericsson-Penker представляє інтерес перш за все у зв'язку із спробою застосування мови UML (спочатку призначеної для моделювання архітектури систем ПЗ) у рамках процессного підходу до моделювання бізнес-процесів. Це стало можливим завдяки наявності в UML механізмів розширення (у першу чергу - стереотипів). Автори методу створили свій профіль UML для моделювання бізнес-процесів, ввівши набір стереотипів, які описують процеси, ресурси, правила і цілі діяльності організації.

Метод використовує чотири основні категорії бізнес-моделі:

· Ресурси - різні об'єкти, які використовуються або беруть участь в бізнес-процесах (люди, матеріали, інформація або продукти). Ресурси структуровані, взаємозв'язані і поділяються на фізичні, абстрактні, інформаційні і людські.

· Процеси - види діяльності, яі змінюють стан ресурсів відповідно до бізнес-правил.

· Цілі - призначення бізнес-процесів. Цілі можуть бути розбиті на підцілі і співставлені з окремими процесами. Цілі досягаються у процесах і виражають необхідний стан ресурсів. Цілі можуть бути виражені у вигляді одного або більш правил.

· Бізнес-правила - умови або обмеження виконання процесів (функціональні, поведінкові або структурні). Правила можуть диктуватися зовнішнім середовищем (інструкціями або законами), або можуть бути визначені у межах бізнес-процесів. Правила можуть бути визначені з використанням мови OCL, яка є частиною стандарту UML.

У рамках методу бізнес-модель має 4 представлення:

· Концептуальне представлення - структура цілей і проблем.

· Представлення процесів - взаємодія між процесами і ресурсами.

· Структурне представлення - структура організації і ресурсів.

· Представлення поведінки - поведінка окремих ресурсів і процесів (діаграми діяльності, станів, взаємодії).

Концептуальне представлення схоже з моделлю бізнес-цілей RUP, але розширене за рахунок вказівки у кожної мети 4-х приміток: проблеми, причини, дії, попередньої умови дії (див. примітки до мети Links from Other Sites).

Мал. Концептуальне представлення бізнес-моделі веб-сайту новин.

Представлення процесів містить діаграми діяльності на яких зображені бізнес-процесси і їх контекст. У методі Eriksson-Penker процес на діаграмі діяльності представляється діяльністю із стереотипом " process ". Процес використовує вхідні ресурси і формує вихідні ресурси, показані у вигляді об'єктів із стереотипом " resourse ", сполучених з процесом зв'язками залежності. Ресурси, які грають ролі " управління " і " механізму ", також сполучені з процесом зв'язками залежності із стереотипами " supply " і " control ". Мета процесу показана як об'єкт із стереотипом " goal ".

Мал. Шаблон діаграми діяльності для представлення процесів.

Мал. Діаграма діяльності процесу Продажі

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

моделлю бізнес-систем у рамках RUP, воно також відображає організаційну структуру організації, але на відміну від RUP підрозділ представляється не пакетом (бізнес-системою), а об'єктом класу Organizational Unit.

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

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

На даній діаграмі приведена структура інформаційних ресурсів (вони представлені класами із стереотипами «information»).

Представлення поведінки описує поведінка окремих ресурсів у вигляді діаграм станів і деталізує процеси у вигляді діаграм діяльності і взаємодії.

Діаграма станів для ресурсу Order показує, як міняється його стан під час бізнес-процесу.

Література до лекції 4

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

Дата добавления: 2014-01-07