Створення нового проекту й зовнішній вигляд системи
При створенні нового проекту програма пропонує вибрати один із предустановленных моделей проекту. Доступні наступні моделі: Bussiness Process, Requirements, Use Case, Domain Model, Class, Database, Component, Deployment, Testing, Maintenance, Project Management, User Interface.
Робоча область програми при роботі з діаграмами розбита за замовчуванням на чотири основні частини(не беремо до уваги панель інструментів, рядок стану й панель меню): Project Browser Model View, Resourses, Notes, Toolbox і, властиво, панель Diagram.
Коротко опишемо призначення кожної панелі:
· Project Browser - дозволяє користувачеві створювати, редагувати й переглядати модель, як ієрархічну структуру. Це досить зручно, тому що дозволяє користувачеві простежити зв'язки між дочірніми й батьківськими вимогами. При виконанні даної лабораторної роботи більша частина дій проходила саме в цьому вікні.
· Notes - дозволяє давати розгорнутий опис того або іншого елемента, що дозволяє давати їм короткі імена, у наслідку розкриваючи їх за допомогою заміток. Так само в даній частині вікна доступні вкладки Pan&Zoom, яка представляє міні-карту вашої діаграми, для більш зручної й швидкої навігації по ній, Properties - для редагування властивостей вимог, Hierarchy - призначена для відображення обраного вимоги й усіх його вкладень.
· Toolbox - дана панель надає кошти для побудови діаграм: різні елементи діаграм, зв'язки між ними, а так само різні елементи, призначені для підвищення удобочитаемости діаграм.
· Diagram - використовується для відображення різних діаграм.
Microsoft Visio
Microsoft Visio — редактор діаграм і блок-схем для Windows. Використовує векторну графіку для створення діаграм.
Випускається у двох редакціях: Standard і Professional. Спочатку Visio розроблявся й випускався компанією Visio Corporation. Microsoft придбала компанію в 2000 році, коли продукт називався Visio 2000.
За допомогою Microsoft Visio можливо наочно документувати, розробляти й оцінювати стан бізнес-процесів і систем, користуючись широким набором доступних діаграм, у тому числі блок-схемами ділових процесів, мережними діаграмами, діаграмами робочого потоку, моделями бази даних і діаграмами програмного забезпечення. Щоб зробити діаграми ще більш корисними й наочними, можливо зв'язати їх в Microsoft Visio Professional 2007 з вихідними даними.
Цей пакет із сімейства Microsoft Office призначений винятково для малювання діаграм. Visio має деякі додаткові можливості, але все-таки по більшій мері - це тільки засіб для ілюстрування документів MS Office, ", що не дотягає" до рівня пакетів, описаних раніше.
Образотворчі ж можливості Visio дійсно досить широкі, крім того програма підтримує:
· розширення можливостей Visio, використовуючи нові шаблони бізнес-діаграм.
· використання зовнішніх источниов даних, сховища або колекції збережених шаблонів.
· прототипирование інтерфейсу додатків за допомогою вбудованих шаблонів користувацького інтерфейсу Microsoft Windows XP, що дозволяє створювати модель користувацького інтерфейсу в стандартному Windows Xp-Стилі
· малювання діаграми мережних ресурсів, що ілюструють розгортання нового ПО на існуючі мережні ресурси.
· створення Uml-Діаграми статичної структури ПО або проведення обратноого проектування за допомогою Visio 2003 Reverse Engineer Wizard
Visio - це не повноцінний засіб моделювання, а програма для створення ілюстрацій ( як і Smartdraw і Dia), що вміє, крім іншого, малювати Uml-Діаграми.
Rational Rose – сімейство об’єктно-орієнтованих CASE-засобів фірми Rational Software Corporation, яке призначене для автоматизації процесів аналізу та проектування програмного забезпечення інформаційних систем, а також для генерації кодів на різних мовах програмування і випуску проектної документації. Rational Rose використовує метод об’єктно-орієнтованого аналізу та проектування, заснований на універсальній мові моделювання UML.
Поточна версія Rational Rose реалізує генерацію кодів програм для С++, Visual C++, Visual Basic, Java, PowerBuilder, CORBA Interface Definition Language (IDL), генерацію описів баз даних для ANSI SQL, Oracle, MS SQL Server, IBM DB2, Sybase, а також дозволяє розробляти проектну документацію у вигляді діаграм і специфікацій. Крім того, Rational Rose містить засоби реверсного інжинірингу програм і баз даних, що забезпечують повторне використання програмних компонентів у нових проектах.
У результаті розробки проекту за допомогою CASE-засобу Rational Rose формуються наступні документи:
діаграми UML, які в сукупності представляють модель розроблювальної програмної системи;
специфікації класів, об'єктів, атрибутів і операцій;
заготівки текстів програм.
Етапи проведення моделювання в Rational Rose
Моделювання здійснюється як проходження за рівнями від концептуальної моделі до логічної, а потім до фізичної моделі програмної системи.
Концептуальна модель виражається у вигляді діаграм варіантів використання (use-case diagram). Цей тип діаграм слугує для проведення ітераційного циклу загальної постановки задачі разом із замовником. Діаграми варіантів використання саме і є основою для досягнення взаєморозуміння між програмістами-професіоналами, що розробляють проект, і замовниками проекту.
Представлення моделі Rose
У моделі Rose підтримується чотири представлення (views) варіантів використання, логічне представлення, представлення компонентів і представлення розміщення. Кожне з них призначено для своїх цілей і для відповідної аудиторії.
Представлення варіантів використаннямістить усіх діючих осіб, усі варіанти використання та їхні діаграми для конкретної системи. Воно може також містити деякі діаграми послідовності і кооперативні діаграми (рис. 3).
Представлення варіантів використання містить:
діючих осіб;
варіанти використання;
документацію за варіантами використання, що деталізує процеси,
що відбуваються в них, (потоки подій), включаючи обробку помилок. Піктограмами зображуються зовнішні файли, прикріплені до моделі Rose. Вид піктограми, залежить від додатка, використовуваного для документування потоку подій;
діаграми варіантів використання. Зазвичай система складається декількох таких діаграм, кожна з яких показує підмножину діючих осіб і/або варіантів використання;
пакети, що є групами варіантів використання і/або діючих осіб.
Логічне представлення (рис. 4) концентрується на тому, як система буде реалізовувати поведінку, описану у варіантах використання. Воно дає докладну картину складових частин системи й описує взаємодію цих частин. Логічне представлення включає, крім іншого, конкретні необхідні класи, діаграми класів і діаграми станів. За їх допомогою конструюється детальний проект створюваної системи.
Логічне представлення містить:
класи;
діаграми класів. Як правило, для опису системи використовується кілька діаграм класів, кожна з яких відображає деяку підмножину всіх класів системи;
діаграми взаємодії, застосовувані для відображення об'єктів, що беруть участь в одному потоці подій варіанта використання;
діаграми станів;
пакети, що є групами взаємозалежних класів.
Представлення компонентів містить:
компоненти, що є фізичними модулями коду;
діаграми компонентів;
пакети, що є групами зв'язаних компонентів.
Представлення розміщення відповідає фізичному розміщенню системи, що може відрізнятися від її логічної архітектури. До нього входять:
процеси, що є потоками (threads), що здійснюються у відведеній для них області пам'яті;
процесори, що включають будь-які комп'ютери, здатні обробляти дані. Кожний процес виконується на одному або декількох процесорах;
пристрої, тобто будь-яка апаратура, не здатна обробляти дані. До числа таких пристроїв відносяться, наприклад, термінали уведення-виведення та принтери;
діаграма розміщення.
Теоретичний матеріал «Діаграма прецедентів»
Діаграма прецедентів (варіантів використання) створюється для моделювання бізнес-процесів і функціональних вимог до створюваної системи. Ця діаграма є найбільш загальною концептуальною моделлю складної системи, і є початковою для побудови решти всіх UML-діаграм.
Діаграма варіантів використання описує дії інформаційної системи з погляду зовніш-нього спостерігача. Акцент ставиться на те, що саме робить система, а не на те, як вона це робить. Діаграма варіантів використання - це колекція акторів, варіантів використання та їх комунікацій.
У цій практичній роботі завдання передбачає побудування концептуальної моделі статичного уявлення інформаційної системи. Таке уявлення надає тільки взаємозв'язки структурного характеру, не залежні від часу або реакції системи на зовнішні події.
Варіант використання (use case) 
є документом, що описує послідовність дій (транзакцій), виконуваних системою у відповідь на подію, що ініціюється деяким зовнішнім об'єктом (дійовою особою). Варіант використання описує типову взаємодію між користувачем і системою.
Основну увагу при описі варіанта використання потрібно сконцентрувати на запитанні: «Як використання системи забезпечує відчутний для користувача результат або вирішує його задачу?», а не на обдумуванні системних вимог в термінах властивостей і функцій.
Дійова особа (actor) 
– це роль, яку користувач відіграє стосовно до системи. Дійові особи є ролями, а не конкретними людьми або найменуваннями робіт. Показувати на діаграмі дійових осіб слід тільки в тому випадку, коли їм дійсно необхідні деякі варіанти використання.
Дійові особи діляться на три основні типи: користувачі системи, інші системи, що взаємодіють з даною, і час. Час стає дійовою особою, якщо від нього залежить запуск певних подій у системі.
Діаграма варіантів використання (use case diagram) відображає взаємодію між варіантами використання і дійовими особами. Вона відображає вимоги до системи з погляду користувача. Таким чином, варіанти використання – це функції, виконувані системою, а дійові особи – це зацікавлені особи (stakeholders) стосовно створюваної системи.
Такі діаграми показують, які дійові особи ініціюють варіанти використання. З них також видно, коли дійова особа одержує інформацію від варіанта використання.
Згідно з існуючою методикою проектування інформаційних систем на діаграмі варіантів використання людські фігурки позначають дійових осіб, овали – варіанти використання, а лінії і стрілки – різні зв'язки між дійовими особами та варіантами використання. Варіанти використання завжди слід аналізувати разом із дійовими особами системи, визначаючи при цьому реальні задачі користувачів і розглядаючи альтернативні способи розв’язання цих задач.
Дійові особи можуть виконувати різні ролі стосовно варіанта використання. Вони можуть користуватися його результатами або можуть самі безпосередньо в ньому брати участь.
Конкретна мета діаграм варіантів використання – це документування варіантів використання (все, що входить у сферу застосування системи), дійових осіб (все поза цією сферою) і зв'язків між ними.
Варіант використання ініціюється запитом дійової особи до системи для отримання певного сервісу, що надаються нею, і описує поведінку системи під час надання даного сервісу. У загальному випадку варіанти використання застосовуються для опису процесів, що відбуваються в предметній області, і є об'єктом переговорів між замовниками й виконавцями на розробку інформаційної системи.
Розробляючи варіанти використання, слід дотримуватися наступних правил:
не треба моделювати зв'язки між дійовими особами. За визначенням дійові особи знаходяться поза сферою діяльності системи. Це означає, що зв'язки між ними також не відносяться до її компетенції;
не слід сполучати стрілкою два варіанти використання безпосередньо. Діаграми даного типу описують тільки, які варіанти використання доступні системі, а не порядок їх виконання;
кожен варіант використання повинен бути ініційований дійовою особою. Це означає, що завжди є стрілка, що починається на дійовій особі і
закінчується на варіанті використання.
Хорошим джерелом для ідентифікації варіантів використання слугують зовнішні події. Слід почати з переліку всіх подій, що відбуваються в зовнішньому світі, на які система повинна якимось чином реагувати. Будь-яка конкретна подія може спричинити реакцію системи, що не вимагає втручання користувачів, або, навпаки, викликати реакцію призначену тільки для користувача. Ідентифікація подій, на які необхідно реагувати, допомагає ідентифікувати варіанти використання.
Виходячи з потреб дійових осіб, виділені наступні варіанти використання (рисунок 1). Якщо кінцевим користувачем системи є лише одна дійова особа, діаграма варіантів використання приймає вигляд, як показано на рисунку 2.
Рисунок 1 - Діаграма варіантів використання комплексу задач
“Облік узгодженості потреби цеху з комплектністю СГД”
Рисунок 2 - Діаграма варіантів використання комплексу задач “Складський облік”
Контрольні питання:
1. З якими інструментами для створення діаграм ви ознайомились?
2. Який із засобів є найбільш розширеним?
3. Які панелі інструментів ви запам’ятали та для чого вони призначені?
4. Яке прикладення ви будете використовувати для створення діаграм?
5. Які з перелічених продуктів підтримують створення коду на основі діаграми?
6. У чому зміст варіанта використання?
7. Яке призначення діаграм варіантів використання?
8. Назвіть основні властивості варіантів використання.
9. Назвіть основні компоненти діаграм варіантів використання.
10. Що таке «дійова особа»?
11. Яку роль можуть грати дійові особи стосовно варіанта використання?
12. Яким чином аналіз зовнішніх подій дозволяє визначити варіанти використання системи?