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

Номер колонки в таблице

Y - видимая колонка, N- невидимая

Ширина колонки в пикселях

Выравнивание колонки: 0-по левому краю, 1-по правому краю, 2- по центру.

Шрифт

Размер шрифта

Цвет шрифта

Стиль шрифта

Заголовок колонки

Шрифт заголовка

Размер шрифта заголовка

Цвет шрифта заголовка

Стиль шрифта заголовка

Форат вывода на экран

Кем создана запись

Дата создания записи

Кем модифицирована запись

Когда модифицирована запись



2.3 Разработка сервера приложений

2.3.1 Алгоритм работы сервера приложений

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

На рисунке 2.5 изображена структура лежащая в основе прототипа сервера приложений.

86

Размещено на http://www.allbest.ru/

Рисунок 2.5 - Структура сервера приложений

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

SELECT [список столбцов]

FROM [список таблиц]

WHERE [условие отбора];

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

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

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

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

1) происходит выделение отдельной лексемы (возможно, используя символы-разделители);

2) если выделенная лексема - ограничитель, то он (точнее, некоторый его признак) выдается как результат лексического анализа;

3) ключевые слова распознаются явным выделением непосредственно из текста.

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

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

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



2.3.2 Разработка интерфейса сервера приложений

Построение трехзвенной архитектуры в Delphi 7 может быть реализовано с помощью различных технологий DCOM, MTS, CORBA, SOAP. При разработке сервера приложений была использована технология DCOM (Distributed Component Object Model). Технология DCOM является развитием базовой технологии COM корпорации Microsoft. Её безусловным достоинством является близость с операционной системой Windows и простота реализации, так как основные инструменты этой технологии представляют собой неотъемлемые части ОС Windows, в которой и планируется эксплуатация разрабатываемой системы. Технология DCOM наилучшим образом подходит для реализации поставленной задачи, потому что она акцентирует внимания на ключевых моментах связи между клиентом и сервером приложений.

Рисунок 2.1 - Схема алгоритма работы сервера приложений



Сервер приложений является DCOM-компонентом. Компонент TRemoteDataModule служит основой для создания сервера приложений, использующего технологию COM/DCOM. Сервер приложений подобно серверу базы данных может одновременно обслуживать нескольких пользователей. Для каждого запроса клиента создается свой экземпляр объекта TRemoteDataModule, что исключает конфликты в многопользовательской среде. С помощью мастера модуля можно уточнить взаимодействие сервера приложений с множеством пользователей. Можно выбрать режим наследования и модель потоков команд.

Сервер приложений инкапсулирует интерфейс IAppServer, методы которого используются в механизме удаленного доступа клиентов к серверу БД. Обмен данными сервера приложения с клиентами обеспечивает динамическая библиотека MIDAS.DLL, которая должна быть зарегистрирована на компьютере сервера приложения.

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

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

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

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

В среде программирования Delphi существуют уже готовые компоненты, реализующих обмен данными между клиентским и серверным приложениями. На объекте класса TRemoteDataModule размещаем компонент TDataSetProvider. Данный компонент связан с одним из объектов класса TQuery, TTable и TStoredProc, а через них - с таблицами, запросами и хранимыми процедурами базы данных. С другой стороны он является источником данных для объектов класса TClientDataSet на стороне клиента.

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

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

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

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

2.3.3 Разработка процедур и функций сервера приложений

Разрабатываемый сервер приложений базируется на классе TJobs, который является потомком класса TRemoteDataModule и реализует методы интерфейса IJobs. IJobs в свою очередь является наследником интерфейса IAppServer.

Рисунок 2.7 - Компонентная организация обмена данными системы

IJobs = interface(IAppServer)

function ExecQuery(const SqlCmd: WideString): WideString; safecall;

function SelectQuery(const SqlCmd: WideString): OleVariant; safecall;

function AppSrvConnect(const hostname: WideString; const username: WideString; const pwd: WideString): WideString; safecall;

function AppSrvInit(const DBSrvName: WideString; const username: WideString; const pwd: WideString): WideString; safecall;

end;

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

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

Так как удаленный модуль данных реализует сервер Автоматизации, дополнительно к основному дуальному интерфейсу IJobs автоматически создан интерфейс диспетчеризации IJobsDisp. При этом для интерфейса диспетчеризации созданы методы, соответствующие методам интерфейса IAppServer.

Класс CoJobs обеспечивает создание СОМ-объектов, поддерживающих использование интерфейса. Для него автоматически созданы два метода класса:

1) class function CoJobs.Create: IJobs; Используется при работе с локальным и внутренним сервером (in process);

2) class function CoJobs.CreateRemote(const MachineName: string): IJobs; Используется в удаленном сервере.

Оба метода возвращают ссылку на интерфейс IJobs.

Разработанный сервер приложений кэширует проходящие через него данные. Для организации хранения этих данных в памяти используется компонент TMemoryStream. Экземпляр класса TMemoryStream создает поток, который сохраняет данные в память. Информация хранится в куче с возможностью изменения максимального объема хранимой информации и задания размеров используемых блоков памяти. Процедура RemoteDataModuleCreate(Sender: TObject) создает данный поток при инициализации сервера приложений. Процедура RemoteDataModuleDestroy(Sender: TObject) уничтожает поток закэшированных данных при завершении работы сервера приложений, чтобы уже ненужные данные не весели в памяти.

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

Процедура ModifyUserInfo(UserName, HostName, PID : string) изменяет информацию о подключении клиентских приложений к серверу приложений.

Процедура DisconnectUserInfo(DBServerName, UserName, HostName, PID : string) записывает изменения при отключении пользователя от сервера приложений.

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

Процедура GetParamsFromCommandText (var SqlCmd: string; out ParametersArray: DynArrayOfVariant) является базовой функцией синтаксического анализа сервера приложений. На вход данного метода поступает запрос пользователя в виде строки SqlCmd. Полученная строка передается в функцию Trim(s: string): string, которая удаляет лишние пробелы из строки. В разработанном сервере приложений было решено продемонстрировать основную функциональность на запросе по выборке данных (Select {*[имя столбца]} From {имя таблицы| имя процедуры (параметры…)}). Как уже упоминалось выше, вместо имени таблицы можно задавать имя процедуры для вызова из модуля бизнес-логики.

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

2.3.4 Разработка средств администрирования сервера приложений

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

При запуске сервера приложений автоматически запускается средство администрирования сервера приложений - монитор, который представлен на рисунке 2.8.

Рисунок 2.8 - Интерфейс монитора сервера приложений

Главная форма монитора сервера приложений содержит 2 вкладки: «Пользователи» и «Протокол».

На вкладке «Пользователи» представлена таблица, которая отображает следующую информацию (по столбцам):

1) «PID» - идентификатор пользователя;

2) «Пользователь» - имя пользователя, оно вводится в клиентской части при подключении к серверу приложений;

3) «Компьютер» - имя компьютера в сети, с которого подключился пользователь;

4) «Время подключения» - отображает системное время компьютера сервера приложения в момент подключения пользователя;

5) «Количество запросов» - количество sql-запросов, поступивших на сервер приложений от данного пользователя;

6) «Время последнего запроса» - отображает системное время компьютера сервера приложения в момент получения от данного пользователя последнего sql-запроса;

7) «Время отключения» - отображает системное время компьютера сервера приложения в момент завершения работы клиентского приложения пользователя.

Строка состояния (TStatusBar) отображает состояние сервера приложений:

– «Неактивен» означает, что сервер приложений не подключен к базе данных;

– «Активен» означает, что сервер приложений подключен к базе данных и готов принимать и обрабатывать sql-запросы от пользователей.

При нажатии на кнопку «Инициализация» появляется модальное окно для авторизации подключения к базе данных (рисунок 2.9).

Рисунок 2.9 - Окно авторизации

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

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

Рисунок 2.10 - Пример заполнения протокола

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

Для администрирования конфигурационной базы данных была разработано приложения «Администратор БД» (рисунок 2.11).

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

Рисунок 2.11 - Администратор БД

2.3.2 Разработка интерфейса модуля бизнес-логики

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

Получив команду загрузить программу, операционная система создает процесс, который располагает 4 Гбайт виртуальной памяти, в которой выполняется программа. После создания процесса создается объект отображения файла, который отображает выполняемый файл в адресное пространство процесса. Выполняемый файл именно отображается с жесткого диска, минуя загрузку всего образа в RAM или копирование в страничный файл. После отображения выполняемого файла в память ОС по заданному смещению от начала образа переходит к адресу, в котором записаны имена всех DLL, используемых данным EXE-модулем. Все DLL разыскиваются в системе и отображаются в тот же процесс. При этом для каждой DLL создается свой объект отображения файла. Если некоторые DLL обращаются, в свою очередь, к другим DLL, последние также отображаются в адресное пространство программы.

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

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

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

function GetModuleInfo (ModelInfo:TModelInfo):string; stdcall;

function GetProc(procname:string):string; stdcall;

Функция GetModuleInfo предназначена для передачи серверу информации о загружаемом модуле бизнес-логики и принимает указатель на структуру TModelInfo, которую должна заполнить:

TModelInfo = record

description : string;

version : double;

end;

Поле description содержит описание вызываемой DLL, а version номер версии.

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

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

Модуль бизнес-логики MemoryProc.dll содердит необходимые процедуры и функции по обработке нереляционных запросов.

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

procedure GetDataFromMemory(var CDSetBuf : TClientDataSet; ParamsList : DynArrayOfVariant);

ParamsList содержит массив параметров различного типа, заданных в текстовом виде. На основе данного массива составляется SQL-запрос на выборку к базе данных. Выходные данные, полученные в результате выполнения запроса, необходимо преобразовать в формат XML, чтобы в дальнейшем добавить их в клиентский набор данных CDSetBuf. Это преобразование происходит при помощи метода XMLFieldDescription.

procedure XMLFieldDescription (FieldName, FieldType : string;Length : integer=0);

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

Поскольку значения типов полей могут различаться для различных СУБД, составим таблицу кодировки типов данных в XML-документе (таблица 2.11).

Таблица 2.11

Кодировка типов данных в XML-документе.

Тип данных в СУБД	Код типа данных в XML-документе
INTEGER	i4
SMALLINT	i2
FLOAT	r2
DOUBLE	r4
NUMERIC	r8
DECIMAL	r10
DATE	dateTime
CHAR(10)	string
VARCHAR(10)	string

Процедура MakeRecordSet формирует и возвращает строку, содержащую описание набора записей (RecordSet) в формате XML:

procedure MakeRecordSet(var CDSetBuf : TClientDataSet);

const

XMLMetaHeader='<?xml version="1.0" standalone="yes"?>

<DATAPACKET Version="2.0"><METADATA><FIELDS>';

XMLNumFld='<FIELD attrname="%s" fieldtype="%s"/>';

XMLVarcharFld='<FIELD attrname="%s" fieldtype="string"

WIDTH="%d"/>';

XMLCharFld='<FIELD attrname="%s" fieldtype="string"

SUBTYPE="FixedChar" WIDTH="%d"/>';

XMLMetaEnd='</FIELDS><PARAMS

LCID="0"/></METADATA><ROWDATA>';

XMLDataEnd='</ROWDATA></DATAPACKET>';

begin

end;

В виде констант описаны теги, которые будут участвовать в формировании XML-документа. Непосредственно формирование XML-документа происходит в следующей последовательности:

1) формирование раздела описания полей;

2) формирование заголовка;

3) формирование раздела описания метаданных (структура записи);

4) формирование закрывающего тэга раздела метаданных;

5) построчное формирование строк данных;

6) формирование закрывающих тэгов.

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

2.4 Разработка клиентского приложения

2.4.1 Разработка графического интерфейса клиентского приложения

Существует 2 основных способа организации графического интерфейса пользователя: MDI (multiple document interface) и SDI (Single document interface).

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

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

Проведя сравнения MDI и SDI можно получить следующие преимущества и недостатка MDI относительно SDI.

Преимущества:

– в интерфейсе типа MDI общая панель меню и панель инструментов для всех дочерних окон, что уменьшает загромождённость экрана элементами интерфейса и увеличивает его полезную площадь;

– все окна приложения можно прятать/показывать, сворачивать/разворачивать и проводить с ними другие манипуляции, как с одним окном;

– дочерние окна можно размещать «черепицей» или «каскадом» в главном окне;

– увеличение скорости и экономия памяти при работе в одном окне, скорость переключения между дочерними окнами также выше, чем между равноправными в среде операционной системы;

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

Недостатки:

– затруднительно (чаще всего, невозможно) выводить содержимое разных дочерних окон на разные мониторы;

– также невозможно выводить их содержимое на разные виртуальные рабочие столы;

– MDI может затруднить параллельную работу с разными приложениями, так как переключение между внешними окнами разных программ и дочерними окнами одной неудобно;

– плавающие панели инструментов одного приложения могут перекрывать рабочее окно другого, загораживая обзор, а иногда и сбивая пользователя с толку - какая панель к какому приложению относится;

– пользователю нужно привыкать к обоим типам интерфейса, так как введение MDI не отменяет полностью использование SDI, который заложен в большинстве операционных систем;

– многие программные менеджеры окон предоставляют более гибкие возможности для работы с группами окон, чем MDI-интерфейс того или иного приложения.

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

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

Рассмотрим интерфейсы форм клиентского приложения, которые были созданы согласно предложенной технологии приложений баз данных с адаптивным интерфейсом. Клиентское приложение содержит 5 типов форм (табличная форма; полноэкранная форма; комбинированная форма; главная/подчиненная форма; форма в стиле Explorer), которые были созданы из заранее разработанных шаблонов форм.

Самой простой и распространенной является табличная форма (рисунок 2.12).

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

Рисунок 2.12 - Табличная форма

Также широко распространена полноэкранная форма (рисунок 2.13).

Рисунок 2.13 - Пример полноэкранной формы

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

Следующий вид формы представляет собой комбинацию двух предыдущих (рисунок 2.14).

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



Рисунок 2.14 - Комбинированная форма

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

Форма типа главная/подчиненная также очень удобна в использовании (рисунок 2.15).

Рисунок 2.15 - Форма типа главная/подчиненная



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

Формы в стиле Explorer (рисунок 2.16) используются для представления данных в нереляционном виде. В примере на рисунке 10 в виде дерева изображена структура предприятия, узлы которого представляют информацию по каждому сотруднику.

Рисунок 2.16 - Форма в стиле Explorer

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

– обновлять таблицы базы данных;

– осуществлять переход по записям;

– осуществлять поиск нужной записи;

– удалять и добавлять записи;

– подготавливать и просматривать отчеты.

Отчеты могут формироваться в виде документов разных форматов - текстовый файл, отчет Quick Report, документ MS Word, книга Excel. Создание отчетов в виде документов Word и Excel осуществляется с помощью компонентов COM.

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

2.4.2 Разработка процедур и функций клиентского приложения

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

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

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

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

procedure ObjectMouseDown (Sender: TObject; Button: TMouseButton;

Shift: TShiftState; X, Y: Integer);

procedure ObjectMouseMove (Sender: TObject; Shift: TShiftState; X,

Y: Integer);

procedure ObjectMouseUp (Sender: TObject; Button: TMouseButton;

Shift: TShiftState; X, Y: Integer);

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

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

Другие основные процедуры и методы описаны в таблице 2.12

Таблица 2.12

Процедуры и методы клиентского приложения

Имя процедуры/функции	Назначение
SetDefaultValue	Заполняет элементы формы значениями по умолчанию при добавлении новой записи.
Refresh	Обновляет поля представления данных.
TextReportFile	Формирует и сохраняет отчет в текстовом формате.
FindField	Осуществляет поиск по базе данных.
MenuConfigure	Считывает конфигурацию меню пользователя.
ReadGrants	Запрашивает права пользователь на изменение определенного набора данных.
MakeReport	Формирует отчет.
AddRecord	Запрос на добавление записи.
DeleteRecord	Запрос на удаление записи.
ModifyRecord	Запрос на изменение записи.
CommitData	Завершение транзакции, сохранение информации в базу данных.
CreateElement	Создает на форме элемент, в соответствии с параметрами из БД.

информационный адаптивный программный клиентский



3. Руководство по эксплуатации

3.1 Системные требования

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

Во время работы на стороне сервера приложений создается удаленный модуль для подключения каждого пользователя и все модули бизнес-логики представленные в виде DLL также загружаются в память сервера приложений. Количество пользователей на крупном предприятии достаточно велико, поэтому, чтобы избежать задержек в работе системы, желательно установить как можно больше оперативной памяти (советуется 2ГБ).

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

3.2 Инструкция администратору

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

1) установить СУБД MS SQL Server 2000 (или выше);

2) выполнить импорт базы данных. Для этого в SQL Server Enterprise Manager нужно выбрать север баз данных => Databases => All Tasks =>Attach Database...

В появившемся окне (рисунок 3.1) выберите файл AppSrvDBase.mdf для подключения базы данных.

Рисунок 3.1 - Подключение базы данный MS SQL Server 2000

Установка сервера приложения:

1) поместить файлы JobsAppSrv.exe, MEMPROC.dll и STRADD.DLL в общую папку на компьютер администратора, который будет использоваться в качестве сервера приложений;

2) установить связь сервера приложений с базой данных (Пуск => Панель управления => Администрирование =>Источники данных (ODBC)). В появившемся окне «Администратор источников данных ODBC» на вкладке пользовательский DSN нажать кнопку «добавить». В окне «Создание нового источника данных» выбрать драйвер «Sql Server».

3) В следующем окне «Создание источника данных для SQL Server» (рисунок 3.2) указать имя источника данных («AppSrvDBase»), выбрать СУБД.

4) запустить сервер приложений (JobsAppSrv.exe), чтобы клиентская программа смогла к нему подключиться. При этом он регистрируется на компьютере администратора и становится доступным клиентским компьютерам в сети;



Рисунок 3.2 - Создание источника данных для SQL Server

5) установить клиентскую часть (ClientApp.exe) на компьютеры пользователей.

3.3 Инструкция пользователю

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

Затем необходимо ввести имя пользователя и пароль в появившемся окне авторизации. Эти данные нужно заранее получить у администратора системы.

Теперь запущенное приложение готово к работе. Описание экранных форм приведено в главе 2.4.1.

4. Организационно-экономические вопросы

4.1 Маркетинговый анализ

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

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

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

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



4.2. Расчет затрат на создание системы

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

Расходы по заплате исполнителей З_з/п определяются

З_з/п=З_осн+(1+К_доп)*(1+К_с.ф.), (4.1)

где З_осн - основная заработная плата работников;

К_доп, К_с.ф. - коэффициенты, учитывающие дополнительную заработную плату и отчисления в социальные фонды.

Значения К_доп, К_с.ф. можно принимать в размере: К_доп- 0,08 - 0,1; К_с.ф. = 0,26.

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

, (4.2)

где т - количество этапов разработки;

п - количество разработчиков, принимающих участие в разработке;

- часовая зарплата работника i-ой квалификации нa j-ом этапе разработки;

- затраты времени в часах i-го разработчика нa j-ом этапе.

Программное изделие изготавливают два человека. Первый - разработчик-аналитик с заработной платой 25000 рублей в месяц, второй - программист с заработной платой 20000 рублей в месяц.

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

Таблица 4.1

Этапы разработки

Наименования этапов	Должность	Кол-во исполни-телей	Поча-совая з/п, руб.	Продолжи-тельность работ, час	З.П исполни-теля по этапу	Стои-мость этапа, руб.	Длитель-ность этапа, дней
1. Исследования рынка	Разработ.	1	142	8	1136	1136	1
2. Исследование предметной области	Разработ.	1	142	16	2272	2272	2
3. Составление спецификаций модулей бизнес-логики	Разработ.	1	142	8	1136	1136	1
4. Разработка системы	Разработ.	1	142	120	17040	17040	15
5. Создание базы данных	Программ.	1	113,6	80	9088	9088	10
6. Реализация системы обработки данных	Программ.	1	113,6	80	9088	9088	10
7. Тестирование системы	Разработч.	1	142	80	11360	11360	10
8. Отладка работы системы	Программ.	1	113,6	32	2625,2	2625,2	4
9. Оформление документации	Программ.	1	113,6	80	13632	13632	10
ИТОГО	67377,2	63

Затраты на материалы Зм рассчитываются по формуле

, (4.3)

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

q_ij - расход материала i-го вида нa j-ом этапе;

ц - цена единицы материала i-го вида.

Расчет показал, что Зм = 1500 рублей (канц. товары).

Расходы по арендной плате за помещения З_ар рассчитывается по формуле

, (4.4)

где Ц_ар - арендная плата за 1 кв. м. площади в год;

S_nл, - арендуемая площадь.;

Т_разр- время на разработку в календарных днях.

Ц_ар = 12000 руб/год.

Т_разр определяется как сумма продолжительностей этапов Т

. (4.5)

, (4.6)

где Т_jэт- трудоемкость j-ro этапа в человеко-часах;

Ч_j, - количество исполнителей нa j-ом этапе;

s - продолжительность рабочего дня в часах;

f- коэффициент перевода рабочих дней в календарные;

f=l,4; Т_разр = 78 дней.

Размер необходимой арендуемой площади S_пл

, (4.7)

где - количество исполнителей;

s - норма площади на одного человека.

Рассчитаем расходы по арендной плате за помещения З_ар по формуле 4, приняв следующие исходные данные: Ц_ар = 12000 рублей, Т_разр = 63 дней, S_пл = 17 м².

З_ар = 12000 * 17 * 6378/365 = 35210 рублей.

Затраты на освещение и отопление З_эн рассчитываются по формуле

, (4.8)

где Р -- суммарная мощность электроприемников;

t_дн -- продолжительность работы электроприемников в течении дня;

Т_{разр.раб.} - продолжительность разработки в рабочих днях;

W_э - тариф на электроэнергию;

W_тепл - тариф на тепловую энергию.

Рассчитаем расходы на освещение и отопление З_эн по формуле 4.8, приняв следующие исходные данные: Р = 0,5 кВт, t_дн = 8 часов, Т_{разр.раб.} = 63 дней, W_э = 1,66 рубля, W_тепл = 340 рублей.

З_эн = 0,5 * 8 * 63 * 1,66 +17 * 340 *63/365=1416 рубль.

Оплата машинного времени З_маш рассчитывается по формуле

, (4.9)

где nm - количество этапов разработки с использованием вычислительной техники;

Ц_маш - стоимость одного машино-часа работы.

Расчитаем затраты на оплату машинного времени З_маш по формуле 4.9, приняв следующие исходные данные: nm = 392, Ц_маш = 6 рублей.

З_маш=392 * 6 =2352 рубля.

Косвенные расходы организации разработчика З_косв рассчитываются по формуле

З_косв=З_осн*k_косв, (4.10)

где К_косв~ коэффициент косвенных затрат.

К_косв=1 ч 1,5; З_косв = 67377,2 * 1,1 = 74114,7 рубля.

Полученные результаты объединим в таблицу 4.2.

Таблица 4.2

Смета затрат на разработку программного продукта

Наименование статьи расходов	Сумма затрат, руб.
Расходы по заплате исполнителей, в том числе	91688,2
- основная заработная плата	67377,2
- дополнительная заработная плата	6700
- отчисления в социальные фонды	17611
Арендная плата за помещения	35210
Материальные затраты	1500
Затраты на освещение и отопление	1416
Оплата машинного времени	2352
Косвенные затраты	74114,7
Общая сумма затрат	297969,1

4.3 Расчет экономической эффективности системы

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

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

С_пост = З_ар+З_маш+З_эн. . (4.11)

С_пост ⁼ 38978 рублей

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

С_пер⁼ (З_зп+З_м+З_косв)* N_год, (4.12)

где N_гoд - годовой объем производства продукции.

N_год = 1; С_пер = 91688,2 + 1500 + 74114,7 = 167302,9 рублей.

Суммарные издержки производства определяются по формуле

S = C_пост+ С_пер. . (4.13)

S = 206280,9 рублей.

Выручка от реализации продукции в год определятся по формуле

В = Ц*N_год, (4.14)

где Ц - рыночная цена единицы продукции, рассчитанная с учетом издержек производства и рыночного спроса.

Рыночная цена рассчитывается по формуле

, (4.15)

где N_пред - предполагаемый объем выпуска (тиражирования) системы;

с - себестоимость единицы продукции;

П - прибыль на единицу продукции;

НДС -- налог на добавленную стоимость.

N_npeд ⁼ 4 (существует возможность внедрения системы на четырех предприятиях).

. (4.16)

с = 41825,7 + 38978 = 80803 рубля.

, (4.17)

где р - планируемая рентабельность.

р = 10 ч 20%

П = 0,2 * (206280,9/4 + 80803) = 26474 рубля.

НДС рассчитывается в соответствии с действующим на данный момент порядком расчета этого налога и размером ставки (н = 0,18) НДС

. (4.18)

НДС = 32718 рублей.

Ц = 191565 рубля.

В = 766260 рубля в год.

Точка безубыточности - определяется объемом реализации продукции, при котором доход до выплаты процентов и налогов равен нулю. Точка безубыточности N_б рассчитывается по формуле

. (4.19)

N_б =38978 / 24263 = 1,6 , что заметно ниже прогнозируемого объема (4 шт.)

4 - 1,6 = 2,4 шт. Запас прочности составляет 2,4 шт. Следовательно, производство прибыльно.

Чистый доход Д рассчитывается по формуле

Д=В - S. (4.20)

Д =559980 рубля в год.



5. Охрана труда

5.1 Безопасность работы на ПК

Видеодисплейные терминалы (ВДТ) и персональные компьютеры (ПК) являются источником ряда вредных и опасных факторов производственной среды:

- излучения электромагнитных полей;

- воздействия статического электричества;

- повышенным уровнем шума;

- неудовлетворительными климатическими условиями;

- недостаточной освещенностью на фоне зрительного и нервно-эмоционального напряжения;

- ограничение двигательной активности и монотонности.

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

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

Таблица 5.1

Значения параметров неионизирующих электромагнитных излучений

Наименование параметров	Допустимое значение
Напряженность электромагнитного поля на расстоянии 50 см вокруг ВДТ по электрической составляющей не более: в диапазоне частот 5 Гц - 2 кГц; в диапазоне частот 2-400 кГц	25 В/м 2,5 В/м
Плотность магнитного потока составляет не более: в диапазоне частот 5 Гц - 2 кГц; в диапазоне частот 2 - 400 кГц	250 нТл 25 нТл
Поверхностный электростатический потенциал не превышает	500 В

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

Многие системные блоки довольно ощутимо шумят, а винчестеры, особенно более старых моделей «подвывают». Шум - причина преждевременного утомления, ослабления внимания, памяти. Шум, создаваемый одним ПК, невелик, он находится в диапазоне 30-68 дБА, но, поскольку на рабочем месте находится не один ПК, то шум, производимый ими, является достаточно высоким. Если в помещении, на рабочем месте используются принтеры, как правило, лазерного типа, что также увеличивает уровень шума. Кроме того, данный тип шума оказывает отрицательное воздействие на человека еще и тем, что он является монотонным. Шум нарушает нервную систему; шумовые явления накапливаются в организме, и все больше и больше угнетает нервную систему.