Опубликован: 02.08.2007 | Уровень: специалист | Доступ: платный
Лекция 14:

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

Аннотация: В данной лекции рассматривается процесс составления спецификаций модулей приложений базы данных и начальная подготовка их к тестированию.
Ключевые слова: базы данных, проектирование баз данных, база данных, потребности пользователей, проектирование модулей приложений, модель предметной области, функциональная модель, физическая структура, поддержка, список, поле, функциональная модель предметной области, иерархия функций, спецификация модулей, отображение бизнес-требований в спецификации модулей, алгоритм, функция, атомарная функция, декомпозиция, аналитик, сущность предметной области, оценщик, информационная модель предметной области, матрица, экземпляр сущности, деструктор, CRUD, create, UPDATE, DELETE, ссылка, процесс обработки данных, диаграмма потока данных, диаграмма жизненного цикла, анализ работы, отображение множества, отображение, опыт, объектно-ориентированный подход, язык моделирования, UML, модуль, куратор проекта, бюджет проекта, руководитель проекта, приложение, принцип построения, Дополнение, логическая модель данных, итерация, физические модели данных, department, файл, пароль, поддержка ссылочной целостности, правила для данных, правила для интерфейса, правила для процессов, пользователь, представление, операции, анализ, интерфейс, структура данных, использование базы данных, формальный язык, администратор баз данных, цикла, идентификация пользователя, входные данные, имя пользователя, таблица, доступ, главная страница, экранная форма, список событий, браузер, навигация, тестировщик, вероятность, системное тестирование, опытная эксплуатация, разработка информационных систем, IBM, модель проектной группы, MSFS, ролевой кластер, программное обеспечение, команда, спецификация теста, automation, test case, билд, проектная группа, testing plan, quality, BAR, деятельность, test engineer, daily build, test report, группа, мониторинг, документирование, анализ тенденций, работ, шаблон, unified, сервер, архивация, поиск, печать, сервер баз данных, функциональное тестирование

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • в функциональной модели базы данных описываются бизнес-функции, и не все они будут непосредственно поддерживаться приложением базы данных;
  • при рассмотрении иерархий нередко возникает ситуация, когда экземпляры одной и той же функции будут иметь разные номера.
  • Если в первом случае дополнительную информацию о том, какие бизнес-функции будут реализованы в системе, можно получить от руководителя проекта, то во втором случае проектировщик базы данных, вероятнее всего, имеет дело с ошибкой аналитика в определении функции.
Александра Каева
Александра Каева
Михаил Забелкин
Михаил Забелкин
Виктория Бычкова
Виктория Бычкова
Россия, Ленинград, Ленинградская лесотехническая академия, 1988
Ivan Klepcsov
Ivan Klepcsov
Россия