Хід роботи

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

Об’єкт дослідження

предмет дослідження

Бізнес-Процес - облік руху кадрів на підприємстві

Мета

Метод вирішення – удосконалення обліку кадрів засобом автоматизації бізнес-задач

Бізнес-задача

Підзадача бізнес-задачі

Актор

Документ, річ, повідомлення, сигнал

Обмеження

1. Аналіз опису предметної області

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

Досягнення поставленої мети здійснюється впровадженням автоматизованого рішення наступних завдань:

прийом в працівники (1);

переміщення працівників (2);

звільнення працівників (3);

аналіз кадрового стану підприємства (4).

У розроблюваному модулі необхідно передбачити ідентифікацію користувачів системи *.

Кінцевий користувач повинен мати можливість в повному обсязі** виконувати операції з даними по робітникам (234), посадам (1234), підрозділам (1234), статтям звільнень(3), щоб здійснювати облік прийнятих, переміщених та звільнених працівників.

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

* - якщо є потреба у багатокористувальницькому режимі

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

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

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

Розглянемо різновиди обмежень.

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

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

Таблиця 1

Можливі параметри обмеження

Тип обмеження	Приклад
Частота	3 рази на добу
Тривалість	Впродовж 5 секунд
Дата	Дата початку 5 вересня, дата закінчення 3 лютого, до 20.02.09, після 13.08.09 і т. ін.
Момент часу	З моменту отримання сигналу, в 12.00 і т.ін.
Період	З 12.00 до 13.00, кожну п’ятницю, з 12.10.08 до 12.11.08 і т. ін.
Кількість	Кількість копій документа, кількість повідомлень
Тип носія	Електронний, паперовий, звуковий
Форма документу	А2, А12, і т. ін.
Формат даних	PDF, TXT, HTML, DOC, XLS і т. ін.
Стан	Стан рахунку (открыт, закрыт, заблокирован, разблокирован)
Список прийнятних значень	{Синій, Червоний, Білий} і т. ін.
Точність	3 десятичних знака після коми
Продуктивність	Три на годину і т.ін.
Умови роботи чи експлуатації	при багато користувальницькому доступі до даних, при виникненні наступних умов: <перелік умов> тощо

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

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

Крім неї для заповнення таблиці 2 можна використовувати наступні матеріали:

діаграми, що описують бізнес-процес, організаційну структуру, функції, потоки даних, документообіг;

зразки заповнених форм документів;

опис одиниць інформації вхідних і вихідних документів, повідомлень чи сигналів;

формати повідомлень;

зображення чи докладний опис об’єктів;

опис сигналів;

методики розрахунку показників і т. ін.

Зазначену допоміжну інформацію зазвичай наводять в розділі додатків документа SRS.

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

Таблиця 2

Інформація для побудови списку ключових C-вимог

Актор	Завдання	Обме-ження на завдання	Підзадача	Обмеження на підзавдання	Документи, повідомлення, сигнали, об’єкти
					Вхідні (атрибути) /джерело	Обме-ження	Вихідні (атрибути) /отримувач	Обмежен-ня	Управляю-чі (параме-три) /джерело	Обмежен-ня
Спеціа-ліст відділу кадрів	1.Зарахування нового працівника	Вико-нуєть-ся за запи-том	1.1. Перегляд даних про кандидата в працівники	Ручна*	Резюме (ПІБ, рік народжен-ня, стать, освіта); Диплом (ПІБ, ВНЗ, спеціаль-ність, каліфікація, номер диплома, дата видачи, період навчання, рівень освіти); трудова книга(стаж, спеціаль-ність, розряд чи категорія) / новий працівник		Інформа-ція** про кандидата в працівники (ПІБ, рік народжен-ня, стать, ВНЗ, спеціаль-ність, каліфі-кація, номер диплома, дата видачи, період навчання, рівень освіти, стаж, спеціаль-ність, розряд чи категорія) / Спеціаліст відділу кадрів
			1.2.Дода-вання даних про нового працівника	Авто-мати-зована	Інформа-ція** про кандидата в працівники / задача 1; Штатний розклад (посада, вітділ, оклад) / Спеціаліст відділу кадрів		Інформація про працівника (Інформа-ція** про кандидата в праців-ники, посада, вітділ, оклад, дата призна-чення) / комп’ютер
	2.Перемі-щення працівника	Вико-нуєть-ся за запи-том	2.1.Пере-гляд даних про працівника	Авто-мати-зована	Інструкція на перемі-щення (ПІБ, вітділ) / Спеціаліст відділу кадрів		Інформація про працівника / Спеціаліст відділу кадрів
			2.2.Редагу-вання даних про працівника	Авто-мати-зована	Інструкція на перемі-щення (ПІБ, вітділ) / Спеціаліст відділу кадрів		Інформа-ція** про працівника ( посада, вітділ, дата призна-чення) / комп’ютер		Правила переміщен-ня працівників
	3.Звільнення працівника	Вико-нуєть-ся за запи-том	3.1.Пере-гляд даних про працівника	Авто-мати-зована	Інструкція на звільнення (ПІБ, відділ) / Спеціаліст відділу кадрів		Інформація про праців-ника** / Спеціаліст відділу кадрів
			3.2.Редагу-вання даних про працівника	Авто-мати-зована	Інструкція на звільнення (ПІБ, вітділ, підстава для звільнення, дата звільнення) / Спеціаліст відділу кадрів	Пере-лік статей звіль-нень,	Інформа-ція** про працівника ( посада, вітділ, причина звільнення, дата звільнення) / комп’ютер		Довідник статей звільнень (умови звільнення,номер статті, причина звільнення), правила звільнення працівника / Спеціаліст відділу кадрів
			3.3.Вида-лення даних про звільненого працівника	Авто-матич-на	Інформа-ція** про працівника (дата звільнення) / комп’ютер	Раз у місяць в остан-ню ніч місяця, період
	4.Аналіз кадрового стану підприємства	Вико-нуєть-ся раз у місяць	4.1.Пере-гляд даних про працівників	Авто-мати-зована	Дані про працівників(ПІБ, рік народжен-ня, освіта) / Спеціаліст відділу кадрів	Вико-нується за запи-том	Інформація про працівника / Спеціаліст відділу кадрів	Кількість повідом-лень дорівнює кількості праців-ників
			4.2.Пере-гляд даних по посадам	Авто-мати-зована	Дані про працівників(посада) / Спеціаліст відділу кадрів	Вико-нується за запи-том, перелік посад	Інформація про працівника / Спеціаліст відділу кадрів	Кількість повідом-лень дорівнює кількості праців-ників на вказаній посаді	Штатний розклад (перелік посад)
			4.3.Пере-гляд даних по статтям звільнень	Авто-мати-зована	Дані про статтю звільнень (номер статті, причина звільнення)/ Спеціаліст відділу кадрів	Вико-нується за запи-том, Перелік статей звіль-нень,	Інформація про працівника / Спеціаліст відділу кадрів	кількість повідом-лень дорівнює кількості праців-ників, звільне-них за вказаною статею й при-чиною	Довідник статей звільнень (умови звільнення,номер статті, причина звільнення) / Спеціаліст відділу кадрів
			4.4.Форму-вання й друк відомості прийнятих працівників	Авто-мати-зована	Дані про період (початкова дата, кінцева дата) / Спеціаліст відділу кадрів	період	Відомість прийнятих праців-ників / Спеціаліст відділу кадрів	форма: А12; вид: електронна та паперова (1 при-мірник)	Вигляд відеокадру й машинограми в 1 примірнику
			4.5.Форму-вання й друк відомості переміщених працівників	Авто-мати-зована	Дані про період (початкова дата, кінцева дата) / Спеціаліст відділу кадрів	період	Відомість перемі-щених працівник-ків / Спеціаліст відділу кадрів	форма: електронна та паперова (1 при-мірник)	Вигляд відеокадру й машинограми в 1 примірнику
			4.6.Форму-вання й друк відомості звільнених працівників	Авто-мати-зована	Дані про період (початкова дата, кінцева дата) / Спеціаліст відділу кадрів	період	Відомість звільнених праців-ників / Спеціаліст відділу кадрів	форма: електронна та паперова (1 при-мірник)	Вигляд відеокадру й машинограми в 1 примірнику
			4.7. Розрахунок показників плинності кадрів	Авто-мати-зована	Відомості прийнятих працівників (кількість за посадами та за відділами), відомості переміще-них працівників (кількість за посадами та за відділами), відомості звільнених працівників (кількість за посадами та за відділами) / Спеціаліст відділу кадрів	період	показник плинності кадрів за посадами (Кпi), показник плинності кадрів за відділами (Квi), Загальний показник плинності кадрів (К) / Спеціаліст відділу кадрів	Кпi = ; Квi = ; К = ; Точність: 1 знак після коми	Методика розрахунку показників плинності кадрів (дивись додаток 1)
			4.8.Форму-вання та друк звіту про стан кадрів на підприємстві	Авто-мати-зована	Відомості прийнятих працівників (кількість на посадах та у відділах), відомості переміще-них працівників (кількість на посадах та у відділах), відомості звільнених працівників (кількість на посадах та у відділах), показники плинності кадрів за посадами (Кпi), показники плинності кадрів за відділами (Квi), Загальний показник плинності кадрів (К)/ Спеціаліст відділу кадрів	період	звіт про стан кадрів на підприємстві / Спеціаліст відділу кадрів, Начальник відділу кадрів		Вигляд відеокадру й машинограми в 1 примірнику

Позначки:

* - операція може виконуватися актором вручну чи автоматизовано (за допомогою комп’ютера) або комп’ютером автоматично.

** - слово «інформація» в даному контексті означає «інформаційне повідомлення», яке після фіксації в розумі аналітика чи в базі даних стає «інформаційним об’єктом».

На основі отриманих даних сформуємо табл. 3.

Таблиця 3

Аналіз бізнес-акторів та ролей спеціаліста відділу кадрів

	Аналітик (працівник відділу кадрів)	Спеціаліст з інформаційного забезпечення (працівник відділу кадрів)
Проблема	велика плинність кадрів (як основна проблема) яка призводить до низького рівня кадрового потенціалу та неефективності його використання	значні витрати часу та грошей на облік руху кадрів
Об’єкт (якась система)	кадри підприємства	система обліку кадрів підприємства
Предмет (процес як зміна стану чи послідовність дій)	рух кадрів	облік руху кадрів підприємства
Мета дослідження (результат)	Соціально-економічний механізм управління кадрами підприємства	Соціально-технічний механізм інформаційного забезпечення підсистеми обліку кадрів
Бізнес-процес (послідовність дій, що має ціль та визначається кількісними показниками)	аналіз руху кадрів та надання рекомендацій щодо підвищення рівня кадрового потенціалу підприємства та ефективності його використання	облік руху кадрів, інформаційне забезпечення, зменшення рівня витрат часу та грошей на облік руху кадрів, збільшення рівня продуктивності праці працівників відділу кадрів
Бізнес-процедури (це зміст ділового процесу)	аналіз кадрового стану підприємства (4)	прийом в працівники (1) переміщення працівників (2) звільнення працівників (3)
Метод вирішення	удосконалення аналізу руху кадрів засобом автоматизації бізнес-задач	удосконалення обліку кадрів засобом автоматизації бізнес-задач

З цієї таблиці видно, що хоча у нас є один бізнес-актор (працівник відділу кадрів), він виконує декілька ролей, а саме: ролі аналітика та постачальника даних (будемо назвати його оператором), об’єкт, предмет і мета дослідження діяльності яких досить різні. Це свідчить про імовірну необхідність розгляду декількох режимів функціонування системи: наприклад, режиму оператора та режиму аналітика, для яких можна розглянути окремі представлення щодо використання системи (view), тобто operator view та analyst view. Формування представлень – це інструмент для моделювання модульної системи, що має бути розроблена.

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

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

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

• процессы важные для организации с коммерческой точки зрения, а именно процессы, связанные с клиентами и партнерами организации (можливі бізнес-актори – співробітник та клиент);

• бизнес-процессы, связанные с поддержкой коммерческих процессов, - администрирование автоматизированных систем, процессы обеспечения безопасности и т.п. (можливі актори - администратор (данных, приложения, баз данних, системы));

• бизнес-процессы, связанные с управлением коммерческими и поддерживающими бизнес-процессами (можливі ролі бізнес-акторів – аналітик, супервізор).

Всегда нужно начинать с бизнес-процессов, которые относятся к клиентам, партнёрам, операторам. Обычно это деловые процедуры с чётким сценарием.

Затем рассмотреть задачи аналитика, который должен формировать отчёты и выполнять интенсивные вычисления с большими объёмами данных.

Супервизор в чём-то похож на клиента, однако у него должна быть возможность просматривать служебные данные, некоторые отчёты, изготовленные аналитиками и наблюдать процессы и их отдельные состояния.

Адміністратор может виконувати такі 4 ролі:

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

2. Адміністратор додатка (виконує настроювання додатка, тестування та перевірки його придатності до роботи).

3. Адміністратор баз даних (виконує створення, настроювання та управління базами даних додатка).

4. Адміністратор системи (виконує настроювання середовища виконання програм додатка, інсталяцію та оновлення компонентів додатка).

Резервне копіювання (BackUp) та відтворення (Recovery) даних додатка може виконувати адміністратор даних. Якщо ж ці операції реалізовані як частина суцільного резервного копіювання системи, то копіювання та відтворення даних виконує адміністратор системи.

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

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

1. Режим взаємодії з клієнтом.

2. Режим оператора.

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

4. Режим супервізора.

5. Режим адміністратора даних.

6. Режим адміністратора додатка.

7. Режим адміністратора баз даних.

8. Режим системного адміністратора.

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

Якщо в задачі є один або декілька бізнес-акторів, то для кожного з бізнес-акторів треба з’ясувати усі його ролі.

В таблиці 3 треба створити відповідні до ролей стовбці й розглянути для кожної ролі відповідні їй:

проблеми,

об’єкт,

предмет,

мету,

бізнес-процес

та заповнити таблицю а також створити UML-модель (див. рис. 1).

Таким чином таблиця 3 може допомогти спроектувати модульний додаток, але на етапі формулювання вимог її також можна використати для групування вимог. Взагалі перш ніж формулювати вимоги необхідно обрати спосіб їх групування (див. табл.. 4).

Таблиця 4

Ознаки групування вимог

Ознака	Примітка
Режим	Якщо потрібно надати додатку модульність, зручність використання для користувача й уникнути конкуренції за критичні ресурси
Функція	Можна групувати вимоги за відділом, посадовою особою, бізнес-задачами, які ця особа виконує
Діюча особа	Можна групувати вимоги як у попередньому випадку. Однак у випадку наскрізного бізнес-процесу можна лише позначувати але не вкладати діючу особу та пов’язані з нею задачі у відділ
Сценарій (бізнес-варіант, тобто задача чи під-задача)	Для кожної дійової особи можна призначити перелік бізнес-задач, які вона має вирішувати. У цьому випадку вимоги групуються за конкретною задачею чи її під задачею
Властивість (варіант використання чи сервіс)	Якщо вимоги згруповано одним з попередніх способів, то можна прив’язати до кожної бізнес-задачі чи її під задачі сукупність сервісів (варіантів використання), необхідних для вирішення задачі та бажаних користувачем додаткових сервісів, які йому має надавати система, що розробляється
Стан	Якщо склад режимів, діючих осіб, їх задачі та сервіси системи значно різняться у залежності від стану деякого об’єкту, що спостерігається (наприклад відносно надійних та ненадійних клієнтів, або відкритого, закритого чи заблокованого рахунку), то можна згуртувати вимоги за станами об’єктів, що спостерігаються.

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

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

В UML-моделі для кожного представлення виділимо пакети з бізнес-задачами, де кожній задачі назначимо свій пакет (рис. 2) , а в пакеті сформуємо діаграму потоків даних та операцій, що відображує вирішення цієї задачи (рис. 3).

Для кожної бізнес-задачи треба побудувати діаграму бізнес-вариантів (з вказанням вхідних і вихідних документів, повідомлень, об’єктів, а також їх атрибутів), використовуючи інформацію з табл.. 1–3.

Рис. 1. Можливі режими

Рис. 2. Діаграма бізнес-задач

для представлення оператора

Целью разработки модели бизнес-процессов (Business Use Case Model) является определение бизнес-процессов, подлежащих автоматизации, связей между ними и целей, которые они поддерживают.

Модель бизнес-процессов, подлежащих автоматизации, следует использовать при разбиении системы на подсистемы на этапе определения требований к системе.

Каждому из выделенных бизнес-процессов предлагается в дальнейшем на этапе Определения требований к системе (Requirements) поставить в соответствие подсистему в разрабатываемой системе.

Например, бизнес-процесс учета и оформления валютных операций включает два бизнес-процесса: учет и оформление валютных операций и учет и оформление депозитных операций. След., например, система учета и оформления валютных операций может включать две подсистемы: подсистему учета и оформления валютных операций и подсистему учета и оформление депозитных операций.

Если, рассматриваемые для автоматизации бизнес-процессы независимы друг от друга, то в разрабатываемой системе подсистемы также будут функционально независимы друг от друга.

Цели, которые поддерживают бизнес-процессы, следует использовать при определении целей разрабатываемой системы. На основе целей бизнес-процессов, подлежащих автоматизации, должны быть сформулированы цели разрабатываемой системы.

Например, целями, которые могут поддерживать процессы учета и оформления валютных операций могут являться:

• получение прибыли Банком

• мониторинг денежных средств;

• получение консолидированной отчетности для принятия управленческих решений;

• создание технологических и должностных инструкций для эффективного управления ресурсами.

Эти же цели могут и являться целями, разрабатываемой системы.

Для изображения собственно бизнес-процесса должен использоваться элемент бизнес-процесс (Business Use Case) (рис. 3).

Рис. 3. Пример изображения бизнес-процесса

Бизнес-процессы должны именоваться отглагольными существительными, например, производство стекловолокна, отгрузка готовой продукции.

Для отображения связей между бизнес-процессами можно использовать связи зависимости со следующими стереотипами:

• включает «include»;

• расширяет «extend»;

• родитель - потомок «generalization».

Для обозначения других типов связей между бизнес-процессами можно использовать связи зависимости с собственными стереотипами, например, стереотип основной сценарий, альтернативный сценарий.

Связь зависимость между бизнес-процессами со стереотипом включает «include», должна использоваться, когда разные бизнес-процессы включает в себя один и тот же бизнес-процесс. Для связи со стереотипом включает «include» стрелку следует направить к включаемому бизнес-процессу от включающего. Связь отображается прерывистой линией с названием стереотипа.

На рис. 1.2 представлен пример связи зависимость со стереотипом включает «include».

Рис. 4. Пример связи между процессами включает «include»

Некоторые бизнес-процессы могут выполняться при наступлении определенных условий или быть опциональными. В этом случае следует использовать связь-зависимость со стереотипом расширяет «extend» (рис. 1.3). Эту связь удобно использовать при отображении бизнес-процессов, которые должны выполняться, например, в исключительных ситуациях или при наступлении определенных условий. Для связи со стереотипом расширяет «extend», стрелку следует направлять к бизнес-процессу, который расширяется другим бизнес-процессом, от бизнес-процесса, который его расширяет. Связь отображается прерывистой линией с названием стереотипа.

Рис. 5. Пример связи между процессами со стереотипом включает «extend»

Связь со стереотипом родитель – потомок «generalization» должна использоваться, когда необходимо чтобы бизнес-процесс потомок обладала всеми свойствами бизнес-процесса родителя и возможно какими – то дополнительными свойствами. Связь со стереотипом родитель – потомок «generalization» отображается сплошной линией с большой треугольной стрелкой. Стрелка направляется от потомка к родителю.

На рис. 6 представлен пример использования связи между бизнес-процессами со стереотипом родитель – потомок «generalization».

Рис. 6. Пример использования связи между бизнес-процессами

со стереотипом родитель - потомок «generalization»

На рис. 1.4 процесс родитель есть процесс ведение журналов, процесс потомок – ведение журнала продукции.

Для изображения субъекта или объекта, являющегося инициатором бизнес-процесса или потребителем результатов бизнес-процесса, необходимо использовать элемент бизнес роль (рис. 7).

Рис. 7. Изображение элемента Бизнес роль

Роль должна именоваться исходя из контекста. Для отображения связи между ролью и бизнес-процессом должна использоваться связь ассоциация. Можно задавать стереотип для этой связи, например, «communicate» («взаимодействует»). Связь отображается сплошной линией с названием стереотипа. Для отображения этих связей также можно использовать собственные стереотипы.

На рис. 8. представлен пример изображения ассоциативной связи между инициатором бизнес-процесса и бизнес-процессом со стереотипом взаимодействует «communicate».

Рис. 9. Пример изображения ассоциативной связи со стереотипом взаимодействует «communicate» между инициатором бизнес-процесса и бизнес-процессом

Связь между ролью и бизнес-процессом может не иметь направления в случае, если роль или бизнес-процесс могут инициировать взаимодействие. В случае инициации взаимодействия со стороны бизнес-процесса связь должна иметь направление от бизнес-процесса к бизнес-роли.

Бізнес-варіант – це аналог ділової задачи чи її підзадачи, що вирішується робітником (бізнес-актор чи Business worker) на підставі переліку функцій, що міститься в його посадовій інструкції. Робітник у цьому випадку – це посадова особа. Щоб зазначити конкретну людину використовується стереотип «Physical business worker». Щоб показати відділ, використовується стереотип «Organization Unit». Коли треба відобразити наскрізний бізнес-процес, треба сполучати бізнес-актора та підрозділ так як показано на рис. 1. Якщо бізнес-процес розгортається у межах одного підрозділу, то можна створити діаграму процесу, вкладену цілком в цей підрозділ.

Якщо задача містить підзадачи, її треба зображувати у вигляді стереотипу «Business system», тобто специфічного пакету (див. рис. 2), й розкривати його у діаграму, на якій розмістити відповідні пакети чи бізнес-варіанти для під-задач. Якщо ж вона не містить вкладених ділових під-задач, то також зображується стереотипом «Business system», а деталізується діаграмою бізнес-варіантів, на якій зображено процедуру, відповідну до рішення цієї під-задачи. На цій діаграмі процедури зображуються стереотипом «Business variant», а мають бути присутніми ділові сутності (Business entities) на ділові актори.

Наприклад, на рис.10 наведена діаграма ділової задачи «Переміщення робітника».

Рис. 10. Діаграма потоків даних для задачі «Переміщення робітника»

Для кожної бізнес-сутності треба вказати її важливі властивості та атрибути згідно з таблицею 2. Для цього треба зробити наступне:

1. Двічи клацнути на її позначці чи відкрити її контекстне меню (рис.11), в якому виконати команду Open Specification.

Рис. 11. Контекстне меню бізнес-сутності

2. У вікні, що відчиниться (рис. 12), треба перейти на вкладку Detail

Рис. 12. Назва, клас та стереотип бізнес-сутності

3. У вкладці Detail (рис. 13) треба встановити кількість копій сутності в полі Multiplicity, ознаку сталого існування (Persistent для документу чи таблиці бази даних, transient для тимчасово існуючих повідомлень).

Рис. 13. Сталість існування та кількість копій

4. На вкладці files треба встановити посилання на форму документу (рис. 14).

Рис. 14. Встановлення посилання на форму документу

5. На вкладці Attributes створити усі атрибути, що наведені в тапблиці 2 для цієї бізнес-сутності (рис. 15)

Рис. 15. Атрибути бізнес-сутності

6. Щоб показати їх на діаграмі, треба скористатися контекстним меню бізнес-сутності, в якому зняти помітку з опції Suppress attributes (рис. 16).

Рис. 16. Зняття помітки Suppress attributes для відображенння атрібутів сутностей на діаграмі

7. У результаті отримаємо наступне зображення бізнес-сутності на діаграмі (рис. 17)

Рис. 17. Бізнес-сутність зі своїми атрибутами.

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

Рис. 18. Діаграма потоків даних для задачі «Звільнення робітника»