Cтраница 3
Уровни абстракции определяют уровни модулей в программе. На этапе проектирования строится схема иерархии, изображающая эти уровни. По внешнему виду она напоминает организационную схему. Их логическое сходство усиливается тем, чю схема иерархии отражает функции и взаимодействие модулей. Каждый прямоугольник в ней изображает функцию или модуль. [31]
Представленный здесь пример программы на ПЛ / I относится все к той же задаче управления запасами, о которой шла речь в гл. На рис. 8.9 представлена схема иерархии этой программы - более подробная детализация схемы, приведенной в конце гл. [32]
![]() |
Блок-схема начисления удержаний. [33] |
В ней отражены правила начисления удержаний и последовательность их расчета. С другой стороны, схема иерархии, приведенная на рис. 2.4, описывает лишь функции и их взаимосвязь в программе. Проявлена группировка функций, отсутствующая на блок-схеме. Каждое удержание выделено в самостоятельный модуль, и все они являются детализацией более общего ведущего модуля ВЫЧИСЛИТЬ УДЕРЖАНИЯ. Блок-схема пока-зывает процедуру, схема иерархии - функцию. [34]
Тогда необходимо идти на компромисс и делать реальный вариант схемы иерархии максимально близким к идеальному. [35]
Разработка структурных программ производится за несколько шагов. Это, кратко говоря, 1) нисходящая разработка схемы иерархии; 2) пошаговая детализация модуля с использованием псевдокода и 3) кодирование на некотором языке. [36]
На рис. 5.18 изображена схема иерархии для нашего модуля из четырех сегментов. В отличие от проектирования программы методом сверху вниз, где схема иерархии рисуется до начала программирования, схема сегментов рисуется после появления текста на псевдокоде. [37]
Составляя план тестирования, укажите для каждого модуле, какие именно тесты нужно выполнить. Для некоторых модулей, особенно для тех, которые находятся на вершине схемы иерархии, может потребоваться несколько наборов тестов. Для многих модулей нижнего уровня будет вполне достаточно одного набора тестов. Если возможно, присоединяйте модули по одному и проверяйте их также по одному. [38]
Бывают и исключения из этого правила. Например, для двух модулей нижнего уровня, не связанных друг с другом и находящихся на разных ветвях схемы иерархии, можно скомбинировать тестовые данные так, чтобы один тест проверял сразу оба модуля. Другое исключение - когда присоединяется модуль, требующий нетривиальной заглушки. Проблема в том, что заглушка сложна и ее программирование может потребовать таких же усилий, как и программирование полного модуля. [39]
После того как контролеры приглашены и ясно, что они могут присутствовать, раздайте им копии контролируемых материалов за несколько дней до начала сессии. Это могут быть описания спецификаций, блок-схемы, проекты форм документов, описания записей и файлов, структура базы данных, схемы иерархии, тексты на псевдокоде или даже листинги программ. Другими словами, большая часть контролируемого материала позднее станет документацией по данному проекту. Изучая материал к сессии, контролеры могут заметить мелкие или типографские ошибки в этих документах, которые вернутся к вам после сессии. Таким путем не только контролируется сама работа, но и отшлифовывается документация до полной завершенности, точности и ясности. Поэтому сквозной контроль создает условия для своевременной выработки документации на тех стадиях разработки, когда это может быть сделано наилучшим образом. [40]
Она легко помогает убедиться в том, что требования и спецификации понимаются обеими сторонами и достигнуто согласие по поводу желаемых результатов. Конец этапа проектирования характеризуется следующими условиями: 1) известно число модулей, 2) связь ( функции и их иерархия) между модулями изображены схемами иерархии, 3) вся выполненная работа проверена пользователями на точность и полноту. [41]
Конформационные характеристики, будучи производными от конфигурационных, вместе с тем напоминают их в том смысле, что здесь тоже имеет место иерархия и соответственно суперпозиция уровней. Кроме того, между конфигурацией и конформацией существует обратная связь: приобретение опред. Ниже приводится схема иерархии конформаций. [42]
Конформационные характеристики, будучи производными от конфигурационных, вместе с тем напоминают их в том смысле, что здесь тоже имеет место иерархия и соответственно суперпозиция уровней. Кроме того, между конфигурацией и конформацией существует обратная связь: приобретение опред. Ниже приводится схема иерархии конформации. [43]
Процесс мысленного выполнения программы может выявить недостатки в проектировании модульной структуры или в документации на модуль. С каждым модулем должно быть связано описание его зависимостей по данным. При ошибке в проектировании следует пересмотреть схему иерархии, при неполной документации или неправильных спецификациях необходимо исправить недочеты до перехода к следующим этапам разработки модуля. [44]
Здесь плановик взвешивает достоинства каждого подхода, определяя конкретную последовательность разработки модулей. Конечно, для одной и той же схемы иерархии возможны различные последовательности. [45]