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

5.2.3. Моделювання взаємодії обєктів


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

Кожен об’єкт у системі має три характеристики:

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

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

— індивідуальність — кожен об’єкт унікальний, навіть якщо його стан ідентичний стану іншого об’єкта.

Гарним способом виявлення деяких об’єктів є вивчення іменників у потоці подій при читанні документів, що описують конкретні сценарії. Сценарієм називають елемент прецеденту, що являє собою один прохід по потоку подій. У кожного потоку подій є кілька сценаріїв, кожен з яких відображається однією з діаграм взаємодії (Interaction diagram) — діаграмою послідовності (Sequence diagrams) або кооперативною діаграмою (діаграма кооперації, діаграма співпраці, діаграма взаємодії, Collaboration diagrams). Деякі з іменників сценарію будуть акторами, інші — об’єктами, а деякі — атрибутами об’єктів. Відмінність між останніми полягає в наявності у об’єкта поведінки.

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

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

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

Діаграми взаємодії містять такі елементи (рис. 5.4, 5.5):

— об’єкти — можуть вказуватись імена як об’єктів, так і класів, або і тих, і інших;

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

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

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

 

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

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

Крім назви, у середовищі IBM Rational Rose для всіх об’єктів можуть бути вказані кілька характеристик:

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

— стійкість його існування (Persistence). Стійкий (Persistent) об’єкт зберігається в базі даних або іншим способом, що забезпечує постійне зберігання, таким чином об’єкт існує навіть після припинення роботи програми. Статичний (Static) об’єкт зберігається у пам’яті комп’ютера протягом роботи програми, зокрема продовжує існувати після виконання показаних на діаграмі дій, але припиняє існування після завершення програми. Тимчасовий (Transient) об’єкт зберігається у пам’яті лише під час виконання процесів, визначених діаграмою послідовності. При цьому тривалість життя об’єкта має відповідати тривалості життя класу: для об’єктів стійкого класу тривалість життя може бути довільною, а для об’єктів тимчасових класів вказується статична або тимчасова стійкість;

— наявність кількох екземплярів (Multiple Instances).

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

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

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

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

У середовищі IBM Rational Rose для повідомлень встановлюють синхронізацію (Synchronization):

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

— Synchronous — синхронне — клієнт надсилає повідомлення і очікує на відповідь сервера;

— Balking — з відмовою ставати в чергу — клієнт надсилає повідомлення серверу, якщо той не може негайно прийняти повідомлення, воно відміняється;

— Timeout — з лімітованим часом очікування — клієнт надсилає повідомлення і очікує на відповідь сервера впродовж указаного часу. Якщо сервер не приймає повідомлення упродовж заданого періоду, воно відміняється;

— Asynchronous — асинхронне — клієнт надсилає повідомлення серверу і продовжує свою роботу, не очікуючи на відповідь.

Окремо позначаються повідомлення, що надходять у відповідь (Return):          .

Також можна зазначити частоту повідомлення (Frequency):

— Periodic — періодичне — повідомлення регулярно надсилається через певні проміжки часу;

— Aperiodic — аперіодичне — повідомлення надсилається нерегулярно.

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

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

Кооперативна діаграма

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

В IBМ Rational Rose перед розміщенням повідомлення на кооперативній діаграмі слід встановити шлях комунікацій між об’єктами — зв’язок (Link). Після цього між об’єктами можна розмістити повідомлення зв’язку (Link Message) або повідомлення зворотного зв’язку (Reverse Link Message) . Якщо необхідно подати рефлексивне повідомлення, то створюється зв’язок з собою (Link to Self) , а потім — повідомлення зв’язку.

Для зв’язків вказується ім’я, асоціація та параметри видимості (Supplier visibility, Client visibility), що зазначають, чи є об’єкт видимим для іншого об’єкта (постачальника/клієнта), зокрема:

— Field — поле — об’єкт-постачальник є частиною об’єктаклієнта. Позначається символом "F" на відповідному кінці зв’язку;

— Parameter — параметр — об’єктпостачальник є параметом для деяких операцій об’єктаклієнта. Позначається символом "P" на відповідному кінці зв’язку;

— Local Supplier — локальний постачальник — локально задекларований об’єкт у масштабі об’єктної діаграми. Позначається символом "L"  на відповідному кінці зв’язку;

— Global Supplier — глобальний постачальник — об’єкт є глобальним відносно клієнта. Позначається символом "G" на відповідному кінці зв’язку;

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

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

За потреби подання на діаграмі взаємодії додаткової інформації у середовищі IBM Rational Rose можна додавати примітки і програмні сценарії (скрипти).

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

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

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

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

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

 

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

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

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