Содержание
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Инструментальная система DVM для разработки параллельных программ
Глава 2. Графический интерфейс
Что такое графический интерфейс
Глава 3. Формальная модель графического интерфейса
Средства построения формальной модели графического интерфейса
Глава 4. Графический интерфейс DVM-системы – ГРИФ
Как устроен ГРИФ
Заключение
Приложение
Список литературы
Введение
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Последние три столетия преподносили человеку новые, немыслимые до того технологии, определяющие весь ход дальнейшего научно-технического прогресса. Появление в 18-м веке механических машин перевернуло человеческие представления о труде. Паровые машины, изобретенные в 19-м веке, открыли новые мощности. 20-й век был ознаменован появлением вычислительной техники. Это открыло для человека новые, гораздо более эффективные способы хранения, передачи и обработки информации. С появлением этих способов, стали возрастать и потребности. Развитие промышленных технологий ставило задачи построения сложных систем. Аналитическое проектирование стало все меньше подходить для этого. Компьютеры стали использоваться для моделирования процессов и систем. Потребность во все более высокой производительности вычислительных систем стала расти экспоненциально.
Существует несколько доступных путей увеличения производительности. Можно улучшить аппаратное обеспечение, используя более высокопроизводительный процессор, можно улучшать программное обеспечение. В первом случае сразу становится виден предел повышения производительности (на каждом этапе развития процессоростроения). Во втором – возникают те же проблемы. Хотя явно нельзя определить «верхний предел» эффективности алгоритма, но и изобретать алгоритмы – дело непредсказуемой сложности.
Но есть еще третий путь – параллельные вычисления. Многие алгоритмы хорошо масштабируемы, и потому выполнение их параллельно на нескольких вычислительных устройствах, даёт большой выигрыш в скорости выполнения. И именно этот третий путь, возможно является своеобразным толчком к появлению главного достижения 21-го века – внедрения вычислительных сетей. Однако, параллельные вычисления - только первая ступенька на этом пути. Еще не существует достаточного количества программных средств, позволяющих писать и, что не менее важно, отлаживать параллельные программы.
Вообще многопроцессорные системы классифицируются по признаку обмена данными между процессорами. Существуют две основные модели параллельного выполнения программ – модель передачи сообщений, и модель взаимодействия через общую память.
В первой модели программа представляет собой систему процессов, взаимодействующих с помощью передачи сообщений. Первая модель может быть использована на любых кластерах.
Во второй модели параллельная программа представляет собой систему нитей (thread), взаимодействующих посредством общих переменных и примитивов синхронизации. Нить – это легковесный процесс имеющий с другими процессами общие ресурсы, в том числе – общую оперативную память. Вторая модель может быть использована только на DSM-кластерах, то есть кластерах, на которых аппаратно или программно-аппаратно реализована распределенная общая память, позволяющая выполняющимся на разных узлах программам взаимодействовать через общие переменные.
Однако, обе эти модели в чистом виде были неудобны для разработчика. Они заставляют его иметь дело с параллельными процессами и низкоуровневыми примитивами передачи сообщений или синхронизации. Особенно большие трудности возникают при необходимости использования многоуровневого параллелизма (например, параллелизм между разными подзадачами и параллелизм внутри подзадач).
Кроме того, программист обычно вынужден иметь и сопровождать два варианта программы – последовательный и параллельный. В качестве примера можно привести несколько подходов различающихся моделями и языками параллельного программирования.
Модель передачи сообщений. MPI.
В этой модели параллельная программа представляет собой множество процессов, каждый из которых имеет собственное локальное адресное пространство. Взаимодействие процессов - обмен данными и синхронизация осуществляется посредством передачи сообщений. В 1993 году был разработан стандарт MPI. К числу приятных особенностей MPI относятся :
- возможность совмещения передачи сообщений и вычислений;
- широкий набор коллективных операций;
- возможность задания типа передаваемой информации;
- широкий набор редукционных операций;
К недостаткам относится то, что интерфейс слишком сложный и громоздкий.
Модель параллелизма по данным. HPF.
В этой модели нет понятия процесса как такового, и, следовательно, нет передачи сообщений и синхронизации. Программист указывает какие данные на какой процессор распределять, а компилятор сам распределяет вычисления таким образом, чтобы каждый узел работал со своими локальными данными. При этом достигается высокая локализация данных, а программа сохраняет удобный «последовательный» стиль.
Модель параллелизма по управлению. OpenMP.
Эта модель возникла в применении к мультипроцессорам. Вместо термина «нить» она использует специальные конструкции – параллельные циклы и секции. Создание и уничтожение нитей, распределения по ним витков циклов – все это делал сам компилятор.
Инструментальная система DVM для разработки параллельных программ
В 1993 году, в институте Прикладной Математики имени М.И.Келдыша РАН, разработана новая модель, объединяющая достоинства прочих. Это - модель DVM. Модель положена в основу языков С-DVM и Fortran-DVM, которые являются расширениями языков C и Fortran, соответственно. Это модель использует сразу два вида параллелизма : по данным и по управлению. Программист сам, под свою ответственность распределяет между процессорами блоки данных и вычисления. Также самостоятельно программист указывает общие блоки памяти, доступные одному процессу на запись, а остальным на чтение, определяет точки обновления таких общих блоков памяти и вручную распределяет между процессами витки циклов. Также модель имеет набор редукционных операций. Таким образом, вся ответственность за правильное распределение данных и вычислений лежит на самом программисте, но это, в то же самое время, дает ему огромную свободу при распределении задачи, делая DVM-модель гибкой.
Языки параллельного программирования C-DVM и Fortran-DVMпредставляют собой стандартные языки расширенные спецификациями параллелизма, причем, эти спецификации прозрачны для стандартных компиляторов. Это значительно упрощает понимание программ, их использование (в последовательном варианте программа может прогоняться на любой машине), и отладку.
Основная работа по реализации модели выполнения параллельной программы (например, распределение данных и вычислений) осуществляется динамически специальной системой - системой поддержки выполнения DVM-программ. Это позволяет обеспечить динамическую настройку DVM-программ при запуске (без перекомпиляции) на параметры приложения (количество и размер массивов данных) и конфигурацию параллельного компьютера (количество процессоров и их производительность). Тем самым программист получает возможность иметь один вариант программы для выполнения на последовательных ЭВМ и параллельных ЭВМ различной конфигурации. То есть, в DVM-модели работает принцип «Написано однажды – работает везде.»
Модель выполнения программы можно упрощенно описать следующим образом
· Параллельная программа на исходном языке Фортран-DVM (или Си-DVM) превращается в программу на языке Фортран 77 (или Си), содержащую вызовы функций системы поддержки, и выполняющуюся в соответствии с моделью SPMD (одна программа – много данных) на каждом выделенном задаче процессоре.
· В момент запуска программы существует единственная её ветвь (поток управления), которая начинает свое выполнение с первого оператора программы сразу на всех процессорах многопроцессорной системы.
· Многопроцессорной системой (или системой процессоров) называется та машина, которая предоставляется программе пользователя аппаратурой и базовым системным программным обеспечением. Число процессоров многопроцессорной системы и её представление в виде многомерной решетки задаётся в командной строке при запуске программы.
· Все объявленные в программе переменные (за исключением специально указанных "распределённых" массивов) размножаются по всем процессорам.
· При входе в параллельную конструкцию (параллельный цикл или область параллельных задач) ветвь разбивается на некоторое количество параллельных ветвей, каждая из которых выполняется на выделенном ей процессоре многопроцессорной системы.
· При выходе из параллельной конструкции все ветви сливаются в ту же самую ветвь, которая выполнялась до входа в параллельную конструкцию.
Разработанная таким образом DVM-система показала при тестировании следующий : эффективность DVM-программ гораздо выше, чем эффективность HPF, и вполне сравнима с эффективностью OpenMP и MPI.
DVM-система имеет свои средства отладки параллельных программ. Один из них – метод динамического контроля. Динамический контроль DVM-указаний позволяет проверить корректность распараллеливания программы посредством DVM-указаний, и основан на моделировании параллельного выполнения DVM-программы во время ее последовательного выполнения на одном процессоре Однако использование данного метода существенно замедляет выполнение программы и требует больших объемов дополнительной памяти. Поэтому, его следует применять только для программы со специально подобранными тестовыми данными.
Второй способ отладки – метод сравнения трассировок, который позволяет определить место в программе и момент, когда появляются расхождения в результатах вычислений. При трассировке вычислений выполняется сбор информации обо всех чтениях и модификациях переменных, о начале выполнения каждого витка цикла, о начале и конце выполнения параллельного цикла, о начале выполнения каждой параллельной задачи, о начале и конце выполнения группы задач. Трассировка вычислений, как и динамический контроль, требовательна к ресурсам вычислительной системы. Поэтому рекомендуется сначала трассировать программы с тестовыми данными, а затем уже переходить к реальным данным.
DVM-система, также имеет средства отладки производительности программ. Система поддержки выполнения DVM-программ во время выполнения программы на многопроцессорной ЭВМ (или однородной сети ЭВМ) накапливает информацию с временными характеристиками в оперативной памяти процессоров, а при завершении выполнения программы записывает эту информацию в файл, который затем обрабатывается на рабочих станциях в среде Windows 95/NT или UNIX специальным инструментом - визуализатором производительности. С помощью визуализатора производительности пользователь имеет возможность получить временные характеристики выполнения его программы с различной степенью подробности.
DVM-система содержит инструмент, называемый Предиктором, для произведения оценки эффективности программ на последовательной машине. С помощью предиктора пользователь имеет возможность получить оценки временных характеристик выполнения его программы на MPP или кластере рабочих станций с различной степенью подробности.
Глава 2. Графический интерфейс
Что такое графический интерфейс
Любая программа взаимодействует с пользователем или другими программами. Она получает некие указания и данные на вход, обрабатывает их и выдает результат своей работы – выходные данные, или указания для других программ. За время существования вычислительной техники программные системы многократно усложнились. Пользователь может хотеть получить от системы данные в удобном для него формате : текст, звук, изображение. Та часть системы, которая является посредником в передаче данных от пользователя к самой программе, конвертируя эти данные из понятного человеку представления, в понятные системе и наоборот, называется интерфейсом. Интерфейс, в данном контексте, это часть программы, наиболее близкая к пользователю, и превращающая остальную программу в «черный ящик». Пользователь уже может не знать как устроена программная система, ему приходится общаться только с интерфейсом. А интерфейс, в свою очередь обращается к системе. При этом сам интерфейс не несет никакой функциональной нагрузки системы. Его цель – быть максимально удобным для пользователя, и общаться с ним на удобном ему языке.
Графический интерфейс системы включает в себя все необходимые для работы с этой системой графические компоненты. В многооконных операционных системах это: окна, кнопки, меню, поля для ввода текста и т.д. Интерфейс должен уметь принимать от пользователя и передавать программе любые данные, передача которых между ними допускается этой программой.
При этом графический интерфейс выполняет сразу несколько функций:
· Он облегчает пользователю работу с программой, связывая функции программной системы с визуальными компонентами.
· Может подсказывать пользователю, какие действия тот может произвести с системой в текущий момент времени.
· Может производить проверку вводимых пользователем данных, до передачи
· Может уметь предоставлять пользователю результаты работы программной системы в любом удобном для пользователя виде. То есть, может предоставлять пользователю инструменты анализа полученных от системы данных.
· Может связывать между собой несколько разных программ. В том числе и операционную систему.
Построение интерфейса – это задача с которой рано или поздно сталкиваются разработчики любого программного обеспечения.. И удачно сделанный интерфейс, зачастую, не менее важный фактор в успешности программного продукта, чем его функциональность. В свою очередь, разработка интерфейса предъявляет свои требования программной системе. Например требования максимально формализованного обмена данными между пользователем и системой.
Таким образом – построение интерфейса это важная и нелегкая задача. Превращая систему в «черный ящик», неудачно спроектированный интерфейс способен «похоронить» в этом ящике некоторые возможности, особенности или свойства системы. Вообще, интерфейс должен повышать эффективность работы программы и понижать суммарную стоимость владения программой, снижением стоимости подготовки пользователя программы.
Требования к графическому интерфейсу
Графический интерфейс – это благо для пользователя, не так ли? Оказывается и он, призванный облегчить жизнь, способен причинять неудобства. И речь не только о том, что интерфейс может быть продуман человеком, который не был пользователем данной системы, и не знает как сделать его действительно «удобным». Речь о других возможных недостатках, которые могут обернуться серьезными проблемами.
Во-первых, это излишняя подробность и нарядность интерфейса. Для программы, в которой критично время ее выполнения, не всегда имеет смысл представлять результат ее работы сложными диаграммами, или другими элементами графического интерфейса, выведение на экран которых занимает много времени.
Во-вторых, это системные требования. Увеличение системных требований, вызванное внедрением графического интерфейса, не должно приводить к повышению общих системных требований выше разумного уровня.
В-третьих, интерфейс не должен скрывать точки входа в систему, если это не вызвано соображениями администрирования и безопасного функционирования системы.
В-четвертых, интерфейс должен быть реализован для всех операционных систем и архитектур, которые поддерживаются программной системой.
В-пятых, интерфейс должен перехватывать все исключительные ситуации, связанные с неправильным вводом данных, и обрабатывать их, сообщая об этом пользователю, и не прерывая работу программной системы.
В-шестых, интерфейс к программе все еще находящейся в стадии разработки, должен иметь внутреннюю структуру, облегчающую его модернизацию, и должен иметь соответствующее описание. На основе вышесказанного, можно сформулировать общие требования к интерфейсу DVM-системы.
Требования к графическому интерфейсу DVM-системы
Исходя из обобщенных требований к графическим интерфейсам, рассмотрим уточненные требования к графическому интерфейсу DVM-системы.
Графический интерфейс должен удовлетворять следующему:
· Графический интерфейс DVM-системы должен открывать все возможные точки входа в DVM-систему. Исключение составляет администрирование системы из соображений безопасности.
· Графический интерфейс DVM-системы должен осуществлять проверку всех значений, подаваемых пользователем на точки входа. В ряде случаев, интерфейс не должен допускать ввода таких значений, посредством блокировки соответствующих графических компонентов. Иначе, при несоответствии ожидаемому значению, графический интерфейс DVM-системы должен, перехватывать исключительные ситуации системы и, извещая об этом пользователя, позволять ему поменять входные данные.
· Графический интерфейс DVM-системы должен позволять повышать эффективность работы с системой, путем предоставления пользователю специальных инструментов, по поиску необходимой информации.(Анализ ошибок, использование диалоговых окон для работы с файлами и т.д.)
· Графический интерфейс DVM-системы должен предоставлять пользователю текстовый редактор, дающий возможность вносить изменения в исходный код, не переключаясь на другие приложения.
· Графический интерфейс DVM-системы должен работать под операционными системами Unix и Win95/NT.
· Графический интерфейс DVM-системы должен быль написан с учетом того, что DVM-система постоянно обновляется. Его исходный код должен быть спроектирован с учетом возможных изменений, и должен содержать все необходимые комментарии.
· Графический интерфейс DVM-системы должен корректно работать с сообщениями об ошибках выполнения команд DVM-системы, и при возникновении таких ошибок, выводить всю информацию на экран.
· Графический интерфейс DVM-системы должен хранить в доступном пользователю виде, информацию о
Введение
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Инструментальная система DVM для разработки параллельных программ
Глава 2. Графический интерфейс
Что такое графический интерфейс
Требования к графическому интерфейсу
Требования к графическому интерфейсу DVM-системы
Модель графического интерфейса
Глава 3. Формальная модель графического интерфейса
Средства построения формальной модели графического интерфейса
Формальная модель графического интерфейса
Глава 4. Графический интерфейс DVM-системы – ГРИФ
Как устроен ГРИФ
Детальное описание графического интерфейса ГРИФ
Заключение
Приложение
Список литературы
Введение
Данная работа посвящена проблемам разработки графического интерфейса для DVM-системы. Задача построения такого интерфейса еще по существу пока не ставилась, поскольку система активно развивалась, и ее интерфейсы заметно менялись. Система базируется на новой языковой модели, в ней реализованы новые методы функциональной отладки программ и отладки эффективности. Практическое использование системы для разработки сложных параллельных программ неизбежно вносило и вносит коррективы в ее алгоритмы и интерфейсы. В настоящее время отсутствие графического интерфейса становится заметным недостатком системы. Однако построение графического интерфейса для сложной программной системы, которая находится в стадии развития, является сложной задачей, решение которой можно существенно упростить путем проектирования обобщенной, формальной модели графического интерфейса DVM-системы. Такая абстрактная модель, позволит оценивать разрабатываемые варианты интерфейса с точки зрения соответствия модели, и проектировать оптимальные интерфейсы. Данная работа предлагает новый инструмент, предназначенный для формализации проектирования новых интерфейсов. В ее рамках был разработан новый интерфейс на языке Java, и проведена его оценка в сравнении с построенной формальной моделью.
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Последние три столетия преподносили человеку новые, немыслимые до того технологии, определяющие весь ход дальнейшего научно-технического прогресса. Появление в 18-м веке механических машин перевернуло человеческие представления о труде. Паровые машины, изобретенные в 19-м веке, открыли новые мощности. 20-й век был ознаменован появлением вычислительной техники. Это открыло для человека новые, гораздо более эффективные способы хранения, передачи и обработки информации. С появлением этих способов, стали возрастать и потребности. Развитие промышленных технологий ставило задачи построения сложных систем. Аналитическое проектирование стало все меньше подходить для этого. Компьютеры стали использоваться для моделирования процессов и систем. Потребность во все более высокой производительности вычислительных систем стала расти экспоненциально.
Существует несколько доступных путей увеличения производительности. Можно улучшить аппаратное обеспечение, используя более высокопроизводительный процессор, можно улучшать программное обеспечение. В первом случае сразу становится виден предел повышения производительности (на каждом этапе развития процессоростроения). Во втором – возникают те же проблемы. Хотя явно нельзя определить «верхний предел» эффективности алгоритма, но и изобретать алгоритмы – дело непредсказуемой сложности.
Но есть еще третий путь – параллельные вычисления. Многие алгоритмы хорошо масштабируемы, и потому выполнение их параллельно на нескольких вычислительных устройствах, даёт большой выигрыш в скорости выполнения. И именно этот третий путь, возможно является своеобразным толчком к появлению главного достижения 21-го века – внедрения вычислительных сетей. Однако, параллельные вычисления - только первая ступенька на этом пути. Еще не существует достаточного количества программных средств, позволяющих писать и, что не менее важно, отлаживать параллельные программы.
Вообще многопроцессорные системы классифицируются по признаку обмена данными между процессорами. Существуют две основные модели параллельного выполнения программ – модель передачи сообщений, и модель взаимодействия через общую память.
В первой модели программа представляет собой систему процессов, взаимодействующих с помощью передачи сообщений. Первая модель может быть использована на любых кластерах.
Во второй модели параллельная программа представляет собой систему нитей (thread), взаимодействующих посредством общих переменных и примитивов синхронизации. Нить – это легковесный процесс имеющий с другими процессами общие ресурсы, в том числе – общую оперативную память. Вторая модель может быть использована только на DSM-кластерах, то есть кластерах, на которых аппаратно или программно-аппаратно реализована распределенная общая память, позволяющая выполняющимся на разных узлах программам взаимодействовать через общие переменные.
Однако, обе эти модели в чистом виде были неудобны для разработчика. Они заставляют его иметь дело с параллельными процессами и низкоуровневыми примитивами передачи сообщений или синхронизации. Особенно большие трудности возникают при необходимости использования многоуровневого параллелизма (например, параллелизм между разными подзадачами и параллелизм внутри подзадач).
Кроме того, программист обычно вынужден иметь и сопровождать два варианта программы – последовательный и параллельный. В качестве примера можно привести несколько подходов различающихся моделями и языками параллельного программирования.
Модель передачи сообщений. MPI.
В этой модели параллельная программа представляет собой множество процессов, каждый из которых имеет собственное локальное адресное пространство. Взаимодействие процессов - обмен данными и синхронизация осуществляется посредством передачи сообщений. В 1993 году был разработан стандарт MPI. К числу приятных особенностей MPI относятся :
- возможность совмещения передачи сообщений и вычислений;
- широкий набор коллективных операций;
- возможность задания типа передаваемой информации;
- широкий набор редукционных операций;
К недостаткам относится то, что интерфейс слишком сложный и громоздкий.
Модель параллелизма по данным. HPF.
В этой модели нет понятия процесса как такового, и, следовательно, нет передачи сообщений и синхронизации. Программист указывает какие данные на какой процессор распределять, а компилятор сам распределяет вычисления таким образом, чтобы каждый узел работал со своими локальными данными. При этом достигается высокая локализация данных, а программа сохраняет удобный «последовательный» стиль.
Модель параллелизма по управлению. OpenMP.
Эта модель возникла в применении к мультипроцессорам. Вместо термина «нить» она использует специальные конструкции – параллельные циклы и секции. Создание и уничтожение нитей, распределения по ним витков циклов – все это делал сам компилятор.
Инструментальная система DVM для разработки параллельных программ
В 1993 году, в институте Прикладной Математики имени М.И.Келдыша РАН, разработана новая модель, объединяющая достоинства прочих. Это - модель DVM. Модель положена в основу языков С-DVM и Fortran-DVM, которые являются расширениями языков C и Fortran, соответственно. Это модель использует сразу два вида параллелизма : по данным и по управлению. Программист сам, под свою ответственность распределяет между процессорами блоки данных и вычисления. Также самостоятельно программист указывает общие блоки памяти, доступные одному процессу на запись, а остальным на чтение, определяет точки обновления таких общих блоков памяти и вручную распределяет между процессами витки циклов. Также модель имеет набор редукционных операций. Таким образом, вся ответственность за правильное распределение данных и вычислений лежит на самом программисте, но это, в то же самое время, дает ему огромную свободу при распределении задачи, делая DVM-модель гибкой.
Языки параллельного программирования C-DVM и Fortran-DVMпредставляют собой стандартные языки расширенные спецификациями параллелизма, причем, эти спецификации прозрачны для стандартных компиляторов. Это значительно упрощает понимание программ, их использование (в последовательном варианте программа может прогоняться на любой машине), и отладку.
Основная работа по реализации модели выполнения параллельной программы (например, распределение данных и вычислений) осуществляется динамически специальной системой - системой поддержки выполнения DVM-программ. Это позволяет обеспечить динамическую настройку DVM-программ при запуске (без перекомпиляции) на параметры приложения (количество и размер массивов данных) и конфигурацию параллельного компьютера (количество процессоров и их производительность). Тем самым программист получает возможность иметь один вариант программы для выполнения на последовательных ЭВМ и параллельных ЭВМ различной конфигурации. То есть, в DVM-модели работает принцип «Написано однажды – работает везде.»
Модель выполнения программы можно упрощенно описать следующим образом
· Параллельная программа на исходном языке Фортран-DVM (или Си-DVM) превращается в программу на языке Фортран 77 (или Си), содержащую вызовы функций системы поддержки, и выполняющуюся в соответствии с моделью SPMD (одна программа – много данных) на каждом выделенном задаче процессоре.
· В момент запуска программы существует единственная её ветвь (поток управления), которая начинает свое выполнение с первого оператора программы сразу на всех процессорах многопроцессорной системы.
· Многопроцессорной системой (или системой процессоров) называется та машина, которая предоставляется программе пользователя аппаратурой и базовым системным программным обеспечением. Число процессоров многопроцессорной системы и её представление в виде многомерной решетки задаётся в командной строке при запуске программы.
· Все объявленные в программе переменные (за исключением специально указанных "распределённых" массивов) размножаются по всем процессорам.
· При входе в параллельную конструкцию (параллельный цикл или область параллельных задач) ветвь разбивается на некоторое количество параллельных ветвей, каждая из которых выполняется на выделенном ей процессоре многопроцессорной системы.
· При выходе из параллельной конструкции все ветви сливаются в ту же самую ветвь, которая выполнялась до входа в параллельную конструкцию.
Разработанная таким образом DVM-система показала при тестировании следующий : эффективность DVM-программ гораздо выше, чем эффективность HPF, и вполне сравнима с эффективностью OpenMP и MPI.
DVM-система имеет свои средства отладки параллельных программ. Один из них – метод динамического контроля. Динамический контроль DVM-указаний позволяет проверить корректность распараллеливания программы посредством DVM-указаний, и основан на моделировании параллельного выполнения DVM-программы во время ее последовательного выполнения на одном процессоре Однако использование данного метода существенно замедляет выполнение программы и требует больших объемов дополнительной памяти. Поэтому, его следует применять только для программы со специально подобранными тестовыми данными.
Второй способ отладки – метод сравнения трассировок, который позволяет определить место в программе и момент, когда появляются расхождения в результатах вычислений. При трассировке вычислений выполняется сбор информации обо всех чтениях и модификациях переменных, о начале выполнения каждого витка цикла, о начале и конце выполнения параллельного цикла, о начале выполнения каждой параллельной задачи, о начале и конце выполнения группы задач. Трассировка вычислений, как и динамический контроль, требовательна к ресурсам вычислительной системы. Поэтому рекомендуется сначала трассировать программы с тестовыми данными, а затем уже переходить к реальным данным.
DVM-система, также имеет средства отладки производительности программ. Система поддержки выполнения DVM-программ во время выполнения программы на многопроцессорной ЭВМ (или однородной сети ЭВМ) накапливает информацию с временными характеристиками в оперативной памяти процессоров, а при завершении выполнения программы записывает эту информацию в файл, который затем обрабатывается на рабочих станциях в среде Windows 95/NT или UNIX специальным инструментом - визуализатором производительности. С помощью визуализатора производительности пользователь имеет возможность получить временные характеристики выполнения его программы с различной степенью подробности.
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-системой, эта реализация, с использованием модели, может быть легко модифицирована и приведена к окончательному виду.
Средства построения формальной модели графического интерфейса
Немаловажная вещь в программировании, недооцениваемая многими – это технология программирования. Без использования соответствующих технологий, разработка программного обеспечения оказывается на уровне экстремального программирования. Для разработки формальной модели графического интерфейса, я использовала технологию RUP (RationalUnifiedProcess). Эта технология использует принципы итеративного наращиваемого подхода к созданию программного обеспечения и планирования управления проектом на основе вариантов использования.
Для построения модели использовалась среда RationalRose, и язык UML. Разработка модели велась на основе формального описания DVM-системы и перечня требований к графическому интерфейсу DVM-системы.
С помощью технологии RUP, для формальной модели графического интерфейса были построены все необходимые диаграммы и приведены соответствующие описания. В процессе разработки формальной модели были соблюдены требования стандарта ISO 12207. При возобновлении разработки графического интерфейса DVM-системы, сравнение с формальной моделью позволит оценить соответствие интерфейса всем требованиям.
Формальная модель графического интерфейса
Модель графического интерфейса строилась на основе «Руководство пользователя системой 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, который предлагает пользователю ввести необходимые данные, для того, чтобы произвести отладку методом сравнения трассировок за один шаг. (То есть, интерфейс, накопив данные параметров требующихся команд, по выбору этого варианта использования последовательно передает системе указания генерировать последовательный и параллельный варианты программы и эталонную трассировку, произвести сравнение трассировок, и в случае нахождения ошибок сравнения, сгенерировать параллельные трассировки, для дальнейшего анализа ошибок.) Это объединение команд необязательно для интерфейса, но, так как оно допустимо, и может быть желательным, имеет смысл включить его в модель, не исключая, впрочем вариантов, основанных на отдельном использовании этих команд.
Диаграмма 2
В модели описано наличие анализатора ошибок, однако, в связи с тем, что его функциональность, на данный момент до конца не определена, анализатор в модели описан в виде заглушки, принимающей от системы список ошибок, и общающийся с пользователем посредством команд «запросить информацию об ошибке», «выдать информацию об ошибке». При уточнении требований к анализатору, и при необходимости построить графический интерфейс его включающий, данная формальная модель подскажет где и как разместить обращения к нему. В модели же, анализатор представлен вариантом использования ErrorAnalize. Кроме того, модель унифицирует команды одного смысла, заданные для программ написанных на языке C-DVM и Fortran-DVM. Это сделано для того, чтобы значительно упростить построение интерфейса – при одинаковом «смысле» команды и заданных параметрах интерфейс способен сам построить правильное обращение к DVM-системе.
Теперь рассмотрим модель детально. Модель разбита на абстрактные классы. Каждому варианту использования соответствует один CONTROL (управляющий) класс, и два BOUNDARY (граничных) класса. BOUNDARY классы – это абстракции, принимающие входные данные у пользователя или передающие эти данные DVM-системе. Граничные классы модели, связывающие актора (пользователя) и управляющие классы, соответствуют графическим компонентам интерфейса, таким как ока, поля для ввода текста, кнопки, меню, переключатели выбора и т.д. Граничные классы взаимодействующие с CONTROL’ами и самой системой, являются описанием вызова нужной командной строки из интерфейса. Управляющие же классы принимают от граничных выбранные пользователем параметры и строят на их основе правильную dvm-команду, передавая затем ее «вторым» граничным классам. Такие же два граничных класса предусмотрены для анализатора ошибок. Независимо от конечной реализации интерфейса, построенной на основе этой модели, эти классы, и связанные с ними диаграммы взаимодействия (поясняющие как и в каком порядке происходит обработка событий в интерфейсе) и кооперативные диаграммы (раскрывающие связи компонентов интерфейса между собой), останутся базой для его построения, которое сведется к итеративному наращиванию модели. Примеры диаграмм взаимодействия и кооперативных диаграмм приведены в приложении.(диаграммы 3-16). Все эти диаграммы описывают абстрактную модель, которая может служить основой для любой реализации интерфейса для DVM-системы, обеспечивая выполнение пяти требований к интерфейсу. То есть, такая модель .делает доступными все точки входа в систему. Она предполагает проверку параметров команд, до их запуска на выполнение, она предлагает основу для построения инструмента, работающего с ошибками, и способна снизить суммарную стоимость владения системой из-за четкого разделения вариантов использования, то есть из-за стиля интерфейса, предлагающего подсказки при вводе параметров команд.
Как устроен ГРИФ
На основе модели графического интерфейса DVM-системы, я разработала интерфейс ГРИФ. (Его название – аббревиатура ГРафический ИнтерФейс.). Эта программа отвечает требованиям к интерфейсу, которые диктует DVM-система на сегодняшний день. Поскольку, не все требования учтенные в абстрактной модели, представляется возможным ваполнить на настоящей стадии развития DVM-системы, то некоторые из них не были выполнены. Это относится к требованиям: открыть в интерфейсе для пользователя все точки входа и проверять все вводимые пользователем значения параметров. И то и другое отклонения от модели обусловлено тем, что некоторые инструменты системы сейчас претерпевают значительные изменения. Улучшение этих инструментов затрагивает и возможности пользователя управлять ими, и как следствие, влияет на интерфейс. По этой причине, интерфейс, реализованный мною, не содержит компонентов, связанных с анализатором производительности и предиктором.
Однако, не смотря на то, что, реализованный мной интерфейс, снизил свои требования по сравнению с моделью, в нем оставлена возможность для будующих разработчиков, дополнить его, вставив необходимый код.
Интерфейс написан на языке программирования JAVA. В прошлом, мной был написан интерфейс отладчика DVM-системы в среде Delphi, на языке ObjectPascal, и этот опыт подсказал, что когда возникнет необходимость создавать интерфейс всей системы, его нужно будет создать платформо-независимым. Так как сама DVM-система может работать под операционными системами семейства Windows95/NT и Unix, то хотелось бы ожидать не меньшей преносимости и от интерфейса. А так как интерфейс может включать в себя и некоторые инструменты анализа (как то простейший анализ ошибок выдаваемых при отладке), то отношение «хотелось бы», имеет смысл заменить на «должно».
Интерфейс разрабатывался отдельно от самой системы, воспринимая ее как внешний набор команд. Это дает возможность дополнять интерфейс в связи с развитием системы, не изменяя его основы. При появлении новых функций в DVM-системе разработчикам будет достаточно вставить необходимые для передачи данных компоненты, и вписать несколько строчек кода в уже существующий, без риска повредить его целостность и нарушить работу. Кроме того, как уже говорилось, такое разделение интерфейса и системы, для которой он написан, оставляет «пространство» для проверки данных, получаемых от пользователя. То есть, в систему попадают только те данные, которые соответсвуют ее ограничениям. Неправильно заданный параметр, не повлияет на работу системы, поскольку просто в нее не попадет.
Стиль интерфейса ГРИФ более прост, чем у стандартных Windows приложений, но это было сделано специально, чтобы при запуске его на разных платформах, разница во внешнем виде была не существенна.
В ГРИФ встроен, специально для него написанный, текстовый редактор, что повысило эффективнось работы с системой. Теперь пользователь, получивший сообщение об ошибке, находящейся в его коде, не должен открывать имеющиеся в его распоряжении инструментальные средства разработки программ, а может редактировать исходный код сразу. Тем более это удобно тем, что в данный графический интерфейс встроены средства анализа ошибок. То есть, при выполнении какой-либо команды, приводящей к появлению ошибок, их список тут же предъявляется пользователю, и интерфейс предлагает простую и удобную навигацию по ним. При выборе пользователем любой ошибки из списка, ГРИФ демонстрирует место ее возникновения в исходном коде или трассировке. Естественно, исправить ее сразу же, и повторить операцию приведшею к ее возникновению, удобнее делать не переключаясь между разными не синхронизированными программами. В ГРИФ все это делать легко и удобно.
Таково общее описание этого интерфейса. Ниже приведено детальное.
Детальное описание графического интерфейса ГРИФ
Графический интерфейс ГРИФ, состоит из 13 файлов с исходным кодом, написанных на языке JAVA и содержащих 52 класса.Всего код ГРИФ’а занимает порядка 5000 строк, что вызвано, в основном, сногочисленными проверками параметров на соответствие. В откомпилированном виде интерфейс мал (200K).
При первом запуске на машине, ГРИФ запрашивает у пользователя информацию местоположении DVM-системы в памяти. Пользователь указывает путь в стандартном диалоговом окне выбора файла, и система хранит его в создаваемом специально для этого фойле – «info.inf». При дальнейших вызовах интерфейса, он будет знать путь команд DVM.
· Интерфейс не позволяет пользователю ввести противоречивые параметры, храня информацию о их возможных сочетаниях.
· Пользователь введет параметры.
Таким образом, GRIFрасширил возможности самого понятия – интерфейс, и привнес немного новой функциональности в систему.
Заключение
В рамках этой дипломной работы была построена формальная модель графического интерфейса DVM-системы. Это модель несет в себе свойства обеспечивающие соблюдение основных требований к интерфейсу DVM-системы. Разработка временных интерфейсов удовлетворяющих данной модели, позволит создавать удобные, эффективные и легко-изменяемые оболочки.
На основе данной модели был построен графический интерфейс к DVM-системе, удовлетворяющий всем требованиям, стоящим перед ним на нынешнем этапе развития системы. Этот интерфейс позволяет повысить эффективность работы с DVM-системой, и снизить ее суммарную стоимость владения.
В дальнейшем, при появлении необходимости совершенствовать интерфейс, разработчики могут дополнить существующий, руководствуясь формальной моделью, гарантирующей соблюдение всех требований.
Приложение
Диаграммы 3 - 4: диаграмма взаимодействия и кооперативная диаграмма для варианта использования FullDebug
Список литератур
ы
Модель графического интерфейса
Как стало видно, известен ряд свойств, которым должен удовлетворять графический интерфейс DVM-системы. Однако, сам интерфейс удовлетворяющий всем этим требованиям еще не построен. В настоящее время продолжается развитие и совершенствования DVM-системы, расширяется круг её возможностей. Это обстоятельство не позволяет создать окончательную версию графического интерфейса. Для облегчения этой работы в будущем создана модель, формально описывающая оптимальный интерфейс DVM-системы. Мной создана наиболее точная на сегодняшний день реализация этой модели. Когда будет завершена работа над DVM-системой, эта реализация, с использованием модели, может быть легко модифицирована и приведена к окончательному виду.
Глава 3. Формальная модель графического интерфейса
Средства построения формальной модели графического интерфейса
Немаловажная вещь в программировании, недооцениваемая многими – это технология программирования. Без использования соответствующих технологий, разработка программного обеспечения оказывается на уровне экстремального программирования. Для разработки формальной модели графического интерфейса, я использовала технологию RUP (RationalUnifiedProcess). Эта технология использует принципы итеративного наращиваемого подхода к созданию программного обеспечения и планирования управления проектом на основе вариантов использования.
Для построения модели использовалась среда RationalRose, и язык UML. Разработка модели велась на основе формального описания DVM-системы и перечня требований к графическому интерфейсу DVM-системы.
С помощью технологии RUP, для формальной модели графического интерфейса были построены все необходимые диаграммы и приведены соответствующие описания. В процессе разработки формальной модели были соблюдены требования стандарта ISO 12207. При возобновлении разработки графического интерфейса DVM-системы, сравнение с формальной моделью позволит оценить соответствие интерфейса всем требованиям.
Формальная модель графического интерфейса
Модель графического интерфейса строилась на основе «Руководство пользователя системой 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-системы, обеспечивая выполнение пяти требований к интерфейсу. То есть, такая модель .делает доступными все точки входа в систему. Она предполагает проверку параметров команд, до их запуска на выполнение, она предлагает основу для построения инструмента, работающего с ошибками, и способна снизить суммарную стоимость владения системой из-за четкого разделения вариантов использования, то есть из-за стиля интерфейса, предлагающего подсказки при вводе параметров команд.
Глава 4. Графический интерфейс DVM-системы – ГРИФ
Как устроен ГРИФ
На основе модели графического интерфейса DVM-системы, я разработала интерфейс ГРИФ. (Его название – аббревиатура ГРафический ИнтерФейс.). Эта программа отвечает требованиям к интерфейсу, которые диктует DVM-система на сегодняшний день. Поскольку, не все требования учтенные в абстрактной модели, представляется возможным ваполнить на настоящей стадии развития DVM-системы, то некоторые из них не были выполнены. Это относится к требованиям: открыть в интерфейсе для пользователя все точки входа и проверять все вводимые пользователем значения параметров. И то и другое отклонения от модели обусловлено тем, что некоторые инструменты системы сейчас претерпевают значительные изменения. Улучшение этих инструментов затрагивает и возможности пользователя управлять ими, и как следствие, влияет на интерфейс. По этой причине, интерфейс, реализованный мною, не содержит компонентов, связанных с анализатором производительности и предиктором.
Однако, не смотря на то, что, реализованный мной интерфейс, снизил свои требования по сравнению с моделью, в нем оставлена возможность для будующих разработчиков, дополнить его, вставив необходимый код.
Интерфейс написан на языке программирования JAVA. В прошлом, мной был написан интерфейс отладчика DVM-системы в среде Delphi, на языке ObjectPascal, и этот опыт подсказал, что когда возникнет необходимость создавать интерфейс всей системы, его нужно будет создать платформо-независимым. Так как сама DVM-система может работать под операционными системами семейства Windows95/NT и Unix, то хотелось бы ожидать не меньшей преносимости и от интерфейса. А так как интерфейс может включать в себя и некоторые инструменты анализа (как то простейший анализ ошибок выдаваемых при отладке), то отношение «хотелось бы», имеет смысл заменить на «должно».
Интерфейс разрабатывался отдельно от самой системы, воспринимая ее как внешний набор команд. Это дает возможность дополнять интерфейс в связи с развитием системы, не изменяя его основы. При появлении новых функций в DVM-системе разработчикам будет достаточно вставить необходимые для передачи данных компоненты, и вписать несколько строчек кода в уже существующий, без риска повредить его целостность и нарушить работу. Кроме того, как уже говорилось, такое разделение интерфейса и системы, для которой он написан, оставляет «пространство» для проверки данных, получаемых от пользователя. То есть, в систему попадают только те данные, которые соответсвуют ее ограничениям. Неправильно заданный параметр, не повлияет на работу системы, поскольку просто в нее не попадет.
Стиль интерфейса ГРИФ более прост, чем у стандартных Windows приложений, но это было сделано специально, чтобы при запуске его на разных платформах, разница во внешнем виде была не существенна.
В ГРИФ встроен, специально для него написанный, текстовый редактор, что повысило эффективнось работы с системой. Теперь пользователь, получивший сообщение об ошибке, находящейся в его коде, не должен открывать имеющиеся в его распоряжении инструментальные средства разработки программ, а может редактировать исходный код сразу. Тем более это удобно тем, что в данный графический интерфейс встроены средства анализа ошибок. То есть, при выполнении какой-либо команды, приводящей к появлению ошибок, их список тут же предъявляется пользователю, и интерфейс предлагает простую и удобную навигацию по ним. При выборе пользователем любой ошибки из списка, ГРИФ демонстрирует место ее возникновения в исходном коде или трассировке. Естественно, исправить ее сразу же, и повторить операцию приведшею к ее возникновению, удобнее делать не переключаясь между разными не синхронизированными программами. В ГРИФ все это делать легко и удобно.
Интерфейс ГРИФ – многооконный. Это неочевидное требование DVM-системы, связвно с тем, что а процессе анализа ошибок желательно иметь перед галазами сразу несколько открытых файлов: с исходным кодом, трассировками и т.д.
ГРИФ содержит маленькое новшество – Лог-инспектор. Это небольшое окно, в котором последовательно отражается информация о каждом обращении к системе и ее реакциях. Такой Лог регистрирует события, и может быть сохранен. Он может быть очень полезен при возникновении ошибок, в поведении системы, играя роль журнала, записи которого, помогут воспроизвести точно такую же ситуацию еще раз.
Таково общее описание этого интерфейса. Ниже приведено детальное.
Детальное описание графического интерфейса ГРИФ
Графический интерфейс ГРИФ, состоит из 13 файлов с исходным кодом, написанных на языке JAVA и содержащих 52 класса.Всего код ГРИФ’а занимает порядка 5000 строк, что вызвано, в основном, сногочисленными проверками параметров на соответствие. В откомпилированном виде интерфейс мал (200K).
При первом запуске на машине, ГРИФ запрашивает у пользователя информацию местоположении DVM-системы в памяти. Пользователь указывает путь в стандартном диалоговом окне выбора файла, и система хранит его в создаваемом специально для этого фойле – «info.inf». При дальнейших вызовах интерфейса, он будет знать путь команд DVM.
В начеле работы, интерфейс представлен одним маленьким окном в верхней левой части экрана, которое содержит стандартное меню. Пункты это меню :
· Files – набор команд для открытия существующих или создания новых исходных кодов программ и логов;
· Compile – вызов компилятора.
· Debug – общий пункт меню для разных команд отладки.
· Manuals – пункт позволяющий выбрать и открыть руководства по DVM-системе
· Exit.
Также при начале работы открывается пустое окно Лог-инспектора и пустое окно для вывода списка ошибок.
Вызов компилятора работает следующим образом:
· Система предлагает пользователю выбрать файл с расширением cdv, fdv или hpf.
· Затем, если пользователь сделал выбор, открывается окно для ввода опций DVM-конвертора.
· Интерфейс не позволяет пользователю ввести противоречивые параметры, храня информацию о их возможных сочетаниях.
· Если пользователь нажимает на кнопку Compile, происходит компиляция выбранного кода, соответствующей командой. В окне логов появляется нужная запись. Если при выполнении этой команды, система обнаружила в коде ошибки, то предупреждение об этом будет записано в окно лога, а список ошибок будет выведен в окне ошибок. При этом, если данный код не был открыт для просмотра в отдельное окно, интерфейс сделает это.
· Для того чтобы узнать где возникла ошибка, пользователь должен выделить мышью строку с сообщением о ней, и нажать кнопку Showerror. В окне показывающем код, строка, в которой возникла ошибка, выделится цветом.
Когда пользователь выберет пункт меню Debug, произойдет примерно тоже самое. Вначале, вистема запросит пользователя о том, какой файл он хочет запускать на отладку. Затем предложит широкий набор опций для конвертера, кластера и матрицы прцессоров. Затем пользователь укажет какой способ отладки он хочет использовать. В настоящем интерфейсе доступны два метода отладки – метод динамического контроля и метод сравнения трассировок. При любом выборе пользователя, интерфейс проверит параметры на соответствие ожидаемым, и начнет задавать DVM-системе цепочку команд, необходимых для ее выполнения.
Например, если пользователь хочет произвести отладку программы с помощью метода сравнения трассировок, то произойдет следующее:
· Пользователь введет параметры.
· Интерфейс, проверив их, передаст системе команды на создание последовательного и параллельного отладочного варианта программы.
· Команды на накопление эталонной трассировки и сравнение результатов выполнения .
· При обнаружении ошибок, они будут предъявлены в окне ошибок. Окно логов сохранит все переданные системе команды по отдельности.
· Пользователь сможет выбирать ошибки в окне ошибок, и видеть места их возникновения, выделенными на листингах кода и трассировок.
Таким образом, GRIFрасширил возможности самого понятия – интерфейс, и привнес немного новой функциональности в систему.
Заключение
В рамках этой дипломной работы была построена формальная модель графического интерфейса DVM-системы. Это модель несет в себе свойства обеспечивающие соблюдение основных требований к интерфейсу DVM-системы. Разработка временных интерфейсов удовлетворяющих данной модели, позволит создавать удобные, эффективные и легко-изменяемые оболочки.
На основе данной модели был построен графический интерфейс к DVM-системе, удовлетворяющий всем требованиям, стоящим перед ним на нынешнем этапе развития системы. Этот интерфейс позволяет повысить эффективность работы с DVM-системой, и снизить ее суммарную стоимость владения.
В дальнейшем, при появлении необходимости совершенствовать интерфейс, разработчики могут дополнить существующий, руководствуясь формальной моделью, гарантирующей соблюдение всех требований.
Приложение
Диаграммы 3 - 4: диаграмма взаимодействия и кооперативная диаграмма для варианта использования FullDebug
Диаграммы 5 - 10: диаграммы взаимодействия и кооперативные диаграммы для варианта использования Debug
Диаграммы 11 - 12: диаграмма взаимодействия и кооперативная диаграмма для варианта использования dvmCSDEB-dvmCPDEB
Диаграммы 13 - 14: диаграмма взаимодействия и кооперативная диаграмма для варианта использования dvmCompile(CDV)
Диаграммы 15 - 16: диаграмма взаимодействия и кооперативная диаграмма для варианта использования dvmErr
Список литератур
ы
1. Документация к системе DVM. http://www.keldysh.ru/dvm
2. Коновалов Н. А., Крюков В. А., Погребцов А. А., Сазанов
Ю. Л. C-DVM язык разработки мобильных параллельных программ
.– М.: Препринт ИПМ им. М.В.Келдыша РАН, 1997. – №86. – 37 с.
3. Konovalov N. A., Krukov V. A., Mihailov S. N. and Pogrebtsov A. A. Fortran DVM – a Language for Portable Parallel Programs Development // Proceedings of Software For Multiprocessors and Supercomputers: Theory, Practice, Experience
4. Крюков В. А., Удовиченко Р. В. Отладка
DVM-программ. – М.: Препринт ИПМ им. М.В.Келдыша РАН, 1999. – №56. – 26 с.
5. В.Е.Денисов, В.Н.Ильяков, Н.В.Ковалева, В.А.Крюков. "Отладка эффективности
DVM-программ". Препринт ИПМ им. М.В.Келдыша РАН №74, 199 8
6. Gay S. Horstmann, Gary Cornell. “Fundamentals of JAVA”. Sun Microsystems Press.
7. Кендалл Скотт. «UML. Основные концепции.». Издательский дом Вильямс.
8. Крюков В.А. «Разработка параллельных программ для вычислительных кластеров и сетей.» . журнал - Информационные технологии и вычислительные системы.