CC BY
30
i $ ■Ф' Ф -Ф & $ & & «& %
Номер цикла
Рис. 4. Зависимость объема плавающего мусора от номера цикла сборки мусора
На рисунке 4 показаны зависимости объемов плавающего мусора (в Кб) от номера цикла сборки мусора с р = 0,1 для Np = 6. Графики строились с использованием следующих условий: шШп= 1Кб; N = 411; А(еай = 411.
В таблице 2 приведены данные о номерах циклов, на которых происходит насыщение, и о максимальном объеме плавающего мусора (в Кб), рассчитанные с теми же исходными условиями для различных р и Np. Как видно из таблицы, значения номера цикла насыщения в лучшем из рассмотренных случаев р=0,1 и Np =2 и худшем из рассмотренных случаев р=1 и Np =10 различаются в 84 раза. А объемы памяти, занимаемые плавающим мусором, различаются в 44 раза для одного и того же приложения. Это говорит о необходимости применения способов, позволяющих локализовать указатели в пределах минимально возможного количества подпространств.
Рассмотренный подход позволяет оценить потери памяти, которые могут возникнуть в ходе работы системы. На основе предварительных данных система может быть настроена на использование определенных приложений, которые могут различаться наборами характеристик, таких как структуры данных, объемы размещаемой памяти, связность графа достижимости. Верхняя граница объема используемой памяти, полученная на основе сведений о работе приложений и характеристиках системы, гарантированно не будет превышена.
Существуют другие схемы выбора подпространства для выполнения текущего цикла сборки мусора, для каждой из которых необходимо рассмотреть
Таблица 2
Np P
0.1 0.2 0.3 0.5 0.7 1
2 цикл 44 85 126 208 290 413
м„ш 17223 31532 44160 64373 77862 85488
3 цикл 86 168 250 414 578 824
м„ш 33624 62242 87498 127924 154902 170154
4 цикл 128 251 374 620 866 1235
м„ш 50025 92952 130836 191475 231942 254820
5 цикл 170 334 498 826 1154 1646
66426 123662 174174 255026 308982 339486
6 цикл 212 417 622 1032 1442 2057
Мта1 82827 154372 217512 318577 386022 424152
7 цикл 254 500 746 1238 1730 2468
99228 185082 260850 382128 463062 508818
8 цикл 296 583 870 1444 2018 2879
115629 215792 304188 445679 540102 593484
9 цикл 338 666 994 1650 2306 3290
132030 246502 347526 509230 617142 678150
10 цикл 380 749 1118 1856 2594 3701
148431 277212 390864 572781 694182 762816
наихудший случай исполнения. Приведенные рассуждения являются лишь частью работы по оценке наихудшего случая использования памяти. Необходимо также получить оценку работы применяемых алгоритмов сборки мусора и размещения новых блоков памяти. Для прогнозирования работы и конфигурации системы с учетом рационального использования ресурсов достаточно использовать результаты исследования исполнения сборки мусора в худшем случае.
Список литературы
1. Richard Jones, Rafael Lins. Garbage collection: algorithms for automatic dynamic memory management. Chichester, England, John Wiley & Sons, 1996.
2. Jonathan E. Cook, Alexander L. Wolf, Benjamin G. Zorn, A Highly Effective Partition Selection Policy for Object Database Garbage Collection IEEE Transactions on knowledge and data engineering, Vol. 10, NO. 1, January/February 1998.
3. Andrew W. Appel Simple Generational Garbage Collection and Fast Allocation Department of [3]. Computer Science Princeton University, March 1988.
4. Barbara Liskov Umesh Maheshwari Tony Ng Partitioned Garbage Collection of a Large Stable Heap (Extended Abstract) Published in the Proceedings of IWOOOS, October 1996.
РЕАЛИЗАЦИЯ СТРУКТУРНОГО АНАЛИЗА ПРИКЛАДНОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
И.Р. Музяков, Н.Г. Мустафин, С.В. Савосин
Практически все прикладные программные продукты, находящиеся сегодня в одном классе решаемого ими определенного круга проблем, схожи друг с другом по составу решаемых функциональных за-
дач. Основной отличительной особенностью таких систем является прикладной пользовательский интерфейс (ППИ), который в наибольшей степени определяет удобство работы пользователя с системой.
41
Поэтому неудивительно, что вопросы проектирования качественного ППИ при разработке, отладке и эксплуатации программного продукта приобретают все более высокий приоритет.
Можно выделить некоторые направления разработки прикладного программного обеспечения, для которых проблема проектирования качественного ППИ достаточно актуальна.
В первую очередь эта проблема касается информационных и информационно-управляющих систем. Наличие прозрачного и удобного интерфейса в таких системах влияет на первичное восприятие, а следовательно, в значительной степени на их востребованность при выборе продукта заказчиком. Необходимо также учесть и влияние ППИ на эргономические показатели работы пользователя (скорость обработки информации, утомляемость, количество допускаемых ошибок и т.п.) [1].
Проблема создания качественного ППИ также стоит при разработке интернет-приложений. В таких системах основная проблема заключается в построении структуры приложения, при которой пользователь без труда смог бы найти необходимую ему информацию. К сожалению, пользовательский интерфейс многих интернет-сайтов нельзя оценить как продуманный и прозрачный. Этому есть вполне объективные причины - такие приложения обычно имеют эволюционный способ развития, и их структуру достаточно сложно определить на этапе начального проектирования.
Еще одним аспектом, усиливающим интерес к методам разработки ППИ, является тот факт, что в последнее время все большое распространение приобретают методы компонентного проектирования программных систем. При создании таких систем основная проблема заключается в стыковке компонент и организации взаимосвязи между ними. Структура взаимосвязей, а также взаимодействие компонент непосредственно с конечным пользователем является важнейшим этапом при разработке и значительным качественным фактором при эксплуатации такой системы.
Несмотря на большую значимость ППИ, его проектирование основывается на интуитивных данных разработчика, а качество напрямую зависит от его опыта и таланта. В связи с этим встает вопрос использования формальных методов проектирования ППИ.
В качестве попытки решения данной проблемы некоторые системы включают в себя возможность осуществлять настройку ППИ. На сегодняшний день существуют системы, позволяющие пользователю задавать и изменять пункты меню, набор функциональных кнопок на панели инструментов и т.п. Но данный механизм работает только при уже существующих и каким-то образом полученных рекомендациях по модификации структуры ПИ.
Возникает необходимость создания механизма, позволяющего выдавать рекомендации по модификации структуры ППИ. Для решения данной задачи предлагается использовать специализированную компоненту, интегрированную в состав ППИ и мо-
дули проекта, которая будет отвечать за сбор, хранение, обработку и анализ характера навигации пользователя по структуре программного продукта при его работе с системой на этапе опытной эксплуатации.
При решении задачи предлагается использовать метод анализа пользовательского интерфейса [2] на основе статистических данных о последовательности вызовов программных модулей при работе с информационной системой.
Рассмотрим пример использования данного метода в реальных приложениях, а именно структуру программного компонента сбора статистических данных (КССД). Как средство описания структуры КССД используем нотацию ИМЬ.
В качестве основного анализируемого элемента (рис. 1) выступает класс Контролируемый объект (КО), соотносимый с теми классами в реализации системы, изменение состояний объектов которых требуется отслеживать. То, что на рисунке отражен лишь один класс КО, продиктовано соображениями компактности и наглядности рисунка.
Каждый КО включает в себя в качестве члена один экземпляр класса Активатор и содержит служебную информацию: наименование модуля и вид деятельности. Информация о виде деятельности непосредственно связана с функциональным назначением КО и может быть использована при анализе статистических данных. При активизации КО вызывается метод, регистрирующий событие входа в модуль (подпрограмму), при деактивизации вызывается метод, регистрирующий выход из модуля. При этом возникает событие Смена состояния, обрабатываемое экземпляром класса Регистратор. Информация о переходе системы из одного контролируемого со-
42
стояния в другое представляется в виде экземпляров класса Переход и далее сохраняется в БД КССД.
Функционирование КССД иллюстрируют диаграммы состояний и последовательности (рис. 2 и рис. 3).
Таким образом, в процессе работы пользователя с приложением в БД КССД накапливается статистика о последовательности активизаций программных КО приложения и о характере выполняемых пользователем работ.
Пример реализации приведем с использованием языка Object Pascal (Borland Delphi). Дадим описание класса TActivater. type
TActivater = class private
Fmodule : Integer; Fdependence : Boolen; FWorkType : Integer; public
procedure DoRegistrationEnter (ModuleID, WorktypeID :Integer);
procedure DoRegistrationExit (ModuleID, WorktypeID :Integer);
property Module : Integer read Fmodule write Fmodule; property Dependence : Boolen read Fdependence write Fdependence; property WorkType : Integer read FWorkType write FWorkType; end;
Данный класс отвечает за связь модуля, в котором находится экземпляр класса, с БД, хранящей данные о переходах между модулями.
Класс состоит из трех полей и основанных на них трех свойств и двух методов. Свойство Dependence определяет зависимость модуля, в котором находится экземпляр класса, от других модулей. Если свойство является ложным, то данный модуль может быть вызван из любого модуля и пункта меню интерфейса в программе, то есть он не имеет входных данных.
Свойство WorkType определяет характер выполняемой работы модулем (пользователем в модуле), например, расчетные действия, редактирование данных, ввод данных и т.д. Свойство Module определяет уникальный номер модуля.
Процедуры DoRegistrationEnter и DoRegistrationExit выполняют регистрацию события входа или выхода из модуля.
В программах, созданных в операционных системах (ОС), не поддерживающих многозадачный режим работы, нет необходимости регистрации выхода из модуля. Моментом выхода будет являться момент входа в другой модуль (подпрограмму). В многозадачных ОС (Windows, Unix, Linux и др.) необходимо также регистрировать и момент выхода из модуля (подпрограммы), так как несколько подпрограмм могут работать одновременно.
Класс TActivater работает с блоком Registrar. Данный блок является связующим звеном между экземплярами классов TActivater и БД, содержащей информацию о последовательности вызовов и характере работы программных модулей системы.
БД, с которой работает данный блок, в простейшем случае содержит две реляционные таблицы: справочник «типы выполняемых работ» с полями уникальный идентификатор, название работы и БД для хранения вызовов программных модулей с полями уникальный идентификатор события, идентификатор модуля, дата и время поступления события, тип события (вход в модуль или выход).
В процессе работы системы при каждом входе и выходе из модуля (подпрограммы) производится регистрация данного события в БД. Таким образом, на этапе опытной эксплуатации системы накапливается информация, по которой можно судить о характере работы операторов на рабочих местах. На основе полученных данных можно построить модели работы оператора для каждого АРМ.
Данная информация может быть полезной в качестве обратной связи между разработчиками и пользователями системы при ее проектировании. Коме того, данная информация может быть использована при выборе комплекса аппаратных средств для комплектации АРМ.
Список литературы
1. Шибанов Г.П. Количественная оценка деятельности человека в системах человек-техника. - М.: Машиностроение, 1983.
2. Музяков И.Р., Мустафин Н.Г., Савосин С.В. Статистический анализ пользовательского интерфейса. // Программные продукты и системы. - 1999. - № 4.
43
