Проектирование модулей приложений

Введение

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

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

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

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

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

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

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

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

Анализ функциональной модели предметной области базы данных

Чтобы спроектировать модули приложений, необходимо знать, как будет работать информационная система с базой данных. Такую информацию можно получить из функциональной модели предметной области базы данных. Для проектирования модулей приложений проектировщику базы данных нужен набор спецификаций функций, которые задают необходимые требования к обработке бизнес-данных, а также набор зависимостей между различными бизнес-функциями.

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

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

Пример. Рассмотрим фрагмент иерархии функций для обработки заявлений о выплате страхового возмещения. На упрощенной схеме рис. 14.1 показана функция "2. Обработать заявление". Выполнение этой функции включает выполнение четырех функций следующего уровня: "2.1. Зарегистрировать заявление", "2.2. Принять решение по заявлению", "2.3. Произвести платеж по заявлению", "2.4. Закрыть заявление".

На рис. 14.1 показана дальнейшая декомпозиция функции "2.2. Принять решение по заявлению". Полученная на этом этапе функция "2.2.5. Разрешить ремонт" является атомарной функцией. Ремонт разрешается либо не разрешается.

Рис. 14.1. Иерархия функции для обработки заявлений о выплате страхового возмещения

При рассмотрении иерархии функций проектировщику базы данных следует обратить внимание на следующие моменты:

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