Упражнения


1. Создается класс Split, который расщепляет вводимые строки на поля. Какая из двух указанных ниже сигнатур класса Java имеет более ортогональную конструкцию? (Ответ см. в Приложении В.)
class Split 1 {
public Splitl(InputStreamReader rdr) {…
public void readNextLine() throws IOException {…
public int numFields() {…
public String getField(int fieldNo) {…
}
class Split2 {
public Split2(String line) {…
public int numFields() {…
public String getField(int fieldNo) {…
}
2. Какая конструкция обладает большей ортогональностью: немодальные или модальные диалоговые окна? (Ответ см. в Приложении В.)
3. Сравним процедурные языки и объектно-ориентированные технологии. Что дает более ортогональную систему? (Ответ см. в Приложении В.)
9
Обратимость
Нет ничего опаснее идеи, если это единственное, что у вас есть.
Эмиль-Огюст Шартье, Разговор о религии, 1938
Технические специалисты предпочитают простые и однозначные решения задач. Математические тесты, позволяющие с большой уверенностью сказать, что х = 2, намного лучше, чем нечеткие, но страстные очерки о миллионах причин Французской революции. К техническим специалистам присоединяются и менеджеры: однозначные и несложные ответы хорошо вписываются в электронные таблицы и проектные планы.
Если бы это находило отклик в реальном мире! К сожалению, сегодня икс может быть равен двум, а завтра он должен быть равен пяти, а на следующей неделе – трем. Ничто не вечно, и если вы всерьез полагаетесь на некоторое явление, то этим вы практически гарантируете, что оно непременно изменится.
Для реализации чего-либо всегда существуют не один-единственный способ и не одна фирма-субподрядчик. Если вы начинаете работать над проектом, недальновидно полагая, что для его осуществления имеется один-единственный способ, то вы можете быть неприятно удивлены. Многим проектным командам открывают глаза принудительно, по мере развития событий:
"Но вы же сказали, чтобы мы использовали базу данных XYZI. Мы написали 85 % текста проекта – мы не можем изменить его в данный момент", – протестует программист. "Очень жаль, но наша фирма решила вместо нее взять за основу базу PDQ – для всех проектов. Это немое решение. Мы все должны переписывать тексты программ… Всем вам придется работать и по выходным – до особого распоряжения".
Конечно, принимаемые меры не должны быть столь драконовскими, сколь и неотложными. Но поскольку время идет, а ваш проект продвигается, вы можете оказаться в шатком положении. С принятием каждого важного решения проектная команда ставит перед собой все более узкую цель – ограниченную версию действительности, в которой имеется меньшее число вариантов.
К тому времени, когда многие важные решения уже приняты, цель уменьшится настолько, что, если она двинется с места или ветер изменит направление, или же бабочка в Токио взмахнет своими крылышками, вы промахнетесь
[9]. И здорово промахнетесь.
Проблема состоит в том, что непросто дать задний ход важным решениям.
Как только вы решите использовать базу данных этой фирмы или архитектурный шаблон, или определенную модель развертывания (например, «клиент-сервер» вместо автономной модели), то вы становитесь на путь, с которого невозможно свернуть – лишь ценой огромных затрат.
Обратимость
Многие из тем, затронутых в данной книге, нацелены на создание гибкого, легко адаптируемого программного обеспечения. Следуя их рекомендациям – в особенности принципу DRY, принципу несвязанности и использованию метаданных (см. ниже), нет нужды в принятии многих важных необратимых решений. Это и хорошо, поскольку вначале мы не всегда принимаем наилучшие решения. Мы придерживаемся некоторой технологии лишь для того, чтобы в один прекрасный день обнаружить, что не в состоянии нанять достаточное количество людей, обладающих необходимыми навыками. Стоит нам остановить свой выбор на некоторой фирме-субподрядчике, как ее сразу перекупают конкуренты. Требования, пользователи и аппаратные средства изменяются быстрее, чем мы разрабатываем программное обеспечение.
Предположим, что в начале проекта вы решили использовать реляционную базу данных, производимую фирмой А. Позже, во время нагрузочного тестирования, вы обнаруживаете, что база данных слишком медленная, а объектная база данных фирмы В работает быстрее. В большинстве случаев, вам не везет. Большую часть времени обращения к программам фирм-субподрядчиков запутываются в тексте программ. Но если вы действительно вычленили идею базы, поместив ее снаружи – в точку, где она просто обеспечивает сохранение состояния объектов (как служба), тогда вы обладаете достаточной гибкостью, чтобы менять коней на переправе.
Предположим, что проект начинается по модели «клиент-сервер», но затем, когда карты уже сданы, отдел маркетинга решает, что для некоторых заказчиков серверы слишком дороги и они хотят сделать автономную версию. Насколько сложным будет для вас этот переход? Поскольку речь идет о развертывании, для этого потребуется минимум несколько дней. Если бы времени требовалось больше, вы бы и не думали об обратимости. Обратная задача еще интереснее. Что будет, если возникнет необходимость в развертывании автономной версии разрабатываемого вами проекта по схеме «клиент-сервер» или по n-звенной модели? Это также не должно представлять затруднений.
Ошибка состоит в предположении, что любое решение высечено на камне, и в неготовности к случайностям, которые могут возникнуть. Вместо того, чтобы высекать решения на камне, рассматривайте их так, как будто они начерчены на морском песке. В любой момент может накатиться большая волна и смыть их.
Подсказка 14: Не существует окончательных решений
Гибкая архитектура
В то время как многие люди пытаются сохранить свои программы гибкими, вам также стоит подумать о том, чтобы обеспечить гибкость архитектуры, развертывания и интеграции продуктов фирм-субподрядчиков.
Технологии, подобные CORBA, могут помочь в защите компонентов проекта от изменений, происходящих в языке, на котором ведется разработка, или в платформе. Вдруг производительность Java на этой платформе не соответствует ожиданиям? Еще раз напишите программу клиента на языке С++, и больше ничего менять не нужно. Подсистема правил в С++ не отличается достаточной гибкостью? Перейдите к версии на языке Smalltalk. При работе с архитектурой CORBA вы должны обращать внимание только на заменяемый компонент, другие компоненты трогать не нужно.
Вы разрабатываете программы для Unix? Какой версии? Вы рассмотрели все из аспектов переносимости? Вы пишете для конкретной версии Windows? Какой – 3.1, 95, 98, NT, СЕ или же 2000? Насколько сложно будет обеспечить поддержку других версий? Если ваши решения характеризуются мягкостью и пластичностью, то это будет совсем несложно. Но это будет невозможно, если пакет неудачно сформирован, есть высокий уровень связанности, а в тексты программ встроена логика или параметры.
Вы не знаете точно, как отдел маркетинга собирается развертывать систему? Подумайте об этом заранее, и вы сможете обеспечить поддержку автономной модели, модели "клиент – сервер" или n-звенной модели только за счет изменений в файле конфигурации. Мы создавали программы, которые действуют подобным образом.
Обычно вы можете просто скрыть продукт фирмы-субподрядчика за четким, абстрактным интерфейсом. На самом деле мы могли это сделать с любым проектом, над которым мы работали. Но предположим, что вы не смогли изолировать его достаточно четко. Вам пришлось раскидать некоторые инструкции по всей программе? Поместите это требование в метаданные и воспользуйтесь автоматическим механизмом, наподобие Aspect (см. "Инструментарии и библиотеки") или Perl для вставки необходимых инструкций в саму программу. Какой бы механизм вы ни использовали, сделайте его обратимым. Если что-то добавляется автоматически, то оно может и удаляться автоматически.
Никто не знает, что может произойти в будущем, в особенности мы! Дайте вашей программе работать в ритме рок-н-ролла: когда можно – качаться, а когда нужно – энергично крутиться.
Другие разделы, относящиеся к данной теме:
• Несвязанность и закон Деметера
• Метапрограммирование
• Всего лишь представление
Вопросы для обсуждения
• Немного квантовой механики – пример с кошкой Шрёдингера. Предположим, что в закрытом ящике сидит кошка, и в нем же находится радиоактивная частица. Вероятность распада частицы на две равна 50 %. Если распад произойдет, кошка умрет. Если не произойдет, кошка останется жива. Итак, умирает кошка или остается жива? Согласно Шрёдингеру, верно и то, и другое. Всякий раз, когда происходит ядерная реакция, у которой имеются два возможных результата, происходит клонирование мира. В одном из двух миров данное событие произошло, а в другом – нет. Кошка жива в одном из миров и мертва в другом. Лишь открыв ящик, вы осознаете, в каком из миров находитесь вы.
Не удивительно, что программировать на перспективу так трудно.
Но подумайте об эволюции программы по аналогии с ящиком, в котором находится множество кошек Шрёдингера: каждое решение приводит к появлению иной версии будущего. Сколько сценариев будущего поддерживает ваша программа? Какие из них наиболее вероятны? Насколько сложно будет поддерживать их в определенный момент в будущем?
Хватит ли у вас смелости открыть ящик?
10
Стрельба трассирующими
На изготовку, по цели – пли!
Существует два способа стрельбы из пулемета в темное время суток
[10]. Вы можете выяснить точно, где находится ваша цель (расстояние, высота и азимут). Вы можете определить погодные условия (температура, влажность, давление, направление ветра и так далее). Вы можете точно определить характеристики используемых вами патронов и пуль и их взаимодействие с реальным пулеметом, из которого вы стреляете. Затем вы можете воспользоваться таблицами или компьютером для вычисления точного азимута и угла возвышения ствола пулемета. Если все работает в точном соответствии с характеристиками, таблицы корректны, а погодные условия не меняются, то пули должны лечь близко к цели. Можно также использовать трассирующие пули.
Трассирующие пули помещаются на пулеметную ленту через равные промежутки наряду с обычными боеприпасами. При стрельбе фосфор, содержащийся в них, загорается и оставляет пиротехнический след, идущий от пулемета до любого места, в которое эти пули попадают. Если в цель попадают трассирующие пули, то, значит, в нее попадут и обычные.
Не удивительно, что стрельбу трассирующими предпочитают математическим расчетам. Обратная связь возникает немедленно, и поскольку трассирующие пули работают в той же среде, что и обычные боеприпасы, то внешние воздействия сведены к минимуму.
Возможно это слишком сильная аналогия, но она применима к новым проектам, особенно когда вы создаете то, чего раньше не было. Подобно стрелкам, вы пытаетесь поразить цель в темноте. Ваши пользователи никогда ранее не видели ничего подобного, поэтому их требования могут быть расплывчатыми. Вы же, в свою очередь, наверняка применяете алгоритмы, методики, языки или библиотеки, с которыми не знакомы, то есть сталкиваетесь с большим количеством неизвестных. И поскольку для выполнения проекта требуется время, вы можете с уверенностью гарантировать, что к моменту окончания работы среда, в которой вы работаете, изменится.
Классический способ решения проблемы – предельно специфицировать систему. Написать горы бумажной документации, регламентирующих каждое требование, связывая каждое неизвестное и ограничивая рабочую среду. Стрелять при помощи жесткого расчета. Один большой предварительный расчет, затем стрельнуть и надеяться.
Однако программисты-прагматики предпочитают стрелять трассирующими.
Программа, которую видно в темноте
Стрельба трассирующими пулями эффективна, поскольку эти пули работают в той же самой среде и подвержены тем же ограничениям, что и реальные пули. Они быстро оказываются у цели, так что стрелок получает немедленную обратную связь. И с практической точки зрения они представляют собой относительно экономичное решение.
Чтобы добиться того же эффекта в программах, мы ищем нечто такое, что позволяет нам быстро, наглядно и многократно проходить путь от требования до некоторой характеристики окончательной версии системы.
Подсказка 15: Пользуйтесь трассирующими пулями, для того чтобы найти цель
Однажды мы работали над сложным маркетинговым проектом с базой данных «клиент-сервер». Частью требований была способность определять и выполнять промежуточные запросы. Серверами являлся ряд реляционных и специализированных баз данных. Клиентский графический интерфейс пользователя, написанный на языке Object Pascal, использовал набор библиотек С для обеспечения интерфейса с серверами. Запрос пользователя хранился на сервере с использованием системы обозначений, подобной Lisp, до момента преобразования в оптимизированный SQL-запрос, предшествующего его выполнению. При этом возникло много неизвестных и много различных сред, и никто не знал наверняка, как же поведет себя графический интерфейс пользователя.
Это был отличный повод для применения программы трассировки. Мы разработали «скелет» внешнего интерфейса, библиотеки для представления запросов и конструкцию для преобразования сохраненного запроса в запрос, определенный базой данных. Затем мы свели все воедино и проверили, работает ли это. Все, что мы могли сделать в первоначальном варианте, был запрос, который выдавал перечень всех строк в таблице, но он доказал, что интерфейс пользователя мог взаимодействовать с библиотеками, библиотеки могли преобразовать запрос в последовательную и параллельную форму, а из результата сервер мог сгенерировать SQL-запрос. На протяжении следующих месяцев мы постепенно разрабатывали основную конструкцию, добавляя новую функциональную возможность путем параллельного наращивания каждого компонента программы трассировки. Когда интерфейс пользователя добавлял новый тип запроса, библиотека увеличивалась, и генерация SQL-запроса становилась более утонченной.
Программа трассировки не является одноразовой: вы пишете ее, чтобы сохранить. Она содержит всю проверку ошибок, структурирование, документацию и самоконтроль, которые имеются в любом фрагменте рабочей программы. Она просто не обладает всеми функциональными возможностями. Однако, как только вы добились сквозного соединения между компонентами вашей системы, вы можете проверить, насколько близко вы находитесь к цели, и в случае необходимости сделать поправку. Как только вы попали в цель, добавление функциональных возможностей облегчается.
Разработка программ трассировки находится в согласии с той идеей, что проект никогда не кончается: всегда будет потребность в изменениях и добавлении функций. Это – инкрементальный подход.
Обычная альтернатива является своего рода тяжеловесным техническим подходом: программа разделяется на модули, которые программируются в вакууме. Модули объединены в подсистемы, которые затем подлежат дальнейшему объединению, пока в один прекрасный день вы не получаете завершенное приложение. И только тогда приложение в целом может быть представлено пользователю и протестировано. Технология программы трассировки имеет много преимуществ:

Пользователи могут увидеть нечто, работающее еще до выпуска окончательной версии.Если вам удалось передать суть делаемого вами (см. "Большие надежды"), то ваши пользователи будут осознавать, что видят перед собой еще нечто незрелое. Они не будут разочарованы отсутствием функциональных возможностей; будут гореть желанием увидеть некий видимый прогрессе создании их системы. По мере того как проект будет продвигаться, они начнут делать вложения. Эти пользователи и станут теми людьми, которые скажут вам о том, насколько близко к цели находится та или иная итерация.

Разработчики выстраивают некую структуру, в которой они работают.Наибольший страх вызывает лист бумаги, на котором ничего не написано. Если вы разработали все механизмы взаимодействия между модулями вашего приложения и воплотили их в тексте программы, то вашей команде не придется многое высасывать из пальца. Это делает труд каждого члена команды более производительным и способствует последовательности в их работе.

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

У вас есть что продемонстрировать.Спонсоры проекта и руководство стремятся увидеть демонстрационные версии в самое неподходящее время. При наличии программы трассировки у вас всегда будет то, что можно им продемонстрировать.

Вы лучше ощущаете прогресс.При разработке программы трассировки программисты работают над сценариями использования системы по очереди. Они заканчивают один сценарий и переходят к следующему. При этом гораздо проще определить производительность и продемонстрировать пользователю продвижение проекта. Поскольку каждая индивидуальная разработка меньше по объему, вы избежите создания монолитных программных блоков, о которых каждую неделю сообщается, что они готовы на 95 %.
При стрельбе трассирующими вы не всегда попадаете в цель
Трассирующие пули показывают, что вы куда-то попали. Это не обязательно должна быть ваша цель. Затем вы корректируете прицел, пока пули не попадают в цель. В этом-то все и дело.
То же самое относится и к программе трассировки. Вы используете методику в ситуациях, когда не уверены на 100 %, куда же вам двигаться. Не стоит удивляться, если две первых попытки сорвались: пользователь говорит: "Это совсем не то, что я имел в виду", нужные данные становятся недоступными в самый неподходящий мо-мент, и явно возникают проблемы с производительностью. Выработайте подход для изменения того, что мешает приблизиться к цели, и будьте благодарны судьбе, что вы используете скудную методологию разработки. Небольшой фрагмент программы отличается малой инерцией – его легко и быстро изменить. Вы сможете собрать отклики на ваше приложение и сгенерировать новую, более точную версию быстрее и дешевле. И поскольку каждый основной компонент приложения представлен в программе трассировки, ваши пользователи могут быть уверены – то, что они видят, основано на реальности, а не на бумажных спецификациях.
Программа трассировки и создание прототипов
Вы могли бы подумать, что принцип программы трассировки – это то же самое, что и чем создание прототипов, только с более агрессивным названием. Отличие есть. Цель работы с прототипом – исследование определенных характеристик (аспектов) конечной версии системы. Создавая истинный прототип, вы отбросите все то, что критиковали при опробовании принципа, и перепишете его надлежащим образом, используя полученные уроки.
Например, вы создаете приложение, которое помогает транспортным компаниям определять, как упаковывать ящики нестандартного размера в контейнеры. Помимо всего прочего, интерфейс пользователя должен быть интуитивно понятным, а алгоритмы, используемые для определения оптимальной упаковки, очень сложны.
Вы могли бы создать интерфейс для конечных пользователей при помощи соответствующих инструментальных средств. Вашей программы достаточно для того, чтобы сделать интерфейс восприимчивым к действиям пользователя. Как только пользователи согласятся с компоновкой интерфейса, вы можете отбросить его и переписать на этот раз на основе бизнес-логики, используя целевой язык. Аналогично, вы можете захотеть создать прототип ряда алгоритмов, которые осуществляют реальную упаковку. Вы можете запрограммировать функциональные тесты на высокоуровневом, «всепрощающем» языке типа Perl и затем запрограммировать низкоуровневые тесты производительности на языке, который более близок к машинному. В любом случае, как только вы приняли решение, необходимо начать сначала и запрограммировать алгоритмы в окончательной версии среды, которая взаимодействует с внешним миром. Это и есть создание прототипов, и это очень полезно.
Подход типа "стрельба трассирующими" обращается к иной проблеме. Вам необходимо знать, как работает приложение в целом. Вы хотите показать вашим пользователям, как на практике осуществляется взаимодействие, и дать им «скелет» архитектуры, на который наращивается тело программы. В этом случае вы можете сконструировать программу трассировки, состоящую из тривиальной реализации алгоритма упаковки контейнера (возможно, нечто вроде FIFO), и простой, но работающий интерфейс пользователя. Как только вы соедините все компоненты приложения, у вас уже есть каркас, который можно представить вашим пользователям и разработчикам. Спустя некоторое время вы добавляете к этому каркасу новую функциональную возможность, заменяя заглушки программами. Но сам остов остается нетронутым, и вы знаете, что система будет вести себя так же, как и в тот момент, когда завершалась первая программа трассировки.
Различие достаточно важно, чтобы гарантировать повторяемость. Прототипы генерируют одноразовую программу. Программа трассировки является скудной, но завершенной; она образует часть «скелета» конечной версии системы. Рассматривайте создание прототипов как рекогносцировку и сбор данных разведки до начала стрельбы трассирующими.
Другие разделы, относящиеся к данной теме:
• Приемлемые программы
• Прототипы и памятные записки
• Западня спецификации
• Большие надежды
11
Прототипы и памятные записки
Для опробования определенных идей во многих отраслях промышленности используются прототипы; это дешевле, чем организовывать полномасштабное производство. Например, в автомобильной промышленности для новой модели автомобиля может быть построено несколько различных прототипов. Каждый из них конструируется для проверки определенных свойств автомобиля – аэродинамики, дизайна, свойств конструкции и т. д. Для испытания в аэродинамической трубе изготовляется модель из глины, для отдела дизайна создается модель из бальзовой древесины и клейкой ленты и т. д. Некоторые автомобильные фирмы идут дальше и осуществляют значительную часть работы по моделированию при помощи компьютеров, что приводит к еще большему сокращению расходов. В этом случае нет необходимости в реальном изготовлении рискованных элементов конструкции для их опробования.
Мы создаем прототипы программ тем же образом и по тем же причинам – для анализа и выявления риска, предлагая возможности для коррекции при существенно меньших затратах. Подобно тому, как это делается в автомобильной промышленности, мы можем использовать прототип для опробования одного или нескольких характеристик проекта.
Мы склонны полагать, что основой прототипов являются программы, но не это не всегда так. Подобно тому, как это делается в автомобильной промышленности, мы можем строить прототипы из различных материалов. Памятные записки великолепно подходят для создания прототипов таких динамических объектов, как логика документооборота и прикладная логика. Прототип интерфейса может моделироваться на лекционной доске, как модель без функциональных возможностей, изображенная с помощью графической программы или программы-построителя интерфейса.
Прототипы разрабатываются для того, чтобы ответить лишь на несколько вопросов, поэтому их разработка намного дешевле и быстрее, чем приложения, которые идут в производство. Программа может игнорировать незначительные подробности – незначительные в данный момент, но позже могущие оказаться для пользователя очень важными. Если, к примеру, вы создаете прототип графического интерфейса пользователя, то можете смириться с неправильными результатами или данными. С другой стороны, если вы просто исследуете характеристики вычислений или производительности, можете обойтись скудным графическим интерфейсом пользователя или вообще без него.
Но если вы работаете в среде, где нельзя отказаться от подробностей, тогда необходимо спросить себя, а нужно ли вообще создавать прототип. Возможно, в этом случае лучше всего подходит стиль разработки типа "стрельба трассирующими" (см. "Стрельба трассирующими").
Для чего создаются прототипы
Какие объекты можно изучать при помощи прототипов? Все, что характеризуются наличием риска. Все, что не подвергались тестированию ранее или являются абсолютно критичными для конечного варианта системы. Вес, что является недоказанным, экспериментальным или сомнительным. Вес то, с чем вы еще не освоились. Вы можете создавать прототипы:
• Архитектуры
• Новой функциональной возможности уже существующей системы
• Структуры или содержания внешних данных
• Инструментальных средств или компонентов, выпущенных фирмами-субподрядчиками
• Рабочих характеристик
• Дизайна интерфейса пользователя
Создание прототипов способствует приобретению опыта.
Значение этого опыта заключается не в созданной программе, а в полученных уроках. В этом и состоит смысл создания прототипов.
Подсказка 16: Создавайте прототипы, чтобы учиться на них
Как использовать прототипы
Какими деталями можно пренебречь при построении прототипа?

Корректность.Там, где это приемлемо, вы сможете использовать фиктивные данные.

Завершенность.Прототип может функционировать лишь в ограниченном смысле, возможно, лишь с одним наперед заданным фрагментом входных данных и одним пунктом меню.

Надежность.Процедура проверки ошибок, вероятно, будет неполной или будет отсутствовать полностью. Если вы отклоняетесь от определенного пути, то прототип может выйти из строя и сгореть, как ракета. Это нормально.

Стиль.Неприятно признавать это, но прототип программы не имеет большого значения для комментариев или документации. При работе с прототипом можно написать горы документации, но сравнительно малая ее часть будет посвящена собственно прототипу системы.
Поскольку в прототипе детали отодвигаются на второй план, а в центре рассмотрения оказываются определенные аспекты системы, вам может показаться реальным создание прототипов с использованием языка очень высокого уровня – выше уровня языка остальной части проекта (язык типа Perl, Python или Tel). Язык сценариев высокого уровня позволяет опускать многие детали (включая указание типов данных) и при этом создавать функциональный (хотя и неполный и медленный) фрагмент программы
[11]. Если вам необходимо создать прототип интерфейсов пользователей, изучите инструментальные средства типа Tcl/Tk, Visual Basic, Powerbuilder или Delphi.
Языки сценариев хороши для использования в качестве «клея» при соединении низкоуровневых фрагментов в новые сочетания. При работе в системе 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: Программируйте ближе к предметной области вашей задачи
Мы полагаем, что вам следует рассмотреть способы перемещения вашего объекта ближе к предметной области проблемы – будь то простейший язык для конфигурирования и управления прикладной программой или же более сложный язык для обозначения правил или процедур. При составлении программы на более высоком уровне абстракции вам легко сосредоточиться на решении проблем предметной области и вы можете проигнорировать мелкие детали, связанные с реализацией.
Помните, что с приложением работают многие пользователи. Существует конечный пользователь, который понимает правила предметной области и то, что должно быть на выходе программы. Есть также вторичные пользователи: обслуживающий персонал, менеджеры, занимающиеся конфигурированием и тестированием, программисты служб поддержки и сопровождения и будущие поколения разработчиков. У каждого из этих пользователей есть собственная предметная область, и для всех них вы можете генерировать мини-среды и языки.
Ошибки, отражающие специфику предметной области
Если вы работаете в определенной предметной области, то можете осуществить и проверку правильности данных, характерных для нее, сообщая о проблемах языком, понятным вашим пользователям. Рассмотрим программу коммутации каналов, приведенную выше. Предположим, что пользователь неправильно обозначил наименование формата:
From X25LINE1 (Format=AB123)
Если подобное происходит в универсальном языке программирования, то выдается стандартное сообщение об ошибке:
Syntax error: undeclared identifier
Используя мини-язык, вместо этого можно создать сообщение об ошибке, используя словарь предметной области:
"АВ123" is not a format. Known formats are ABC123, XYZ43B, PDQB, and 42.
Реализация мини-языка
В самом простейшем варианте мини-язык может реализовываться в строчно-ориентированном, легко анализируемом формате. Практически мы используем эту форму больше, чем любую другую. Ее просто проанализировать при помощи инструкций switch или используя регулярные выражения в языках сценариев типа Perl. Ответ к упражнению 5 (Приложение В) показывает простую реализацию мини-языка на языке С.
Вы можете реализовать и более сложный язык с более формальным синтаксисом. Хитрость состоит в том, чтобы вначале определить синтаксис, используя систему обозначений, подобную нормальной форме Бэкуса-Наура
[12]. Как только вы определили грамматику, ее обычно легко преобразовать во входной синтаксис для генератора. Программисты, работающие с языками С и С++, давно используют уасс (или его бесплатную версию bison [URL 27]). Подробное описание этих программ приводится в книге "Lex and Yacc" [LMB92]. Программисты, работающие с языком Java, могут поработать с программой javaCC, которая находится на сайте [URL 26]. В ответе к упражнению 7 (Приложение В) дана программа грамматического разбора, написанная с помощью bison. Пример показывает, что как только вы изучите синтаксис, написание мини-языков не представит сложности.
Существует другой способ реализации мини-языка: расширить существующий. Например, можно интегрировать функциональные возможности на уровне приложения при помощи Python [URL 9] и написать нечто вроде
[13]:
record = X25UNE1.get(format=ABC123)
if (record.balanc<0):
X25UNE1.put(record, format=ABC123)
else:
TELSTR1.put(record, format=XYZ43B)
DB.store(record)
Языки управления данными и процедурные языки
Реализуемые вами языки могут использоваться двумя различными способами.
Языки управления даннымисоздают некую форму структуры данных, используемой приложением. Эти языки часто используются для представления конфигурации.
Например, программа sendmail применяется во всем мире для маршрутизации электронной почты в сети Интернет. Она обладает многими достоинствами и преимуществами, которые управляются огромным файлом конфигурации, написанном на собственном языке конфигурирования программы sendmail:
Mlocal, P=/usr/bin/procmail,
F=lsDFMAw5:/|@qSPfhn9,
S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=procmail -Y -a $h -d $u
Очевидно, удобочитаемость не является сильной стороной sendmail.
Уже давно фирма Microsoft использует язык данных, который может описывать меню, реквизиты окон, диалоговые окна и другие ресурсы Windows. На рис. 2.2 показан фрагмент типичного файла ресурсов. Он читается намного легче, чем пример с программой sendmail, но используется точно так же – компилируется для генерации структуры данных.
Рис. 2.2. Файл .rc для Windows
MAIN_MENU MENU
{
POPUP " &File"
{
MENUITEM "&New", CM_FILENEW
MENUITEM "&Open…", CM_FILEOPEN
MENUITEM "&Save", CM_FILESAVE
}
}
MY_DIALOG_BOX DIALOG 6,15,292,287
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "My Dialog Box"
FONT 8, "MS Sans Serif"
{
DEFPUSHBUTTON «OK», ID_OK, 232,16, 50,14
PUSHBUTTON «Help», ID.HELP, 232, 52, 50,14
CONTROL "Edit Text Control", ID EDIT1, "EDIT", WS_BODER | WS_TABSTOP, 16,16, 80, 56
CHECKBOX «Checkbox», ID CHECKBOX 1,153, 65,42,38, BS_AUTOCHECKBOX | WS_ABSTOP
}
Процедурные языкиидут дальше. В этом случае язык является исполняемым и поэтому может содержать инструкции, конструкции управления и т. п. (подобные сценарию на с. 50).
Вы также можете использовать собственные процедурные языки, чтобы облегчить сопровождение программы. Например, вас просят интегрировать информацию из унаследованного приложения в новую разработку графического интерфейса. Обычно это осуществляется при помощи "экранного кармана"; ваше приложение связывается с основным (mainframe) приложением так, как если бы это обычный пользователь-человек, генерируя нажатия клавиш и «считывая» принимаемые отклики. Вы можете создать сценарий взаимодействия при помощи мини-языка
[14].
locate prompt "SSN:"
type "%s" social_security_number
type enter
waitfor keyboardunlock
if text_at(10,14) is "INVALID SSN" return bad_ssn
if text_at(10,14) is "DUPLICATE SSN" return dup_ssn
# etc…
Когда приложение определяет, что пора вводить номер SSN, то по этому сценарию оно вызывает интерпретатор, который затем управляет транзакцией. Если интерпретатор встроен в приложение, то они даже могут совместно использовать данные (например, при помощи механизма обратного вызова).
В этом случае вы программируете в предметной области программиста сопровождения. Когда изменяется основное приложение и поля смещаются, программист может просто обновить высокоуровневое описание, вместо того чтобы копаться в подробностях программы на языке С.
Автономные и встроенные языки
Чтобы приносить пользу, мини-язык не должен использоваться приложением напрямую. Можно многократно использовать язык спецификации для создания искусственных объектов (включая метаданные), которые компилируются, считываются или используются самой программой иным образом (см. "Метапрограммирование").
Например, в разделе "Обработка текста" описывается система, в которой мы использовали Perl, чтобы генерировать большое количество выводов из первоначальной спецификации схемы. Мы изобрели общий язык, чтобы представить схему базы данных, и затем сгенерировали все его формы, которые нам необходимы, – SQL, С, интернет-страницы, XML и др. Приложение не использовало спецификацию напрямую, но оно полагалось на выходные данные, полученные из нее.
Обычной практикой является встраивание процедурных языков высокого уровня непосредственно в ваше приложение, так, чтобы они исполнялись, когда исполняется ваша программа. Очевидно, что это мощное средство; можно изменять поведение приложения, варьируя сценарии, которые оно считывает, причем все это
Несложная разработка или несложное сопровождение?
Мы рассмотрели несколько различных грамматик – от простых строчно-ориентированных форматов до более сложных, которые выглядят как реальные языки. Если для реализации требуются дополнительные усилия, тогда зачем выбирать более сложную грамматику?
Компромиссом являются расширяемость и сопровождение. В то время как программа грамматического разбора «реального» языка может быть более сложной в написании, для пользователя она будет намного понятнее, и ее будет легче расширить за счет добавления новых средств и функциональных возможностей. Слишком простые языки могут быть легкими для грамматического разбора, но они могут быть зашифрованными – подобно примеру с программой sendmail (см. "Языки управления данными и процедурные языки").
Учитывая, что срок службы большинства прикладных программ превышает ожидаемый, вам лучше примириться с суровой действительностью и принять заранее более сложный и удобочитаемый язык. Усилия, затраченные вначале, многократно окупятся за счет снижения затрат на поддержку и сопровождение.
Другие разделы, относящиеся к данной теме:
• Метапрограммирование
Вопросы для обсуждения
• Можно ли выразить некоторые из требований проекта, над которым вы работаете в настоящее время, на языке, отражающем специфику предметной области? Возможно ли написать компилятор или транслятор, который мог бы сгенерировать большую часть требуемой программы?
• Если вы решили принять мини-язык как способ программирования, близкий к предметной области, вы принимаете и то, что для их реализации потребуются некоторые усилия. Как выдумаете, есть ли способы, при которых «скелет», разработанный для одного проекта, может многократно использоваться в других?
Упражнения
5. Требуется реализовать мини-язык управления простым графическим пакетом (возможно, с графикой в относительных командах). Язык состоит из однобуквенных команд. После некоторых команд указывается число. Например, следующий фрагмент изображает на экране прямоугольник. (Ответ см. в Приложении В.)
Р 2 # select pen 2
D # pen down
W 2 # draw west 2cm
N 1 # then north 1
E 2 # then east 2
S 1 # then back south
U # pen up
Составьте программу, которая анализирует этот язык. Она должна быть разработана так, чтобы операция добавления новых команд была несложной.
6. Спроектируйте грамматику BNF (нормальной формы Бэкуса-Наура), чтобы провести грамматический разбор спецификаций времени. Все указанные примеры должны быть успешно проанализированы. (Ответ см. в Приложении В.)
4pm, 7:38pm, 23:42, 3:16, 3:16am
7. Реализуйте программу грамматического разбора для грамматики нормальной формы Бэкуса-Наура в упражнении 6, используя программы уасс, bison или аналогичный генератор грамматического разбора. (Ответ см. в Приложении В.)
8. Реализуйте программу грамматического разбора времени, используя Perl. (Подсказка: регулярные выражения позволяют написать хорошие программы грамматического разбора.) (Ответ см. в Приложении В.)
13
Оценка
Сколько времени потребуется для пересылки "Войны и мира" по модемной линии в 56 байт? Какое место займет на диске миллион имен и адресов? Сколько времени понадобится для прохождения 1000-байтового блока через маршрутизатор? Сколько месяцев потребуется, чтобы завершить ваш проект?
С одной стороны, все эти вопросы бессмысленны – информация, содержащаяся в них, недостаточна для ответа. И тем не менее, на все из них можно ответить, если вы сможете провести оценку. В процессе работы над генерацией оценки, вы придете к большему пониманию мира, в котором обитают ваши программы.
Научившись оценивать и развивая этот навык до уровня, на котором у вас появляется интуитивное ощущение величины того или иного предмета, вы сможете показать явно магическую способность к определению их выполнимости. Если кто-либо говорит: "Мы вышлем вам резервную копию по каналу ISDN в центральный офис", вы сможете интуитивно осознать, имеет ли это смысл. Когда вы составляете программу, вы сможете понять, какие подсистемы нуждаются в оптимизации, а какие нужно оставить в покое.
Подсказка 18: Проводите оценки во избежание сюрпризов
В конце данного раздела мы приведем единственно правильный ответ (в виде бесплатного приложения), который необходимо давать во всех случаях, когда вас просят оценить что-либо.
Насколько точной является "приемлемая точность"?
До некоторой степени все ответы представляют собой оценки. Просто некоторые из них точнее остальных. Так что первым вопросом, который вам придется задать самому себе, когда кто-либо просит вас об оценке, является вопрос о контексте, в котором будет приниматься данный вами ответ. Нужна ли здесь высокая точность, или речь идет о примерной цифре?
• Если ваша бабушка спрашивает, когда вы появитесь, она, вероятно, задается вопросом, готовить вам обед или ужин. С другой стороны, водолаз, оказавшийся в подводной ловушке и испытывающий недостаток воздуха, интересуется ответом с точностью до секунды.
• Каково значение числа «пи»? Если вас интересует, какое количество бордюрного камня понадобится для оформления цветочной клумбы, то цифра 3 вероятно будет приемлемой
[15]. На школьном уровне хорошим приближением является 22/7. Ну а если вы работаете в NASA, то двенадцати цифр после запятой будет вполне достаточно.
Одной из интересных особенностей оценки является тот факт, что интерпретация ее результата зависит от используемых вами единиц измерения. Если выговорите, что для некоего действия потребуется 130 рабочих дней, то люди будут ожидать наступления этого события в достаточно узком интервале. Но если вы скажете "около шести месяцев", они будут знать, что этого события следует ожидать через 5–7 месяцев. Обе цифры обозначают одну и ту же продолжительность, но "130 дней", вероятно, подразумевает большую точность, чем вы полагаете. Мы рекомендуем следующую градацию оценок времени:
Продолжительность == Оценка (порядок)
1-15 дней == дни
3-8 недель == недели
8-30 недель == месяцы
30 и более недель == перед тем, как оценить, стоит хорошенько подумать
Так, если после всей необходимой работы, вы придете к решению, что проект займет 125 рабочих дней (25 недель), он может быть оценен как "примерно за шесть месяцев".
Те же принципы применимы к оценкам любых количеств: выберите единицы, в которых будет дан ответ, чтобы отразить точность, которую вы намерены передать.
Из чего исходят оценки?
Все оценки основаны на моделях проблемы. Но перед тем как углубиться в методики построения моделей, необходимо упомянуть о главной хитрости, которая всегда дает хорошие результаты: спросите того, кто уже делал это. Перед тем как вплотную заняться построением модели, оглянитесь вокруг в поисках тех, кто ранее находился в подобной ситуации. Посмотрите, как они решали свою задачу. Маловероятно, что вы обнаружите точное совпадение, но будете удивлены, сколь часто вы успешно обращались к опыту других.
Понимание сути заданного вопроса
Первой частью любого упражнения в составлении оценки является понимание сути заданного вопроса. Как и в случае с вопросами точности, обсуждаемыми выше, вам необходимо осознать масштаб предметной области. Зачастую он неявно выражен в самом вопросе, но осознание масштаба, перед тем как начать строить предположения, должно войти у вас в привычку. Зачастую выбранная вами предметная область частично формирует ответ, который вы даете: "Если предположить, что по дороге не будет аварий и машина заправлена, я буду там через 20 минут".
Построение модели системы
Эта часть процесса оценки – самая интересная. Исходя из вашего понимания заданного вопроса, постройте в уме скелет действующей модели. Если вы оцениваете время отклика, то в вашей модели может иметься узел обслуживания и некий входной поток. При работе над проектом моделью могут послужить стадии, которые ваша организация использует в разработке, наряду с весьма грубым представлением того, как система может быть реализована.
Построение модели может быть творческим процессом, полезным в долгосрочной перспективе. Зачастую построение модели приводит к открытию схем и процессов, лежащих в основе чего-либо и не видимых невооруженным глазом. У вас даже может возникнуть желание повторно исследовать исходный вопрос: "Вы попросили дать оценку X. Однако, похоже, что У, являющийся вариантом X, может быть выполнен примерно в два раза быстрее, и при этом вы теряете лишь одну характеристику".
Построение модели вносит погрешности в процесс оценки. Это и неизбежно, и полезно. Вы жертвуете простотой модели ради точности. Удвоение усилий, прилагаемых к модели, может увеличить точность лишь незначительно. Ваш опыт подскажет вам, когда закончить процесс совершенствования.
<< | >>
Источник: Эндрю Хант. Программист-прагматик. Путь от подмастерья к мастеру. 2004

Еще по теме Упражнения:

  1. 6. Физические упражнения
  2. Упражнения
  3. Упражнения
  4. Психотерапевтические упражнения
  5. ПРАКТИЧЕСКОЕ УПРАЖНЕНИЕ В МЕТАФОРИЧЕСКОЙ СРЕДЕ
  6. ВИДЫ МЕТАФОРИЧЕСКИХ ИНТЕГРАЦИОННЫХ УПРАЖНЕНИЙ
  7. Упражнение 16. Придумывание имен
  8. Упражнение.
  9. Упражнение
  10. Упражнение 5. Развертка концептов
  11. Упражнения против стресса
  12. 13. ЗАДАЧИ И УПРАЖНЕНИЯ
  13. СТРУКТУРА КЛАССИЧЕСКОГО ИНТЕГРАЦИОННОГО УПРАЖНЕНИЯ