МЕТОДОЛОГІЯ ОБ'ЄКТНО-ОРІЄНТОВАНОГО ПРОЕКТУВАННЯ ІС

ОБ'ЄКТНО-ОРІЄНТОВАНИЙ ПІДХІД ДО ПРОЕКТУВАННЯ ІС

ОСНОВНІ ПРИНЦИПИ ПОБУДУВАННЯ ОБ'ЄКТНОЇ МОДЕЛІ

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

Об'єктна модель є найбільш природним способом уявлення реального світу.

Поняття «об'єкт» вперше було використано близько 30 років тому у технічних засобах при спробах відійти від традиційної архітектури фон Неймана та подолати бар'єр між високим рівнем програмних абстракцій та низьким рівнем абстрагування на рівні комп'ютерів. З об'єктно-орієнтованою архітектурою також тісно пов'язані об'єктно-орієнтовані операційні системи. Однак найбільш значний внесок у об'єктний підхід було внесено об'єктними та об'єктно-орієнтованими мовами програмування: Simula (1967), Smalltalk (1970-і рр.), C++ (1980-і рр.) та мовою моделювання UML (1990-і рр.) . На об'єктний підхід вплинули також методи моделювання даних, що розвивалися досить незалежно, особливо модель «сутність-зв'язок».

Концептуальною основою об'єктно-орієнтованого підходу є об'єктна модель. Основними принципами її побудови [1]:

• • інкапсуляція (encapsulation);
• • успадкування (inheritance);
• • поліморфізм (polymorphism);
• • абстрагування (abstraction);
• • модульність (modularity);
• • ієрархія (hierarchy).

Інкапсуляція - властивість, при якому об'єкти містять опис атрибутів та дій одночасно [2]. Інкапсуляція - це процес відділення один від одного окремих елементів об'єкта, що визначають його будову та поведінку [1]. Інкапсуляція служить у тому, щоб ізолювати інтерфейс об'єкта, який відбиває його зовнішнє поведінка, від внутрішньої реалізації об'єкта. Об'єктний підхід передбачає, що власні ресурси, якими можуть маніпулювати лише операції самого об'єкта, приховані від довкілля. Абстрагування та інкапсуляція є взаємодоповнювальними: абстрагування фокусує увагу на зовнішніх особливостях об'єкта, а інкапсуляція (або інакше обмеження доступу) не дозволяє об'єктам-користувачам розрізняти внутрішній пристрій об'єкта.

Спадкування - метод визначення об'єктів, при якому похідні об'єкти (нащадки) успадковують властивості (атрибути та дії) від своїх батьків [2]. Спадкування властивостей в об'єктно-орієнтованому підході розуміється як успадкування атрибутів та методів, тобто можливість використання у похідному об'єкті атрибутів та методів базового об'єкта.

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

• • можливість однакового найменування статичних способів;
• • можливість однакового найменування динамічних способів.

У UML для опису поліморфізму вводяться поняття операції

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

Операція — це лише опис будь-якої риси поведінки об'єкта, а метод — конкретна реалізація.

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

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

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

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

Ієрархія - це ранжована або впорядкована система абстракцій, розташування їх за рівнями. Основними видами ієрархічних структур стосовно складних систем є структура класів (ієрархія за номенклатурою) та структура об'єктів (ієрархія за складом). Прикладами ієрархії класів є просте та множинне спадкування (один клас використовує структурну або функціональну частину відповідно одного або кількох інших класів), а ієрархії об'єктів – агрегація [1].

Об'єктно-орієнтована декомпозиція та моделювання

У попередньому параграфі ми розглянули основні підходи створення ПЗ. У цьому вся параграфі розглянемо підходи до побудови об'єктних моделей програмних систем. Спосіб проектування складних систем був відомий ще в давнину — «розділяй і володарюй». p align="justify"> При проектуванні складної програмної системи необхідно розділяти її на всі менші і менші підсистеми, кожну з яких можна вдосконалювати незалежно. У цьому випадку для розуміння будь-якого рівня системи нам необхідно одночасно тримати в умі інформацію лише про деякі її частини, і цей спосіб називається декомпозицією. Алгоритмічна декомпозиція. Більшість фахівців, які під час створення програмних систем використовують технологію структурного процедурного програмування і, зокрема, проектування «згори донизу», сприймають декомпозицію як звичайне поділ алгоритмів, де кожен модуль системи виконує одне із підзадач загального процесу.

Об'єктно-орієнтована декомпозиція, на відміну від алгоритмічної, наказує поділ моделі предметної області на елементи, вибираючи як критерій декомпозиції належність цих елементів до різних абстракцій даної предметної області. Перед тим, як розділяти завдання на кроки, необхідно визначити об'єкти предметної області. Хоча обидва варіанти декомпозиції вирішують одну й ту саму задачу, але вони роблять це різними способами. У другому випадку предметна область представлена ​​сукупністю автономних елементів предметної області, які взаємодіють один з одним, щоб забезпечити поведінку системи, що відповідає вищому рівню. Кожен елемент має свою власну поведінку, і кожен з них моделює певний об'єкт реального світу. З цієї точки зору об'єкт є цілком відчутною річчю, яка демонструє певну поведінку конкретної частини предметної області. Об'єкти щось роблять, і їм можна надіслати повідомлення, попросивши їх виконати те й те. Так як ця декомпозиція заснована на об'єктах, а не на алгоритмах, вона називається об'єктно-орієнтованою декомпозицією. Для складної програмної системи важливими є обидва способи декомпозиції: і за алгоритмами, і за об'єктами. Поділ за алгоритмами концентрує увагу до порядку подій, що відбуваються, і обчислювальному процесі, а поділ по об'єктах надає особливого значення елементам, які є об'єктами. Однак не можна сформулювати складну систему одночасно двома способами. Поділ системи можливий або за алгоритмами, або за об'єктами, а потім, використовуючи отриману структуру, треба спробувати розглянути проблему з іншого погляду. Досвід показує, що для складних програмних систем корисніше починати з об'єктної декомпозиції, яка має кілька важливих переваг перед алгоритмічною декомпозицією. Об'єктна декомпозиція допомагає зменшити розмір програмних систем з допомогою повторного використання загальних механізмів. Об'єктно-орієнтовані системи гнучкіші і простіше еволюціонують з часом. Справді, об'єктна декомпозиція істотно знижує ризик під час створення складної програмної системи, оскільки вона розвивається з менших систем, у яких ми впевнені. Більше того, об'єктна декомпозиція допомагає на ранніх стадіях проектування розібратися у складній програмній системі. А вже після створення об'єктної моделі та опису структури кожного класу для розробки операцій класу можна використовувати алгоритмічну декомпозицію для проектування процедур У результаті об'єктно-орієнтованої декомпозиції розробник створює об'єктно-орієнтовані моделі, тобто такі моделі, які фокусують увагу на об'єктах заданої предметної області та задачі, що розв'язується. Моделювання широко поширене у всіх інженерних дисциплінах, значною мірою через те, що воно реалізує принципи декомпозиції, абстракції та ієрархії. Кожна модель описує певну частину аналізованої системи, далі будуються нові моделі з урахуванням старих моделей тощо. буд. Моделі дозволяють контролювати наші невдачі. Ми оцінюємо поведінку кожної моделі у звичайних та незвичайних ситуаціях, а потім проводимо відповідні доопрацювання, якщо нас щось не задовольняє.

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

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

Невдалі проекти закінчуються крахом з різних причин, а ось успішні, як правило, мають багато спільного. Хоча успіх програмного проекту забезпечується безліччю різних доданків, одним із загальних є застосування моделювання.

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

Отже, що таке модель? Простіше кажучи, вона є спрощеним уявленням реальності.Модель – це візуальне відображення системи (креслення системи): до неї може входити як детальний план, і більш абстрактне уявлення системи. Хороша модель завжди включає елементи, які суттєво впливають на результат, і не включає ті, які малозначущі на даному рівні абстракції. Кожна система може бути описана з різних точок зору, для чого використовуються різні моделі, кожна з яких є семантично замкнутою абстракцією системи. Модель може бути структурною, що підкреслює організацію системи, або поведінковою, тобто відображає її динаміку.

Навіщо ми моделюємо? Для цього є фундаментальна причина. Ми будуємо моделі для того, щоб краще розуміти прикладну програму, що розробляється.

Моделювання дозволяє вирішити чотири різні завдання:

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

Моделювання призначене не лише для створення великих систем. Чим

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

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

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

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

Моделювання має багату історію у всіх інженерних дисциплінах. Тривалий досвід його використання дозволив сформулювати чотири основні принципи створення моделей [4, 5].

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

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

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

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

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

Третій принцип: найкращі моделі — ті, що ближчі до реальності.

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

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

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

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

p align="justify"> При розробці програмного забезпечення теж існує кілька підходів до моделювання. Найважливішими з них є алгоритмічний та об'єктно-орієнтований підходи, про що ми говорили в п. В.1.

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

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

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

Сутності - це абстракції, які є основними елементами моделі. Сутності є основними об'єктно-орієнтованими блоками мови. З їхньою допомогою можна створювати коректні моделі.

Як ми вже говорили, при об'єктно-орієнтованому підході в об'єктній моделі предметна область може бути представлена ​​як сукупність об'єктів, які об'єднані в класи. Класи можуть існувати на кількох рівнях уявлення: концептуальному – рівні аналізу, рівні проектування та рівні реалізації [4].

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

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

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

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

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

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

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

Об'єктна декомпозиція

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

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

Чорновий план процесу об'єктної декомпозиції:

Ø Виділити класи та об'єкти

Ø Визначити, що вони означають

Ø Виявити зв'язок між класами та об'єктами

Ø Описати інтерфейс та реалізацію

приклад. Найпростіший графічний редактор

o Малювання кола та квадрата

o Можливість зміни кольору, розміру та координат центру.

Коло ß (намалювати) керуючий блок à (намалювати) квадрат

(змінити колір) (змінити колір)

(Змінити розмір) (Змінити розмір)

(Змінити координати) (змінити координати)

приклад. Адресна книга

Потрібно написати програму, в якій можна:

o Відкривати адресну книгу

o Додавати записи про контакти

o Вести пошук записів

Складемо діаграму станів інтерфейсу

Режим відкриття книги режим додавання записів режим пошуку записів

"некоректне ім'я файлу" немає інформації про контакт

Діаграма об'єктів

Активізувати активізувати активізувати

Форма відкриття файлу форма «додавання записів» Форма «пошук записів»

Повідомлення "некоректне ім'я файлу" Файл Повідомлення "немає інформації про контакт"

Об'єктна декомпозиція може бути багаторівневою.

приклад. Об'єктна декомпозиція меню, форма, файл.

Корова 3 Вівця 3 курка 3

Корова 2 Вівця 2 курка 2

Корова 1 Вівця 1 курка 3

Алгоритм побудови діаграми класів:

Ø Скласти варіанти використання

Ø Виділити поняття-кандидати на роль класів

Ø Визначити, які з кандидатів справді є класами

Ø Описати взаємозв'язки класів

Ø Встановити атрибути класів.

Варіанти використання:

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

Поняття-кандидат не підходить на роль класу, якщо:

· Поняття відповідають однина, змінна або проста структура в програмі

· Поняття суворо відповідає складнішому поняття, наприклад, входячи до його складу.

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

o поняття «вік» описується однією змінною і є атрибутом класу «студент»

o Чи можна зрозуміти «дисципліна» призначити атрибутом класу викладач? (загалом може бути окремим класом))

Основним елементом діаграми класів є:

Типи зв'язків між класами:

ü Означає наявність сематичного зв'язку між двома класами.

ü Інші відносини уточнюють тип зв'язку

ü Асоціації можуть мати ім'я та напрямок, об'єктом асоціації можуть бути складені ролі.

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

· Узагальнення – це відношення між поняттями виду «загальне-приватне»

· Узагальнююче поняття називається супертипом (батьком, предком)

Ø Агрегація – відношення між поняттями виду «ціле-частина» (факультетß кафедра)

ü Використання – відношення між поняттями виду «клієнт-сервер» (студент 0---- відділ кадрів)

Сподобалася стаття? Додай її в закладку (CTRL+D) і не забудь поділитися з друзями: