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

1.

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

2.

Моделювання підсистем та
частин систем
Зміст
1. Логічна архітектура
2. Рівень представлення, бізнес-рівень та рівень даних
3. Сервіси та рівні. Рівні і розділи
4. Етапи проектування багаторівневої структури
5. Пакети.
6. Компоненти.
7. Системи та підсистеми.
8. Композитні структурні діаграми.
9. Події та сигнали.
10. Види подій.
11. Події виклику.
12. Події часу та змін.
13. Передача і отримання подій.
14. Моделювання сімейства сигналів.
15. Моделювання аварійних ситуацій.
2

3.

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

4.

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

5.

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

6.

Сервіси та рівні
Рівні і розділи.
Архітектурні рівні представляють ділення системи по вертикалі, а
розділи – по горизонталі на паралельні підсистеми в рамках
одного рівня.
Наприклад, рівень служб можна розділити на розділи, які
відповідають за виконання вимог безпеки і формування звітів.
Більшість систем спирається на зовнішні ресурси чи служби, такі
як бази даних.
В логічному представлені архітектури можна використовувати не
тільки рівні, але і фізичні реалізації компонентів.
В термінах логічного представлення архітектури доступ до
конкретної бази даних відображається як пакет рівня предметної
галузі. При цьому для доступу до бази даних можна
використовувати пакет Persistence (Сховище) розділу технічних
служб.
6

7.

Етапи проектування
багаторівневої структури
Зазвичай при проектуванні використовується наступна
послідовність кроків:
Крок 1 – Вибір стратегії поділу на рівні
Крок 2 – Вибір необхідних рівнів
Крок 3 – Ухвалення рішення про розподіл рівнів і компонентів
Крок 4 – З'ясування можливості згортання рівнів
Крок 5 – Визначення правил взаємодії між рівнями
Крок 6 – Визначення наскрізної функціональності
Крок 7 – Визначення інтерфейсів між рівнями
Крок 8 – Вибір стратегії розгортання
Крок 9 – Вибір протоколів зв'язку
7

8.

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

9.

Компоненти
Компонент – це логічна частина системи, що заміщається, яка відповідає певному
набору інтерфейсів і забезпечує їх реалізацію.
Порт – спецефічне “вікно” в інкапсульований компонент, що приймає повідомлення
для компонента і від нього у відповідності до заданого інтерфейсу.
Внутрішня структура – реалізація компонента, яка представляється набором
частин, з’єднаних одна з одною конкретним способом.
Частина – специфікація ролі, яка складає частину реалізації компонента.
Конектор – зв'язок комунікації між двома частинами чи портами в контексті
компонента.
9

10.

Системи та підсистеми
Система (system), можливо декомпозіровать на ряд підсистем, - це безліч елементів,
організованих певним чином для виконання певної мети. Вона може бути охарактеризована
моделей, часто з різних точок зору.
Підсистема (subsystem) - це об'єднання елементів, ряд яких складає специфікацію поведінки
інших її елементів.
Система і підсистема зображаються у вигляді піктограми компонента зі стереотипом.
Модель (model) - це спрощення реальності, абстракція, створювана для кращого сприйняття
системи.
Подання (view) - це проекція моделі, що розглядається під певним кутом зору: в ній
відображені одні сутності і опущені інші, які з цієї точки зору не представляють інтересу.
10

11.

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

12.

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

13.

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

14.

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

15.

Події часу та змін
Подія часу представляє собою закінчення певного проміжку часу.
В UML така подія моделюється за допомогою ключового слова after.
Простий вираз: after 2 seconds. Складний вираз: after 1 ms since
exiting Idle (“через 1 мс після виходу зі стану Очікування”).
Для визначення кінця періоду використовується слово at наприклад:
at (1 Jan 2007, 1200 UT).
За допомогою події зміни описується зміна стану чи виконання
деякої умови.
15

16.

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

17.

Моделювання сімейства сигналів
У більшості систем, що управляються подіями, події сигналів
утворюють ієрархію
17

18.

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

19.

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

20.

Моделювання підсистем та
частин систем
Дякую за увагу!
20