Примітка. У розглянутому вище прикладі використовувалася одна з прийнятих нотацій в деяких мовах програмування (наприклад

У розглянутому вище прикладі використовувалася одна з прийнятих нотацій в деяких мовах програмування (наприклад, в Object Pascal) для позначення приналежності методу тому або іншому класу. Відповідно до цієї нотації, спочатку вказується назва класу, в якому визначений метод, а потім через крапку назва самого методу. Якщо метод визначений в деякому підкласі, то треба вказати весь ланцюжок класів, починаючи з найбільш загального з них. При цьому характерною ознакою методу є пара дужок, які використовуються для вказівки списку аргументів або формальних параметрів даного методу.

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

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

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

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

Ця сукупність завдань не стільки пов'язана з написанням кодів, скільки із загальним аналізом вимог до майбутньої програми, а також аналізом конкретної предметної області, для якої розробляється програма. Всі ці обставини привели до появи спеціальної методології, що отримала назву методології об’єктно-орієнтованого аналізу і проектування (ООАП).

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

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

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

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

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

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

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

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

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

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

· супровід програми,

· відмови від використання програми.

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

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

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

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

Поиск по сайту: