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

1.3.2 Використання схеми документу

Структуровані дані, які можуть бути представленими у формі XML-файлу, потребують додаткової інформації. Найбільш розповсюдженими є два основних формати представлення такої інформації - Визначення шаблону документу (DTD) та Схема документу (XSD).

DTD (Document Template Definition) - набір правил, що дозволяють однозначно визначити структуру певного класу XML-документів. Директиви DTD можуть бути присутніми як у заголовку самого XML-документу (internal DTD), так і в іншому файлі (external DTD). Наявність DTD не є обов'язковим. Проте, XML-документ, що не містить DTD, або не вказує на нього, не може вважатися "правильним" (valid).

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

1.3.3 Технологія зв'язування даних

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

Засіб зв'язування даних XML містить компілятор схеми, що транслює схему в набір специфічних для схеми класів з відповідними методами доступу і зміни (тобто get і set). Він також містить структуру маршалінгу, що підтримує демаршалінг XML документів у відповідну структуру взаємозалежних екземплярів і маршалінг цих структур у XML-документи.

В інтегрованому середовищі Eclipse можна застосувати додатковий модуль Castor, який дозволяє створити необхідні класи з використанням інформації файлу схеми.

1.4 Візуальне проектування програм графічного інтерфейсу

1.4.1 Застосування бібліотеки javax.swing

Бібліотека javax.swing пропонує розробникові низку стандартних класів, які можна використовувати для проектування графічного інтерфейсу користувача. Ця бібліотека замінила собою попередню менш вдалу бібліотеку AWT (Abstract Window Toolkit). Для ідентифікації приналежності до бібліотеки javax.swing до імен класів візуальних компонентів додана літера J (наприклад, JButton, JPanel і т. д.).[3]

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

import javax.swing.*;

Використання візуальних компонентів базується на застосуванні спеціального різновиду класів - так званих Java Beans. Java Bean - це клас, у якого відсутні відкриті дані (відкритими можуть бути тільки методи) та обов'язково є конструктор без параметрів. [4]

Бібліотека Swing дозволяє змінювати зовнішній вид інтерфейсу користувача відповідно до стилю (Look & Feel), який прийнято у певній операційній системі. Для керування стилем використовують спеціальний клас UIManager. За умовчанням прийнято крос-платформений стиль ("metal").

1.4.2 Використання менеджерів компонування (layout managers)

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

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

Контейнер елементів графічного інтерфейсу Java (клас java.awt.Container) використовує менеджер компонування (layout manager) - спеціальний об'єкт для управління розміщенням та розмірами компонентів під час відображення форми. Цей об'єкт автоматично розміщує елементи контейнеру відповідно до своїх специфічних правил.

Основний фрейм програми найчастіше використовує менеджер компонування BorderLayout.  Усі компоненти, які додаються до контейнеру, BorderLayout поміщає в центр, розтягуючи об'єкт в усі сторони до краю. Альтернативою є додавання елементів по краях контейнеру зверху, знизу, з правого та з лівого краю Для цього другим параметром методу add(), який додає компоненти до контейнеру, вказуються константи NORTH, SOUTH, EAST та WEST відповідно.

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

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

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

Більш складні варіанти компонування здійснюються за допомогою менеджерів GridBagLayout та BoxLayout.[4]

1.4.3 Обробка подій

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

1.4.4 Методи візуалізації Java 2D

Програмний інтерфейс Java 2D API надає користувачеві розширений набір засобів двовимірної графіки.

Для здійснення безпосереднього малювання можна використовувати будь-який компонент, який є нащадком JComponent, але найчастіше з цією метою використовують JPanel. Клас JComponent має метод paintComponent(), який необхідно перекрити для здійснення малювання на поверхні контейнеру. Параметр цього методу - посилання на об'єкт класу Graphics. Клас Graphics інкапсулює в собі графічні засоби. Один з нащадків цього класу - клас Graphics2D, який розширює графічні можливості свого базового класу.

Система координат Java 2D включає два координатних простори:  простір користувача, у якому визначаються координати графічних примітивів простір  пристрою виведення (device space). У випадку малювання на екрані можна безпосередньо застосовувати координати простору користувача.

1.4.5 Проектування графічного інтерфейсу користувача у Eclipse

Програми, які використовують бібліотеку javax.swing, можуть бути створені у середовищі Eclipse як безпосередньо, так і за допомогою спеціального додаткового модуля Visual Editor (VE). Цей модуль дозволяє створити так звані візуальні класи, редагування яких може здійснюватись двома шляхами - шляхом маніпуляції графічними компонентами та через редагування вихідного коду.

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

2 ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

   2.1 Використання UML

   2.1.1 Уніфікована мова програмування (UML)

    Створення Уніфікованої мови моделювання (Unіfіed Modeling Language, UML) почалося в 1994 році. У цей час Грэйди Буч (Grady Booch) і Джеймс Рамбо (James Rumbaugh) почали поєднувати кілька методів об'єктно-орієнтованого моделювання у фірмі Ratіonal Software. У 1995 році була представлена специфікація методу, який отримав назву Unіfіed Method. Пізніше до розроблювачів приєднався Івар Джекобсон (Іvar Jacobson). Раніше всі три автори працювали самостійно над різними концепціями об'єктно-орієнтованого моделювання і проектування.

    Перша версія UML була прийнята консорціумом OMG (Object Management Group) у січні 1997 року як міжнародний стандарт. Затверджена ж у вересні версія UML 1.1 була застосована основними компаніями - виробниками програмного забезпечення, такими, як Mіcrosoft, ІBM, Hewlett-Packard і виробниками CASE-засобів, що реалізували підтримку UML у своїх програмних продуктах.

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

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

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

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

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

Рисунок 2.1 - Варіант використання

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

Рисунок 2.2 – Актор

   UML визначає наступні типи зв'язків між акторами та варіантами використання:

1)     Асоціація (між актором та варіантом використання):

Рисунок 2.3 – Асоціація

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