Вы могли бы создать интерфейс для конечных пользователей при помощи соответствующих инструментальных средств. Вашей программы достаточно для того, чтобы сделать интерфейс восприимчивым к действиям пользователя. Как только пользователи согласятся с компоновкой интерфейса, вы можете отбросить его и переписать на этот раз на основе бизнес-логики, используя целевой язык. Аналогично, вы можете захотеть создать прототип ряда алгоритмов, которые осуществляют реальную упаковку. Вы можете запрограммировать функциональные тесты на высокоуровневом, «всепрощающем» языке типа Perl и затем запрограммировать низкоуровневые тесты производительности на языке, который более близок к машинному. В любом случае, как только вы приняли решение, необходимо начать сначала и запрограммировать алгоритмы в окончательной версии среды, которая взаимодействует с внешним миром. Это и есть создание прототипов, и это очень полезно.
Подход типа "стрельба трассирующими" обращается к иной проблеме. Вам необходимо знать, как работает приложение в целом. Вы хотите показать вашим пользователям, как на практике осуществляется взаимодействие, и дать им «скелет» архитектуры, на который наращивается тело программы. В этом случае вы можете сконструировать программу трассировки, состоящую из тривиальной реализации алгоритма упаковки контейнера (возможно, нечто вроде FIFO), и простой, но работающий интерфейс пользователя. Как только вы соедините все компоненты приложения, у вас уже есть каркас, который можно представить вашим пользователям и разработчикам. Спустя некоторое время вы добавляете к этому каркасу новую функциональную возможность, заменяя заглушки программами. Но сам остов остается нетронутым, и вы знаете, что система будет вести себя так же, как и в тот момент, когда завершалась первая программа трассировки.
Различие достаточно важно, чтобы гарантировать повторяемость. Прототипы генерируют одноразовую программу. Программа трассировки является скудной, но завершенной; она образует часть «скелета» конечной версии системы. Рассматривайте создание прототипов как рекогносцировку и сбор данных разведки до начала стрельбы трассирующими.
• Приемлемые программы
• Прототипы и памятные записки
• Западня спецификации
• Большие надежды
11
Прототипы и памятные записки
Для опробования определенных идей во многих отраслях промышленности используются прототипы; это дешевле, чем организовывать полномасштабное производство. Например, в автомобильной промышленности для новой модели автомобиля может быть построено несколько различных прототипов. Каждый из них конструируется для проверки определенных свойств автомобиля – аэродинамики, дизайна, свойств конструкции и т. д. Для испытания в аэродинамической трубе изготовляется модель из глины, для отдела дизайна создается модель из бальзовой древесины и клейкой ленты и т. д. Некоторые автомобильные фирмы идут дальше и осуществляют значительную часть работы по моделированию при помощи компьютеров, что приводит к еще большему сокращению расходов. В этом случае нет необходимости в реальном изготовлении рискованных элементов конструкции для их опробования.
Мы создаем прототипы программ тем же образом и по тем же причинам – для анализа и выявления риска, предлагая возможности для коррекции при существенно меньших затратах. Подобно тому, как это делается в автомобильной промышленности, мы можем использовать прототип для опробования одного или нескольких характеристик проекта.
Мы склонны полагать, что основой прототипов являются программы, но не это не всегда так. Подобно тому, как это делается в автомобильной промышленности, мы можем строить прототипы из различных материалов. Памятные записки великолепно подходят для создания прототипов таких динамических объектов, как логика документооборота и прикладная логика. Прототип интерфейса может моделироваться на лекционной доске, как модель без функциональных возможностей, изображенная с помощью графической программы или программы-построителя интерфейса.
Прототипы разрабатываются для того, чтобы ответить лишь на несколько вопросов, поэтому их разработка намного дешевле и быстрее, чем приложения, которые идут в производство. Программа может игнорировать незначительные подробности – незначительные в данный момент, но позже могущие оказаться для пользователя очень важными. Если, к примеру, вы создаете прототип графического интерфейса пользователя, то можете смириться с неправильными результатами или данными. С другой стороны, если вы просто исследуете характеристики вычислений или производительности, можете обойтись скудным графическим интерфейсом пользователя или вообще без него.
Но если вы работаете в среде, где нельзя отказаться от подробностей, тогда необходимо спросить себя, а нужно ли вообще создавать прототип. Возможно, в этом случае лучше всего подходит стиль разработки типа "стрельба трассирующими" (см. "Стрельба трассирующими").
Для чего создаются прототипы
Какие объекты можно изучать при помощи прототипов? Все, что характеризуются наличием риска. Все, что не подвергались тестированию ранее или являются абсолютно критичными для конечного варианта системы. Вес, что является недоказанным, экспериментальным или сомнительным. Вес то, с чем вы еще не освоились. Вы можете создавать прототипы:
• Архитектуры
• Новой функциональной возможности уже существующей системы
• Структуры или содержания внешних данных
• Инструментальных средств или компонентов, выпущенных фирмами-субподрядчиками
• Рабочих характеристик
• Дизайна интерфейса пользователя
Создание прототипов способствует приобретению опыта. Значение этого опыта заключается не в созданной программе, а в полученных уроках. В этом и состоит смысл создания прототипов.
Подсказка 16: Создавайте прототипы, чтобы учиться на них
Как использовать прототипы
Какими деталями можно пренебречь при построении прототипа?
• Корректность. Там, где это приемлемо, вы сможете использовать фиктивные данные.
• Завершенность. Прототип может функционировать лишь в ограниченном смысле, возможно, лишь с одним наперед заданным фрагментом входных данных и одним пунктом меню.
• Надежность. Процедура проверки ошибок, вероятно, будет неполной или будет отсутствовать полностью. Если вы отклоняетесь от определенного пути, то прототип может выйти из строя и сгореть, как ракета. Это нормально.
• Стиль. Неприятно признавать это, но прототип программы не имеет большого значения для комментариев или документации. При работе с прототипом можно написать горы документации, но сравнительно малая ее часть будет посвящена собственно прототипу системы.
Поскольку в прототипе детали отодвигаются на второй план, а в центре рассмотрения оказываются определенные аспекты системы, вам может показаться реальным создание прототипов с использованием языка очень высокого уровня – выше уровня языка остальной части проекта (язык типа Perl, Python или Tel). Язык сценариев высокого уровня позволяет опускать многие детали (включая указание типов данных) и при этом создавать функциональный (хотя и неполный и медленный) фрагмент программы [11]. Если вам необходимо создать прототип интерфейсов пользователей, изучите инструментальные средства типа Tcl/Tk, Visual Basic, Powerbuilder или Delphi.