Web-орієнтована система для аналізу використання ресурсів комп’ютерної аудиторії студентами

Користуючись  функцією отримаємо наступну формулу середньодобової тривалості використання ресурсу

 

, (2.3)

 

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

Обчислення середньої частки роботи з ресурсом у стаціонарному стані можна виконати за формулою

 

, (2.4)

 

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

Середня тривалість роботи з ПК може бути обчислена за формулою

 

, (2.5)

 

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

Очевидно, що коли встановити , де – нинішня дата, то , тобто середні оцінки тривалості використання ресурсу (2.3), частки (2.4) та тривалості користуванням комп’ютером (2.5) стають оцінками стаціонарного стану, що уточнюються щодня внаслідок дії закону великих чисел Чебишева-Бернуллі, див. [7].

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

Отже  показник динаміки розраховується на час подачі запиту на отримання поточної картини часток звернення до ресурсу, наприклад, так

 

, (2.6)

 

де  – час подачі запиту на обрахунок поточної частки тривалості користування програмою в загальному обсязі часу користування комп’ютером в нинішню добу , – тривалість користування програмою в нинішню добу на момент подачі запиту (t= ).

Кожного разу при подачі запиту система  дає нову оцінку показника частки тривалості роботи з програмою  . Ці показники слід протоколювати у базу даних і відображати у таблиці діалогового вікна прикладної частини системи, див. §3.2.

2.2. Проектування програмного забезпечення  системи

Для проектування прикладної частини  програмного забезпечення системи  аналізу використання ресурсів комп’ютеризованих  аудиторій скористаємося об’єктно-орієнтованим підходом на базі універсальної мови моделювання UML на основі методики, запропонованої Брюсом Уамплером в [35]. Ця методика складається з наступних етапів:

1. Написання специфікації системи на природній мові.
2. Опис системи однією із найзагальніших діаграм мови UML, а саме діаграмою способів використання системи (Use-case).
3. Формулювання письмового опису кожного способу використання з супровідними сценаріями.
4. Пошук об’єктів, атрибутів та методів.

На першому етапі проектування необхідно написати специфікацію розроблюваної системи. Згідно з [35] специфікація повинна містити:

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

 

Для того, щоб розробити вдалу  специфікацію, ми скористалися досвідом класиків у галузі об’єктно-орієнтованого проектування, зокрема, досвідом Брюса Уамплера, який на 195 сторінці своєї книги [35] навів приклад специфікації системи. Отже за аналогією до його специфікації сформульовано специфікацію для системи аналізу використання комп’ютерних ресурсів ВНЗ, що наведена далі.

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

Додаток потрібно розробити як „настільну” програму Java або веб-додаток на основі технології Java server pages [27], він повинен мати графічний інтерфейс користувача (GUI), що є простим та зручним у використанні.

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

Інформацію про користування комп’ютерними ресурсами додаток повинен подавати в двох режимах: статичному та динамічному. При виборі „статичного” режиму користувач повинен обрати дату, починаючи з якої система обчислюватиме показники функціонування ПЗ: загальна та середньодобова тривалість роботи з програмами, середньодобова частка роботи з кожною програмою, середня тривалість роботи з ПК протягом доби.

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

Для зручності вищенаведену специфікацію повторено у додатку А. На основі специфікації розроблено use-case діаграму системи аналізу використання комп’ютерних ресурсів аудиторій ВНЗ, що зображена на рис. 2.1.

Рисунок 2.1 – Діаграма способів використання системи

 

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

Сценарій редагування списку ІР-адрес підконтрольних ПК:

1. Система відображає діалогове вікно чи форму з поточним списком ІР-адрес підконтрольних ПК комп’ютерної аудиторії.
2. Користувач обирає одну з дій: добавити ІР-адресу, вилучити ІР-адресу, редагувати ІР-адресу.
3. Система надає інтерфейс, необхідний для виконання обраної користувачем дії.

 

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

1. Система виводить діалогове вікно чи форму, де перелічено назви всіх виконуваних файлів, що були будь-коли спостережені на підконтрольних ПК. Навпроти кожної назви – категорія, до якої він належить, а саме текстові процесори, браузери, засоби розробки, засоби моделювання, засоби відтворення (аудіо-відео програвачі, переглядачі зображень та текстів), службові (для роботи з принтером, DVD-записувачем), розважальні (ігри), шкідливі (троянські коні). Коли файл ще не було категоризовано, то навпроти нього стоятиме напис „невідома категорія”.
2. Користувач обирає у цьому списку назву одного із виконуваних файлів, клацнувши на ньому мишею.
3. Система виводить нове діалогове вікно, в якому користувач повинен обрати категорію, до якої належить обраний виконуваний файл.

Сценарій перегляду статистики використання комп’ютерних ресурсів у статичному режимі:

1. Користувач обирає дату, починаючи з якої потрібно обчислювати статистичні характеристики використання ресурсів комп’ютерної аудиторії.
2. Користувач натискає кнопку „Обчислити”.
3. Система завантажує список тривалостей роботи з програмами з підконтрольних робочих станцій починаючи від обраної дати до теперішнього часу.
4. На основі завантаженого списку тривалостей система обчислює показники загальної та середньодобової тривалості роботи з програмами, середньодобової частки роботи з кожною програмою, середньої тривалості роботи з ПК протягом доби. Усі показники відображаються у новому діалоговому вікні в таблицях, що відсортовані в порядку спадання значень тривалості.

Сценарій перегляду статистики використання комп’ютерних ресурсів у динамічному режимі:

1. Система виводить список підконтрольних робочих станцій.
2. Користувач обирає одну з робочих станцій у списку.
3. Система надсилає запит на обрану робочу станцію, вимагаючи інформації про тривалості використання прикладних програм у нинішній день.
4. Система обчислює процентні частки тривалості використання програм кожної категорії і протоколює їх у базі даних, асоціюючи з датою-часом надіслання запиту.
5. Система відображає нове діалогове вікно з таблицею, де відображено протокол часток тривалості з бази даних.
6. Коли користувач натискає кнопку „Оновити”, система повторює всі кроки цього сценарію, починаючи з третього.

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

Прочитання тексту специфікації дозволило виявити наступний список іменників: додаток, працівник ВНЗ, користувач, аналіз роботи студентів з комп’ютерними ресурсами, лабораторія, прикладна програма, інженер лабораторії, Java, веб-додаток, технологія Java server pages, графічний інтерфейс користувача, список ІР-адрес, аудиторія ВНЗ, виконувані файли, категорії, текстові процесори, браузери, засоби розробки, засоби моделювання, засоби відтворення, службове ПЗ, розважальне ПЗ, шкідливе ПЗ, невідоме ПЗ, заняття, „статичний” режим, „динамічний” режим, дата, тривалість роботи з програмами, загальна тривалість роботи з програмами, середня тривалість роботи з програмами, середня частка тривалості роботи з програмами, середня тривалість роботи з ПК, динаміка частки машинного часу.

У додатку А наведено таблицю, де на основі аналізу іменників у тексті специфікації (див. попередній абзац) знайдено класи системи і їхні атрибути.

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

Висновки до розділу 2

За результатами другого розділу  зроблено наступні висновки:

1. Обчислення середніх оцінок тривалості використання ресурсів, її частки та роботи ПК у стаціонарному стані щодня уточнюється внаслідок дії закону великих чисел (Чебишев-Бернуллі).
2. Показники динаміки користування ресурсами в нинішню добу дозволяє протоколювати у базі даних аналітичні дані частки використання ресурсів. Це дає змогу отримувати таблиці та графіки траєкторії частки тривалості використання комп’ютерних ресурсів.

 

Розділ 3 
Програмна реалізація і дослідження системи

3.1. Реалізація системної частини веб-орієнтовагого додатку

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

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

Реалізація  алгоритму 2.1 вимагає пошуку функцій ядра, що фіксують ідентифікатор активного вікна (1.2), реалізують відображення (1.3) та (1.5).

Ідентифікатор активного вікна (1.2) можна визначити за допомогою функції ядра ОС Windows GetForegroundWindow(), наприклад, таким кодом:

 

HWND active_window = GetForegroundWindow();

 

де  active_window – ідентифікатор вікна , що для 32-розрядних ОС може приймати значення в діапазоні .

Реалізація відображення (1.3) може бути здійснена за допомогою функції DWORD GetWindowThreadProcessId(HWND active_window, DWORD *pid). Ця функція повертає ідентифікатор потоку, якому належить вікно, а ідентифікатор процесу вписує за адресою, на котру вказує другий аргумент – DWORD *pid. Код, що визначає ідентифікатор процесу , якому належить активне вікно може виглядати наступним чином:

 

DWORD pid;

DWORD tid = GetWindowThreadProcessId(active_window, &pid);

 

де pid – ідентифікатор процесу, якому належить вікно , тобто pid= .

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