Графический интерфейс должен удовлетворять следующему:

· Графический интерфейс DVM-системы должен открывать все возможные точки входа в DVM-систему. Исключение составляет администрирование системы из соображений безопасности.

· Графический интерфейс DVM-системы должен осуществлять проверку всех значений, подаваемых пользователем на точки входа. В ряде случаев, интерфейс не должен допускать ввода таких значений, посредством блокировки соответствующих графических компонентов. Иначе, при несоответствии ожидаемому значению, графический интерфейс DVM-системы должен, перехватывать исключительные ситуации системы и, извещая об этом пользователя, позволять ему поменять входные данные.

· Графический интерфейс DVM-системы должен позволять повышать эффективность работы с системой, путем предоставления пользователю специальных инструментов, по поиску необходимой информации.(Анализ ошибок, использование диалоговых окон для работы с файлами и т.д.)

· Графический интерфейс DVM-системы должен предоставлять пользователю текстовый редактор, дающий возможность вносить изменения в исходный код, не переключаясь на другие приложения.

· Графический интерфейс DVM-системы должен работать под операционными системами Unix и Win95/NT.

· Графический интерфейс DVM-системы должен быль написан с учетом того, что DVM-система постоянно обновляется. Его исходный код должен быть спроектирован с учетом возможных изменений, и должен содержать все необходимые комментарии.

· Графический интерфейс DVM-системы должен корректно работать с сообщениями об ошибках выполнения команд DVM-системы, и при возникновении таких ошибок, выводить всю информацию на экран.

· Графический интерфейс DVM-системы должен хранить в доступном пользователю виде, информацию о проделанных операциях с DVM-системой, и, по возможности, выдавать пользователю разнообразные подсказки, для снижения суммарной стоимости владения программой.

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

Как стало видно, известен ряд свойств, которым должен удовлетворять графический интерфейс DVM-системы. Однако, сам интерфейс удовлетворяющий всем этим требованиям еще не построен. В настоящее время продолжается развитие и совершенствования DVM-системы, расширяется круг её возможностей. Это обстоятельство не позволяет создать окончательную версию графического интерфейса. Для облегчения этой работы в будущем создана модель, формально описывающая оптимальный интерфейс DVM-системы. Мной создана наиболее точная на сегодняшний день реализация этой модели. Когда будет завершена работа над DVM-системой, эта реализация, с использованием модели, может быть легко модифицирована и приведена к окончательному виду.

 

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

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

Немаловажная вещь в программировании, недооцениваемая многими – это технология программирования. Без использования соответствующих технологий, разработка программного обеспечения оказывается на уровне экстремального программирования. Для разработки формальной модели графического интерфейса, я использовала технологию RUP (Rational Unified Process). Эта технология использует принципы итеративного наращиваемого подхода к созданию программного обеспечения и планирования управления проектом на основе вариантов использования.

Для построения модели использовалась среда Rational Rose, и язык UML. Разработка модели велась на основе формального описания DVM-системы и перечня требований к графическому интерфейсу DVM-системы.

С помощью технологии RUP, для формальной модели графического интерфейса были построены все необходимые диаграммы и приведены соответствующие описания. В процессе разработки формальной модели были соблюдены требования стандарта ISO 12207. При возобновлении разработки графического интерфейса DVM-системы, сравнение с формальной моделью позволит оценить соответствие интерфейса всем требованиям.

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

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

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

· dvmCompile&Link(cc/f77)

· dvmCompile&Convert(c/f)

· dvmCompile(cdv\fdv)

· 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-системы, обеспечивая выполнение пяти требований к интерфейсу. То есть, такая модель .делает доступными все точки входа в систему. Она предполагает проверку параметров команд, до их запуска на выполнение, она предлагает основу для построения инструмента, работающего с ошибками, и способна снизить суммарную стоимость владения системой из-за четкого разделения вариантов использования, то есть из-за стиля интерфейса, предлагающего подсказки при вводе параметров команд.

 

Глава 4. Графический интерфейс DVM-системы – ГРИФ

Как устроен ГРИФ

На основе модели графического интерфейса DVM-системы, я разработала интерфейс ГРИФ. (Его название – аббревиатура ГРафический ИнтерФейс.). Эта программа отвечает требованиям к интерфейсу, которые диктует DVM-система на сегодняшний день. Поскольку, не все требования учтенные в абстрактной модели, представляется возможным ваполнить на настоящей стадии развития DVM-системы, то некоторые из них не были выполнены. Это относится к требованиям: открыть в интерфейсе для пользователя все точки входа и проверять все вводимые пользователем значения параметров. И то и другое отклонения от модели обусловлено тем, что некоторые инструменты системы сейчас претерпевают значительные изменения. Улучшение этих инструментов затрагивает и возможности пользователя управлять ими, и как следствие, влияет на интерфейс. По этой причине, интерфейс, реализованный мною, не содержит компонентов, связанных с анализатором производительности и предиктором.

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

Интерфейс написан на языке программирования JAVA. В прошлом, мной был написан интерфейс отладчика DVM-системы в среде Delphi, на языке Object Pascal, и этот опыт подсказал, что когда возникнет необходимость создавать интерфейс всей системы, его нужно будет создать платформо-независимым. Так как сама DVM-система может работать под операционными системами семейства Windows95/NT и Unix, то хотелось бы ожидать не меньшей преносимости и от интерфейса. А так как интерфейс может включать в себя и некоторые инструменты анализа (как то простейший анализ ошибок выдаваемых при отладке), то отношение «хотелось бы», имеет смысл заменить на «должно».

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

Стиль интерфейса ГРИФ более прост, чем у стандартных Windows приложений, но это было сделано специально, чтобы при запуске его на разных платформах, разница во внешнем виде была не существенна.

В ГРИФ встроен, специально для него написанный, текстовый редактор, что повысило эффективнось работы с системой. Теперь пользователь, получивший сообщение об ошибке, находящейся в его коде, не должен открывать имеющиеся в его распоряжении инструментальные средства разработки программ, а может редактировать исходный код сразу. Тем более это удобно тем, что в данный графический интерфейс встроены средства анализа ошибок. То есть, при выполнении какой-либо команды, приводящей к появлению ошибок, их список тут же предъявляется пользователю, и интерфейс предлагает простую и удобную навигацию по ним. При выборе пользователем любой ошибки из списка, ГРИФ демонстрирует место ее возникновения в исходном коде или трассировке. Естественно, исправить ее сразу же, и повторить операцию приведшею к ее возникновению, удобнее делать не переключаясь между разными не синхронизированными программами. В ГРИФ все это делать легко и удобно.

Интерфейс ГРИФ – многооконный. Это неочевидное требование DVM-системы, связвно с тем, что а процессе анализа ошибок желательно иметь перед галазами сразу несколько открытых файлов: с исходным кодом, трассировками и т.д.

ГРИФ содержит маленькое новшество – Лог-инспектор. Это небольшое окно, в котором последовательно отражается информация о каждом обращении к системе и ее реакциях. Такой Лог регистрирует события, и может быть сохранен. Он может быть очень полезен при возникновении ошибок, в поведении системы, играя роль журнала, записи которого, помогут воспроизвести точно такую же ситуацию еще раз.