Головні принципи об'єктно-орієнтованого підходу: абстрагування, інкапсуляція, модульність, ієрархічність. Додаткові принципи - типізація, паралелізм і збереженість. Називаючи їх додатковими, ми маємо на увазі, що вони корисні в об'єктної моделі, але не обов'язкові. Кожен з перерахованих принципів сам по собі не новий, але в об'єктній моделі вони вперше застосовані в сукупності.
Абстрагування є одним з основних принципів, використовуваних для вирішення складних завдань. Абстракція виділяє істотні характеристики деякого об'єкта, що відрізняють його від всіх інших видів об'єктів і, таким чином, чітко визначає його концептуальні межі з точки зору спостерігача.
Інкапсуляція. Якщо абстрагування направлено на спостерігається поведінка об'єкта, то за його внутрішню організацію відповідає інкапсуляція. Інкапсуляція - це процес відділення один від одного елементів об'єкта, що визначають його пристрій і поведінку; інкапсуляція служить для того, щоб ізолювати контрактні зобов'язання абстракції від їх реалізації. Таким чином, абстракція і інкапсуляція доповнюють один одного. Абстракція працює тільки разом з инкапсуляцией. Практично це означає наявність двох частин у класі: інтерфейсу і реалізації. Інтерфейс відображає зовнішню поведінку об'єкта, описуючи абстракцію поведінки всіх об'єктів даного класу. Внутрішня реалізація описує уявлення цієї абстракції і механізми досягнення бажаної поведінки об'єкта. Принцип поділу інтерфейсу і реалізації відповідає суті речей: в інтерфейсної частини зібрано все, що стосується взаємодії даного об'єкта з будь-якими іншими об'єктами; реалізація приховує від інших об'єктів всі деталі, що не мають відношення до процесу взаємодії об'єктів.
Модульність. Поділ програми на модулі дозволяє зменшити її складність, однак набагато важливішим є той факт, що всередині модульної програми створюються безлічі добре визначених і документованих інтерфейсів, які важливі для вичерпного розуміння програми в цілому. Модулі в програмі виконують роль фізичних контейнерів, в які поміщаються визначення класів і об'єктів. Правильне поділ програми на модулі є майже такою ж складним завданням, як вибір правильного набору абстракцій. Модулі слід прагнути будувати таким чином, щоб об'єднати логічно пов'язані абстракції і мінімізувати взаємні зв'язки між модулями.
Важливим елементом об'єктно-орієнтованих систем і основним видом ієрархії «is a» є концепція успадкування. Спадкування означає таке ставлення між класами (відношення батько / нащадок), коли один клас запозичує структурну або функціональну частину одного або декількох інших класів (відповідно, одиночне і множинне спадкування). Іншими словами, успадкування створює таку ієрархію абстракцій, в якій підкласи успадковують будову від одного або декількох суперкласів. Часто підклас добудовує або переписує компоненти вищого класу. Таким чином, спадкування породжує ієрархію «узагальнення-спеціалізація», в якій підклас є спеціалізованим окремий випадок свого суперкласу. Ставлення «part of» (частина), на відміну від ієрархії «is а», вводить ієрархію агрегації. Агрегація дозволяє фізично згрупувати логічно пов'язані структури, а спадкування копіює ці загальні групи в різні абстракції.
Типізація - це спосіб захиститися від використання об'єктів одного класу замість іншого, або, по крайней мере, управляти таким використанням. Типізація змушує розробника прикладної системи висловлювати абстракції так, щоб інструментальне засіб, що використовується в реалізації, підтримувало дотримання прийнятих проектних рішень. Велику гнучкість при цьому розробнику надає механізм поліморфних операцій. Поліморфізм визначає, чтоодно і те ж ім'я може означати об'єкти різних типів, але, маючи загального предка, всі вони мають і загальне підмножина операцій, які можна над ними виконувати. Протилежність поліморфізму називається мономорфізму.
Паралелізм. Існують завдання, в яких автоматизовані системи повинні обробляти багато подій одночасно. В інших випадках потреби в обчислювальній потужності перевищує ресурси одного процесора. У кожній з таких ситуацій природно використовувати кілька комп'ютерів для вирішення завдання або задіяти багатозадачність на многопроцессорном комп'ютері. Процес (потік управління) - це фундаментальна одиниця дії в системі. Кожна програма має принаймні один потік управління, паралельна система має багато таких потоків. Але як тільки в систему введений паралелізм, відразу виникає питання про те, як синхронізувати відносини активних об'єктів один з одним, а також з іншими об'єктами, що діють послідовно. Наприклад, якщо два об'єкти посилають повідомлення третьому, повинен бути якийсь механізм, який гарантує, що об'єкт, на який спрямована дія, що не зруйнується при одночасній спробі двох активних об'єктів змінити його стан. У паралельних системах недостатньо визначити поведінку об'єкта, треба ще вжити заходів, що гарантують, що він не буде зруйнований декількома незалежними процесами.
Спектр зберігання об'єктів в часі охоплює:
- проміжні результати обчислення виразів;
- локальні змінні у виклику процедур;
- власні змінні, глобальні змінні і динамічно створювані дані;
- дані, що зберігаються між сеансами виконання програми;
- дані, що зберігаються при переході на нову версію програми;
- дані, які взагалі переживають програму.
Традиційно, першими трьома рівнями займаються мови програмування, а останніми - бази даних. Введення зберігання призвело до об'єктно-орієнтованим баз даних (OODB, object-oriented databases). У OODB має сенс зберігати не тільки дані. але і класи, так, щоб програми могли правильно інтерпретувати дані. Це створює великі труднощі в міру збільшення обсягу даних, особливо, якщо клас об'єкта потрібно змінити.
Що стосується питань зберігання об'єктів в просторі, то в більшості систем об'єктів при їх створенні відводиться місце в пам'яті, яке не змінюється і в якому об'єкт перебуває все своє життя. Однак для розподілених систем бажано забезпечувати можливість перенесення об'єктів в просторі, так, щоб їх можна було переносити з машини на машину і навіть при необхідності змінювати форму представлення об'єкту в пам'яті.
§ 6. Призначення і цілі уніфікованої мови моделювання. Основні концепції UML