Разработка графического интерфейса DVM-системы (стр. 2 из 5)

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

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

Для построения модели использовалась среда RationalRose, и язык 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