Введення
UML (Скор. від англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML моделлю . UML був створений для визначення, візуалізації, проектування та документування у основному програмних систем. UML не є мовою програмування, але в засобах виконання UML-моделей як інтерпретується коду можлива кодогенерацію. Використання UML не обмежується моделюванням програмного забезпечення. Його також використовують для моделювання бізнес-процесів, системного проектування і відображення організаційних структур.
UML дозволяє також розробникам програмного забезпечення досягти угоди в графічних позначеннях для представлення загальних понять (таких як клас, компонент, узагальнення (generalization), об'єднання (aggregation) і поведінка) і більше сконцентруватися на проектуванні та архітектурі.
Завдання
За допомогою UML діаграм описати бізнес-процеси В«ХімчисткиВ», у візуальному середовищі Visual Paradigm UML 2.0.
Use Case (Варіанти використання)
Основна мета створення будь програмної системи - створення такого програмного продукту, який допомагає користувачеві виконувати свої повсякденні завдання. Для створення таких програм першою справою визначаються вимоги, яким повинна задовольняти система. Однак якщо дати користувачам написати ці вимоги на папері, то часто можна отримати список функцій, по якому важко судити чи буде майбутня система виконувати своє призначення і чи зможе вона полегшити користувачеві виконання його роботи взагалі. Незрозуміло які з виконуваних функцій більш важливі і для кого.
Для того, щоб більш точно зрозуміти як повинна працювати система, всі частіше використовується опис функціональності системи через варіанти використання (Use Case або прецеденти). Варіанти використання це - опис послідовності дій, які може здійснювати система у відповідь на зовнішні впливи користувачів або інших програмних систем. Варіанти використання відображають функціональність системи з точки зору отримання значущого результату для користувача, тому вони точніше дозволяють ранжувати функції по значущості одержуваного результату.
Варіанти використання призначені в першу чергу для визначення функціональних вимог до системі і керують усім процесом розробки. Всі основні види діяльності такі як аналіз, проектування, тестування виконуються на основі варіантів використання. Під час аналізу і проектування варіанти використання дозволяють зрозуміти як результати, які хоче отримати користувач впливають на архітектуру системи і як повинні поводитися компоненти системи, для того щоб реалізувати потрібну для користувача функціональність.
В процесі тестування, описані раніше варіанти використання дозволяють простіше оцінити точність реалізації вимог користувачів і дозволяють провести покрокову перевірку цих вимог.
Стратегія використання прецедентів при визначенні вимог визначає необхідність додатково до питання "що користувачі чекають від системи?" задавати питання "що система повинна зробити для конкретного користувача?". Такий підхід дозволяє шукати функції, які потрібні багатьом користувачам і виключати ті можливості, які не можуть допомогти користувачам виконувати свої повсякденні завдання.
Склад діаграми Use Case
Діаграма варіантів використання складається з акторів , для яких система виробляє дія і власне дії Use Case , яке описує те, що актор хоче отримати від системи. Актор позначається чоловічка, а Use Case - овалом. Додатково в діаграми можуть бути додані коментарі.
Окремий варіант використання позначається на діаграмі еліпсом , усередині якого міститься його коротку назву або ім'я у формі дієслова з пояснювальними словами.
Мета варіанти використання полягає в тому, щоб визначити закінчений аспект або фрагмент поведінки деякої сутності без розкриття її внутрішньої структури. В Як такої сутності може виступати система або будь-який елемент моделі, який володіє власною поведінкою.
Кожен варіант використання відповідає окремому сервісу, який надає моделируемая сутність за запитом актора, тобто визначає спосіб застосування цієї сутності. Сервіс, який ініціалізується за запитом актора, являє собою закінчену неподільну послідовність дій. Це означає, що після того як система закінчить обробку запиту, вона повинна повернутися в початковий стан, щоб бути готовою до виконання наступних запитів.
Актори взаємодіють з системою за допомогою обміну повідомленнями з варіантами використання. Повідомлення являє собою запит актором певного сервісу системи та отримання цього сервісу. Ця взаємодія може бути виражене за допомогою асоціацій між окремими акторами і варіантами використання або класами. Крім цього, з акторами можуть бути пов'язані інтерфейси, які визначають, яким чином інші елементи моделі взаємодіють з цими акторами.
Види взаємодій
Між акторами і варіантами використання можуть бути різні види взаємодії. Основні види взаємодії наступні:
• Проста асоціація - Відбивається лінією між актором і варіантом використання (без стрілки). Відображає зв'язок актора і варіанти використання. На малюнку між актором адміністратор і варіантом використання переглядати замовлення .
• Спрямована асоціація - то ж що і проста асоціація, але показує, що варіант використання ініціалізується актором. Позначається стрілкою.
• Спадкування - показує, що нащадок успадковує атрибути та поведінку свого прямого предка. Може застосовуватися як для акторів, так для варіантів використання.
• Розширення (extend) - показує, що варіант використання розширює базову послідовність дій і вставляє власну послідовність. При цьому на відміну від типу відносин "включення" розширена послідовність може здійснюватися залежно від певних умов.
Включення - показує, що варіант використання включається в базову послідовність і виконується завжди (на малюнку не показаний).
На даному етапі курсового проектування ми додали 5 акторів: В«клієнтВ», В«адміністраторВ», В«БухгалтеріяВ», В«робітникВ» і В«директорВ». Також додали 8 дій Use Case: В«Подача заявки на чисткуВ», В«оформлення заявки на чисткуВ», В«зміна заявкиВ», В«Виконати роботуВ», В«видача квитанцій про оплату послугВ», В«додати заявку до звітом В»,В« оновити звіт за день В»,В« відхилити заявку на чистку В», останнім є якраз розширення. На даному малюнку видно, що актори взаємодіють з діями (варіантами використання). Кожен Актор породжує взаємодії. Всі взаємодії представлені на малюнку.
Sequence diagram (діаграма послідовності)
Діаграма послідовності, Sequence diagram - діаграма, на якій зображено впорядковане в часі взаємодія об'єктів. В Зокрема, на ній зображуються беруть участь у взаємодії об'єкти та послідовність повідомлень, якими вони обмінюються.
На діаграмі послідовності зображаються виключно ті об'єкти, які безпосередньо беруть участь у взаємодії і не показуються можливі статичні асоціації з іншими об'єктами. Для діаграми послідовності ключовим моментом є саме динаміка взаємодії об'єктів у часі. При цьому діаграма послідовності має як би два виміри. Одне - зліва направо у вигляді вертикальних ліній, кожна з яких зображає лінію життя окремого об'єкта, який бере участь у взаємодії. Графічно кожен об'єкт зображається прямокутником ...
