Діаграма компонентів UML, Планерка онлайн-школа креативності
Діаграма компонентів UML
Для чого використовується метод проектування
Показати розбиття програмної системи на структурні компоненти та зв'язки (залежності) між компонентами.
Як фізичні компоненти можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і т.п.
План дій
Після ознайомлення з розділами («Приклад», «Застосування»), ви можете спробувати свої сили в самостійному складанні діаграм компонентів.
Як застосовувати метод проектування
Діаграми компонентів слід застосовувати, коли система поділяється на компоненти і треба показати їх взаємовідносини за допомогою інтерфейсів чи схему компонентів у низькорівневій структурі системи.
Приклад використання
В об'єктно-орієнтованому співтоваристві йдуть дебати про те, в чому полягає відмінність між компонентом і звичайним класом. Ми не обговорюватимемо тут це спірне питання, але покажемо нотацію мови UML, що використовується, щоб відрізнити їх один від одного.
У UML 1 був окремий символ компонента (рис. 14.1). УUML 2 цього значка немає, але можна позначити прямокутник класу схожим значком. Або можна скористатися ключовим словом «component » (компонент ).
Крім цього, значка компоненти не принесли з собою жодних нових позначень. Компоненти зв'язуються між собою за допомогою інтерфейсів, що надаються або необхідних, при цьому кульово-гніздова нотація зазвичай застосовується тільки на діаграмах класів. Можна також розбивати компоненти частини за допомогою діаграм складових структур.
На рис. 14.2 показано приклад простої діаграми компонентів. У цьому прикладі компонент Till може взаємодіяти з компонентомSales Server (Сервер продажу) за допомогою інтерфейсу sales message (Повідомлення про продаж). Оскільки мережа ненадійна, компонент Message Queue (Черга повідомлень) встановлений так, щоб каса могла спілкуватися з сервером, коли мережа працює, і розмовляти з чергою повідомлень, коли мережа вимкнена. Тоді черга повідомлень зможе поговорити із сервером, коли мережа знову стане доступною. В результаті черга повідомлень надає інтерфейс для розмови з касою і вимагає такий самий інтерфейс для розмови з сервером. Сервер поділено на два основні компоненти: Transaction Processor (Процесор транзакцій) реалізує інтерфейс повідомлень, а Accounting Driver (Драйвер рахунків) спілкується з Accounting System (Система ведення рахунків).
Питання сутності компонента є предметом нескінченних суперечок. Ось одна з найбільш продуманих суджень, виявлених нами:
Компоненти – це технологія. Технічні фахівці вважають їх важкими розуміння. Компоненти – це скоріше стиль ставлення клієнтів до програмного забезпечення. Вони хочуть мати можливість купувати необхідне програмне забезпечення частинами, а також мати можливість оновлювати його, як вони оновлюють свою стереосистему. Вони хочуть, щоб нові компоненти працювали так само, як і колишні, і оновлювати їх згідно своїх планів, а не за вказівкою виробників. Вони хочуть, щоб системи різних виробників могли працювати разом та були взаємозамінними. Це дуже розумні вимоги. Одна проблема: їх важко виконати. Ральф Джонсон (Ralph Johnson), http://www.c2.com/cgi/wiki?DoComponentsExist
Важливо те, що компоненти є елементами, які можна незалежно один від одного купити і оновити. В результаті поділ системи на компоненти є більшою міроюмаркетинговим рішенням, ніж технічним. Прекрасний посібник з цього питання представляє книга Хохмана [23]. Вона також нагадує про те, що слід остерігатися поділу системи на надто дрібні компоненти, оскільки дуже великою кількістю компонентів важко управляти, особливо коли виробництво версій піднімає свою потворну голову; звідси пішов вираз "пекло DLL" або "dll hell". У ранніх версіях мови компоненти UML застосовувалися для представлення фізичних структур, таких як DLL. Тепер це не є актуальним; в даний час це завдання вирішується за допомогою артефактів (10 artifacts 10).
Підписуйтесь на новини сайту, форму підписки ви можете знайти у правій колонці сайту.
Якщо ви хочете навчитися працювати на фрілансі професійно, запрошуємо на курс «Як заробляти на фрілансі».