МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ ТРАНСПОРТНИЙ УНІВЕРСИТЕТ
Факультет транспортних та інформаційних технологій
Кафедра інформаційних систем і технологій
Звіт з лабораторних робіт
з дисципліни
«Case-технології»
1. Опис використання банкомату за допомогою діаграми прецедентів
Основне завдання діаграм прецедентів полягає в тому, щоб розробник і користувач змогли знайти спільну мову без застосування спеціальних термінів.
Перш ніж будувати діаграму прецедентів визначаються:
• актори;
• прецеденти;
• вимоги прецеденту.
Вимоги можна оформити в таблицю. У лівій її частині вказуються варіанти використання системи, а в правій особи (необов'язково люди), які беруть участь в прецеденті.
Таблиця. 1 Актори та відповідні прецеденти
Прецедент
Актор
Вставити карту
Користувач
Відображення інформації про карту
Інтерфейс Банкомату
Запит Pin-коду
Інтерфейс Банкомату
Введення Pin-коду
Користувач
Перевірка Pin-коду
Інтерфейс Банкомату
Відображення меню
Інтерфейс Банкомату
Зняти гроші
Користувач
Пропозиція ввести потрібну суму
Інтерфейс Банкомату
Запит в банк про стан рахунку
Інтерфейс Банкомату
Ввести потрібну суму
Користувач
Виведення інформації про стан рахунку
Інтерфейс Банкомату
Отримати готівку і чек
Користувач
Перевірити баланс
Користувач
Пропозиція забрати карту
Інтерфейс Банкомату
Взяти карту
Користувач
На основі цієї таблиці побудуємо діаграму прецедентів.
Рис.1 Діаграма прецедентів
За допомогою діаграми прецедентів показується загальне уявлення процесу, і визначаються дії осіб, які взаємодіють в системі.
2. Опис процесу діяльності
Кожен варіант використання повинен мати пов'язаний з ним короткий опис того, що він робитиме. Опис має визначати типи задіяних користувачів та очікуваний ними результат.
Основний і альтернативний потоки подій. Конкретні деталі варіантів використання описуються в основному і альтернативних потоках подій. Потік подій поетапно описує, що має відбуватися під час виконання закладеної в варіанти використання функціональності. Потік подій звертає увагу на те, що буде робити система, а не як вона буде робити це, причому описує все це з точки зору користувача. Основний і альтернативний потоки подій включають таке опис:
• яким чином запускається варіант використання;
• різні шляхи виконання варіанта використання;
• нормальний, або основний, потік подій варіанту використання;
• відхилення від основного потоку подій (так звані альтернативні потоки);
• потоки помилок;
• яким чином завершується варіант використання.
Потік подій варіанту використання «Зняти гроші з рахунку»:
Основний потік
1. Варіант використання починається, коли клієнт вставляє свою картку в банкомат.
2. Банкомат виводить вітання і пропонує клієнту ввести свій персональний PIN-код.
3. Клієнт вводить PIN-код.
4. Банкомат підтверджує введений код. Якщо код не підтверджений, виконується альтернативний потік подій А1.
5. Банкомат виводить список доступних дій:
• зробити вклад;
• зняти гроші з рахунку;
• перевести гроші.
6. Клієнт вибирає пункт «Зняти гроші з рахунку».
7. Банкомат запитує, скільки грошей треба зняти.
8. Клієнт вводить необхідну суму.
9. Банкомат визначає, чи є на рахунку достатньо грошей. Якщо грошей недостатньо, виконується альтернативний потік А2. Якщо під час підтвердження суми виникають помилки, виконується потік помилок Е1.
10. Банкомат віднімає необхідну суму з рахунку клієнта.
11. Банкомат видає клієнтові необхідну суму готівкою.
12. Банкомат повертає клієнту його картку.
13. Банкомат друкує чек для клієнта.
14. Варіант використання завершується.
коду
Альтернативний потік А1. Введення неправильного PIN-коду
1. Банкомат інформує клієнта, що код введено неправильно. Якщо пін-код введено не правильно більше трьох разів,виконується альтернативний потік А3.
2. Банкомат повертає клієнту його картку.
3. Варіант використання завершується.
Альтернативний варіант використання А2. Недостатньо грошей на рахунку
1. Банкомат інформує клієнта, що грошей на його рахунку недостатньо.
2. Банкомат повертає клієнту його картку.
3. Варіант використання завершується.
Альтернативний варіант використання А3. Введення неправильного PIN-коду більше трьох разів.
1. Банкомат інформує клієнта, що код введено неправильно більше трьох разів.
2. Банкомат забирає картку.
3. Варіант використання завершується.
Потік помилок El. Помилка в підтвердженні запитуваної суми
1. Банкомат повідомляє користувачеві, що при підтвердженні запитуваної суми сталася помилка, і дає йому номер телефону служби підтримки клієнтів банку,
2. Банкомат заносить відомості про помилку в журнал помилок. Кожен запис містить дату і час помилки, ім'я клієнта, номер його рахунку і код помилки.
3. Банкомат повертає клієнту його картку.
4. Варіант використання завершується.
Рис. 2. Діаграма діяльності
3. Побудова діаграми послідовності
Якщо в діаграмі діяльності переважно відображається процес за участю різних категорій користувачів системи, то діаграма послідовності більше підходить для відображення «внутрішньо машинного» процесу за участю класів програми або пристроїв.
Таблиця 5.1. Класи, задіяні на діаграмі послідовності
Клас
Відповідальність
Клієнт
Введення карти, паролю. Здійснення банківських операцій.
Система управління банкоматом
Виконує аутентифікацію карти користувача і дозволяє чи забороняє здійснювати банківські операції.
Екран
Візуалізує роботу з банкоматом. Дозволяючи користувачу переглядати баланс рахунку, отримати допомогу тех.підтирмки, здійснювати операції.
Рахунок
Збегігає та надає дані про кошти.
Приймач карти
Обслугвує клієнта. Приймає та повертає або забирає карту клієнта.
Прилад видачі готівки
Видача готівки.
Рис. 3. Діаграма послідовності для процесу «Зняття готівки (основний потік)»
Діаграма класів визначає типи класів системи і різного роду статичні зв'язки, які існують між ними. На діаграмах класів зображуються також атрибути класів, операції класів та обмеження, які накладаються на зв'язку між класами.
Рис.4 Діаграма класів для варіанту використання «Зняти гроші з рахунку»
Діаграма кооперації призначена для специфікації структурних аспектів взаємодії. Головна особливість діаграми кооперації полягає в можливості графічно представити не тільки послідовність взаємодії, але і всі структурні відносини між об'єктами, які беруть участь у цій взаємодії.Насамперед, на діаграмі кооперації у вигляді прямокутників зображуються беруть участь у взаємодії об'єкти, що містять ім'я об'єкта, його клас і, можливо, значення атрибутів. Далі, як і на діаграмі класів, вказуються асоціацію між об'єктами у вигляді різних сполучних ліній. При цьому можна явно вказати імена асоціації і ролей, які грають об'єкти в даній асоціації. Додатково можуть бути зображені динамічні зв'язки - потоки повідомлень. Вони представляються також у вигляді з'єднувальних ліній між об'єктами, над якими розташовується стрілка з вказівкою напрямку, імені повідомлення і порядкового номера в загальній послідовності ініціалізації повідомлень.
На відміну від діаграми послідовності, на діаграмі кооперації зображаються тільки відносини між об'єктами, що грають певні ролі у взаємодії. З іншого боку, на цій діаграмі не вказується час у вигляді окремого вимірювання. Тому послідовність взаємодій і паралельних потоків може бути визначена за допомогою порядкових номерів. Отже, якщо необхідно явно специфікувати взаємозв'язку між об'єктами в реальному часі, краще це робити на діаграмі послідовності.
Поведінка системи може описуватися на рівні окремих об'єктів, які обмінюються між собою повідомленнями, щоб досягти потрібної мети або реалізувати деякий сервіс. З точки зору аналітика або конструктора важливо представити в проекті системи структурні зв'язки окремих об'єктів між собою. Така статична уявлення структури системи як сукупності взаємодіючих об'єктів і забезпечує діаграма кооперації.
Таким чином, за допомогою діаграми кооперації можна описати повний контекст взаємодій як своєрідний тимчасової «зрізу» сукупності об'єктів, що взаємодіють між собою для виконання певного завдання або бізнес-цілі програмної системи.
Рис.5 Діаграма кооперації
Діаграма компонент — в UML, діаграма, на якій відображаються компоненти, залежності та зв'язки між ними.
Діаграма компонент відображає залежності між компонентами програмного забезпечення, включаючи компоненти вихідних кодів, бінарні компоненти, та компоненти, що можуть виконуватись. Модуль програмного забезпечення може бути представлено як компоненту. Деякі компоненти існують під час компіляції, деякі — під час компонування, а деякі під час роботи програми.
Діаграма компонент відображає лише структурні характеристики, для відображення окремих екземплярів компонент слід використовувати діаграму розгортування.
Рис.6 Діаграма компонентів
Рис.7 Діаграма станів
IDEF - методології сімейства ICAM (Integrated Computer-Aided Manufacturing) для вирішення завдань моделювання складних систем, дозволяє відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.
IDEF0 - методологія функціонального моделювання (англ. Function modeling) і графічна нотація, призначена для формалізації і опису бізнес-процесів. Відмінною особливістю IDEF0 є її акцент на підпорядкованість об'єктів. В IDEF0 розглядаються логічні відносини між роботами, а не їх тимчасова послідовність (потік робіт).
Рис.8 Контекстна діаграмма. IDEF0
Деталізація обслуговування клієнта.
Рис.9 IDEF 1-го рівня - деталізація процесу
Рис.10 IDEF 2-го рівня Діаграма потоків даних, що деталізує процес видачі грошей»