1.3. Методологія об'єктно-орієнтованого аналізу і проектування

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

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

Для виділення або ідентифікації компонентів наочної області було запропоновано декілька способів і правил. Сам цей процес одержав назву концептуалізації наочної області. При цьому під компонентою розуміють деяку абстрактну одиницю, яка володіє функціональністю, т.  е. може виконувати певні дії, пов'язані з рішенням поставлених задач. На попередньому етапі концептуалізації рекомендується використовувати так звані CRC‑ картки (Component, Responsibility, Collaborator– компоненту, обов'язок, співробітники) [1]. Для кожної виділеної компоненти наочної області розробляється власна CRC‑ картка (мал. 1.6).

Мал. 1.6. Загальний вид CRC‑ картки для опису компонентів наочної області

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

Розділення процесу розробки складних програмних додатків на окремі етапи сприяло становленню концепції життєвого циклу програми. Під життєвим циклом (ЖЦ) програми розуміють сукупність взаємозв'язаних і наступних в часі етапів, починаючи від розробки вимог до неї і закінчуючи повною відмовою від її використовування. Стандарт ISO/IEC 12207, хоча і описує загальну структуру ЖЦ програми, не конкретизує деталі виконання тих або інших етапів. Згідно прийнятим поглядам ЖЦ програми складається з наступних етапів:

Аналізу наочної області і формулювання вимог до програми

Проектування структури програми

Реалізації програми в кодах (власне програмування)

Упровадження програми

Супроводи програми

Відмови від використовування програми

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

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

Етап програмування навряд чи потребує уточнення, оскільки є самим традиційним для програмістів. Поява інструментаріїв швидкої розробки додатків (Rapid Application Development, RAD) дозволила істотно скоротити час, і витрати на виконання цього етапу. Результатом даного етапу є програмний додаток, який володіє необхідною функціональністю і здатне вирішувати потрібні задачі в конкретній наочній області.

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

Примітка

Розглядаючи різні етапи ЖЦ програми, слід зазначити одна важлива обставина. А саме, якщо поява RAD‑ інструментаріїв дозволила істотно скоротити терміни етапу програмування, то відсутність відповідних засобів для перших двох етапів довгий час стримувала процес розробки додатків. Розвиток методології ООАП був направлений на автоматизацію другого, а потім і першого етапів ЖЦ програми.

Методологія ООАП тісно пов'язана з концепцією автоматизованої розробки програмного забезпечення (Computer Aided Software Engineering, CASE). Поява перших CASE‑ засобів зустріла з певною настороженістю. З часом з'явилися як захоплені Відгуки про їх вживання, так і критичні оцінки їх можливостей. Причин для таких суперечливих думок було дещо. Перша з них полягає в тому, що ранні CASE‑ засоби були простою надбудовою над деякою системою управління базами даних (СУБД). Хоча візуалізація процесу розробки концептуальної схеми БД має важливе значення, вона не вирішує проблем розробки додатків інших типів.

Друга причина має складнішу природу, оскільки пов'язана з графічною нотацією, реалізованою в тому або іншому CASE‑ засобі. Якщо язики програмування мають строгий синтаксис, то спроби запропонувати відповідний синтаксис для візуального представлення концептуальних схем БД були сприйняті далеко неоднозначно. З'явилося декілька підходів, які більш детально будуть розглянуті на чолі 2. На цьому фоні поява уніфікованого язика моделювання (Unified Modeling Language, UML), який орієнтований на рішення задач перших двох етапів ЖЦ програм, була сприйнята з великим оптимізмом всім співтовариством корпоративних програмістів.

Примітка

Абревіатура UML допускає відповідний переклад і подальше скорочення, але зважаючи на нелегкість для читання «УЯМ», що виходить, було вирішено використовувати початковий термін на всьому протязі книги. Частково це можна пояснити традицією вживання оригінальних термінів, що вже склалася, таких як CASE, RAD, DLL, ISDN і цілого ряду інших.

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