CC BY
28
В структуру БД включены вспомогательные таблицы:
• Users_Is_On - для хранения информации обо всех клиентах, подключившихся к серверу;
• Contacts - для сохранения информации о контактах для каждого клиента;
• Not_Send_Messages - для сохранности сообщений, поступивших в тот момент, когда клиент-получатель был отключен.
Наиболее удобное средство разработки программ - язык C#, так как он ориентирован на создание приложений для работы с БД и на формирование удобного, интуитивно понятного интерфейса. Также в нем реализована возможность работы с XML-документами, что облегчат работу по созданию анализирующих частей в клиент-серверном приложении. Он предлагает разработчику ряд готовых стандартных решений для выполнения необходимых задач.
Сокеты - это удобное средство передачи данных между удаленными узлами в сети. Их преимущество заключается в том, что не требуется выделять определеный узел под серверные нужды. Любой компьютер в сети, на котором запущена серверная программа, сам становится сервером и может отбрабатывать приходящие ему сообщения.
В мире информационых технологий все большую популярность получают XML-технологи. Благодаря основной возможности языка создавать собственные теги его можно настраивать под описание любых объектов в рамках любых задач. Возможность создавать собственные теги и распознавать их позволяет эффективно использовать язык XML в качестве протокола передачи данных между клиентом и сервером. Работа с XML-структурами проста и эффективна, тогда как для структурирования, преобразования и редактирования информации SQL БД приходится прикладывать дополнительные усилия. Этим выгоден XML-формат в качестве прослойки между уровнями бизнес-логики и хранения данных.
Программа сервер решает следующие задачи:
• прослушивание порта в ожидании подключения клиента;
• получение от клиента сообщения в виде XML-документа;
• анализ XML-документа, распознавание собственных тэгов и формирование SQL-запроса к БД;
• выполнение соединения с БД и получение результата запроса;
• отправка результата клиенту в виде XML-документа, содержащего собственные тэги.
Программа клиент реализует следующие функции:
• инициирует соединение с сервером по IP-адресу:
• отправляет XML-документ, содержащий собственные тэги;
• ожидает ответа сервера;
• получает и интерпретирует XML-документ;
• предоставляет удобный пользовательский интерфейс.
Сам интерфейс может быть реализован различными способами с использованием стандартных компонентов выбранной среды разработки, таких как таблицы, календари, списки, метки, текстовые поля, ниспадающие меню и т.д.
Подводя итог, отметим, что в силу разных причин возникает необходимость в организации деятельности сотрудников для своевременного завершения работы или задания, сокращения или удаления дублирования действий, создания центров ответственности, обеспечения стабильности в функционировании организации. Информационные системы должны поддерживать эти цели. Системы, подобные описанной, обеспечивают определенные преимущества перед конкурентами, автоматизируя операции внутри системы и улучшая качество или поставку конечного продукта организации. Преимущества внутри самой фирмы проявляются в поддержке оперативного контроля, организации управленческого контроля и в стратегическом планировании.
Список литературы
1. Боронников А.Б., Семенов С.В. Построение информационных систем на основе технологии XML веб-сервисов // Программные продукты и системы. -2004. -№4. -С. 61-62.
2. Боронников А.Б. Место XML-технологий в среде современных информационных технологий // Программные продукты и системы. -2005. -№2. -С. 57-59.
3. Постолит А.В. Visual Studio.NET: разработка приложений баз данных.- СПб.: БХВ-Петербург, 2003. -544 с.
МЕХАНИЗМ КОНТРОЛЯ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ОПТИКО-ЭЛЕКТРОННЫХ СИСТЕМ КОНТРОЛЯ
Е.А. Балыков, В.А. Царев
Автоматизированные оптико-электронные системы контроля (ОЭСК) [1], позволяющие повысить эффективность управления технологиче-
скими процессами, чрезвычайно востребованы в промышленном производстве, транспортных перевозках, охранном наблюдении и т.п.
Одной из составных частей ОЭСК является нетривиальное программное обеспечение (ПО), к которому предъявляются жесткие функциональные требования. Основной задачей, решаемой в процессе разработки ПО ОЭСК, является подтверждение и улучшение качества изготовляемых программных модулей (ПМ). Данная задача эффективно разрешается с помощью механизма контроля качества ПО ОЭСК, включающего процедуры ручного контроля, методы аналитической верификации и дисциплину тестирования [2,3].
При создании ПО ОЭСК приходится сталкиваться со значительными трудностями. Это обусловлено рядом факторов, специфичных для программных систем класса ОЭСК:
- недостаточное развитие теоретических основ процесса верификации, тестирования и отладки ПМ ОЭСК, использующих разнообразные циклические структуры, массивы, подпрограммы, и операторы, которые могут потенциально привести к исключительным или аварийным ситуациям;
- математическое обеспечение ОЭСК представлено в большей части эвристическими алгоритмами обработки и анализа изображений, которые не всегда обеспечивают получение правильного или оптимального решения, что обусловливает неприменимость методов верификации для доказательства корректности и затрудняет выявление источника ошибки, найденной в ПМ ОЭСК, реализующем эвристический алгоритм.
Следовательно, необходимо развитие и адаптация существующих методов, а также построение новых способов контроля качества, которые бы учитывали специфику ОЭСК и позволяли создавать ПМ ОЭСК, обладающие высокими заданными характеристиками качества.
Принятые в классических методах верификации программ (методах Флойда и Хоара) [4] допущения позволяют применять их к небольшому числу достаточно тривиальных программ. Реальные программные системы намного сложнее. К ним относятся ПМ ОЭСК, которые содержат такие программные структуры, как подпрограммы; массивы видеоизображений; особые операторы, которые при определенных значениях входных переменных могут не завершиться, привести к исключительной ситуации или аварийному сбою.
Следовательно, необходимо развить и доработать классические методы верификации, чтобы они учитывали особенности рассмотренных программных элементов.
Предложения по развитию метода Флойда, включают следующие этапы.
1. К существующим операторам, используемым при построении блок-схемы алгоритма программы P , добавляются операторы подпрограмм и особые операторы, производные от операторов присваивания и ветвления. Если значение некоторого аргумента подпрограммы Pi вычисляется в
момент вызова, то оператор подпрограммы следует упростить.
2. Для доказательства частичной корректности программы P, содержащей подпрограммы, необходимо предварительно доказать частичную корректность всех подпрограмм: {ф^{у^, где Ф^ уi - предусловия и постусловия соответствующих подпрограмм. Доказательство корректности подпрограмм, как и основной программы, следует проводить относительно расширенной спецификации вида {ф?&й0 (у,'V)} Р {у?&й0 (у,У)}. Доказательство истинности всех условий верификации, следующих за подпрограммой Pi, необходимо проводить с использованием предиката уi. Истинность постусловия уi обеспечивается истинностью фi и {ф^РДу^ . А для вывода истинности фi используется стандартное условие верификации Флойда вида Уу(18(у) л Ка (у)) ^ ^ ф^Та (у)) , где а - базовый путь, ведущий в подпрограмму Pi; у - вектор переменных пути; в - точка начала пути; 18(у) - индуктивное утверждение для начальной точки пути; Ка(у) -
предикат пути; Та (у) - функция отображения состояния памяти.
3. Доказательство частичной корректности программы Р, содержащей массив М, заключается в доказательстве истинности условий вида
18(у) ^ К,(х), где К,(х) - утверждение, задающее принадлежность индексов массиву М ; 1 - оператор в котором осуществляется доступ к элементам массива М ; х - вектор индексов или указателей.
4. Для доказательства завершаемости программы Р , содержащей особый оператор 10 , необходимо доказать истинность условия вида ^(у) ^Ф1о(х), где 18(у) - индуктивное утверждение, составленное для входного ребра оператора 10 , а ф1о (х) - предусловие оператора 10 , задающее область определения вычисляемого в 10 выражения.
Предложения по развитию метода Хоара включают следующие этапы.
1. Для доказательства частичной корректности программы Р , содержащей подпрограмму Р1, исходная система аксиом и правил вывода дополняется правилом вида:
(р(х1,...,хп) = р1(х1,...,хк)лРз(хк+1,...,хп))^фх {фх}8{ух}, (р}8{ у1(х1,...,Хк) л Р2(Хк+1,...,Хп)}
где р(х1,...,хп) - постусловие предшествующего оператора; (ф1,у1) - предусловие и постусловие оператора вызова подпрограммы 8. Причем
постусловие р состоит из двух частей: предиката р1(х1,...,хк), определяющего тот же набор переменных хх,...,хк, который определен и в постусловии подпрограммы ^1(х1,...,хк), а также предиката р2(хк+1,...,хп), определяющего набор переменных хк+1,...,хп, который не задан в у1 и элементы которого не модифицируются в Р1. Как и в развитии метода Флойда, в данном случае необходимо доказать {ф®&й0 (у,У)}Р1 (У^0 (у,У)} .
2. Доказательство частичной корректности программы Р , содержащей массив М , заключается в доказательстве истинности условия вида
уi_1 ^К,(х), где у|-1 - постусловие предшествующего оператора.
Для доказательства завершаемости программы Р , содержащей особый оператор 10 , необходимо
доказать истинность условия вида у|_1 ^ Ф1о(х).
Для доказательства завершаемости подпрограммы Р1 необходимо в сформированном выше правиле заменить все утверждения о частичной корректности на утверждения о полной корректности.
При проектировании эвристических алгоритмов принимаются определенные допущения, не имеющие строгого математического обоснования, а основанные исключительно на опыте и интуиции разработчика, вследствие чего ПМ ОЭСК, реализующие подобные алгоритмы, не всегда вырабатывают правильное решение. Следовательно, известные методы верификации неприменимы для доказательства правильности функционирования ПМ ОЭСК вида Р^, то есть ПМ, реализующих эвристические алгоритмы.
В [5] отмечено, что корректность программы определяется двумя свойствами: корректностью функционирования и корректностью построения, или так называемой конструктивной правильностью. Поэтому в статье предлагается использование методов верификации для доказательства конструктивной правильности (ф)Р^(у)е ПМ ОЭСК вида Р^, что позволит повысить их качество.
Методика доказательства конструктивной правильности включает следующие шаги.
1. Верификация завершаемости ПМ ОЭСК вида Р^. Завершаемость программ ОЭСК, реализующих эвристические алгоритмы, может быть подтверждена существующими методами верификации. Данное положение справедливо как для (ф)Р^(О, так и для (фг +фе)Р^(1). Причем для ПМ ОЭСК с трудно формализуемыми спецификациями можно доказать завершаемость (фг +фе)Р^(1), так как предикаты итераторов циклов и особых операторов принадлежат, как правило, к четко формализуемой части спецификации бр(фг, ).
2. Верификация правильности построения ПМ ОЭСК вида Р^. Основная идея основывается на том факте, что большинство эвристических алгоритмов представимо комбинацией точных алгоритмов с четко формализуемыми спецификациями. Это позволяет применить существующие методы верификации для доказательства правильности алгоритмов входящих в комбинацию, а соответственно, проверить конструктивную правильность ПМ ОЭСК, реализующего эвристический алгоритм.
2.1. Декомпозиция программы Р^, имеющей спецификацию вида б(ф,у) или бр+Е(фг +фе,
+у е), на набор подпрограмм или этапов вида Р1, реализующих точные алгоритмы и имеющих четко формализуемые спецификации вида б1(ф1, V 1).
2.2. Доказательство с помощью известных методов аналитической верификации частичной корректности всех этапов Р1 относительно своих спецификаций б1(ф1,у 1), {ф1}Р1{у 1}.
2.3. Вывод о конструктивной правильности (ф)Р^(у)е ПМ ОЭСК на основе частичной корректности составляющих его этапов {ф1}Р1{у 1} и завершаемости всей программы Р^, что обеспечит полную корректность всех этапов (ф1) Р1 (у 1).
Верификация ПМ ОЭСК вида Р^, проведенная в соответствии с предложенной методикой, даст возможность подтвердить конструктивную правильность и завершаемость программ, пред-ставимых комбинацией точных алгоритмов с четко формализуемыми спецификациями. Вопрос правильности функционирования программы Р^ разрешается методами функционального тестирования.
Основное отличие эвристических алгоритмов от точных заключается в том, что они не всегда дают правильное решение. Следовательно, если с помощью некоторого механизма контроля качества (например тестирования) выявлена ошибка в ПМ ОЭСК вида Р^, то в этом случае трудно определить действительный источник ошибки. При этом можно выделить три возможных источника ошибки: ошибка реализации, дефект эвристического алгоритма и ошибка трансляции алгоритма в реализацию. Разрешение указанной проблемы в рамках процесса обеспечения качества ПО ОЭСК позволит сократить трудоемкость отладки и уменьшить сроки разработки ПО ОЭСК.
Часть модели ЖЦ ПО ОЭСК, связанная с проектированием и реализацией алгоритмического обеспечения, представлена на рисунке.
Как правило, алгоритмическое обеспечение ОЭСК разрабатывается математиком с использо-
ванием вспомогательного языка, предоставляемого специализированными математическими пакетами (Mathlab, Mathcad), позволяющими проводить проверку эффективности и осуществлять предварительную верификацию синтезированных алгоритмов. Затем спецификация алгоритма вида б(ф, у), где ф, у - предусловие и постусловие эвристического алгоритма, а также описание алгоритма (псевдокод или блок-схема) передаются на этап реализации. На этапе реализации осуществляется кодирование алгоритма программистом с использованием основного языка программирования (С/С++, MC++, С#), предоставляемого интегрированной средой разработки (MS Visual Studio.net). Спецификация реализации б'(ф',у') получена из исходной спецификации алгоритма б(ф, у) путем дополнения спецификации интерфейсной части
бею .
Для разрешения проблемы поиска источника ошибки, выявленной в ПМ ОЭСК вида Р|, предлагается способ, учитывающий рассмотренную специфику конструирования и модели ЖЦ ПО ОЭСК. Способ основан на так называемой многоязыковой реализации исходного алгоритма и вспомогательных языках программирования и включает следующие этапы.
• Определение исходных данных. Пусть исходный эвристический алгоритм задан спецификацией б(ф,у) и описанием O|. Пусть существует основная реализация эвристического алгоритма Р| и ее спецификация б'(ф',у'), а также вспомогательная реализация Pi1 = i | и ее спецификация
ба(фа, уа) = б(ф, у), идентичные описанию и спецификации исходного алгоритма.
• Проверка корректности трансляции. Источником выявленной ошибки является неправильная трансляция алгоритма в основную реализацию, если выявлено несоответствие между спецификациями или между описанием и реализацией (б(ф,у)*б'(ф',у'))v(O| *D|). Однако полное соответствие между алгоритмом и основной реализацией (б(ф,у) = б'(ф',у'))л(O| = D|) не позволяет сделать вывод об алгоритмической природе дефекта, так как могут существовать ошибки несоответствия спецификации и реализации «ф' >Р|<у' >) = f .
• Проверка корректности алгоритма и реализации. Если отсутствуют дефекты трансля-
ции исходного алгоритма в основную реализацию, то есть выполнено условие вида (б(ф, у) = = б'(ф',у'))л (О^ = В^), и если результаты тестирования всех реализаций алгоритма В^,Ва отличаются хотя бы на одном тестовом случае, то источник ошибки - реализация, если же результаты
тестирования В^,Ва идентичны для всего тестового набора, то принимается решение об алгоритмической природе ошибки. Степень надежности такого решения зависит от степени тестированно-сти реализаций.
Следует отметить, что этап проверки корректности трансляции алгоритма в реализацию достаточно сложен и нетривиален. Поэтому способ поиска источника ошибки дополнен методикой проверки корректности трансляции алгоритма в реализацию, которая включает следующие шаги.
1. Определение семантического соответствия между спецификацией эвристического алгоритма
и спецификацией основной реализации ?
б(ф,у)=б'(ф',у'). Как правило, спецификация алгоритма записывается с помощью строгих математических обозначений и отражает суть алгоритма. Спецификация основной реализации является более детальной и записывается с учетом синтаксиса конкретного языка программирования, а также учитывает особенности аппаратного представления и хранения данных, адаптирует исходную спецификацию к конкретным типам данных и дополняет ее требованиями к интерфейсной части (так называемая интерфейсная обвязка).
1.1. Построение эквивалентной спецификации вида: б уёа (фуёа, ууёа) = б '(ф', у') ^ б (ф, у).
1.2. Проверка семантического равенства всех термов и утверждений, входящих в спецификацию алгоритма и эквивалентную спецификацию:
Т! =Тр ,...,ТП =Тр; Т1,...,ТП ё б, Тр ,...,Туёа ё б уёа .
1.3. Фиксация всех выявленных несоответствий и различий между буеа (фуеа, ууеа) и б(ф, у).
1.4. Семантическое равенство термов, входящих в исходную спецификацию алгоритма и спецификацию реализации Т1 = Т/еа,...,Тп = Туеа, и отсутствие зафиксированных на шаге 1.3 различий позволяет сделать вывод о семантическом соответствии между исходной спецификацией алгоритма и спецификацией реализации б(ф,у) = = б'(ф', у'). В случае наличия различий решение о соответствии спецификаций и отсутствии ошибок трансляции должно приниматься на следующем этапе.
2. Определение семантического соответствия
между описанием эвристического алгоритма и его
?
основной программной реализацией О^=В^. Как правило, описание алгоритма задается в общем
виде и не учитывает конкретные особенности реализации (типы данных, интерфейсной части и языка программирования). Поэтому при реализации алгоритм определенным образом модифицируется.
2.1. Построение эквивалентного описания I |еа = в ^! ^ в виде псевдокода или блок-схемы.
2.2. Проверка того, учитывает ли I |еа различия, зафиксированные на шаге 1.3. Если I уеа и реализация Р^ построены с учетом различий, зафиксированных между буеа(фуеа, ууеа) и б(ф, у), то принимается решение о семантическом соответствии спецификаций б(ф,у) = б'(ф',у'), иначе констатируется несоответствие спецификаций б(ф, у) * б'(ф', у') и принимается решение о наличии ошибки трансляции.
2.3. Проверка семантического равенства экви-
?
валентного и исходного описания ! уеа =! ^ путем прямого сопоставления полученного и исходного псевдокода или блок-схем.
Если (! |ёа = I 9) л (б (ф,у) = б' (ф',у')), то принимается решение о корректности трансляции алгоритма в реализацию (б(ф,у)=б'(ф',у,))л(0^=Е^), в противном случае констатируется несоответствие описания и реализации и принимается решение об ошибке трансляции.
Реализация алгоритма на нескольких языках программирования приводит к значительному удорожанию процесса разработки и увеличению сроков выпуска ПС. Однако ЖЦ ПО ОЭСК преду -сматривает две стадии разработки: фаза синтеза алгоритма с одновременной его реализацией на вспомогательном языке и фаза реализации алгоритма на основном языке программирования. Следовательно, в рамках ЖЦ ПО ОЭСК реализация алгоритмов всегда осуществляется в двух языках программирования, что обусловливает минимальные затраты, связанные с поиском источника ошибки в ПМ ОЭСК вида Р^.
Среди широко используемых в рамках ПМ ОЭСК программных конструкций можно выделить циклические структуры. К наиболее распространенным дефектам циклических структур относятся ошибки некорректного изменения итераторов, которые могут привести к зацикливанию соответствующего ПМ и зависанию работы ОЭСК. Анализ существующих методов тестирования показал отсутствие каких-либо методик
тестирования завершаемости циклических структур.
В статье представлена новая методика, позволяющая осуществлять целенаправленное тестиро-
вание завершаемости циклов ПМ ОЭСК. Методика разработана с учетом специфики циклов, применяемых в ПМ ОЭСК для обработки массивов видеоданных, заключающаяся в изменении значений итераторов цикла в соответствии, как правило, с монотонными функциями. Предложенная методика базируется на принципах верификации и включает следующий ряд шагов.
1. Проверка на входе в цикл возможности достижения итератором значения выхода из цикла 1 = 1п , где 1 - итератор цикла; 1п - граничное значение в условии выхода из тела цикла. Для составного условия необходимо проверить возможность достижения итератором соответствующих граничных значений. Первый шаг позволяет выявить ошибки несоответствия типов итератора и граничного значения в условии выхода из цикла, которые могут привести к исполнению бесконечного числа итераций.
2. Проверка внутри тела цикла изменения итератора на некоторую необязательно постоянную величину 1к = 1к-1 + А , приближающую итератор к окончанию цикла, где к < п, 1к-1,1к - значения итератора; А - шаг приращения индекса. Подтверждением приближения итератора к окончанию цикла является истинность неравенства |1п _ 1к| < |1п _ 1к_1, где 1п - граничное значение в
условии выхода из тела цикла. Второй шаг предназначен для выявления ошибок некорректного изменения итератора цикла, способных повлечь за собой зацикливание или некорректную работу тестируемого метода.
3. Исполнение второго шага в соответствии с одним из структурных критериев для покрытия тех команд, ветвей или маршрутов внутри тела цикла, которые приводят к модификации значения итератора цикла.
Представленная методика позволяет повысить качество ПМ ОЭСК, широко использующих циклические структуры, повысить эффективность процедур контроля качества и снизить трудоемкость тестирования циклов.
Список литературы
1. Еремин С.Н., Малыгин Л.Л., Рачинский Е.В. Оптико-электронные системы контроля. Алгоритмы обработки // Тез. доклад. и сообщ. XIII межвуз. воен.-науч. конф.- Череповец: ЧВИИР. - 1999. - Ч. 2. - С. 21-22.
2. Маейрс Г. Искусство тестирования программ/Пер. с англ. - М.: Финансы и статистика, 1982. - 176 с.
3. Макгрегор Джон, Сайкс Дэвид. Тестирование объектно-ориентированного программного обеспечения. / Пер. с англ. - К.: ООО "ТИД ДС", 2002. - 432 с.
4. Непомнящий В.А., Рякин О.М. Прикладные методы верификации программ / Под ред. А.П. Ершова. - М.: Радио и связь, 1988. - 256 с.
5. Брауде Э. Технология разработки программного обеспечения. - СПб.: Питер, 2004. - 655 с.
