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

 

Содержание

Введение

. Анализ предметной области и постановка задачи

.1 Описание задачи

.2 Обзор аналогичных систем

.2 Формулировка общих и специальных требований к системе

.2.1 Требования к функциональным характеристикам

.2.2 Требования к надежности

.2.3 Требования к информационной и программной совместимости

.3 Выбор архитектуры

.4 Декомпозиция системы

.5 Модель взаимодействия модулей системы

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

.1. Выбор средств разработки

.2. Разработка структур данных

.2.1 Построение инфологической модели данных

.2.2 Построение физической модели данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.2 Решение поставленной задачи

.2.1 Режим труда и отдыха при работе с ПК

.2.2 Электромагнитные излучения

.2.3 Шум

.2.4 Электробезопасность

.2.5 Естественное и искусственное освещение

.2.6 Микроклимат

.2.7 Пожарная безопасность

Заключение

Список использованных источников

Приложение 1

Приложение 2

Приложение 3

Введение

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

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

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

Функционально-стоимостный анализ. Он служит для:

расчета реальной стоимости изделий и услуг;

определение затратных центров;

анализа дорогостоящих факторов и показателей производительности бизнес-процессов;

анализ организации бизнеса. Назначение:

определения принципов ведения бизнеса;

оценка эффективности реализации бизнес-процессов;

спецификация требований к подсистеме информационной поддержки;

информационное моделирование. В него входит:

описание информационной структуры объектов, сущностей атрибутов, ключей;

идентификация отношений между объектами.

имитационное моделирование. Его целью является:

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

анализ динамических характеристик бизнес-процессов;

анализ распределения ресурсов;

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

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

1. проектирование и разработка логической структуры самой информационной системы как набора программ;
2. проектирование лежащей в основе общего проекта информационной системы базы данных и выбор соответствующей системы управления базами данных (СУБД);
3. проектирование и разработка интерфейсных подсистем, как тех, которые относятся к взаимодействиям информационной системы с конечным пользователем, так и тех, которые связывают прикладные программы с СУБД.

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

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

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

1. Анализ предметной области и постановка задачи

.1 Описание задачи

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

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

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

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

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

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

.2 Обзор аналогичных систем

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

К одним из самых простейших способов создания экранных форм можно отнести формы, создаваемые в MS ACCESS. Среда MS ACCESS сама по себе является СУБД и предлагает пользователю возможность создания шести основных типов экранных форм:

1. полноэкранная форма;
2. ленточная форма, позволяющая отображать несколько записей одновременно;
3. табличная форма отображает несколько записей одновременно в строках и столбцах подобно электронной таблице;
4. главная/подчиненная отображает данные, связанные родительски-дочерними отношениями;
5. сводная таблица, которая позволяет отображать перекрестную таблицу в стиле MS EXCEL;
6. Диаграмма, включающая гистограммы, графики, круговые диаграммы и другие типы диаграмм.

Процесс автоматического создания всех перечисленных видов форм достаточно прост и эффективен при создании приложений малой сложности. При дальнейшем росте и развитии информационной системы на поверхность сразу же всплывут недостатки использования данного подхода. Во первых, MS ACCESS не может предоставить тех возможностей создания экранных форм, которые нам дают среды программирования DELPHI, C++, C#, JAVA. Во вторых, клиентские приложения, созданные в MS ACCESS способны работать лишь в данной СУБД на локальном компьютере (файл-сервер) или в лучшем случае подключаться к серверу баз данных MS SQL SERVER (клиент-сервер). Таким образом, полученная информационная система будет лишь двухуровневой (клиентское приложение - сервер баз данных), что уже делает ее неконкурентоспособной на современном рынке.

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

Зачастую CASE-системы интегрируются с программными системами языков четвертого поколения. Они предоставляют пользователю более или менее удобные средства для формирования интерфейса с конечным пользователем (например, в виде меню или форм), обеспечивают сравнительно простые возможности для взаимодействия с системой управления базами данных, а также предоставляют (обычно, достаточно примитивные) средства программирования. Основным достоинством языков четвертого поколения является то, что они обеспечивают возможность быстрого создания прототипов приложений (rapid prototyping).

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

Ярким примером, позволяющим продемонстрировать работу CASE - технологии, является ORACLE DESIGNER 2000. Входящие в его состав генераторы разбиваются на две группы:

генератор объектов сервера баз данных;

генераторы клиентской части.

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

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

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

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

Рассматривая готовые, закрепившиеся на рынке информационные системы, нельзя не упомянуть программный продукт отечественных разработчиков прикладного обеспечения - 1С: Предприятие.В1С: Предприятие.8.0 реализован современный дизайн интерфейса и повышена комфортность работы пользователей при работе с системой в течение длительного времени. Интерфейс системы спроектирован с учетом необходимости массового ввода информации (в том числе с использованием клавиатуры), а также с учетом работы менее опытных пользователей. Дизайн интерфейса разрабатывался таким образом, чтобы снизить утомляемость пользователей при длительной работе с системой.

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

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

.2 Формулировка общих и специальных требований к системе

.2.1 Требования к функциональным характеристикам

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

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

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

взаимодействие клиента и сервера по протоколам TCP/IP, HTTP и DCOM (CORBA);

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

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

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

объем передаваемых данных в рамках одного запроса не ограничен;

обмен данными выполнять XML-документами;

наличие средств инсталляции (консольные и GUI);

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

старт/стоп сервера приложений;

замена порта TCP/IP;

подключение/замена DLL;

мониторинг пользователей:

фиксация времени и места подключения;

общее количество обращений;

интенсивность обращений (средний интервал времени между запросами);

время последнего обращения;

установка максимального интервала пассивности;

автоматическое отключение «заснувших» пользователей;

принудительное отключение с консоли администратора.

сохранение протокола работы в Log-файлах. Фиксировать события:

время запуска/останова сервера приложений;

время подключения/отключения пользователей;

время обращения и текст запроса с параметрами;

сообщения об ошибках.

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

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

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

прототип клиентского приложения должен иметь следующие шаблоны форм:

1. форма табличного представления набора записей;
2. форма для представления полей одной записи;
3. комбинированная форма, отображающая как набор записей, так и выбранную в таблице запись отдельно;
4. форма в стиле Explorer для отображения иерархически организованных данных;
5. форма для представления отношений таблиц «главная-подчиненная»;
6. форма для представления справочников.

1.2.2 Требования к надежности

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

Основные требования к надежности информационной системы:

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

шифрование канала передачи данных;

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

1.2.3 Требования к информационной и программной совместимости

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

операционная система - Windows 2000 и выше;

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

.3 Выбор архитектуры

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

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

Рисунок 1.1 - Общая схема трехуровневой информационной системы

Таким образом, трехуровневую архитектуру можно представить в виде трех основных компонентов:

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

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

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

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

Сервер приложений в данной схеме является многопользовательским многопотоковым сокет-сервером, назначение которого - обеспечить доступ из клиентских приложений к данным, хранящимся в базе данных, а также к процедурам и функциям бизнес-логики, реализуемым в виде COM-компонентов или DLL. Набор интерфейсных функций обеспечивает получение из клиентского приложения SQL-запроса и возврат результата в виде набора данных SQL-запроса. Сервер приложений выполняет разбор SQL-инструкции и выясняет местоположение источника/потребителя данных или бизнес-процедуры. Если объект находится в БД, то запрос передается в СУБД. В противном случае выполняется поиск процедуры (функции) в DLL и COM-серверах, вызов и передача ей параметров, получение результатов и возврат их клиентскому приложению. Для изоляции клиентского приложения от структуры базы данных используются запросы (обзоры), хранящиеся в БД.

При разработке информационной системы используется компонентный подход. Компонентные технологии распределенных вычислений, в частности DCOM, используемая в разрабатываемой системе, ограничивают область применения, построенных на их основе ИС (относящихся, как правило, к типу информационных систем уровня предприятия), локальной сетью или интрасетью, что делает систему более защищенной от вмешательства извне. Применение компонентного подхода при разработке клиентских приложений позволяет существенно расширить их функциональность. Всю заботу о передаче данных по сети берет на себя подсистема удаленных вызовов процедур - RPC (Remote Procedure Call) в случае DCOM, что избавляет разработчиков клиентов от сосредоточения на низкоуровневых деталях сетевой коммуникации.

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

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

Взаимодействие с базой данных происходит через интерфейс ODBC, что дает нам полную свободу в выборе сервер управления базой данных (СУБД). Интерфейс ODBC был разработан фирмой Microsoft в качестве унифицированного средства для доступа к реляционным базам данных, управляемых различными СУБД. Для пользователей он представляется в виде совокупности функций и источников данных. Под источниками данных здесь подразумеваются объекты являющиеся связующим звеном между базами данных и их приложениями. Источники данных осуществляют взаимодействие с базами данных через ODBC-драйверы. Такие драйверы поставляются фирмами-разработчиками СУБД. Создание и настройка источников осуществляется пользователями, а интерфейсные функции предоставляет фирма Microsoft. После настройки источника данных, его имя используется в приложениях в качестве псевдонима для обращения к соответствующей базе данных.

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

Реализация средств администрирования сервера может быть осуществлена несколькими способами:

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

интерфейс пользователя может быть вынесен в отдельное приложение.

Достоинством первого подхода является простота реализации - не требуется обеспечения взаимодействия нескольких приложений, а сам сервер должен быть выполнен в виде обычного EXE-модуля. Недостаток такого подхода в том, что администрирование сервера возможно только на той машине, где он выполняется. Кроме того, контроль над выполнением сервера, в случае реализации его в виде обычного исполняемого модуля, берет на себя менеджер объектов COM, из-за чего сервер может периодически выгружаться и запускаться вновь. Чтобы избежать этого, следует реализовать серверную часть системы в виде службы Windows. Однако наделять сервисы интерфейсом пользователя не рекомендуется.

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

Разработанная архитектура (рисунок 1.2) позволяет достаточно полно использовать возможности, предоставляемые технологией COM, для обеспечения высокого уровня производительности сервера приложений и масштабируемости нагрузки на сервер.

Рисунок 1.2 - Архитектура системы

.4 Декомпозиция системы

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

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

1.5 Модель взаимодействия модулей системы

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

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

Рисунок 1.3 - Модель взаимодействия модулей системы

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

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

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

.1 Выбор средств разработки

В настоящее время существует огромное количество программных средств для разработки информационных систем (Delphi, С++, C#, JAVA). Все это современные языки программирования высокого уровня.

Для программной реализации поставленной данной задачи была выбрана среда разработки Borland Delphi 7. Данная среда позволяет создавать самые различные программы: от простейших однооконных приложений до программ управления распределенными базами данных.- это комбинация нескольких важнейших технологий:

высокопроизводительный компилятор в машинный код;

объектно-ориентированная модель компонент;

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

масштабируемые средства для построения баз данных.

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в двухуровневой («клиент-сервер») и трехуровневых архитектурах. Этот компилятор в настоящее время является одним из самых быстрых в мире. Он предлагает легкость разработки и быстрое время проверки готового программного блока. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

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

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

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

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

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

2.2 Разработка структур данных

В основе всех современных информационных приложений находятся системы хранения данных во внешней памяти и их эффективного поиска. В зависимости от специфики приложений используются разные технологии хранения и поиска данных. Если проводить грубую классификацию таких технологий, то можно выделить два основных направления - системы управления базами данных (СУБД) и информационно-поисковые системы (ИПС). ИПС в основном работают с полнотекстовыми документами и применяются в WEB-приложениях, поэтому в данном дипломном проекте они рассматриваться не будут.

Основными характеристиками среды хранения данных, управляемой СУБД, являются:

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

существенно частое обновление данных, эффективно поддерживаемое СУБД и производимое многими пользователями, одновременно подключенными к базе данных;

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

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

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

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

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

Примеры моделей представления данных в нереляционном виде показаны на рисунках 2.1 и 2.2.

Рисунок 2.1 - Иерархическая модель представления данных

Рисунок 2.2 - Сетевая модель представления данных

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

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

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

1. создание структур базы данных (таблиц с индексами, связями, триггерами; обзоров (представлений); сохраненных процедур и функций);
2. создание форм;
3. создание групп пользователей (ролей пользователей в системе);
4. создание меню АРМов групп пользователей;
5. создание учетных записей пользователей;
6. определение прав доступа пользователей и групп пользователей к формам и данным;
7. создание меню АРМов пользователей;
8. изменение параметров АРМов и форм;
9. добавление новых форм.

2.2.1 Построение инфологической модели данных

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

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

Рисунок 2.3 - Инфологическая модель базы данных

2.2.2 Построение физической модели данных

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

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

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

1)Users - пользователи и группы пользователей системы;

2)Menus - меню АРМов для ролей и пользователей;

3)Form_Parametrs - параметры форм;

4)Form_Access - доступ пользователей к формам;

5)Form_Objects - Объекты формы;

6)Object_Types- типы объектов;

7)Panel_Params - параметры объектов панели текущей записи форм (отдельно для каждого пользователя);

8)Form_Types - типы форм;

9)Lookup_Params- параметры форм выбора Lookup-значений (отдельно для каждого пользователя);

10)Column_Params- параметры колонок таблиц форм (отдельно для каждого пользователя);

Рисунок 2.4 - Физическая модель базы данных

Подробное описание сущностей конфигурационной базы данных представлено в таблицах 2.1-2.10

Таблица 2.1

Сущность Users

ТаблицаАтрибутыТипКомментарийUsersid_user role sysadm name dolgnost comment id_creator date_created id_mod dat_mod department apptitle login passint int nvarchar nvarchar nvarchar nvarchar bigint datetime bigint datetime bigint nvarchar nvarchar nvarcharИдентификатор Код роли пользователя Системный администратор Ф.И.О. пользователя Должность Примечание Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись Код подразделения предприятия Заголовок приложения Логин для авторизации Пароль для авторизации

Таблица 2.2

Сущность Menus

ТаблицаАтрибутыТипКомментарий Menusid_menu fk_user itemnumb uppercod fk_FT itemname id_creator date_created id_mod dat_modint int int int int nvarchar int datetime int datetimeИдентификатор Код пользователя Порядковый номер пункта в меню Код записи пункта меню-родителя Kод формы, запускаемой этим пунктом меню Наименование пункта меню Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.3

Сущность Form_Params

ТаблицаАтрибутыТипКомментарийForm_Paramsid_fp fk_FT confitem formname formtitle descript FROMTXT CMDSELECT WHERETXT ORDERTXT kodfld mainlstfld maintablename ZapFilter id_creator date_created id_mod dat_modbigint bigint nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar int datetime int datetimeИдентификатор Код типа формы(в программе) Пункт меню в модуле Main Внутренний индитификатор формы Заголовок формы Описание формы Секция from базового запроса Секция select базового запроса Секция where базового запроса Секция order by базового запроса Индитификатор ключевого поля базового запроса Список полей базовой таблицы обзора Индитификатор базовой таблицы обзора Фильтр отбора записей, к которым имеет доступ пользователей Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.4

Сущность Form_Access

ТаблицаАтрибутыТипКомментарий Form_Accessid_fa fk_user fk_FP readen appenden deleteen updateen allrecen showcard sysinfo autopen activeform strongedit id_creator date_created id_mod dat_modint int int nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar int datetime int datetimeИдентификатор Код пользователя или группы Код формы Доступ на чтение Доступ на запись Доступ на удаление Доступ на изменение Доступ на получение всех записей showcard sysinfo Автоматически открывать форму при запуске приложения Форма становится активной Y-редактирование возможно при нажатии на кнопку, N-редактирование возможно всегда Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.5

Сущность Form_Objects

ТаблицаАтрибутыТипКомментарий Form_Objectsid_FO fk_FP fk_OT objname defvalue lookupsqllist id_creator date_created id_mod dat_modint int int nvarchar nvarchar nvarchar int datetime int datetimeИдентификатор Код формы Код типа объекта Имя поля таблицы базы данных Значение по умолчанию Текст запроса для получения внешнего ключа Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.6

Сущность Object_Types

Object_Typesid_OT typeobject comment id_creator date_created id_mod dat_modint nvarchar nvarchar int datetime int datetimeИдентификатор Тип объекта Примечание Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.7

Сущность Panel_Params

ТаблицаАтрибутыТипКомментарийPanel_Paramsid_PP fk_user fk_FO topmargin leftmargin width height fontsize fontname labelfontcolor labelfontstyle taborder captionpos visible required variable caption pagenumber fontcolor fontstyle labelfontsize labelfontname additional id_creator date_created id_mod dat_modint int int int int int int int nvarchar int int int nvarchar nvarchar nvarchar nvarchar nvarchar int int int int nvarchar nvarchar int datetime int datetimeИдентификатор Код пользователя Код объекта формы Отступ сверху Отступ слева Ширина Высота Размер шрифта Шрифт Цвет подписи Размер шрифта подписи Порядок перехода на панели текущей записи по табуляции Положение подписи Видимость Видимость Изменяемое поле Подпись поля Номер закладки панели _екущее записи Цвет фона Стиль фона Размер шрифта подписи Шрифт подписи Дополнительные свойства Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.8

Сущность Form_Types

ТаблицаАтрибутыТипКомментарийForm_Typesid_FT typeform comment id_creator date_created id_mod dat_modint nvarchar nvarchar int datetime int datetimeИдентификатор Название типа форм Описание Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.9

Сущность Lookup_Params

ТаблицаАтрибутыТипКомментарийLookup_Paramsid_LP fk_OT fk_user indx fieldname columntitle fieldtype width alignment id_creator date_created id_mod dat_modint int int int nvarchar nvarchar nvarchar int int int datetime int datetimeИдентификатор Код объекта формы Код пользователя и группы Номер колонки в таблице Имя поля в таблице Заголовок таблицы Тип поля(s-string, n- number, d- date) ширина Выравнивание Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

Таблица 2.10

Сущность Column_Params

ТаблицаАтрибутыТипКомментарийColumn_Paramsid_CP fk_user fk_OT colindex visible width alignment fontname fontsize fontcolor fontstyle caption titlefontname titlefontsize titlefontcolor titlefontstyle displayformat id_creator date_created id_mod dat_modint int int int nvarchar int int nvarchar int int int nvarchar nvarchar int int int nvarchar int datetime int datetimeИдентификатор Код пользователя Код объекта формы Номер колонки в таблице Y - видимая колонка, N- невидимая Ширина колонки в пикселях Выравнивание колонки: 0-по левому краю, 1-по правому краю, 2- по центру. Шрифт Размер шрифта Цвет шрифта Стиль шрифта Заголовок колонки Шрифт заголовка Размер шрифта заголовка Цвет шрифта заголовка Стиль шрифта заголовка Форат вывода на экран Кем создана запись Дата создания записи Кем модифицирована запись Когда модифицирована запись

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для данного модуля синтаксического и семантического разбора 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.

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

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

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

IJobs = interface(IAppServer)ExecQuery(const SqlCmd: WideString): WideString; safecall;SelectQuery(const SqlCmd: WideString): OleVariant; safecall;AppSrvConnect(const hostname: WideString; const username: WideString; const pwd: WideString): WideString; safecall;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)«Пользователь» - имя пользователя, оно вводится в клиентской части при подключении к серверу приложений;

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

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

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

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

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

Строка состояния (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: string;: double;;

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

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

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

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

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

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

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

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

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

Таблица 2.11

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

Тип данных в СУБДКод типа данных в XML-документеINTEGERi4SMALLINTi2FLOATr2DOUBLEr4NUMERICr8DECIMALr10DATEdateTimeCHAR(10)stringVARCHAR(10)string

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

procedure MakeRecordSet(var CDSetBuf : TClientDataSet);='<?xml version="1.0" standalone="yes"?>

<DATAPACKET Version="2.0"><METADATA><FIELDS>';='<FIELD attrname="%s" fieldtype="%s"/>';='<FIELD attrname="%s" fieldtype="string" ="%d"/>';='<FIELD attrname="%s" fieldtype="string" ="FixedChar" WIDTH="%d"/>';='</FIELDS><PARAMS ="0"/></METADATA><ROWDATA>';='</ROWDATA></DATAPACKET>';

end;

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

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

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

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

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

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

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

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

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

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

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

SDI - способ организации графического интерфейса <#"justify">в интерфейсе типа MDI общая панель меню и панель инструментов для всех дочерних окон, что уменьшает загромождённость экрана элементами интерфейса и увеличивает его полезную площадь;

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

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

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

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

Недостатки:

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

также невозможно выводить их содержимое на разные виртуальные рабочие столы <#"justify">Поскольку целью дипломной работы является создание типового проекта многоуровнего приложения баз данных с адаптивным интерфейсом, и каждое клиентское приложение может содержать до нескольких сотен экранных форм, то очевидно выбор в реализации графического интерфейса пользовательских приложений ложится в сторону 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;: TShiftState; X, Y: Integer);

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

procedure ObjectMouseUp (Sender: TObject; Button: TMouseButton; : TShiftState; X, Y: Integer);

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

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

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

Таблица 2.12

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

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

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

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

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

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

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

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

.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».

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

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

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

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

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

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

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

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

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. Исследования рынкаРазработ.114281136113612. Исследование предметной областиРазработ.1142162272227223. Составление спецификаций модулей бизнес-логикиРазработ.114281136113614. Разработка системыРазработ.11421201704017040155. Создание базы данныхПрограмм.1113,68090889088106. Реализация системы обработки данныхПрограмм.1113,68090889088107. Тестирование системыРазработч.1142801136011360108. Отладка работы системыПрограмм.1113,6322625,22625,249. Оформление документацииПрограмм.1113,680136321363210ИТОГО67377,263

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

, (4.3)

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

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

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

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

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

, (4.4)

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

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

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

Цар = 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 м2.

Зар = 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пред - предполагаемый объем выпуска (тиражирования) системы;

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

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

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

Nnpeд = 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 шт.)

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

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

Д=В - S. (4.20)

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 5.1

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

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

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

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

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

При организации рабочего места пользователя ВДТ и ПЭВМ обеспечивается соответствие конструкции всех элементов рабочего места и их взаимного положения эргономическим требованиям.

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

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

Экран видеомонитора находится от глаз пользователя на оптимальном расстоянии 600-700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов. Конструкция монитора обеспечивает возможность фронтального наблюдения экрана путем поворота корпуса в горизонтальной плоскости вокруг вертикальной оси в пределах ± 30° и в вертикальной плоскости вокруг горизонтальной оси в пределах ± 30° с фиксацией в заданном положении.

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

Рабочие места с ВДТ и ПЭВМ по отношению к световым проемам располагаются так, чтобы естественный свет падал сбоку, преимущественно слева.

Схемы размещения рабочих мест с ВДТ и ПЭВМ учитывают расстояния между рабочими столами с видеомониторами (в направлении тыла поверхности одного видеомонитора и экрана другого), которые составляют не менее 2,0 м, а расстояния между боковыми поверхностями видеомониторов не менее 1,2 м.

Естественное освещение осуществляется через светопроемы, ориентированные, преимущественно на север и северо-восток и обеспечивать коэффициент естественной освещенности (к.е.о.) не ниже 1,2% в зонах с устойчивым снежным покровом. Искусственное освещение в помещениях эксплуатации ВДТ и ПЭВМ осуществляется системой общего равномерного освещения. В случаях преимущественной работы с документами, допускается применение системы комбинированного освещения.

Освещенность на поверхности стола в зоне размещения рабочего документа составляет 300-500 лк. Для подсветки документов допускается установка светильников местного освещения.

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

Работы на ВДТ и ПЭВМ по тяжести и энергозатратам относятся к категории - легкие физические работы (1а,1б). К категории 1а относятся работы, производимые сидя и не требующие физического напряжения, при которых энергозатраты составляют до 120 ккал/ч. При выполнении таких работ, температура воздуха должна быть в холодный период года не более 22¸24°C, в теплый период года не более 23÷25°С. При работе с программой, работа относится к категории 1а.

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

Площадь на одно рабочее место с ВДТ или ПЭВМ для взрослых пользователей должна составлять не менее 6,0 кв. м., а объем не менее 20,0 куб. м.

Для внутренней отделки интерьера помещений с мониторами и ПЭВМ должны использоваться диффузно - отражающиеся материалы с коэффициентом отражения для потолка - 0,7-0,8; для стен - 0,5-0,6; для пола - 0,3-0,5.

В помещениях с ВДТ и ПК присутствуют все три основных фактора, необходимых для возникновения пожара.

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

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

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

По взрыво-пожароопасности помещения с ВДТ и ПК относятся к категории В - пожароопасные (в помещениях имеются твердые сгораемые вещества и материалы).

5.2 Решение поставленной задачи

.2.1 Режим труда и отдыха при работе с ПК

Профессиональные пользователи ВДТ и ПЭВМ должны проходить обязательные предварительные (при поступлении на работу) и периодические осмотры в порядке и в сроки, установленные Минздравмедпромом России и Госкомсанэпиднадзором России.

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

Выделяют три вида работ, выполняемых на ПК: группа А - работа по считыванию информации с экрана с предварительным запросом, группа Б - работа по выводу информации, группа В - творческая работа в режиме диалога с ПК. Работа пользователей системы относится к группе В. Категории тяжести и напряженности работы на ПК (I, II, III) определяются уровнем нагрузки за рабочую смену: для группы В - по суммарному времени непосредственной работы на ПК (таблица 5.2).

Таблица 5.2

Виды и категории трудовой деятельности с ПК

Категория работы (по тяжести и напряженности работы с ВДТ и ПЭВМ)Уровень нагрузки за рабочую смену при видах работы на ПКГруппа В, часIдо 2,0IIдо 4,0IIIдо 6,0

5.2.2 Электромагнитные излучения

Мероприятия по снижению излучений включают:

мероприятия по сертификации ПЭВМ (ПК) и аттестации рабочих мест;

применение мониторов с антибликовым и антистатическим покрытием;

применение экранов и фильтров;

организационно-технические мероприятия.

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

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

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

5.2.3 Шум

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

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

рациональной планировкой помещения и правильностью расположения оборудования;

уменьшением шума по пути его распространения;

применением звукоизолирующих кожухов, когда это не мешает технологическому процессу;

с помощью шумозащитных экранов;

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

При планировке помещения наиболее шумящее оборудование необходимо располагать вдали от терминалов и другого сервисного оборудования.

5.2.4 Электробезопасность

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

Заземление является основной технической мерой защиты в сетях с изолированной централью.

Защитное отключение представляет собой быстродействующую защиту, обеспечивающую автоматическое отключение электроустановок при возникновении опасности поражения человека.

Еще одним средством защиты является недоступность токоведущих частей. Все токоведущие части ВДТ и ПК закрыты корпусом. Снимать корпус при включенном оборудовании запрещается.

5.2.5 Естественное и искусственное освещение

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

Общее освещение выполняется в виде сплошных или прерывистых линий светильников.

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

В качестве источников света при искусственном освещении применяются преимущественно люминесцентные лампы типа ЛБ и ТЛБ, мощностью 20, 40 и 80 Вт.

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

5.2.6 Микроклимат

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

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

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

5.2.7 Пожарная безопасность

Для увеличения пожарной безопасности при эксплуатации ПЭВМ применяются следующие меры:

-оборудовать помещения противопожарной сигнализацией;

-оборудовать помещения средствами пожаротушения;

-установить контроль нагрузки в электрической сети;

-установить контроль качества электрических соединений;

-строго соблюдается режим эксплуатации;

Для тушения пожаров в начальной стадии их возникновения широко применяются огнетушители.

Заключение

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

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

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

Приложение 1

Листинг файла RDM.pas

unit RDM;

{$WARN SYMBOL_PLATFORM OFF}, Messages, SysUtils, Classes, ComServ, ComObj, VCLCom, ,, JobsAppSrv_TLB, StdVcl, Provider, DB, DBTables, DBLocal, ,, JobAppSrvForm_U;= array of Variant;= procedure (var CDSetBuf : TClientDataSet;ParamsList : );= procedure (var CDSetBuf : ;ParamsList : DynArrayOfVariant) of object;= procedure (ParamsList : DynArrayOfVariant) of ;= record: string[64];: string[9];: longword;;=record:string;:string;;= class(TRemoteDataModule, IJobs): TDatabase;: TQuery;: TQuery;: TQuery;RemoteDataModuleCreate(Sender: TObject);RemoteDataModuleDestroy(Sender: TObject);Database1AfterDisconnect(Sender: TObject);

{ Private declarations }: TMemoryStream;:TStringList;: array of TXMLFldDescr;: DynArrayOfVariant;: DynArrayOfVariant;,FieldsStr,WhereStr,OrderByStr,GroupByStr : string;: TProcGetDataFromMemory;: TProcSetDataToMemory;OpenQuery(TmpQuery : TQuery; SqlCmd : string);ExecuteQuery(TmpQuery : TQuery; SqlCmd : string);ExecuteProcedure(ParamsList : DynArrayOfVariant);procedure UpdateRegistry(Register: Boolean; const ClassID, ProgID: ); override;ExecQuery(const SqlCmd: WideString): WideString; safecall;SelectQuery(const SqlCmd: WideString): OleVariant; safecall;AppSrvConnect(const hostname, username, pwd: WideString): ; safecall;AppSrvInit(const DBSrvName, username,: WideString): WideString; safecall;

{ Public declarations },User,PID : string;;: TDateTime;

{$R *.DFM}

MemoryState: integer; { -1 - íåçàãðóæåíà, 0 - çàãðóæàåòñÿ, 1 - ãîòîâà ê

ðàáîòå}getproc(procname:string):string;stdcall; external 'MemProc.dll';HourToDateTime(P: PDouble): PChar; cdecl; external 'StrAdd.dll' 'HOURTODATETIME';DateTimeToHour(S: PChar): Double; cdecl; external 'StrAdd.dll' 'DATETIMETOHOUR';AndBit(A, B: PInteger): Integer; cdecl; external 'StrAdd.dll' name

'AANDBIT';PosStr (S1, S2: PChar): Integer; cdecl; external 'StrAdd.dll' name

'APOSSTR';FirstWord (S: PChar; Ch: PChar): PChar; cdecl; external

'StrAdd.dll' name 'AFIRSTWORD';DelFirstWord (S: PChar; Ch: PChar): PChar; cdecl; external

'StrAdd.dll' name 'ADELFIRSTWORD';RoundExt(E: PDouble; L: PInteger): Double; cdecl; external

'StrAdd.dll' name 'AROUNDEXT';Trim(s : string) : string;Copy(s,1,1)=' ' do Delete(s,1,1);Copy(s,Length(s),1)=' ' do Delete(s,Length(s),1);:=s;;EnteringInSet(Value : integer; SetValues : Variant):boolean;: integer;: array of Variant;:=false;:=SetValues;i:=0 to High(tmp) doValue=SetValues[i] then begin:=true;;;DateTimeToStrLatMonth(DateTime :TDateTime): string;= 'JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV ';,sLat : string[3];: integer;:=FormatDateTime('dd-mmm-yyyy',DateTime);:=Copy(Result,Pos('-',Result)+1,3);:=Pos(AnsiUpperCase(sRus),RusMonth);i>0 then begin:=Copy(LatMonth,i,3);:=AnsiReplaceStr(Result,sRus,sLat);;;procedure TJobs.UpdateRegistry(Register: Boolean; const ClassID, : string);Register thenUpdateRegistry(Register, ClassID, ProgID);(ClassID);(ClassID);else(ClassID);(ClassID);UpdateRegistry(Register, ClassID, ProgID);;;TJobs.OpenQuery(TmpQuery : TQuery; SqlCmd : string);.Active:=false;.SQL.Text:=SqlCmd;.Active:=true;;TJobs.ExecuteQuery(TmpQuery : TQuery; SqlCmd : string);.Active:=false;.SQL.Text:=SqlCmd;.ExecSQL;;TJobs.GetParamsFromCommandText(var SqlCmd : string;out : DynArrayOfVariant);,j,ColParam,L : integer;: array of string;,ParamStr : string;:=Trim(SqlCmd);:=Pos(' FROM ',SqlCmd);:=Copy(SqlCmd,8,i-8);(SqlCmd,1,i+5);:=SqlCmd;:=Pos(' WHERE ',SqlCmd);i=0 then begin:=Pos(' ORDER ',SqlCmd);:=Pos(' GROUP ',SqlCmd);(i>j) and (j>0) or (i=0) then i:=j;;i=0 then i:=Length(SqlCmd);:=Copy(SqlCmd,1,i);(SqlCmd,1,i);SqlCmd<>'' then SqlCmd:=' '+SqlCmd;:=Pos('(',ParamStr);i=0 then i:=Length(ParamStr)+1;:=Copy(ParamStr,1,i-1);(ProcName);(ParamStr,1,i);ParamStr='' then exit;:=Pos(')',ParamStr);(ParamStr,i,Length(ParamStr)-i+1);:=0;ParamStr<>'' do begin(ColParam);(TmpArray,ColParam);

L:=Pos(',',ParamStr);

if L=0 then L:=Length(ParamStr)+1;:=Copy(ParamStr,1,L-1);(s<>'') and (s[1]=' ') do Delete(s,1,1);(s<>'') and (s[Length(s)]=' ') do Delete(s,Length(s),1);s[1]='''' then Delete(s,1,1);s[Length(s)]='''' then Delete(s,Length(s),1);(ParamStr,1,L);[ColParam-1]:=s;;:=VarArrayCreate([0,ColParam-1],varVariant);i:=0 to ColParam-1 do begin[i]:=TmpArray[i];;;TJobs.ExecuteProcedure(ParamsList : DynArrayOfVariant);= 2500;: integer;: double;: TDateTime;: string;: integer;:DynArrayOfVariant;:=StrToInt(ParamsList[0]);:=StrToFloat(ParamsList[1]);:=StrToDateTime(ParamsList[2]);:=ParamsList[3];E:Exception doEExternalException.CreateFmt('Error');;;TJobs.ExecQuery(const SqlCmd: WideString): WideString;: string;,j,ColParam,L : integer;: array of string;,ParamStr : string;.ModifyUserInfo(User,Host,PID);:=AnsiUpperCase(Trim(SqlCmd));:=CmdText;:=Pos('(',CmdText);i=0 then i:=Length(CmdText)+1;:='';j:=i-1 downto 1 do beginCmdText[j]=' ' then break;:=CmdText[j]+ProcName;;(ProcName);(ParamStr,1,i);:=0;(TmpArray,ColParam);ParamStr<>'' then begin:=Pos(')',ParamStr);(ParamStr,i,Length(ParamStr)-i+1);ParamStr<>'' do begin(ColParam);(TmpArray,ColParam);:=Pos(',',ParamStr);L=0 then L:=Length(ParamStr)+1;:=Copy(ParamStr,1,L-1);(s<>'') and (s[1]=' ') do Delete(s,1,1);(s<>'') and (s[Length(s)]=' ') do Delete(s,Length(s),1);s[1]='''' then Delete(s,1,1);s[Length(s)]='''' then Delete(s,Length(s),1);(ParamStr,1,L);[ColParam-1]:=s;;;:=VarArrayCreate([0,ColParam-1],varVariant);i:=0 to ColParam-1 do begin[i]:=TmpArray[i];;(ParamsArray);:='OK';:='ER';;;TJobs.AppSrvConnect(const hostname, username, pwd: ): WideString;not JobAppSrvForm.ServerReady then begin:='Can''t connect';;;:=HostName;:=UserName;DataBase1 do begin.Values['SERVER NAME'] := .MainDB.Params.Values ['SERVER NAME'];.Values['USER NAME'] := JobAppSrvForm.MainDB.Params.Values

['USER NAME'];.Values['PASSWORD'] := JobAppSrvForm.MainDB.Params.Values

['PASSWORD'];;not DataBase1.Connected then begin.Connected:=true;.UserDBConnectInfo(JobAppSrvForm.DBSERVER_NAM,User,Host,PID);:=JobAppSrvForm.DBSERVER_NAME;E:Exception do:=E.Message;;;TJobs.RemoteDataModuleCreate(Sender: TObject);:=TMemoryStream.Create;:=TStringList.Create;;TJobs.RemoteDataModuleDestroy(Sender: TObject);.Free;.Free;TJobs.SelectQuery(const SqlCmd: WideString): OleVariant;,str : string;,j : integer;,CDSetFull : TClientDataSet;withoutGroupByFunc : OleVariant;,j : integer;.Position:=0;.LoadFromStream(TempStream);.EmptyDataSet;:=CDSetFull.FieldCount-1;not CDSetFull.Eof do begin.Insert;i:=0 to j do.Fields[i].Value:= CdSetFull.Fields[i].Value;.Next;;

Приложение 2

Листинг файла MemProc.dpr

MemProc;, DB, Dialogs, DBClient, variants, SysUtils, Classes, windows;

{$R *.res}=array of Variant;= record: string[64];: string[9];: longword;;= record: string;: double;;:TDateTime;: array of TXMLFldDescr;:TStringList;: TMemoryStream;Suspend(var CDSetBuf : TClientDataSet;var :DynArrayOfVariant);: integer;.Insert;j:=0 to CDSetBuf.FieldCount-1 do(CDSetBuf.Fields[j].DataType=ftInteger) or

(CDSetBuf.Fields[j].DataType=ftSmallint) then.Fields[j].asInteger:=TmpRecord[j](CDSetBuf.Fields[j].DataType=ftFloat) then.Fields[j].AsFloat:=TmpRecord[j](CDSetBuf.Fields[j].DataType=ftDateTime) then.Fields[j].asDateTime:=TmpRecord[j].Fields[j].AsString:=TmpRecord[j];.Post;(TmpRecord,0);;MakeRecordSet(var CDSetBuf : TClientDataSet);='<?xml version="1.0" standalone="yes"?>

<DATAPACKET Version="2.0"><METADATA><FIELDS>';='<FIELD attrname="%s" fieldtype="%s"/>';='<FIELD attrname="%s" fieldtype="string" ="%d"/>';='<FIELD attrname="%s" fieldtype="string" ="FixedChar" WIDTH="%d"/>';='</FIELDS><PARAMS ="0"/></METADATA><ROWDATA>';='</ROWDATA></DATAPACKET>';,j,FieldsCount : integer;: string;DateTimeToXMLFmt(DT :TDateTime) : string;(Result,'yyyymmddhh:nn:sszzz',DT);('T',Result,9);;VariantToStr(FldValue : Variant;FldType : string) : string;FldType='i4' then Result:=IntToStr(Integer(FldValue)) elseFldType='r8' then Result:=FloatToStr(Extended(FldValue)) elseFldType='dateTime' then :=DateTimeToXMLFmt(TDateTime(FldValue)) else:=String(FldValue);;.Clear;.Add(XMLMetaHeader);:=High(FldArr);i:=Low(FldArr) to FieldsCount do beginFldArr[i] dofieldtype='string' then:=Format(XMLVarcharFld,[attrname,width])fieldtype='FixedChar' then:=Format(XMLCharFld,[attrname,width]):=Format(XMLNumFld,[attrname,fieldtype]);.Add(TmpStr);;.Add(XMLMetaEnd);:='<ROW ';j:=0 to FieldsCount doFldArr[j] do(fieldtype='string') or (fieldtype='FixedChar') then:=TmpStr+attrname+ '="" 'fieldtype='dateTime' then:=TmpStr+FldArr[j].attrname+

'="'+VariantToStr(Now,FldArr[j].fieldtype)+'" ':=TmpStr+FldArr[j].attrname+ '="0" ';:=TmpStr+'/>';.Add(TmpStr);.Add(XMLDataEnd);.Clear;.SaveToStream(TempStream);.Position:=0;.LoadFromStream(TempStream);.EmptyDataSet;;XMLFieldDescription(FieldName,FieldType : string;Length : =0);: integer;:=High(FldArr)+1;(FldArr,FieldCount+1);FldArr[FieldCount] do begin:=FieldName;AnsiUppercase(FieldType)='INTEGER' then fieldtype:='i4' elseAnsiUppercase(FieldType)='SMALLINT' then fieldtype:='i2' elseAnsiUppercase(FieldType)='FLOAT' then fieldtype:='r8' elseAnsiUppercase(FieldType)='DOUBLE PRECISION' then fieldtype:='r8' AnsiUppercase(FieldType)='NUMERIC' then fieldtype:='r8' elseAnsiUppercase(FieldType)='DECIMAL' then fieldtype:='r8' elseAnsiUppercase(FieldType)='DATE' then fieldtype:='dateTime' elseAnsiUppercase(FieldType)='CHAR' then fieldtype:='FixedChar' elseAnsiUppercase(FieldType)='VARCHAR' then fieldtype:='string';:=Length;;;GetDataFromMemory(var CDSetBuf : ;ParamsList : DynArrayOfVariant);= 2500;: integer;: double;: TDateTime;: string;: integer;:DynArrayOfVariant;:=0;:=0;:=NullDate;:='';Length(ParamsList) > 0 then begin:=StrToInt(ParamsList[0]);:=StrToFloat(ParamsList[1]);:=StrToDateTime(ParamsList[2]);:=ParamsList[3];;

Приложение 3

Листинг файла WorkClientForm_U.pas

WorkClientForm_U;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, UCDM, Grids, DBGrids, DB, DBClient, MConnect, DBTables,, Buttons, JobsAppSrv_TLB, Mask, DBCtrls, ComCtrls, ExtCtrls,, SConnect;= class(TForm): TDataSource;: TClientDataSet;: TPanel;: TBitBtn;: TPageControl;: TTabSheet;: TTabSheet;: TDBGrid;: TPanel;: TPanel;: TBitBtn;: TDBGrid;: TDataSource;: TClientDataSet;: TEdit;: TLabel;: TLabel;: TEdit;: TBitBtn;: TSimpleObjectBroker;: TDCOMConnection;: TLabel;: TEdit;: TEdit;: TLabel;: TSocketConnection;BitBtn2Click(Sender: TObject);BitBtn5Click(Sender: TObject);ClientDataSet5BeforeGetRecords(Sender: TObject;OwnerData: OleVariant);Button2Click(Sender: TObject);BitBtn6Click(Sender: TObject);

{ Private declarations }: IJobsDisp;: TMemoryStream;:TStringList;GetDataFromMemory(Sender : TObject);

{ Public declarations };: TWorkClientTestForm;: Exception;_Cursor:TCursor;PasswordDlg_U;

{$R *.dfm}HourGlassCursor;_Cursor := Screen.Cursor;.Cursor := crHourGlass;;NormalCursor;.Cursor := Save_Cursor;;TWorkClientTestForm.BitBtn2Click(Sender: TObject);: OleVariant;: integer;: integer;,HostName : string;: array [0..255] of char;: dword;true doPasswordDlg do begin.Caption:=Ok;Showmodal= mrOK then begin;.Connected:=false;i:=0 to SObjBroker.Servers.Count-1 do.Servers[i].Enabled:=SObjBroker.Servers[i].ComputerName=cb.Text;.Connected:=true;:=IJobsDisp(IDispatch(DCOMConCommon.AppServer));:='';:=255;(@sbuf,pBufLen);:=string(sbuf);:=JobsInterface.AppSrvConnect(HostName,UserName.text,Password.Text)

;

// s:='localhost';Pos(ch,s)>0 then:=StrToInt('');.Enabled:=true;.Text:=s;.Text:=cbAppServerName.Text;.Enabled:=false;;MessageDlg(Message, 0) <> mrYes then;;E : Exception doMessageDlg(Message, 0) <> mrYes then;;break;;;;TWorkClientTestForm.BitBtn5Click(Sender: TObject);.CommandText:=Edit1.Text;(ClientDataSet5) ;;TWorkClientTestForm.ClientDataSet5BeforeGetRecords(: TObject; var OwnerData: OleVariant);(Sender);;

Содержание Введение . Анализ предметной области и постановка задачи .1 Описание задачи .2 Обзор аналогичных систем .2 Формулировка общих и сп

Больше работ по теме: