Міністерство освіти і науки, молоді та спорту України Національний університет водного господарства та природокористування Кафедра землеустрою, геодезії та геоінформатики 076-150 Методичні вказівки до виконання лабораторних робіт з дисципліни «Планування та управління ГІС – проектами» студентами зі спеціальності 7.08010105 та 8.08010105 „Геоінформаційні системи та технології” денної форми навчання Рекомендовано методичною комісією зі спеціальності „Геоінформаційні системи та технології” Протокол №2 від 25 жовтня 2011 р. Рівне 2012

2

Методичні вказівки до виконання лабораторних робіт з дисципліни «Планування та управління ГІС–проектами» студентами напряму підготовки 7.08010105 та 8.08010105 „Геодезія, картографія та землеустрій”/ Лагоднюк О.А., Прокопчук А.В., Ревуцький В.Р.. - Рівне: НУВГП, 2012.- 30 с. Упорядники: Лагоднюк О.А., доцент кафедри землеустрою, геодезії та геоінформатики, Прокопчук А.В., асистент кафедри землеустрою, геодезії та геоінформатики, Ревуцький В.Р., асистент кафедри землеустрою, геодезії та геоінформатики. Відповідальний за випуск: Черняга П.Г., доктор технічних наук, професор кафедри землеустрою, геодезії та геоінформатики Лагоднюк О.А. Прокопчук А.В. Ревуцький В.Р. НУВГП, 2012

3

Зміст 1. Лабораторна робота №1: Створення діаграм прецедентів (сценаріїв виконання)………………………………..…………4 2. Лабораторна робота №2: Створення діаграми класів………11 3. Лабораторна робота №3: Створення діаграми послідовностей…………………………………………...……17 4. Лабораторна робота №4: Створення діаграми взаємодій…..20 5. Лабораторна робота №5: Створення діаграми станів......…..22 6. Лабораторна робота №6: Створення діаграми діяльності.…25 7. Варіанти завдань……………………………………….…...…29 8. Список літератури………………………………………….....30

4

Лабораторна робота № 1 Створення діаграм прецедентів (сценаріїв виконання) Мета роботи: одержати навички побудови діаграм прецедентів. Завдання: 1. Створити головну Діаграму прецедентів, зобразивши на ній Сценарії виконання та акторів; 2. Додати зв'язки між Акторами й Сценаріями виконання; 3. Створити додаткову Діаграму прецедентів; 4. Описати Акторів і Сценарії виконання; 5. Для кожного сценарію задати та прикріпити потік подій у вигляді окремого файлу. Зміст звіту: - створені Діаграми прецедентів; - короткий опис кожного Актора й Прецедента; - опис потоку подій для кожного Сценарію виконання. Приклад виконання роботи. Примітка: У цьому й наступному прикладах ми будемо проектувати систему для предметної області "Підприємство із збирання й продажу комп'ютерів". Для того, щоб приступити до створення UML (англ. Unified Modeling Language) діаграми потрібно виконати: Файл=>створити=>приступаючи до роботи. По іншому, це можна зробити так: Файл=>Створити=>Програмне забезпечення=>Схема моделі UML. В Провіднику по моделям, клацніть правою кнопкою миші по пакету або підсистемі, в яку потрібно додати Схему сценаріїв виконання, а потім виберіть команду Створити й пункт Схема сценаріїв виконання. Відкриється порожня сторінка, набір елементів Сценарій виконання UML відобразиться першим. На робочій області з'явиться водяний знак "Сценарій виконання". У Провіднику по моделям буде додано значок, який представляє схему. Примітка. Якщо провідник по моделям не відображається, виберіть у меню UML команду Вид, а потім - команду Провідник по моделям.

5

Перетягніть фігуру Межа системи на сторінку документу. Щоб змінити межі даної фігури потрібно виділити фігуру, а потім змінити контур, потягнувши за маркер виділення. Щоб назвати фігуру, потрібно виділити фігуру, а потім ввести ім'я. Щоб перемістити фігуру разом з сценаріями виконання, які там містяться, потрібно розтягнути навколо фігури Межа системи рамку виділення, виділивши в ній всі фігури Сценаріїв виконання, а потім перетягнути всі фігури в потрібне місце. Для нашої предметної області ми виділили наступних Акторів: Таблиця 1 Опис акторів Актор Короткий опис Менеджер з роботи із клієнтами Співробітник, який спілкується із замовником і працює із замовленням Менеджер з постачання Співробітник, який займається закупівлею необхідних комплектуючих Інженер із складання настільних комп'ютерів Співробітник, який займається складанням настільних комп'ютерів Інженер із складання ноутбуків Співробітник, який займається складанням ноутбуків Інженер з тестування Співробітник, який займається тестуванням настільних комп'ютерів та ноутбуків Завскладом Співробітник, який завідує складом комплектуючих Давайте конкретніше розглянемо, функції акторів нашої системи: - актор “Менеджер з роботи із клієнтами” використовує систему для оформлення, редагування замовлень і керування інформацією про клієнтів підприємства; - актор “Менеджер з постачання” використовує систему для перегляду переліку необхідних для закупівлі комплектуючих і ведення інформації про постачання; - актор “Інженер із складання настільних комп'ютерів” використовує систему для перегляду технічних завдань на

6

складання настільних комп'ютерів, для замовлення комплектуючих зі складу й фіксації ходу виконання робіт; - актор “Інженер із складання ноутбуків” використовує систему для перегляду технічних завдань на складання ноутбуків, для замовлення комплектуючих зі складу й фіксації ходу виконання робіт; - актор “Інженер з тестування” використовує систему для перегляду технічних завдань на тестування зібраної продукції й фіксації ходу виконання робіт; - актор ”Завскладом” використовує систему для обліку надходження й видачі комплектуючих. На підставі вищевикладеного, можна виділити наступні Сценарії виконання: Таблиця 2 Опис сценаріїв виконання Сценарій Короткий опис Робота із замовленням Виконується Менеджером з роботи із клієнтами. Дозволяє вносити, змінювати, видаляти або переглядати замовлення. Керування інформацією про клієнта Виконується Менеджером з роботи із клієнтами. Дозволяє переглядати, додавати, змінювати або видаляти дані про клієнтів. Керування інформацією про постачальників Виконується Менеджером з постачання. Дозволяє переглядати, додавати, змінювати або видаляти дані про постачальників. Керування інформацією про комплектуючі Виконується Менеджером з постачання. Дозволяє переглядати інформацію про комплектуючі, виконувати аналіз їхньої витрати, прогнозувати необхідну кількість комплектуючих і робити замовлення. Складання комп'ютерів Виконується Інженером із складання. Дозволяє переглядати технічні завдання на складання комп'ютерів і робити відмітки про хід виконання роботи. Замовлення комплектуючих Виконується Інженером із складання. Дозволяє замовляти необхідні комплектуючі зі складу.

7

продовження таблиці 2 Тестування комп'ютерів Виконується Інженером із тестування. Дозволяє переглянути список комп'ютерів, що підлягають тестуванню й зробити відмітку про хід виконання робіт. Облік надходження й видачі комплектуючих Виконується завідуючим складом. Дозволяє вести облік надходження й видачі запчастин і комплектуючих. Перетягніть фігури Сценаріїв виконання з набору елементів й розмістіть їх всередині системи. Потім перетягніть та розмістіть за межею системи фігури Акторів. На Схемі сценаріїв виконання Сценарій виконання представляє безліч подій, що відбуваються в міру того, як актор використовує систему для досягнення якої-небудь мети. Звичайно, в Сценарії виконання ціль досягається в результаті тривалої процедури, а не однієї дії або транзакції. Щоб присвоїти ім’я Сценарію виконання, відкрийте діалогове вікно Властивості UML для даного елемента, двічі клацнувши по значку елемента в Провіднику по моделям або по фігурі елемента на схемі. Також, до наших сценаріїв ми можемо додати Точки розширень. Точка розширень –це іменований маркер, який вказує на місце в Сценарії виконання, куди можна ввести додаткову дію. Якщо в сценарій ви додаєте Точку розширення, – значить готуєте його до можливого розширення. Для того, щоб в схему додати Точки розширень, потрібно: 1. Перетягнути фігуру Сценарій виконання на сторінку документа; 2. Двічі клацнути по фігурі Сценарій виконання та вибрати категорію Точки розширень; 3. Натиснути кнопку Створити, ввести ім'я Точки розширення та натиснути кнопку ОК; 4. Повторити пункти 1-3 для додавання інших Точок розширень. Щоб, для фігури Сценарій виконання, приховати розділ Точок розширень, клацніть по фігурі правою кнопкою миші, виберіть команду Параметри відображення фігури, а потім зніміть прапорець Точка розширення. Щоб застосувати це тільки до

8

виділеної фігури, зніміть прапорець Застосувати до розташовуваних фігур UML того ж типу на поточній сторінці вікна документа в діалоговому вікні Параметри відображення фігури. На Схемі сценаріїв виконання Актор представляє будь-яку із ролей зовнішнього об'єкта. Таким чином, один фізичний об'єкт може бути представлений декількома Акторами. Щоб присвоїти ім’я для фігури Актор відкрийте діалогове вікно Властивості UML для даного елемента, двічі клацнувши по значку елемента в Провіднику по моделям або по фігурі Актора на схемі. Для зображення зв’язків між Сценаріями виконання й Акторами використовуються фігури Повідомлень. Розглянемо докладніше зв’язки між Акторами й Сценаріями виконання. В мові UML можливий тільки один тип зв’язків між Актором і Сценарієм виконання - відношення комунікації. Оскільки інший тип відношень тут ми задати не можемо, то стереотип communіcate можна не вказувати (він неявно мається на увазі). Для сценарію “Складання комп'ютерів” немає значення який саме Актор буде з ним взаємодіяти - “Інженер із складання настільних комп'ютерів” або “Інженер із складання ноутбуків”. Тому ми ввели ще одного Актора - “Інженер із складання”, з яким зв'язали перших двох акторів відношенням узагальнення (Generalіzatіon). Відношення між “Роботою із замовленням” і “Керуванням інформацією про клієнта” – являється відношенням розширення («exdents»), оскільки, коли актор “Менеджер з роботи із клієнтами” працює із замовленням (оформляє, змінює й т.д.), то не завжди при цьому він управляє інформацією про клієнтів. Відношення між сценаріями “Складання комп'ютерів” і “Замовлення необхідних комплектуючих” – це відношення включення («uses»), оскільки для складання комп'ютерів обов'язково потрібно замовляти необхідні комплектуючі зі складу.

Рис.1. Д

іаграма прецед

ентів

9

Рис.2. Д

одаткова діагра

ма прецедентів

10

11

Лабораторна робота №2 Створення діаграми класів Мета роботи: навчитись будувати діаграми класів, створювати пакети та групувати класи в пакетах. Завдання: - вибрати один із Сценаріїв виконання (з попередньої роботи) на основі якого буде створена Діаграма класів; - створити Діаграму класів зобразивши на ній Класи та зв’язки між ними; - кожному Класу задати атрибути і операції; - детально задокументувати кожен Клас; - створити пакети та згрупувати у них Класи. Зміст звіту: - опис кожного Класа; - створена Діаграма класів; - діаграма із згрупованими у пакети Класами. Приклад виконання роботи. 1. Створення діаграми класів для сценарію "Додати нове замовлення" прецеденту "Робота із замовленням". Діаграми класів розглядатимемо з концептуальної точки зору. Створимо нову Діаграму класів і назвемо її “Add New Order”. У полі документації запишемо для неї наступний текст: "Діаграма класів для сценарію “Додати нове замовлення" прецеденту “Робота із замовленням””. Заповнення діаграми почнемо з визначення Класів та їх властивостей. Даний сценарій складається з: - замовлення; - клієнта, який робить замовлення; - комплектуючих виробів, які входять в замовлення. Створимо слідуючі Класи: “Order” (Замовлення), “Client” (Клієнт) і “ComponentPart” (Комплектуючий виріб). Оскільки в одне замовлення може входити багато різних комплектуючих виробів, і один комплектуючий виріб може входити в багато замовлень, то введемо ще один Клас “OrderItem” (Пункт замовлення). Опишемо кожен Клас.

12

Таблиця 3 Опис класів Параметр Значення Клас Client Коментар Клас, що є клієнтом фірми Атрибути name: String – найменування клієнта address: String – адреса клієнта phone: String – телефон клієнта Усі атрибути мають модифікатор доступу - private Операції AddClient() – додавання нового клієнта RemoveClient() – видалення існуючого клієнта GetInfo() – отримати інформацію про клієнта Усі операції мають модифікатор доступу - public Клас Order Коментар Клас, що є замовленням, яке робить клієнт Атрибути orderNumber: Integer – номер замовлення orderDate: Date – дата оформлення замовлення orderComplete: Date – дата виконання замовлення Усі атрибути мають модифікатор доступу – private Операції Create() – створення нового замовлення SetInfo() – занести інформацію про замовлення GetInfo() – отримати інформацію про замовлення Усі операції мають модифікатор доступу – public Клас OrderItem Коментар Клас, що є пунктом замовлення, яке робить клієнт Атрибути itemNumber: Integer – номер пункту замовлення quantity: Integer – кількість комплектуючих виробів price: Double – ціна за одиницю Усі атрибути мають модифікатор доступу – private Create() – створення нового рядка замовлення SetInfo() – занести інформацію про рядок замовлення GetInfo() – отримати інформацію про рядок замовлення Усі операції мають модифікатор доступу – public

Операції

13

продовження таблиці 3 Клас ComponentPart Коментар Клас, що є комплектуючими виробами Атрибути name: String – найменування manufacturer: String – виробник price: Double – ціна за одиницю description – опис Усі атрибути мають модифікатор доступу – private Операції

AddComponent() – додавання нового комплектуючого виробу RemoveComponent() – видалення комплектуючого виробу GetInfo() – отримати інформацію про комплектуючий виріб Усі операції мають модифікатор доступу – public Створені Класи зображені на рис.3.

Рис.3. Створені Класи Встановимо зв’язки між цими Класами (рис.4): • між Класами “Client” і “Order” – Відношення асоціації, оскільки дані Класи просто пов'язані один з одним і ніякі інші типи зв'язків тут застосувати не можна. Один клієнт може зробити декілька замовлень, кожне замовлення надходить лише від одного клієнта, тому кратність зв'язку з боку Класа “Client” – 1, з боку “Order” – 1.n; • між Класами “Order” і “OrderItem” – Відношення композиції, оскільки пункт замовлення є частиною замовлення, і без нього існувати не може. В одне замовлення може входити декілька пунктів замовлень. Пункт замовлення відноситься тільки до одного

14

замовлення, тому кратність зв'язку з боку “Order” – 1, з боку “OrderItem” – 1.*; • між Класами “OrderItem” і “ComponentPart” – Відношення агрегації, оскільки комплектуючі вироби є частинами пункту замовлення, але і ті, і інші, являються самостійними класами. Один комплектуючий виріб може входити до багатьох пунктів замовлень. В один пункт замовлення входить тільки один комплектуючий виріб, тому кратність зв'язку з боку “ComponentPart” – 1, з боку “OrderItem” – 1.n.

Рис.4. Класи та зв’язки між ними Додамо тепер Граничні та Керуючі класи (implementation class) (рис. 5). Даний сценарій – це тільки одна з дій, яку забезпечує Прецендент “Робота із замовленням”. Прецедент також дозволяє проглянути, відредагувати або видалити замовлення. Це означає, що необхідно передбачити механізм, який дозволяє вибрати необхідну дію. Створимо для цього Граничний клас “OrderOptions” (Параметри роботи із замовленням) з коментарем “Клас, що забезпечує механізм роботи із замовленнями”. Також створимо Граничний клас “AddNewOrder” (Додавання нового замовлення), з коментарем “Клас служить для додавання нових замовлень”. Цей Клас використовуватиметься для додавання нових замовлень.

15

Відношення між цими класами - агрегація, оскільки в даному випадку Клас “AddNewOrder” розглядається як частина Класа “OrderOptions”, частинами якого також будуть Класи для перегляду, редагування і видалення замовлень. Кратність зв'язку буде 1 до 1, оскільки до складу Класа “OrderOptions” входить тільки один “Клас AddNewOrder”. Перейдемо тепер до Керуючих класів. Додамо Керуючий клас “OrderManager” (Менеджер по роботі із замовленнями), з коментарем “Клас, що керує потоком подій прецеденту “Робота із замовленнями””. Цей Клас забезпечуватиме обробку потоку подій для даного Прецеденту. Він буде пов'язаний з Класами “AddNewOrder” і “Order”. Зв’язки між Класами: - “AddNewOrder” і “OrderManager” – однонапрямлена асоціація з кратністю зв'язку 1 до 1, оскільки один екземпляр Класа “AddNewOrder” взаємодіє тільки з одним екземпляром Класа “OrderManager”; - “OrderManager” і “Order” – однонапрямлена асоціація з кратністю зв'язку 1 до n, оскільки один Клас “OrderManager” може взаємодіяти з декількома Класами “Order”.

Рис.5. Кінцева діаграма класів

16

Тепер перейдемо до створення Пакетів. Пакети призначені для згрупування елементів за певними критеріями. В найпростішому випадку Класи можна групувати за їх стереотипами. Створимо три Пакети: “Entities” (класи-суті), “Boundaries” (граничні класи) і “Control” (керуючі класи).

Рис.6. Створені пакети У полі документації (Documentation) для кожного Пакету задамо коментар: • для “Entities” – “Пакет містить класи-суті”; • для “Boundaries” – “Пакет містить граничні класи”; • для “Control” – “Пакет містить керуючі Класи”. Після створення Пакетів, Класи необхідно згрупувати. Групування Класів в Пакети здійснюється шляхом копіювання та вставляння їх у схему відповідного Пакету. Для зручності можна користуватися Провідником по моделям. Групувати створені Класи будемо таким чином: • Класи Client, Order, OrderItem і ComponentPart перенесемо в Пакет Entities; • Класи OrderOptions і AddNewOrder перенесемо в Пакет Boundary; • Клас OrderManager перенесемо в Пакет Control.

17

Лабораторна робота №3 Створення діаграми послідовностей Мета роботи: отримати навички побудови діаграм послідовностей. Завдання: Створити Діаграму послідовностей для одного з сценаріїв будь-якого прецеденту, створеного в лабораторній роботі № 1 Зміст звіту: створена Діаграма послідовностей. Приклад виконання роботи. Побудова Діаграми послідовностей починається з розміщення на ній об'єктів, які обмінюватимуться повідомленнями. Спочатку необхідно розмістити об'єкти, які посилають повідомлення, а потім об'єкти, що їх отримують. Ініціатором взаємодії виступає Актор “Менеджер з роботи із клієнтами”. Тому на діаграмі він буде знаходиться в лівому кутку. Далі розміщуємо об’єкти: - Клас “OrderOptions” (Параметри роботи із замовленням), що відповідає за вибір можливої дії із замовленням в даному прецеденті; - Клас “AddNewOrder” (Додавання нового замовлення), що відповідає за додавання замовлення; - Клас “OrderManager” (Менеджер з роботи із замовленнями), що відповідає за обробку потоку подій даного прецеденту; - Клас “Order” (Замовлення); - Клас “Client” (Клієнт); - Клас “ComponentPart” (Комплектуючий виріб). Тепер на діаграмі слід вказати повідомлення, якими обмінюватимуться об'єкти (рис. 7): Таблиця 4 Опис повідомлень Номер повідом-лення Об'єкт - відправник повідомлення Об'єкт - одержувач повідомлення Назва 1 Менеджер з роботи із клієнтами OrderOptions введення пароля

18

продовження таблиці 4 2 OrderOptions OrderOptions перевірка пароля 3 Менеджер з роботи із клієнтами OrderOptions вибір операції "додати" 4 OrderOptions AddNewOrder відображення полів введення 5 Менеджер з роботи із клієнтами AddNewOrder вибір типу комп'ютера 6 AddNewOrder OrderManager отримання списку клієнтів 7 OrderManager Client отримання списку клієнтів 8 Client AddNewOrder список клієнтів 9 AddNewOrder AddNewOrder відображення списку клієнтів 10 Менеджер з роботи із клієнтами AddNewOrder вибір клієнта 11 AddNewOrder OrderManager отримання списку комплектуючих 12 OrderManager ComponentPart отримання списку комплектуючих 13 ComponentPart AddNewOrder список комплектуючих 14 AddNewOrder AddNewOrder відображення списку комплектуючих 15 Менеджер з роботи із клієнтами AddNewOrder вибір необхідних комплектуючих 16 Менеджер з роботи із клієнтами AddNewOrder зберегти замовлення 17 AddNewOrder OrderManager передача управління 18 OrderManager Order зберегти

19

Рис. 7. Кінцева

діаграма послід

овностей

20

Лабораторна робота №4 Створення діаграми взаємодій Мета роботи: отримати навички побудови Діаграм взаємодій. Завдання: Створити Діаграму взаємодій для одного з сценаріїв будь-якого прецеденту, створеного в лабораторній роботі № 1. Зміст звіту: створена Діаграма взаємодій. Приклад виконання роботи. У меню Файл виберіть Створити=>Програмне забезпечення=> Схема моделі UML. У Провіднику по моделям клацніть правою кнопкою мишки по Пакету в який необхідно включити Схему взаємодій, виберіть Створити=> Схема взаємодій. Буде відкрита порожня сторінка, а набір елементів Взаємодії UML переміститься вверх. В Провіднику за моделями з’явиться значок, що відповідає схемі. Для кожної ролі об'єкта, яку необхідно показати у Діаграмі взаємодій, перетягніть фігуру Роль класифікатора на сторінку документа. В схемі взаємодій клацніть правою кнопкою миші по фігурі Роль класифікатора для об'єкта, який необхідно позначити як новий, знищений або тимчасовий, а потім виберіть команду Параметри відображення фігури. В полі Стан Ролі класифікатора виберіть необхідну умову. Умова відображається у фігурних дужках після імені об'єкта (наприклад, "Об'єкт1{проміжний}"). Щоб вказати, що Клас активний, двічі клацніть по фігурі або відповідному значку в Провіднику по моделям. У діалоговому вікні Властивості класа UML виберіть Клас, потім встановить прапорець ІsActіve і натисніть кнопку ОК. Роль класифікатора стане активною. Для відображення декількох фігур, перетягніть фігуру Кілька об'єктів на сторінку документу. Двічі клацніть по кожній із фігур Роль класифікатора або по фігурі Кілька об'єктів, щоб відкрити діалогове вікно Властивості ролі класифікатора UML, у якому можна ввести ім'я й значення інших властивостей.

21

Вкажіть зв'язок між об'єктами, з'єднавши їх за допомогою фігури Роль асоціації. Перетягніть фігуру Роль асоціації на місце поруч із фігурами Роль класифікатора або Кілька об'єктів, між якими необхідно створити зв’язок. Перетягніть кінці фігури Роль асоціації на межу фігури Роль класифікатора. Двічі клацніть по фігурі Роль асоціації, щоб відкрити діалогове вікно Властивості ролі асоціації UML. В цьому вікні можна додати ім'я, потік, мітку повідомлення, множинність і значення інших властивостей. Введіть ім'я Ролі асоціації й натисніть кнопку Повідомлення, потім клацніть Створити. Введіть ім'я й вираз. Виберіть необхідний стереотип, напрямок і різновид потоку. Для звичайного повідомлення або виклику процедури, відкрийте вікно Властивості. Виберіть операцію, котра повинна створити повідомлення. Якщо ця операція не існує, натисніть кнопку Створити. Для створення Асинхронного повідомлення виберіть сигнал, який повинен його створити. Якщо сигналу не існує, натисніть кнопку Створити, щоб створити сигнал. У фігурі Роль класифікатора, рядок підкреслений для вказівки на те, що даний об'єкт є конкретним екземпляром. Перед двокрапкою можна додати ім'я об'єкта. Фігури Зв'язків, або Ролі асоціацій, показують залежності між асоціаціями, а наявність наконечника, вказує на можливість навігації. Двічі клацнувши по зв'язку і вибравши команду Повідомлення, можна визначити повідомлення, яке передається по цьому зв'язку. Пронумеруйте Повідомлення процедур відповідно до послідовності викликів. Перше Повідомлення завжди приходить ззовні контексту, включеного в дану схему. Приклад діаграми наведено на рис.8.

22

Рис. 8. Діаграма взаємодії Лабораторна робота № 5 Створення діаграми станів Мета роботи: отримати навички побудови Діаграм станів. Завдання: розробити Діаграму станів для одного з раніше розроблених Класів або Прецедентів. Зміст звіту: Діаграма станів й опис станів у вигляді таблиці: Стан Опис стану Приклад виконання роботи. Діаграми станів використовуються для моделювання поводження класів, прецедентів або системи в цілому. Діаграма станів показує, як об'єкт переходить із одного стану в інший. Очевидно, що діаграми станів служать для моделювання динамічних аспектів системи. Від інших діаграм Діаграма станів відрізняється тим, що описує процес зміни станів тільки одного екземпляра певного Класа –

23

одного об'єкта, поводження якого характеризується його реакцією на зовнішні події. Складемо діаграму станів для Класа “Order” (Замовлення), оскільки в нашій моделі він найбільше часто буде міняти свій стан. Замовлення може перебувати в декількох станах: • при створенні замовлення воно переходить у стан Ініціалізація, у якому виконуються деякі попередні дії; • після завершення ініціалізації замовлення переходить у стан Відкрите, у якому до замовлення додаються нові пункти. Вихід із цього стану можливий або у випадку скасування замовлення, або у випадку заповнення всіх необхідних пунктів замовлення; • якщо заповнені всі необхідні пункти замовлення, то воно переходить у стан Закрите, у якому відбувається виписка рахунку. Вихід із цього стану відбудеться тільки після того, як рахунок буде виписаний; • якщо замовлення відмінене, то зі стану Відкрите воно переходить у стан Відмінене. При виході із цього стану відбувається видалення всіх пунктів замовлення. Діаграма станів для класа “Order”, представлена на рис.9. Розглянемо список умовних позначень та фігур, притаманних даній діаграмі. Першим станом на діаграмі станів є Початковий стан. При виконанні події “Замовлення створене” замовлення переходить у стан “Ініціалізація”. При вході в цей стан виконується вхідна дія “Зберегти дату замовлення”. Основна дія, що буде виконуватися під час всього часу, поки замовлення буде перебуває в цьому стані, це “Внести інформацію про клієнта”. Перехід із цього стану в стан “Відкритий” відбудеться тільки при виконанні умови “Ініціалізація завершена”. В стані “Відкритий” є вихідна дія й перехід на самого себе (Рекурсивний перехід). Рекурсивний перехід означає, що подія ініціює перехід, відбувається вихід з поточного стану, виконується деяка дія, після чого відбувається повернення у вихідний стан. Оскільки при Рекурсивному переході відбувається вихід зі стану й повторний вхід у нього, то виконується дія, асоційована з переходом, і, крім того, дія при вході в стан.

24

Рис. 9. Діаграма станів для класа Order В стані “Відкрите” до замовлення додаються нові пункти, причому їх можна додати тільки в тому випадку, якщо є незаповнені пункти. Для відображення цього процесу, ми використали Рекурсивний перехід “Додавання пункту замовлення” з умовою “Заповнені не всі пункти замовлення”. Вихід із цього стану відбудеться в двох випадках – або коли виконається гранична умова “Заповнені всі позиції замовлення" (при цьому замовлення перейде в стан Закритий), або коли наступить подія “Замовлення відмінне” (при цьому замовлення перейде в стан “Відмінене”). При виході зі стану виконується дія виходу “* Orderіtem.Create()” (створення пункту замовлення). Символ “*” вказує на те, що ця дія виконується багато разів (залежно від кількості доданих в замовлення пунктів). В стані “Закритий” є присутнім тільки внутрішня дія – “Виписати рахунок”. В цей стан замовлення переходить зі стану “Відкритий” тільки при виконанні сторожової умови “Заповнені всі позиції замовлення”. Вихід із цього стану й перехід у кінцеве відбудеться при настанні події “Рахунок виписаний”.

25

В стан “Відмінене”, замовлення переходить зі стану “Відкритий”: при настанні події “Замовлення відмінене”. При виході з нього виконується дія виходу “Зберегти дату скасування”. При переході із цього стану в кінцеве виконується дія “Видалення замовлення”. Тут також є “*”, оскільки ця дія буде виконуватися багато разів. Лабораторна робота №6 Створення діаграм діяльності Мета роботи: отримати навички побудови Діаграм діяльності. Завдання: 1. Cтворити Діаграму діяльності, що описує один з бізнес-процесів обраної предметної області; 2. Створити Діаграму діяльності, що описує потік подій одного з варіантів використання, створеного в лабораторній роботі № 1. Зміст звіту: створені Діаграми діяльності з вказівкою того, який процес і потік подій якого варіанту використання вони описують. Приклад виконання роботи. Створимо Діаграму діяльності для опису бізнес-процесу, підприємства із складання комп'ютерів. Розглянемо в цілому, що відбувається на підприємстві від моменту оформлення замовлення до видачі готового комп'ютера. Після оформлення замовлення “Менеджер з роботи із клієнтами” передає його “Менеджерові із складання”, який спершу замовляє необхідні комплектуючі зі складу. На складі завідувач підбирає необхідні комплектуючі (у випадку їхньої відсутності замовляє їх у “Менеджера з постачання”) і передає їхньому “Інженерові із складання”. Після отримання комплектуючих “Менеджер із складання” здійснює складання комп'ютера й передає його “Інженерові з тестування”. Якщо комп'ютер не пройшов тестування, він повертається для повторного складання. При успішному завершенні тестування, комп'ютер передається на склад на зберігання. Зі складу, комп'ютер за запитом передається “Менеджерові з роботи із клієнтами”, який оформляє на нього документи й видає клієнтові. При створенні Діаграм діяльності, слід керуватися наступним порядком дій:

26

1. Перетягніть доріжки для визначення дій окремих Акторів зі схеми прецедентів. 2. Задайте їм імена, двічі клацнувши по них: - “Менеджер з роботи із клієнтами”; - “Інженер із складання”; - “Завскладом”; - “Інженер з тестування”. 3. Перетягніть Початковий стан об’єкта. 4. Перетягніть Стан дії для кожного Актора та підпишіть його згідно діаграми прецедентів. 5. За допомогою стрілок управління відобразіть процеси між станами окремих акторів. 6. Перетягнути фігуру кінцевого стану для завершення технологічного ланцюжка робіт із складання комп’ютерів. Примітка: між діями “тестування” та “передача комп'ютера на склад” потрібно вказати умову – „комп’ютер пройшов тестування ”. Для цього слід двічі клацнути мишкою по стрілці та в категорії „перехід” поставити галочку поруч з „умовою” та набрати з клавіатури вище згадану умову. Побудована діаграма показана на рис. 10.

Рис. 10. Діаграма діяльності

27

Тепер, створимо Діаграму діяльності для варіанта використання "Робота із замовленням". Потік подій сценарію виконання "Робота із замовленням" складається з головного потоку, підпотоків й альтернативних потоків. Щоб не захаращувати діаграму покажемо потік подій на декількох діаграмах діяльності. На першій з них (умовно назвемо її головною) покажемо дії для основного потоку й пов'язаний з ним альтернативний потік (рис. 11). Підпотоки можна буде показати шляхом декомпозиції відповідної дії головної діаграми.

Рис. 11. Діаграма діяльності для потоку подій сценарію “Робота із замовленням”

28

На рис. 12. Показана діаграма діяльності для підпотоку "Додати замовлення", що є декомпозицією дії "Додати замовлення" головної діаграми діяльності.

Рис. 12. Діаграма діяльності для сценарію “Додати замовлення”

29

Варіанти завдань 1. Розробити проект використання пульта дистанційного керування телевізором. 2. Розробити проект використання пульта дистанційного керування DVD-програвачем. 3. Розробити проект використання телефону. 4. Розробити проект використання холодильника. 5. Розробити проект роботи підіймального ліфта. 6. Розробити проект підтримки системи сигналізації. 7. Розробити проект роботи турнікета метрополітену. 8. Розробити проект роботи автомата з продажу цукерок. 9. Розробити проект використання дитячою іграшкою. 10. Розробити проект системи продажу залізничних квитків. 11. Розробити проект системи керування супутником. 12. Розробити проект використання кухонного комбайну. 13. Розробити проект роботи бортового комп’ютера автомобіля. 14. Розробити проект роботи автопілота літака. 15. Розробити проект роботи бібліотеки. 16. Розробити проект використання аудіоцентру. 17. Розробити проект використання автомобіля. 18. Скласти систему класифікації геометричних фігур. 19. Скласти систему класифікації тварин. 20. Скласти систему класифікації рослин. 21. Скласти модель взаємодії комп’ютера з периферійними пристроями (комп’ютер подати як складний пристрій). 22. Скласти модель котеджу та “взаємодії” з ним людини. 23. Змоделювати роботу комп’ютерного класу. 24. Змоделювати роботу магазину з продажу запчастин. 25. Змоделювати процес встановлення програмного забезпечення. 26. Скласти модель аеропорт — допоміжні технічні засоби — літаки — обслуговуючий персонал. 27. Змоделювати структуру та функціонування метрополітену. 28. Змоделювати роботу факсимільного апарату. 29. Змоделювати роботу космічного апарату. 30. Змоделювати роботу пошти.

30

Список літератури 1. Арлоу Д. UML 2 и Унифицированный процесс. Практический объектно_ориентированный анализ и проектирование, 2-е издание/Д.Арлоу, И.Нейштадт.–Пер. с англ.–СПб: Символ-Плюс, 2007.–624 с. 2. Rumbaugh J. Modeling Language Reference Manual/J.Rumbaugh, I.Jacobson, G.Booch.–MA.: Addison-Wesley Publishing Co., 1999. – 576 с. 3. Буч Г. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++/Г.Буч.-Пер с анг.–СПб: “Издательство Бином”, “Невский диалект”, 1998.–560 с. 4. Буч Г. Язык UML: Руководство пользователя/Г.Буч, Дж.Рамбо, А.Якобсон.–М.: ДМК, 2000. – 356 с. 5. Київський освітній портал [Електронний ресурс].-режим доступу: http:// www.edu.kiev.ua. 6. Рамбо Д. Тенденции в развитии языка UML и разработки ПО [Електронний ресурс]/Д.Рамбо. –режим доступу: http://www.interface.ru/fset.asp?Url=/rational/umltend.htm. 7. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения/ А.Якобсон., Г.Буч, Дж.Рамбо. – СПб.: Питер, 2002. – 498 с.