ТЕХНОЛОГІЯ ПРОГРАМУВАННЯ ТА СТВОРЕННЯ ПРОГРАМНИХ ПРОДУКТІВ

Візуальне моделювання на основі UML

Мета викладання

У цій лекції основна увага буде приділена розгляду мови об'єктного моделювання UML. Розкриті деякі сторони аналізу і проектування ПЗ. Розкритий об'єктно-орієнтований підхід при моделюванні за допомогою UML

Аналіз і проектування. Деякі окремі питання

Раніше, в попередніх лекціях неодноразово розглядалася типова схема вирішення завдань по розробці програмного забезпечення (ПЗ). При цьому особлива увага приділялася тому, що безпосереднє програмування або написання коду починається далеко не відразу. Більш того, етапи попередньої розробки не менш важливі і складні, ніж, так звана, основна робота. Зразкова схема, що відображає процес від постановки завдання до випуску готового продукту може виглядати так:

Рис. 8.1.

Або в укрупненому вигляді:

Рис. 8.2.

Пригадаємо суть об'єктного підходу.

Огляд принципів об'єктного підходу

Алгоритмічна і об'єктна декомпозиції. Класи і об'єкти

Принципово можна виділити 2 види розбиття предметної області на елементи, що становлять:

•Алгоритмічна декомпозиція (основні елементи програми - будівельні блоки - алгоритми).

•Об'єктна декомпозиція (основні елементи програми - види абстракцій (класи) і представники цих класів (об'єкти)).

Відповідно до алгоритмічної декомпозиції предметної області при аналізі завдання ми

намагаємося зрозуміти, які алгоритми необхідно розробити для її вирішення, які специфікації цих алгоритмів (вхід, вихід), і як ці алгоритми зв'язані один з одним. У мовах

3

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

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

На сьогоднішній день об'єктний підхід і його основи - об'єктна модель і об'єктна декомпозиція - підтримуються усіма сучасними об'єктно-орієнтованими мовами програмування (Object Pascal, C++, Java, C#.).

Складові частини об'єктного підходу

Розглянемо стисло складові частини об'єктного підходу, грамотне виконання яких, як правило, приводить до створення якісного програмного продукту.

Об'єктний підхід:

•OOA (object oriented analysis) - об'єктно-орієнтований аналіз.

•OOD (object oriented design) - об'єктно-орієнтоване проектування.

•OOP (object oriented programming) - об'єктно-орієнтоване програмування.

Що означають ці ключові поняття [1]:

Об'єктно-орієнтований аналіз - це методологія, при якій вимоги до системи

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

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

Об'єктно-орієнтоване програмування - це методологія програмування, заснована на представленні програми у вигляді сукупності об'єктів, кожен з яких є екземпляром певного класу, а класи утворюють ієрархію спадкоємства.

У російськомовній і україномовній літературі, як правило, під абревіатурою ООП розглядають всі 3 складових об'єктного підходу. Далі і ми слідуватимемо цьому принципу.

Курси з циклу "Методи програмування" і, конкретніше, "Об'єктно-орієнтоване програмування" переважно концентруються на OOP. Даний курс, принаймні, його теоретична частина основна увага приділяє OOA і OOD.

Принципи об'єктного підходу

Розглянемо найбільш важливі принципи об'єктного підходу.

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

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

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

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

4

Приклад: ООП і структури зберігання. Стек

Постановка завдання: Необхідно розробити структуру зберігання Стек. Примітки:

•Не враховувати необхідність перерозподілу пам'яті.

•Вважати, що елементи цілого типу. Аналіз і проектування.

Дані:

•MemSize - максимальна кількість елементів.

•DataCount - кількість елементів в стеку.

•pMem - покажчик на пам'ять для зберігання значень. Операції:

•IsFull - перевірка на повноту.

•IsEmpty - перевірка на порожнечу.

•Get - узяти елемент з вершини.

•Put - покласти елемент в стек.

Розглянемо модель і фінальний результат нашого проектування (використовується нотація UML):

Рис.8.3. Рис. 3.4.

Повторне використання

Ідея повторного використання.

Повторне використання - застосування вже існуючих напрацювань в тому, що розробляється ПЗ.

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

Девіз: не треба винаходити велосипед, якщо він вже винайдений.

Достоїнства повторного використання.

Достоїнства повторного використання (по Соммервілю [1]):

5

•Підвищення надійності.

•Зменшення проектних рисок.

•Ефективне використання фахівців.

•Дотримання стандартів (приклад: призначений для користувача інтерфейс).

•Прискорення розробки.

Повторне використання досягається за рахунок наступних прийомів (видів

використання):

•Компонентна розробка. Частина компонентів вже розроблені раніше, мають чітко описаний інтерфейс. Вони використовуються як "цегла" в новій системі.

•Використання патернів (шаблонів) проектування. Застосовуються відомі підходи до вирішення деяких проблем, що зустрічалися раніше.

•Використання стандартних прикладних (MKL, MFC) і системних (API) бібліотек.

Візуальне моделювання. Історія мови UML

При вивченні матеріалів по візуальному моделюванню і мові UML як основне джерело рекомендується класична книга [2]. Додатково рекомендується наступна книга: G.

Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004. Велика кількість матеріалів може бути знайдене на сайті www.uml.org.

Ідея візуального моделювання

Пригадаємо, в чому полягає основна проблема в розробці ПЗ – софтверні проекти не укладаються в терміни, бюджет, не задовольняють вимогам.

Як вирішувати цю проблему? На допомогу приходить моделювання. Під моделлю зазвичай розуміють спрощене представлення об'єктів і явищ реального миру.

Відповімо на питання, навіщо будують моделі: Моделі будують для того, щоб краще зрозуміти досліджувану систему.

Завдання моделювання [2]:

•Візуалізація системи в її деякому стані.

•Визначення структури і поведінки системи.

•Отримання шаблону для створення системи.

•Документування ухвалених рішень. Принципи моделювання [2]:

•Вибір моделі надає визначальний вплив на підхід до рішення проблеми і на те, як виглядатиме це рішення.

•Кожна модель може бути втілена з різним ступенем абстракції.

•Кращі моделі - ті, що ближче до реальності.

•Якнайкращий підхід при розробці складної системи - використовувати декілька майже незалежних моделей.

Як вже згадувалося раніше, одним з найбільш популярних підходів до моделювання є об'єктний підхід. Відповідно до цього підходу в результаті OOA і OOD ми отримуємо "хороший" проект програмної системи, що прозорий, такий, що задовольняє вимогам, зручний для тестування і відладки, колективної розробки, такий, що розвивається, допускає повторне використання компонентів.

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

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

•Візуалізація спрощує розуміння проекту в цілому.

6

•Візуалізація допомагає погоджувати термінологію і переконатися, що всі однаково розуміють терміни.

•Візуалізація робить обговорення конструктивним і зрозумілим.

Для візуального моделювання потрібна спеціальна нотація або мова.

UML (unified modeling language) - це мова для візуалізації, специфікації, конструювання, документування елементів програмних систем. UML - мова загального призначення, призначена для об'єктного моделювання.

Історія мови UML

До 1994 року існувало декілька нотацій для візуального відображення ухвалюваних проектних рішень і декілька методів аналізу і проектування. У 1994 році відбулася знакова подія - Grady Booch і James Rumbaugh, співробітники фірми Rational Software, об'єднали свої методи проектування і аналізу, створивши так званий Unified method. З цієї миті процес стандартизації домовленостей увійшов до робочого ритму. Приведемо важливі віхи цього шляху:

•1994: Grady Booch & James Rumbaugh (Rational Software) об'єднали методи Booch

(проектування) і OMT (аналіз) ->Unified method.

•1995: приєднався Ivar Jacobson (автор методу OOSE). Згодом група авторів Booch, Rumbaugh і Jacobson разом випустила не одну книгу, що стала бестселером (наприклад, див. список літератури). Цю трійцю жартівливо називали "Three amigos", натякаючи на те, як жарко вони сперечалися з приводу ухвалюваних рішень.

•1996 - Ідея про Unified Modeling Language (three amigos).

•1996 - створений консорціум UML Partners під керівництвом three amigos.

•Червень, Жовтень 1996 - UML 0.9 & UML 0.91.

•Січень 1997 - специфікації UML 1.0 запропоновані OMG (Object Management Group).

•Серпень 1997 - специфікації UML 1.1 запропоновані OMG.

•Листопад 1997 - UML 1.2 - результат адаптації OMG.

•Червень 1999 - UML 1.3.

•Вересень 2001 - UML 1.4.

•Березень 2003 - UML 1.5. Прийнятий стандарт:

•ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.

•Жовтень 2004 - UML 2.0.

Структура мови UML

Моделі UML

UML дозволяє описувати систему наступними моделями:

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

•Об'єктна модель (показує, як виглядає проект системи з погляду об'єктного підходу).

•Динамічна модель (показує, як взаємодіють один з одним компоненти системи в динаміці, з часом). Демонструє, які процеси відбуваються в системі.

Діаграми UML

Діаграми UML призначені для візуального відображення моделей і їх компонентів. UML 2.0 містить 13 типів діаграм. Зокрема:

•Структурні діаграми (6).

•Діаграми поведінки (3).

•Діаграми взаємодії (4).

Розглянемо кожну з груп докладніше.

Структурні діаграми:

•Діаграма класів - показує класи, їх атрибути і зв'язки між класами.

7

•Діаграма компонентів - показує компоненти і зв'язки між ними.

•Структурна діаграма - показує внутрішню структуру класів і зв'язку із зовнішнім світом.

•Діаграма розгортання - показує, як ПЗ розміщується на апаратурі (серверах, робочих станціях...).

•Діаграма об'єктів - показує структуру системи в конкретний момент часу, об'єкти, їх атрибути...

•Діаграма пакетів - показує, як система розкладається на крупні складові частини і зв'язки між цими частинами

Діаграми поведінки:

•Діаграма дії - показує потоки інформації в системі.

•Діаграма стану - є кінцевий автомат, що показує функціонування системи.

•Діаграма варіантів використання - показує роботу системи з погляду користувачів.

Діаграми взаємодії

•Діаграма кооперації - показує структурну організацію об'єктів, що беруть участь у взаємодії.

•Діаграма взаємодії (новація UML 2.0).

•Діаграма послідовності - показує тимчасову впорядкованість подій.

•Тимчасова діаграма - діаграма пов'язана з тимчасовими рамками проекту.

Поняття UML

Для опису структури: Актор, Атрибут, Клас, Компонент, Інтерфейс, Об'єкт, Пакет. Для опису поведінки: Дія, Подія, Повідомлення, Метод, Операція, Стан, Варіант

використання.

Для опису зв'язків: Агрегація, Асоціація, Композиція, Залежність, Спадкоємство. Деякі інші поняття: Стереотип, Множинність, Роль.

Учбовий приклад. Постановка завдання

Система бронювання квитків для авіакомпанії Короткий опис

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

При формулюванні вимог менеджери згадали, що рейси сплановані так, що до пункту призначення можна долетіти з пересадками. Одна з вимог полягала в тому, щоб система допомагала купувати квитки залежно від побажань користувача.

Аналіз постановки - повний опис

•Завдання є математичним. Система повинна уміти вирішувати однокритериальную задачу пошуку найкоротших шляхів на графах. Критерій - ціна.

•Система розподілена: оскільки в кожному аеропорту своя база напрямів польотів літаків, то знають про рейс тільки аеропорти-сусіди по рейсах.

Об'єкти системи: розподілене сховище рейсів, покупець квитків, менеджер рейсів.

•Розподілене сховище рейсів: назва рейсів, номери і вартість квитків.

•Покупець: ФІО, сума. Покупець задає параметри, пов'язані з сумою, яку він хоче витратити. Система повинна підібрати оптимальний маршрут. За відсутності прямих маршрутів система повинна спробувати знайти маршрути з пересадками. Якщо таких не знаходиться, система повинна сказати, що з такими обмеженнями не можна дістатися до місця призначення.

Серед причин:

•Відсутність рейсів в бажаному напрямі навіть з урахуванням пересадок.

8

•Брак грошей.

Увідповідь, користувач повинен мати можливість поміняти параметри з урахуванням передісторії.

Менеджер рейсів: повинен мати наступні можливості:

•створення і видалення аеропортів в системі.

•створення і видалення рейсів в аеропортах.

Візуальний опис функціональної моделі засобами UML

Актори і варіанти використання в UML

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

Рис. 3.5.

Актори і варіанти використання спілкуються за допомогою посилки повідомлень. Повідомлення можуть йти в обидві сторони. Стрілка показує ініціатора спілкування (актор на малюнку) і може бути опущена.

Рис. 3.6.

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

Перелік Варіантів використання для наший завдання може бути, наприклад, таким:

•Забронювати квиток.

•Підібрати рейс.

•Працювати з даними.

•Управляти рейсами.

•Працювати з БД аеропорту.

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

9

Рис. 3.7.

Приведемо деякі додаткові міркування:

•При такому моделюванні звертають увагу на поведінку системи, а не на її реалізацію.

•Хороша модель описує основну поведінку системи, не будучи дуже докладною.

•Подібна модель дозволяє перевірити, чи задовольнить система вимоги замовника.

•Система середніх розмірів може бути описана великою кількістю варіантів використання.

•Варіанти використання можуть описуватися різними сценаріями.

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

Діаграма дії це блок-схема, яка відображає динаміку в поведінці системи. Відмітимо, що ця діаграма може використовуватися не тільки для опису сценаріїв Варіанту використання.

Приведемо приклад відповідної діаграми для варіанту використання Бронювання квитків в системі SRS.

Рис. 3.8.

10

Структура системи і її опис засобами UML

У даному розділі розглядаються елементи UML, призначені для опису структури проектованої програмної системи. Наш виклад влаштований таким чином: для стандартних понять, відомих з курсу ООП, ми приводимо тільки позначення. Для інших перш за все даємо визначення і коротку характеристику. Отже, приступимо.

Класи

Рис. 3.9.

Позначення модифікаторів доступу:

Шаблони класів

Рис. 3.10.

Об'єкти

Рис. 3.11.

Інтерфейси

Визначимося з тим, що ми в даному випадку розуміємо під Інтерфейсом.

Інтерфейс визначає межу між специфікацією того, що робить абстракція, і реалізацією того, як вона це робить [3.3].

11

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

Сенс використання Інтерфейсу полягає у відділенні деталей реалізації від функціональності. Так, клас, підсистема, компонент зазвичай надають деяку функціональність, якою можуть користуватися інші класи, підсистеми, компоненти. Опис цій, доступною ззовні, функціональності міститься в Інтерфейсі.

У багатьох мовах програмування поняття Інтерфейс включено в об'єктну модель, що відповідно відбивається на синтаксисі (Object Pascal, Java і ін.). С++, на жаль, не містить поняття Інтерфейс, тому Інтерфейси моделюються за допомогою використання класів.

Рис. 3.12.

Пакети

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

Рис. 3.13.

Підсистеми

На етапі проектування системи класи і пакети можуть об'єднуватися в підсистеми. Підсистема - структурна одиниця. Кожна підсистема мають свою область відповідальності і реалізує деяку функціональність. Підсистема реалізує Інтерфейс, який описує її поведінку. У даному учбовому прикладі SRS прикладами підсистем є: підсистема бронювання квитків; підсистема доступу до даним...

Рис. 3.14.

12

Компоненти

Компонент - фізична замінювана частина системи, що сумісна з одним набором інтерфейсів і забезпечує реалізацію якого-небудь іншого [3.3]. Компонент може розроблятися і тестуватися незалежно від системи.

Види компонентів:

•Початкові файли (.cpp, .h, .java.).

•Бінарні файли (.dll, .ocx.).

•Виконувані файли (.exe).

По сенсу компонент є реалізацією підсистеми. На етапі проектування ми працюємо з підсистемами. На етапі реалізації - з компонентами.

Рис. 3.15.

Коментарі

UML передбачає можливість написання коментарів (заміток). Робиться це таким чином:

Рис. 3.16.

Відношення між елементами моделі

UML підтримує наступні види відносин між елементами моделі:

•Залежність.

•Асоціація.

•Узагальнення (спадкоємство).

•Реалізація (для Інтерфейсу).

Відносини показують наявність зв'язків між елементами моделі і семантику цих

зв'язків.

Розглянемо кожен з цих типів відносин.

Залежність

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

Рис. 3.17.

Асоціація

Асоціація - зв'язок між суттю (класами, об'єктами). Асоціація показує наявність структурного зв'язку між екземплярами (об'єктами). Структурний зв'язок реалізується через поле класу. У позначеннях UML напрям може бути не вказане (двосторонній зв'язок).

13

Рис. 3.18.

Напрям і навігація

Відмітимо, що наявність напряму пов'язана з поняттям Навігація. Навігація означає, що у напрямі стрілки один об'єкт "бачить" інший, тоді як зворотне не виконується.

Рис. 3.19.

Кратність

Кратність - спосіб конкретизації характеру відношення. Показує тип відношення 1:1,

1:M, N:1, N:M.

Рис. 3.20.

Окремі випадки асоціацій: агрегація і композиція

Агрегація припускає, що 0 або більш за об'єкти одного типу включені в 1 або більш за об'єкти іншого типу.

Композиція - варіант агрегації, в якому кожен об'єкт другого типу може бути включений рівно в 1 об'єкт першого типу.

14

Рис. 3.21.

Узагальнення (спадкоємство)

Рис. 3.22.

15