Диаграмма 2
В модели описано наличие анализатора ошибок, однако, в связи с тем, что его функциональность, на данный момент до конца не определена, анализатор в модели описан в виде заглушки, принимающей от системы список ошибок, и общающийся с пользователем посредством команд «запросить информацию об ошибке», «выдать информацию об ошибке». При уточнении требований к анализатору, и при необходимости построить графический интерфейс его включающий, данная формальная модель подскажет где и как разместить обращения к нему. В модели же, анализатор представлен вариантом использования ErrorAnalize. Кроме того, модель унифицирует команды одного смысла, заданные для программ написанных на языке C-DVM и Fortran-DVM. Это сделано для того, чтобы значительно упростить построение интерфейса – при одинаковом «смысле» команды и заданных параметрах интерфейс способен сам построить правильное обращение к DVM-системе.
Теперь рассмотрим модель детально. Модель разбита на абстрактные классы. Каждому варианту использования соответствует один CONTROL (управляющий) класс, и два BOUNDARY (граничных) класса. BOUNDARY классы – это абстракции, принимающие входные данные у пользователя или передающие эти данные DVM-системе. Граничные классы модели, связывающие актора (пользователя) и управляющие классы, соответствуют графическим компонентам интерфейса, таким как ока, поля для ввода текста, кнопки, меню, переключатели выбора и т.д. Граничные классы взаимодействующие с CONTROL’ами и самой системой, являются описанием вызова нужной командной строки из интерфейса. Управляющие же классы принимают от граничных выбранные пользователем параметры и строят на их основе правильную dvm-команду, передавая затем ее «вторым» граничным классам. Такие же два граничных класса предусмотрены для анализатора ошибок. Независимо от конечной реализации интерфейса, построенной на основе этой модели, эти классы, и связанные с ними диаграммы взаимодействия (поясняющие как и в каком порядке происходит обработка событий в интерфейсе) и кооперативные диаграммы (раскрывающие связи компонентов интерфейса между собой), останутся базой для его построения, которое сведется к итеративному наращиванию модели. Примеры диаграмм взаимодействия и кооперативных диаграмм приведены в приложении.(диаграммы 3-16). Все эти диаграммы описывают абстрактную модель, которая может служить основой для любой реализации интерфейса для DVM-системы, обеспечивая выполнение пяти требований к интерфейсу. То есть, такая модель .делает доступными все точки входа в систему. Она предполагает проверку параметров команд, до их запуска на выполнение, она предлагает основу для построения инструмента, работающего с ошибками, и способна снизить суммарную стоимость владения системой из-за четкого разделения вариантов использования, то есть из-за стиля интерфейса, предлагающего подсказки при вводе параметров команд.
Глава 4. Графический интерфейс DVM-системы – ГРИФ
Как устроен ГРИФ
На основе модели графического интерфейса DVM-системы, я разработала интерфейс ГРИФ. (Его название – аббревиатура ГРафический ИнтерФейс.). Эта программа отвечает требованиям к интерфейсу, которые диктует DVM-система на сегодняшний день. Поскольку, не все требования учтенные в абстрактной модели, представляется возможным ваполнить на настоящей стадии развития DVM-системы, то некоторые из них не были выполнены. Это относится к требованиям: открыть в интерфейсе для пользователя все точки входа и проверять все вводимые пользователем значения параметров. И то и другое отклонения от модели обусловлено тем, что некоторые инструменты системы сейчас претерпевают значительные изменения. Улучшение этих инструментов затрагивает и возможности пользователя управлять ими, и как следствие, влияет на интерфейс. По этой причине, интерфейс, реализованный мною, не содержит компонентов, связанных с анализатором производительности и предиктором.
Однако, не смотря на то, что, реализованный мной интерфейс, снизил свои требования по сравнению с моделью, в нем оставлена возможность для будующих разработчиков, дополнить его, вставив необходимый код.
Интерфейс написан на языке программирования JAVA. В прошлом, мной был написан интерфейс отладчика DVM-системы в среде Delphi, на языке ObjectPascal, и этот опыт подсказал, что когда возникнет необходимость создавать интерфейс всей системы, его нужно будет создать платформо-независимым. Так как сама DVM-система может работать под операционными системами семейства Windows95/NT и Unix, то хотелось бы ожидать не меньшей преносимости и от интерфейса. А так как интерфейс может включать в себя и некоторые инструменты анализа (как то простейший анализ ошибок выдаваемых при отладке), то отношение «хотелось бы», имеет смысл заменить на «должно».
Интерфейс разрабатывался отдельно от самой системы, воспринимая ее как внешний набор команд. Это дает возможность дополнять интерфейс в связи с развитием системы, не изменяя его основы. При появлении новых функций в DVM-системе разработчикам будет достаточно вставить необходимые для передачи данных компоненты, и вписать несколько строчек кода в уже существующий, без риска повредить его целостность и нарушить работу. Кроме того, как уже говорилось, такое разделение интерфейса и системы, для которой он написан, оставляет «пространство» для проверки данных, получаемых от пользователя. То есть, в систему попадают только те данные, которые соответсвуют ее ограничениям. Неправильно заданный параметр, не повлияет на работу системы, поскольку просто в нее не попадет.
Стиль интерфейса ГРИФ более прост, чем у стандартных Windows приложений, но это было сделано специально, чтобы при запуске его на разных платформах, разница во внешнем виде была не существенна.
В ГРИФ встроен, специально для него написанный, текстовый редактор, что повысило эффективнось работы с системой. Теперь пользователь, получивший сообщение об ошибке, находящейся в его коде, не должен открывать имеющиеся в его распоряжении инструментальные средства разработки программ, а может редактировать исходный код сразу. Тем более это удобно тем, что в данный графический интерфейс встроены средства анализа ошибок. То есть, при выполнении какой-либо команды, приводящей к появлению ошибок, их список тут же предъявляется пользователю, и интерфейс предлагает простую и удобную навигацию по ним. При выборе пользователем любой ошибки из списка, ГРИФ демонстрирует место ее возникновения в исходном коде или трассировке. Естественно, исправить ее сразу же, и повторить операцию приведшею к ее возникновению, удобнее делать не переключаясь между разными не синхронизированными программами. В ГРИФ все это делать легко и удобно.
Интерфейс ГРИФ – многооконный. Это неочевидное требование DVM-системы, связвно с тем, что а процессе анализа ошибок желательно иметь перед галазами сразу несколько открытых файлов: с исходным кодом, трассировками и т.д.