Вимоги до структури системи 3 страница
11.6. Зберегти створену модель, для чого вибрати пункт меню Save (File ® Save) і ввести ім'я файлу « dlvr_idef3 ».
11.7. В результаті у вікні «Model Explorer» можна буде побачити вихідну модель і моделі, що з'явилися в результаті розщіплення, рис. 2.1.
11.8. Вихідні з робіт «Формування замовлення на поставку» і «Узгодження з постачальником термінів і форми оплати» граничні стрілки, що з'явилися в результаті декомпозиції, можна видалити.
11.9. Закрити створені в результаті розщеплення моделі.
12. Декомпозувати роботу «Формування замовлення на поставку».
Рис. 2.1. Результат розщеплення моделі.
12.1. Вибрати роботу «Формування замовлення на поставку» і клацнути мишею по кнопці «Go to Child Diagram» в панелі інструментів
12.2. У вікні «Activity Box Count» встановити кількість робіт в діаграмі декомпозиції рівне 7.
12.3. Для робіт на діаграмі ввести такі назви: «Визначення номенклатури продукції, що замовляється», « Визначення списку постачальників», «Аналіз прайс-листів», «Аналіз термінів поставки», «Вибір постачальника», «Відправлення даних замовлення», «Отримання підтвердження замовлення».
12.4. Граничну стрілку «Дані про наявність продукції на складі» перейменувати в «Замовлення на поставку» і пов'язати з роботою «Отримання підтвердження замовлення». Пов'язати з роботами інші граничні стрілки.
12.5. Вставити на діаграму внутрішні стрілки.
13. Декомпозувати роботу «Узгодження з постачальником термінів і форми оплати».
13.1. В роботі «Узгодження з постачальником термінів і форми оплати» клацнути мишею по кнопці «Go to Child Diagram» в панелі інструментів.
13.2. У вікні «Activity Box Count» встановити кількість робіт в діаграмі декомпозиції рівне 5.
13.3. Для робіт на діаграмі ввести такі назви: «Узгодження строків поставки», «Узгодження форми оплати», «Узгодження термінів оплати», «Укладення договору на поставку», «Оплата поставки або видача гарантійного документа».
13.4. Додати на діаграму стрілки.
14. Сформувати діаграму дерева вузлів.
14.1. Для створення діаграми дерева вузлів потрібно вибрати в меню пункт «Diagram» і в вертикальному меню вибрати пункт «Add Node Tree ...», отримати вікно «Node Tree Wizard».
14.2. Натиснути кнопку «Готово», в результаті чого на екран буде виведена діаграма, зовнішній вигляд якої наведено на ріс.2.2, зберегти створену модель.
Рис. 2.2. Кінцева діаграма
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Провести проектування бізнес-процесів відповідно до пропонованого списку або узгодити вибір бізнес-процесів з викладачем.
1. Продаж авіаквітків.
2. Покупка обладнання.
3. Закупка медичних препаратів.
4. Функціонування платіжної системи.
5. Закупка науково-технічної літератури.
6. Оказання авіаційних послуг.
7. Здійснення транспортних перевезень.
8. Надання ремонтних послуг.
9. Підготовка фахівців.
10. Діяльність складу.
11. Організація аудіторської діяльності.
Запитання для самоперевірки
1. Що таке Сase-засоби? Які Сase-засоби Вам відомі?
2. Що таке бізнес-процес?
3. Якими Сase-засобами відбувається моделювання бізнес-процесів?
4. Охарактеризувати можливості BPwin по моделюванню бізнес-процесів.
5. Як на діаграмі IDEF0 позначаються роботи, зв’язки?
6. Назвати основні типи зв’язків на контексній діаграмі.
7. Як позначається на контексній діаграмі тунелювання?
Лабораторна робота 2.2
ПОБУДОВА МОДЕЛЕЙ ОПИСУ ПРОЦЕСІВ ПРИ СТРУКТУРНОМУ ПІДХОДІ МОДЕЛЮВАННЯ
Мета: ознайомитись з технологією побудови опису процесів IDEF3.
Завдання: створити діаграму в нотації IDEF3 обраного бізнес-процесу.
Основні теоретичні відомості
IDEF3 (Integrated DEFinition for Process Description Capture Method) - методологія моделювання та стандарт документування процесу, який показує причинно-наслідкові зв'язки між ситуаціями і подіями в зрозумілій експерту формі, використовуючи структурний метод вираження знань про те, як функціонує система, процес або підприємство. Система описується як упорядкована послідовність подій з одночасним описом об'єктів, що мають відношення до процесу, що моделюється.
IDEF3 складається з двох методів опису: технологічних процесів Process Flow Description (PFD) і переходів станів об'єктів Object State Transition Description (OSTD).
Основу методології IDEF3 становить графічна мова опису процесів. Модель в нотації IDEF3 може містити два типи діаграм:
• діаграму «Описи послідовності етапів процесу» (Process flow description diagrams, PFDD);
• діаграму «Мережі трансформації стану об'єктів» (Object state transition network, OSTN).
Діаграма IDEF3 типом Process Flow Description включає 7 основних описових блоків: роботи (boxes, activities); стрілки або зв'язки (arrows, links); перехрестя (junctions); об'єкти посилань; unit of behavior; decomposition; elaboration.
Порядок виконання роботи
1. Ознайомитися з літературою [1, 2, 12].
2. Відкрити модель, створену в результаті розщеплення вихідної моделі і збережену в файлі «dlvr_idef3.bp1».
3. Виконати декомпозицію моделі, вказавши при цьому тип моделі - IDEF3 і кількість робіт в діаграмі - 5.
4. Формування діаграми
4.1. Для робіт на діаграмі ввести такі назви: «Узгодження строків поставки», «Узгодження форми оплати», «Узгодження термінів оплати», «Укладення договору на поставку», «Повна оплата поставки».
4.2. Додати дві нові роботи - «Часткова оплата поставки» та «Видача гарантійного документа про наступної оплати». Для додавання нової роботи клацнути мишею по кнопці «Activity Box Tool», а потім клацнути по тому місцю діаграми, де потрібно розмістити нову роботу.
4.3. Створити на діаграмі перехрестя клацнувши мишею по кнопці «Junction Tool», а потім клацнути по тому місцю діаграми, де потрібна розмістити перехрестя. Типи перехресть та їх розміщення на діаграмі показані на рис.2.3. Вибрати тип перехрестя з таких міркувань:
• чи узгоджені форма оплати і терміни оплати;
• оплата поставки проводиться тільки після завершення договору.
Рис. 2.3. Розміщення робіт на діаграмі.
4.4. Розмістити на діаграмі внутрішні і граничні стрілки,.
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Провести проектування бізнес-процесів відповідно до списку пропонованого в лабораторній роботі 3 або узгодити вибір бізнес-процесів з викладачем.
Запитання для самоперевірки
1. Що таке діаграма та які види діаграм використовуються в нотації IDEF3?
2. В чому заключається основна ідея функціонального аналізу бізнес процесів?
3. З яких будівельних блоків складається діаграма в нотації IDEF3?
4. Які генерації звітів моделі в нотації IDEF3 існують?
5. Який зміст счеплення та розчеплення моделів?
6. В чому полягає різниця між нотаціями IDEF0 та IDEF3?
7. В чому полягає різниця між функціональною і обєктною методиками?
Лабораторна робота 2.3
ПОБУДОВА МОДЕЛЕЙ ПОТОКІВ ДАНИХ
Мета: ознайомитись з технологією DFD.
Завдання: побудувати діаграму потоків даних для обраної інформаційної системи.
Основні теоретичні відомості
Діаграми потоків даних (Data Flow Diagramming) є основним засобом моделювання функціональних вимог до проектованої системи. Вимоги представляються у вигляді ієрархії процесів, пов'язаних потоками даних. Діаграми потоків даних показують, як кожен процес перетворить свої вхідні дані у вихідні, і виявляють відносини між цими процесами. DFD-діаграми успішно використовуються як доповнення до моделі IDEF0 для опису документообігу та обробки інформації. Подібно IDEF0, DFD представляє модельовану систему як мережу зв'язаних робіт. Основні компоненти DFD – процеси або роботи, зовнішні сутності, потоки даних, накопичувачі даних (сховища).
У BPwin для побудови діаграм потоків даних використовується нотація Гейна-Сарсона. Діаграма DFD розглядає систему як сукупність предметів. Стрілки на DFD показують, як об'єкти (включаючи дані) рухаються від однієї роботи до іншої. Потоки робіт зображуються стрілками і описують рух об'єктів з однієї частини системи в іншу. Оскільки в DFD кожна сторона роботи не має чіткого призначення, як в IDEF0, стрілки можуть підходити і виходити з будь-якої грані прямокутника роботи. У DFD також застосовуються двонаправлені стрілки для опису діалогів типу "команда-відповідь" між роботами, між роботою і зовнішньої сутністю і між зовнішніми сутностями.
У матеріальних системах сховища даних зображуються там, де об'єкти очікують обробки, наприклад в черзі. У системах обробки інформації сховища даних є механізмом, який дозволяє зберегти дані для подальших процесів.
У DFD стрілки можуть зливатися і розгалужуватися, що дозволяє описати декомпозицію стрілок. Кожен новий сегмент такої стрілки може мати власне ім'я.
У DFD номер кожної роботи може включати префікс A, номер батьківської роботи і номер об'єкта. Номер об'єкта - це унікальний номер роботи на діаграмі. Наприклад, робота може мати номер А.12.4. Унікальний номер мають сховища даних і зовнішні сутності незалежно від їх розташування на діаграмі. Кожне сховище даних має префікс D і унікальний номер, наприклад D5. Кожна зовнішня сутність має префікс Е і унікальний номер, наприклад Е5.
Порядок виконання роботи
1. Ознайомитися з літературою [1, 2, 12].
2. Відкрити модель, створену в результаті розщеплення вихідної моделі і збережену в файлі «dlvr_dfd3.bp1».
3. Виконати декомпозицію моделі, вказавши при цьому тип моделі – DFD і кількість робіт в декомпозіровано діаграмі - 7.
4. Зформувати діаграму (рис. 2.4).
Рис. 2.4. Поєднання робіт на діаграммі графічними стрілками.
4.1. Видалити з діаграми всі граничні стрілки.
4.2. На діаграмі ввести такі назви робіт: «Визначення номенклатури продукції, що замовляється», «Визначення списку постачальників», «Аналіз прайс-листів», «Аналіз строків поставки», «Вибір постачальника», «Відправлення даних замовлення», «Отримання підтвердження замовлення».
4.3. Внести на діаграму зовнішнє посилання «Замовлення клієнтів» шляхом виклику «Зовнішнє завдання Інструмент» з панелі інструментів, а потім клацнути по тому місцю діаграми, де потрібна розмістити зовнішнє посилання.
4.4. Розмістити на діаграмі сховища даних. Для цього клацнути мишею по кнопці «магазин даних інструментів» на панелі інструментів та місці діаграми, де буде розміщено сховище даних. Створити сховища даних з назвами «Продукція», «Постачальники», «Замовлення клієнтів», «Стан ринку», «Стан складу», «Реалізація продукції».
4.5. Створити внутрішні стрілки і зв'язати їх на діаграмі. За необхідністю створити двонаправлені стрілки. Для цього в меню вибрати пункт «Стиль» і у вікні «Стрілка Властивості», у розділі «Тип» встановити перемикач в положення «двобічна» і зберегти діаграму.
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Побудувати діаграму потоків даних для бізнес-процесів відповідно до списку пропонованого в лабораторній роботі 3 або узгодити їх вибір з викладачем.
Запитання для самоперевірки
1. В чому заключається відмінність діаграм IDEF0 і DFD?
2. Назвати основні компоненти діаграми DFD.
3. В яких випадках доцільно будувати діаграму DFD.
4. В чому відмінність побудови стрілок на DFD від IDEF0?
5. Пояснити позначення компонентів діаграми DFD.
6. Як згенерувати звіт по діаграмі DFD?
7. Пояснити призначення сховищ та зовнішних суттностів.
Модуль 3. Реалізація об’єктно-орієнтованих програмних систем
Лабораторна робота 3.1.
ПОБУДОВА ДІАГРАМИ ВАРІАНТІВ ВИКОРИСТАННЯ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:побудова use-case діаграм в середовищіIBM Rational Rose.
Завдання:побудувати діаграмувикористання інформаційної системи.
Основні теоретичні відомості
Розробка специфікації, проектування та документування інформаційних систем графічними засобами (діаграмами) відбувається за допомогою уніфікованої мови (Unified Modeling Language, UML).
Базовий елемент мови – діаграма, що являє собою графічне подання елементів системи графом з вершинами (сутностями) і ребрами (відносинами).
Діаграма прецедентів вважається основним видом діаграми візуального моделювання. Основні елементи діаграми прецедентів є ектор, прецендент і відносини між ними.
Ектор – це сутність, з якою взаємодіє система в процесі своєї роботи. В якості ектора можуть виступати люди, зовнішня система, підсистема, клас і т. ін.
Прецедент (use case) – подання послідовних подій, виконуваних системою, які ведуть до спостережуваного ектором результату. Прецеденти на діаграмі позначаються еліпсами. Вони розміщуються всередині прямокутника, який звуть рамками системи, контекстом або просто системою. У верхній частині прямокутника вказується назва модельованої системи.
Ектор і преценденти зв'язані між собою відносинами. На діаграмі прецендентов використовуються відносини асоціації, включення, розширення, успадкування та коментарі. Асоціації між ектором і прецедентом завжди бінарні, представляють відносини типу "один до одного". Подання кратності відносин між прецедентами здійснюється відношенням включення.
Включення означає, що деяка точка базового прецеденту містить поведінку іншого прецедента. Зображується включення залежністю (пунктирна лінія зі стрілкою) зі стереотипом «include». При цьому стрілка спрямована у бік включаємого прецедента.
Розширення доповнює прецедент іншими прецедентами, тобто додає у вихідний прецедент послідовність дій, що міститься в іншому прецеденті. Зображується розширення залежністю (пунктирна лінія зі стрілкою) зі стереотипом «еxtend».
Узагальнення - це відношення між предком і нащадком, і стрілка завжди вказує на предка. Зображується узагальнення лінією з "незафарбованою" трикутною стрілкою на кінці.
У відношенні спадкування, можуть перебувати між собою пакети, ектор, прецеденти. Єдине допустиме відношення між екторами – генералізація (успадкування). Коментарі з'єднуються пунктирною лінією без стрілки.
Порядок виконання роботи
Пропонується ознайомитися з літературою [1, 2, 14-16] та підготуватися до розробки інформаційної системи «банкомат». Виконати послідовність дій 1-13, за їх результатами отримати діаграму, представлену на рис. 3.1.
1. Відкрити діалогове вікно налаштування спеціальних панелей інструментів для діаграм в середовищі IBM Rational Rose 2006 одним із способів:
· з головного меню: Tools® Options (Інструменти®Параметри);
· через вкладку Toolbars (Панелі інструментів) і натиснути відповідну кнопку Use Case diagram в групі опцій Customize Toolbars (Налаштування панелей інструментів);
· за допомогою операції контекстного меню Customize (Налаштування) при позиціонуванні курсора на спеціальній панелі інструментів. Проект назвати «АТМmodel».
Рис. 3.1. Діаграма використання проекту «Банкомат»
2. Додати Ектора на діаграму варіантів використання і відредагувати його властивості шляхом зміни імені, заданого програмою за умовчанням «NewClass» на «Клієнт Банкомату». Змінити його стереотип і додати текст документації. Для зміни стереотипу у вкладеному списку Stereotype потрібно вибрати рядок «Business Actor» (бізнес-актор). Для додавання тексту документації в секцію «Documentation» слід ввести текст: «Будь-яка фізична особа, яка користується послугами банкомата» і натиснути кнопку «Apply» або «OK».
3. Додати і відредагувати варіант використання. Замінити пропоноване програмою ім'я преценденту за замовчуванням «NewUseCase» на «Зняття готівки по кредитній картці». Також змінити стереотип у вкладеному списку «Stereotype», вибравши рядок «Business Use Case». У секцію «Documentation» ввести текст: «Основний варіант використання для розроблюваної моделі банкомату» і закрити діалогове вікно.
4. Додати асоціацію між актором і варіантом використання на діаграму. Зробити спрямовану асоціацію ненаправленою, для чого слід скористатися діалоговим вікном властивостей асоціації. Подвійним клацанням відкрити це вікно на зображенні лінії асоціації на діаграмі, після чого прибрати позначку рядка вибору «Navigable» на вкладці «Role A Detail».
5. Додати варіант використання з ім'ям «Перевірка ПІН-коду». Після цього за допомогою лівої кнопки миші натиснути кнопку із зображенням піктограми залежності на спеціальній панелі інструментів, відпустити ліву кнопку миші, клацнути лівою кнопкою миші на зображенні варіанта використання «Зняття готівки по кредитній картці» і відпустити її на зображенні варіанта використання «Перевірка ПІН-коду». Для доданої відносини залежність слід додатково вказати текстовий стереотип «include».
6. Додати актора з ім'ям «Банк», для якого вибрати стереотип «Service», що означає, що банкомат використовує деякі послуги Банку в якості сервісу.
7. Додати варіант використання «Отримання довідки про стан рахунку», для якого вибрати стереотип «Business Use Case».
8. Додати варіант використання «Блокування кредитної картки».
9. Додати спрямовану асоціацію від бізнес-актора «Клієнт Банкомату» до варіанту використання «Отримання довідки про стан рахунку».
10. Додати спрямовану асоціацію від варіанту використання «Зняття готівки по кредитній картці» до сервісу «Банк».
11. Додати спрямовану асоціацію від варіанту використання «Отримання довідки про стан рахунку» до сервісу «Банк».
12. Додати відношення залежності зі стереотипом «include», спрямоване від варіанту використання «Отримання довідки про стан рахунку» до варіанту використання «Перевірка ПІН-коду».
13. Додати відношення залежності зі стереотипом «extend», спрямоване від варіанту використання «Блокування кредитної картки» до варіанту використання «Перевірка ПІН-коду».
Після закінчення роботи над проектом виконану роботу необхідно зберегти через меню File® Save або File® Save As у файлі проекту з розширенням «.MDL».
Оформлення результатів роботи
Результати лабораторної роботи оформлюються у вигляді звіту обов'язковими елементами, якого є: титульний аркуш; формулювання мети та завдання на роботу; основна частина; висновки. Зразок титульного листа наведений у Додатку 1.
Основна частина роботи повинна містити етапи вирішення індивідуального завдання шляхом аналізу досягнутих результатів в обраній предметній області.
Висновки повинні містити результати виконаної роботи.
Індивідуальні завдання
Розробити use-cаse діаграми для систем, список яких дається або узгодити вибір бізнес-процесів з викладачем.
1. Електронна бібліотека.
2. Система керування доставкою вантажів.
3. Система обслуговування хворих.
4. Система покупки авіаквітків.
5. Інтернет-магазин.
6. Система обслуговування автівок.
7. Система доставки продуктів.
8. Система оплати платежів.
9. Система електронних переказів.
10. Система ремонту побутової техніки.
11. Система надання послуг мобільного зв’язку.
Запитання для самоперевірки
1. Як нефункціональні вимоги відображаються на діаграмах прецедентів?
2. Які способи зображення ектора вам відомі?
3. В які відносини можуть вступати ектори між собою?
4. У чому полягає сенс відносин включення та розширення?
5. Що розуміють під точкою розширення?
6. Перелічити причини використання прецедентів.
7. Як прецеденти застосовують в прямому і зворотному проектуванні?
Лабораторна робота 3.2
РОЗРОБКА ДІАГРАМИ КЛАСІВ В СЕРЕДОВИЩІ IBM RATIONAL ROSE
Мета:навчитися будувати діаграми класів в середовищі IBM Rational Rose.
Завдання:побудувати діаграму класів для заданої інформаційної системи.
Основні теоретичні відомості
Діаграма класів – це набір статичних, декларативних елементів моделі. Елементами діаграмі класів можуть бути інтерфейси, пакети, відносини, об'єкти та зв'язки.
Клас на діаграмі зображується у вигляді прямокутника, розділеного горизонтальними лініями на три секції. Перша секція містить назву класу. Як правило, ім'я класу складається з одного, максимум двох слів. Друга містить перелік атрибутів класу, які характеризують той чи інший об'єкт цього класу в моделі предметної області. Третя містить перелік операцій, що відображають його поведінку в моделі предметної області.
Атрибут – змістовна характеристика класу, що описує множину значень, які можуть приймати окремі об'єкти цього класу.
Операція – це сервіс, що надається кожним екземпляром або об'єктом класу на вимогу своїх клієнтів, в якості яких можуть виступати інші об'єкти, в тому числі і екземпляри даного класа.
Інтерфейс – іменована множина операцій, які характеризують поведінку окремого елемента моделі. Інтерфейс в контексті мови UML є спеціальним випадком класу, у якого є операції, але відсутні атрибути. Для позначення інтерфейсу використовується спеціальний графічний символ коло або стандартний спосіб – прямокутник класу зі стереотипом «interface».
Таблиця 3.1
Символи видимості атрибуту класу
| Символ | Значення |
| + | public - відкритий доступ |
| - | private - тільки для операцій того ж класу |
| # | protected - тільки для операцій того ж класу і класів, що створюються на його основі |
Відношення залежність виникає тоді, коли реалізація класу одного об'єкта залежить від специфікації операцій класу іншого об'єкта.
Асоціація – це зв'язок між об'єктами. Асоціація може мати ім'я, яке показує природу відносин між об'єктами, при цьому в імені може вказуватися напрямок читання зв'язку за допомогою трикутного маркера. Однонапрямлена асоціація може зображуватися стрілкою. Крім напрямку, на асоціації в діаграмі вказуються ролі, які кожен клас відіграє в даному відношенні, і кратність, тобто кількість об'єктів, пов'язаних відношенням. Якщо асоціація об'єднує три і більше класів, то її називають n-арною і зображуються ромбом на перетині ліній. Асоціація з агрегуванням є складним відношенням між класами типу "частина-ціле".
Розрізнюють асоціації агрегації і композиції. Проста агрегація припускає, що частини, які відділені від цілого, можуть продовжувати своє існування незалежно від нього. Під композитним агрегуванням розуміється ситуація, коли ціле володіє своїми частинами і їх час життя відповідає часу життя цілого, тобто незалежно від цілого частини існувати не можуть.
Графічно відношення агрегації зображується суцільною лінією, один з кінців якої являє собою незафарбований усередині ромб, а відношення композиції – суцільною лінією з зафарбованим всередині ромбом. Цей ромб вказує на той клас, який являє собою або клас-контейнер або клас-композит.
Відношення узагальнення позначається суцільною лінією з трикутною стрілкою на одному з кінців. Стрілка вказує на більш загальний клас (клас-предок або суперклас), а її початок – на більш спеціальний клас (клас-нащадок або підклас).
Порядок виконання роботи
Ознайомитися з літературою [1, 2, 14-16], виконати послідовність дій 1-32, за їх результатами отримати діаграму у вигляді, який показано на рис. 3.2.
1. Викликати діаграму класів та змінити запропоноване за замовчуванням ім'я діаграми «Main» на «Діаграма класів ATM», а ім'я доданого класу на діаграму – на «Транзакція Банкомату». Імена класів, їх атрибутів і операцій для більшої наочності і розуміння подаються українською мовою з пробілами.
Рис. 3.2. Діаграма класів для варіанта використання «Зняття грошей»
2. Додати клас «Транзакція Банкомату» на діаграму класів. Для класу Транзакція Банкомату вточнити його призначення в моделі за допомогою вказання стереотипу і пояснювального тексту в документації. Для цього відкрити діалогове вікно специфікації властивостей цього класу і на вкладці «General» вибрати з вкладеного списку «Stereotype» стереотип «entity». У секцію документації даного класу можна ввести пояснювальний текст: «Використовується для збереження інформації про виконані банкоматом транзакції» і натиснути кнопку «Apply» або «OK» для збереження результатів редагування.
3. Додати на діаграму другий клас «Контролер Банкомату», для якого у вікні специфікації властивостей виберемо стереотип «control», а для документації вводимо текст: «Реалізує логіку функціонування банкомату». При цьому атрибути та операції у даного класу будуть відсутні.
4. Додати на діаграму третій клас з ім'ям «Пристрій читання картки», для якого у вікні специфікації властивостей виберемо стереотип «boundary», який означає, що даний клас знаходиться на межі модельованої системи, в якості якої розглядається модель банкомату. Після цього в секцію документації даного класу можна ввести пояснювальний текст: «Встановлюється на банкоматі».
5. Додати клас з ім'ям «IКонтроллер Банку», для якого вибрати стереотип «Interface», що означає, що банкомат користується послугами «Банку» при обробці своїх транзакцій. Першою літерою в імені цього класу є англійське «I», яке служить в мові UML для вказання інтерфейсу.
6. Задаємо операції класів. Для класу «Транзакція Банкомату» в якості імені першої операції задаємо: створити нову транзакцію. Для операції «створити нову транзакцію ()» вибрати з вкладеного списку квантор видимості «public». У секцію документації даної операції класу вводиться пояснювальний текст: «Викликається після того, як кредитна картка вставлена в Пристрій читання картки» і натиснути кнопку «Apply» або «OK».
Додати в специфікацію класу «Транзакція Банкомату» наступні атрибути і операції.
· для значення ПІН-коду картки встановити квантор видимості «public». Атрибутом значення обрати тип «Integer», а в секцію документації атрибута ввести пояснювальний текст: «Пристрій читання картки зчитує значення цього атрибута з кредитної картки клієнта».
· для атрибуту «введений ПІН-код» встановити квантор видимості «public». Для цього атрибуту вибрати тип Integer, а в секцію документації атрибуту ввести пояснювальний текст: «Значення цього атрибута вводиться клієнтом з клавіатури банкомату».
· для атрибуту «сума готівки» встановити квантор видимості «public». Для цього атрибуту обрати тип «Currency», а в секцію документації атрибута ввести пояснювальний текст: «Значення цього атрибута вводиться клієнтом з клавіатури банкомату».