Зубенко, Омельчук - Програмування. Поглиблений курс

Розділ ІІ. ЕЛЕМЕНТИ ІНФОРМАТИКИ

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

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

Розглянемо як приклад кілька специфікацій функції n !. Скориста- ємося для цього засобами, розглянутими в попередніх підрозділах.

Приклад 2.47. Одинадцять специфікацій функції n !.

1) n ! – добуток перших n натуральних чисел, розпочинаючи з 1;

def

2) n ! = 1×2×...×n ;

def n

3) n ! = ∏i ;

i=1

4)(БФ) 0! =1 , (ІФ) (n +1)! = (n +1)×n ! ;

5)(БФ) n ! = g (1,n ), g (n,n ) =1;

(ІФ) g (i,n ) = i × g (s (i ),n );

6)найменший розв'язок функціонального рівняння f (n ) = (n = 0 →1|n × f (n −1));

7)n ! = μQ* (n ) – функція, породжена рекурентною системою (*)

a1 =1,ak = ak −1 * k,

(*)k − лiчильник, k1 =1,n − константа

іфільтром Q(k,n ) = k < n ;

241

ПРОГРАМУВАННЯ

8)

Ввести (n)

n:=!; k :=1; a :=1;

+

a:=a*k;

n:=n+1;

9)

{n:=!; k:=1; a:=1; i:=1; while (k<n) do {k:=k+1; a:=a*k;

}

}

10)

long f(int n) {int k=1;

long a=1;

while (k<n) do {k++; a*=k;

}

return a;

11)

long f(int n)

{

return (n<2) ? 1:n*f(n-1);

}

242

Розділ ІІ. ЕЛЕМЕНТИ ІНФОРМАТИКИ

Перші три специфікації відомі зі школи. Третій варіант використо- вує поняття добутку індексованої сукупності чисел (див. підрозд. 1.2.3); четвертий і п'ятий – два різновиди індуктивних означень (під- розд. 2.6.2). У них застосовано індукції відповідно типу згортки й роз- гортки. Шоста специфікація – функціональне рівняння (див. під- розд. 1.3.3); сьома – рекурентне означення (див. підрозд. 2.5.3); вось- ма – стандартна програма для обчислення n !; дев'ята – її лінійна фо- рма; десята й одинадцята – ітеративна й рекурсивна функції мови С.

Усі наведені специфікації є повними й точними, але різними за ме- тою та зрозумілістю. Перші вісім орієнтовані на людину, решта – на машинну обробку. Деякі з них відрізняються лише синтаксисом, на- приклад 1–3, 8 та 9, 4 та 11.

Найпростішими специфікаціями є 1 та 2, що показують, як обчис- лити значення n !. Щоб скористатися ними, треба лише вміти пере- множити два числа й розуміти українську мову. Наступним за прозо- рістю є, на наш погляд, індуктивний варіант типу розгортки 4. Най- складніші ж ті, що потребують володіння спеціальними поняттями й технічними навичками – 7 (методи розв'язку функціональних рів- нянь), 8 (методи побудови рекурентних співвідношень і стандартних програм), 10–11 (знання мови програмування С) ■

Серед відомих формальних мов специфікацій можна виділити та- кі, як VDM, Z, B, CCS, LOTOS тощо. Подібні мови призначені для роз- робки систем із підвищеними вимогами до безпеки.

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

Звернемось до практики програмування й порівняємо витрати на розробку систем без використання формальних специфікацій і з та- ким на різних стадіях. За окремими даними [120] у першому випадку вартість атестації системи становить біля 50 % усієї вартості продук- ту, а вартість проектування й реалізації вдвічі більше вартості етапу аналізу системи. У другому випадку вартості проектування й реаліза- ції, з одного боку, і аналізу – з іншого, зіставні, проте вартість атеста- ції значно зменшується. У цілому загальна вартість системи в обох випадках якщо й не зіставна, то різниця у вартості може нівелювати-

243

ПРОГРАМУВАННЯ

ся більшою надійністю системи, розробленою за допомогою формаль- них специфікацій.

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

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

2.7.3. МОВА UML

Серед практичних методів проектування систем важливе місце по- сідає об'єктно-орієнтоване проектування й програмування систем (див. підрозд. 2.3). В ООП для опису архітектурних моделей найчас- тіше використовується мова специфікацій UML (Unified Modeling Language). Стисло розглянемо її основні ідеї й засоби.

В UML знайшли відображення методи об'єктно-орієнтованого мо- делювання, розроблені Бучем, Рамбо (метод Object Modeling Technique

– OMT) і Якобсоном (метод Object-Oriented Software Engineering – OOSE). Метод Буча був орієнтований на проектування систем, OMT – на аналіз, а OOSE забезпечував можливості для специфікації бізнес- проектів і аналізу вимог за допомогою сценаріїв використання. Усі вказані методи відомі як засоби візуального моделювання, що добре зарекомендували себе на практиці.

Зокрема, UML дозволяє описати визначальні типи об'єктних моделей:

•структурні (статичні) – описується структура сутностей системи, включаючи класи, інтерфейси, відношення, атрибути;

•моделей поведінки (динамічних) – описується поведінка (функці- онування) об'єктів системи, включаючи методи, взаємодію, процес зміни станів окремих компонент чи всієї системи.

UML забезпечує моделювання різних зображень архітектури:

•структури,

•(динамічної) поведінки,

•керування моделями.

Концептуальна модель UML. Словник UML містить сутності, від- ношення й діаграми. Перші є первинними елементами моделі, другі пов'язують різні сутності, а треті групують сукупності сутностей.

В UML існує низка семантичних правил, що дозволяють коректно й однозначно визначати:

• імена, які можна давати сутностям, відношенням і діаграмам;

244

Розділ ІІ. ЕЛЕМЕНТИ ІНФОРМАТИКИ

•область дії імен (контекст, в якому ім'я має деяке значення);

•видимість (коли імена видимі й можуть використовуватися ін- шими елементами);

•цілісність (узгоджене співвідношення елементів системи);

•виконання моделі.

UML має механізми:

•специфікації;

•доповнення;

•розподілу;

•розширення.

Сутності мови UML. В UML є чотири типи сутностей:

•структурні;

•поведінкові;

•групувальні;

•анотаційні.

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

Поведінкові сутності є динамічними складовими моделі UML. Виділяють такі типи поведінкових сутностей: взаємодія й автомат.

Групувальні сутності є організуючими частинами моделі UML. На даний момент реалізована лише одна групувальна сутність – пакет.

Анотаційні сутності – роз'яснювальні частини моделі UML, що зображуються примітками.

Відношення мови UML. В UML існує чотири типи відношень:

•залежність;

•асоціація;

•узагальнення;

•реалізація.

Є також їхні варіації, наприклад уточнення, трасування, включен- ня й розширення (для залежностей), агрегація й композиція.

Діаграми мови UML. Це основні об'єкти UML. Існує кілька типів діаграм, що подають різні аспекти систем. Набори діаграм дозволяють отримати достатньо повне уявлення про всю проектовану систему та її окремі компоненти. Діаграма в UML – це графічне

245

ПРОГРАМУВАННЯ

подання набору елементів, зображуване зазвичай у вигляді зв'язного графа з вершинами (сутностями) і ребрами (відношеннями).

В UML визначено вісім видів діаграм, кожна з яких може містити елементи певного типу. Типи можливих елементів і відношень між ними залежать від виду діаграми. Види діаграм:

•діаграма використання;

•діаграма класів;

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

•діаграми реалізації, до яких належать діаграми компонентів і розгортання.

Коментар приєднується таким відношенням: .

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

Діаграми прецедентів є основою для подальшої деталізації системи у формі логічних і фізичних моделей.

Окрема діаграма прецедентів складається з:

246

Розділ ІІ. ЕЛЕМЕНТИ ІНФОРМАТИКИ

Між актором і прецедентом можливий зв'язок асоціації, який ука- зує на те, що актор ініціює відповідний прецедент:

Актор

Знайти найкоротший маршрут

Відношення розширення (extend) є відношенням залежності між ба- зовим та іншим прецедентом, функціональна поведінка якого викори- стовується базовим не завжди, а лише при виконанні деяких умов. Стрілка напрямлена до базового прецеденту (у всіх інших відношеннях

– від прецеденту, що викликає, до того, який викликається):

Переглянути стан рахунку

<<extend>>

Роздрукувати квитанцію

Відношення включення (include) у мові UML є відношенням залежно- сті між прецедентами й указує на те, що задана поведінка для одного прецеденту включає як обов'язкову складову частину поведінку іншого:

247

ПРОГРАМУВАННЯ

<<include>>

Видача готівки в банку Перевірка стану рахунку

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

Відношення узагальнення може бути як між двома акторами, так і між двома варіантами використання. Для прецедентів воно вказує, що один із них (нащадок) є спеціалізацією іншого (батьківського). Наприклад:

Нащадок успадковує всі властивості поведінки батьківського пре- цеденту (актора) і може мати додаткові.

Приклад узагальнення між акторами:

Службовець

Діаграма класів (Class diagram). Описує статичну структуру класів. Дозволяється на концептуальному рівні формувати словник предметної області й на рівнях специфікацій і реалізацій визначати структуру класів у програмній реалізації системи.

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

248

Розділ ІІ. ЕЛЕМЕНТИ ІНФОРМАТИКИ

Клас зображується прямокутником, розділеним на три секції:

NewClass

name name2 name3

opname() opname2() opname3()

.

У верхній секції розміщено ім'я, у середній – атрибути, у нижній – методи класу.

Атрибути й методи класу описуються із зазначенням специфікаторів доступу. В UML вони позначаються +, # та – і означають:

Виділяють такі типи класів (класифікація за призначенням):

• прикордонні (boundary), або інтерфейсні:

Boundary

• класи-сутності (entity):

Entity

• керівні (control) (класи-менеджери): .

Control

Інтерфейси позначаються так: Interface

249

ПРОГРАМУВАННЯ

Класи можуть бути абстрактними чи конкретними, що зазначається при їхньому описі.

Типи відношень між класами: узагальнення – ; залежність – ; асоціація – ; агрегація – ; композиція – .

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

Як обмеження можуть бути використані такі ключові слова UML: {complete} – у даному відношенні узагальнення специфіковані всі

класи-нащадки – інших нащадків у даного класу бути не може; {incomplete} – на цій діаграмі зображені не всі нащадки, додавання

нових нащадків не вплине на побудовану діаграму;

{disjoint} – класи-нащадки не можуть містити об'єктів, що одночас- но є екземплярами двох чи більше класів;

{overlapping} – окремі екземпляри класів-нащадків можуть належа- ти одночасно кільком класам.

Приклад успадкування:

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

250