Аналіз і проектування інформаційної системи, Інженерія програмного забезпечення, ЧНУ ім. Хмельницького

2. Аналіз і проектування інформаційної системи

2.1 Моделювання предметної області

Модель предметної області – це візуальне подання концептуальних класів або об'єктів реального світу в термінах предметної області, а не програмні компоненти. Такі моделі також називають концептуальними моделями, моделями об'єктів предметної області, або об'єктними моделями аналізу. Це свого роду словник основних абстракцій, тобто найважливіших іменників у просторі задачі. Іменники, які описують поняття з предметної області, називають доменними об'єктами. На самому початку аналізу і проектування необхідно створити модель предметної області, в якій всі доменні об'єкти будуть зображені на одній великій діаграмі класів [4, підрозділ 10].

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

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

2.2 Формування та аналіз вимог до об’єкту проектування

Для найефективнішого виконання поставленого завдання студент вибирає та обґрунтовує свій вибір між структурно-орієнтованою та об’єктно-орієнтованою технологією проектування інформаційної системи (ІС).

При виборі об’єктно-орієнтованої технології рекомендується процес проектування будувати відповідно до спіральної моделі, яка передбачає етапи аналізу, проектування, конструювання (кодування), тестування ІС.

Етап формування та аналізу передбачає виконання (розділ 10) [4]:

1. Формування та аналіз вимог (розділ 10.2).

1.1. Формування вимог.

1.2. Аналіз вимог.

2. Об’єктний аналіз вимог інформаційної системи (розділ 10.3-10.6).

2.1. Формування вимог за допомогою діаграми прецедентів (розділ 10.3).

2.2. Формування та аналіз вимог за допомогою діаграми діяльності (розділ 10.5).

2.3. Аналіз вимог за допомогою діаграми послідовності (розділ 10.6).

2.4. Аналіз вимог за допомогою діаграми комунікації (розділ 10.6).

3. Визначення поведінки об’єктів інформаційної системи (розділ 10.7).

Другий розділ(20-25 сторінок) є розділом аналізу об’єкта проектування. Структурно розділ може об’єднувати 3-5 підрозділів. Характер та зміст цього розділу повинен базуватися на результатах аналізу, наведеного у першому розділі роботи. Розділ закінчується висновками обсягом 0,5-1 с.

2.2.1 Формування та аналіз вимог

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

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

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

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

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

Формування вимог є лише початковою фазою роботи з вимогами.

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

Реалізація процедур цього етапу проектування відбувається в процесі побудови відповідних діаграм мовою UML або іншими мовами, що використовуються системами автоматизованого проектування. Результати процедур із формування та аналізу вимог оформляються у вигляді діаграми прецедентів (варіантів використання, Use Case), діаграми діяльності, діаграми взаємодій (діаграми послідовностей і комунікації ) та їх описів.

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

Детальніше з особливостями використання процесів побудови діаграм прецедентів, діаграм діяльності та діаграм взаємодій (у формі діаграм послідовностей і комунікації) для реалізації етапу формування та аналізу вимог об’єктно-орієнтованої технології проектування інформаційних систем необхідно ознайомитись з посібником з проектування ІС [4].

2.2.2 Формування вимог за допомогою діаграми прецедентів

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

У цьому розділі необхідно розглянути основне питання, яке необхідно задати на початку розробки будь-якої системи: «Що хочуть її користувачі?». Тут необхідно якомога докладніше уявити дії користувачів і реакцію системи, оскільки її поведінка зумовлена їхніми вимогами. Іншими словами, робота системи залежить від того, як до неї звертаються і чого хочуть досягти.

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

Основна ідея в дослідженні і формуванні функціональних вимог полягає в написання історій «з життя системи». Ці історії допомагають сформулювати різні задачі і являють собою сценарії використання системи – це спеціальна послідовність дій або взаємодій між виконавцями і системою.

У процесі опису сценаріїв необхідно задавати питання: «Хто є користувачем системи? Які типові сценарії використання системи? Які цілі і задачі користувачів?». Такий погляд на систему набагато більше орієнтований на користувача, ніж на звичайний список системних вимог, і дозволяє отримати відмінне візуальне уявлення про вимоги користувачів.

До складу діаграм варіантів використання входять елементи Use Case, актори, а також відносини залежності, узагальнення та асоціації. Як і інші діаграми, діаграми Use Case можуть включати примітки і обмеження.

2.2.3 Формування та аналіз вимог за допомогою діаграми діяльності

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

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

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

2.2.4 Аналіз вимог за допомогою діаграми послідовності

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

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

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

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

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

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

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

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

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

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

Діаграми послідовності вважають найпопулярнішим засобом представлення детальних вимог на етапі аналізу. Вихідними даними для їх створення є словесні описи вимог замовника, що містяться в специфікаціях елементів Use Case (сценаріях). Ці описи і перетворюються в діаграми послідовності. Мета перетворення – підвищити рівень точності, формалізувати вимоги, привести їх до виду, необхідною для розв’язання задач проектування.

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

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

Розділ тексту має закінчуватися Висновками до розділу (не більш 1-2 сторінки). Розмір одного висновку приблизно – один абзац (5-7 рядків). Висновки цього розділу є важливою і значущою частиною роботи.

2.3 Об’єктно-орієнтоване проектування ІС

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

 Проектна частина пояснювальної записки (20-25 сторінок) повинна містити опис процесів проектування інформаційної системи відповідно до її призначення. При застосуванні технологій об’єктно-орієнтованого проектування процес складається з таких етапів:

1. Архітектурне проектування – описує логічну структуру ІС (програмні класи, підсистеми, пакети) та їх зв’язки.

1.1. Діаграми пакетів.

1.2. Діаграми компонентів.

2. Детальне проектування – описує структури даних та алгоритмів всередині окремих класів.

3. Розгортання програмної системи на апаратних засобах – розподіл елементів (результатів розробки) програмного додатку за апаратними вузлами комп'ютерної системи.

2.3.1 Архітектурне проектування

Формування архітектури – перший і основний крок у розв’язанні завдання проектування, що закладає фундамент уявлення програмної системи, здатної виконувати весь спектр детальних вимог.

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

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

Етап архітектурного проектування ІС повинен бути відображений шляхом опису процесу об’єктно-орієнтованої декомпозиції системи до рівня переліку підсистем та їх зв’язків, опису її логічної структури у вигляді пакетів (діаграма пакетів UML) та компонентів (діаграма компонентів UML) [4].

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

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

Діаграма пакетів – це структурна діаграма, в якій основними елементами є пакети і залежності між ними.

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

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

Діаграми пакетів зручні у великих за розмірами системах для подання картини залежностей між основними елементами системи.

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

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

2.3.2 Детальне проектування

Попередні етапи проектування забезпечили аналіз об’єкта проектування (формування та аналіз вимог, ідентифікація об’єктів та їхньої поведінки) та архітектурне проектування (визначення логічної структури ІС).

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

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

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

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

Як відомо, класи можуть застосовуватись на етапі аналізу для складання переліку об’єктів (глосарію системи) або для аналізу предметної області. Але ці класи повинні бути деталізовані до одного або кількох проектних класів на етапі детального проектування. Ця потреба викликана відсутністю у класів на етапі аналізу повного набору атрибутів. А набір операцій – це тільки ескіз, що відображає ключові сервіси, які запропоновані класом.

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

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

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

2.3.3 Розгортання програмної системи на апаратних засобах

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

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

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

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

Розподіл елементів (результатів розробки) програмного додатку за апаратними вузлами комп'ютерної системи зручно показати за допомогою діаграм розгортання (у російській (українській) літературі їх називають також діаграмами розміщення) та діаграм компонентів [4, підрозділи 11.3, 17.3].

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

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

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

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

Розділ тексту має закінчуватися Висновками до розділу (не більш 1-2 сторінки). Розмір одного висновку приблизно – один абзац (5-7 рядків). Висновки цього розділу є важливою і значущою частиною роботи.

2.4 Моделювання поведінки системи

При створенні програмної системи недостатньо відповісти на питання що робить система? і з чого вона складається? – потрібно відповісти на питання як працює система?. Відповідь на це питання дає модель поведінки. Поведінка реальної програми цілком і повністю визначається її кодом – як програма складена, так вона і виконується. Але програма – це просто запис алгоритму. Таким чином, модель поведінки (behavior model) – це опис алгоритму роботи системи [4, розділи 12, 18].

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

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

Кінцевий автомат орієнтований на представлення поведінки окремого об'єкта. Як і діаграми видів діяльності, діаграми кінцевих автоматів (станів) UML відображають динамічну модель системи. З їх допомогою ілюструються події і стани об’єктів – транзакцій, прецедентів, людей тощо.

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

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

2.4.1 Діаграма кінцевого автомату

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

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

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

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

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

2.4.2 Діаграми діяльності

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

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

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

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

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

З одного боку, діаграми діяльності – загальний та потужний засіб опису алгоритмів. Діаграми діяльності з успіхом також можна застосовувати для моделювання поведінки людей, пристроїв і організацій при виконанні бізнес-процесів.

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

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

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

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

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

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

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

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

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

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

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

З повагою ІЦ "KURSOVIKS"!