Программное обеспечение и его разработка
Шрифт:
Хотя обычно мы не рассматриваем операционную систему или систему управления базой данных в качестве отдельного слоя общей системы, по сути это на самом деле так. С каждой из этих подсистем мы связываем определенные функции, причем эти функции сосредоточиваются в ограниченной части системы.
Системы следует проектировать в расчете на пиковые ситуации — ситуации, которые обычно не возникают Если же возможность их возникновения реальна, то именно в этих случаях система особенно необходима (Очень интересно исследовать чистые затраты груда на имитацию пиковых
Результаты проектирования программного обеспечения на среднем уровне могут быть проиллюстрированы на таком примере: как нам разделить на части программу обработки запросов, чтобы работа была максимально эффективной?
В первом варианте решения (см. рис. 5.26) есть модуль «одиночного обслуживания», который строит из всех нуждающихся в нем очередь и «обслуживает» их по одному за раз.
Если очереди станут длинными, то такое решение приведет к задержкам, т. е. одновременно будет поступать много запросов. Второй вариант решения заключается в том, что в памяти машины одновременно находится несколько копий одного модуля, так что одновременно можно обрабатывать несколько очередей. Однако на это затрачивается много памяти.
Третий вариант предлагает одну программу обработки очередей, которая одновременно может работать сразу с несколькими очередями. Эта программа является повторно входимой. Она может одновременно выполняться для нескольких пользователей. Вариант, который будет выбран группой проектировщиков, окажет значительное влияние на производительность системы.
Внутри модуля, служащего для управления линиями связи, можно иметь около 100 микромодулей размером около 30 операторов на языке высокого уровня или 30 модулей размером в 100 операторов. Каждый микромодуль должен быть максимально изолирован от других. Под этим мы, в частности, подразумеваем следующее:
1. Ни один модуль не зависит от других, кроме как в смысле последовательности исполнения; каждый модуль должен быть обеспечен всеми данными, кроме тех, которые нужно вводить с внешних устройств.
2. Все модули должны иметь минимальные размеры, лучше всего около 30 операторов на языке высокого уровня. Этим достигается микромодулярность.
3. Каждый модуль должен выполнять одну и только одну функцию.
Ключ к созданию легко изменяемого программного обеспечения заключается в том, что создавать его надо компактными сегментированными разделами. К счастью, для этого у нас теперь есть достаточно стандартные способы. Технические методы описаны в многочисленных публикациях, здесь мы ограничимся перечислением основных моментов.
Мы продолжаем
Проект модуля включает в себя:
Размер модуля
Внешние данные
Содержание
Внутреннее строение
Внешние связи
Желательно иметь минимум внешних данных; этим определяется независимость модулей. Модуль, выполняющий единственную, хорошо определенную функцию, строго функционален.
Строго функциональные модули могут быть реализованы методом, позволяющим организовать упрятывание информации. Различные состояния данных, возникающие при выполнении функций модуля, известны только этому модулю, поэтому проектировщики и программисты, составляющие другие модули, не должны знать подробности работы данного модуля. Они будут лишены возможности пользоваться сведениями о том, как мы собирались написать данный модуль. Это удержит их от поспешных решений. Вот так-то!
Принцип упрятывания информации мы проиллюстрируем следующим примером. На языке Бейсик команда печати, в которой за символом @ следует число, например PRINT@ 482, отсчитывает заданное число позиций строка за строкой начиная с самой левой позиции верхней строки и печатает некоторое значение в 482-й позиции. Если я программировал в расчете на использование экрана шириной в 32 позиции, то команда PRINT® 69 вызовет пропуск двух пустых 32-символьных строк и выдачу на экран с отступом на 4 шага вправо. Чтобы напечатать
я должен написать: PRINT@69, N (имя) PRINT® 69, А (адрес)
Но, если используемые нами экраны сменились на 79-символьные, программа станет работать неверно. Я получу в этом случае что-нибудь вроде этого:
Чтобы работать с новыми устройствами, надо менять программу.
Приведенный пример тривиален, но представьте, что нам нужно менять сотни программ, работавших в течение многих лет. Это уже проблема! Многих программистов уже нет; другие заняты в других важнейших делах. Ответ напрашивается сам собой — не будем ставить никаких новых дисплеев! Даже если они более дешевы, более надежны и т. д.!
Обходным путем решения подобной проблемы может быть написание программ, не зависящих от числа позиций на экране. Программист просто следует соглашению, по которому текст начинается: 1) с самого начала или 2) отступя 1/8 часть строки, и т. д.
Системные программы берут указания о том, где надо начать текст, преобразуют их к фактическим значениям в соответствии с фактически подключенным дисплеем, и лишь затем будет выполняться наша программа. Теперь при смене физического дисплея нужно будет изменить только системные программы. Если у нас сотни прикладных программ, выгоды налицо. Возможность внесения изменений планируется заранее, (см. рис. 5.27.)