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

Тема: Створення проекту Rational Rose

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

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

1.1. Основні відомості про систему 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, що визначають архітектуру системи, її статичні і динамічні аспекти.

Основні структурні компоненти Rational Rose:

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

2. Графічний інтерфейс користувача.

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

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

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

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

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

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

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

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

· заготовки текстів програм.

Користувальницький інтерфейс Rational Rose

Основними елементами інтерфейсу є:

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

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

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

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

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

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

Подання варіантів використання

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

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

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

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

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

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

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

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

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

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

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

Потік подій зазвичай включає:

· короткий опис;

· передумові (pre-conditions);

· основний потік подій;

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

· постумови (post-conditions).

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

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

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

· спосіб запуску варіанти використання;

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

· нормальний потік подій;

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

· потоки помилок;

· спосіб завершення варіанти використання.

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

Основний потік:

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

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

3. Клієнт вводить пін - код.

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

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

6. Клієнт вибирає пункт «Зняти гроші».

7. Банкомат запрошувати суму.

8. Клієнт вводить суму.

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

10. Банкомат віднімає суму з рахунку.

11. Банкомат видає необхідну суму.

12. Банкомат повертає клієнту картку.

13. Банкомат друкує чек.

14. Варіант використання завершується.

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

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

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

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

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

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

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