5. Методологія об’єктно-орієнтованого аналізу і проектування складних систем

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

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

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

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

Основна ідея об’єктно-орієнтованого аналізу і проектування складається в розгляді предметної області і логічного рішення задачі з погляду об'єктів.

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

Об'єктна декомпозиція має ряд переваг перед алгоритмічною:

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

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

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

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

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

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

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

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

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

Уніфікована мова моделювання (Unіfіed Modelіng Language - UML) пропонує досить повну нотацію, що розширюється при переході від аналізу до проектування.

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

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

У UML визначений наступний набір діаграм, кожна їх яких демонструє визначений аспект опису моделі:

- діаграми варіантів використання (use case);

- діаграми класів (class dіagram);

- діаграми станів (state dіagram);

- діаграми послідовності (sequence dіagram);

- діаграми діяльності (actіvіty dіagram);

- діаграми кооперації(collaboratіon dіagram);

- діаграми компонентів (component dіagram);

- діаграми розгортання (deployment dіagram).

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

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

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

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

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

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

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

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