Структура и архитектура программного продукта

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

- Модуль интерфейса.

- Модуль входящего потока данных.

- Модуль исходящего потока данных.

Все модули образуют древовидный граф зависимостей. Корнем дерева является модуль интерфейса (рис. 2.8)

Рис. 2.8. Граф зависимостей между модулями

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

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

Рис. 2.9. Логическая структура базы данных

На (рис. 2.10) представлена информационно-логическая модель базы данных, реализованная в MySQL.

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

Рис. 2.10. Информационно логическая модель базы данных

База нормализована до третьего уровня, что предполагает:

-атомарность значений в полях данных;

- зависимость не ключевых полей от ключевых;

- отсутствие транзитивной зависимости в базе данных.

Объём внешней памяти, необходимый для функционирования системы определяется двумя составляющими: память, занимаемая модулями СУБД (ядро, утилиты, вспомогательные программы), и память, отводимая под данные (МД). Наиболее существенным обычно является МД. Объём памяти МД, требуемый для хранения данных, можно приблизительно оценить по формуле

где l_i – длина записи в i-й таблице (в байтах),

N_i – примерное (максимально возможное) количество записей в i-й таблице,

N_a – количество записей в архиве i-й таблицы.

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

Посчитаем приблизительно, какой объём внешней памяти потребуется для хранения данных. Примем ориентировочно, что:

- параллельно осуществляется около шести работ, работа над проектом продолжается круглый год (0,7К);

- в программе работает 6 сотрудников (0,3К на каждого сотрудника);

- в день обслуживается порядка двадцати документов (0,1К);

Тогда объём памяти для хранения данных за первый год примерно составит:

Mc = 2×(6×0,3+6×(6×0,7) +250×(20×0,1)) = 750К » 7,5 М,

где 250 – количество рабочих дней в году, а 12 мес./2 мес. = 6. Объём памяти будет увеличиваться ежегодно на столько же при сохранении объёма работы.

Объём памяти, занимаемый программными модулями пользователя, обычно невелик по сравнению с объёмом самих данных, поэтому его можно не учитываться. Требуемый объём оперативной памяти определяется на основании анализа интенсивности запросов и объёма результирующих данных. [21]

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

При помощи последних реализованы селективные и запросы удаления, изменения добавления данных в базе. Соединяющим звеном между базой данных и приложением является драйвер ODBC. (рис. 2.11).

В реализуемом проекте применен драйвер версии 5.1, тестируемые более ранние версии, работали с перебоями.

Рис. 2.11. ODBC connector, драйвер соединения