Отображение функций в модули
Одной из основных задач проектирования модулей приложений является построение отображения функций в модули. При решении этой задачи проектировщик базы данных должен акцентировать внимание на структуре базы данных, которая составляет основу приложения.
Как правило, решение задачи отображения функций в модули решается в четыре этапа:
- Анализ работы функции.
- Построение модели сущностей, поддерживающей эти функции.
- Начать проектирование физической структуры с создания схемы, поддерживающей разработанную модель сущностей.
- Завершить проектирование разработкой спецификаций модулей, которые реализуют функции на предложенной схеме базы данных.
Из предложенного выше подхода видно, как тесно переплетаются в процессе проектирования процессы разработки физической модели базы данных и спецификаций модулей приложений. Таким образом, если проектировщиком был разработан черновой вариант физической модели базы данных по алгоритмам, рассмотренным нами в предыдущих лекциях, то на этом этапе он должен быть адаптирован к реализации функций и, возможно, значительно переработан.
К сожалению, никаких унифицированных и простых способов отображения функций в модули приложений не существует. Это обусловлено двумя обстоятельствами: комбинаторной сложностью построения отображений множеств (теоретически доказано, что для такого класса комбинаторных задач не существует в общем случае алгоритмов с линейной сходимостью) и сложностью выработки критерия того, что полученное отображение оптимально (т.е. довольно широкий семантический произвол в обосновании вариантов того или иного отображения). Как показывает опыт проектирования, мнение относительно состава и количества модулей приложений в процессе проектирования меняется неоднократно.
В последнее время хорошие результаты в разработке и проектировании систем и, в частности, модулей приложений получены с применением объектно-ориентированного подхода на основе унифицированного языка моделирования 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 | Чтение | ||