< Попередня  Змiст  Наступна >

5.2.2. Функціональне моделювання


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

Інструментом функціонального моделювання в IBM Rational Rose є діаграми варіантів використання (діаграми прецедентів, Use case diagrams, рис. 5.3), що містять прецеденти, акторів та відношення між ними.

Діаграма прецедентів. Ліворуч — панель інструментів діаграми прецедентів IBM Rational Rose

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

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

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

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

При визначенні прецедентів часто виникають проблеми, пов’язані з вибором рівня їх деталізації. Рекомендацією є включення до окремого прецеденту окремого елемента функціональності, що здійснюється від початку до кінця і приносить значущий для актора результат. Водночас різні дії, що ініціюються одним актором і виконуються з однією сутністю, наприклад, введення, коригування та знищення даних у певному довіднику, також доцільно об’єднати в один прецедент. Модель типової системи зазвичай містить від 20 до 50 прецедентів.

В IBM Rational Rose варіантам використання можуть бути присвоєні пріоритети (ранги), що визначатимуть порядок, у якому слід працювати над ними.

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

Актор (діюча особа) — це зовнішня стосовно ІС сутність, яка може взаємодіяти з системою. Акторами можуть бути люди, зовнішні ІС або пристрої. При цьому актор — це не конкретна особа чи пристрій, а логічно пов’язана між собою множина ролей, що їх відіграють користувачі прецедентів під час взаємодії з ними. Наприклад, як актор «Бухгалтер» може виступати весь штат бухгалтерії. Водночас одна особа може відігравати кілька ролей стосовно системи. Головний бухгалтер може виступати як актор з таким іменем, але може використовувати систему і як актор «бухгалтер». Кожен актор може використовувати систему порізному, тобто ініціювати виконання різних прецедентів.

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

У загальному випадку як актор визначається кожне джерело зовнішніх подій, з якими має взаємодіяти система. Кожен актор повинен мати ім’я, яке відображає його роль. Також модель має містити специфікацію кожного актора, в якій вказується його роль під час взаємодії з системою, стереотип, кількість екземплярів (Multiplicity), чи є він абстрактним (див. далі пояснення для відношення узагальнення) та інші деталі. Слід зазначити, що вікна специфікації актора і класу в IBM Rational Rose схожі між собою, вони містять однакові поля, але при специфікації актора деякі з них заблоковані. Поясненням є те, що у середовищі IBM Rational Rose актор розглядається як особлива форма класу.

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

Стандартним графічним позначенням актора є фігурка «людини», під якою записується його ім’я. 

Для організації прецедентів їх групують у пакети                   .

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

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

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

— стереотип (Stereotype) — communicate (спілкується), extend (розширює), include (включає), realize (реалізує), subscribe (приєднується). Стереотип communicate, власне є надлишковим, оскільки комунікативна асоціація — єдиний припустимий тип зв’язку між актором і прецедентом. Інші стереотипи реалізуються через відношення залежності (див. далі);

— роль (Role A, Role В) — позначення ролі назвою, що визначає мету або ємність, при цьому елемент (Element A, Element В) показує клас, до якого належить роль;

— виведення (Derived) — елемент виводиться (обчислюється);

— елемент зв’язку (Link Element) — приписані асоціації;

— назва напряму (Name Direction) — напрям до ролі;

— обмеження (Constraints) — вирази деяких семантичних умов, що їх слід дотримуватися, поки система перебуває у стабільному стані. На закладках Detail і Detail A (Detail В) вказуються обмеження, що стосуються зв’язку загалом або окремої ролі;

— контроль експорту (Export Control) — наскільки клас та його елементи є видимими поза пакетом, в якому вони визначені;

— документація (Documentation) — опис елементів моделі або зв’язків;

— кількість елементів (Cardinality);

— напрям (Navigable) — в якому напрямі відбувається переміщення по зв’язку;

— агрегація (Aggregate) — установка напряму до всіх/частини екземплярів класів. Тільки один кінець зв’язку може бути агрегований;

— статичний (Static) — класклієнт асоційований (володіє) класомпостачальником;

— друг (Friend) — класпостачальник передає права класуклієнту для доступу до його непублічних частин;

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

— ключ/визначник (Key/Qualifier) — атрибут, який унікально ідентифікує єдиний цільовий об’єкт і зменшує кількість екземплярів.

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

Відношення «включає» (include) — це різновид відношення залежності між базовим прецедентом і його окремим випадком, коли зміна одного елемента (незалежного) призводить до зміни іншого (залежного). Відношення включення встановлюється лише між прецедентами і показує, що задана поведінка одного варіанта використання завжди включається до послідовності іншого прецеденту. Наприклад, таке відношення можна встановити між прецедентом «Видача кредиту» і прецедентом «Перевірка кредитоспроможності клієнта». У загальному випадку виокремлення прецедентів, що включаються, доцільне в разі їх входження до кількох базових прецедентів. Один варіант використання може входити до кількох інших прецедентів і, своєю чергою, містити інші варіанти використання. Базовий варіант використання залежить лише від результатів виконання прецеденту, що включається.

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

Відношення «розширює» («доповнює», extend) є різновидом відношення залежності і визначає взаємозв’язок базового прецеденту з іншим, функціональність якого залучається не завжди, а лише при настанні додаткових умов. Відношення розширення застосовується для відображення додаткових режимів; режимів, що запускаються лише при настанні певних умов, наприклад, в разі припущення помилки; альтернативних потоків, що запускаються за вибором актора. Таке відношення передбачає перевірку виконання певної умови і посилання на точку розширення у базовому прецеденті, в яку передається результат виконання розширення. При цьому один прецедент може бути розширенням для кількох базових і розширятися іншими прецедентами. Базовий варіант використання не залежить від своїх розширень.

На діаграмі відношення «розширює» подається як пунктирна стрілка, спрямована від прецедентурозширення до базового прецеденту з зазначенням стереотипу <>. Відношення узагальнення може встановлюватись і між акторами, і між прецедентами. Відношення узагальнення діючих осіб показує, що у них є спільність рис і ролей. Наприклад, серед клієнтів банку можуть бути юридичні особи і фізичні особи. Для відображення такого зв’язку створюється три актори — «Клієнт», «Юридична особа», «Фізична особа». Останні два з них є конкретними акторами і наповнюються безпосередньо. Актор «Клієнт» є абстрактним, він не має екземплярів, його множинність дорівнює 0. За необхідності розгалуження можна збільшити, але в загальному випадку зв’язки цього типу потрібні лише тоді, коли поведінка одного актора відрізняється від поведінки іншого настільки, що це впливає на систему. Наприклад, клієнтиюридичні особи ініціюють виконання прецедентів, що не запускаються для клієнтівфізичних осіб. Якщо таких відмінностей немає, узагальнення не потрібне.

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

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

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

Для зв’язків залежності передбачено стереотипи derive (виводить), extend (розширює), include (включає), owner (власник), refine (деталізує).

Правила складання діаграм прецедентів:

— не моделюйте зв’язки між акторами. За визначенням актори перебувають поза межами сфери дії системи. Таким чином, зв’язки між ними також не стосуються проектованої системи. Для вивчення комунікацій між акторами використовують діаграми потоків робіт (workflow diagram). Виняток становлять відношення узагальнення з абстрактним актором;

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

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

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

У середовищі IBM Rational Rose до діаграми прецедентів можна прикріпити файл або адресу ресурсу Інтернету. Таким чином можна, наприклад, зв’язати з діаграмою будьякий допоміжний документ, зокрема специфікації вимог високого рівня, документи концептуального характеру або план проекту. Так, можна послатися на огляд системи і специфікації прецедентів, створені за допомогою IBM Rational RequisitePro (див. п. 3.5). Усі пов’язані файли і посилання показуються у вікні браузера під відповідною діаграмою.

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


< Попередня  Змiст  Наступна >
Iншi роздiли:
5.2.4. Логічна модель системи
Тема 5. АВТОМАТИЗАЦІЯ ОБ’ЄКТНО ОРІЄНТОВАНОГО ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
4.4. АВТОМАТИЗАЦІЯ ПРОТОТИПУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ
4.3. ПІДТРИМКА ПРОЕКТУВАННЯ НА ОСНОВІ ІНТЕЛЕКТУАЛЬНОГО РЕПОЗИТОРІЮ
4.2. АВТОМАТИЗОВАНА ПІДТРИМКА ГРУПОВОГО ПРОЕКТУВАННЯ
Тема 4. АВТОМАТИЗОВАНА ПІДТРИМКА ПРИЙНЯТТЯ ПРОЕКТНИХ РІШЕНЬ
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki