Джозеф Фокс - Программное обеспечение и его разработка

Собрание инструментальных средств это одно. Взаимосвязанный, автоматизированный набор инструментальных средств это совершенно другое. Еще в очень многих современных разработках программисты продолжают применять инструментальные средства вручную. Они вставляют в свою программу команды для вызова вспомогательных программ или физически вкладывают свои программы в тестирующие колоды и передают их на выполнение.

Сегодня программист уже имеет возможность оформлять обращение к этим инструментам отладки как вызовы процедур, а программное окружение, работающее под управлением операционной системы, выполнит задание, которое ранее приходилось выполнять вручную.

Недостаточно хорошие инструментальные средства значительно замедляют процесс разработки. Чем новее вычислительная машина, тем более непривычные средства предлагаются на ней, тем меньше средств предлагается вообще.

Выбор инструментальных средств должен следовать за выбором методики. Если сначала вы выберете язык, то это может помешать вам применять методы структурного программирования. Некоторые языки не отвечают методам структурного программирования.

Некоторые языки не дают вам возможности контролировать получающиеся модули. Некоторые лишают возможности упрятывания информации. Переходить к выбору инструментов нужно после выбора методик. А методика должна выбираться после того, как произведен выбор процесса. (См. рис. 5.42.)

В основании выбора транслятора лежит выбор двух типов проводимой нами оптимизации, мы оптимизируем:

1) либо использование транслятора (время трансляции),

2) либо программу, получающуюся в результате трансляции (время использования). Техническая программа, которая будет выполнена только один раз, совершенно не нуждается в том, чтобы оптимизировать параметры ее использования.

Пользователь, который транслирует свою программу один раз, а затем ежедневно выполняет полученную в результате рабочую программу, совершенно не интересуется тем насколько быстро проходит эта трансляция; этот пользователь хочет иметь «эффективную рабочую программу». (См. рис. 5.43.)

Выбор языка.С такими же компромиссами приходится иметь дело и при выборе языка программирования. Какой язык вы будете использовать, зависит от задания, которое вам поручено, контингента ваших сотрудников и сроков, которые вам отведены. За выбором языка следует выбор транслятора, и язык должно выбирать руководство, а не программист (см. рис. 5.44).

Язык I (на рис. 5.44) оптимален в фазе разработки; язык II — в фазе сопровождения, но за счет времени первичной разработки.

Заметьте, что выбор языка не связан с выбором транслятора. А теперь посмотрите на схему последовательного выбора языка и транслирующей программы (рис. 5.45).

Мы обращаемся к методу сверху вниз именно сейчас, а не при обсуждении процесса проектирования. Реализация сверху вниз смысл имеет, а вот проектирование сверху вниз совершенно бессмысленно.

В разделе, посвященном проектированию, мы увидели, что первой частью этого процесса является этап создания, творчества. По своей природе этот процесс связан с переходами взад и вперед. У этого процесса может быть верхний уровень, а может и не быть.

Но если мы можем найти этот верхний уровень в фазе проектирования, то реализовать программное обеспечение мы сможем, двигаясь сверху вниз. Мы можем создать программы верхнего уровня и, «отталкиваясь» от них, добавлять подчиненные программы, продвигаясь вглубь, уровень за уровнем, создавая нужное нам программное обеспечение.

Такой подход заметно отличается от метода реализации снизу вверх, когда первыми создаются программы самого нижнего уровня. Можно ли говорить в этом случае о проектировании сверху вниз? Многие считают, что это не проектирование, а реализация сверху вниз. Во многих сложных системах во многих случаях нужно проводить проектирование снизу вверх, поскольку система часто зависит от решений, принятых при проектировании одной-двух подсистем.