Логика - модуль
Cтраница 1
Логика модуля - это описание внутреннего алгоритма модуля или описание того, как он выполняет свою функцию. [1]
При проектировании логики модуля необходимо предусмотреть совокупность контрольных мероприятий, обеспечивающих функционирование модуля. Совокупность контрольных мероприятий отождествляется с приемами защитного программирования. Один из принципов защитного программирования состоит в том, что проектировщик обязан предусмотреть контроль правильности входной информации модуля до начала его работы. Действительно, прием неверных входных данных может привести к получению и выдаче неверных, но правдоподобных выходных данных. [2]
При проектировании логики модуля желательный результат - структурная программа, и один из мыслительных процессов называется пошаговой детализацией. [3]
Используется итеративный процесс последовательного усовершенствования логики модуля, начиная с абстрактного определения логики и заканчивая разработкой кода для модуля. Алгоритм проведения работы на данном шаге базируется, как правило, на элементах структурного программирования. [4]
 |
Типичный результат выполнения модуля wkschdl. prg. [5] |
Этот модуль приведен на рис. 9.14. Логика модуля требует одного пояснения. Цель модуля состоит в выявлении наибольшего значения атрибута week для текущего активного файла БД. Так как в оба отношения SCORES и SCHED включено поле week в качестве атрибута, следовательно, одно из этих отношений может быть активировано до обращения к модулю findwk. Если SCORES является активным, то значение week определяется как последняя неделя, для которой результаты встреч были занесены в БД; однако если активным является отношение SCHED, то значение week определяется как последняя неделя сезона. [6]
Остальные три шага проектирования тестов предполагают исследование логики модуля. Один из основных критериев подбора тестов требует, чтобы каждая команда модуля выполнялась хотя бы раз. Это требование определенно необходимо, но останавливаться на этом нельзя. Гораздо лучше убедить тестовика в том, что нужно подготовить достаточно тестов, чтобы каждое разветвление проходилось в результате принятия решения в каждом направлении по крайней мере один раз. Это приводит нас к еще одной аксиоме автономного тестирования. [7]
Три завершающих шага назначения тестовых комбинаций базируются на проверке логики модуля. Для выбираемого множества тестовых комбинаций в качестве критерия полноты может выступать утверждение о том, что - каждая команда контролируемого модуля выполняется хотя бы один раз. Этот критерий необходим, но он не всегда является выполнимым. Лучшим критерием является обеспечение достаточного количества тестовых условий, позволяющих для каждой спроектируемой конструкции i модуля, которая порождает многовариантный переход, прохождение каждой ветви. [8]
Следующий шаг - итеративный, он предполагает последовательную детализацию логики модуля, начиная с достаточно высокого уровня абстракции и заканчивая готовым текстом программы. На этом шаге используются методы пошаговой детализации и структурного программирования, о которых говорится в следующем разделе. [9]
Основное затруднение, с которым может столкнуться читатель при рассмотрении логики модуля teamstd. [10]
Пошаговая детализация представляет собой простой процесс, предполагающий первоначальное выражение логики модуля в терминах гипотетического языка очень высокого уровня с последующей детализацией каждого предложения в терминах языка более низкого уровня, до тех пор пока наконец не будет достигнут уровень используемого языка программирования. На протяжении всего процесса логика выражается основными конструкциями структурного программирования. [11]
Итак, можно сделать вывод, что самое важное - постраничная организация логики модуля. Сегментировать нужно выполняемые предложения ПЛ / I. Невыполняемые предложения, подобные DECLARE, группируются вместе и могут как делиться, так и не делиться на отдельные страницы. [12]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [13]
Когда вместо псевдокода используют блок-схемы, следуют тем же принципам расширения и структурирования логики модуля. Однако как только подготовлена очередная детализация, представляющие ее блоки должны быть поставлены на место расширяемого элемента блок-схемы. Следовательно, необходимо каким-то образом отражать такую замену. Действуя в лоб, можно просто перерисовывать всю блок-схему после каждого прохода. [14]
Необходимо отличать внешнюю спецификацию модуля от другой документации, такой, как описание логики модуля, так как логика модуля может изменяться без воздействия вызывающих модулей, а изменение внешних спецификаций модуля обычно приводит к изменениям в вызывающих модулях. Внешняя спецификация модуля может принимать ряд физических форм в зависимости от включения шести перечисленных выше категорий. [15]
Страницы: 1 2 3