CC BY
48
УДК 681.3
РАЗРАБОТКА ПРИКЛАДНЫХ ПРОГРАММ ДЛЯ БАЗ ДАННЫХ
С.В. Зыкин
In this article the technology of development of the applied programs for corporate databases is considered. The technology contains conventional components: documenting, testing and support of the software. All these components are considered from the point of view of specific character of work with databases.
Введение
Действующие в настоящее время стандарты достаточно жестко регламентируют состав и структуру документации на программное обеспечение, оформление результатов тестирования и сопровождения готовых программных систем.
В соответствии с ГОСТами регламентируются требования: 1) для описания проектных решений по программному обеспечению; 2) для установления требований к комплексу программ; 3) для описания решений, обеспечивающих сопровождение, изготовление и эксплуатацию комплекса программ; 4) для проверки работоепоеобноети комплекса программ.
В этих же ГОСТах регламентируется структура каждого документа, который должен содержать вводную часть и разделы: 1) структура программного обеспечения; 2) основные функции частей программного обеспечения; 3) методы и средства разработки программного обеспечения; 4) операционная система; 5) средства, расширяющие возможности операционной системы. Кроме того, для каждого из разделов документации приводятся специфические требования к их содержанию.
Необходимо отметить, что регламентируя структуру и содержание документации, ГОСТы оставляют открытым вопрос о способе достижения той или иной цели. Другими словами, ГОСТы дают ответ на вопрос «что надо сделать» и оставляют открытым вопрос о том «как это надо делать».
Ответу на вопрос «как это надо делать» посвящена данная работа. В ней рассмотрены специализированные вопросы разработки, документирования, тестирования и сопровождения программного обеспечения информационных систем на основе баз данных. Специализация заключается в том, что акцент делается на описание данных, представленных в программах в виде переменных,
© 2001 С.В. Зыкин
E-mail: zykin@iitam.omsk.net.ru ОФИМ СО РАН
а не на алгоритмы, которые в случае информационных систем в большинстве своем являются прозрачными, В работе преднамеренно опускается вопрос проектирования информационных систем, поскольку это наиболее проработанное направление, которому посвящено огромное количество публикаций,
1. Документирование программ
Цитаты:
«Наилучшей документацией на программное обеспечение является сама программа, содержащая достаточное количество комментариев»,
«Опытные программисты имеют свой стиль программирования, основанный на использовании стандартизованных шаблонов, В организации, занимающейся разработкой программного обеспечения, важно иметь единый стиль программирования»,
«Программист должен комментировать свою программу так, чтобы она была понятна другому программисту».
Последовательность создания документированного программного комплекса должна быть следующей:
- общее проектирование программного комплекса с использованием одной из известных технологий;
- детализация проектных требований вплоть до конкретных комментариев к программам;
- расшифровка комментариев операторами языка программирования.
Другими словами, создается описание системы с уточнением его с заказчиком на ранних стадиях разработки проекта, В последующем это описание детализируется до уровня, достаточного для написания программного кода. То есть, документация на систему должна создаваться раньше самой системы,
1.1. Методическое обоснование подхода к созданию документации
Пространство состояний системы определяется совокупностью значений переменных, с которыми оперирует программное обеспечение. Обозначим: Щ - наименование i-той переменной, / = 1. /к П, область определения i-той переменной (область допустимых значений). Тогда пространство состояний всей системы может быть представлено в виде декартова произведения
£>1 х £)2 х ... х Dn.
В фиксированный момент времени системе соответствует точка в пространстве состояний. Работе системы в течение некоторого времени соответствует некоторая траектория L в пространстве состояний (см, рис, 1),
Не все состояния системы являются допустимыми. Допустимые состояния образуют некоторую область О (рис, 1) в пространстве состояний. Выход траектории L за пределы этой области соответствует ошибочной работе программного обеспечения. Приложение, работающее с базой данных, всякий раз начинает
D2
Рис. 1. Пространство состояний переменных
работу с различных состояний, поскольку поля базы данных также являются переменными и в процессе эксплуатации БД их значения изменяются.
Проблема корректности работы программного обеспечения в данном случае интерпретируется как проблема корректного прохождения траектории в пространстве состояний. Корректность проекции траектории на переменные, соответствующие полям БД, в настоящее время реализуется средствами СУБД (ограничения целостности). Следовательно, актуальной является проблема корректности поведения прикладной программы в процессе модификации значений других переменных.
1.2. Описание переменных и программ
Алгоритмы обработки данных при работе с базами данных обычно бывают несложными. Комментирование блоков операторов, реализующих какую-либо одну функцию, обычно является достаточным для понимания текста программы. А использование некомментированных переменных и структур способно ввести в заблуждение даже самого разработчика, если он некоторое время не работал с программой. Этот эффект усиливается за счет возможностей объект-но-ориетированного программирования. А именно, за счет механизма наследования.
Таким образом, при документировании особое внимание необходимо уделять переменным и структурам.
Описание программного модуля (головной программы, процедуры, функции) должно включать следующие компоненты:
- содержательное назначение модуля;
- перечень с описанием входных параметров;
- перечень с описанием выходных параметров;
- наименование точки входа;
- наследованные объекты с описанием их компонент;
- дата написания программы и ФИО программиста;
- дата изменения программы и ФИО программиста.
Описание переменных и структур:
- имя переменной (структуры);
- тип переменной;
- описание содержательного смысла переменной;
- область значений переменной;
- правило формирования значений переменной;
- особые значения переменной (если есть).
Для неоднозначных смысловых значений (в цикле):
- имя переменной;
- тип переменной;
- содержательный смысл переменной;
- подобласть значений переменной;
- правило формирования значения переменной;
- особые значения переменной (если есть).
Примечание, Имя переменной и тип задаются средствами языка программирования, и не требуется дополнительное дублирование их описания. Кроме того, эти пункты нет необходимости именовать в описании, поскольку они являются обязательными практически во всех инструментальных средствах разработки приложений. Для однозначного восприятия описания без именования можно оставить еще один пункт: содержательный смысл переменной,
1.3. Примеры описания переменных
1, Простые переменные (на примере целочисленных):
- EmployeeBirthYear;
- Integer;
- год рождения сотрудника предприятия;
- область значений: интервал (CurrentYear-70 ,, CurrentYear-15), где CurrentYear - значение функции Year();
- правило формирования значений переменной: нет;
- особые значения: нет,
2, Символьные переменные:
- EmploveeName;
- char;
- фамилия имя отчество сотрудника учреждения;
- область значений переменной: строчные символы русского алфавита, символ «пробел», максимальная длина переменной: 30 символов;
- правило формирования значений переменной: символ «пробел» не может быть первым символом в строке и не может быть более одного подряд идущего символа «пробел», за исключением конца строки;
- особые значения переменной: нет,
3, Массивы:
- ListFaetors;
- аггау[1..21] of Real;
- коэффициенты вычисления оклада по ЕТС;
- область значений элементов массива: 00,0 ,, 99,9;
- правило формирования значений переменной: i-тый элемент массива равен i-му коэффициенту разрядной сетки ЕТС;
- особые значения переменной: нет,
4, Записи:
- employees;
- record;
- базовая информация о сотруднике предприятия;
- область значений неоднозначна: определяется компонентами;
- правило формирования значений неоднозначно: определяется компонентами;
- особые значения переменной: нет,
5, Для неоднозначных смысловых значений (в цикле):
- TabNum;
- Integer;
- табельный номер сотрудника;
- подобласть значений переменной: 1 ,, 9999;
- правило формирования значения переменной: нет;
- особые значения переменной: нет,
- EmploveeName;
- char;
- фамилия имя отчество сотрудника учреждения;
- область значений переменной: строчные символы русского алфавита символ «пробел», максимальная длина переменной: 30 символов;
- правило формирования значений переменной: символ «пробел» не может быть первым символом в строке и не может быть более одного подряд идущего символа «пробел», за исключением конца строки;
- особые значения переменной: нет,
- Datelntroduetion;
- Date;
- дата устройства на работу;
- подобласть значений переменной: 01,01,1950 ,, «текущая дата»;
- правило формирования значения переменной: правильность контролируется системным программным обеспечением;
- особые значения переменной: нет.
Замечание. Описание объектного типа осуществляется по аналогии с описанием записи. Если компонент в описании является полем, то для него расписывается циклическая группа, как для неоднозначных значений. Если компонент в описании является методом, то выполняется переход к описанию функции (процедуры).
Предлагаемый подход позволит не только избежать большинства ошибок в программах, но и организовать корректное тестирование и сопровождение программного обеспечения.
2. Тестирование программного обеспечения
Проблема тестирования программного обеспечения имеет длительную историю. Первые систематизированные обобщения по этой тематике появились в работах [1,2]. Обращает на себя внимание оптимизм Майерса: «Еще одна причина, по которой трудно говорить о тестировании, - это тот факт, что о нем известно очень немногое. Если сегодня мы располагаем 5% тех знаний о проектировании и собственно программировании (кодировании), которые будут у нас к 2000 г,, то о тестировании нам известно менее 1%»,
К сожалению, приходится констатировать, что существенного изменения ситуации в данной области не произошло. Если в части развития инструментальных средств программирования можно отметить существенный прогресс, то в части создания и развития инструментальных средств тестирования программного обеспечения (промышленные варианты) принципиальных изменений не наблюдается. Возможной причиной этого является то, что инструмент для тестирования зависит от систем программирования, которые в последнее время меняются практически ежегодно. По финансовым соображениям фирмы-разработчики инструментального программного обеспечения не заинтересованы в развитии соответствующих средств тестирования. Экономически более целесообразно немного модифицировать средство программирования, дополнив к нему некоторые функции, и как можно быстрее выставить его на рынок программного обеспечения. Такой продукт сам, как правило, содержит множество ошибок, а о развитии средств тестирования в нем и речи не идет, В лучшем случае в составе инструментария есть «трассирующий» компилятор-отладчик, который проблем тестирования не касается, поскольку отладка не является разновидностью тестирования. Тестирование - деятельность, направленная на обнаружение ошибок; отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки,
2.1. Принципы тестирования
«Эпидемия ускоренной разработки продуктов началась примерно десять лет назад. Сторонники формального подхода отстаивали идею сокращения циклов разработки за счет совершенствования методологии, без снижения качества. Однако, по мнению экспертов, ускорение часто происходило в ущерб тщательности тестирования или требовало сверхурочной работы сотрудников» [5]. Вопреки существенным затратам на тестирование в организациях, занимающиеся созданием программного обеспечения, большинство программных продуктов неприемлемо ненадежно даже после «основательного тестирования» [2]. Причиной тому является игнорирование принципов тестирования, В большинстве случаев под тестированием понимается следующее: «Тестирование - процесс, подтверждающий правильность программы и демонстрирующий, что ошибок в программе нет». Однако, правильный подход заключается в том, что: «Тестирование - процесс выполнения программы с намерением найти ошибки». Тестирование - процесс разрушительный, так как цель проверяющего - заставить программу сбиться. Успех заключается в обнаружении как можно большего ко-
личества ошибок, С другой стороны, ограничением является то, что надежность невозможно внести в программу в результате тестирования, она определяется правильностью этапов проектирования. Наилучшее решение проблемы надежности - с самого начала не допускать ошибок в программе.
Таким образом, критерием качественного теста является наибольшая вероятность обнаружить все возможные ошибки. Невозможность достижения абсолютной правильности (надежности) программ обсуждается далее.
Рассмотрим виды ошибок программирования [1], которые имеют место при работе с базами данных:
1, Неправильная постановка задачи: правильное решение неверно сформулированной задачи,
2, Семантические ошибки: непонимание порядка выполнения команды,
3, Синтаксические ошибки: нарушение правил, определяемых языком программирования,
4, Ошибки в данных: неудачное определение возможного диапазона изменения данных,
5, Ошибки в документации: документация пользователя не соответствует действующему варианту программы (программы не удовлетворяют некоторым требованиям, но эти требования не были сформулированы в задании на разработку программы).
Замечание. Кроме перечисленных ошибок существует еще ошибки физического характера: искажение программного кода на физическом уровне.
Для обнаружения перечисленных ошибок в [2] предлагаются следующие виды тестов:
1, Тестирование модуля, или автономное тестирование (module testing, unit testing) - контроль отдельного программного модуля, обычно в изолированной среде,
2, Тестирование сопряжения (integration testing) - контроль сопряжения между частями системы (модулями, компонентами, подсистемами),
3, Тестирование внешних функций (external function testing) - контроль внешнего поведения системы, определенного внешними спецификациями,
4, Комплексное тестирование (system testing) - контроль и/или испытание системы по отношению к исходным целям,
5, Тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя,
6, Тестирование настройки (installation testing) - проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.
Рассмотренный порядок тестирования ориентирован на технологию разработки программного обеспечения «снизу вверх» или «модульное программирование», Метод «снизу вверх» предполагает первоначальное написание и проверку модулей с самого нижнего уровня. Затем программируются и тестируются элементы более высокого уровня и так далее до тех пор, пока не будет завершено написание всей программы. Однако, наиболее распространенным способом
проектирования и разработки программного обеспечения является метод «сверху вниз». Метод тестирования «сверху вниз» является дополнительным этапом проектирования сверху вниз, сквозного контроля и кодирования «сверху вниз». При этом сначала пишется головная программа, а ^запрограммированные модули более низкого уровня заменяются имитирующими их «заглушками». Разработанный модуль тестируется. Далее «заглушки» заменяются соответствующими программными модулями, которые тестируются совместно е программами верхнего уровня.
Второй метод тестирования обладает неоспоримыми преимуществами по сравнению е первым:
1, Тестовые данные накапливаются как единое целое для всего программного комплекса, а не раздельно, как в первом случае,
2, Спецификации на программное обеспечение, логика управления программным комплексом и интерфейсы начинают тестироваться на начальных этапах и затем многократно этот процесс повторяется. При раздельном тестировании логика и интерфейсы тестируются на последнем этапе, что может привести к необходимости переписывания уже разработанных методов,
2.2. Подходы к организации тестирования
Тестирование программ аналогично последовательности процессов разработки программного обеспечения. Сюда входят постановка задачи для теста, проектирование, написание тестов, тестирование тестов и, наконец, выполнение тестов и изучение результатов тестирования. Решающую роль играет проектирование теста.
Рассмотрим два подхода (метода) к организации тестирования.
Подход 1, Тестирование спецификации компонента делается, в основном, по принципу тестирования «черного ящика» и выполняется в течение всей разработки, Даже интегральное тестирование начинается на ранних стадиях разработки, Экземпляры различных классов объединяются непрерывно в течение процесса разработки. Планирование тестов должно быть сделано на ранней стадии вместе с идентификацией тестов, В этом случае не важно как выглядит эта программа и выполняются ли все команды или все пути. Цель считается достигнутой, если программа будет вести себя так, как указано в спецификациях, Способ организации тестирования - проверка всех возможных комбинаций и значений на входе.
Подход 2, Компонентное тестирование выполняется по принципу «белого ящика». Это означает, что используются знания о внутреннем устройстве компонента, Могут быть использованы различные критерии покрытия для тестов, минимальный из которых покрывает все операторы текста программы. Однако критерии покрытия бывает трудно определить из-за полиформизма, когда многие ветвления управления в объектно-ориентированных программах происходят неявно. Использование наследования также усложняет тестирование, поскольку приходится заново тестировать операции на различных уровнях иерар-
хии наследования. Тем не менее, полиформизм повышает независимость объектов, делая их легче тестируемыми, как отдельные части. Другими словами, тесты проектируются на основе изучения логики программы, В этом случае подготавливается достаточное число тестов для того, чтобы каждая команда была выполнена по крайней мере один раз, В более сложном случае, тесты проектируются так, чтобы каждая команда условного перехода выполнялась в каждом направлении хотя бы раз. Цель - проверить каждый путь, каждую ветвь алгоритма. При этом совсем (или почти совсем) не используются спецификации.
Заметим, что ни один из этих подходов не гарантирует обнаружения всех возможных ошибок, С одной стороны, тестирование по методу «черного ящика» может иметь огромное количество возможных комбинаций внешних параметров, С другой стороны, тестирование по методу «белого ящика» может иметь огромное количество возможных путей выполнения программы, В том и другом случае осуществить перебор всех возможных комбинаций не представляется возможным. Ситуация усугубляется для метода «черного ящика», если программные комплексы сохраняют «память» о предыдущих входных данных, а таковыми и являются программы для работы с базами данных. Потребовалось бы тестировать программу не только для каждого входного значения, но и для каждой последовательности, каждой комбинации входных данных. Предположим, что по методу «белого ящика» все возможные пути программы проверены, Однако это не дает основания для утверждения, что программа работает правильно. Основанием для этого заключения служит то, что выполнение всех путей не гарантирует соответствия программы ее спецификациям.
Таким образом, тестирование - проблема экономическая. Поскольку исчерпывающее тестирование невозможно, необходимо ограничиться чем-то меньшим, Каждый тест должен давать максимальную отдачу по сравнению с затратами, Эта отдача измеряется вероятностью того, что тест выявит не обнаруженную прежде ошибку. Затраты измеряются временем и стоимостью подготовки, выполнения и проверки результатов теста. Во всех случаях затраты на тестирование ограничены бюджетом и временем на разработку. Поэтому тестирования представляет собой искусство отбора тестов с максимальной вероятностью обнаружения ошибки. Более того, каждый тест должен быть представителем некоторого класса входных значений так, чтобы его правильное выполнение создавало некоторую убежденность в том, что для определенного класса входных данных программа будет выполняться правильно. Это обычно требует некоторого знания алгоритма и структуры программы, то есть второго метода в комплексе с первым.
Приведем замечание по поводу объектно-ориентированных (00) технологий [4]: «00 технология - это прежде всего - архитектурная дисциплина в том смысле, что она позволяет сфокусироваться на высокоуровневой структуре программной системы, издаваемой как сеть сотрудничающих агентов-объектов, между которыми определены только два отношения: поставщик-клиент и родитель-наследник. Именно эти поистине драконовские ограничения обеспечивают то критическое свойство системы, которое Ф,Брукс назвал
концептуальной целостностью (conceptual integrity). При этом уходят от таких понятий, как «основная программа», «глобальные переменные», «проектирование сверху-вниз» и т.п., предполагающих, что система обязательно имеет некий центр». Это достаточно тенденциозное высказывание на самом деле не противоречит технологии разработки программного обеспечения «сверху вниз». Прежде всего, данная технология предполагает в качестве начала разработку программных модулей, реализующих внешние (пользовательские) спецификации, Таких модулей может быть несколько, но они всегда существуют,
2.3. Организация процесса тестирования
Исходя из рассмотренного материала сформулируем требования к организации процесса тестирования, используя рекомендации из [2].
1, Тест должен обладать высокой вероятностью обнаружить ошибку, а не демонстрировать правильную работу программы,
2, Определяется конечное число тестов, которые дают максимальную вероятность обнаружения ошибок при фиксированном количестве затрат,
3, Программист будет плохо тестировать свою собственную программу, поскольку это процесс разрушительный,
4, Необходимая часть всякого теста - описание ожидаемых выходных данных или результатов. Ожидаемые результаты нужно определять заранее, чтобы не возникла ситуация, когда «глаз видит то, что хочет увидеть»,
5, Тесты следует документировать и хранить в такой форме, чтобы каждый мог использовать их повторно,
6, Тесты должны быть как для правильных, так и для неправильных входных данных. Многие ошибки, которые неожиданно обнаруживаются в работающих программах, проявляются вследствие неверных действий пользователя программы. Тесты, представляющие неожиданные или неправильные входные данные, часто лучше обнаруживают ошибки, чем «правильные» тесты,
7, Детально изучите результаты каждого теста. Самые изощренные тесты ничего не стоят, если их результаты удостаиваются лишь беглого взгляда,
8, По мере того как число ошибок, обнаруженных в некоторой компоненте программного обеспечения увеличивается, растет также относительная вероятность существования в ней необнаруженных ошибок. Этот эффект означает, что ошибки встречаются группами,
9, Тесты, как и всякое программное обеспечение, должны быть спроектированы, реализованы, проверены и, наконец, выполнены,
2.4. Рекомендации
Резюмируя все выше сказанное, предлагается следующий порядок тестирования, Рассмотрим произвольный модуль и соответствующие ему внешние спецификации, Для «внутренних» модулей внешние спецификации определяются вызывающим модулем.
Для области каждой внешней переменной, в том числе унаследованной, определяется несколько значений: 1) вблизи границ области определения,
2) в центре области определения и области особых значений (если они есть),
3) за пределами области определения. Выделенные значения для переменных комбинируются таким образом, чтобы в тестируемом модуле по возможности были покрыты все варианты его выполнения, В крайнем случае, значения переменных комбинируются друг с другом как независимые параметры. Для каждой комбинации переменных определяются ожидаемые значения результатов работы тестируемого модуля, В лучшем случае это точные значения переменных с соответствующим комментарием, в худшем - только текстовое описание. Все перечисленные в данном разделе варианты с их обоснованием необходимо оформить в виде файла - протокола тестирования, который будет являться частью документации на систему.
Замечание. Для организации процесса тестирования иногда предлагаются методы планирования эксперимента, обеспечивающие статистическую достоверность получаемых результатов, В данном случае использование этих методов приведет к увеличению затрат на разработку теста и времени тестирования, хотя результат будет хуже, чем тестирование на основе знаний о специфике тестируемого модуля.
Далее разрабатывается тестовая программа, в которой организуется вызов тестируемого модуля с различными комбинациями внешних переменных. Если значения переменных определяются в процессе диалога с пользователем, то желательно автоматически генерировать их значения с использованием эмуляции функций устройств ввода (клавиатура, мышь и т,д,). Исполняющая среда обычно содержит такие функции, поскольку они полезны не только для тестирования, но и для организации более дружественного интерфейса, В случае преднамеренного генерирования ошибочных ситуаций исполняющая среда может очистить буфера устройств ввода информации (для текущего окна в Windows), В этом случае тестирующая программа должна перехватить и обработать соответствующее событие (оно должно быть предсказуемым).
После подготовки тестовой программы осуществляется ее выполнение в пакетном режиме. Если ожидаемые результаты заданы точно, то результаты тестирования проверяются автоматически в тестовой программе, В противном случае результаты тестирования вместе с ожидаемыми результатами выводятся в файл (протокол тестирования) и далее анализируются с подстановкой соответствующего комментария для каждого результата выполнения тестируемого модуля. Если в модуле есть вызовы неразработанных программ, то на месте обращения к ним вставляются заглушки, выдающие правдоподобные данные. Если работа модуля сильно зависит от работы отсутствующих программ (заглушка по сложности эквивалентна самой программе), то перед тестированием модуля разрабатываются и отдельно тестируются программы. Только после этого тестируется исходный модуль, в котором вместо заглушки вставлен вызов реальной программы.
При обнаружении ошибки на завершающих этапах разработки, либо в процессе эксплуатации тестирование осуществляется снизу вверх: от исправленного
модуля последовательно ко веем предкам данного модуля,
3. Сопровождение программного обеспечения
3.1. Цикл жизни разработки
Все системы меняются в течение своего цикла жизни. Это нужно учитывать при разработке систем, которые предполагают существование более чем одной версии, что относится практически ко всем системам. Большинство методов разработки сегодня концентрируются на последней версии, лишь кратко рассматривая работу по ревизии, хотя известно, что изменения составляют самую большую часть общего цикла жизни большинства систем, а первая версия системы представляет лишь малую часть затрат всех ресурсов разработки. Истинно промышленный процесс, следовательно, должен концентрироваться на изменениях системы.
Система обычно разрабатывается через изменения в некотором числе версий, Первая версия устанавливает архитектурную основу системы, которая должна сохраняться в течение всей последующей разработки. Ошибочная основа будет иметь серьезные последствия для цикла жизни системы.
Заслуживает внимания подход из [6], в котором используется коммерческий пакет Lotus Notes, дополненный компонентом LIGHT, Этот подход позволяет решить проблему связывания различных компонент системы и организовать их совместное сопровождение,
3.2. Требования к сопровождению
При разработке прикладного программного обеспечения, имеющего множество внедрений (множество заказчиков) или инструментальных средств генерации приложений, для обеспечения функции сопровождения необходимо хранить:
1) все версии поддерживаемых программных систем (находящихся в эксплуатации) ;
2) рабочие версии или инсталляции исполняющих сред (в том числе операционных систем), которые использовались при разработке прикладных систем;
3) для каждого заказчика необходимо хранить параметры настройки на операционную среду.
Для каждой версии программной системы должны храниться следующие компоненты:
а) полный набор исходных текстов программ для текущей версии системы (содержанием которой в основном будет документация на программное обеспечение);
б) библиотеки специализированных объектов;
в) тестирующие модули (все, а не только для внешних спецификаций);
г) инструкции пользователя, прикладного программиста, системного программиста, администратора системы.
Замечание. Между компонентами, указанными в пунктах а), б) и в), должно быть установлено соответствие, например как в [6]. При переходе к разработке новой версии прикладной системы старая версия должна быть полностью сохранена без каких-либо изменений.
Например, для СУБД ORACLE предполагается совместное использование и обслуживание следующих компонент:
1) совместно используемые процедуры;
2) совместно используемые пакеты;
3) скрипты на создание объектов БД;
4) каталоги с исходными текстами модулей (в том числе и тестирующих);
5) файлы помощи;
6) описания программ, библиотек для программистов;
7) руководства пользователей;
8) тексты с описаниями модулей;
9) параметры инициализации;
10) параметры настройки;
11) параметры ресурсов.
Параметры настройки профилей и пр. являются индивидуальными для каждой группы разработчиков и взаимному согласованию не подлежат.
В самом простом случае - без использования дополнительных инструментальных средств, в том числе и репозитария, рекомендуется у каждого администратора в каталоге «Сопровождение» хранить 12 текстовых файлов сопровождения (один на каждый пункт 1 - 12), в которых первая строка содержит полный путь до сопровождаемой группы компонентов (для параметров указывается группа параметров). Далее для каждого компонента создается следующая строка:
«наименование компонента» - «признак занятости компонента», где «признак занятости компонента» принимает значение идентификационных данных программиста, который в настоящее время занимается модификацией компонента, пусто - в противном случае.
Используя информацию из файлов сопровождения, достаточно легко можно синхронизировать работу коллектива программистов по сопровождению системы, если даже доступным средством связи является только электронная почта.
Приложение
Пример программного модуля, разработанного по рекомендуемой технологии.
Данный пример реализует простейшую функцию работы с простейшей базой данных (для краткости и наглядности изложения). Для формирования текста программы использован некий алгоритмический язык, близкий к языкам Pascal и PL\SQL, в котором отсутствуют операторы обработки специфики реализации конкретного языка.
{ Содержательное назначение модуля: организация пользовательского интерфейса с базой данных для модификации сведений о сотрудниках предприятия.
Модуль предназначен для работы со следующей схемой:
Сотрудники (employees) [табельный номер сотрудника (TabNum),
ФИО еотрудника(ИО)], переменные employees, TabNum и FIO по умолчанию считаются глобальными (внешними)}
{Входные параметры: нет}
{Выходные параметры: нет}
{Наименование точки входа: EmployeeListQ}
{Наследованный метод: function EmploveeName(FIO: String): String;
- произвольную строку FIO приводит к строчному виду: удаляет пробелы в начале строки и совокупность пробелов заменяет одним пробелом в середине строки)
{Дата написания программы: 12,08,87 ФИО программиста: Иванов И,И,}
{Дата изменения программы: 11,06,95 ФИО программиста: Петров И,И,}
{Дата изменения программы: 30,12,1999 ФИО программиста: Сидоров С,С,}
program EmployeeListQ
unit WriteL, ReadL, IventW, UpStr, WritRea;
uses Windows, Messages, ,,,, EmploveeName;
declare
employ = object employ - базовая информация о сотруднике предприятия; область значений неоднозначна: определяется компонентами; правило формирования значений неоднозначно: определяется компонентами; особые значения переменной: нет,
TabNum: Integer; табельный номер сотрудника; подобласть значений переменной: 1 ,, 9999; правило формирования значения переменной: нет; особые значения переменной: нет; function EmploveeName (FIO: String): String;
{фамилия имя отчество сотрудника учреждения; область значений переменной: строчные символы русского алфавита, символ «пробел», максимальная длина переменной: 30 символов; правило формирования значений переменной: символ «пробел» не может быть первым в строке и не может быть более одного подряд идущего символа «пробел», за исключением конца строки; особые значения переменной: нет;}
end
begin
declare
StrName: String; {переменная для ввода строки с ФИО сотрудника для поиска в БД;
правило формирования значения переменной: нет; особые значения переменной: нет;}
end
StrName=ReadL() {чтение строки ввода е экрана, воспринимаются два события "Enter" — строка введена, "Esc" — отказ от ввода сроки} iflventWQ = "Enter"
StrName = UpStr(StrName) {преобразование в строчные символы} select * into employ from employees where FIO = StrName if COUNT(*) = 1 then
WritRea(employ) {вывод записи для редактирования на экран} update * into employ from employees where FIO = StrName else
WriteL(«3anHCB не найдена») end if; end if;
end.
Пример организации тестирования модуля EmployeeListQ Содержание файла-протокола тестирования.
Заголовок: { Содержательное назначение модуля: организация пользовательского интерфейса е базой данных для модификации сведений о сотрудниках предприятия.
Модуль предназначен для работы со следующей схемой:
Сотрудники (employees) [табельный номер сотрудника (TabNum),
ФИО сотрудника(ЕЮ)], переменные employees, TabNum и FIO по умолчанию считаются глобальными (внешними)}
{Входные параметры: нет}
{Выходные параметры: нет}
{Наименование точки входа: EmployeeListQ}
{Наследованный метод: function EmployeeName(FIO: String): String;
- произвольную строку FIO приводит к строчному виду, удаляя пробелы в начале строки, и совокупность пробелов заменяет одним пробелом в середине строки).
Комментарий к выбору комбинаций значений управляемых переменных: внешними переменными для данного модуля являются поля отношения employees: TabNum и FIO, кроме того, в режиме диалога тестируемая программа запрашивает строку - значение модифицируемой фамилии сотрудника с использованием функции ReadL(), которая обрабатывает два события: "Enter" — строка введена, "Esc" — отказ от ввода строки. Переменная FIO может принимать новое значение. При редактировании записи возникают события: "Enter" — редактирование выполнено, "Esc" — отказ от редактирования. Таким образом, имеется четыре управляемых переменных для тестирования: «строка» - поисковое значение, «т-еобытие1» - тип события при вводе поискового значения, «FIO»
- новое значение фамилии, «т-еобытие2» - тип события при редактировании фамилии.
Тест 1,
«строка» литвинко «т-еобытие1» «Enter»
FIO литвиненко л,а,
«т-еобытие2» «Enter»
Ожидаемые результаты: в БД должна появиться запись, где FIO = ЛИТВИНКО Л,А, заменена записью FIO = ЛИТВИНЕНКО Л,А,
Результаты выполнения теста: содержимое записи осталось прежним: ЛИТВИНКО Л,А, В программе была выдана диагностика: Запись не найдена. Тест 2,
«строка» литинко «т-еобытие1» «Enter»
FIO литвиненко л,а,
«т-еобытие2» «Enter»
Ожидаемые результаты: содержимое записи должно остаться прежним: ЛИТВИНКО Л,А, В программе должна быть выдана диагностика: Запись не найдена.
Результаты выполнения теста: содержимое записи осталось прежним: FIO = ЛИТВИНКО Л,А, В программе была выдана диагностика: Запись не найдена. Тест 3,
«строка» -«т-еобытие1» «Esc»
FIO
«т-еобытие2» -
Ожидаемые результаты: программа должна завершить работу без диагностики и без изменения БД,
Результаты выполнения теста: программа завершила работу без диагностики и без изменения БД,
Тест 4,
«строка» литвинко «т-еобытие1» «Enter»
FIO
«т-еобытие2» «Esc»
Ожидаемые результаты: запись в БД должна остаться прежней FIO = ЛИТВИНКО Л,А, Отсутствует диагностика.
Результаты выполнения теста: содержимое записи осталось прежним: FIO = ЛИТВИНКО Л,А, В программе была выдана диагностика: Запись не найдена. Замечание. Предложенные четыре теста являются достаточными для отработки всех возможных ситуаций описанных переменных.
Тестирующая программа
Поскольку в тестируемой программе управляемые переменные формируются в режиме диалога, то в тестирующей программе достаточно организовать
циклический вызов без параметров,
{Содержательное назначение модуля: тестирование программы EmployeeListQ,}
{Входные параметры: нет}
{Выходные параметры: нет}
{Наименование точки входа: EmployeeListTestQ}
{Дата написания программы: 12,08,87 ФИО программиста: Иванов И,И,}
{Дата изменения программы: 11,06,95 ФИО программиста: Петров И,И,}
{Дата изменения программы: 30,12,1999
ФИО программиста: Сидоров С,С,}
program EmployeeListTest ()
unit WriteL, ReadL, IventW, UpStr, WritRea;
uses Windows, Messages, ,,,, EmployeeName;
declare
end
begin
declare
Nom: Integer; {переменная для диалогового ввода значения номера теста, е которого начинается тестирование; правило формирования значения переменной: нет; особые значения переменной: нет;}
N: Integer; {переменная цикла;
правило формирования значения переменной: нет; особые значения переменной: нет;}
end
Nom=ReadL() {чтение номера теста е экрана, воспринимаются два события "Enter" — номер введен, "Esc" — отказ от ввода номера} iflventWQ = "Enter"
For N = Nom To 4 EmployeeListTestQ Wait *, "Номер теета=", N Endfor end if;
end.
Порядок тестирования
Одновременно на выполнение запускаются следующие программы:
1) тестирующая программа;
2) просмотр-редактирование файла протокола тестирования;
3) при необходимости, вспомогательная программа анализа тестов (в данном случае - вьювер базы данных).
Данные из файла протокола подаются на вход тестирующей программы и после прохождения теста заполняется раздел: результаты выполнения теста.
Замечание. После выполнения тестовой программы протокол передается программисту для отладки, В приведенном примере предполагалась ошибка не совпадающей кодировки.
Литература
1. Ван Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ. М.: Мир, 1981. 320 с.
2. Майерс Г. Надежность программного обеспечения. М.: Мир, 1980. 367 с.
3. Jacobson I., Christianson М., Constantine L. The OOSE Method: A Use-Case-Driven Approach, http://ns.math.rsu.ru/smalltalk/usecase.ru.html
4. Аджиев В. Объектная ориентация: философия и футурология.
http: //dibr .da.ru/etc/computers / oophil .html
5. Sims D. Сокращение цикла разработки продуктов: за и против // CWM. 1997. V.34. ('.39 15.
6. Рынок программных средств. Технологии оценки качества программных продуктов. http://www.infoart.ru/it/press/cwm/25_96/teh.htm
