Предупреждение

Задачу уменьшения сложности труднее решить при использовании средств ускоренной разработки приложений (УРП). То, что сначала имеет вид относительно небольшого модуля, часто преврашается в универсальный модуль, который делает все подряд, разве что не готовит кофе, стоит только пользователям начать понемногу расширять функциональные возможности при анализе макета. Это нужно жестко контролировать.

Пакетная обработка

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

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

Ключ к реализации такого задания - построение управляюшей структуры для основного цикла и последуюшее жесткое отделение (инкапсуляция) каждого действия, выполняюшегося на каждой итерации цикла. Это позволяет модифицировать только одно из действий без воздействия на остальные. Для программиста может быть совершенно очевидно, что шаг 24 выполняется только в тех случаях, когда на шаге 17 выполняется определенное условие. Однако всем заинтересованным лицам (и особенно группе обслуживания) будет гораздо легче жить, если вы не обеспечите полную оптимизацию и не сделаете так, что шаг 17 оставит свое заключение в каком-то потайном месте, откуда его сможет взять шаг 24. Самое простое решение - заставить и шаг 17, и шаг 24 проверять базу данных на предмет выполнения вышеупомянутого условия (если повезет, то весь требуемый SQL-код и данные будут еше находиться в SGA). Если из-за того, что на этих шагах теперь приходится выбирать одни и те же данные для принятия того же самого решения, возникает серьезная проблема с эффективностью, то принятие этого решения следует инкапсулировать в процедуру, которая будет регистрировать (незаметно для этих шагов) факт выполнения необходимой обработки.

Отчеты

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

Оперативные приложения

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

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

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

л к с:

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

Следует ли выполнять макетирование?

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

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

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

Горячие споры о макетировании приложений ведутся уже много лет. Стоит ли макетировать? Какие цели при этом достигаются? Не задают ли макеты неприемлемо высокие уровни пользовательских ожиданий? Что делать с макетом - выбросить или, доработав, включить в состав системы? Не слишком ли это трудоемкое занятие?

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

Макетирование средствами УРП

Достоинство метода УРП состоит в том, что мы не теряем время на создание того, что потом придется выбросить. Кроме того, мы, как правило,