- •Глава II
- •12. Предварительные замечания о процессе разработки программ
- •12.1. Жизненный цикл математического обеспечения
- •12. Предварительные замечания о процессе разработки программ
- •12.1. Жизненный цикл математического обеспечения
- •12.2. Анализ требований
- •12.3. Пример задачи
- •13.1. Обзор процесса проектирования
- •13.2.1. Вводный раздел
- •13.2.2. Разделы абстракций
- •13.8. Абстракция строки
- •13.9. Обзор и обсуждение
- •14. Этап перехода от проектирования к реализации
- •14.1. Оценка проекта
- •14.1.1. Корректность и эффективность
- •14.1.2. Структура
- •15.2. Выбор подхода
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говорит нам о том, что данное устройство находится в режиме «с заполнением». В outs doc$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
Трассировка проекта несколькими наборами входных данных позволяет нам обнаружить серьезные ошибки, касающиеся согласованности между собой составляющих проект абстракций. На следующем шаге рекомендуется пройти по диаграмме модульной зависимости снизу вверх, изолируя подсистемы, которые можно оценить независимо от используемого контекста. Поскольку эти подсистемы значительно меньше, чем вся система целиком, мы можем проверить их с большим числом наборов тестировочных данных.
Модифицируемость проекта должна быть рассмотрена отдельно. Необходимо обсудить, каким образом должен быть изменен проект для внесения каждого из предполагаемых изменений. Хорошим мерилом приспособленности проекта к модификациям является число абстракций, претерпевающих изменения в каждом таком случае. Наилучшей является ситуация, при которой модифицируется только одна абстракция.
Описанный сквозной подход позволяет взглянуть на проект с друге.., отличной от выработанной в процессе проектирования точки зрения. В процессе проектирования мы фокусировали свое внимание на определении абстракций и спецификации их интерфейсов. Эти абстракции возникли из анализа шагов, которые необходимо выполнить, при этом различные части программы рассматривались в отдельности друг от друга. Теперь мы производим просмотр по шагам, выполняемым программой, что позволяет понять, помогают ли введенные абстракции решить исходную задачу.