Глава 3: Типы тестов ... 65

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

Сравнительный анализ различных методологий проектирования можно найти у Бсргланда (Bergland, 1981). О разработке структур данных расска­зывается в книгах Гейна и Сарсона (Gane & Sarson, 1979) и Йордана и Константайна (Yourdon & Constantine, 1979). А об ориентированном на данные подходе к тестированию можно прочесть у Бейзера (Beizer, 1990).

Описание алгоритмов

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

Хорошим учебником по преобразованию высокоуровневых задач в про­граммный код может служить книга Иордана (Yourdon, 1975).

Моделирование

Чтобы лучше представить себе будущий программный продукт, на этапе проектирования может быть разработан его прототип — программная мо­дель всего продукта или его части. Прототип строится очень быстро и с минимумом затрат. Его очень легко менять, и он не выполняет никакой реальной работы.

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

66 Часть I: Основы

Как правило, прототип создается для оценки функциональности буду­щей системы и ее пользовательского интерфейса. Это исключительно по­лезная технология: когда люди получают возможность собственноручно поэкспериментировать с системой или ее прототипом, их требования зна­чительно изменяются. Идеи, которые в спецификации казались просто блестящими, в работающей модели могут утратить всю свою привлекатель­ность. (Мартин и Мак-Клер (Martin & mcClure, 1983), Вассерман и Шыо- мейк (Wasserman & Shewmake, 1985)).

Мартин и Мак-Клер настоятельно рекомендуют писать прототипы на том же языке, на котором будет реализован конечный продукт: если про­тотип окажется удачным, то конечный продукт может разрабатываться прямо на его основе. Однако, на наш взгляд, так поступать не стоит, и вот почему.

• Многие языки или системы разработки не подходят для создания быстрого и дешевого прототипа.

• Хороший совет дали в своих книгах Брукс (Brooks, 1975) и Керни- ган и Плугер (Kernigan & Plauger, 1974). Они рекомендуют отложить первый черновик программы и начать ее разработку с чистого ли­ста. Особенно это касается прототипа. Ведь от него не требуется хорошая внутренняя организация. Он может работать медленно и неэффективно, а то и вообще неправильно. Согласитесь, что такая программа не лучшая основа для хорошей разработки. Да и разра­ботчики прототипа будут чувствовать себя гораздо свободнее, если будут думать только о скорости и не беспокоиться, что допущенные ими ошибки и неверные решения впоследствии затруднят програм­мирование.

Вопросы моделирования интерфейса, стратегий оценки проекта и тех­нологий его разработки обсуждаются в книгах Де Грейса и Стала (DeGrace & Stahl, 1990), Хеландера (Helander, 1991), Рубенштейна и Херша (Rubenstein & Hersh, 1984), Оулда (Ould, 1990) и Шнейдермана (Schneiderman, 1987).

Тестирование на этапе проектирования

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