Про проектування складних систем

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

1. Задовольняє заданим функціональним специфікаціям.

2. Узгоджена з обмеженнями, що накладаються обладнанням.

3. Задовольняє явним і неявним вимогам за експлуатаційними якостями і ресурс поживанню.

4. Задовольняє явним і неявним критеріям дизайну продукту.

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

Елементи програмного проектування. Було розроблено десятки різних методів, які можна класифікувати за трьома категоріями:

1. Умовні позначення - мова для опису кожної моделі.

2. Процес - правила проектування моделі.

3. Інструменти - кошти, які прискорюють процес створення моделей, і в яких вже втілені закони функціонування моделей. Інструменти допомагають виявляти помилки в процесі розробки.

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

1. Динамічна.
2. Статично.
3. Логічна.
4. Фізична.

Глава 2
Об'єктна модель

Парадигми програмування. Виявили п'ять основних різновидів стилів програмування:

1. Процедурно-орієнтований – алгоритми.

2. Об'єктно-орієнтований - класи та об'єкти.

3. Логіко-орієнтована мета - часто виражені в термінах числення предикатів.

4. Орієнтований на правила - правила «якщо-то».

5. Орієнтований на обмеження - інваріантні співвідношення.

Кожен стиль програмування має свою концептуальну базу. Кожен стиль вимагає свого умонастрої і способу сприйняття розв'язуваної задачі. Для об'єктно-орієнтованого стилю концептуальна база - це об'єктна модель. Вона має чотири головні елементи:

· абстрагування

· інкапсуляція

· модульність

· ієрархія

Ці елементи є головними в тому сенсі, що без будь-якого з них модель не буде об'єктно-орієнтованої. Крім головних, є ще три додаткові елементи:

· типізація

· паралелізм

· збереженість

 

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

Існуючі абстракції:

1. Абстракція суті - Об'єкт представляє собою корисну модель якоїсь сутності в предметної області.

2. Абстракція поведінки - Об'єкт складається з узагальненого безлічі операцій.

3. Абстракція віртуальної машини - Об'єкт групує операції, які або разом використовуються більш високим рівнем керування, або самі використовують деякий набір операцій більш низького рівня.

4. Довільна абстракція - Об'єкт, включає в себе набір операцій, що не мають один з одним нічого спільного.

Всі абстракції володіють як статичними, так і динамічними властивостями. Наприклад, фото як об'єкт вимагає певного обсягу пам'яті на конкретному пристрої, має ім'я і зміст. Ці атрибути є статичними властивостями. Конкретні ж значення кожного з перерахованих властивостей динамічні і змінюються в процесі використання об'єкта: файл можна збільшити або зменшити, змінити його ім'я і вміст. У процедурному стилі програмування дії, що змінюють динамічні характеристики об'єктів, складають суть програми. Будь-які події пов'язані з викликом підпрограм і з виконанням операторів. Стиль програмування, орієнтований на правила, характеризується тим, що під впливом певних умов активізуються певні правила, які в свою чергу викликають інші правила, і т. д.

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

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

Модульність. Модульність - це властивість системи, яка була розкладена на внутрішньо зв'язкові, але слабо пов'язані між собою модулі.

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

Модулі виконують роль фізичних контейнерів, в яких розміщуються визначення класів і об'єктів при проектуванні системи.

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

Ієрархія. Ієрархія - це упорядкування абстракцій, розташування їх по рівнях.

Основними видами ієрархічних структур стосовно кладних систем є структура класів (ієрархія «is-a») і структура об'єктів (ієрархія «part of»).

Типізація. Типізація - це спосіб захиститися від використання об'єктів одного класу замість іншого, або принаймні керувати таким використанням.

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

Було відзначино наступні важливі переваги суворо типізованих мов:

1. «Відсутність контролю типів може приводити до загадкових збоїв у програмах під час їх виконання.

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

3. Оголошення типів покращує документування програм.

4. Багато компілятори генерують більш ефективний об'єктний код, якщо їм явно відомі типи».

Мови, в яких типізація відсутній, володіють більшою гнучкістю.

Паралелізм. Паралелізм - це властивість, що відрізняє активні об'єкти від пасивних.

В об'єктно-орієнтованому проектуванні є три підходи до паралелізму.

По-перше, паралелізм - це внутрішня властивість деяких мов про-граммірованія.

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

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

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

Збереженість. Існують об'єкти, які присутні лише під час обчислення виразу, але є й такі, як бази даних, які існують незалежно від програми. Цей спектр зберігання об'єктів охоплює:

1. «Проміжні результати обчислення виразів.

2. Локальні змінні у виклику процедур.

3. Власні змінні, глобальні змінні і динамічно створювані дані.
4. Дані, що зберігаються між сеансами виконання програми.
5. Дані, які зберігаються при переході на нову версію програми.
6. Дані, які взагалі переживають програму».

Збереженість - це не тільки проблема збереження даних. У OODB має сенс зберігати і класи, так, щоб програми могли правильно інтерпретувати дані. Це створює великі труднощі в міру збільшення обсягу даних, особливо, якщо клас об'єкта раптом знадобилося змінити.

Збереженість - здатність об'єкта існувати в часі, переживаючи породив його процес, і (або) у просторі, переміщаючись з свого початкового адресного простору.

 

Глава 3
Класи і об'єкти

Об'єктом може бути:
1. Відчутний і (або) видимий предмет.
2. Щось, сприймане мисленням.
3. Щось, на що спрямована думка або дія.

Корисно розуміти, що об'єкт - це щось, що має чітко визначені кордони, але цього недостатньо, щоб відділити один об'єкт від іншого або дати оцінку якості абстракції.

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

Семантика. Стан об'єкта характеризується переліком (зазвичай статичним) всіх властивостей даного об'єкту і поточними (зазвичай динамічними) значеннями кожного з цих властивостей.

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

Всі властивості мають деякі значення. Ці значення можуть бути простими кількісними характеристиками, а можуть посилатися на інший об'єкт.

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

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

Операцією називається певний вплив одного об'єкта на інший з метою викликати відповідну реакцію.

В об'єктно-орієнтованих мовах операції, виконувані над даним об'єктом, називаються методами і входять у визначення класу об'єкту. У C вони називаються функціями-членами.

Операції. Операція - це послуга, яку клас може надати своїм клієнтам.

Три найбільш поширені операції:

1. Модифікатор - Операція, яка змінює стан об'єкта.

2. Селектор - Операція, зчитує стан об'єкта, але не змінює стану.

3. Ітератор - Операція, що дозволяє організувати доступ до всіх частин об'єкта в строго певній послідовності.

Дві операції є універсальними, вони забезпечують інфраструктуру, необхідну для створення і знищення примірників класу:

1. Конструктор - Операція створення об'єкта та / або його ініціалізації.

2. Деструктор - Операція, звільняє стан об'єкта та / або руйнівне сам об'єкт.

Ідентичність

Семантика. " Ідентичність - це така властивість об'єкта, яка відрізняє його від всіх інших об'єктів".

У більшості мов програмування і управління базами даних для розрізнення тимчасових об'єктів їх іменують, тим самим плутаючи адресованих та ідентичність. Більшість баз даних розрізняють постійні об'єкти по ключовому атрибуту, тим самим змішуючи ідентичність і значення даних.
Час життя об'єктів. Початком часу існування будь-якого об'єкту є момент його створення,а закінченням - повернення відведеної ділянки пам'яті системі.
Об'єкти створюються явно або неявно. Є два способи створити їх явно. По-перше, це можна зробити при оголошенні тоді об'єкт розміщується в стеку. По-друге, можна розмістити об'єкт, тобто виділити йому пам'ять з "купи". У C у будь-якому випадку при цьому викликається конструктор, який виділяє відоме йому кількість правильно ініціалізувала пам'яті під об'єкт.
При явному або неявному знищенні об'єкта в C викликається відповідний деструктор. Його завдання не лише звільнити пам'ять, але й вирішити, що робити з іншими ресурсами, наприклад, з відкритими файлами.

 

Природа класів

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

Ми можемо розділити інтерфейс класу на три частини:

1. Відкриту (public) - видиму всім клієнтам.

2. Захищену (protected) - видиму самому класу, його підкласами і друзям

(friends).

3. Закриту (private) - видиму тільки самому класу і його друзям.

Типи відносин. Відомі три основних типи відносин між класами. По-перше, це відношення "узагальнення / спеціалізація", відоме як "is-a". По друге, це ставлення "ціле / частина", відоме як "part of". По-третє, це семантичні, смислові відносини, асоціації. Мови програмування виробили кілька загальних підходів до вираження відносин цих трьох типів. Зокрема, більшість об'єктно-орієнтованих мов безпосередньо підтримують різні комбінації наступних видів відносин:

· асоціація

· спадкування

· агрегація

· використання

· інстанціювання

· метаклас

Відносини між класами та об'єктами. Класи та об'єкти - це окремі, але тісно пов'язані поняття. Зокрема, кожен об'єкт є екземпляром якого-небудь класу; клас може породжувати будь-яке число об'єктів.
Роль класів та об'єктів в аналізі та проектуванні. На етапі аналізу та ранніх стадіях проектування вирішуються дві основні задачі:
1. Виявлення класів та об'єктів, що становлять словник предметної

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

У першому випадку говорять про ключові абстракціях завдання, у другому - про механізми реалізації.

Вимірювання якості абстракції. Для оцінки якості класів та об'єктів, що виділяються в системі, можна запропонувати наступні п'ять критеріїв:
1. Зачеплення.
2. Зв'язність.
3. Достатність.
4. Повнота.
5. Примітивність.
В об'єктно-орієнтованому проектуванні прийнято розглядати методи класу як єдине ціле, оскільки всі вони взаємодіють один з одним для реалізації протоколу абстракції. Таким чином, визначивши поведінку, потрібно вирішити, в якому з класів це поведінка реалізується. Халберт і 0'Брайен запропонували наступні критерії для прийняття такого рішення:
1. Повторно використовуваного - Чи буде це поведінка корисно більш

ніж в одному контексті?

2. Складність - Наскільки важко реалізувати таку поведінку?

3. Застосовність - Наскільки дана поведінка характерна для класу, в

який ми хочемо включити поведінку?

4. Знання реалізації - Чи треба для реалізації даної поведінки знати

секрети класу?

 

Методологія

Глава 1

Система позначень

Елементи системи позначень

Необхідність різних точок зору. Неможливо охопити всі тонкі деталі складної програмної системи одним поглядом. Слід усвідомити також таксономічну структуру класів об'єктів, що використовуються механізми успадкування, індивідуальну поведінку об'єктів і динамічну поведінку системи в цілому. Наша система позначень багата деталями, але це не означає, що в кожному проекті необхідно використовувати всі її аспекти. На практиці для опису більшої частини підсумків аналізу і проектування досить деякого малої підмножини цієї системи. Слід пам'ятати, що позначення - тільки засіб висловити підсумки роздумів над архітектурою і поведінкою системи, а ніяк не самоціль. Треба користуватися виключно тими елементами позначень, які необхідні. Також, не треба занадто докладно описувати рішення задачі. Мета цієї глави - визначити синтаксис і семантику наших позначень для об'єктно-орієнтованого аналізу і проектування.

Моделі та ракурси. При прийнятті рішення в аналізі та проектуванні корисно розглянути взаємодію класів і об'єктів у двох вимірах: логічному / фізичному і статичному / динамічному. Обидва цих аспекти необхідні для визначення структури та поведінки об'єктної системи. У кожному з двох вимірювань ми будуємо кілька діаграм, які дають нам вигляд моделей системи в різних ракурсах. Таким чином, моделі системи містять всю інформацію про класи, зв'язки та інші сутності, а кожна діаграма представляє одну з проекцій моделі. У сталому стані проекту, всі такі діаграми повинні бути узгоджені з моделлю, а, отже, і одна з одною. Розглянемо для прикладу систему, що включає в себе кілька сотень класів; ці класи утворюють частину моделі. Неможливо, а насправді і не потрібно представляти всі класи і їх зв'язок на єдиній діаграмі. Замість цього ми можемо описати модель у кількох діаграмах класів, кожна з яких представляє тільки один її ракурс. Одна діаграма може показувати структуру успадкування деяких ключових класів; інша - транзитивне замикання множини всіх класів, що використовуються конкретним класом. Щоб розрізняти діаграми, ми повинні дати їм імена, які відображали б їх предмет і призначення.

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

Діаграми класів

Класи. Кожен клас повинен мати ім'я; якщо ім'я занадто довге, його можна скоротити або збільшити сам значок на діаграмі. Для деяких мов, особливо - для C + + і Smalltalk, ми повинні вимагати, щоб кожен клас мав ім'я, унікальне в системі. На деяких значках класів корисно перераховувати кілька атрибутів і операцій класу. Атрибути і операції на діаграмі представляють прообраз повної специфікації класу, в якій оголошуються всі його елементи. Якщо ми хочемо побачити на діаграмі більше атрибутів класу, ми можемо збільшити значок; якщо ми зовсім не хочемо їх бачити - ми видаляємо розділяємо межу і пишемо лише ім'я класу. Атрибути використовуються в аналізі та проектуванні для вираження окремих властивостей класу. Ім'я атрибута повинно бути недвозначно в контексті класу. Операції зазвичай зображаються всередині значка класу тільки своїм ім'ям. Щоб відрізняти їх від атрибутів, до їх іменами додаються дужки. Імена операцій повинні розумітися в контексті класу однозначно відповідно до правил перевантаження операцій вибраної мови реалізації.

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

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

Діаграми станів і переходів

Стани. Діаграма станів і переходів показує: простір станів даного класу; події, які спричиняють перехід з одного стану в інший; дії, які відбуваються при зміні стану. Стан представляє собою підсумковий результат поведінки системи. У будь-який момент часу стан об'єкта визначає набір властивостей (зазвичай статичний) об'єкта і поточні (зазвичай динамічні) значення цих властивостей. Під "властивостями" мається на увазі сукупність усіх зв'язків і атрибутів об'єкта. Ми можемо узагальнити поняття стану так, щоб воно було застосувати і до об'єкта, і до класу, так як всі об'єкти одного класу "живуть" в одному просторі станів. Кожен стан повинен мати ім'я; якщо воно виявляється занадто довгим, то його можна скоротити або збільшити значок стану. Кожне ім'я стану повинне бути унікальною в своєму класі. На значках деяких станів корисно вказати асоційовані з ними дії.

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

Діаграми об’єктів. Діаграма об'єктів показує існуючі об'єкти і їх зв'язок в логічному проекті системи. Інакше кажучи, діаграма об'єктів являє собою миттєвий знімок потоку подій в деякій конфігурації об'єктів. Таким чином, діаграми об'єктів є свого роду прототипами: кожна представляє взаємодію чи структурні зв'язки, які можуть виникнути у даної множини екземплярів класів, безвідносно до того, які конкретно екземпляри беруть участь у цій взаємодії. У такому сенсі, окрема діаграма об'єктів є ракурс структури об'єктів системи. При аналізі ми використовуємо діаграми об'єктів для показу семантики основних і другорядних сценаріїв, які відстежують поведінку системи. При проектуванні ми використовуємо діаграми об'єктів для ілюстрації семантики механізмів у проектуванні системи.

Відношення між об’єктами. Зв'язок між двома об'єктами може існувати тоді і тільки тоді, коли існує асоціація між відповідними класами. Асоціація між класами може проявлятися різними способами, наприклад, як проста асоціація, відношення спадкоємства або ставлення включення. У сталому стані структури класів і об'єктів системи повинні бути узгоджені. Повідомлення може сповіщати про подію. Воно підпорядковується визначеним раніше синтаксису подій, і, отже, може представляти символьне ім'я, об'єкт або ім'я деякої операції. У всякому разі, назва події має бути визначено на відповідній класу об'єкта сервера діаграмі переходів і станів. Якщо повідомлення про подію є операцією, то воно може включати фактичні параметри. Якщо порядковий номер явно не вказано, то повідомлення може бути надіслане незалежно від інших повідомлень. Щоб вказати явний порядок подій, ми можемо їх пронумерувати. Нумерація починається з одиниці і додається як необов'язковий префікс до виклику операції або повідомлення про подію. Порядковий номер показує відносний порядок посилки повідомлень. Повідомлення з однаковими номерами не впорядковані один до одного; повідомлення з меншим порядковим номером надсилається до повідомлення з більшим номером.

Діаграми взаємодії

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

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

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

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

Діаграми процесів.

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

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

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