получаем работающую модель, а не рщ1; пустых экранных форм, не поддерживающих какие-либо функции. Мы испытываем процесс, а не просто демонстрируем экранные формы, которые являются не более чем схемами.

При всех своих достоинствах метод УРП обладает рядом значительных недостатков, среди которых можно назвать следующие:

Если разработанный данным методом код должен стать конечным продуктом, его следует создавать в соответствии со стандартами проекта. Это значит, что либо нужно подготовить эти стандарты до макетирования, либо понести затраты на переработку кода после создания стандартов. Конечно, такая переработка никогда не делается. Более вероятный сценарий - создание набора туманных стандартов, насильно приведенных б соответствие с существующим кодом.

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

Код, переработанный несколько раз, обычно отличается неупорядоченностью. Существует высокая вероятность наличия устаревшего кода, который никогда не вызывается, не используемых переменных, комментариев, не соответствующих действительности, и закомментированных фрагментов. Последовательность этого кода не так логична, как в случае, когда код создается набело .

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

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

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

времени для этого процесса - использовать ограничения временными рамками, упомянутые в главе 1. Еще один способ - установить для каждой экранной формы фиксированное число итераций, после которого изменения принимаются только при очень убедительном обосновании.

Пользуясь возможностями современных средств разработки четвертого поколения и УРП, достаточно легко придать данным привлекательный внешний вид - программа-художник позволяет нарисовать все, что нужно показать на экране. Но это, однако, не все. За кулисами таких экранных форм находится (или в конечном итоге будет находиться) база данных Oracle. Вы должны быть уверены, что она поддерживает структуры, которые так легко рисовать , и мы рекомендуем на самом деле выбирать все данные, отображенные в макетах, а не просто предполагать, что выборка возможна, и жестко программировать ее. Мы должны рассматривать базу данных как неустойчивую на период макетирования; она разрабатывается средствами УРП вместе с экранными формами. К сожалению, этот метод проектирования БД не всегда дает наилучший результат.

Проектировшики должны при разработке макетов постоянно помнить обо всех этих недостатках. Необходимо совершенствовать свои навыки генерации, потому что проектирование и генерация при разработке средствами УРП тесно переплетены. Вряд ли имеет смысл производить все итерации отдельно, а затем передавать результаты для генерации окончательного варианта, ведь на этот момент будет выполнено 90% всего объема работы.

Если бы хотите больше узнать о том, как корпорация Oracle относится к использованию УРП в среде Oracle, почитайте книгу CASE Methods FastTrack: А RAD Approach (Dai Clegg, Richard Barker. Addison Wesley, 1994).

Макетирование при разработке без использования средств УРП

В более традиционной среде разработки мы стоим перед выбором: макетировать или нет. В этой среде макетирование может служить двум очень разным, но важным целям:

оно помогает проектировщикам понять, как будет работать система (и будет ли);

оно позволяет уже на ранних стадиях проекта привлечь к работе конечных пользователей.

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

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

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

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

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

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

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

А ten