14. Этап перехода от проектирования к реализации

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

14.1. Оценка проекта

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

Важно, чтобы как разработчики, так и сторонние наблюдатели, понимали, что основная задача заключается в выявлении в проекте нерешенных проблем. Хотя разработчики неизбежно займут по отношению к созданному проекту оборонительную позицию, они должны при этом понимать, что это не является их главной задачей. Кроме этого, как разработчики, так и остальные участ­ники обсуждения должны помнить, то их основная задача заклю­чается в обнаружении ошибок, а не в исправлении их. Ошибки должны заноситься в журнал ошибок, после чего анализ должен быть продолжен (если только число ошибок не окажется настолько большим, что дальнейший поиск будет бессмыслен).

Проектировщикам желательно предоставить на обсуждение не только проект, но и изученные и отвергнутые альтернативы. Это позволит сторонним наблюдателям лучше оценить выбранный под­ход, а также облегчит выявление в нем слабых мест. К распро­страненной проблеме относится невозможность полного соблюде­ния выбранного критерия. Объяснение того, что некоторая альтер­натива была отброшена по причине неудовлетворения выбранного критерия, может помочь наблюдателям обнаружить части про­екта, в которых указанный критерий также не выполняется.

Существуют три важных аспекта, используемых при оценке проекта.

Этап перехода от проектирования к реализации

1.Все ли части проекта обеспечивают необходимую функцио­нальность? То есть будет ли программа «правильной»?

2.Существуют ли реализации проекта, которые будут обла­дать приемлемой эффективностью?

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

14.1.1. Корректность и эффективность

Ранее мы обсуждали два метода, позволяющие повысить уве­ренность в правильности поведения программы —тестирование и верификацию. К сожалению, ни один из этих методов не может быть применен к проектам. Поскольку проекты нельзя «запус­кать», то тестирование, очевидно, неприменимо. Если бы проекты создавались на полностью формализованном языке, то существо­вала бы возможность некоторой верификации. Однако на сегод­няшний день возможность создания формальной спецификации для больших программ отсутствует.

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

К двум важным свойствам относятся ограниченность и обоб­щенность. Они были рассмотрены в гл. 8.Другой важной локаль­ной характеристикой является эффективность. При оценке об­щей эффективности системы первым шагом является создание для каждой абстракции выражения, связывающего время работы и объем памяти, занимаемый данной абстракцией, с ее аргументами. Степень точности этих выражений зависит от степени завершен­ности проекта. Рассмотрим процедуруsort:

sort = proc (a: int. array)

modifies a

effects Переставляет элементы массива а таким образом, что массив а упорядочивается по возрастанию.'

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

302 Глава 14

заций гораздо больше можно будет сказать в том случае, если в проект будет включен следующий критерий:

Эффективность. Худший случай: время =n*log(п) сравнений, где п есть размер массива а

и еще больше, если проект содержит следующее замечание:

Эффективность.Худший случай: время == n*log(п) сравнений, где п есть размер массива а. Максимальный размер временно используемой оперативной памяти постоянен и невелик

В процессе обзора проекта важно обнаружить те места, где необ­ходимо более подробное описание требований к реализации. После оценки каждого модуля, взятого изолированно, мы переходим к оценке проекта в целом. Хорошо исследовать проект, проходя по нему маршрутами, соответствующими различным вариантам применения программы. Мы выбираем некоторые тестировочные данные, а затем следим, как данные и управляющая информация «пройдет» через реализацию, основанную на предложенном про­екте. Такой метод трассировки иногда называютсквозным проходом. Тестировочные данные выбираются аналогично тому, как это было описано в гл. 9.Однако, поскольку «тестирование» проекта го­раздо сложнее, чем тестирование реализации, выбор тестировочных данных должен быть избирательным.

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

Выбор тестировочных -случаев на этапе оценки проекта не­сколько упрощается за счет того, что данные могут быть символиче­скими. Нам необходимо только идентифицировать свойства, ко­торые должны иметь тестировочные данные; нет нужды изобре­тать данные с такими свойствами. В качестве примера рассмотрим программуformat, спроектированную в гл. 13.Начнем со случая ввода корректных данных, т. е. полагаем, что все аргументы для программыformatприведены в корректном формате. Постольку начальное 'содержащие файла выходных данных и файла ошибок не имеет значения, мы должны побеспокоиться только о содержимом входного файлаins.

Тест должен учитывать случаи, включающие различные со­четания:

Этап перехода от проектирования к реализации

1)короткие и длинные слова, включая слова, длина которых превышает длину выходной строки;

2)одиночные и повторяющиеся пробелы между словами;

3)символы табуляции и пробелы в различных позициях вы­ходных строк, например в начале, середине и конце;

4)короткие и длинные входные строки, включая входные строки, более длинные, чем выходные;

5)выходные строки, для которых выравнивание не требуется;

6)выходные строки, для которых число добавляемых в них пробелов превышает число промежутков между словами;

7)выходные строки,, содержащие только одно слово. Приводимые ниже символические данные покрывают некоторые их этих ситуаций:

слово1 пробел слово2 пробел словоЗ пробел слово4 где сумма длин слова1 и слова2 меньше длины выходной строки, а сумма длин слова1,слова 2и словаЗ больше, чем длила выход­ной строки.

Мы можем использовать эти, данные для прохода по проекту задачиformat. Этот проход фактически представляет собой руч­ную имитацию работы программы. Посмотрим,, как мы можем начать этот проход на основе предложенных выше данных:

1.После проверки типов аргументов, задачаformatсоздает но­вое выходное устройствоdoc, обращаясь для этого кdoc$cre-ate(outs). Спецификация дляdoc$createговорит нам о том, что данное устройство находится в режиме «с заполнением». Вoutsdoc$createничего не записывается.

2.Затем программаformatобращается кdoJine(ins,d,errs). В этой точке мы можем отметить, чтоdo.lineне имеет прямого доступа кouts, и должны спросить себя, не порождает ли это проблему. Похоже, что нет.

3.Процедураdo_lineустанавливается на первый символ вход­ной строки вins, обнаруживает, что он не являются, точкой и обра­щается затем кdo_text_line(ins, d).Мы видим, чтоdo.text.lineне передаетсяerrs. Также отметим отсутствие возможности пере­дачи информации об ошибках назад к do_line.Это не порождает никаких проблем для процедурыformatв ее нынешней специфи­кации, однако, похоже, создаст проблемы в том случае, если спецификация будет модифицирована с тем, чтобы позволить ра­ботать не только со словами, а например, с информацией об измене­нии типа шрифта, содержащейся в строках входного текста. Этот момент необходимо отметить в документации.

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

304 Глава. 14

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

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

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