Опубликован: 02.08.2007 | Доступ: свободный | Студентов: 3887 / 751 | Оценка: 4.55 / 4.39 | Длительность: 27:09:00
ISBN: 978-5-9556-0111-3
Лекция 14:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Александра Каева
Александра Каева
Михаил Забелкин
Михаил Забелкин