Система моделювання росту зерен в металах та сплавах

· контроль користувачем інтерфейса;

· зменшення завантаження пам'яті користувача;

· послідовність користувацького інтерфейса.

Хансен представив найкоротший список прицнипів проектування:

· знати користувача;

· скоротити запам'ятовування;

· оптимізувати операції;

· позбутися помилок.

Ці принципи застосовні до всього програмного та апаратного забезпечення, в усіх типах та стилях інтерфейсів. Трактування цих принципів буде, звісно, залежати від апартного забезпечення, операційної системи, складових користувацького інтерфейса та його задач. Користувацькі моделі теж різні і впливають на те, як будуть застосовуватись принципи. На деяких важливих етапах розробки проекту може постати питання ”Що відбудеться далі?”. Відповідь повинна бути “Що захоче користувач”.

Основне правило проектування - дати користувачу контроль над системою. Проста аналогія - водій автомобіля та пасажир потягу. Рішення - їхати власним авто або потягом - повинен приймати саме пасажир (в нашому випадку користувач).

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

Досвідчені проектувальники дозволяють користувачам вирішувати деякі задачі за власним розсудом. Так, наприклад, архітектори по завершенні будівництва складного комплексу будівель повинні прокласти між ними доріжки для пішоходів. Доки вони не знають, в якому саме місці люди перетинатимуть майданчики, тому хороші архітектори ніколи не прокладають доріжки одночасно з побудовою будівель. На майданчиках між домами ставлять таблички: “Ходіть, будь-ласка, по траві”. Через деякий час будівельники повертаються і лише тепер, згідно волевиявленню населення, асфальтують протоптані доріжки.

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

Принципи, за якими користувачу дається контроль над системою:

· безрежимність - використання режимів розважливо;

· гнучкість - надання користувачу можливості обирати (наприклад, працювати мишею, клавіатурою чи їх комбінацією);

· можливість переривання - дозвіл користувачу сфокусувати увагу;

· корисність - демонстрація повідомлень, які допомагатимуть йому в роботі;

· поблажливість - створення умов для негайних та зворотніх дій, а також зовротнього зв'язку;

· можливість орієнтування - забезпечення відповідних шляхів і виходів;

· доступність - пристосування системи до користувачів з різним рівнем підготовки;

· полегшення в користуванні - створення більш зрозумілого КІ;

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

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

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

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

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

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

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

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

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

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

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

Корисність. Повідомлення типу «Пароль надто короткий. Він повинен бути як мінімум 26908 байт» можливо й інформативне, але воно не допомагає користувачу, тому що він не знає, скільки символів може вміститись в 26908 байт. Користувачі не повинні переводити число символів в байти. Таке повідомлення порушує принцип «прозорості».

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

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

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

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

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

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

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

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

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

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

Принципи, які дозволяють знизити завантаження пам'яті користувача:

· запам'ятовування - не потрібно завантажувати короткочасну пам'ять;

· розпізнавання - потрібно опиратись на розпізнавання, а не на повторення;

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

· терпимість - потрібно передбачити установки за замовчуванням, команди відхилення дії та потворення дії;

· швидкість - потрібно передбачити “швидкі” шляхи;

· інтуїтивність - потрібно активізувати синтаксис дій з об'єктами;

· перенос - потрібно використовувати метафори з реального світу;

· контекст - потрібно застосовувати розкриття та пояснення понять та дій;

· організація - потрібно збільшити візуальну ясність.

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

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

Не змушуйте користувачів запам'ятовувати та потворювати те, що може й повинен робити комп'ютер.

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

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

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

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

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

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

Швидкість. Крім комбінованого використання миші та клавіатури потрібно відшукати інші можливості пришвидшити роботу з програмою. “Гарячі” клавіші зменшують завантаження пам'яті користувача та доводять виконання операції до автоматизму.

Є два основних способи для установки ярликів: прискорюючі та мнемонічні. Мнемонічні (або доступні) - це одиночні буквенно-цифрові символи, які пересувають курсор на потрібний об'єкт та дозволяють зробити вибір. Вони використовують різні меню (панель, спадні, які з'являються) та списки. Мнемонічні символи повинні бути унікальними для кожного роду дій. Наприклад, типове меню вікна використовує стандартні клавіші - F для файлу, E для редагування, V для перегляду, H для виклику довідкової системи. Наступний рівень меню (спадні) використовують свої установки мнемонічних клавіш. Наприклад, N - новий документ, O - відкрити, C - закрити, S - зберегти. Мнемонічні символи пришвидшують рух і вибір потрібного меню або списка.

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

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

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

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

Перенос. Метафори реального світу дозволяють користувачу переносити свої знання з реального світу в світ комп'ютерів. Наприклад, не потрібно для програми Калькулятор розробляти новий інтерфейс, він повинен збігатись з інтерфейсом звичайного калькулятора, який добре засвоїли користувачі. Але потрібно бути обережними при виборі та використанні метафор для інтерфейсу. Обираючи метафору, зафіксуйте її та слідуйте ній весь час. Якщо ви виявите, що метафора не відповідає свому призначенню в усьому інтерфейсі, оберіть нову метафору. Продовжуйте метафору, не перериваючи її.

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

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

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

Деякі програми одночасно надають надто багато інформації на екрані. Це викликає відчуття хаосу. Інформація повинна показуватись в порядку, зрозумілому для користувачів. Тобто “форма повинна слідувати призначенню”.

Комп'ютерні графіки та оформлювачі книг добре засвоїли мистецтво подання інформації. Цю навичку повинні мати й члени команди по розробці КІ.

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

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

Принципи створення сумісного інтерфейсу:

· послідовність - проектування послідовного інтерфейсу;

· досвід - спільна сумісність всіх програм;

· прогнозування - збереження результатів взаємодії;

· відношення - естетична привабливість та цілісність;

· передбачуваність - заохочення вивчення.

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

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

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

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

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

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

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

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

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

Приємний для погляду інтерфейс не повинен приховувати недолік функційності програмного продукту. Користувачі повинні одержати гарний інтерфейс, який допоможе їм в роботі.

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

3.9. Вимоги, стандарти та керівні принципи при побудові

3.9.1 Вимоги

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

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

Орієнтований на користувачів колектив розробників формує наступні вимоги:

· аналіз задач та прецедентів;

· можливості (функції, користувальницький інтерфейс і т.д.);

· критерії (практичність, продуктивність, якість і т.д.);

· конкуренти та кращі зразки;

· користувачі, технології, обмеження;

· методи залучення користувачів;

· візуалізація проектних рішень.

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

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

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

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

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

Є чимало джерел інформації у вигляді галузевих публікацій.

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

Типовий сценарій збирання вимог:

· кінцевий користувач звертається до керівника;

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

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

· менеджер ІТ-підрозділа звертається до спеціаліста з планування продуктів;

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

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

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

Очевидні питання, які повинні увійти у вимоги:

· стиль КІ;

· платформа та інші стандарти КІ для додатку;

· сумісність з провідним ПЗ, працюючим на даній платформі;

· вміст екрану;

· поведінка екрану;

· характеристики звонішнього вигляду екрану;

· методи взаємодії користувачів із системою;

· можливості роботи з клавіатурою;

· зворотній зв'язок користувача у відповідь на стан системи та час відзиву;

· користувацький контроль над різними функціями;

· запам'ятовування результатів операцій розташування та зміни розмірів вікна, а також даних, стану та контекста;

· можливості навігації для додатку;

· збереження даних користувача при навігації;

· запам'ятовування проміжних даних користувача при навігації;

· інтерактивне навчання, підтримка продуктивності та довідкова система;

· попередження помилок та відновлення системи після помилок;

· методи прямого введення для усунення діалогу;

· перевірка правильності значень полів, а також ідентифікація потрібних полів;

· стандартне використання кольору, індикаторів, графіки і т.д.;

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

Вимоги по практичності легко встановлювати в невизначеному та важкому для вимірювання вигляді.

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

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

· кількість підтримуваних переривань задач;

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

· підтримка КІ під час переривань.

3.9.2 Комп'ютерні стандарти

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

3.9.3 Керівні принципи

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

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

Більшість програмних продуктів створені для роботи на різних платформах. З тих пір, як ці платформи мають різні операційні системи, інструменти та стилі інтерфейсу, дуже складно розробляти інтерфейс, який задовольняє всі платформи або навіть просто працюючий на кожній з платформ. Недавнє доповнення - підбірка індустріальних керівництв по проектуванню - було розроблене Беллкором. Воно мітсить опис та керівні принципи для основних компонентів проектування КІ для таких компаній та операційних систем, як IBM CUA, OSF Motif, Microsoft Windows та ін.

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

Найпростіші принципи по розробці ПЗ, сформульовані Берстом:

· для свого програмного середовища оберіть відповідні промислові керівні принципи;

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

· орієнтуйтесь на кінцевий додаток, використовуючи дані керівних принципів;

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

Стандарти, промислові керівництва по розробці та стилю оформлення в порядку спадання пріоритету:

· міжнародні стандарти;

· галузеві керівні принципи по платформах;

· корпоративне керівництво по оформленню стилю інтерфейсу;

· керівництво по оформленню стилю групи продуктів;

· керівництво по оформленню стилю продукту.

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

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

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

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

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

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

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

4. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ

4.1 Функціональне призначення та технологічні особливості розробки

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

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

Система моделювання росту зерен в металах та сплавах була створена за допомогою інструментального засобу прискореної розробки програмного забезпечення Delphi з використанням пакету альтернативних компонентів Development Express та Rsruler40, за допомогою яких був реалізований інтерфейс системи.

Вимоги до програмного забезпечення:

· Робота в середовищі операційних систем Windows 2000/XP/Vista/7;

· Відсутність додаткових вимог до розміщення здійсненних файлів;

Мінімальні вимоги до апаратного забезпечення:

· IBM-Сумісний комп'ютер, не нижче Pentium III, RAM-512Mb, SVGA-монітор 17 дюймів, вільний простір на жорсткому диску біля 3 Мб.

4.2 Розробка логіко-функціональної схеми системи

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



Рис. 4.1 Логіко-функціональна схема роботи системи

4.3 Математичні основи розрахунку координат точок перетину кіл

Нехай задані два кола, перше з центром в точці 1 з координатами X1,Y1 і радіусом R1. Друге з центром в точці 2 з координатами X2,Y2 і радіусом R2. В точках перетину знаходяться шукані точки 3 і 4 з координатами, відповідно X3,Y3 і X4,Y4. Центральна точка 0 - точка перетину всіх ліній, з координатами X,Y.

Рис. 4.2 Координати точок кіл, що перетинаються

Розглянемо два прямокутні трикутники 103 і 203 із загальним катетом 03. Гіпотенузи нам відомі - це радіуси R1 і R2 (рис. 4.3).

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

D - відстань між центрами кіл;

H - відстань від точки перетину всіх ліній до точок перетину кіл;

A - відстань від центру першого кола до точки перетину всіх ліній;

B - відстань від центру другого кола до точки перетину всіх ліній.

Знаючи координати X1,Y1 і X2,Y2 легко можна знайти відстань D між ними:

(4.1)

Рис. 4.3 Схема знаходження координат точок перетину

Одержимо умову перетину кіл:

(4.2)

Відрізок H загальний, це означає, що можна скласти наступну систему рівнянь:

(4.3)

Звідси знаходимо наступні вирази. Відстань від центру другого кола до точки перетину всіх ліній:

(4.4)

Відстань від центру першого кола до точки перетину всіх ліній:

(4.5)

Відстань від точки перетину всіх ліній до точок перетину кіл:

(4.6)

Координати центру перетину всіх ліній:

(4.7)

Координати точок перетину кіл:

(4.8)

4.4 Розробка алгоритмів та програмна реалізація

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

procedure Tmain.Image1MouseDown(Sender: TObject; Button: TMouseButton;

Shift: TShiftState; X, Y: Integer);

begin

if flag then exit; // якщо запущений режим моделювання додавати нові зерна заборонено

// Встановлюємо колір та товщину лінії границі зерен

Image1.Canvas.Brush.Style:=bsClear;

Image1.Canvas.Pen.Color:=col_c;

Image1.Canvas.Pen.width:=w_c;

// Заборона побудови кіл, якщо вони виходять за зону області побудови

if (x-radius)<0 then exit;

if (x+radius)>Image1.ClientWidth then exit;

if (y-radius)<0 then exit;

if (y+radius)>Image1.ClientHeight then exit;

Image1.Canvas.Brush.Style:=bsClear;

if Button=mbLeft then // якщо натиснута ліва клавіша мишки

image1.canvas.Ellipse(x-radius,y-radius,x+radius,y+radius); // будуємо коло з заданими параметрами

cxMemo1.Lines.Add(inttostr(j+1)+'. X='+inttostr(x)+'; Y='+inttostr(y)+'; R='+inttostr(radius)); // виводимо данні в текстовому вікні

j:=j+1; // підраховуємо кількість створених центрів кристалізаціїї

x1[j]:=x; y1[j]:=y; r1[j]:=radius; r[j]:=r1[j]; // заносимо до відповідних масивів координати центрі та радіусів побудованих кіл

end;

При переміщені курсору в області побудови в StatusBar відображаються поточні координати перехрестя.

procedure Tmain.Image1MouseMove(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

begin

RsRuler1.HairLinePos := X; // визначення координати х

RsRuler2.HairLinePos := y; // визначення координати y

StatusBar1.Panels[0].Text:=Format('X=%d, Y=%d pt', [X,Y]);

StatusBar1.Panels[1].Text:=Format('X=%d, Y=%d мм', [round(X/96*25.4),round(X/96*25.4)]); // вивід значень на панель в пікселях та міліметрах

end;

Зміна одиниць вимірювання відбувається наступним чином.

procedure Tmain.RsRulerCorner1Click(Sender: TObject);

begin

if RsRulerCorner1.Units=ruPixel then // якщо поточна одиниця - пікселі

begin

RsRulerCorner1.Units:=ruMilli;

RsRuler1.Units:=ruMilli;

RsRuler2.Units:=ruMilli;

end

else // якщо поточна одиниця - міліметри

begin

RsRulerCorner1.Units:=ruPixel;

RsRuler1.Units:=ruPixel;

RsRuler2.Units:=ruPixel;

end;

end;

Зміна інтервалу росту зерен відбувається за допомогою наступної процедури.

procedure Tmain.dxBarSpinEdit2CurChange(Sender: TObject);

begin

Timer1.Interval:=round(dxBarSpinEdit2.Value*1000); // встановлюємо інтервал таймеру

end;

За очищення області побудови відповідає наступна процедура.

procedure Tmain.dxBarButton5Click(Sender: TObject);

var i:integer;

begin

Image1.Enabled:=true; // область побудови є доступною

dxBarButton6.Caption:='Моделирование';

w:=0; w1:=0;

image1.Canvas.Brush.Style:=bsSolid;

image1.Canvas.Brush.Color:=clwhite;

image1.canvas.FillRect(ClientRect); // очищення області побудови

cxMemo1.Clear;

j:=0; // кількість побудованих зерен

Timer1.Enabled:=false; // таймер відключений

flag:=false; // ознака того, що процес моделювання не запущений

Image1.Canvas.Pen.Width:=1;

Image1.Canvas.Pen.Color:=clblack;

Image1.Canvas.Brush.Style:=bsClear;

dxBarButton6.Enabled:=true;

end;

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

procedure Tmain.Timer1Timer(Sender: TObject);

var i,k,n,z,m:integer;

A,B,H,D:Real;

x,y,X3,x33,X4,x44,Y3,y33,Y4,y44:Integer;

fu:boolean;

f:boolean; //ознака того, що процес моделювання закінчено

kol:integer; //кількість зерен, що зростають

begin

Timer1.Interval:=round(dxBarSpinEdit2.Value*1000);

// Встановлюємо колір та стиль заливки

Image1.Canvas.Brush.Style:=bssolid;

Image1.Canvas.Brush.Color:=clWhite;

// Заливка області побудови

image1.canvas.FillRect(ClientRect);

// Колір заливки чорний, стиль - заливка відсутня

Image1.Canvas.Brush.Style:=bsClear;

// Встановлюємо колір та товщину лінії границі зерен

Image1.Canvas.Pen.Color:=col_c;

Image1.Canvas.Pen.width:=w_c; kol:=0;

// Перебираємо в циклі всі кола окрім утворюючого

for i:=1 to j-1 do

begin

// Якщо розміри кіл не виходять за область побудови

if not(((x1[i]-r[i])<0) or((x1[i]+r[i])>Image1.ClientWidth) or((y1[i]-r[i])<0)

or((y1[i]+r[i])>Image1.ClientHeight)) then begin

r[i]:=r[i]+1; kol:=kol+1; end; //збільшуємо радіус кола на 1 піксель

// Побудова кіл з новим радіусом

image1.canvas.Ellipse(x1[i]-r[i],y1[i]-r[i],x1[i]+r[i],y1[i]+r[i]);

end;

if not (w1=(j-1)) then // якщо ще не знайдені всі точки кристалізації

r[j]:=r[j]+1;

// Побудова утворюючого кола з новим радіусом

image1.canvas.Ellipse(x1[j]-r[j],y1[j]-r[j],x1[j]+r[j],y1[j]+r[j]);

if kol=0 then f:=false;

if (not f) then// моделювання закінчене

begin

Timer1.Enabled:=false; // відключення таймеру

dxBarButton6.Caption:='Моделировать'; // зміна назви кнопки

dxBarButton6.Enabled:=false; // кнопка „Моделювання”

стає недоступною

end;

// Знаходимо точки перетину всіх кіл із утворюючим

if not (w1=(j-1)) then // якщо ще не знайдені всі точки кристалізації

begin

for i:=1 to j-1 do // перебираємо в циклі всі створені кола окрім утворюючого

begin

D:=sqrt(sqr(X1[i]-X1[j])+sqr(Y1[i]-Y1[j])); // відстань між центрами кіл

If (D<=(R[i]+R[j])) AND (D>=ABS(R[i]-R[j])) Then // якщо кола перетинаються

Begin

B:=(sqr(R[i])-sqr(R[j])+sqr(D))/(2*D); // відстань від центру другого кола до точки перетину всіх ліній

A:=D-B; // відстань від центру першого кола до точки перетину всіх ліній

H:=sqrt(sqr(R[i])-sqr(B)); // відстань від точки перетину всіх ліній до точок перетину кіл

// X,Y - координати центру перетину всіх ліній

X:=round(X1[j]+(X1[i]-X1[j])/(D/A));

Y:=round(Y1[j]+(Y1[i]-Y1[j])/(D/A));

// X3,Y3 - координати першої точки перетину кола з утворюючим

//X4,Y4 - координати другої точки перетину кола з утворюючим

X33:=round(X-(Y-Y1[i])*H/B);

Y33:=round(Y+(X-X1[i])*H/B);

X44:=round(X+(Y-Y1[i])*H/B);

Y44:=round(Y-(X-X1[i])*H/B);

// Установка параметрів для побудови точок перетину

Image1.Canvas.Brush.Style:=bsSolid;

Image1.Canvas.Brush.Color:=clgreen;

Image1.Canvas.Pen.Color:=clgreen;

// Побудова точок перетину кіл

image1.canvas.Ellipse(x33-3,y33-3,x33+3,y33+3);

image1.canvas.Ellipse(x44-3,y44-3,x44+3,y44+3);

end;

end;

// Пошук точок перетину всіх кіл між собою і перехоплення точок кристалізації

for i:=1 to j-2 do

begin

// Пошук точок перетину i-го кола з утворюючим

D:=sqrt(sqr(X1[i]-X1[j])+sqr(Y1[i]-Y1[j])); // відстань між центрами кіл

If (D<=(R[i]+R[j])) AND (D>=ABS(R[i]-R[j])) Then // якщо кола перетинаються

Begin

B:=(sqr(R[i])-sqr(R[j])+sqr(D))/(2*D); // відстань від центру другого кола до точки перетину всіх ліній

A:=D-B; // відстань від центру першого кола до точки перетину всіх ліній

H:=sqrt(sqr(R[i])-sqr(B)); // відстань від точки перетину всіх ліній до точок перетину кіл

// X,Y - координати центру перетину всіх ліній

X:=round(X1[j]+(X1[i]-X1[j])/(D/A));

Y:=round(Y1[j]+(Y1[i]-Y1[j])/(D/A));

// X3,Y3 - координати першої точки перетину кола з утворюючим

//X4,Y4 - координати другої точки перетину кола з утворюючим

X33:=round(X-(Y-Y1[i])*H/B);

Y33:=round(Y+(X-X1[i])*H/B);

X44:=round(X+(Y-Y1[i])*H/B);

Y44:=round(Y-(X-X1[i])*H/B);

end;

for k:=i+1 to j-1 do

begin

// Пошук точок перетину i-го та k-го кола

D:=sqrt(sqr(X1[k]-X1[i])+sqr(Y1[k]-Y1[i])); // відстань між центрами кіл

If (D<=(R[i]+R[k])) AND (D>=ABS(R[i]-R[k])) Then // якщо кола перетинаються

Begin

B:=(sqr(R[k])-sqr(R[i])+sqr(D))/(2*D); // відстань від центру другого кола до точки перетину всіх ліній

A:=D-B; // відстань від центру першого кола до точки перетину всіх ліній

H:=sqrt(sqr(R[k])-sqr(B)); // відстань від точки перетину всіх ліній до точок перетину кіл

// X,Y - координати центру перетину всіх ліній

X:=round(X1[i]+(X1[k]-X1[i])/(D/A));

Y:=round(Y1[i]+(Y1[k]-Y1[i])/(D/A));

// X3,Y3 - координати першої точки перетину кола з утворюючим

//X4,Y4 - координати другої точки перетину кола з утворюючим

X3:=round(X-(Y-Y1[k])*H/B);

Y3:=round(Y+(X-X1[k])*H/B);

X4:=round(X+(Y-Y1[k])*H/B);

Y4:=round(Y-(X-X1[k])*H/B);

// Установка параметрів для побудови точок перетину

Image1.Canvas.Brush.Style:=bsSolid;

Image1.Canvas.Brush.Color:=clRed;

Image1.Canvas.Pen.Color:=clRed;// Побудова точок перетину кіл

image1.canvas.Ellipse(x3-3,y3-3,x3+3,y3+3);

image1.canvas.Ellipse(x4-3,y4-3,x4+3,y4+3);

// Різниця між координатами перетину i-го кола із утворюючим та i-го кола з k-м

if ((abs(y3-y33)<=1) and (abs(x3-x33)<=1) )

then begin

w:=w+1;

xx[w]:=x3; yy[w]:=y3; // формуємо масиви координат точок кристалізації

end;

if ((abs(y4-y44)<=5) and (abs(x4-x44)<=5) ) then

begin