Лабораторна робота №2

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Мета роботи: вивчити можливості та інтерфейс користувача системи підтримки проектування програмного забезпечення Rational Rose. Створити уявлення варіантів використання для індивідуального варіанта завдання на розробку програмного забезпечення.

Важливим досягненням розвитку методології ООП стало усвідомлення того, що процес написання програмного коду може бути відділений від процесу проектування структури програми. Перш ніж почати програмування класів, їх властивостей і методів, необхідно визначити самі ці класи, властивості та методи, необхідні для додання їм необхідного поводження, а також взаємозв'язку між класами. Ця сукупність завдань вирішується в процесі загального аналізу вимог до майбутньої програмі, а також аналізу конкретної предметної області її застосування. Всі ці обставини призвели до появи спеціальної методології, що отримала назву методології об'єктно орієнтованого аналізу і проектування (ООАП).

Об'єктно-орієнтований аналіз та проектування (Object-Oriented Analysis / Design, OOA / D) - технологія розробки програмних систем, в основу яких покладена об'єктно-орієнтована методологія уявлення предметної області у вигляді об'єктів, що є екземплярами відповідних класів.

Уніфікована мова моделювання (Unified Modeling Language, UML) є графічною мовою для візуалізації, специфіцирування, конструювання та документування систем, в яких велика роль належить програмному забезпеченню. За допомогою UML можна розробити детальний план створюваної системи, що містить не тільки її концептуальні елементи (системні функції, бізнес-процеси), а й конкретні особливості (наприклад, класи, написані на спеціальних мовах програмування, схеми баз даних, програмні компоненти багаторазового використання). Поточною версією UML є 2.0, однак в якості міжнародного стандарту ISO / IEC прийнятий UML 1.4.2.

Rational Rose - сімейство об'єктно-орієнтованих CASE-засобів фірми Rational Software Corporation, призначене для автоматизації процесів аналізу і проектування ПЗ, а також для генерації кодів на різних мовах програмування і випуску проектної документації.

В основі роботи Rational Rose лежить побудова діаграм і специфікацій UML, що визначають архітектуру системи, її статичні і динамічні аспекти.

1. Репозиторій, що представляє собою базу даних проекту.

3. Засоби перегляду проекту - браузер, що забезпечує навігацію по проекту, в тому числі по ієрархіям класів і підсистем, перемикання від одного виду діаграм до іншого і т. Д.

4. Засоби контролю проекту та збору статистики, що дозволяють находить і усувати помилки у міру розвитку проекту.

5. Генератор документів, що формує тексти вихідних документів з урахуванням інформації, що міститься в репозиторії.

6. Засоби автоматичної генерації кодів програм, що формують на основі інформації в діаграмах класів і компонентів файли заголовків і файли описів класів і об'єктів.

7. Аналізатор кодів С ++ (реалізований у вигляді окремого програмного модуля), який на основі визначених користувачем вихідних текстів на мові C ++ може створювати модулі проектів Rational Rose.

В результаті розробки проекту за допомогою CASE-засобів Rational Rose можуть бути сформовані наступні документи:

· діаграми UML, що представляють собою Модель розроблювального ПЗ;

· специфікації класів, об'єктів, атрибутів і операцій;

1. Браузер проекту - використовується для швидкої навігації по моделі.

2. Вікно документації - застосовується для роботи з текстовим описом моделі.

3. Панелі інструментів (головна і стандартна) - застосовуються для б строго доступу до найбільш поширених командам.

4. Робоча область зображення діаграми - використовується для просмот ра і редагування однієї або декількох діаграм UML.

5. Журнал - застосовується для перегляду помилок і звітів про результати виконання різних команд.

У моделі Rational Rose підтримується чотири вистави (views) - представлення варіантів використання, логічне подання, подання компонентів і уявлення розміщення. У першій лабораторній роботі розглядається подання варіантів використання.

Поняття варіанта використання, чи прецеденту (Use Case) є основним елементом розробки та планування проекту. Варіант використання являє собою послідовність дій (транзакцій), виконуваних системою у відповідь на подію, що ініціюється деяким зовнішнім об'єктом (дійовою особою). Прецедент описує типове взаємодія між користувачем і системою.

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

Розглянемо приклад діаграми використання, який ілюструє роботу банкомату (рис. 1.1).

Рис. 1.1. Діаграма варіантів використання для системи «Банкомат»

Дійовими особами в даній системі є клієнт і банківська система. Проектована система «Банкомат» повинна виконувати наступні дії: перевести гроші, зробити внесок, зняти гроші з рахунку, змінити код, показати баланс, здійснити оплату. На діаграмі показано взаємодію між варіантами використання і діючими особами, відбиті вимоги до системи з точки зору користувача. Можна сказати, що варіанти використання - це функції, виконувані системою, а актори - зацікавлені особи (stakeholders), які ініціюють варіанти використання або одержують від нього інформацію.

При розробці діаграм варіантів використання бажано дотримуватися наступних правил.

1. Дійові особи перебувають поза сферою дії проектованої системи, а значить, і зв'язки між ними моделювати не варто.

2. Небажано з'єднувати комунікаційної зв'язком два варіанти використання, так як діаграма повинна описувати доступні системі варіанти використання, а не порядок їх проходження.

3. Варіант використання має бути ініційований дійовою особою (повинна бути суцільна стрілка, що йде від актора до прецеденту).

Починати будувати діаграму найкраще з перерахування всіх подій зовнішнього світу, на які система повинна реагувати.

Більш конкретні деталі варіантів використання описуються в спеціальному документі, званому потік подій (Flow of Events). Його метою є документування процесу обробки даних в рамках варіанта використання.

· альтернативний потік подій (один або декілька);

Короткий опис. Кожен прецедент повинен мати пов'язане з ним короткий опис виконуваної дії. Наприклад: Варіант використання «Переказати гроші» дозволяє клієнтові або службовцю банку переказувати гроші з одного рахунку на інший.

Предусловия. Предусловия прецеденту - це такі умови, які повинні бути виконані, перш ніж прецедент почне виконуватися сам. Наприклад, виконання іншого варіанту використання, наявність у користувача прав доступу і т.п.

Основний і альтернативний потоки подій. Потік подій поетапно описує, що повинно виконуватися у варіанті використання:

· різні шляху виконання варіанти використання;

· відхилення від нормального потоку (альтернативні потоки);

Приклад: Потік подій для прецеденту «Зняти гроші з рахунку»

1. Варіант використання починається, коли клієнт вставляє карточку в банкомат.

2. Банкомат виводить вітання і пропонує користувачеві ввести пін - код.

4. Банкомат підтверджує введений пін - код. Якщо код НЕ підтверджується, виконується альтернативний потік А1.

5. Банкомат виводить список доступних дій: покласти гроші, зняти гроші, перевести гроші.

9. Банкомат перевіряє наявність введеної суми на рахунку. Якщо грошей на рахунку недостатньо, виконується альтернативний потік А2. При виник новении помилки виконується потік помилки Е1.

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

В UML на діаграмах прецедентів підтримується кілька типів зв'язків між елементами:

· комунікація (communication) - позначається суцільний лінією зі стрілкою - зв'язок між актором і прецедентом, напрямок стрілки ет зрозуміти, хто ініціює комунікацію;

· включення (include) - позначається лінією з відповідним стерео типом - застосовується в тих ситуаціях, коли фрагмент поведінки системи по повторюється в декількох варіантах використання (наприклад, аутентифікація клієнта в системі «Банкомат» потрібно як в прецеденті «Зняти гроші з рахунку», так і «Зробити внесок» і т. д.);

· розширення (extend) - позначається аналогічно включенню – використовується при описі змін в нормальному поведінці системи, що дозволяє прецеденту використовувати функціональні можливості іншого прецеденту тільки при необхідності;

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

Приклад різних зв'язків між прецедентами показаний на рис. 1.2.