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

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

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

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

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

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

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

Спецификация модуля должна обязательно включать следующее:

• Условное название модуля.
• Функции, выполнение которых обеспечивает данный модуль.
• Список таблиц и колонок, к которым производится доступ.
• Для каждой колонки - способ использования колонки, а именно, запрашиваются ли, вставляются, удаляются ли, обновляются ли данные указанных колонок.
• Список колонок, которые используются в предикатах поиска.
• Конкретное описание того, что модуль должен делать.

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

Наименование модуля: Страница для входа в приложение (LogIn).

Цель: идентификация пользователя и предоставление доступа к приложению базы данных.

Входные данные

Имя пользователя

Пароль

Таблица базы данных: USERACCOUNT

Колонки:

USERNAME - запрашивается, используется в предикате поиска

USERPASS - запрашивается, используется в предикате поиска

Действия:

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

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

Комментарий:

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

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

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

Наименование экранной формы: Web-страница Форма 3: Список исполнителей.

Цель: приписать исполнителей к проекту, определить их занятость и статус.

Входные данные

• Номер проекта

Навигация:

Вызывается из модуля "Редактирование Формы 1".

Возвращает управление в модуль "Редактирование Формы 1".

Действия:

• Выбрать из списка исполнителя
• Определить его статус - основной, неосновной, руководитель
• Определить занятость исполнителя
• Сохранить запись об исполнителе
• Перейти на ввод данных о следующем
• Возвратить на редактирование Формы 1.

Таблицы:

Требования к макету страницы:

• Должен быть раскрывающийся список, содержащий ФИО сотрудников, из которого осуществляется выбор сотрудника для участия в проекте.
• Кнопка, инициирующая действие по сохранению данных в таблице базы данных, должна располагаться вверху и внизу страницы.
• Возврат в вызывающий модуль должен происходить через кнопку, расположенную слева вверху страницы.

Ошибки:

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

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