Создание АРМ "Клиент-менеджер.Наружная реклама"

Рис. 3.2. Структура реляционной базы данных «Клиент-менеджер. Наружная реклама»

3.6. Подключаемые внешние модули

Подключаемые внешние модули являются технологией, которая позволяет расширить функциональность приложения. Модуль представляет стандартную динамически загружаемую библиотеку (DLL — Dynamic Link Library) Windows, которая содержит дополнительные функции по обработке данных[31].

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

16. Функция инициализации;

17. Функция получения имени модуля;

18. Функция обработки данных.

Процедура подключения библиотеки:

// Загрузка файла конфигурации

void __fastcall TForm1::LoadConfiguration(AnsiString cfgname)

{

// Загрузка файла из параметра cfgname

st->Items->LoadFromFile(cfgname);

HINSTANCE htmp;

void (__stdcall *ver)(char *); // описание указателя на функцию

for(int i=0;i<st->Items->Count;i++)  // перебор всех строк из файла

{

  htmp=LoadLibrary((st->Items->Strings[i]).c_str()); // Загрузка динамической библиотеки dll

  if(htmp){ // проверка успешно ли загруженна библиотека

   ver=(void (__stdcall *)(char *))GetProcAddress(htmp,"_GetDllVersion"); // получение адреса функции проверки версии библиотеки

   if(ver){ // если данная функция существует

    char *ctmp=new char[50]; ctmp[0]='\0'; ver(ctmp); // вызов функции

    if(strcmp(ctmp,"Master v1")==0){ // совместима ли библиотека с данной версией программы

     // установка массива переменных

     libs[libscount].Lib=htmp;

     libs[libscount].Name=st->Items->Strings[i];

     ver=(void (__stdcall *)(char *))GetProcAddress(htmp,"_GetLibraryID"); // получение адреса функции определения уникального идентификатора библиотеки

     ctmp[0]='\0'; ver(ctmp);

     libs[libscount++].UniqueID=ctmp;

     ver=(void (__stdcall *)(char *))GetProcAddress(htmp,"_GetLibraryHeader"); // получение адреса функции определения заголовка библиотеки

     ctmp[0]='\0'; ver(ctmp);

     libs[libscount++].LibHeader=ctmp;

     // добавление закладки загруженной библиотеки

     TabControl1->Tabs->Add(ctmp);

    }else{ FreeLibrary(htmp);} // если библиотека не та то высвобождаем память от нее

    delete [] ctmp;

   }else{ FreeLibrary(htmp);}

  }

}

if(libscount>0){

  LoadResource(0); // в случае загрузки библиотек загружаем ресурсы из них

}

}

В начале работы, программа сканирует файл конфигурации на  наличие динамических загружаемых библиотек — DLL.

// Загрузка кофигурационного файла библиотек

LoadConfiguration(rootdir+"\\test.cfg");

Путем вызова процедуры LoadLibrary, программа открывает динамически обновляемую библиотеку. Если успешно, то осуществляется загрузка модуля в память. Далее, для получения имени модуля и отображения его в закладке редактора вызывается функция GetProcAddress. При завершении работы программы, все модули выгружаются из памяти.

В файле MR_lib.cpp содержатся описания методов работы с классами, находящимися в DLL-файле:

enum ProgModes { mNone, mInsertObject, mDragInsertObject,

                  mSelectObject, mDragObject, mMouseOnPoint,

                  mTextInput };

enum StatusModes {sNone, sBeforeInsert, sAfterInsert,

                  sBeforeSelect, sAfterSelect,

                  sBeforeDrag, sAfterDrag,

                  sBeforeResize, sAfterResize};

enum ReturnMode { rmNone, rmBreak, rmStop, rmCrash,

                  rmTextInput };

enum MouseButton { Left, Midle, Right };

3.7. Тестирование и отладка

3.7.1. Методы тестирования

После завершения этапа разработки приложения «АРМ «Клиент-менеджер. Наружная реклама» необходимо провести его тестирование в отношении критериев эффективности. Тестирование программного продукта необходимо для проверки правильности функционирования всех компонентов программы.

Тестирование является одним из этапов жизненного цикла ПИ, направленным на повышение качественных характеристик. При создании типичного программного продукта около 40% общего времени и более 40% общей стоимости расходуется на проверку (тестирование) разрабатываемой программы [23].

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

Так как для разработки приложения применялась методология Object Modeling Technique (OMT), то тестирование и отладка приложения производилась после написания очередного модуля, потому что это является одной из особенностей данной методологии. Учитывая этот фактор, в качестве метода тестирования был выбран метод статистического тестирования. Реализация этого метода проводится путем проверки программного кода и исправлении его, в случае выявления ошибок.

Статическое тестирование - наиболее формализованное, базируется на правилах структурного построения программ и обработки данных. Проверка степени выполнения этих правил проводится без изменения объектного кода программы путем формального анализа текста программы на языке программирования. Операторы и операнды текста программы анализируются в символьном виде, поэтому этот метод тестирования иногда называют символическим тестированием.

Статическое тестирова­ние реализуется путем применения ручных методов тестирова­ния программ. Они получили развитие с начала 70-х годов, когда в программировании были введены требования структур­ного и модульного написания программ. Это сделало програм­мы удобочитаемыми и позволило проводить тестирование отдельных модулей вручную без использования ЭВМ.

Использование ручных методов тестирования достаточно эф­фективно. Для типичных программ, по данным фирмы IВМ, можно находить от 30 до 80% ошибок логического проектирова­ния и кодирования. Эти методы способствуют существенному увеличению производительности и повышению надежности программ, позволяют раньше обнаружить ошибки, а значит, уменьшить стоимость исправления. При ручных методах тести­рования вероятность того, что при исправлении ошибок не вно­сятся новые ошибки, намного выше [24].

Мной был выбран  метод ручного тестирования – инспекции исход­ного текста.

В этом методе предполагается некоторая подготовительная работа и проведение собрания, состоящего из участников проверки, цель которого нахождение ошибок, но не их устранение (т.е. тестирование, а не отладка).

В проверке участвовали разработчик ПС – А.Е. Сысуев и Д.В. Ануфриев (дизайнер фирмы «Мастерская Рекламы»). Д.В. Ануфриев проверял работоспособность программного кода, написанного А.Е. Сысуевым.

Рассмотрим каждую из предлагаемых процедур.

Инспекции исходного текста – набор правил и приемов обнаружения ошибок при изучении текста программы.

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

Тестер должен сосредоточить свое внимание на поиске ошибок, а не на их корректировке. По окончании проверки автору программы передается список найденных ошибок. Если он очень велик и требует больших доработок, то может быть принято решение повторной инспек­ции. Оптимальная продолжительность заседания 90-120 мин. Скорость просмотра 150 операторов в час.

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

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

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

3.7.2. Результаты тестирования и отладки

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

Примеры некоторых ошибок:

     Не работали некоторые свойства подключенного модуля;

     Не корректно работал «Предварительный просмотр»;

     Данные некоторых таблиц выдавались неверно.

При оценке программного средства были проверены функции:

     Вывод на печать;

     Просмотр сформированных документов;

     Подключение модуля;

     Построение графиков.

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

Также во время оценки производилась проверка удобности интерфейса.

Выводы.

1.      В качестве платформы для создания программного продукта выбрана Win32, как наиболее распространенная и эффективная.

2.      Средством разработки выбран программный продукт Borland C++ Builder 5.0.

3.      Описана реализация интерфейса программы «АРМ «Клиент-менеджер. Наружная реклама», разработанного с использованием стандартов графического интерфейса пользователя (GUI), являющегося обязательным компонентом большинства современных программных продуктов.

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

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