Передмова наукового редактора серії підручників «КОМП’ЮТИНҐ»

Міністерство освіти та науки України

В.В. Литвин, Н.Б. Шаховська

Проектування інформаційних систем

Навчальний посібник

з курсу “Проектування інформаційних систем”

для студентів базового «Консолідована інформація»

Львів – 2010

У посібнику розглядаються основні принципи логічного та фізичного проектування інформаційних систем. Перша частина – структурне проектування – присвячений опису таких засобів проектування, як діаграми потоків даних, діаграми «сутність-зв’язок”, діаграми станів. Далі детально описується фізичне моделювання та методи фізичного моделювання.

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

Друга части присвячена об’єктно-орієнтовану проектуванню. Розглядаються поняття складність, об'єктна модель. Далі вводяться поняття классу та об'єкту, здійснюється класифікація засобів об'єктно-орієнтовано проектування.

Буде корисним для студентів, що навчаються за напрямом підготовки фахівців “Комп’ютерні науки”, «Консолідована інформація».

Відповідальний за випуск: д.т.н., проф. Пасічник В.В.

Рецензенти: д.т..н., професор Бунь Р.А.

д.ф.-м.н., професор Цегелик Г.Г.

д.т.н., доцент Романишин Ю.М.

Зміст

Вступне слово авторів. 19

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ. 20

РОЗДІЛ 1. Складність розроблення інформаційних систем.. 21

1.1. Складність програмного забезпечення. 22

1.2. Структура складних систем.. 25

1.2.1. Приклади складних систем.. 25

1.2.2. П'ять ознак складної системи. 28

1.2.3. Організована і неорганізована складність. 30

1.3. Методи подолання складності 33

1.3.1. Роль декомпозиції 33

1.3.3. Роль абстракції 36

1.3.4. Роль ієрархії 37

1.4. Про проектування складних систем.. 40

1.4.1. Інженерна справа як наука і мистецтво. 40

1.4.2. Сенс проектування. 41

Висновки. 44

Контрольні питання. 44

РОЗДІЛ 2. Інформаційні системи та їх характеристики. 45

2.1. Базові означення. 45

2.2. Методи проектування інформаційних систем.. 49

2.3. Види інформаційних систем.. 51

2.4. Рівні моделей даних. 55

Висновки. 62

Контрольні питання. 63

РОЗДІЛ 3. Розвиток методологій проектування інформаційних систем.. 64

3.1. Методологія процедурно-орієнтованого програмування. 64

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

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

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

Висновки. 81

Контрольні питання. 82

РОЗДІЛ 4. Історичний огляд розвитку структурної та об'єктно-орієнтованої методологій проектування інформаційних систем.. 83

4.1. Передісторія. Математичні основи. 83

4.1.1. Теорія множин. 83

4.1.2. Теорія графів. 87

4.1.3. Семантичні мережі 91

4.2. Діаграми структурного системного аналізу. 94

4.3. Основні етапи розвитку UML.. 94

Висновки. 100

Контрольні питання. 100

РОЗДІЛ 5. Структурний підхід. 102

5.1. Принципи структурного підходу до проектування. 102

5.2. Структурний аналіз. 103

5.3. Структурне проектування. 105

5.4. Методологія структурного аналізу. 106

5.5. Інструментальні засоби структурного аналізу та проектування. 109

Висновки. 109

Контрольні питання. 110

РОЗДІЛ 6. Методологія функціонального моделювання SADT. 111

6.1. Основні елементи. 111

6.2. Типи зв’язків. 113

6.3. Техніка побудови. 115

6.4. Діаграма бізнес – функцій. 116

6.4.1. Призначення діаграми бізнес-функцій. 116

6.4.2. Основні елементи. 117

Висновки. 118

Контрольні питання. 118

РОЗДІЛ 7. Діаграми потоків даних. 119

7.1. Призначення діаграм потоків даних та основні елементи. 119

7.1.1. Зовнішні сутності 120

7.1.2. Процеси. 121

7.1.3. Накопичувачі даних. 122

7.1.4. Потоки даних. 122

7.2. Методологія побудови DFD. 122

Висновки. 125

Контрольні приклади. 125

РОЗДІЛ 8. Діаграми "сутність-зв'язок", атрибутів, категоризації 127

8.1. Діаграма «сутність-зв’язок». 127

8.2. Діаграма атрибутів. 129

8.3. Діаграма категоризації 130

8.4. Обмеження діаграм сутність-зв’язок. 131

8.5. Методологія IDEF1. 134

Висновки. 137

Контрольні питання. 138

РОЗДІЛ.9. Діаграми переходів станів. 139

9.1. Основні елементи. 139

9.2. Типи керуючих потоків. 140

9.3. Принципи побудови. 142

Висновки. 143

Контрольні питання. 143

РОЗДІЛ. 10. Структурне проектування на етапі проектування програмного забезпечення 145

10.1. Структурні карти Константайна. 145

10.2. Структурні карти Джексона. 147

Висновки. 150

Контрольні питання. 150

РОЗДІЛ 11. Засоби створення діаграм.. 151

11.1. Призначення CASE-технологій. 151

11.2. Інструментальний засіб BPwin. 153

11.2.1. IDEF0. 154

11.2.2. DFD.. 157

11.2.3. IDEF3. 160

11.2.4. Інші діаграми BPWin. 162

11.2.5. Моделі AS IS і TO BE.. 164

11.3. ERwin. 166

11.3.1. Основні властивості 166

11.3.2. Стандарт IDEF1X.. 169

11.4. Програмний засіб Visio. 176

Висновки. 180

Контрольні питання. 180

РОЗДІЛ 12. Приклади моделей структурного проектування. 182

12.1. Системний аналіз області наукових досліджень. 182

12.1.1. Аналіз предметної області 182

12.1.2. ER - діаграми системи аналізу наукових досліджень. 188

12.1.3. DF-діаграми системи аналізу наукових досліджень. 189

12.2. Системний аналіз біржі праці 191

12.2.1. Дерево цілей. 192

12.2.2. Опис об’єктів предметної області 193

12.2.3. Концептуальна модель. 196

РОЗДІЛ 13. Характеристики CASE-засобів. 203

13.1. Silverrun+JAM... 203

13.1.1. Silverrun. 203

13.1.2. JAM... 205

13.2. Vantage Team Builder (Westmount I-CASE) + Uniface. 208

13.2.1. Vantage Team Builder (Westmount I-CASE) 208

13.2.2. Uniface. 210

13.3. Designer/2000 + Developer/2000. 211

РОЗДІЛ 14. Об'єктна модель. 214

14.1. Еволюція об'єктної моделі 214

14.1.1. Основні положення об'єктної моделі 214

14.1.2. OOP, OOП і ООА.. 215

14.2. Складові частини об'єктного підходу. 219

14.2.1. Парадигми програмування. 219

14.2.2. Абстрагування. 220

14.2.3. Інкапсуляція. 227

14.2.4. Модульність. 232

14.2.5. Ієрархія. 236

14.2.6. Типізація. 241

14.2.7. Паралелізм.. 248

14.2.8. Збереженість. 250

14.3. Застосування об'єктної моделі 251

14.3.1. Переваги об'єктної моделі 251

14.3.2. Використання об'єктного підходу. 253

14.3.3. Відкриті питання. 253

Висновки. 254

Контрольні питання. 254

РОЗДІЛ 15. Класи й об'єкти. 256

15.1. Природа об'єкта. 256

15.1.1. Що є й що не є об'єктом?. 256

15.1.2. Стан. 258

15.1.3. Поведінка. 260

15.1.4. Ідентичність. 265

15.2. Відношення між об'єктами. 271

15.2.1. Типи відношень. 271

15.2.2. Зв'язки. 271

15.2.3. Агрегація. 275

15.3. Природа класів. 276

15.3.1. Що таке клас?. 276

15.3.2. Інтерфейс і реалізація. 277

15.3.3. Життєвий цикл класу. 278

15.4. Відношення між класами. 279

15.4.1. Типи відношень. 279

15.4.2. Асоціація. 280

15.4.3. Успадкування. 281

15.4.4. Агрегація. 295

15.4.5. Використання. 297

15.4.6. Інсталювання (Параметризація) 297

15.4.6. Метакласи. 300

15.5. Взаємозв'язок класів і об'єктів. 302

15.5.1. Відношення між класами й об'єктами. 302

15.5.2. Роль класів і об'єктів в аналізі й проектуванні 302

Висновки. 303

Контрольні питання. 303

РОЗДІЛ 16. Класифікація. 305

16.1. Важливість правильної класифікації 305

16.1.1. Класифікація й об’єктно-орієнтовне проектування. 305

16.1.2. Труднощі класифікації 306

16.2. Ідентифікація класів і об'єктів. 309

16.2.1. Класичний і сучасний підходи. 309

16.2.2. Об’єктно-орієнтований аналіз. 312

16.3. Ключові абстракції й механізми. 318

16.3.1. Ключові абстракції 318

16.3.2. Ідентифікація механізмів. 320

Висновки. 321

Контрольні питання. 322

РОЗДІЛ 17. Основні компоненти мови UML.. 323

17.1. Призначення мови UML.. 325

17.2. Загальна структура мови UML.. 328

17.3. Пакети в мові UML.. 331

17.4. Основні пакети мета-моделі мови UML.. 334

17.5. Специфіка опису мета-моделі мови UML.. 344

17.6. Особливості зображення діаграм мови UML.. 348

Висновки. 353

Контрольні питання. 353

РОЗДІЛ 18. Діаграма варіантів використання (use case diagram) 355

18.1. Варіант використання. 356

18.2. Актори. 358

18.3. Інтерфейси. 360

18.4. Примітки. 362

18.5. Відношення на діаграмі варіантів використання. 363

18.5.1. Відношення асоціації 364

13.5.2. Відношення розширення. 366

18.5.3. Відношення узагальнення. 368

18.5.4. Відношення включення. 370

18.6. Приклад побудови діаграми варіантів використання. 371

18.7. Рекомендації з розроблення діаграм варіантів використання. 376

Висновки. 379

Контрольні питання. 379

РОЗДІЛ 19. Діаграма класів (class diagram) 381

19.1. Клас. 382

19.1.1. Ім'я класу. 383

19.1.2. Атрибути класу. 384

19.1.3. Операція. 389

19.2. Відношення між класами. 392

19.2.1. Відношення залежності 392

19.2.2. Відношення асоціації 394

19.2.3. Відношення агрегації 397

19.2.4. Відношення композиції 399

19.2.5. Відношення узагальнення. 400

19.3. Інтерфейси. 404

19.4. Об'єкти. 405

19.5. Шаблони або параметризовані класи. 406

19.6. Рекомендації з побудови діаграми класів. 408

Висновки. 409

Контрольні питання. 409

РОЗДІЛ 20. Діаграма станів (statechart diagram) 410

20.1. Автомати. 411

20.2. Стан. 414

20.2.1. Ім'я стану. 416

20.2.2. Список внутрішніх дій. 416

20.2.3. Початковий стан. 417

20.2.4. Кінцевий стан. 418

20.3. Перехід. 418

20.3.1. Подія. 419

20.3.2. Сторожова умова. 420

20.3.3.Вираз дії 422

15.4. Складений стан і підстан. 423

20.4.1. Послідовні підстани. 424

20.4.2. Паралельні підстани. 425

15.5. Історичний стан. 427

20.6. Складні переходи. 428

15.6.1. Переходи між паралельними станами. 429

20.6.2. Переходи між складеними станами. 430

20.6.3. Синхронізуючі стани. 430

20.7. Рекомендації з побудови діаграм станів. 433

Висновки. 434

Контрольні питання. 435

РОЗДІЛ 21. Діаграма діяльності (activity diagram) 436

21.1. Стан дії 437

21.2. Переходи. 438

21.3. Доріжки. 444

21.4. Об'єкти. 445

21.4. Об'єкти. 446

21.5. Рекомендації до побудови діаграм діяльності 449

Висновки. 451

Контрольні питання. 451

Розділ 22. Діаграма послідовності (sequence diagram) 452

22.1. Об'єкти. 453

22.1.1. Лінія життя об'єкта. 454

22.1.2. Фокус керування. 454

22.2. Повідомлення. 456

22.2.1. Розгалуження потоку керування. 458

22.2.2. Стереотипи повідомлень. 460

22.2.3. Тимчасові обмеження на діаграмах послідовності 462

22.2.4. Коментарі або примітки. 463

22.3. Приклад побудови діаграми послідовності 463

22.4. Рекомендації з побудови діаграм послідовності 465

Висновки. 467

Контрольні питання. 467

РОЗДІЛ 23. Діаграма кооперації (collaboration diagram) 468

23.1. Кооперація. 469

23.2. Об'єкти. 472

23.2.1. Мультиоб'єкт. 474

23.2.2. Активний об'єкт. 474

23.2.3. Складений об'єкт. 476

23.3. Зв'язки. 477

23.3.1. Стереотипи зв'язків. 477

23.4. Повідомлення. 478

23.4.1. Формат запису повідомлень. 480

23.5. Приклад побудови діаграми кооперації 483

23.6. Рекомендації з побудови діаграм кооперації 485

Висновки. 486

Контрольні питання. 486

РОЗДІЛ 24. Діаграма компонентів (component diagram) 488

24.1. Компоненти. 489

24.1.1. Ім'я компоненту. 490

24.1.2. Види компонент. 491

24.2. Інтерфейси. 493

24.3. Залежності 494

24.4. Рекомендації з побудови діаграми компонент. 497

Висновки. 498

Контрольні питання. 498

РОЗДІЛ 25. Діаграма розгортання (deployment diagram) 500

25.1. Вузол. 501

25.2. З'єднання. 504

25.3. Рекомендації з побудови діаграми розгортання. 507

Висновки. 510

Контрольні питання. 510

РОЗДІЛ 26. Особливості реалізації мови UML в CASE-інструментарії Rational Rose. 511

26.1. Загальна характеристика CASE-засобу Rational Rose. 512

26.2. Особливості робочого інтерфейсу Rational Rose. 513

26.1.1. Головне меню програми. 514

26.1.2. Стандартна панель інструментів. 515

26.1.3. Вікно браузера. 515

26.1.4. Спеціальна панель інструментів. 516

26.1.5. Вікно діаграми. 517

26.1.6. Вікно документації 518

26.1.7. Вікно журналу. 518

26.3. Початок роботи над проектом у середовищі Rational Rose. 519

26.4. Розроблення діаграми варіантів використання в середовищі Rational Rose 520

26.5. Розроблення діаграми класів у середовищі Rational Rose. 522

26.6. Розроблення діаграми станів у середовищі Rational Rose. 525

26.7. Розроблення діаграми послідовності в середовищі Rational Rose. 526

26.8. Розроблення діаграми кооперації в середовищі Rational Rose. 527

26.9. Розроблення діаграми компонентів у середовищі Rational Rose. 528

26.10. Розроблення діаграми розгортання в середовищі Rational Rose. 530

Контрольні питання. 532

Висновок. 533

Передмова наукового редактора серії підручників «КОМП’ЮТИНҐ»

Шановний читачу!

Започатковуючи масштабний освітньо-науковий проект підготовки і видання серії сучасних підручників під загальним гаслом «КОМП’ЮТИНҐ» та загальним методичним патронуванням його Інститутом інноваційних технологій та змісту освіти МОН України, мені, як ініціатору та науковому керівнику, неодноразово доводилось прискіпливо аналізувати загальну ситуацію в царині сучасного україномовного підручника комп’ютерно-інформатичного профілю. Загалом, позитивна тенденція останніх років ще не співмірна з надзвичайно динамічним розвитком як освітньо-наукової та виробничої сфери комп’ютинґу, так і стрімким розширенням потенційної цільової читацької аудиторії цього профілю. Іншими словами, попередній аналіз засвідчує наявність значного соціального замовлення під реалізацію пропонованого Вашій увазі проекту.

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

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

Читач, безсумнівно, зверне увагу, на нашу послідовну промоцію нового терміну КОМП’ЮТИНҐ (computing, англ.), який є вдалим та комплексно узагальнювальним для означення галузі знань, науки, виробництва, надання відповідних послуг та сервісів. Видається доречним подати ретроспективу як самого терміну комп’ютинґ, так і широкої освітньої, наукової, бізнесової та виробничої сфери діяльності, що іменується комп’ютинґом.

Уперше термін комп’ютинґ уведений 1998 року Яном Фостером з арагонської національної лабораторії Чікагського університету та Карлом Кесельманом з інституту інформатики штату Каліфорнія (США) та запропонований для означення комплексної галузі знань, яка включає проектування та побудову апаратних і програмних систем для широкого кола застосувань: вивчення процесів, структур і керування інформацією різних видів; виконання наукових досліджень із застосування комп’ютерів та їх інтелектуальності; створення і використання комунікаційних та демонстраційних засобів, пошуку та збирання інформації для конкретної мети і т. ін.

У подальшому сфера використання терміну суттєво розширилась, зокрема, в освітньо-науковій царині. Його почали використовувати для означення відповідної галузі знань, для якої періодично (орієнтовно щодесять років) провідними університетами та професійними асоціаціями фахівців розробляються та імплементуються навчальні плани і програми, котрі в подальшому набувають статусу міжнародно визнаних освітньо-професійних стандартів. Зокрема, варто акцентувати увагу на версіях підсумкового документу “Computing CURRICULA” 2001 року. За окремими повідомленнями можна стверджувати, що черговий збірник стандартів “Computing CURRICULA” буде поданий професійному загалу до 2011 року. Перше організаційне засідання відповідних фахових робочих груп відбулось у Чікагському університеті влітку 2007 року.

Для формування цілісного однорідного подання суті КОМП’ЮТИНҐУ ми базуємось на сучасних наукових уявленнях з максимально можливим строгим покомпонентним викладенням основних базових означень та понять, які склались історично і є загально визнаними в професійних колах. Водночас для побудови цілісної зваженої картини ми використали певні узагальнення та загальносистемні класифікаційні підходи.

Безсумнівно, що базовим та фундаментальним поняттям було, є і залишається поняття ІНФОРМАТИКИ (informatique - франц.), як фундаментальної науки, котра вивчає найбільш загальні закони та закономірності процесів відбору, реєстрації, збереження, передавання, захисту, опрацювання та подання інформації. У такому сенсі як фундаментальна наука інформатика була подана в 70-х роках ХХ ст. При цьому хочу відразу ж застерегти від примітивного ототожнення, яке часто є наївно вживаним щодо еквівалентності понять «інформатика» (informatique - франц.) та «комп’ютерні науки» (computer science - англ.). Такі ототожнення з певною мірою наближення можливі щодо розширеного сучасного трактування інформатики як, загалом, прикладної науки про обчислення, збереження, опрацювання інформації та побудову прикладних інформаційних технологій і систем на їх базі. Таке трактування є характерним в ряді європейських країн. Строге ж означення та подання предмету досліджень інформатики, а саме – інформації, має справу з фундаментальним не редукованим поняттям і фіксується у словниках як «informatio» (лат.) – відомості, повідомлення. Вивченням та всестороннім аналізом сутності інформації опікується наука, що називається „теорія інформації”. На нашу думку, основною принциповою відмінністю між інформатикою та комп’ютерними науками є те, що перша в своєму первинному поданні відноситься до категорії фундаментальних наук, як то фізика, математика, хімія і т. ін. У той же час комп’ютерні науки загалом за своєю сутнісною природою та всіма наявними ознаками належать до категорії прикладних наук, які базуються на фундаментальних законах та закономірностях інформаційних процесів, котрі вивчаються в рамках фундаментальної науки інформатики.

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

Для комп’ютерних наук характерною ознакою виділення їх у спектрі прикладних наук є об’єкт прикладення знань, умінь та навичок у контексті конкретного об’єкту – обчислювача (комп’ютера). Іншою відокремленою прикладною науковою галуззю, що базується на підвалинах інформатики, є розділ прикладних наук, основним об’єктом яких є сам процес обчислень. Це науки, які іменуються обчислювальними науками - «computationally science» (англ.). Традиційно сюди відносять обчислювальну та комп’ютерну математику.

Третьою прикладною науковою галуззю, яка ґрунтується на фундаментальних законах інформатики, є розділ прикладних наук, основним об’єктом яких є інформаційний ресурс (у сучасній літературі часто вживається поняття «контент» (сontent-англ.). У розумінні інформаційного наповнення. Ці прикладні науки одержали назву „інформаційні науки” (information science - англ.).

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

Узагальнюючи класифікаційно-ознакову схему, стверджуємо, що на базі фундаментальної науки ІНФОРМАТИКИ формуються три прикладні наукові галузі, а саме: комп’ютерні науки, обчислювальні науки та інформаційні науки з відповідними об’єктами досліджень у своїх сферах.

Ще раз підкреслимо, що результати фундаментальних наукових досліджень не призначені для безпосереднього промислового використання, у той же час результати прикладних наукових досліджень, як правило, призначені для створення та удосконалення нових технологій.

Гносеологічний аналіз подальшого формування інженерного рівня сфери КОМП’ЮТИНҐУ невідворотно веде до структурного подання базових типів інженерій, які трактуються у класичному розумінні. ІНЖЕНЕРІЯ (майстерний - від лат. ingeniosus) – це наука про проектування та побудову (чит. створення) об’єктів певної природи. У цьому контексті природними для сфери КОМП’ЮТИНҐУ є декілька видів інженерії. Мова йтиме про:

КОМП’ЮТЕРНУ ІНЖЕНЕРІЮ (computer engineering, англ.), яка охоплює проблематику проектування та створення об’єктів комп’ютерної техніки;

ПРОГРАМНУ ІНЖЕНЕРІЮ (software engineering, англ.), яка опікується проблематикою проектування та створення об’єктів, що іменуються програмними продуктами;

ІНЖЕНЕРІЮ ДАНИХ ТА ЗНАНЬ (data & knowledge engineering, англ.), інженерія, яка опікується проектуванням та створенням інформаційних продуктів;

інженерію, яка опікується проектуванням та створенням міжкомпонентних (інтерфейсних) взаємозв’язків та формуванням цілісних системних об’єктів, усе частіше іменують СИСТЕМНОЮ ІНЖЕНЕРІЄЮ (systems engeneering, англ.).

У разі такого структурно-класифікаційного подання видів інженерій сфери комп’ютинґу зазначимо, що кожен з них у цьому трактуванні є „відповідальним” за певний тип забезпечення, а саме апаратного (hardware, англ.), програмного (software, англ.), інформаційного (dataware, англ.) та між компонентного (middleware, англ.). Інформаційну технологію (ІТ) можна трактувати як певну точку в чотиривимірному просторі зазначених інженерій. При цьому слід обов’язково зважити на певну частку наближення та інтерпретації цього простору як дискретного та неметричного.

У зв’язку з поширеним різночитанням та трактуванням поняття інформаційної технології (ІТ) видається необхідним детальніше подати сутнісну структуру цього терміну, використовуючи при цьому термінологічні статті популярного інформаційного ресурсу, яким є Wikipedia - (http://www.wikipedia.org/).

Технологія (від грецького téchne – мистецтво, майстерність, вміння та грецького logos – знання), сукупність методів та інструментів для досягнення бажаного результату, спосіб перетворення чогось заданого в необхідне. Технологія – це наукова дисципліна, в рамках якої розробляються та удосконалюються способи й інструменти виробництва.

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

Технологія включає в себе методи, прийоми, режими роботи, послідовність операцій та процедур, вона тісно взаємопов’язана із засобами, що застосовуються, обладнанням, інструментами, використовуваними матеріалами. За методологією ООН – технологія в чистому вигляді охоплює методи та техніку виробництва товарів і послуг (dissembled technology, англ.); втілена технологія охоплює машини, обладнання, споруди, виробничі системи та продукцію з високими техніко-економічними параметрами (embodied technology, англ.). Матеріальна технологія (МТ) створює матеріальний продукт. Інформаційна технологія (ІТ) створює інформаційний продукт на основі інформаційних ресурсів.

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

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

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

Комплексний виклад структурованого подання галузі КОМП’ЮТИНҐУ дозволяє, загалом, чіткіше уявити проблематику та тематику підручників, котрі будуть виходити в світ у однойменній освітньо-науковій серії. Для кращого розуміння в майбутньому ще раз наведемо означення сфери КОМП’ЮТИНҐУ як галузі знань (науки, виробництва, бізнесу та надання послуг), предметом якої є комплексні дослідження, розроблення, впровадження та використання інформаційних систем, складовими елементами яких є інформаційні технології, що реалізовані на основі сучасних інженерних досягнень комп’ютерної інженерії, інженерії програмного забезпечення, інженерії даних та знань, системної інженерії, котрі базуються на фундаментальних законах та закономірностях інформатики.

Автори підручників серії «КОМП’ЮТИНҐ» пропонують значний перелік навчальних дисциплін, котрі, з одного боку, включаються до сфери комп’ютинґу за означенням, а, з іншого боку, їх предмет ще не знайшов якісного висвітлення у вітчизняній навчальній літературі для вищої школи. Перший крок ми робимо у 2008 році, виданням принаймні десяти книг серії з подальшим її п’ятикратним розширенням до 2011 року. Структурно серія подається узагальненими профілями як то:

- фундаментальні проблеми комп’ютинґу;

- комп’ютерні науки;

- комп’ютерна інженерія;

- програмна інженерія;

- інженерія даних та знань;

- системна інженерія;

- інформаційні технології та системи.

При цьому зауважу, що наведені укрупнені профілі серії підручників загалом співпадають з профілями бакалавратів, зафіксованих у підсумковому звіті “Computing CURRICULA” редакції 2006 року. Ми розуміємо, що чітка завершена будівля комп’ютинґу з’явиться лише в перспективі, а наша праця буде подаватись як активний труд будівничих з якнайшвидшого втілення в життя проекту цієї, без перебільшення, ґрандіозної будівлі сучасного інформаційного суспільства. Я запрошую потенційних авторів долучитись до цього освітньо-наукового проекту, а шановних читачів виступити в ролі творчих критиків та опонентів. Буду вдячний за Ваші побажання, зауваження та пропозиції.

З глибокою повагою науковий редактор серії підручників «КОМП’ЮТИНҐ», д.т.н., професор Володимир Пасічник.

Вступне слово авторів

Структурно посібник складається з двох частин.

Перша частина – структурне проектування – присвячений опису таких засобів проектування, як діаграми потоків даних, діаграми «сутність-зв’язок”, діаграми станів. Далі детально описується фізичне моделювання та методи фізичного моделювання.

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

Друга части присвячена об’єктно-орієнтовану проектуванню. Розглядаються поняття складність, об'єктна модель. Далі вводяться поняття классу та об'єкту, здійснюється класифікація засобів об'єктно-орієнтовано проектування.

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

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

Викладений у посібнику матеріал презентує методику формування знань з методів системного аналізу та застосування цих знань при створенні інформаційних систем. Методи системного аналізу та інформатики подаються у посібнику як «міст» між теорією та практикою побудови прикладних корпоративних інформаційних систем

Проаналізовано принципи побудови, структуру і технологію використання CASE-засобів для аналізу бізнес-процесів.

У додатках подано приклади проектування інформаційних систем з використанням Case-засобів, Visio, BpWin, ERWin.

ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ

АБД – адміністратор бази даних

БД –база даних

ЖЦ – життєвий цикл

ІАД –інтелектуальний аналіз даних

ІАС – інформаційно-аналітична система

ІС - інформаційна система

КД – контекстна діаграма

КІАС – корпоративна інформаційно-аналітична система

МС – міні специфікація

ООА – об’єктно-орієнтований аналіз

ООАП – об’єктно-орієнтований аналіз і проектування

ООП – об’єктно-орієнтоване проектування

ПА – програмний агент

ПЗ – програмне забезпечення

ПО – предметна область

ППП – промисловий програмний продукт

РБД – розподілена база даних

СКБД – системи керування базами даних

СППР – система підтримки прийняття рішень

СОД – система опрацювання даних

ССА – системний структурний аналіз

ТСД – тематичне сховище даних

РОЗДІЛ 1. Складність розроблення інформаційних систем

à Складність програмного забезпечення

à Структура складних систем

à Методи подолання складності

à Зміст проектування складних систем

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

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

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

1.1. Складність програмного забезпечення

Складність програмного забезпечення - зовсім не випадкова її властивість. Складність виникає через чотири основні причини:

· складністю реальної ПО, з якої виходить замовлення на розроблення програмного забезпечення (ПЗ);

· складністю керування процесом розроблення;

· необхідністю забезпечити достатню гнучкість програми;

· незадовільними способами опису поведінки великих дискретних систем.

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

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

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

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

· під супроводом розуміється усунення помилок;

· під еволюцією - внесення змін до системи у відповідь на вимоги, що змінилися, до неї;

· під збереженням - використання всіх можливих і неможливих способів для підтримки життя в „дряхлій” системі, що розпадається на частини.

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

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

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

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

Всередині великої прикладної програми можуть існувати сотні і навіть тисячі змінних і декілька потоків керування. Повний набір цих змінних, їх поточних значень, поточної адреси і стеку виклику для кожного процесу описує стан прикладної програми в кожний момент часу. Оскільки виконання нашої програми здійснюється на цифровому комп'ютері, ми маємо систему з дискретними станами. Аналогові системи, такі, як рух кинутого м'яча, навпаки, є безперервними. Коли ми говоримо, що система описується безперервною функцією, ми маємо на увазі, що в ній немає прихованих сюрпризів. Невеликі зміни вхідних параметрів завжди викличуть невеликі зміни вихідних. З іншої сторони, дискретні системи за своєю природою мають кінцеве число можливих станів, хоча у великих системах це число відповідно до правил комбінаторики дуже велике. Ми прагнемо проектувати системи, розділяючи їх на частини так, щоб одна частина мінімально впливало на іншу. Проте переходи між дискретними станами не можуть моделюватися безперервними функціями. Кожна подія, зовнішня по відношенню до програмної системи, може перевести її в новий стан, і, більш того, перехід з одного стану в інший не завжди детермінований. За несприятливих умов зовнішня подія може порушити поточний стан системи через те, що її творці не змогли передбачити всі можливі варіанти. Уявимо собі пасажирський літак, в якому система керування польотом і система електропостачання об'єднані. Було б дуже неприємно, якби від включення пасажиром, що сидить на місці 17В, індивідуального освітлення літак негайно увійшов би у глибокого піке. У безперервних системах така поведінка була б неможливою, але в дискретних системах будь-яка зовнішня подія може вплинути на будь-яку частину внутрішнього стану системи. Це, вочевидь, і є головною причиною обов'язкового тестування наших систем; але річ у тому, що за винятком найтривіальніших випадків, всеосяжне тестування таких програм провести неможливо. І доки у нас немає ні математичних інструментів, ні інтелектуальних можливостей для повного моделювання поведінки великих дискретних систем, ми повинні задовольнитися розумним рівнем упевненості в їх правильності.

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

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

Як ми можемо змінити ці справи? Оскільки проблема виникає в результаті складності структури програмних продуктів, ми пропонуємо спочатку розглянути способи роботи із складними структурами в інших областях. Насправді, можна навести безліч прикладів успішно функціонуючих складних систем. Деякі з них створені людиною, наприклад: космічний човник Space Shuttle, тунель під Ла-Маншем, великі фірми типу Microsoft або General Electric. У природі існують ще складніші системи, наприклад система кровообігу людини або рослина.

1.2. Структура складних систем

1.2.1. Приклади складних систем

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

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

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

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

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

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

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

У комп'ютері транзистори використовуються як в схемі ЦП, так і жорсткого диска. Аналогічно цьому велике число "уніфікованих елементів" є у всіх частинах рослини. Наприклад, клітини служать основними будівельними блоками всіх структур рослини; коріння, стебла і листя рослини складаються з кліток. І хоча будь-який з цих вихідних елементів дійсно є клітиною, існує величезна кількість всіляких клітинок. Є клітини, що містять і не містять хлоропласт, клітини з оболонкою, проникною і непроникною для води, і навіть живі і померлі клітини.

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

Звернемося до зоології. Багатоклітинні тварини, як і рослини, мають ієрархічну структуру: клітки формують тканини, тканини працюють разом як органи, групи органів визначають систему (наприклад, травну) і так далі. Основний будівельний блок всіх рослин і тварин - клітина. Природно, між клітинами рослин і тварин існують відмінності. Клітини рослини, наприклад, поміщені в жорстку целюлозну оболонку на відміну від клітинок тварин. Але, не дивлячись на ці відмінності, обоє вказаної структури, поза сумнівом, є клітинами. Це приклад узагальненості в різних сферах.

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

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

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

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

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

1.2.2. П'ять ознак складної системи

Виходячи з такого способу вивчення, можна вивести п'ять загальних ознак будь-якої складної системи:

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

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

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

Що ж слід вважати простими елементами системи? Досвід підказує нам наступну відповідь:

2. Вибір, які компоненти в системі вважаються елементарними, відносно довільний і у великій мірі залишається на розсуд дослідника.

Нижчий рівень для одного спостерігача може виявитися досить високим для іншого.

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

3. Внутрішньокомпонентний зв'язок зазвичай сильніший, ніж зв'язок між компонентами. Ця обставина дозволяє відділяти "високочастотні" взаємодії усередині компонентів від "низькочастотної" динаміки взаємодії між компонентами.

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

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

4. Ієрархічні системи зазвичай складаються з небагатьох типів підсистем, по-різному скомбінованих і організованих.

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

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

5. Будь-яка працююча складна система є результатом розвитку працюючої простішої системи... Складна система, спроектована "з нуля", ніколи не запрацює. Слід починати з працюючої простої системи.

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

1.2.3. Організована і неорганізована складність

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

Цей приклад наводить на думку, що ми мали на увазі термін ієрархія у подібному сенсі. Найцікавіші складні системи містять багато різних ієрархій. У літаку, наприклад, можна виділити декілька систем: живлення, керування польотом і так далі Таке розбиття дає структурну ієрархію типу "бути частиною". Цю ж систему можна розкласти абсолютно іншим способом. Наприклад, турбореактивний двигун - особливий тип реактивного двигуна, а "Pratt and Whitney TF30" - особливий тип турбореактивного двигуна. З іншого боку, поняття "Реактивний двигун" узагальнює властивості, властиві всім реактивним двигунам; "турбореактивний двигун" - це просто особливий тип реактивного двигуна з властивостями, які відрізняють його, наприклад, від прямоточного.

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

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

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

Структури класів і об'єктів системи разом називається архітектурою системи.

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

Рис. 1.1. Канонічна форма складної системи.

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

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

1.3. Методи подолання складності

1.3.1. Роль декомпозиції

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

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

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

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

¨ визначення і декомпозиція загальної мети дослідження;

¨ виділення проблеми зі середовища, визначення її ближнього і далекого оточення;

¨ опис факторів впливу.

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

¨ повнота — проблема має розглядатись максимально всесторонньо і детально;

¨ простоти — все дерево має бути максимальне компактним «вшир» і «углиб».

Компроміс досягається за допомогою чотирьох основоположних понять:

¨ суттєвості — в модель включаються тільки компоненти, суттєві по відношенню до цілей аналізу;

¨ елементарності — доведення декомпозиції до простого, зрозумілого результату, який можна реалізувати;

¨ поступовій деталізації моделі;

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

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