Материал: Розробка програми створення фракталу Жюліа

До основних термінів та визначень дипломного проекту можна віднести наступні терміни:

. Фракталом називається структура, що складається з частин, які в якомусь сенсі подібні цілому.

. Фрактальною графікою називається технологія створення зображень на основі фракталів.

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

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

. Комплексним числом називається число виду x+iy, де x та y - дійсні числа, i - уявна одиниця.

Головне вікно розроблюваної програми у макетному вигляді зображено на рисунку 1.6.

Рисунок 1.6 - Макет головного вікна

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

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

Рисунок 1.7 - Макет вікна інструкції

Створений програмний продукт планується здати в експлуатацію з 10 червня 2015 року.

1.5 Вибір засобів розробки

Для розробки ПП було обрано програму Microsoft Visual Studio 2010, яка відповідає всім вимогам проекту. Написання коду здійснюється на основі кістяка бібліотеки MFC, який автоматично створює вихідні рядки коду. Потрібно відзначити, що MFC AppWizard створює тексти додатків тільки з використанням бібліотеки класів MFC.

Перевагами MS VS 2010 є:

легкість створення проектів;

зручний інтерфейс;

підвищена швидкість компіляції;

підвищена швидкість зборки проекту;

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

Мовою розробки було обрано мову програмування С++, яка приділяє багато уваги підтримці об'єктно-орієнтованого програмування.

Мова С++ є удосконаленою мовою С та характеризується за такими ознаками:

підтримка об'єктно-орієнтованого програмування через класи. C ++ надає всі чотири можливості ООП - абстракцію, інкапсуляцію, успадкування (у тому числі і множинне) і поліморфізм.

підтримка узагальненого програмування через шаблони функцій і класів;

стандартна бібліотека C ++ складається з стандартної бібліотеки C (з деякими модифікаціями) і бібліотеки шаблонів STL, яка надає великий набір узагальнених контейнерів і алгоритмів;

додаткові типи даних;

обробка виключень;

віртуальні функції;

простір імен;

вбудовані функції (inline);

перевантаження (overloading) операторів;

перевантаження імен функцій;

посилання і оператори управління вільно розподіленою пам'яттю.

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

Для того, щоб скомпонувати презентаційний матеріал, використовується програма пакету Microsoft Office - PowerPoint. Матеріали, підготовлені за допомогою PowerPoint, призначені для відображення на великому екрані - через проектор, або телевізійний екран великого розміру, що є дуже зручною можливістю демонстрації програмного виробу аудиторії [5].

1.6 Вибір моделі життєвого циклу

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

Моделлю ЖЦ ПЗ називають структуру, що визначає послідовність виконання і взаємозв'язок процесів, дій, задач протягом ЖЦ.

Модель ЖЦ конкретного ПЗ інформаційної системи визначає характер процесу створення цього ПЗ, що означає сукупність упорядкованих у часі, об'єднаних у стадії робіт [6].

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

Рисунок 1.8 - Модель спірального процесу розроблення

Спіральна модель була розроблена у середині 1980-х років Барі Боемом. Вона ґрунтується на класичному циклі Демінга PDCA [7]. При використанні цієї моделі ІС створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

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

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

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

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

2. Алгоритмічне забезпечення

2.1 Діаграма варіантів використання

Діаграма варіантів використання є вихідним концептуальним уявленням або концептуальною моделлю системи в процесі її проектування і розробки (рисунок 2.1).

Рисунок 2.1 - Діаграма варіантів використання

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

відкрити информацію про фрактали, натиснувши кнопку "О фракталах";

відкрити інструкцію, натиснувши кнопку "Инструкция";

ввести вихідні дані комплексного числа, заповнивши поля "Вещественная часть" та "Мнимая часть" (обов'язкова дія);

ввести число ітерацій, заповнивши поле "Число итераций" (обов'язкова дія);

обрати кольорову гаму для побудування фракталу Жюліа за допомогою трьох слайдерів RGB;

побудувати фрактал згідно з введеними даними, натиснувши кнопку "Начать построение";

зберегти отримане зображення, натиснувши кнопку "Сохранить".

2.2 Діаграма послідовності дій

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

Рисунок 2.2 - Діаграма послідовності

З діаграми послідовності зрозуміло, що для початку потрібно запустити ПЗ.

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

2.3 Структура класів

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

Рисунок 2.3 - Структура класів

Структура містить в собі перелік всіх класів та їх базових типів, а саме: карти, глобальні змінні, макроси та константи, CAboutDlg з його базовим типом CDialogEx, CJuliaApp з його базовим типом CWinApp, CJuliaDlg з його базовим типом CDialogEx.

.4 Файлова структура проекту

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

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

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

Рисунок 2.4 - Файлова структура проекту

Файлова структура пректу містить в собі заголовні файли, файли початкового коду, файли ресурсів та файл ReadMe.txt.

3. Математичний апарат

3.1 Математична модель

Множина Жюліа будується для функції виду (формула 3.1)

, (3.1)

де p і q - комплексні поліноми.

Для спрощення задачі, будуватиметься множина Жюліа лише для квадратичного полінома. Квадратичний комплексний поліном у загальній формі виглядає наступним чином (формула 3.2)

. (3.2)

Також існує поняття унітарної (a=1) центрованої (b=0) форми квадратичного полінома (формула 3.3)

 (3.3)

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

Множина Жюліа збігається з A (∞), іншими словами з множиною тих точок z, для яких траєкторії йдуть у нескінченність, тобто не сходяться до якоїсь нерухомої точки, а так само не коливаються між двома або більше періодичними точками (нерухома точка - це періодична точка з періодом рівним одиниці), яка є замкнутою і обмеженою підмножиною всіх комплексних чисел. Звідси, множина Жюліа теж замкнена і обмежена. Позначимо наступним чином ту підмножину комплексних чисел, яка генерується ітераціями функції f і залишається обмеженою.

Назвемо таку множину заповненою множиною Жюліа (формула 3.4):

 (3.4)

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

- нехай дано деякий квадратичний поліном виду (формула 3.5)

(z) = z2 + c; (3.5)

позначимо (формула 3.6)

; (3.6)

тоді для певної точки  та n>0 виконується наступна умова (формула 3.7)

, (3.7)

тобто якщо модуль n-ої ітерації більше R, то ітерації функції f розходяться, це еквівалентно тому, що точка  входить в басейн аттрактора до нескінченності A(∞). Звідси вибігає, що  не являється точкою заповненої множини Жюліа [7].

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

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

1. обираємо с для того, аби задати поліном (формула 3.5);

. обчислюємо R для вихідного полінома (формула 3.5);

. обираємо параметр maxIter для позначення максимальної ітерації (чим він вищий, тим краще точність, тим повільніше алгоритм);

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

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

6. якщо |z |>R, то використовуємо менш яскравий колір, далі використовуємо той колір, на якому номері ітерації був перевищений поріг [7].

3.2 Логічне проектування

Опираючись на умови поставленого завдання були використані стандартні класи бібліотеки MFC. Діаграма класів відображає логічну структуру проектування (рисунок 2.4).