Для поиска темы - пользуйтесь СИСТЕМОЙ ПОИСКА


Стоимость дипломной работы


Home Материалы для работы Особливості машинної реалізації моделюючого алгоритму

Особливості машинної реалізації моделюючого алгоритму
загрузка...
Рейтинг пользователей: / 0
ХудшийЛучший 

Особливості машинної реалізації моделюючого алгоритму 

Практика процедури і форми початкової організації інфо-рмації підтвержує наявність ситуації коли, не зважаючи на спрощеність до визначеної межі розуміння процедури, не всі вхідні параметри (ВП) і їх значення зрозумілі користувачам (ЛПР) системи „Агротехнолог” в режимі машинної експлуата-ції. Точніше, користувач може неадекватно реагувати на запи-тання ПЕОМ (в діалозі “ПЕОМ – людина”). В цьому випадку доцільним буде передбачити систему підказок, де надаються тлумачення змісту кожного ВП. Враховуючи об’єктивний чин-ник дефіциту кваліфікованих агрономів, такий підхід до ство-рення системи довідкової допомоги до процедур проектування технологій цілком виправдано. Цим самим забезпечується тех-нологічна підтримка проекту, підсилюється порозуміння між ПЕОМ і людиною, розширюються можливості діалогу і, наре-шті, людина отримує додаткові знання з технологічних питань, чим підвищує власну теоретичну освіту.
 В цілому СПТР „Агротехнолог” стає сервісно привабли-вішою і істотно, що з таких умов коефіцієнт корисної дії сісте-ми значно підвищується.
З таких міркувань  процедурі  надання пояснень до ВП слід приділяти особливу увагу, оскільки забезпечується комфо-ртність і підвищення сервісних можливостей системи.
Для формування підказок на початковому етапі організації інформації краще використовувати спеціальні форми (табл. 5.7), що спрощує представлення їх на етапах розробки алгорит-му і програмування.

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

Відомо, що ефективність використання системи і, як слід-ство, вироблених нею рішень можна досягти лише з умови су-місної роботи фахівця-експерта, програміста і ПЕОМ, раціона-льного розподілу між ними функцій. В цьому сенсі  найкращим буде варіант, коли застосовується діалоговий режим роботи.
Відразу зауважимо, що в реальному виробництві існують нестандартні задачі і непередбачені вимоги щодо управлінь, які виникають у заздалегідь не обумовлені часи на підставі відхи-лень течії виробничого процесу і умов навколишнього середо-вища від тих, що прогнозуються. Також звичайним для сільсь-когосподарських об'єктів (особливо технологій вирощування культур) є наявність великої кількості погано структурованих задач, для яких неможливо скласти у повній мірі формалізовану постанову і тому людина стає обов'язковим чинником процесів вироблення рішення. Тобто, технолог повинен мати можливість у нагоді уточнювати і змінювати постанову задачі, яка вирішу-ється, вносити зміни до структури моделі і критеріїв, вибирати різні алгоритми рішень.
Також треба враховувати, що інформаційна база зберігає не тільки дані у вигляді формалізованих документів з чисель-ною і символьною інформацією, але і значну кількість нефор-малізованих повідомлень у вигляді текстів. Крім того, спілку-вання користувача-агронома з ПЕОМ не може відбуватися на формалізованій мові.
Тому автоматизація процедур вироблення управляючих рішень потребує діалогового підходу, який крім вирішення не стандартизованих задач дозволяє підвищити якість рішень за рахунок оперативності спілкування ЛПР с ПЕОМ, можливості контролю вхідної інформації при введенні.
Виділимо особливості такого роду інтерактивних систем:
 - безпосередній контакт між ЛПР і системою;
 - обробка даних відразу після введення;
 - можливість колективного обслуговування користувача;
 - випадковий характер моменту ініціювання діалогу.
Декілька слів відносно особливості діалогу в задачах, які планується експлуатувати в режимі оперативного планування чи управління. Справа в тому, що визначені вище особливості тягнуть за собою низку проблем, вирішення яких є обов'язко-вим при створенні системи. Важливою з них слід вважати час реакції системи. Особливо це стосується задач, які функціону-ють в режимі реального часу, тобто таких, де обробка даних повинна відбуватись негайно з швидкістю достатньою, щоб ви-користати результати обробки для конкретного управління. Звідси витікає проблема синхронізації роботи користувача і си-стеми. Потрібно виключити періоди чекання користувачем від-повіді системи. Проблемою вважається і створення зручної структури діалогу. Сюди слід віднести і виділення процедур, розмов, обміну.
Під процедурою будемо розуміти найбільш високий рівень при виконанні якоїсь функції системи в діалоговому режимі; розмова - це серія обмінів, пов'язаних загальною метою і спря-мованих на реалізацію деякої функції; логічний обмін зв'язує одиничне введення з множиною можливих відповідей на нього.
В цьому ракурсі, спираючись на матеріли наведені в [130 - 132], конкретизуємо основні вимоги до діалогових систем, ма-ючи на увазі з одного боку трьох етапну процедуру вибору управлінь (одержання даних, аналіз, прийняття рішень), з іншо-го - необхідність забезпечення зручності введення діалогу (мо-ва, віддзеркалення інформації, організація процедур спілкуван-ня):
1. Забезпечення основних режимів отримання даних-складання типових довідок, отримання довідок любої форми.
2. Мови спілкування людини з ПЕОМ повинні бути зруч-ними для користувача, багатоваріантними. На верхньому рівні мова повинна бути орієнтована на користувача, який не є про-грамістом і наближеною до професійно-орієнтованої мови. Ця мова може мати декілька підмножин з урахуванням наявності користувачів різного рівня.
3. Повинні визначатись стандартні процедури обробки ін-формації, звернення до яких відбувається найбільш спрощено. До таких процедур слід віднести задачі ранжирування, групу-вання об'єктів по показниках, вибір по логічним умовам, отри-мання підсумків, порівняння параметрів, виявлення статистич-них зв'язків. Правильний вибір таких процедур дозволяє в по-дальшому суттєво скоротити час отримання рішень.
4. Розвинений механізм контролю вхідних повідомлень у зв'язку з можливістю помилок запиту або його багатозначніс-тю. У таких випадках система повинна направляти користувача за допомогою запитувань на зміну запиту.
5. Відповіді системи повинні бути по можливості однозна-чними і вичерпними.
6. Час реакції системи не повинен перевищувати декілька секунд.
7. Повиннен забезпечуватись захист даних від несанкціо-нованого втручання.
8. Повинен передбачатись режим: введення нових об'єктів і додавання нових параметрів; знищення об'єктів, зміна значень параметрів раніше сформованих об'єктів. Система повинна ма-ти можливість розвинення і бути адаптивною.
9. Передбачається можливість звертання до стандартних моделей дослідження операцій, а також до процедур реалізую-чих евристичні методи пошуку управлінь з поетапним коректу-ванням процесу вибору рішень.
10. Система повинна доповнюватись устроями, що дозво-ляють отримати тверді копії.
У принципі можливі такі види побудови діалогу:
1. Регламентований - коли активною стороною є ПЕОМ, а людина пасивна. Діалог з користувачем ініціюється по заздале-гідь описаному сценарію і полягає у відповідях користувача на запитання, що задаються у природній формі як макети і потре-бують заповнення на дисплеї. Простота організації діалогу по-в'язана з тим, що на кожному кроці діалогу система запитує (і приймає) значення відповідного параметра, реакція на який з боку системи, саме із-за його визначеності, вже закладена у сценарії.
2. Нерегламентований діалог - діалог за допомогою ко-мандної мови. Тут ініціатива за людиною і їй надається ком-плекс простих за семантикою команд. Однією з команд є ко-манда підказки, за допомогою якої формується список об'єктів, які цікавлять користувача. Користувач має можливість створю-вати пойменовані командні файли і виконувати їх, викликаючи  найменування. Така процедура дозволяє йому за бажанням (у потрібний термін) спрямовувати розрахунковий процес у необ-хідний бік.
Відмітимо ще один вид діалогу [133], що розбудовується за принципом  розпізнавання тієї чи іншої кількості ключових слів, яким відповідають списки правил декомпозиції пропози-цій на фрагменти, в котрих ці слова можуть зустрічатись. Кож-ному такому правилу відповідає список правил конструювання відповіді.
Можливо припустити, що на перших ступенях створення діалогових систем для задач СПТР більш переважним буде рег-ламентований діалог, який забезпечує прості, технологічні і ефективні форми спілкування сторін.
Діалогові процедури спроможні виконувати одну або декі-лька базових функцій:
 -введення і контроль змін, створення, оновлення або лік-відацію запису постійних масивів бази даних;
 -запит на обробку, що веде до виконання однієї або декі-лькох програм;
 -запит на перезаписування, або передачу тих чи інших да-них масиву в інший масив.
В нашому випадку, коли мова йде про деяку автоматизо-вану задачу прийняття рішень, стає питання відносно раціона-льного поділення функціональних діалогових процедур на час-ні схеми діалогу, яким будуть відповідати і часні програмні мо-дулі, що їх реалізують .
Практика розробки показує, що основними факторами, які слід враховувати у разі організації діалогових процедур були - простота використання і фактор часу. Строки виконання зале-жать від простоти використання процедур: користувачу зручно, коли процедура вміщує лише ті функції, які йому потрібно ви-конувати у конкретний момент.
Програмне забезпечення (ПЗ) діалогових систем, як пра-вило, складається з базового і спеціального. У якості базового ПЗ представлені засоби операційної системи, в сфері яких фун-кціонує діалогова система. З використанням таких ПЗ відбува-ється розробка і відладжування діалогових систем за відомими принципами.
До спеціальних засобів ПЗ відносяться пакети прикладних програм (ППП), що орієнтовані на створення діалогових сис-тем. ППП¬¬ - ¬це універсальні програмні засоби, що настроюються на конкретне використання за вказівкою користувача. Вико-нання дій, пов'язаних з введенням-виведенням на дисплей від-буваєься через звертання до стандартних засобів операційних систем.
Створення діалогових систем на базі ППП є менш праце-містким (і суттєво) у порівнянні з використанням стандартних засобів операційних систем і прийнятих там мов програмуван-ня.
У вигляді блок-схеми алгоритм функціонування СПТР в режимі проектування технологій наведена на рис.5.5 (фрагмент програми машинної реалізації в додатку Г). Частина блоків схеми виконують допоміжні функції, а основні реалізують ал-горитми проектування конкретних технологічних процесів.
 
Підкреслимо, що у процедурі машинної реалізації алгори-тму ми цілком свідомо з причин описаних раніше, ініціативу в діалозі "людина-комп'ютер " віддали машині. На рівні запиту користувачеві пропонується ввести адресу об'єкту, вказати свою спеціальність, обрати рівень планування ( період, техно-логію в цілому, технологічний процес, операцію).
В процесі діалогу, машина пропонує з впливаючих на  рі-шення вхідних параметрів, обрати конкретні, відповідні до си-туації. При цьому користувачу надається можливість одержати додаткову інформацію щодо ВП.
Загальний вигляд меню машинної реалізації алгоритму на-ведено на рисунку 5.6.
Якщо приймаються рішення у відношенні агрозаходів, що залежать від чинників, які мають кількісні характеристики, тоб-то, легко формалiзуємих, пропонується уточнити рішення за допомогою розрахунків. Для цього використовуються задачі з розрахункового модулю. В такому випадку cутність проекту і рішення, які приймаються на його підставі будуть більш обґру-нтованими. Оскільки в цих задачах використовується інформа-ція складної структури, то незважаючи на простоту алгоритмів і моделей, буде справедливим вважати  їх досить складними, що заслуговують на особисте розглядання.
Підкреслимо, що під час проектування СПТР ставилася задача багаторівневого використання системи: в виробництві, в напрямку освіти і наукових досліджень. Тому для кожного ва-ріанту вибору створювалися спеціальні коментарі і обґрунту-вання щодо рекомендацій.

Встановлено, що між параметрами ТО і об'єктів управлін-ня існують певні залежності. Пов'язані тією чи іншою формою, залежності і параметри об'єкту, створюють ситуацію, коли змі-на одних змінює характеристики інших. Ці зв'язки можуть мати як кількісні значення, так і якісний вислів. Тому в коментарях розкривається механізм дії операції на об'єкт, описується хара-ктер прямого і побічного ефекту. Крім того, сервісні можливос-ті системи дозволяють користувачу доповнити  (оновити) свої знання в предметній галузі, звернувшись до спеціального фон-ду, а змінюючи умови проектування ( вхідні параметри, їх ха-рактеристики, рівень планування і т.ін.), порівняти декілька альтернативних рішень. Одержані рекомендації повністю, або їх фрагменти можуть бути виведені на екран і надруковані.
Кінцевою метою моделювання, як відомо, є одержання програми агрозаходів у формі документу. Документ стає більш привабливим і сприймається краще, якщо програма надається в традиційному виді, тобто, у вигляді таблиці, де рядки відпові-дають операціям, а графи термінам проведення агрозаходів і їх параметрам. Послідовність рядків повинна відбивати черговість операцій в часі.
Уявлення відносно схеми реалізації алгоритму технології через мащинний синтез надають рисунки 5.6 і 5.7.
1. Запровадження запиту. Форма запровадження універса-льна і різниться поміж культурами конкретним змістом вхідних параметрів. В запиті зазначається: адреса поля, культура, сорт (гібрид), площа поля, урожайність, коди вхідних параметрів
При заданому періоді планування вибирається комплекс функціональних модулів, відповідним цікавлячим користувача технологічним процесам (операціям). Якщо період планування не задається, проектування технології відбувається у повному обсязі.
Для зручності користувача вводиться система необов'язко-вих параметрів. Це ті параметри для яких система автоматично привласнює їм стандартні регіональні значення, якщо не зазна-чаються конкретні значення. З цією метою до системи вводять-ся довідники обмежень.
2. Контроль запиту заснований на послідовному порівнян-ні даних, що вводяться з відповідними порогами.
3. Аналіз сукупності вхідних параметрів. Перевіряється не протиречiвість їх одне одному. Якщо виявляється, що вхідні параметри задані невірно, то з'являється повідомлення.
4. Виводиться програма агротехнічних заходів в порядку їх природної череди і у обсязі, відповідному зазначеному в за-питі режиму видавання, а в пам'ять заносяться шифри потріб-них даних (для використання в інших підсистемах).
Експлуатація СПТР в такому режимі  забезпечує розробку і видавання технологічного проекту одержання урожаю на кон-кретному полі.
На рівні господарства колективної форми власності, або фермерського схема функціонування системи може включати слідуючи заходи (рис. 5.7):

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


 
загрузка...

Добавить комментарий


Защитный код
Обновить