в .ituoii г.июе:

Ре.а/льтаты

Отображение фупнцпй в модули

IJr забудьте о систе.мпыл-модулнх

У]1равлеш1е ac.voduiti.v h-odoM и версиями

Шаблоны кода

Проеьптроваине процееса аистиропапая

Неиользование QiSE-epcdcHio

Введение в проектирование

кода

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

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

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

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

Как проектировать модули кода? Обычно это делается в несколько этапов, причем на каждом вносятся уточнения, основанные на опыте и знании того, как будет работать система. Часто уточнение является прямым следствием создания макетов в процессе проектирования.

Результаты анализа

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

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

Иерархии функций

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

/10П