Логика - модуль
Cтраница 2
 |
Окончательный результат. [16] |
Эти подробности упоминаются здесь только для того, чтобы читатель понимал особенности нашего загрузчика; в действительности в этот момент не следует интересоваться логикой модуля. [17]
 |
Разбиение ЗАГРУЗИТЬ-ЗАМКН-ПРОГР. [18] |
На следующем шаге нужно взять модули, изображенные на рис. 6.3, и заняться их разбиением. Логику модулей НАСТР-АДР и ВЫДАТЬ-ЛИСТИНГ ( PRODUCE-OUTPUT-LISTING) легко себе представить, поэтому их разбиением мы здесь заниматься не будем. Первым делом рассмотрим его как подлежащую решению задачу и наметим его структуру, как показано на рис. 6.4. Входной поток - множество объектных модулей из ВХФАЙЛ, а выходной поток - объектная программа, в которой замкнуты все внешние ссылки. Точка наивысшей абстракции входного потока - там, где все модули из ВХФАЙЛ размещены в памяти и представлены в ТВИМ и ТПЕРМ. Точка наивысшей абстракции выходного потока находится на самом выходе задачи. [19]
 |
Последовательность микрошагов. [20] |
Биполярные ВИС микропрограммируемого ЦП обычно разделяются на наборы БИС, которые более или менее соответствуют рассмотренным модулям. Большая часть логики модуля тракта данных содержится в нескольких ПЭ, каждый из которых оперирует 2 или 4 битами. Параллельное включение ПЭ обеспечивает обработку нескольких бит, число которых кратно длине слова ПЭ. [21]
Формулируется определение функции или функций, выполняемых модулем. Этот элемент спецификации не должен описывать логику модуля или контекст, в котором модуль используется. [22]
После этого разрабатывается логическая структура модуля и блок-схема алгоритма работы, которая может быть написана либо с использованием языка высокого уровня, например Кобола или Фортрана, либо в виде графического изображения. Последнее всегда проще для понимания работы и логики модуля, чем алгоритмический аналог, поскольку для этого не требуются знания языков высокого уровня. [23]
Внешнее проектирование сводится к решению такой задачи: Переведите множество целей системы во внешние спецификации, где цели - данные, а внешние спецификации - неизвестные. В задаче проектирования логики модуля даны внешние спецификации модуля, а неизвестное - текст его программы. [24]
Эти два шага ведут к процессу проектирования структуры программы, в котором проектируются модули, их сопряжения и взаимосвязи для каждой программы, компоненты или подсистемы. Последний шаг - проектирование логики модуля - состоит в разработке внутренней логики каждого модуля системы, он включает также выражение этой логики текстом конкретной программы. [25]
Традиционным средством документирования является блок-схема, разновидностью которой мы воспользовались, изображая типовые управляющие конструкции. Блок-схемы наглядны и компактны, они позволяют сразу охватить всю логику модуля, но обладают двумя недостатками. Второй недостаток заключается в том, что блок-схема имеет двумерную конструкцию ( потому она и наглядна), а программа, которую надо составлять на ее основе, - одномерную. Поэтому написание программы по блок-схеме требует некоторых дополнительных усилий и чревато появлением ошибок. Проектный документ, лишенный этих недостатков, можно составить, пользуясь языком текстового описания структурированной программы. [26]
Защитное программирование требует разумного подхода, ибо, доведенное до крайности, оно повлечет нежелательные эффекты. Если над входными данными выполнять все мыслимые проверки, защищающая часть программы может стать настолько сложной ( и потому чреватой ошибками), что ее влияние на надежность ( а также на эффективность) будет не позитивным, а негативным. Чтобы решить, сколько защитных проверок оправдано, сначала изучите по логике модуля все предположения о входных данных, которые в нем сделаны, и составьте список всех проверок, которые можно было бы сделать. Для каждой из них оцените ее сложность, вероятность того, что входные данные могут быть ошибочными, и последствия отсутствия проверки. После этого остается принять трудное компромиссное решение по определению того минимума защитной части программы, который обеспечивает максимально возможный уровень обнаружения ошибок. [27]
Первый шаг при проектировании модуля состоит в определении его внешних характеристик. Эта информация выражается в виде внешних спецификаций модуля, которые содержат все сведения, необходимые вызывающим его модулям, и ничего больше. В частности, внешние спецификации модуля не должны содержать никакой информации о логике модуля или о внутреннем представлении данных. Кроме того, спецификации не должны включать каких бы то ни было ссылок на вызывающие модули или на контексты, в которых этот модуль используется. [28]
Теперь, по-видимому, ясно, как возник термин пошаговая детализация. Первый шаг связан с очень общим предложением. Разложение первого общего шага в последовательность шагов второго или более низкого уровня заставляет более точно определить логику модуля - это и есть детализация предыдущей формулировки задачи. Таким образом, хорошо видно, как модуль расширяется по мере добавления и уточнения деталей. Это похоже на проектирование здания - вначале определяется общий замысел, затем проектируются этажи, комнаты и, наконец, решается вопрос об обоях, мебели и деталях конкретных комнат. Конечно, можно было бы спроектировать одну комнату полностью до начала проектирования следующей и проектировать второй этаж только тогда, когда полностью завершен первый, но это, вероятно, приведет к ошибкам и противоречиям в документации. Подобным же образом, модули должны вначале целиком проектироваться на достаточно общем уровне, а затем следует возвращаться, чтобы с каждой итерацией определять все новые и новые детали. [29]
Начальным шагом в проектировании модуля является определение его внешних характеристик. Эта информация содержится во внешней спецификации модуля, которая включает все данные, необходимые для модулей, вызывающих данный модуль. В особенности необходимо отметить, что внешняя спецификация модуля не должна содержать указаний о внутреннем представлении данных или о логике модуля. Кроме того, недопустимо, чтобы спецификация содержала какие-либо ссылки на вызывающие модули или на контексты, в которых данный модуль используется. [30]
Страницы: 1 2 3