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

Діаграма компонентів (ДК) є структурною діаграмою і відноситься до загальних діаграм. ДК будується в моделі реалізації, реалізовує фіз.. представлення системи, визначають архітектуру системи, що розробляється, встановлює залежність між програмними компонентами. Компоненти відповідають окремому файлу. Пунктирні стрілки, які об’єднують модулі, показують співвідношення взаємозв’язків між компонентами і залежними інтерфейсами. Цілі: 1) візуалізація загальної структури вихідного коду програмної системи; 2) специфікація програмної системи на рівні виконання; 3) забезпечення багатократного використання програмного коду; 4) представлення концептуальних і фізичних систем БД. Можна моделювати бізнес-процеси через ці діаграми. Нотація компонента: прямокутник з двома маленькими прямокутниками на лівій стороні. Реалізовує будьякий набір інтерфейсів, позначає загально фізичне представлення моделі. Вміст запису: ім’я компонента (ім’я пакету:ім’я компонента). Використовується також tagged values {version 1}. В UML ліві прямокутники порожні (а в загальному верхній – дані, нижній – операції). Екземпляр компонента:тип компонента (Component Instance). В якості простих імен використовують імена файлів; представлення залежить від програмного середовища. Є 3 типи компонентів (в UML необов’язково): 1) розгортання (забезпечують виконання системою функцій – динамічні бібліотеки, html-сторінки, файли-довідники); 2) робочі продукти (файли з вихідним текстом програм); 3) компоненти використання (виконувальні модулі *.exe). Позначення типізованого компонента може бути необов’язкове. <<Artifact>> назвами артефактів підкреслюють завершеність інформаційного вмістилища, яке залежить від конкретної програмної реалізації. Вказування стереотипів <<stereotype>> перед іменем файлу: Розгортання: 1) library – відноситься до 1-го; 2) table – таблиця; 3) file – файл з вихідним текстом програми; 4) document. Використання: 5) executable – виконувані; 6) interface – інтерфейси (зображується ◌, або у вигляді класу з стереотипом <<interface>>), використовують зв'язок без асоціацій, для реалізацій інтерфейсу, а наявність інтерфейсу в компонента, означає що цей компонент реалізує даний набір інтерфейсів). Використовують для взаємодії систем з зовнішніми сутностями і для реалізації можливості вносити зміни не зачіпаючи системи загалом (інтерфейс – як посередник). Є два типи інтерфейсів: експортовані ( від них іде з’єднання ─◌) і імпортовані (від них іде ─ →). Відношення між різними типами компонентів: 1) залежний main.exe від всіх інших (діаграма компонентів main.exe посередині, від неї стрілки типу ─ → до інших фалів index.html, help.hlp, 1.cpp, примітка 1.h у вигляді загорнутих сторіночок). 2) За такою ж схемою можна побудувати компонент, який залежний від класів; 3) реалізований компонент відповідними класами, і це може ображатись як компонент який містить їх в собі (типу Part); 4) компонент містить деякі об’єкти.

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

Діаграма об’єктів (ДО) належить до спеціальних діаграм, які використовують для обслуговування загальних діаграм. Об'єкт (object) – є екземпляром класу і створюється на етапі програмної реалізації. ДО відносяться до структурних діаграм класів. (Зображуються у вигляді прямокутника зверху якого стоїть підкреслене ім’я цього об’єкту). Кожен об’єкт володіє індивідуальністю (має власне ім'я, яке не співпадає з іменем класу, індивідуальні значення атрибутів). Для об’єкту вказують конкретні значення атрибутів, як його власних, так і успадкованих від всіх батьківських класів. Щоб відрізнити об’єкт від класу, ім'я об’єкту пишуть з малої букви і підкреслюють. Використовують різні варіанти позначення імен об’єктів, найповніший серед них – після імені об’єкта через двокрапку вказують ім'я класу. На UML діаграмах можна побачити позначення об’єкта класу, який називають анонімним. У цьому випадку ім'я об’єкта складається тільки з імені класу перед яким ставиться двокрапка. Діаграму об’єктів, як правило, створюють для окремих об’єктів з складною поведінкою і взаємодією. Об’єкти можуть бути позакласовими, або належати певному класу: <ім’я об’єкту>:<ім’я класу>. Інколи, коли потрібно, вказують шлях в ієрархії класів, але вже через символ «::».ДО дозволяють: моделювати екземпляри сутності, які є в класах. На ДО зображають: об’єкти і відношення між ними в момент часу. ДО важлива для: візуалізації, специфікації, документації, конструювання статичних аспектів системи за допомогою прямого і зворотного (частіше використовують, для відлагодження системи) програмування. ДО містить: об’єкти, зв’язки. Object Diagram – діаграма на якій показують об’єкти та їх співвідношення в будь-який момент часу (можуть містити умови, примітки, обмеження, пакети, підсистеми іноді і класи, особливо, якщо треба візуалізувати клас, який стоїть за конкретним об’єктом). ДО – статична частина діаграми взаємодії. Акцентує увагу на абстрактних екземплярах (прототипах). Типові приклади застосування: під час моделювання статичного виду системи з точки зору проектування або процесів використаних для зображення структури об’єктів. ДО не можуть відобразити повний стан системи, бо вона являє собою знімок системи в деякий момент часу. Рекомендації: 1) давати ім’я діаграми відповідно до її призначення; 2) розміщувати елементи з мінімальними перетинами і семантично близькі об’єкти близько, задаючи різну кольоровість діаграм і т.п. для їх чіткості.