5.1. ВІЗУАЛЬНЕ МОДЕЛЮВАННЯ ЯК ОБ’ЄКТ АВТОМАТИЗАЦІЇ
Як зазначалось у темі 1, спільною характеристикою сучасних підходів до проектування ІС є побудова візуальних моделей. Візуальне моделювання — це процес графічного подання моделі за допомогою стандартного набору графічних елементів. Модель як абстракція, що описує сутність проблеми або структури ІС без несуттєвих деталей, допомагає зрозуміти проблему всім учасникам проекту — замовнику, експерту, аналітику, проектувальнику, автору документації, програмісту, тестувальнику тощо — та обговорити її. Спілкування можна забезпечити і за допомогою текстової інформації, але візуальне подання системи значно спрощує цей процес і надає всім зацікавленим особам саме ту інформацію, котра їм потрібна. Моделювання також дає змогу точно оцінити потрібні ресурсі, розробити плани й забезпечити ефективне функціонування створюваної системи. Проектування системи передбачає поступове доповнення моделей для переходу до реалізації.
Моделі майбутньої ІС складаються із використанням загальноприйнятої системи позначень — нотації. Нині найповнішу нотацію, що розширяється при переході від аналізу до проектування, пропонує уніфікована мова моделювання UML (Unified Modeling Language).
UML є результатом консолідації методів, що ввійшли до її складу у 1993—1995 роках — Booch Граді Буча, ОМТ (Object Modeling Technique, методологія об’єктного моделювання) Джеймса Рамбо та OOSE (ObjectOriented Software Engineering, об’єктноорієнтований програмний інжиніринг) Айвара Якобсона. Зусилля зі стандартизації підтримали також провідні компанії з розробки програмного забезпечення (Microsoft, IBM, HewlettPackard, Oracle та ін).
Нині UML — це мова для визначення, подання, проектування і документування систем різного роду (програмних, організаційноекономічних, технічних тощо). UML містить стандартний набір різноманітних діаграм і нотацій. Це готова до використання потужна мова візуального моделювання для розробки моделей та обміну ними з можливостями розширення і спеціалізації, незалежна від конкретних мов програмування і процесів розробки. UML підтримується у CASEзасобах усіх великих компанійвиробників, провідною з яких є система IBM Rational Rose (див. п. 5.2).
UML створено для оптимізації процесу розробки програмних систем, його використання дає можливість багаторазово збільшити ефективність розробки і суттєво поліпшити якість кінцевого продукту. UML застосовують на всіх етапах аналізу бізнессистем і розробки додатків. За допомогою діаграм подаються як ділові, так і програмні системи. Згодом їх можна перевести у програмний код. Діаграми полегшують супроводжуваність проекту і документування.
UML застосовується:
— керівниками проектів під час управління розподілом задач і контролю за їх виконанням;
— проектувальниками при розробці технічних завдань для програмістів;
— бізнесаналітиками, які досліджують реальну систему і проводять інжиніринг і реінжиніринг бізнеспроцесів;
— програмістами, які реалізують модулі інформаційної системи.
Стандарт UML містить такий набір діаграм (рис. 5.1):
1) структурні моделі (structural):
— діаграми класів (class diagrams) — для моделювання статичної структури класів системи і зв’язків між ними. На цих діаграмах зображуються також атрибути класів, операції класів та обмеження, що накладаються на зв’язки між класами. Вид та інтерпретація діаграми класів можуть суттєво варіювати — класи можна подавати як сутності предметної області в процесі аналізу, так і елементи програмної системи під час проектування та реалізації;
— діаграми компонентів (component diagrams) — для моделювання ієрархії компонентів програмного забезпечення і зв’язків між ними. Як правило, показують два типи компонентів: виконувані компоненти і бібліотеки коду. Кожен клас моделі перетворюється на компонент початкового коду. Між окремими компонентами встановлюють залежності, що відповідають залежностям на етапі компіляції або виконання програми;
— діаграми розташування, топології (deployment diagrams) — для моделювання фізичної архітектури системи — фізичних взаємозв’язків між програмними та апаратними компонентами системи та розміщення їх у розподіленій системі. Основними елементами цієї діаграми є вузол мережі (обчислювальний ресурс) і з’єднання — канал взаємодії вузлів;
2) моделі поведінки (behavioral):
— діаграми варіантів використання, прецедентів (use case diagrams) — для моделювання функціональних вимог до системи у вигляді сценаріїв взаємодії користувачів з системою. Мета побудови таких діаграм — документування функціональних вимог в узагальненому вигляді, тому вони мають бути максимально спрощеними. Варіант використання — це послідовність дій (транзакцій), що виконуються системою у відповідь на подію, яка ініціюється певним зовнішнім об’єктом (діючою особою). Варіант використання описує типову взаємодію між користувачем і системою та відображає уявлення про поведінку системи з погляду користувача. У найпростішому випадку варіант використання визначається в процесі обговорення з користувачем тих функцій, які б він хотів мати реалізованими, або цілей, які він переслідує щодо майбутньої системи.
Діаграма варіантів використання є найбільш загальним поданням функціональних вимог до системи. Для подальшого проектування потрібні більш конкретні деталі, які описуються у документі «сценарій варіанта використання» («потік подій», flow of events). Сценарій докладно документує процес взаємодії діючої особи із системою, що реалізується у рамках варіанта використання. Основний потік подій описує нормальний перебіг подій (за відсутності помилок), а альтернативні — відхилення від нього (помилкові ситуації) та їх оброблення.
Переваги моделі варіантів використання: визначаються користувачі і межі системи, системний інтерфейс; зручна для спілкування користувачів з розробниками; використовується для написання тестів і користувацької документації; добре вписується у будьякі методи проектування (як об’єктноорієнтовані, так і структурні);
— діаграми взаємодії (interaction diagrams) — діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams) — для моделювання процесу обміну повідомленнями між об’єктами.
Діаграми взаємодії описують поведінку взаємодіючих груп об’єктів (у рамках варіанта використання або певної операції класу). Як правило, діаграма взаємодії охоплює поведінку об’єктів у рамках лише одного потоку подій варіанта використання. На такій діаграмі відображається низка об’єктів і ті повідомлення, якими вони обмінюються між собою. Діаграми послідовності відображають часову послідовність подій, що відбуваються у рамках варіанта використання, а кооперативні діаграми концентрують увагу на зв’язках між об’єктами;
— діаграми станів (statechart diagrams) — для моделювання поведінки об’єктів системи при переході з одного стану в інший. Такі діаграми визначають усі можливі стани, в яких може перебувати конкретний об’єкт, а також процес зміни станів об’єкта в результаті настання певних подій. Діаграми станів не є обов’язковими для кожного класу, вони застосовуються тільки у складних випадках, наприклад якщо об’єкт класу може існувати в кількох станах і в кожному з них веде себе порізному;
— діаграми діяльності (activity diagrams) — для моделювання поведінки системи в рамках різних варіантів використання або потоків управління. У цих діаграмах реалізовано ідеї інших методів, зокрема метода моделювання станів SDL і мереж Петрі. Діаграми діяльності особливо корисні для опису поведінки, що містить велику кількість паралельних процесів. Ще одне популярне застосування — паралельне програмування, для якого можна графічно зобразити всі гілки і визначити, коли їх необхідно синхронізувати. Діаграми діяльності можна застосовувати для опису потоків подій у варіантах використання. Текстовий опис може докладно представити потік подій, але в складних і заплутаних потоках із багатьма альтернативними гілками важко зрозуміти логіку подій, тому перевагу віддають наочним діаграмам діяльності.
Як уже зазначалося, UML має механізми розширення, за допомогою яких мову можна адаптувати під конкретні вимоги, не змінюючи метамоделі. Це відрізняє UML від інших, сильно типізованих мов моделювання (IDEFO, IDEF1X, IDEF3, DFD, ERM), які не передбачають довільної інтерпретації семантики елементів моделей. UML є слабко типізованою мовою з такими механізмами розширення:
— стереотип — новий тип елемента моделі, який визначається на основі наявного елемента. Стереотипи розширюють нотацію моделі і можуть застосовуватися до будьяких елементів моційними базами даних на основі діаграми класів створюється фізична модель бази даних для зберігання даних об’єктів постійних класів. При цьому мають бути завершені всі рішення, пов’язані з побудовою об’єктноорієнтованої моделі програмної системи;
— на стадії реалізації за допомогою CASEзасобів створені моделі переводять у початковий код 3GL або 4GL мов програмування (C++, Java, Delphi, Power Builder, Visual Basic, Centura, Forte, Ada, Smalltalk та ін.) і генерують базу даних. Під час компіляції та збирання системи застосовують діаграми компонентів;
— на стадії тестування розроблені моделі стають підґрунтям для розробки сценаріїв тестування модулів і програми загалом. До того ж об’єктна модель системи сприяє уникненню несумісності окремих модулів, що зменшує кількість помилок і полегшує тестування в цілому;
— на стадії упровадження діаграми використовують як допоміжний засіб для супроводу проекту.
При створенні діаграм рекомендується дотримуватися таких правил:
— кожна діаграма має бути завершеним поданням певного фрагмента ІС, що моделюється, тобто містити всі сутності, важливі в контексту даної моделі і діаграми;
— усі сутності на діаграмі мають бути одного рівня подання, що передбачає узгодженість імен однакових елементів і вкладення окремих діаграм одна в одну для поступового уточнення або деталізації в разі моделювання складних систем;
— діаграма має містити всю інформацію про представлені на ній сутності. Хоча мова UML передбачає використання значень за умовчанням, наприклад у разі відсутності визначення видимості атрибутів та операцій класу, рекомендується чітка вказівка властивостей усіх елементів діаграм;
— діаграма не має містити суперечливої інформації, наприклад елементи з однаковими іменами і різними атрибутами властивостей в одному просторі імен, позаяк це призводить до проблем під час реалізації системи та використання її на практиці;
— кожна діаграма має бути самодостатньою для правильної інтерпретації всіх її елементів і розуміння семантики всіх використовуваних графічних символів. Водночас загальні фрагменти діаграм можуть уточнюватися або деталізовуватися на інших діаграмах того самого типу, утворюючи вкладені або підпорядковані діаграми;
— кількість типів діаграм для конкретної моделі не регламентується. Це залежить від складності системи і специфіки конкретного проекту;
— будьяка модель має містити лише елементи, що їх визначено в нотації UML. Механізми їх розширення застосовують лише за неможливості адекватного подання конкретної моделі за допомогою базових елементів. Елементи, що належать до базової нотації метамоделі мови UML, перевизначати забороняється.
CASEзасоби об’єктноорієнтованого аналізу і проектування з підтримкою UML контролюють побудову діаграм та внеможливлюють деякі помилки, наприклад неправильне використання графічних символів або неунікальні імена елементів. Однак недостатня формалізованість мови і неможливість загального контролю моделі по суті зумовлюють обмеженість такої автоматизованої підтримки.
