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

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

Рисунок 5.14 - Діаграма розміщення

Підсистема в UML розглядається як різновид пакета, який має самостійну функцію.

Групування в пакети може бути вкладеним, тобто складовими пакетів можуть бути класи, інші пакети та підсистеми.

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

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

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

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

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

Над прямокутником ліворуч зверху розміщується менший за розміром прямокутник, в якому подається стереотип пакета та його назва. Якщо елементи, включені до пакета, не показують, його назва розміщується у великому прямокутнику. На рис. 5.15 показано пакет, названий А 1, до котрого включено пакет В 1, клас К 1 та підсистему С 1.

Рисунок 5.15 - Пакет UML

Серед фіксованих стереотипів для позначення різновидів пакета введено такі: <<система>>, <<прикладна система>>, <<підсистема>>, <<елемент конфігурації>>, <<складова системи>>, <<охоплююча система>>, <<фасад>> (facade — пакет, який є інтерфейсом іншого пакета), <<каркас>> (framework — типовий зразок взаємодії об’єктів, детальніше див. п. 7.3.8.), <<заглушка>> (stub — позначення пакета, який буде описано пізніше) тощо.

Між пакетами може бути встановлено відношення з відповідними стереотипами. Наприклад, відношення А «імпортує» Б означає, що визначені в пакеті Б класи можна використовувати в класах пакета А.

Нагадаємо, що дозволяється виділяти власні категорії стереотипів, в тому числі і для різновидів пакетів, котрі відповідають власним смакам чи потребам. Наприклад, стереотип «успадковано» може додаватися до назви пакета, який є елементом застарілої версії системи, і без перероблення його включено до нової версії системи.

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

Контрольні запитання і завдання

1. Які з елементів моделювання UML дозволяють визначити головні складові концептуального моделювання проблеми, а саме:

а) онтологію домену;

б) модель поведінки об’єктів;

в) модель процесів?

2. Метод UML пропонує різні нотації (графічні діаграми) для різних аспектів опису проблеми. Чому не єдину?

3. Аналоги яких діаграм UML Вам зустрічалися:

а) у методі С. Шлеєр та С. Меллора;

б) у методі Джекобсона?

4. Чи дозволяє діаграма класів UML відобразити відношення:

а) між класами об’єктів;

б) між екземплярами класів?

5. Які значення може мати атрибут видимості класів та що вони означають?

6. Які відношення позначаються в діаграмі класів UML спеціальними графічними символами?

7. Які відношення пов’язують сценарії системи?

8. Які діаграми UML доцільно застосовувати для аналізу вимог? З якої діаграми доцільно починати?

9. Які діаграми відображають обмін повідомленнями як єдиний засіб взаємодії об’єктів?

10. Які діаграми зручно застосовувати:

а) на стадії проектування;

б) на стадії реалізації?

Чи можна застосувати ті самі діаграми для кількох стадій розроблення?

11. Яка роль стереотипів у нотаціях UML?

12. Які засоби групування елементів моделювання?