125556 (593128), страница 6

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

Текст из файла (страница 6)

Рисунок 9 - Формы, появляющиеся при запуске программного модуля

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

Еще одной важной задачей сетки "Grid", является оперативное хранение введенных данных и позволяет осуществить реализацию постпроцессирования. Редактор кода выделяет ключевые слова языка программирования ("procedure", "var", "begin", "end", "if" и другие) полужирным шрифтом, что делает текст программы более выразительным и облегчает восприятие структуры программы (рисунок 10).

Рисунок 10 - Редактор кода программы

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

Остальные формы отвечают за удобный ввод данных (параметры заготовки, инструмента, операций обработки, настройка технологических параметров и т.д.). Некоторые параметры требуют математических расчетов. Delphi со стандартными настройками может производить только самые простые математические действия. Чтобы вводить тригонометрические функции, а также сложные алгебраические действия необходимо подключить дополнительный модуль Delphi "Math". Сделано это для того, чтобы не загружать компилятор лишними данными и упростить программу, если она таких вычислений не требует. Модуль "Math" необходимо ввести в строку "Uses" редактора кода.

Из всех настроек можно выделить настройку самого постпроцессора для перевода в Lisp. Так как этот постпроцессор создает файл для пакета 3D моделирования, то параметры, выведенные в этот файл влияют на качество полученной модели. Модель в данном случае строится по направляющей и большому количеству сечений. При таком способе построения качество модели зависит от количества созданных сечений, и от качества каждого сечения в отдельности. Тут необходимо найти компромисс между качеством производительностью. Чем больше кривизна поверхностей модели, тем больше сечений надо, для получения качественной модели, но слишком большое количество сечений в свою очередь может перегрузить процессор даже достаточно мощного компьютера, что также не допустимо. На качество каждого сечения влияет количество элементарных отрезков и дуг, из которых оно состоит. Тут также слишком малое количество элементарных частей может привести к значительным отклонениям от действительных размеров, а слишком большое их количество может привести к математическим аномалиям (длина отрезка равна нулю или дуга образует внутреннюю петлю) [27].

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

Весь проект Delphi сохраняется в специально созданном для этого каталоге. В подкаталогах главного каталога сохраняются пользовательские файлы, на которые ссылается программный модуль (набор картинок, текстовые файлы, содержащие массивы данных, дополнительные библиотеки данных). Для проверки работоспособности программного модуля, в Delphi есть достаточно большой объем инструментальных средств. Это пошаговые компиляторы и отладчики с широким набором функций проверки правильности кода и т.п. При запуске программы на проверку, Delphi автоматически компилирует программный модуль в исполняемый файл (рисунок 11).

Рисунок 11 - Программный модуль

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

Процесс устранения ошибок носит итерационный характер. Обычно сначала устраняются наиболее очевидные ошибки, например, декларируются необъявленные переменные. После очередного внесения изменений в текст программы выполняется повторная компиляция.

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

1. 3.2 Правила установки и настройки программного модуля

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

Для работы программного модуля, для начала необходимо установить на компьютер программный пакет One Space Designer Modeling 2005 и новее, созданный компанией CoCreate. Процесс установки этого пакета полностью описан в инструкции к дистрибутиву.

Далее в корне любого постоянного диска, необходимо создать каталог с названием "CIP6". Такое название было принято при создании программного модуля, поэтому менять его нельзя. Внутри этого каталога должен быть создан подкаталог "Emul". Сделано это для того, чтобы в каталоге "CIP6" можно было создать ряд других каталогов, в которых могла бы храниться информация, связанная со станком, но не связанная с программным модулем (требование заказчика).

В каталоге "Emul" создаются подкаталоги, содержащие служебные файлы.

Каталог "BMP" содержит файлы изображений, используемые для пояснений и графического оформления программного модуля.

Каталог "DAT" содержит файлы, с настроечными параметрами станка (значения абсолютных координат положения инструмента относительно заготовки в начальном положении). Эти параметры остаются неизменными в течение всего периода между ремонтами. В случае изменения этих значений достаточно открыть каждый из файлов как текстовый, вручную изменить значения этих параметров и сохранить изменения в том же файле. Сделано это для того, чтобы после ремонта станка, программа не нуждалась в повторной компиляции.

Каталог "LSP" содержит группу файлов, отвечающую за визуализацию процесса обработки в пакете 3D моделирования. Часть файлов являются неизменными, они содержат базовую геометрию, которая будет преобразована в частный случай. Это система координат, взаимное положение осей, параметрическая модель патрона и заготовки. Остальные файлы предназначены для изменения базовой геометрии. Эти файлы имеют переменное содержимое, и создаются каждый раз заново. Они строят круги, реальную заготовку, патрон, содержат информацию о перемещениях рабочих органов станка.

Также особой настройки требует и пакет 3D моделирования. Необходимо создать функцию загрузки базовой и дополнительной геометрии из файла (рисунок 12).

Рисунок 12 - Создание дополнительных функций

Ссылка идет на файл, в котором прописаны ссылки на группу других файлов, что упрощает настройку. После этого необходимо прописать в пакете 3D моделирования каталог "Emul", как рабочую директорию.

На этом процесс установки завершается.

1. 3.3 Тестирование и отладка программного модуля

Первые программные системы разрабатывались в рамках программ научных исследований или программ для нужд министерств обороны. Тестирование таких продуктов проводилось строго формализовано с записью всех тестовых процедур, тестовых данных, полученных результатов. Тестирование выделялось в отдельный процесс, который начинался после завершения кодирования, но при этом, как правило, выполнялось тем же персоналом [23].

В тестировании программного модуля можно выделить четыре этапа:

• тестирование отдельных модулей;

• совместное тестирование модулей;

• тестирование спецификации программы;

• тестирование всего комплекса в целом (т.е. поиск несоответствия созданного программного продукта сформулированным ранее целям проектирования, отраженным в техническом задании).

Модульное тестирование (юнит-тестирование) – тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками программного обеспечения.

Интеграционное тестирование – тестируются интерфейсы между компонентами, подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

Системное тестирование – тестируется интегрированная система на её соответствие требованиям.

Альфа-тестирование – имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями и заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы специалистам по тестированию для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программное обеспечение.

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

Часто для свободного (открытого) программного обеспечения стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования – стадию исправления ошибок. При этом, как правило, на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

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

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

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

Существует множество подходов к решению задачи тестирования и верификации ПО, но эффективное тестирование сложных программных продуктов – это процесс, в высшей степени, творческий, не сводящийся к следованию строгим и чётким процедурам или созданию таковых.

С точки зрения ISO9126, качество (программных средств) можно определить как совокупную характеристику исследуемого программного обеспечения с учётом следующих составляющих:

• надёжность;

• сопровождаемость;

• практичность;

• эффективность;

• мобильность;

• функциональность.

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

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

При тестировании чёрного ящика, специалист по тестированию имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идёт правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе. Как правило, в данном виде тестирования критерий покрытия складывается из покрытия структуры входных данных, покрытия требований и покрытия модели (в тестировании на основе моделей).

При тестировании серого ящика разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.

Характеристики

Список файлов ВКР