Языки сценариев хороши для использования в качестве «клея» при соединении низкоуровневых фрагментов в новые сочетания. При работе в системе Windows язык Visual Basic может «скреплять» средства управления СОМ. В более общем смысле вы можете использовать языки типа Perl и Python для связывания воедино низкоуровневых библиотек языка С – вручную или автоматически при помощи инструментов наподобие бесплатного SWIG [URL 28]. Используя этот подход, вы можете быстро собрать существующие компоненты в новые конфигурации, чтобы посмотреть, как они работают.
Создание прототипов архитектуры
Многие прототипы создаются, чтобы смоделировать рассматриваемую систему в целом. В отличие от подхода типа "стрельба трассирующими", ни один из отдельных модулей в прототипе системы не должен быть особенно функциональным. На самом деле вам даже не нужно писать программу для создания прототипов – вы можете создать прототип на лекционной доске, при помощи памятных записок или каталожных карточек. Вы пытаетесь понять то, как система выглядит в собранном виде, опуская детали. Вот некоторые из конкретных областей, которые вы можете обнаружить в архитектурном прототипе:
• Четко ли определены обязанности основных компонентов, и являются ли они приемлемыми?
• Четко ли определена совместная работа основных компонентов?
• Сведено ли к минимуму связывание?
• Можно ли идентифицировать потенциальные источники дублирования?
• Можно ли применить определения интерфейсов и ограничения?
• Обладает ли каждый из модулей путем доступа к данным, требуемым ему в ходе выполнения? Может ли он получить такой доступ в случае необходимости?
Последний пункт приносит большинство сюрпризов и наиболее ценных результатов, основанных на опыте создания прототипов.
Как не надо использовать прототипы
Перед тем как вы займетесь созданием любого прототипа, основанного на программе, убедитесь, что все понимают – вы пишете одноразовую программу. Прототипы могут быть обманчиво привлекательными для людей, которые не знают, что это всего лишь прототипы. Вы должны очень четко уяснить – эта программа одноразовая, незавершенная и не может быть завершена.
Легко впасть в заблуждение из-за очевидной завершенности демонстрационного прототипа, и спонсоры проекта или менеджмент могут настаивать на развертывании прототипа (или его потомства), если вы заранее не определите, что можно ожидать от прототипа. Напомните им, что вы, конечно, можете создать великолепный прототип новой модели автомобиля из бальзовой древесины и клейкой ленты, но вы же не поедете на нем в час пик!
Если вы полагаете, что в вашей среде или культуре существует большая вероятность того, что назначение прототипа программы может быть истолковано неправильно, вам лучше воспользоваться подходом "стрельба трассирующими". Вы получите некий жесткий каркас, на котором можно основывать будущие разработки.
При надлежащем использовании прототип может сэкономить вам огромное количество времени, денег, головной боли и мучений за счет идентификации и исправления потенциальных проблем в самом начале цикла разработки – затраты на устранение ошибок будут недорогими и не вызовут затруднений.
• Мой исходный текст съел кот Мурзик
• Общайтесь!
• Стрельба трассирующими
• Большие надежды
4. Специалисты по маркетингу хотели бы сесть и вместе с вами провести мозговой штурм по дизайну нескольких интернет-страниц. Они думают об активных картах ссылок – для перехода к другим страницам. Но они не могут определиться с моделью ссылки: это могут быть изображения автомобиля, телефона или дома. У вас имеется перечень целевых страниц и содержания; они хотели бы увидеть несколько прототипов. Да, кстати, в вашем распоряжении 15 мин. Какими инструментами вы могли бы воспользоваться? (Ответ см. в Приложении В.)
12
Языки, отражающие специфику предметной области
Границы моего языка есть границы моего мира.
Языки программирования влияют на то, как вы думаете о проблеме, и на то, как вы думаете об общении. В каждом языке имеются свои особенности – ученые словечки типа "статический и динамический контроль типов", "раннее и позднее связывание", "модели наследования" (простое, множественное или отсутствие) – все они могут предложить определенные решения или затруднить их. Решение, создаваемое в стиле Lisp, отличается от решения, основанного на мышлении приверженца языка С, и наоборот. Верно и обратное (и по нашему мнению, более важное) – язык, отражающий специфику данной области, может, со своей стороны, предложить решение в области программирования.
Мы всегда пытаемся написать программу, используя словарь, характерный для прикладной области (см. "Ловушка требований", где предлагается использовать проектный глоссарий). В ряде случаев можно перейти на следующий уровень и действительно программировать, пользуясь словарем, синтаксисом и семантикой предметной области.
Пользователи предложенной системы должны быть в состоянии точно изложить, как она должна работать:
Ожидать прихода сообщений, определенных нормативом 12.3 фирмы ABC, по каналам связи Х.25, преобразовать их в формат 43В фирмы XYZ, ретранслировать на спутниковый канал связи и сохранить для анализа в будущем.
Если ваши пользователи располагают набором подобных четких инструкций, то вы можете изобрести мини-язык, скорректированный в соответствии с прикладной областью и выражающий именно то, что им нужно:
From X25LINE1 (Format=ABC123) {
Put TELSTAR1 (Format=XYZ43B);
Store DB;
}
Этот язык не должен быть исполняемым. В своем исходном виде он мог бы просто фиксировать требования пользователя – спецификации. Однако вы наверняка посчитали возможным пойти дальше и фактически реализовать язык. Ваша спецификация превратилась в исполняемую программу.
После того как вы написали приложение, пользователи предъявляют вам новое требование: сообщения с отрицательным балансом не должны сохраняться и должны отсылаться обратно по каналам связи Х.25 в первоначальном формате:
From X25LINE1 (Format=ABC123) {
if (ABC123.balance «0) {
Put X25L1NE1 (Format=ABC123);
}
else {
Put TELSTAR1 (format=XYZ43B);
Store DB;
}
}
Несложно? При наличии надлежащей поддержки вы можете программировать значительно ближе к прикладной области. Мы не предлагаем, чтобы ваши конечные пользователи программировали на этих языках. Вместо этого вы даете самому себе инструмент, который позволяет вам работать ближе к их области.
Подсказка 17: Программируйте ближе к предметной области вашей задачи
Мы полагаем, что вам следует рассмотреть способы перемещения вашего объекта ближе к предметной области проблемы – будь то простейший язык для конфигурирования и управления прикладной программой или же более сложный язык для обозначения правил или процедур. При составлении программы на более высоком уровне абстракции вам легко сосредоточиться на решении проблем предметной области и вы можете проигнорировать мелкие детали, связанные с реализацией.
Помните, что с приложением работают многие пользователи. Существует конечный пользователь, который понимает правила предметной области и то, что должно быть на выходе программы. Есть также вторичные пользователи: обслуживающий персонал, менеджеры, занимающиеся конфигурированием и тестированием, программисты служб поддержки и сопровождения и будущие поколения разработчиков. У каждого из этих пользователей есть собственная предметная область, и для всех них вы можете генерировать мини-среды и языки.