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

• Введение
• 1. Анализ предметной области и постановка задачи
• 1.1 Описание задачи
• 1.2 Обзор аналогичных систем
• 1.2 Формулировка общих и специальных требований к системе
• 1.2.1 Требования к функциональным характеристикам
• 1.2.2 Требования к надежности
• 1.2.3 Требования к информационной и программной совместимости
• 1.3 Выбор архитектуры
• 1.4 Декомпозиция системы
• 1.5 Модель взаимодействия модулей системы
• 2. Разработка структур данных и программного обеспечения
• 2.1. Выбор средств разработки
• 2.2. Разработка структур данных
• 2.2.1 Построение инфологической модели данных
• 2.2.2 Построение физической модели данных
• 2.3 Разработка сервера приложений
• 2.3.1 Алгоритм работы сервера приложений
• 2.3.2 Разработка интерфейса сервера приложений
• 2.3.3 Разработка процедур и функций сервера приложений
• 2.3.4 Разработка средств администрирования сервера приложений
• 2.3.2 Разработка интерфейса модуля бизнес-логики
• 2.4 Разработка клиентского приложения
• 2.4.1 Разработка графического интерфейса клиентского приложения
• 2.4.2. Разработка процедур и функций клиентского приложения
• 3. Руководство по эксплуатации
• 3.1 Системные требования
• 3.2 Инструкция администратору
• 3.3 Инструкция пользователю
• 4. Организационно-экономические вопросы0
• 4.1 Маркетинговый анализ
• 4.2. Расчет затрат на создание системы
• 4.3 Расчет экономической эффективности системы
• 5. Охрана труда
• 5.1 Безопасность работы на ПК
• 5.2 Решение поставленной задачи
• 5.2.1 Режим труда и отдыха при работе с ПК
• 5.2.2 Электромагнитные излучения
• 5.2.3 Шум
• 5.2.4 Электробезопасность
• 5.2.5 Естественное и искусственное освещение
• 5.2.6 Микроклимат
• 5.2.7 Пожарная безопасность
• Заключение
• Список использованных источников
• Приложение 1
• Приложение 2
• Приложение 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

проектирование и разработка логической структуры самой информационной системы как набора программ;

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

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

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

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

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

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

1.1 Описание задачи

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

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

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

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

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

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

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

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

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

полноэкранная форма;

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

табличная форма отображает несколько записей одновременно в строках и столбцах подобно электронной таблице;

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

сводная таблица, которая позволяет отображать перекрестную таблицу в стиле MS EXCEL;

Диаграмма, включающая гистограммы, графики, круговые диаграммы и другие типы диаграмм.

Процесс автоматического создания всех перечисленных видов форм достаточно прост и эффективен при создании приложений малой сложности. При дальнейшем росте и развитии информационной системы на поверхность сразу же всплывут недостатки использования данного подхода. Во первых, 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 реализован современный дизайн интерфейса и повышена комфортность работы пользователей при работе с системой в течение длительного времени. Интерфейс системы спроектирован с учетом необходимости массового ввода информации (в том числе с использованием клавиатуры), а также с учетом работы менее опытных пользователей. Дизайн интерфейса разрабатывался таким образом, чтобы снизить утомляемость пользователей при длительной работе с системой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

форма табличного представления набора записей;

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

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

форма в стиле Explorer для отображения иерархически организованных данных;

форма для представления отношений таблиц «главная-подчиненная»;

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

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

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

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

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

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

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

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

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

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

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

1.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 — Архитектура системы

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

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

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

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

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

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

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

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

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

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

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

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

Delphi — это комбинация нескольких важнейших технологий:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

создание форм;

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

создание меню АРМов групп пользователей;

создание учетных записей пользователей;

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

создание меню АРМов пользователей;

изменение параметров АРМов и форм;

добавление новых форм.

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

Таблица 2.2

Сущность Menus

Таблица 2.3

Сущность Form_Params

Таблица 2.4

Сущность Form_Access

Таблица 2.5

Сущность Form_Objects

Таблица 2.6

Сущность Object_Types

Таблица 2.7

Сущность Panel_Params

Таблица 2.8

Сущность Form_Types

Таблица 2.9

Сущность Lookup_Params

Таблица 2.10

Сущность Column_Params