Модуль - нижний уровень
Cтраница 2
Оба метода обладают как достоинствами, так и недостатками. При использовании метода нисходящего проектирования практически до его завершения остаются неизвестными размер программы и ее эксплуатационные характеристики, так как они определяются в основном модулями нижнего уровня. Кроме того, на последних этапах проектирования может возникнуть необходимость в структурных изменениях, требующих пересмотра уже разработанных модулей верхнего уровня. А в методе восходящего проектирования принципиальные ошибки в проекте модулей нижнего уровня будут выявлены лишь на заключительной стадии работ. [16]
 |
Типовой аппаратурный модуль химического синтеза. [17] |
Таким образом, модульный принцип аппаратурного оформления гибких технологических систем состоит в том, что разрабатываются модули различных уровней иерархии. Модули са - о го нижнего уровня представляют собой легко заменяемые конструкционные элементы технологических аппаратов. Из модулей нижнего уровня компонуют аппараты, которые, в свою очередь, являются модулями следующего уровня иерархии. Они имеют необходимые средства для коммутации с другими аппаратами. Комбинируя эти аппараты, формируют аппаратурные модули в виде простейших, как правило, одностадийных химико-технологических систем. Из аппаратурных модулей подобным же образом формируют аппаратурные блоки или химико-технологические системы любой сложности. [18]
При проверке программ снизу вверх наиболее существенные особенности заключены в имитации среды. Здесь приходится имитировать программную составляющую среды верхнего уровня, иными словами, создавать специальную программу, управляющую работой проверяемого модуля. Чаще всего модуль нижнего уровня обрабатывает данные, не являющиеся входными для всей задачи, что требует имитации входных данных для модуля, в том числе и с помощью специальных программ. Проблема состоит в том, чтобы перечисленные средства имитации среды не оказались того же порядка сложности, что и проверяемые программы. Если средства имитации оказываются сложны, то они сами требуют проверки, и такая работа оправдана только в случае их многократного использования. [19]
Составляя план тестирования, укажите для каждого модуле, какие именно тесты нужно выполнить. Для некоторых модулей, особенно для тех, которые находятся на вершине схемы иерархии, может потребоваться несколько наборов тестов. Для многих модулей нижнего уровня будет вполне достаточно одного набора тестов. Если возможно, присоединяйте модули по одному и проверяйте их также по одному. [20]
Программа представляется в виде иерархии модулей. Модули верхнего уровня выполняют более общие функции и вызывают модули нижних уровней, в которых детализируется решение задачи. В свою очередь, например, модуль опроса датчиков разбивается на модули нижнего уровня, в которых определяется номер датчика, читаются данные из его регистров, происходит их перекодировка. [21]
 |
Иерархия модулей системы управления объектом. [22] |
Метод подобен процессу получения все более детального изображения предмета из его общего вида путем применения все более сильного увеличения. В данном методе сначала кодируются, тестируются и отлаживаются модули самого верхнего уровня. При этом, чтобы как можно раньше начать проверку работоспособности системы, вместо модулей нижнего уровня, еще детально не разработанных, используются заглушки. Заглушка - это очень простой по структуре модуль, в котором входные и выходные данные соответствуют замещаемому модулю, но алгоритм обработки данных упрощен. Часто в заглушке помимо описания входных и выходных данных присутствует один оператор печати, сообщающий, что в этом месте программы вызывается заглушка. Применение метода нисходящего проектирования основано на пошаговом уточнении решения задачи. Начиная с верхних, самых общих шагов на каждом следующем происходит все большее уточнение функций, выполняемых программой, до полной их реализации. Основное преимущество метода пошагового уточнения состоит в том, что при его использовании основное внимание обращается на проектирование правильной программы, а не только на детальное понимание всей задачи. Если первый этап проектирования корректен, то каждый последующий этап является лишь уточнением предыдущего с небольшими изменениями. На этом основании легко может быть выполнена проверка корректности процесса разработки программы на всех этапах. [23]
На этапе проектирования ППП МИС позволяет описать общую структуру пакета: используемые структуры данных и взаимосвязи между ними. С помощью такого описания, используя реализуемые системой возможности автоматического синтеза программ, разработчик может получить алгоритмы решения типовых задач и проверить, соответствует ли проект спецификациям пакета. Таким образом, МИС поддерживает технологию разработки сверху вниз, позволяя гарантировать корректность алгоритма решения задачи, до того как будут разработаны модули нижнего уровня. [24]
Модульность построения приводит к использованию иерархической структуры взаимодействия модулей программы. Иерархические структуры системы характеризуются, с одной стороны, вертикальным управлением, когда модули верхнего уровня имеют право вмешательства и координирования работы модулей нижнего уровня. [25]
В методе восходящего проектирования, наоборот, в первую очередь разрабатываются модули самого нижнего уровня. Эти модули, работоспособность которых уже проверена, включаются в разрабатываемые модули более высокого уровня. При таком подходе не требуется писать лишних программ заглушек, однако работоспособность модуля верхнего уровня можно проверить только после разработки и отладки модулей нижнего уровня. На их базе проектируются вызывающие их модули 1 и 2, которые также проверяются отдельно друг от друга, но совместно с вызываемыми модулями 1.1, 1.2 и 2.1. Последней создается головная программа. [26]
Оба метода обладают как достоинствами, так и недостатками. При восходящем методе разработки принципиальные ошибки в проекте модулей верхнего уровня будут выявлены лишь на заключительной стадии работ. При использовании нисходящего метода разработки практически до ее завершения остаются неизвестными размеры программы и ее эксплуатационные характеристики, так как они определяются в основном модулями нижнего уровня, а следовательно, остаются нерешенными и все связанные с ними вопросы. Применение обоих методов связано: разработкой дополнительных программ для проведения тестирования. На практике обычно наилучшие результаты дает сочетание обоих методов, при котором вначале создаются модули я верхних, и критичных нижних уровней с использованием заглушек для имитации менее существенных для характеристик программы модулей, разрабатываемых впоследствии. [27]
 |
Концентрические кольца защиты системы Multics. [28] |
Может быть, это покажется несколько странным, но появившаяся недавно тенденция к структурному и функциональному упрощению ядер частично объясняется повышением требований, предъявляемых к операционным системам в целом. Если среда выполнения предназначена только для непосредственного обслуживания запросов прикладных программ, то скорее всего следует обеспечить высокоуровневые интерфейсы и большие функциональные возможности. Если же порядок использования операционной системы меняется и прикладные программы все чаще и чаще начинают обращаться к системе со специфическими запросами, возникающими как следствие работы в режиме диалога и применения специальных средств обработки транзакций, то логично включить в модули нижнего уровня меньшее число функций. В какой-то мере ситуация с ядром напоминает ситуацию с системой машинных команд. Чем изощреннее становится программирование и чем выше наши требования к машине, тем выгоднее оказывается обеспечивать лишь примитивные команды, возлагая всю фактическую нагрузку на компиляторы. [29]
При восходящем тестировании прежде всего проверяются модули нижних иерархических уровней. Затем тестированию подвергаются вызывающие их модули и так до главного модуля. Основные трудности состоят в необходимости обновления тестовых данных при подключении каждого нового модуля более высокого уровня. Однако все модули нижнего уровня тестируются детально и независимо, что устраняет значительное число ошибок при подключении их к вызывающим модулям. [30]
Страницы: 1 2 3