Діаграма варіантів використання
Якщо сукупність бізнес-варіантів бізнес-процесу та їх діаграм відображає предметну область бізнес-процесу, тобто його межі, то сукупність діаграм варіантів використання відображає межі системи, що розробляється. Бізнес-варіант – це частина бізнес процесу, його складова, а варіант використання – це частина системи, що розробляється, її складова, сервіс, що система надає її користувачу.
Деякі ділові під-задачі можуть бути автоматизовані (виконуватися актором за допомогою системи, що розробляється) або виконуватися автоматично системою, що розробляється без участі актора-людини. Однак можуть бути ділові задачі, які неможливо або досить складно автоматизувати. Тому вони залишаються такими, що виконуються в ручну. Саме такі задачі ми не розглядаємо, а залишаємо для розгляду ті, що потенційно можуть бути автоматизовані або зроблені автоматично вирішуваними.
Для кожного бізнес-варіанту, що автоматизується, розглядаємо необхідний перелік сервісів системи для підтримки його автоматизованого вирішення. Кожний сервіс, якщо він відповідає елементарній функціональній С-вимозі, треба позначити стереотипом «Use case» та його зв’язати стрілкою Communicate з актором, який з ним взаємодіє (рис. 19).
Рис. 19. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Переміщення робітника»
Таким чином отримаємо сукупність діаграм варіантів використання, кожна з яких пов’язана з відповідним пакетом чи бізнес-варіантом, й зображує сервіси системи, що підтримують його автоматизоване чи автоматичне вирішення.
Щоб зв’язати бізнес-варіант з діаграмою варіантів використання, необхідно двічі клацнути лівою кнопкою миші на зображенні бізнес-варіанту або виконати команду Open specification з його контекстного меню (рис. 20), та у вікні, що відчиниться, перейти на вкладку «Diagrams» (рис. 21), створити в ній нову діаграму командою «Insert new Use Case Diagram» (рис. 22) й двічі клацнути на її позначці. У вікні діаграми, що відчиниться, треба створити акторів, варіанти використання та їх зв’язки (рис. 23).
Рис. 20. Вигляд контекстного меню бізнес-варіанту
Рис. 21. Додавання діаграми варіантів використання до бізнес-варіанту
Рис. 22. Діаграма варіанту використання, що була створена та
пов’язана зі бізнес-варіантом
Рис. 23. Діаграма варіантів використання для бізнес-варіанта
Так треба зробити для кожного бізнес-варіанту, що автоматизується.
Для зручності упізнавання таких бізнес-варіантів можна встановлювати їх кольорові відзнаки: колір межі та колір фону. Наприклад, красний колір для межі стереотипу «Business variant» (рис. 24).
Рис. 24. Діаграма потоків документів, потоків даних та процедур
для задачі «Переміщення робітника»
Рис. 25. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Переміщення робітника»
Рис. 26. Діаграма потоків документів, потоків даних та процедур
для задачі «Звільнення робітника»
Рис. 27. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Звільнення робітника»
Рис. 28. Діаграма бізнес-задач
для представлення аналітика (Analyst view)
Рис. 29. Діаграма потоків документів, потоків даних та процедур
для задачі «Формування відомостей»
Рис. 30. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Формування відомостей»
Рис. 31. Діаграма потоків документів, потоків даних та процедур
для задачі «Аналіз кадрового стану»
Рис. 32. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Аналіз стану кадрів»
Рис. 33. Діаграма варіантів використання (сервісів), що підтримують
автоматизоване вирішення задачі «Аналіз кадрового стану»
Таку модель аналітик надає розробнику, тобто той отримує величезну сукупність варіантів використання, яка структурована за допомогою пакетів на дуже прості діаграми. Він має з’єднати їх в одну чи декілька загальних діаграм, щоб побачити усі варіанти використання та створити мінімально необхідний й достатній їх склад для системи, що розробляється.
Для цього він має визначити ті варіанти, які використовуються іншими варіантами й з’єднати з ними стрілкою стереотипу «include». Потім треба визначити варіанти розширення та варіанти узагальнення/спеціалізації та модифікувати діаграму. Ці діаграми причепити до пакету, що містить діаграму бізнес-варіантів підзадачі.
Після цього треба таким же чином з’єднати варіанти використання з усіх діаграм, що причеплені до пакетів, які містяться в пакеті задачі. Коли це зроблено, таким же чином треба створити єдину діаграму варіантів використання для представлення ролі бізнес-актора в цілому.
Згодом отримаємо мінімально необхідний й достатній склад варіантів використання, тобто, чітко визначимо контекст та межі системи, що розробляється.
С точки зрения клиента ключевыми являються те требования выполнение которых позволит бізнес-процесу успішно завершиться. Но сформировав их список мы прийдём к выводу, что для их піддержки необходимы дополнительные требования, которые позволят удовлетворить ключевые для заказника требования и должны біть реализованы первыми. Поэтому таким требованиям назначается наивысший пріоритет 1, а ключевым для клиента – пріоритет 2. Затем нужно рассмотреть дополнительные сервисы для увеличения удобства решения задачи пользователем системы. Например дополнительные сервисы и назначить им пріоритет 3.
Приоритет назначается для удобства управления требованиями исходя из следующих оснований: не известно, будет ли реализовываться требование вообще, не известно как оно будет реализовываться (решений об архитектуре, языке программирования, средствах проектирования и разработки ещё не принято), не известно насколько сложно его реализовать, не известно, кто его будет реализовывать (для кратчайших сроков реализации требований удобно реализовывать их не последовательно одно за другим, а паралельно, несколькими разработчиками ранніх тренований одновременно).