Формальная модель графического интерфейса

Модель графического интерфейса строилась на основе «Руководство пользователя системой DVM». Сама функциональность системы рассматривалась как «черный ящик», в котором интересовали лишь точки входа и выхода. Точками вода в систему являются вызовы всех ее команд, поскольку, при наличии правильных (распознаваемых системой) входных данных, работа с системой может быть начата с выполнения любой из них.

Эти команды являются логическими единицами работы системы. Для проектирования модели интерфейса на их основе было построено множество вариантов использования. Множество это состояло из следующих элементов (по названиям соответствующих команд).

· dvmCompile&Link(cc/f77)

· dvmCompile&Convert(c/f)

· dvmCompile(cdvfdv)

· dvmCSDEB(fsdeb)

· dvmCPDEB(fpdeb)

· dvmRun

· dvmRunpred

· dvmTrc

· dvmSixe

· dvmErr

· dvmDif

· dvmPtrc

· dvmPred

· dvmPA

· dvmRed

Кроме того, отдельными вариантами использования, стали команда показа документации (dvmDoc) и команда настройки DVM-системы (dvmSettings) Вышеперечисленные команды принимают на вход имя DVM-программы, находящейся в некотором состоянии: написанной в формате cdv или fdv, откомпилированной, исполняемой рабочей или отладочной, параллельной или последовательной. Графический интерфейс должен учитывать не только тип файла, требуемого для выполнения dvm команды, для того, чтобы подсказать его пользователю и проверить правильность его выбора. Интерфейс также должен учитывать в какой последовательности эти файлы создаются и используются для работы, для того, чтобы смочь предложить или подсказать пользователю определенный порядок действий, для повышения эффективности работы с системой.

Итак, первая диаграмма модели интерфейса (см. диагр. 1) - это усложненная диаграмма вариантов использования, которая описывает связи между вариантами использования и акторами системы, в качестве которой (в этой диаграмме, в отличие от других) выступают не только пользователь и сама система, но и файлы, содержащие DVM-программу. Эта диаграмма содержит возможные цепочки выполнения команд, которые в реализации модели могут быть объединены для повышения эффективности. Подробная диаграмма вариантов использования получилась слишком громоздкой, поэтому модель содержит более простой (классический) вариант диаграммы (см. диагр. 2) В этой диаграмме только два актора: пользователь и система. Зато, в силу того, что модель описывает не саму систему, а ее интерфейс, и, следовательно, пользователю может быть предложен визуализированный выбор (в виде пунктов меню, или различных кнопок), набор вариантов использования увеличился, за счет введения двух новых : dvmFullDebug, который предлагает пользователю выбрать способ отладки - сравнение трассировок или метод динамического контроля, и dvmDebug, который предлагает пользователю ввести необходимые данные, для того, чтобы произвести отладку методом сравнения трассировок за один шаг. (То есть, интерфейс, накопив данные параметров требующихся команд, по выбору этого варианта использования последовательно передает системе указания генерировать последовательный и параллельный варианты программы и эталонную трассировку, произвести сравнение трассировок, и в случае нахождения ошибок сравнения, сгенерировать параллельные трассировки, для дальнейшего анализа ошибок.) Это объединение команд необязательно для интерфейса, но, так как оно допустимо, и может быть желательным, имеет смысл включить его в модель, не исключая, впрочем вариантов, основанных на отдельном использовании этих команд.

Диаграмма 1

Диаграмма 2

В модели описано наличие анализатора ошибок, однако, в связи с тем, что его функциональность, на данный момент до конца не определена, анализатор в модели описан в виде заглушки, принимающей от системы список ошибок, и общающийся с пользователем посредством команд «запросить информацию об ошибке», «выдать информацию об ошибке». При уточнении требований к анализатору, и при необходимости построить графический интерфейс его включающий, данная формальная модель подскажет где и как разместить обращения к нему. В модели же, анализатор представлен вариантом использования ErrorAnalize. Кроме того, модель унифицирует команды одного смысла, заданные для программ написанных на языке C-DVM и Fortran-DVM. Это сделано для того, чтобы значительно упростить построение интерфейса - при одинаковом «смысле» команды и заданных параметрах интерфейс способен сам построить правильное обращение к DVM-системе.

Теперь рассмотрим модель детально. Модель разбита на абстрактные классы. Каждому варианту использования соответствует один CONTROL (управляющий) класс, и два BOUNDARY (граничных) класса. BOUNDARY классы - это абстракции, принимающие входные данные у пользователя или передающие эти данные DVM-системе. Граничные классы модели, связывающие актора (пользователя) и управляющие классы, соответствуют графическим компонентам интерфейса, таким как ока, поля для ввода текста, кнопки, меню, переключатели выбора и т.д. Граничные классы взаимодействующие с CONTROLами и самой системой, являются описанием вызова нужной командной строки из интерфейса. Управляющие же классы принимают от граничных выбранные пользователем параметры и строят на их основе правильную dvm-команду, передавая затем ее «вторым» граничным классам. Такие же два граничных класса предусмотрены для анализатора ошибок. Независимо от конечной реализации интерфейса, построенной на основе этой модели, эти классы, и связанные с ними диаграммы взаимодействия (поясняющие как и в каком порядке происходит обработка событий в интерфейсе) и кооперативные диаграммы (раскрывающие связи компонентов интерфейса между собой), останутся базой для его построения, которое сведется к итеративному наращиванию модели. Примеры диаграмм взаимодействия и кооперативных диаграмм приведены в приложении.(диаграммы 3-16). Все эти диаграммы описывают абстрактную модель, которая может служить основой для любой реализации интерфейса для DVM-системы, обеспечивая выполнение пяти требований к интерфейсу. То есть, такая модель .делает доступными все точки входа в систему. Она предполагает проверку параметров команд, до их запуска на выполнение, она предлагает основу для построения инструмента, работающего с ошибками, и способна снизить суммарную стоимость владения системой из-за четкого разделения вариантов использования, то есть из-за стиля интерфейса, предлагающего подсказки при вводе параметров команд.