Основы проектирования реляционных баз данных

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

Разбить на страницы
Показывать лекцию целиком

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Определение функций

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

    Пример. Определения функции "2.2.2. Проверить обеспечено ли заявление".

    "Получить и зарегистрировать все требуемые страховой компанией сведения о заявлении (СВЕДЕНИЯ О ЗАЯВЛЕНИИ), включая все подробные сведения о третьих сторонах (СТОРОННИЕ ЮРИДИЧЕСКИЕ ЛИЦА) и свидетелях (ФИЗИЧЕСКИЕ ЛИЦА).

    Изучить страховой полис (ПОЛИС) на предмет наличия исключительных ситуаций (ИСКЛЮЧЕНИЯ) и определить, действуют ли эти ситуации в случае данного заявления (ЗАЯВЛЕНИЕ).

    Если имеется исключение, то закрыть заявление и составить стандартное письмо заявителю об отказе в выплате (ПИСЬМО) заявителю (ЗАЯВИТЕЛЬ).

    Если никаких исключений нет, то изменить статус заявления на ожидание оценки, назначить и уведомить оценщика (ОЦЕНЩИК)."

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

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

    При выполнении анализа функций полезно иметь некоторую таблицу (матрицу) "Функция-Сущность". Эта матрица должна дать ответ на следующие вопросы:

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

    Процесс анализа взаимодействия функции и сущности принято обозначать аббревиатурой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление).

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

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

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

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

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

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

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

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

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

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

     (рис 14.2) Иерархия бизнес-функции "Управление проектами в организации" (рис 14.3) Перечень функции управления проектами в организации

    Задача состоит в отображении функций из перечня на рис. 14.3 в список модулей.

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

  • назначить куратора проекта;
  • известить руководителей подразделений;
  • известить сотрудников;
  • собрать совещание;
  • приступить к выполнению;
  • составить список работ;
  • определить объем работ;
  • определить стоимость работ;
  • определить время работ;
  • определить производственные мощности;
  • распределить производственные мощности;
  • распределить работы по сотрудникам;
  • контролировать ход выполнения проекта.
    •

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

    Списки функций и модулей
    Функции Модуль
    Назначить руководителяя проекта Ввод информации о проекте
    Определить бюджет проекта Ввод информации о сотрудниках
    Определить список подразделений Поиск информации о сотрудниках
    Определить список сотрудников Поиск информации о проектах
    Выполнять проект Генерация отчета о выполненных проектах
    Сдать проект Генерация отчета о выполняемых проектах

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

  • Какие проекты выполняются в организации?
  • Какие сотрудники в каком проекте участвуют?
  • Какими проектами кто руководит?
  • Какие проекты выполнялись в организации?
  • Какие сотрудники в каком проекте участвовали?
  • Какими проектами кто руководил?
    •

    Проектировщик базы данных составил список модулей приложения базы данных (правая колонка таблицы 14.1) и установил отображение функций в модули, как показано на рис. 14.4.

    (рис 14.4) Отображение функции в модули

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

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

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

    Пример. Рассмотрим модуль "Ввод информации о сотрудниках" из предыдущего примера и составим для него схему "модули-данные". При этом мы используем схему базы данных, приведенную на рис. 14.5.

     (рис 14.5) Физическая модель базы данных

    Один из возможных результатов, который может быть получен проектировщиком базы данных, приведен в таблице 14.2.

    Фрагмент схемы "модули-данные"
    Модуль Таблица Колонки Состояние колонки
    Ввод информации о сотрудниках Employee Empno Чтение
    Ename Чтение, Поиск
    Lname Чтение, Поиск
    Job Чтение
    Sal Чтение
    Depno Чтение, Поиск
    Department Depno Чтение, Поиск
    Manager Чтение

    Системные модули

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

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

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

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

    Размещение логики обработки

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

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

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

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

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

    Примерами правил для данных являются следующие:

  • Пол человека должен быть либо мужской, либо женский. Это правило может быть введено с помощью ограничения CHECK в определении колонки таблицы базы данных.
  • Каждый заказ должен быть предназначен для одного и только одного покупателя. Это правило для данных можно ввести с помощью ограничений PRIMERY KEY или NOT NULL.
    •

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

    Примерами правил для процессов являются следующие:

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

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

    Примерами правил для интерфейса являются следующие:

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

    Некоторые сформулированные правила бывают составными, а их составные части относятся к разным группам правил. Например, рассмотрим правило:

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

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

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

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

    Остановимся кратко на основных принципах размещения бизнес-логики в модулях приложения базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Пароль

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

    Колонки:

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

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

    Действия:

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

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

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

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

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

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

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

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

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

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

    Навигация:

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

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

    Действия:

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

    Таблицы:

    Таблица tblProjEMP
    Имя поля Содержание Использование
    ENPID Внутренний номер служащего INSERT
    PROJID Внутренний номер проекта INSERT
    TN табельный номер (из представления)
    NM ФИО INSERT
    PS Должность
    GR Разряд
    DR Ученая степень
    ZV Ученое знание
    JOB Занятость в проекте в мес. INSERT
    EMPSTATUS Статус исполнителя INSERT
    Таблица tblEmpl
    Имя поля Содержание Использование
    ENPID Внутренний номер служащего
    TN табельный номер (из представления)
    NM ФИО Предикат поиска
    PS Должность
    GR Разряд
    DR Ученая степень
    ZV ученое звание

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

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

    Ошибки:

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

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

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

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

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

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

  • Автономные тесты (тесты модулей).
  • Тесты связей модулей.
  • Системный тест для приложения базы данных в целом.
  • Приемо-сдаточные испытания (которые может проводить заказчик).
  • Тесты производительности.
    •

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

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

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

    Рассмотрим подход, который основан на модели проектной группы Модель MSF версии 3.1, предлагаемой компанией Microsoft. В этой методике предусмотрен так называемый ролевой кластер "Тестирование".

    Задача ролевого кластера "Тестирование" (test) - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Обнаружение и устранение дефектов может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом - как для проектной команды, так и для заказчика.

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

  • Планирование тестов:
  • разработка методологии и плана тестирования;
  • участие в установлении стандарта качества (quality bar);
  • разработка спецификаций тестов.
    •
  • Разработка тестов:
  • разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов;
  • проведение тестов с целью определения состояния проекта;
  • управление билдами (manage the build process).
  • Отчетность о тестах:
  • доведение до сведения проектной группы информации о качестве продукта;
  • мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.

    • Планирование тестов. Данная область компетенции (планирование тестов - test planning) ролевого кластера "Тестирование" формулирует методологию нахождения и урегулирования проблем качества продукта.

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

    Существенная часть работы данной области компетенции заключается в участии в выработке требуемого уровня качества (quality bar) продукта. Эта деятельность включает в себя предоставление проектной группе метрик контроля качества и критериев успешности решения.

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

    Разработка тестов. Эта область компетенции (разработка тестов - test engineering) ответственна за предусмотренные планом тестирования мероприятия, направленные на нахождение и урегулирование всех проблем качества создаваемого продукта. В их числе - работа по созданию и поддержке тестовых сценариев (test cases), разработка средств, скриптов и документации процесса тестирования, управление ежедневными билдами (daily builds), проведение на них тестов с целью четкого определения уровня завершенности продукта.

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

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

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

    В заключение раздела рассмотрим некоторые практические рекомендации проектировщикам базы данных при разработки стратегии тестирования.

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

    Стратегия тестирования должна отвечать на следующие вопросы:

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

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

    Из стратегии тестирования органично выписывается план тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестирования или же включают описание стратегии в пункты плана, отвечающие за тестирование конкретных частей функционала. К примеру, шаблон методологии Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.

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

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

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

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

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

    Клиент: 50 тестов на работу с данными (ввод форм, расчет данных на основе данных, хранимых в словарях, поиск данных, редактирование словарей и т.п.), 10 тестов на работу с печатными формами (формирование периодов выборок, выбор типов отчетов, печать или экспорт в предопределенный список форматов и т.д.). Пусть для тестирования работы с системой требуется еще 5 тестов. Для проверки функциональности, связанной с самой операционной системой, потребуется (5 + 10)*2 = 30 тестовых прогонов. Будем считать, что 50 тестовых прогонов будет достаточно для проверки логики работы с данными. Итог - 80 тестовых прогонов для тестирования клиента системы.

    Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учета работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчетов и еще несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, чтобы проверить работоспособность серверного функционала системы. Итог - 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идет только о функциональном тестировании.

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

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

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

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

    Литература: [9], [17], [18], [19], [22], [30], [33], [45].

    Страницы:

    Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Определение функций

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

    Пример. Определения функции "2.2.2. Проверить обеспечено ли заявление".

    "Получить и зарегистрировать все требуемые страховой компанией сведения о заявлении (СВЕДЕНИЯ О ЗАЯВЛЕНИИ), включая все подробные сведения о третьих сторонах (СТОРОННИЕ ЮРИДИЧЕСКИЕ ЛИЦА) и свидетелях (ФИЗИЧЕСКИЕ ЛИЦА).

    Изучить страховой полис (ПОЛИС) на предмет наличия исключительных ситуаций (ИСКЛЮЧЕНИЯ) и определить, действуют ли эти ситуации в случае данного заявления (ЗАЯВЛЕНИЕ).

    Если имеется исключение, то закрыть заявление и составить стандартное письмо заявителю об отказе в выплате (ПИСЬМО) заявителю (ЗАЯВИТЕЛЬ).

    Если никаких исключений нет, то изменить статус заявления на ожидание оценки, назначить и уведомить оценщика (ОЦЕНЩИК)."

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

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

    При выполнении анализа функций полезно иметь некоторую таблицу (матрицу) "Функция-Сущность". Эта матрица должна дать ответ на следующие вопросы:

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

    Процесс анализа взаимодействия функции и сущности принято обозначать аббревиатурой CRUD (Create, Reference, Update, Delete - создание, ссылка, модификация, удаление).

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

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

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

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

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

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

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

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

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

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

     (рис 14.2) Иерархия бизнес-функции "Управление проектами в организации" (рис 14.3) Перечень функции управления проектами в организации

    Задача состоит в отображении функций из перечня на рис. 14.3 в список модулей.

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

  • назначить куратора проекта;
  • известить руководителей подразделений;
  • известить сотрудников;
  • собрать совещание;
  • приступить к выполнению;
  • составить список работ;
  • определить объем работ;
  • определить стоимость работ;
  • определить время работ;
  • определить производственные мощности;
  • распределить производственные мощности;
  • распределить работы по сотрудникам;
  • контролировать ход выполнения проекта.
    •

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

    Списки функций и модулей
    Функции Модуль
    Назначить руководителяя проекта Ввод информации о проекте
    Определить бюджет проекта Ввод информации о сотрудниках
    Определить список подразделений Поиск информации о сотрудниках
    Определить список сотрудников Поиск информации о проектах
    Выполнять проект Генерация отчета о выполненных проектах
    Сдать проект Генерация отчета о выполняемых проектах

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

  • Какие проекты выполняются в организации?
  • Какие сотрудники в каком проекте участвуют?
  • Какими проектами кто руководит?
  • Какие проекты выполнялись в организации?
  • Какие сотрудники в каком проекте участвовали?
  • Какими проектами кто руководил?
    •

    Проектировщик базы данных составил список модулей приложения базы данных (правая колонка таблицы 14.1) и установил отображение функций в модули, как показано на рис. 14.4.

    (рис 14.4) Отображение функции в модули

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

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

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

    Пример. Рассмотрим модуль "Ввод информации о сотрудниках" из предыдущего примера и составим для него схему "модули-данные". При этом мы используем схему базы данных, приведенную на рис. 14.5.

     (рис 14.5) Физическая модель базы данных

    Один из возможных результатов, который может быть получен проектировщиком базы данных, приведен в таблице 14.2.

    Фрагмент схемы "модули-данные"
    Модуль Таблица Колонки Состояние колонки
    Ввод информации о сотрудниках Employee Empno Чтение
    Ename Чтение, Поиск
    Lname Чтение, Поиск
    Job Чтение
    Sal Чтение
    Depno Чтение, Поиск
    Department Depno Чтение, Поиск
    Manager Чтение

    Системные модули

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

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

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

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

    Размещение логики обработки

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

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

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

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

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

    Примерами правил для данных являются следующие:

  • Пол человека должен быть либо мужской, либо женский. Это правило может быть введено с помощью ограничения CHECK в определении колонки таблицы базы данных.
  • Каждый заказ должен быть предназначен для одного и только одного покупателя. Это правило для данных можно ввести с помощью ограничений PRIMERY KEY или NOT NULL.
    •

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

    Примерами правил для процессов являются следующие:

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

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

    Примерами правил для интерфейса являются следующие:

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

    Некоторые сформулированные правила бывают составными, а их составные части относятся к разным группам правил. Например, рассмотрим правило:

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

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

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

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

    Остановимся кратко на основных принципах размещения бизнес-логики в модулях приложения базы данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Пароль

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

    Колонки:

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

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

    Действия:

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

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

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

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

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

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

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

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

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

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

    Навигация:

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

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

    Действия:

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

    Таблицы:

    Таблица tblProjEMP
    Имя поля Содержание Использование
    ENPID Внутренний номер служащего INSERT
    PROJID Внутренний номер проекта INSERT
    TN табельный номер (из представления)
    NM ФИО INSERT
    PS Должность
    GR Разряд
    DR Ученая степень
    ZV Ученое знание
    JOB Занятость в проекте в мес. INSERT
    EMPSTATUS Статус исполнителя INSERT
    Таблица tblEmpl
    Имя поля Содержание Использование
    ENPID Внутренний номер служащего
    TN табельный номер (из представления)
    NM ФИО Предикат поиска
    PS Должность
    GR Разряд
    DR Ученая степень
    ZV ученое звание

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

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

    Ошибки:

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

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

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

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

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

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

  • Автономные тесты (тесты модулей).
  • Тесты связей модулей.
  • Системный тест для приложения базы данных в целом.
  • Приемо-сдаточные испытания (которые может проводить заказчик).
  • Тесты производительности.
    •

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

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

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

    Рассмотрим подход, который основан на модели проектной группы Модель MSF версии 3.1, предлагаемой компанией Microsoft. В этой методике предусмотрен так называемый ролевой кластер "Тестирование".

    Задача ролевого кластера "Тестирование" (test) - одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены. Любое программное обеспечение содержит дефекты. Обнаружение и устранение дефектов может подразумевать различные решения, начиная от устранения и заканчивая документированием способов обхода дефекта. Поставка продукта с известным дефектом, но с описанием способов его обхода является более предпочтительной, чем поставка продукта с невыявленным дефектом, который в дальнейшем станет сюрпризом - как для проектной команды, так и для заказчика.

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

  • Планирование тестов:
  • разработка методологии и плана тестирования;
  • участие в установлении стандарта качества (quality bar);
  • разработка спецификаций тестов.
    •
  • Разработка тестов:
  • разработка и поддержка автоматизированных тестов (automated test cases), инструментов и скриптов;
  • проведение тестов с целью определения состояния проекта;
  • управление билдами (manage the build process).
  • Отчетность о тестах:
  • доведение до сведения проектной группы информации о качестве продукта;
  • мониторинг найденных ошибок с целью обеспечения их улаживания до выпуска продукта.

    • Планирование тестов. Данная область компетенции (планирование тестов - test planning) ролевого кластера "Тестирование" формулирует методологию нахождения и урегулирования проблем качества продукта.

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

    Существенная часть работы данной области компетенции заключается в участии в выработке требуемого уровня качества (quality bar) продукта. Эта деятельность включает в себя предоставление проектной группе метрик контроля качества и критериев успешности решения.

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

    Разработка тестов. Эта область компетенции (разработка тестов - test engineering) ответственна за предусмотренные планом тестирования мероприятия, направленные на нахождение и урегулирование всех проблем качества создаваемого продукта. В их числе - работа по созданию и поддержке тестовых сценариев (test cases), разработка средств, скриптов и документации процесса тестирования, управление ежедневными билдами (daily builds), проведение на них тестов с целью четкого определения уровня завершенности продукта.

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

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

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

    В заключение раздела рассмотрим некоторые практические рекомендации проектировщикам базы данных при разработки стратегии тестирования.

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

    Стратегия тестирования должна отвечать на следующие вопросы:

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

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

    Из стратегии тестирования органично выписывается план тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестирования или же включают описание стратегии в пункты плана, отвечающие за тестирование конкретных частей функционала. К примеру, шаблон методологии Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.

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

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

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

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

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

    Клиент: 50 тестов на работу с данными (ввод форм, расчет данных на основе данных, хранимых в словарях, поиск данных, редактирование словарей и т.п.), 10 тестов на работу с печатными формами (формирование периодов выборок, выбор типов отчетов, печать или экспорт в предопределенный список форматов и т.д.). Пусть для тестирования работы с системой требуется еще 5 тестов. Для проверки функциональности, связанной с самой операционной системой, потребуется (5 + 10)*2 = 30 тестовых прогонов. Будем считать, что 50 тестовых прогонов будет достаточно для проверки логики работы с данными. Итог - 80 тестовых прогонов для тестирования клиента системы.

    Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учета работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчетов и еще несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, чтобы проверить работоспособность серверного функционала системы. Итог - 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идет только о функциональном тестировании.

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

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

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

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

    Литература: [9], [17], [18], [19], [22], [30], [33], [45].

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^