і придатність для повторного використання не тільки програм, а й проектів, що врешті-решт веде до створення середовища розробки і переходу до складального створення ПЗ. Системи найчастіше виходять більш компактними, ніж їх структурні еквіваленти, що означає не тільки зменшення обсягу програмного коду, але і здешевлення проекту за рахунок використання попередніх розробок.
. Об'єктна декомпозиція зменшує ризик створення складних систем ПЗ, тому що вона припускає еволюційний шлях розвитку системи на базі відносно невеликих підсистем. Процес інтеграції системи розтягується на весь час розробки, а не перетворюється на одноразову подія.
. Об'єктна модель цілком природна, оскільки в першу чергу орієнтована на людське сприйняття світу, а не на комп'ютерну реалізацію.
. Об'єктна модель дозволяє повною мірою використовувати виражальні можливості об'єктних і об'єктно-орієнтованих мов програмування.
До недоліків об'єктно-орієнтованого підходу відносяться деяке зниження продуктивності функціонування ПЗ і високі початкові витрати. Об'єктна декомпозиція істотно відрізняється від функціональної, тому перехід на нову технологію пов'язаний як з подоланням психологічних труднощів, так і додатковими фінансовими витратами. Безумовно, об'єктно-орієнтована модель найбільш адекватно відображає реальний світ, що представляє собою сукупність взаємодіючих (за допомогою обміну повідомленнями) об'єктів. Але на практиці зараз продовжується формування стандарту мови UML для об'єктно-орієнтованого моделювання, і кількість CASE-засобів, що підтримують об'єктно-орієнтований підхід, невелика в порівнянні з аналогічними засобами, що підтримують структурний підхід.
Крім того, діаграми, що відображають специфіку об'єктного підходу (діаграми класів тощо), набагато менш наочні і погано зрозумілі непрофесіоналами. Тому одна з головних цілей впровадження CASE-технології, а саме постачання всіх учасників проекту (у тому числі і замовника) спільною мовою для передачі розуміння raquo ;, забезпечується на сьогоднішній день тільки структурними методами.
При переході від структурного підходу до об'єктному, як при всякій зміні технології, необхідно вкладати гроші в придбання нових інструментальних засобів. Тут слід врахувати і витрати на навчання (оволодіння методом, інструментальними засобами й мовою програмування). Для деяких організацій ці обставини можуть стати серйозними перешкодами. Об'єктно-орієнтований підхід не дає негайної віддачі. Ефект від його застосування починає позначатися після розробки двох-трьох проектів та накопичення повторно використовуваних компонентів, що відбивають типові проектні рішення в даній області. Перехід організації на об'єктно-орієнтовану технологію - це зміна світогляду, а не просто вивчення нових CASE-засобів і мов програмування [6].
Очевидно, що в конкретному проекті декомпозировать складну систему одночасно двома способами неможливо. Можна почати декомпозицію яким-небудь одним способом, а потім, використовуючи отримані результати, спробувати розглянути систему з іншої точки зору. Тепер перейдемо до розгляду взаємозв'язку між структурними та об'єктно-орієнтованим підходами. Основою взаємозв'язку є спільність ряду категорій і понять обох підходів (процес і варіант використання, сутність і клас та ін.). Цей взаємозв'язок може виявлятися в різних формах. Так, одним з можливих підходів є використання структурного аналізу як основи для об'єктно-орієнтованого проектування. Такий підхід доцільний через поширення CASE-засобів, що підтримують структурний аналіз. Структурний аналіз триває до моменту, при якому діаграми потоків даних починають відображати не тільки предметну область, а й систему ПЗ.
Після виконання структурного аналізу і побудови діаграм потоків даних разом зі структурами даних і іншими результатами аналізу можна різними способами приступити до визначення класів і об'єктів. Так, якщо взяти якусь окрему діаграму, то кандидатами в об'єкти можуть бути зовнішні сутності і накопичувачі даних, а кандидатами в класи - потоки даних.
Іншою формою прояву взаємозв'язку можна вважати інтеграцію об'єктної і реляційної технологій. Реляційні СУБД є на сьогоднішній день основним засобом реалізації великомасштабних баз даних і сховищ даних. Причини цього очевидні: реляційна технологія використовується досить довго, освоєна величезною кількістю користувачів і розробників, стала промисловим стандартом, в неї вкладені значні кошти і створено безліч корпоративних БД в самих різних галузях, реляційна модель проста і має строгий математичний підставу; існує велика різноманітність промислових засобів проектування, реалізації та експлуатації реляційних БД. Внаслідок цього реляційні БД в основному використовуються для зберігання і пошуку об'єктів в так званих об'єктно-реляційних сист...
