Загрузка...
Учебная работа. Курсовая работа: Разработка графического интерфейса DVM-системы
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Инструментальная система DVM для разработки параллельных программ
Глава 2. Графический интерфейс
Что такое графический интерфейс
Требования к графическому интерфейсу
Требования к графическому интерфейсу DVM-системы
Модель графического интерфейса
Глава 3. Формальная модель графического интерфейса
средства построения формальной модели графического интерфейса
Формальная модель графического интерфейса
Глава 4. Графический интерфейс DVM-системы – ГРИФ
Как устроен ГРИФ
Детализированное описание графического интерфейса ГРИФ
Заключение
приложение
Перечень литературы
Введение
Данная работа посвящена дилеммам разработки графического интерфейса для DVM-системы. Задачка построения такового интерфейса еще по существу пока не ставилась, так как система интенсивно развивалась, и ее интерфейсы приметно изменялись. Система базируется на новейшей языковой модели, в ней реализованы новейшие способы многофункциональной отладки программ и отладки эффективности. Практическое внедрение системы для разработки сложных параллельных программ безизбежно вносило и заносит коррективы в ее методы и интерфейсы. В истинное время отсутствие графического интерфейса становится приметным недочетом системы. Но построение графического интерфейса для сложной программной системы, которая находится в стадии развития, является сложной задачей, решение которой можно значительно упростить методом проектирования обобщенной, формальной модели графического интерфейса DVM-системы. Таковая абстрактная модель, дозволит оценивать разрабатываемые варианты интерфейса исходя из убеждений соответствия модели, и проектировать рациональные интерфейсы. Данная работа дает новейший инструмент, созданный для формализации проектирования новейших интерфейсов. В ее рамках был разработан новейший интерфейс на языке Java, и проведена его оценка в сопоставлении с построенной формальной моделью.
Глава 1. Распределенные вычислительные системы
Роль распределенных вычислительных систем в решении современных задач
Крайние три столетия преподносили человеку новейшие, невообразимые до того технологии, определяющие весь ход предстоящего научно-технического прогресса. Возникновение в 18-м веке механических машин перевернуло людские представления о труде. Паровые машинки, придуманные в 19-м веке, открыли новейшие мощности. 20-й век был ознаменован возникновением вычислительной техники. Это открыло для человека новейшие, еще наиболее действенные методы хранения, передачи и обработки инфы. С возникновением этих методов, стали возрастать и потребности. Развитие промышленных технологий ставило задачки построения сложных систем. Аналитическое проектирование сделалось меньше подступать для этого. компы стали употребляться для моделирования действий и систем. Потребность во все наиболее высочайшей производительности вычислительных систем стала расти экспоненциально.
Существует несколько доступных путей роста производительности. Можно сделать лучше аппаратное обеспечение, используя наиболее высокопроизводительный машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) (либо вычислительной системы) которое делает арифметические и логические операции данные программкой преобразования инфы управляет вычислительным действием и коор, можно облагораживать программное обеспечение. В первом случае сходу становится виден предел увеличения производительности (на любом шаге развития процессоростроения). Во 2-м – появляются те же трудности. Хотя очевидно недозволено найти «верхний предел» эффективности метода, да и изобретать методы – дело непредсказуемой трудности.
Но еще есть 3-ий путь – параллельные вычисления. Почти все методы отлично масштабируемы, и поэтому выполнение их параллельно на нескольких вычислительных устройствах, даёт большенный выигрыш в скорости выполнения. И конкретно этот 3-ий путь, может быть является типичным толчком к возникновению головного заслуги 21-го века – внедрения вычислительных сетей. Но, параллельные вычисления — лишь 1-ая ступень на этом пути. Еще не существует достаточного количества программных средств, позволяющих писать и, что не наименее принципиально, отлаживать параллельные программки.
Совершенно многопроцессорные системы классифицируются по признаку обмена данными меж микропроцессорами. Есть две главные модели параллельного выполнения программ – модель передачи сообщений, и модель взаимодействия через общую память.
В первой модели программка представляет собой систему действий, взаимодействующих при помощи передачи сообщений. 1-ая модель быть может применена на всех кластерах.
Во 2-ой модели параллельная программка представляет собой систему нитей (thread), взаимодействующих средством общих переменных и примитивов синхронизации. Нить – это легковесный процесс имеющий с иными действиями общие ресурсы, в том числе – общую оперативную память. 2-ая модель быть может применена лишь на 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-программы во время ее поочередного выполнения на одном микропроцессоре Но внедрение данного способа значительно замедляет выполнение программки и просит огромных размеров доборной памяти. Потому, его следует использовать лишь для программки со специально подобранными тестовыми данными.
2-ой метод отладки – способ сопоставления трассировок, который дозволяет найти пространство в программке и момент, когда возникают расхождения в результатах вычислений. При трассировке вычислений производится сбор инфы обо всех чтениях и модификациях переменных, о начале выполнения всякого витка цикла, о начале и конце выполнения параллельного цикла, о начале выполнения каждой параллельной задачки, о начале и конце выполнения группы задач. Трассировка вычислений, как и динамический контроль, требовательна к ресурсам вычислительной системы. Потому рекомендуется поначалу трассировать программки с тестовыми данными, а потом уже перебегать к настоящим данным.
DVM-система, также имеет средства отладки производительности программ. Система поддержки выполнения DVM-программ во время выполнения программки на многопроцессорной ЭВМ (либо однородной сети ЭВМ ) копит информацию с временными чертами в оперативки микропроцессоров, а при окончании выполнения программки записывает эту информацию в файл, который потом обрабатывается на рабочих станциях в среде Windows 95/NT либо unix особым инвентарем — визуализатором производительности. При помощи визуализатора производительности юзер имеет возможность получить временные свойства выполнения его программки с различной степенью подробности.
DVM-система содержит инструмент, именуемый Предиктором, для произведения оценки эффективности программ на поочередной машине. При помощи предиктора юзер имеет возможность получить оценки временных черт выполнения его программки на MPP либо кластере рабочих станций с различной степенью подробности.
Глава 2. Графический интерфейс
Что такое графический интерфейс
Неважно какая программка ведет взаимодействие с юзером либо иными программками. Она получает некоторые указания и данные на вход, обрабатывает их и выдает итог собственной работы – выходные данные, либо указания для остальных программ. За время существования вычислительной техники программные системы неоднократно усложнились. юзер может желать получить от системы данные в комфортном для него формате : текст, звук, изображение. Та часть системы, которая является посредником в передаче данных от юзера к самой программке, конвертируя эти данные из понятного человеку представления, в понятные системе и напротив, именуется интерфейсом. интерфейс, в данном контексте, это часть программки, более близкая к юзеру, и превращающая остальную программку в «темный ящик». юзер уже может не знать как устроена программная система, ему приходится разговаривать лишь с интерфейсом. А интерфейс, в свою очередь обращается к системе. При всем этом сам интерфейс не несет никакой многофункциональной перегрузки системы. Его цель – быть очень комфортным для юзера, и разговаривать с ним на комфортном ему языке.
Графический интерфейс системы содержит в себе все нужные для работы с данной нам системой графические составляющие. В многооконных операционных системах это: окна, клавиши, меню, поля для ввода текста и т.д. Интерфейс должен уметь принимать от юзера и передавать программке любые данные, передача которых меж ними допускается данной нам программкой.
При всем этом графический интерфейс делает сходу несколько функций:
· Он упрощает юзеру работу с программкой, связывая функции программной системы с зрительными компонентами.
· Может давать подсказку юзеру, какие деяния тот может произвести с системой в текущий момент времени.
· Может создавать проверку вводимых юзером данных, до передачи
· Может уметь предоставлять юзеру результаты работы программной системы в любом комфортном для юзера виде. Другими словами, может предоставлять юзеру инструменты анализа приобретенных от системы данных.
· Может связывать меж собой несколько различных программ. В том числе и операционную систему.
Построение интерфейса – это задачка с которой рано либо поздно сталкиваются создатели хоть какого программного обеспечения.. И успешно изготовленный интерфейс, часто, не наименее принципиальный фактор в удачливости программного продукта, чем его функциональность. В свою очередь, разработка интерфейса предъявляет свои требования программной системе. к примеру требования очень формализованного обмена данными меж юзером и системой.
Таковым образом – построение интерфейса это принципиальная и нелегкая задачка. Превращая систему в «темный ящик», безуспешно спроектированный интерфейс способен «похоронить» в этом ящике некие способности, индивидуальности либо характеристики системы. Совершенно, интерфейс должен увеличивать эффективность работы программки и понижать суммарную стоимость владения программкой, понижением цены подготовки юзера программки.
Требования к графическому интерфейсу
Графический интерфейс – это благо для юзера, не так ли? Оказывается и он, призванный облегчить жизнь, способен причинять неудобства. И речь не только лишь о том, что интерфейс быть может обмыслен человеком, который не был юзером данной системы, и не понимает как создать его вправду «комфортным». Речь о остальных вероятных недочетах, которые могут обернуться суровыми неуввязками.
Во-1-х, это излишняя подробность и нарядность интерфейса. Для программки, в какой критично время ее выполнения, не постоянно имеет смысл представлять итог ее работы сложными диаграммами, либо иными элементами графического интерфейса, выведение на экран которых занимает много времени.
Во-2-х, это системные требования. Повышение системных требований, вызванное внедрением графического интерфейса, не обязано приводить к увеличению общих системных требований выше разумного уровня.
В-3-х, интерфейс не должен скрывать точки входа в систему, если это не вызвано соображениями администрирования и неопасного функционирования системы.
В-4-х, интерфейс должен быть реализован для всех операционных систем и архитектур, которые поддерживаются программной системой.
В-5-х, интерфейс должен перехватывать все исключительные ситуации, связанные с неверным вводом данных, и обрабатывать их, сообщая о этом юзеру, и не прерывая работу программной системы.
В-шестых, интерфейс к программке все еще находящейся в стадии разработки, должен иметь внутреннюю структуру, облегчающую его модернизацию, и должен иметь соответственное описание. На базе вышесказанного, можно сконструировать общие требования к интерфейсу 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 (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-ая диаграмма модели интерфейса (см. диагр. 1) – это усложненная диаграмма вариантов использования, которая обрисовывает связи меж вариациями использования и акторами системы, в качестве которой (в данной нам диаграмме, в отличие от остальных) выступают не только лишь юзер и сама система, да и файлы, содержащие DVM-программу. Эта диаграмма содержит вероятные цепочки выполнения установок, которые в реализации модели могут быть объединены для увеличения эффективности. Подробная диаграмма вариантов использования вышла очень массивной, потому модель содержит наиболее обычный (традиционный) вариант диаграммы (см. диагр. 2) В данной нам диаграмме лишь два актора: юзер и система. Зато, в силу того, что модель обрисовывает не саму систему, а ее интерфейс, и, как следует, юзеру быть может предложен визуализированный выбор (в виде пт меню, либо разных клавиш), набор вариантов использования возрос, за счет введения 2-ух новейших : dvmFullDebug, который дает юзеру избрать метод отладки – сопоставление трассировок либо способ динамического контроля, и dvmDebug, который дает юзеру ввести нужные данные, для того, чтоб произвести отладку способом сопоставления трассировок за один шаг. (Другими словами, интерфейс, накопив данные характеристик требующихся установок, по выбору этого варианта использования поочередно передает системе указания генерировать поочередный и параллельный варианты программки и эталонную трассировку, произвести сопоставление трассировок, и в случае нахождения ошибок сопоставления, сгенерировать параллельные трассировки, для предстоящего анализа ошибок.) Это объединение установок необязательно для интерфейса, но, потому что оно допустимо, и быть может желательным, имеет смысл включить его в модель, не исключая, вообщем вариантов, основанных на отдельном использовании этих установок.
Диаграмма 1
Диаграмма 2
В модели описано наличие анализатора ошибок, но, в связи с тем, что его функциональность, на данный момент до конца не определена, анализатор в модели описан в виде заглушки, принимающей от системы перечень ошибок, и контактирующий с юзером средством установок «запросить информацию о ошибке», «выдать информацию о ошибке». При уточнении требований к анализатору, и по мере необходимости выстроить графический интерфейс его включающий, данная формальная модель даст подсказку где и как расположить воззвания к нему. В модели же, анализатор представлен вариантом использования ErrorAnalize. Не считая того, модель унифицирует команды 1-го смысла, данные для программ написанных на языке C-DVM и Fortran-DVM. Это изготовлено для того, чтоб существенно упростить построение интерфейса – при схожем «смысле» команды и данных параметрах интерфейс способен сам выстроить правильное воззвание к DVM-системе.
сейчас разглядим модель детально. Модель разбита на абстрактные классы. Любому варианту использования соответствует один CONTROL (управляющий) класс, и два BOUNDARY (граничных) класса. BOUNDARY классы – это абстракции, принимающие входные данные у юзера либо передающие эти данные DVM-системе. Граничные классы модели, связывающие актора (юзера) и управляющие классы, соответствуют графическим компонентам интерфейса, таковым как ока, поля для ввода текста, клавиши, меню, переключатели выбора и т.д. Граничные классы взаимодействующие с CONTROL’ами и самой системой, являются описанием вызова подходящей командной строчки из интерфейса. Управляющие же классы принимают от граничных избранные юзером характеристики и строят на их базе правильную dvm-команду, передавая потом ее «вторым» граничным классам. Такие же два граничных класса предусмотрены для анализатора ошибок. Независимо от конечной реализации интерфейса, построенной на базе данной нам модели, эти классы, и связанные с ними диаграммы взаимодействия (поясняющие как и в котором порядке происходит обработка событий в интерфейсе) и кооперативные диаграммы (раскрывающие связи компонент интерфейса меж собой), останутся базой для его построения, которое сведется к итеративному наращиванию модели. Примеры диаграмм взаимодействия и кооперативных диаграмм приведены в приложении.(диаграммы 3-16). Все эти диаграммы обрисовывают абстрактную модель, которая может служить основой для хоть какой реализации интерфейса для DVM-системы, обеспечивая выполнение 5 требований к интерфейсу. Другими словами, таковая модель .делает доступными все точки входа в систему. Она подразумевает проверку характеристик установок, до их пуска на выполнение, она дает базу для построения инструмента, работающего с ошибками, и способна понизить суммарную стоимость владения системой из-за точного разделения вариантов использования, другими словами из-за стиля интерфейса, предлагающего подсказки при вводе характеристик установок.
Глава 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. Крюков В.А. «Разработка параллельных программ для вычислительных кластеров и сетей.» . журнальчик — Информационные технологии и вычислительные системы.
]]>