Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
examen.docx
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
235 Кб
Скачать
☆

Наведіть характеристику складових загальної структури мови uml.

Загальна структура мови UML складається з:

1. Семантика мови UML. Представляє метамодель, яка забезпечує найбільш абстрактний синтаксис ООП на мові UML.

2. Нотація мови UML. Графічна нотація для візуального представлення семантики мови UML.

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

Основні (канонічні) та спеціальні (допоміжні) діаграми uml.

Структурні діаграми:

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

Діаграми поведінки:

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

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

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

Семантика і нотація діаграм розгортання. Нарисуйте елементи нотації і наведіть їх інтерпретацію.

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

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

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

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

З системою актори взаємодіють через повідомлення, або, якщо, використовувати терміни use case моделювання, то вони взаємодіють з системою через варіанти використання або прецеденти. Один і той же актор може бути пов'язаний з декількома прецедентами, і, навпаки, один прецедент може бути пов'язаний з декількома різними акторами. Зв'язки між актором і прецедентом завжди бінарні, тобто, представляють відношення типу "один -до одного". Це не заперечує сказаного вище: насправді, один актор може бути пов'язаний з декількома прецедентами, але тільки за допомогою окремих зв’язків, по одному на кожен прецедент. Актори не можуть бути пов’язані один з одним. Єдиний тип зв’язку між акторами, який є можливим, це успадкування (наслідування, generalization). Сказане не забороняє спілкування між акторами в реальному світі, просто під час створення моделі варіантів використання, таке спілкування і його відображення на діаграмі вважають несуттєвим.

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

Всі діаграми в UML представлені спеціальними графічними нотаціями, які, як правило, містять вершини (представлені геометричними фігурами), які пов’язані ребрами (різними дугами або стрілками).

Елементи нотації і їх інтерпретація.

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

компонентом діаграми.

-зовнішня стосовно системи сутність, яка взаємодіє із системою і

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

-опис послідовно виконуваних дій, які приводять до

суттєвого для актора результату.

-опис сукупності екземплярів акторів і об’єктів ,і їх взаємодії в

процесі вирішення конкретного завдання.

-фіз частина с-ми, модулі с-ми, які забезпечують реалізацію

узгодження набору інтерфейсу.

- фіз частина с-ми,яка надає ресурси для розвязку завдань.

-пояснююча сутність

Семантика і нотація діаграми діяльності (активності). Нарисуйте елементи нотації і наведіть їх інтерпретацію.

Діаграма діяльності (Activity Diagram) відноситься до загальної діаграми поведінки, вона один з часткових випадків діаграми станів (але до діаграм станів не зводяться). Будуються на рівні моделей проектування Designer Model. Під час побудови поведінки, виникає потреба алгоритмічної деталізації. Вимоги до зображення послідовності зростають. Семантика , нотації, дають можливість відобразити певні стани і переходи між цими станами. Основним напрямком діаграм діяльності є візуалізувати особливості реалізації класів, за умови представлення алгоритмів їх виконання; кожен стан може бути представлений на виконанні операції чи її частини, дозволяє описати реакцію системи на внутрішні події. На діаграмі діяльності (ДД) відображається логіка або послідовність переходу від 1-ї до 2-ї і увага фіксується на результаті діяльності; власне цей результат може вплинути на зміну стану системи або повернути значення. Час явним чином не вказується в ДД. Елементарна дія (action state – стан дії (зображується у вигляді горизонтально видовженого прямокутника з заокругленими кутами)) – це атомарне обчислення, яке виконується і приводить до зміни системи чи повертає значення, дія миттєва і не піддається перериванню ззовні. Діяльність – тривалі неатомарні обчислення. Стан дії – специфічний випадок стану з деякою вхідною дією і хоча б одним переходом, який виходе з цього стану. Цей перехід неявно передбачає, що описана дія (action state) завершилась. Один з способів іменування у формі дієслова або у вигляді певної обчислювальної операції. Існує можливість використати subactivity state (підстан діяльності) (зображується горизонтально видовженим прямокутником із позначкою скобки), коли система розглядається з певним 0-вим наближенням. Наявні псевдостани. Кожна діаграма володіє одним початковим і одним кінцевим псевдо станом (• Initial state, ּFinal state). Реалізується зверху вниз від Initial state до Final state. Переходи (Transition) – реакція об’єкту на деяку подію; об’єкт виконує дію, яка прикріплена до переходу, і змінює свій стан. Кожному стану відповідає своя множина переходів. Час переходу вважають нульовим, тобто перехід миттєвий. Розрізняють переходи: тригерні (кріпиться подія, перехід реагує на неї); нетригерні (подія може бути явно не прикріплена). Ці переходи передбачають, що елементарна дія в стані завершилась, спрацьовують відразу після завершення дій в стані. Зображуються: →. Сторожові умови прописуються в квадратних дужках [ ], їх кріплять до переходу, коли переходів є декілька після певного стану, з яких є лише один істинний. В UML розгалуження носить назву Decision (Рішення), логічне АБО. (зображають у вигляді ромбу). Якщо лог. АБО, то стрілки входять зліва і зверху в ромб, а при потребі зобразити рішення як злиття, стрілки входять зліва і справа в ромб, а виходить вниз. Паралельні гілки обчислень використ. для зображення розпаралелювання і забезпечують синхронізацію. Зображується: ▬ Логіка таких І береться з мереж Петрі (вперше використали в IDEF2). Concurent fork (розпаралелення) – одна стрілка входить і декілька виходить, Concurent join (злиття) – декілька входить і одна виходить. Діаграма діяльності може бути представлена як спеціальний випадок діаграм станів, де більшість станів – дії, більшість переходів – не тригерні переходи, які спрацьовують в станах, які є джерелами. Доріжки (swinlane) – діаграма діяльності ділиться зверху. Як правило, пишуть кому доріжка належить, порядок їх розміщення семантично немає значення. Доріжки асоціюють з діями певних структурних підрозділів організації, а кожен такий підрозділ несе відповідальність в рамках своєї доріжки. Перехід між підрозділами можливий, коли відбувається перехід до потоку управління в відповідний підрозділ. Зображуються об’єкти на діаграмах діяльності – прямокутником , заголовок – назва об’єкта і через «:» назва класу об’єкту, підкреслені лінією. Можуть бути анонімні (без імені) і позакласові об’єкти (без класу). В ДД об’єкти мають додатковий зміст, адже вони ініціюють виконання певних дій, або визначають деякий результат цих дій. Один і той же об’єкт на ДД може бути представлений декілька разів (може бути з іншим вмістом). Об’єкти під’єднуються до станів стрілками ─ ─ →. Якщо об’єкти зображаються у доріжках, то можуть бути і на межах доріжок, тоді перехід до наступного стану в сусідній доріжці є асоційований з готовністю деякого документу (стану), якщо ж об’єкт зображається в рамках одної доріжки, то він визначається лише цією доріжкою. Для ДД можливе несхідне (↓) і висхідне (↑).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]