Хід виконання роботи

Дати відповіді на питання.

1. Як розшифровується абревіатура UML?

2. Яка версія UML є поточної?

3. Хто були авторами UML?

4. Чим НЕ є UML?

5. Які програмні засоби, що підтримують UML, ви знаєте?

6. Чи використаються в UML "тривимірні" фігури?

ЛАБОРАТОРНА РОБОТА №2 (частина перша)

Тема

Діаграма прецедентів (use case diagram)

Мета роботи

Отримати уявлення про діаграму прецедентів

Теоретичні відомості

Будь-які (у тому числі й програмні) системи проектуються з обліком того, що в процесі своєї роботи вони будуть використатися людьми й/або взаємодіяти з іншими системами. Сутності, з якими взаємодіє система в процесі своєї роботи, називаються екторами, причому кожний ектор очікує, що система буде поводитися строго певним, передбачуваним чином. UML Zicom Mentor:

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

Графічно ектор зображується або "чоловічком", подібним тим, які ми малювали в дитинстві, зображуючи членів своєї родини, або символом класу з відповідним стереотипом, як показано на рис.2.1:

Рис 2.1. Ектор

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

Прецедент (use-case) - опис окремого аспекту поводження системи з погляду користувача (Буч).

Прецедент (use case) - опис безлічі послідовних подій (включаючи варіанти), що виконуються системою, які приводять до спостережуваного ектором результату. Прецедент представляє поводження сутності, описуючи взаємодію між екторами й системою. Прецедент не показує, "як" досягається деякий результат, а тільки "що" саме виконується.

Прецеденти позначаються дуже простим образом - у вигляді еліпса, усередині якого зазначене його назва. (рис. 2.2.).

Рис.2.2. Прецендент

Прецеденти й ектори з'єднуються за допомогою ліній. Часто на одному з кінців лінії зображують стрілку, причому спрямовано вона до тому, у кого запитують сервіс, інакше кажучи, чиїми послугами користуються.

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

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

• визначення границі й контексту предметної області на ранніх етапах проектування;

• формування загальних вимог до поводження проектованої системи;

• розробка концептуальної моделі системи для її наступної деталізації;

• підготовка документації для взаємодії із замовниками й користувачами системи.

Розглянемо діаграму прецедентів (рис 2.3.)

Крім зазначених у практичній роботі №2 елементів, у цій діаграмі використовуються елементи, які дозволяють :

1. визначити візуально межі системи;

2. узагальнити об’єкти;

3. додати сценарії для прецеденту за допомогою коментарю;

4. зв’язати один прецедент з іншими, які є складовими частинами цього прецеденту (включення);

5. зв’язати прецедент з іншим (розширення), вказуючи на те, що цей прецедент є частиною іншого.

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

Прецедент	Ектор