на тему рефераты Информационно-образоательный портал
Рефераты, курсовые, дипломы, научные работы,
на тему рефераты
на тему рефераты
МЕНЮ|
на тему рефераты
поиск
Разработка графического интерфейса DVM-системы
b>DVM-система содержит инструмент, называемый Предиктором, для произведения оценки эффективности программ на последовательной машине. С помощью предиктора пользователь имеет возможность получить оценки временных характеристик выполнения его программы на MPP или кластере рабочих станций с различной степенью подробности.

Глава 2. Графический интерфейс

Что такое графический интерфейс

Любая программа взаимодействует с пользователем или другими программами. Она получает некие указания и данные на вход, обрабатывает их и выдает результат своей работы - выходные данные, или указания для других программ. За время существования вычислительной техники программные системы многократно усложнились. Пользователь может хотеть получить от системы данные в удобном для него формате : текст, звук, изображение. Та часть системы, которая является посредником в передаче данных от пользователя к самой программе, конвертируя эти данные из понятного человеку представления, в понятные системе и наоборот, называется интерфейсом. Интерфейс, в данном контексте, это часть программы, наиболее близкая к пользователю, и превращающая остальную программу в «черный ящик». Пользователь уже может не знать как устроена программная система, ему приходится общаться только с интерфейсом. А интерфейс, в свою очередь обращается к системе. При этом сам интерфейс не несет никакой функциональной нагрузки системы. Его цель - быть максимально удобным для пользователя, и общаться с ним на удобном ему языке.

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

При этом графический интерфейс выполняет сразу несколько функций:

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

· Может подсказывать пользователю, какие действия тот может произвести с системой в текущий момент времени.

· Может производить проверку вводимых пользователем данных, до передачи

· Может уметь предоставлять пользователю результаты работы программной системы в любом удобном для пользователя виде. То есть, может предоставлять пользователю инструменты анализа полученных от системы данных.

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

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

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

Требования к графическому интерфейсу

Графический интерфейс - это благо для пользователя, не так ли? Оказывается и он, призванный облегчить жизнь, способен причинять неудобства. И речь не только о том, что интерфейс может быть продуман человеком, который не был пользователем данной системы, и не знает как сделать его действительно «удобным». Речь о других возможных недостатках, которые могут обернуться серьезными проблемами.

Во-первых, это излишняя подробность и нарядность интерфейса. Для программы, в которой критично время ее выполнения, не всегда имеет смысл представлять результат ее работы сложными диаграммами, или другими элементами графического интерфейса, выведение на экран которых занимает много времени.

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

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

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

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

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

Требования к графическому интерфейсу DVM-системы

Исходя из обобщенных требований к графическим интерфейсам, рассмотрим уточненные требования к графическому интерфейсу DVM-системы.

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

· Графический интерфейс 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, 3


© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.