Побудова UML-діаграм в IBM Rational

При побудові моделі складних систем ми не можемо описати їх повністю, "окинути одним поглядом". Тому ми виділяємо лише суттєві для конкретного завдання властивості системи і будуємо її модель, що відображає ці властивості. Метод об'єктно-орієнтованого аналізу дозволяє описувати реальні складні системи найбільш адекватним чином. Але зі збільшенням складності систем виникає потреба в хорошій технології моделювання. В якості такої "стандартної" технології використовується уніфікована мова моделювання (Unified Modeling Language, UML), яка є графічною мовою для специфікації, візуалізації, проектування та документування систем. За допомогою UML можна розробити детальну модель створюваної системи, що відображає не тільки її концепцію, а й конкретні особливості реалізації.

UML - уніфікована мова моделювання..

Пеше слово в абревіатурі  UML - слово мова, формальна і штучна. Штучна вона тому, що у неї є автори, Формальною її можна назвати, оскільки є правила її вживання . Ще один нюанс: UML - мова графічна.При описі формальної штучної мови описуються такі її елементи, як:

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

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

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

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

Третє слово в назві UML - слово "уніфікована". UML стала  єдиним універсальним стандартом для об'єктно-орієнтованого моделювання. "Єдиною" мовою моделювання UML можна назвати ще й тому, що в його створенні об'єдналися зусилля авторів трьох найбільш популярних методів моделювання .

Одним із завдань UML є служити засобом комунікації всередині команди і при спілкуванні з замовником. "У робочому порядку" діаграми часто малюють на папері від руки, причому зазвичай - не надто акуратно. Тому при виборі елементів нотації основним принципом був відбір значків, які добре виглядали б і були б правильно інтерпретовані в будь-якому випадку - будь вони намальовані олівцем на серветці або створені на комп'ютері і роздруковані на лазерному принтері.

Взагалі ж, у UML використовується чотири види елементів нотації: фігури, лінії, значки, написи. Фігури використовуються "плоскі" - прямокутники, еліпси, ромби і т. д. Але є один виняток - як ми побачимо далі, на діаграмі розгортання для позначення вузлів інфраструктури застосовується "тривимірне" зображення паралелепіпеда. Усередині будь-якої фігури можуть поміщатися інші елементи нотації.Про лінії варто сказати лише те, що своїми кінцями вони повинні з'єднуватися з фігурами. На UML діаграмах ви не зустрінете ліній, намальованих "самі по собі" і не з'єднують фігури. Застосовується два типи ліній - суцільна і пунктирна. Лінії можуть перетинатися, і хоча таких випадків слід по можливості уникати, в цьому немає нічого страшного.Взагалі ж варто сказати, що UML надає виняткову свободу - можна малювати що завгодно і як заманеться, аби можна було зрозуміти сенс створених діаграм. У зображенні фігур і значків теж немає якихось жорстких вимог, і розробники CASE-засобів для UML-проектування щосили використовують цю свободу, застосовуючи різні стилі малювання, заливку фігур кольором, тіні і т. д.

.До речі про інструменти малювання:до  найбільш помітних програм цього класу можна віднести:

IBM Rational;

Borland Together;

Gentleware Poseidon;

Microsoft Visio;

Telelogic TAU G2.

 

У рамках UML-моделі всі уявлення про систему фіксуються у вигляді спеціальних графічних конструкцій, що одержали назву діаграм

 

Види діаграм UML 1.5 визначив дванадцять типів діаграм, розділених на три групи:

чотири  типи діаграм представляють статичну структуру програми;

п'ять представляють  поведінкові аспекти системи;

три представляють фізичні аспекти  функціонування системи (діаграми реалізації).

Поточна версія UML 2.1 внесла не надто багато змін. Кількість типів діаграм для конкретної моделі конкретного додатка не є строго фіксованим. Для простих додатків немає необхідності будувати все без винятку діаграми. Важливо розуміти, що перелік діаграм залежить від специфіки розроблюваного проекту і визначається самим розробником.

Існують такі види діаграм:

діаграма прецедентів;

діаграма класів;

діаграма  об'єктів;

діаграма  послідовностей;

діаграма  взаємодії;

діаграма  станів;

діаграма  активності;

діаграма розгортання.

Діаграма прецедентів (use case diagram).Будь-які (у тому числі і програмні) системи проектуються з урахуванням того, що в процесі своєї роботи вони будуть використовуватися людьми та / або взаємодіяти з іншими системами. Сутності, з якими взаємодіє система в процесі своєї роботи, називаються Ектора, причому кожен Ектор очікує, що система буде вести себе строго певним, передбачуваним чином. Спробуємо дати більш суворе визначення Ектора.Ектор (actor) - це безліч логічно пов'язаних ролей, виконуваних при взаємодії з прецедентами або сутностями (система, підсистема або клас). Ектором може бути людина або інша система, підсистема або клас, які представляють щось поза сутності.Графічно Ектор зображується або «чоловічком» або символом класу з відповідним стереотипом.

Прецедент (use-case) - опис окремого аспекту поведінки системи з точки зору користувача (Буч).Це формулювання можна розширити: Прецедент (use case) - опис безлічі послідовних подій (включаючи варіанти), виконуваних системою, які призводять до спостережуваного Ектором результату. Прецедент являє поведінку сутності, описуючи взаємодію між Ектора і системою. Прецедент не показує, "як" досягається певний результат, а тільки "що" саме виконується.Прецеденти позначаються дуже простим чином - у вигляді еліпса, всередині якого зазначено його назву. Прецеденти і Ектора з'єднуються за допомогою ліній. Часто на одному з кінців лінії зображують стрілку, причому спрямована вона до того, у кого запитують сервіс, іншими словами, чиїми послугами користуються. Іноді на діаграмах прецедентів межі системи позначають прямокутником, у верхній частині якого може бути зазначено назву системи. Таким чином, прецеденти - дії, що виконуються системою у відповідь на дії Ектора, - поміщаються усередині прямокутника.Діаграми прецедентів відносяться до тієї групи діаграм, які представляють динамічні або поведінкові аспекти системи. Це відмінний засіб для досягнення взаєморозуміння між розробниками, експертами та кінцевими користувачами продукту.

 

Діаграма класів (class diagram). Класики про поняття класи говорять дуже просто і зрозуміло:Клас (class) - категорія речей, які мають спільні атрибути і операції. Продовжуючи тему, скажімо, що класи - це будівельні блоки будь об'єктно-орієнтованої системи. Вони являють собою опис сукупності об'єктів із загальними атрибутами, операціями, відносинами і семантикою. При проектуванні об'єктно-орієнтованих систем діаграми класів обов'язкові.Класи використовуються в процесі аналізу предметної області для складання словника предметної області розробляється. Це можуть бути як абстрактні поняття предметної області, так і класи, на які спирається розробка та які описують програмні або апаратні сутності.Діаграма класів - це набір статичних, декларативних елементів моделі. Діаграми класів можуть застосовуватися і при прямому проектуванні, тобто в процесі розробки нової системи, і при зворотному проектуванні - описі існуючих і використовуваних систем. Інформація з діаграми класів безпосередньо відображається у вихідний код програми - в більшості існуючих інструментів UML-моделювання можлива кодогенерацію для певної мови програмування (зазвичай Java або C + +). Таким чином, діаграма класів - кінцевий результат проектування і відправна точка процесу розробки..

Як клас зображується на діаграмі UML? .Клас на діаграмі зображується у вигляді прямокутника, розділеного горизонтальними лініями на три частини. У першій частині вказується назва класу. Як правило, ім'я класу складається з одного, максимум двох слів. Друга частина містить перелік атрибутів класу, які характеризують той чи інший об'єкт цього класу в моделі предметної області. Третя частина містить перелік операцій, що відображають його поведінку в моделі предметної області.А що всередині? Користувачеві про це знати необов'язково, більше того, абсолютно не потрібно. Для людини, що використовує його, об'єкт виступає в ролі чорного ящика. Приховуючи від користувача внутрішній устрій об'єкта, ми забезпечуємо його надійну роботу.. Якщо атрибут або операція описані з модифікатором private, то доступ до них можна отримати тільки з операції, визначеної в тому ж класі. Якщо ж атрибут або операція описані з модифікатором видимості public, то до них можна отримати доступ з будь-якої частини програми. Модифікатор protected дозволяє доступ тільки з операцій цього ж класу і класів, створюваних на його основі. У UML атрибути та операції з модифікаторами доступу позначаються спеціальними символами зліва від їх імен:Символ Значення+ Public - відкритий доступ- Private - тільки з операцій того ж класу# Protected - лише з операцій цього ж класу і класів, створюваних на його .

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

 

Отже, поговоримо про вимоги. Що це таке, ми, загалом, розуміємо - коли замовник описує нам, чого ж саме він хоче, ми завжди чуємо фрази типу "хотілося б, щоб перевірка оновлень проводилася автоматично, як в антивірусах", "хочу велику зелену кнопку в центрі вікна , яка починає процес "," програма повинна дозволяти переглядати і друкувати звіти "," і щоб гарненько все було, з напівпрозорими, як у Вісті "," при виході має виводитися підтвердження "і т. д. і т. п. Ці фрази описують, як замовник уявляє собі систему, чого замовник хоче від системи, функціональність, якої він від неї чекає, вимоги, які до неї пред'являє.Якщо звернутися до класиків, наприклад, до "банді трьох" (Якобсон, Буч, Рамбо), ми дізнаємося, що вимога - це бажана функціональність, властивість або поведінку системи. Саме зі збору вимог починається процес розробки ПЗ. Якщо зобразити процес розробки ПЗ у вигляді "чорної скриньки", на виході якого ми отримуємо програмний продукт, то на вхід цього "чорного ящика" подаватиметься саме набір вимог до програмного продукту.В радянські часи цей набір вимог називався технічним завданням. І от поступово технічне завдання поступилося місцем набору артефактів, що складається з документів двох видів:

діаграми прецедентів;

нефункціональні вимоги.

Діаграми прецедентів складають  модель прецедентів (варіантів використання, use-cases).

.Нефункціональні вимоги - це опис  таких властивостей системи, як  особливості середовища та реалізації, продуктивність, розширюваність, надійність  і т. д.

 Часто нефункціональні вимоги  не прив'язані до конкретного варіанту використання і тому виносяться в окремий список додаткових вимог до системи.

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

Визначення дійових осіб.

Визначення прецедентів.

Складання опису кожного прецеденту.

Опис моделі прецедентів в цілому (цей етап включає в себе створення словника предметної області).

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

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

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