PrIS

71

За короткий період часу обидва інструментарії перетворилися на потужні системи розроблення програм з відповідними бібліотеками стандартних класів, що мають сотні різних властивостей і методів. Стосовно середовища MS Visual C++ 5/6 така бібліотека має спеціальну назву – MFC (Microsoft Foundation Classes), тобто фундаментальні класи від Microsoft. При цьому похідні класи успадковують властивості і методи батьківських класів. Нижче наводиться фраґмент ієрархії класів MFC у тому вигляді, як він зображений у відповідній документації (рис. 3.3).

CView

CScrollView

CFormView

CRecordView

CDaoRecordView

COleDBRecordView

CHtmlView

Рис. 3.3. Фраґмент ієрархії класів MFC, використовуваних у середовищі програмування MS Visual C++ 5/6.

Процес розроблення програм у середовищі Borland/Inprise Delphi також тісно пов'язаний з використанням бібліотеки стандартних класів – VCL (Visual Component Library) або бібліотеки візуальних компонентів. Ця бібліотека теж побудована за ієрархічним принципом, відповідно до якого компоненти рівнів, що розташовані нижче, успадковують властивості і методи вищерозміщених компонентів. Для цього випадку також наводимо фрагмент ієрархії класів VCL (рис. 3.4).

72

Рис. 3.4. Фраґмент ієрархії класів VCL, використовуваних у середовищі програмування Borland/Inprise Delphi 15.4.

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

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

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

73

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

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

ІНТЕРФЕЙС

РЕАЛІЗАЦІЯ

Рис. 3.5. Ілюстрація проховування внутрішніх деталей реалізації методів класів.

Примітка

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

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

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

74

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

Примітка

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

Унашому прикладі для операції вимкнути() можна визначити такі додаткові параметри, як час вимикання, деяку умову знаходження об'єкту

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

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

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

75

адекватним чином. Реакція програми при цьому теж зв'язується з наступними подіями.

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

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

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

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

Для виділення або ідентифікації компонентів предметної області запропоновано декілька способів і правил. Сам цей процес отримав назву

76

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

компонент, обов'язок, співробітники) [1]. Для кожного виділеного компоненту предметної області розробляється власна CRC-карточка (рис. 3.6).

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

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

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

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

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

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

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

77

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

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

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

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

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

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

Примітка

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

78

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

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

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

3.4. Методологія системного аналізу і системного моделювання

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

79

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

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

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

Розглянемо приклад. Як систему візьмемо "Автомобіль". Для цього випадку система охолоджування двигуна буде підсистемою "Автомобіля". З одного боку, двигун є елементом системи "Автомобіль". З іншого боку, двигун сам є системою, що складається з окремих компонентів, таких як циліндри, свічки запалення та ін. Тому система "Двигун" також буде підсистемою системи "Автомобіль".

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

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

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

80

закономірності її структури і процес функціонування, що фіксується на деякій мові або в іншій формі.

Прикладів моделей можна навести достатньо багато. Наприклад, аеродинамічна модель гоночного автомобіля або проектованого літака, модель ракетного двигуна, модель коливальної системи, модель системи електропостачання регіону, модель виборчої кампанії та ін.

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

Примітка

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

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

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