Содержание к диссертации
Введение
1. Анализ объекта исследования 14
1 1 Описание предметной области 14
12 Постановка задачи 19
13 Анализ существующих подходов к проблеме 21
131 Подходы к хранению данных 21
13 2 Подходы к построению программных компонент крупных распределенных программных комплексов 23
Выводы ПО ГЛАВЕ 1 26
2. Программный комплекс сбора, хранения и обработки информации о регистрации эмиссионных документов кредитных организаций. особенности предложенного подхода к разработке 27
2 1 Особенности разработки программных систем, имеющих возможность работы с БД различного типа 27
2 1 1 Выбор СУБД 28
2 12 Выбор БД файлового типа 30
2 13 Выбор средств разработки 32
2 14 Анализ возможностей двух типов БД и создание универсальной структуры БД 35
215 Оценка влияния типа БД на функциональность системы 39
2 16 Создание программных компонент, обеспечивающих возможность работы с БД
различного типа 40
Выводы по главе 2 55
3. Общая характеристика методов и средств, примененных при разработке программного комплекса 57
3 1 Понятие жизненного цикла по 57
3 11 Каскадная модель ЖЦ 58
3 12 Спиральная модель ЖЦ 59
3 2 Методология rad 60
3 3 Основные этапы разработки крупных ас 63
3 4 Выбор средств информационного моделирования 65
3. 4.1. Краткая характеристика 65
3.4.2. Обоснование выбора 67
3.4.3. Расширение возможностей Designer/2000 68
Выводы по главе 3 69
4. Реализация программного комплекса сбора, хранения и обработки информации о регистрации эмиссионных документов кредитных организаций 70
4.1. Структура комплекса 71
4.1.1. Система классификации и кодирования информации 71
4.1.2. Функциональная структура ПО 72
4.2. Создание универсальных компонент 91
4.2.1. Конвертер данных 91
4.2.2. Модуль создания отчетов произвольной структуры 96
Выводы по главе 4 112
Заключение 113
Перечень использованных сокращений 115
Список использованной литературы
- Анализ существующих подходов к проблеме
- Анализ возможностей двух типов БД и создание универсальной структуры БД
- Выбор средств информационного моделирования
- Функциональная структура ПО
Введение к работе
Роль информационно-вычислительных систем в жизни человека
На современном этапе развития человеческого общества информационно-вычислительные системы (ИВС) играют важную роль в самых разнообразных сферах деятельности. Это геоинформационные и метеорологические, транспортные и финансовые, а также многие другие системы. По количеству работающих крупных программно/аппаратных комплексов Россия значительно отстает от западных стран, но в течение нескольких последних лет этот разрыв начал сокращаться.
Анализ существующих подходов к проблеме
Существует два распространенных подхода к хранению данных: - хранение данных в виде таблиц определенного формата в файловой системе (на файл-сервере или на локальном диске). - хранение данных на сервере СУБД; Каждый из этих способов имеет свои достоинства и недостатки
Хранение данных в виде таблиц определенного формата в файловой системе (далее - БД файлового типа), и использование программных средств, работающих с этими таблицами, распространено очень давно. Самыми известными средствами, работающими с БД файлового типа, являются Borland DBase, Microsoft FoxPro, Borland Paradox, Microsoft Access.
Достоинствами данного подхода являются: - Нетребовательность к ресурсам; - Отсутствие необходимости специального администрирования; - Простота работы с таблицами файловой системы (копирование, архивация, перенос и т.д.); - Отсутствие дополнительных надстроек над данными, что теоретически обеспечивает программисту максимальную свободу при работе с информацией.
Однако, с другой стороны, простота работы с БД файлового типа при реализации сложных систем оборачивается необходимостью реализации на уровне прикладного ПО большого количества функций работы с данными, не имеющих прямого отношения к возлагаемым на систему задачам, что значительно увеличивает срок разработки и снижает качество результата. Во избежание подобных проблем были созданы и продолжают бурно развиваться СУБД - системы управления базами данных.
Основным принципом любой современной СУБД является изоляция прикладных программ от данных. Взаимодействие прикладных программ с данными осуществляется посредством некоего специализированного интерфейсного языка (в современных реляционных СУБД такими языками являются DML (Data Manipulation Language) и DDL (Data Definition Language). Такой подход позволяет перенести большую часть сервисных функций по работе с данными, а также жестко связанную с данными часть бизнес-логики на сервер СУБД. Таким образом, на прикладном уровне остается только необходимость программирования интерфейса пользователя и функциональных частей ПО.
На СУБД возлагаются функции [56, 16, 40, 73]: - Структурированного и надежного хранения данных (ведение репозитария объектов и журнализация операций); - Обеспечения согласованности данных (физическая и логическая целостность); - Обеспечения единообразного интерфейса доступа к данным; - Реализации механизма транзакций; - Оптимизации хранения и доступа к данным; - Реализации бизнес-логики, связанной с конкретными данными (напр., триггеров, обеспечивающих реакцию на события, производимые над данными); - Многопользовательского доступа к данным; - Разграничения полномочий и аудита операций. Естественным образом из достоинств СУБД вытекают и недостатки, а именно: - Требовательность к ресурсам; - Необходимость квалифицированного и трудоемкого администрирования; - Отсутствие полной "прозрачности" работы с данными (на физическом уровне) для программиста; - Трудность взаимодействия со внешними по отношению к БД объектами; - При доступе к данным из приложения через интерфейсный слой (язык SQL) не всегда возможно эффективное выполнение некоторых пользовательских операций, связанных, например, с выдачей большого объема информации (скроллинг таблицы на экране), позиционированием на запись, фильтрацией данных и т.д.
В последнее время наблюдается сближение средств двух вышеупомянутых типов: средства, издавна работавшие с БД файлового типа, дополняются компонентами работы с СУБД; возникают универсальные механизмы доступа к данным типа Microsoft ODBC или Borland BDE, позволяющие однотипно работать с любым источником данных, если есть соответствующий драйвер.
Как правило, при создании крупных распределенных программных комплексов, разработчики по очевидным причинам стараются в максимальной степени унифицировать способы хранения информации (БД) и работающие с ней программные компоненты.
Соответственно, в начале разработки делается выбор, какой из подходов к хранению данных выбрать. По результатам данного выбора система строится либо на основе БД файлового типа, что в последнее время встречается все реже, либо на основе промышленной СУБД.
В случае БД файлового типа, очевидно, проблем масштабируемости системы с т.з. мощности техники не возникает: средства работы с такими БД нетребовательны к ресурсам. Однако в крупных программных системах в данном случае остро встает проблема надежности хранения больших объемов данных, а также производительности доступа к ним.
При работе с СУБД проблема масштабируемости стоит достаточно остро. На данный момент практически все известные СУБД обладают набором версий различной мощности, предназначенных для вычислительной техники определенного класса, совместимых снизу-вверх [43,16]. Однако и у самых "маломощных" вариантов СУБД требования к аппаратным средствам, на которых они способны функционировать, достаточно высоки.
Таим образом, в условиях, налагаемых на программный комплекс в данной работе, ни один из вышеописанных подходов не работает: БД файлового типа не обеспечивает необходимой надежности и производительности работы с данными на объектах автоматизации "верхнего" уровня, а СУБД невозможно установить на некоторых объектах автоматизации "нижнего" уровня.
Анализ возможностей двух типов БД и создание универсальной структуры БД
Разработанная структура БД является отражением следующих требований на способы хранения информации:
1. Структура БД должна быть максимально схожей для Oracle и Paradox.
Так как структура БД разрабатывалась таким образом, чтобы объекты могли быть созданы как в Oracle, так и в Paradox, а исходная информация загружается в БД из таблиц Paradox, приходилось учитывать отличия этих БД, приведенные в таблице 3.
Эти отличия приходилось учитывать как на этапе создания БД, так и при создании ПО для загрузки данных в БД различного типа.
2. Должен поддерживаться максимально возможный уровень целостности данных.
Для БД Oracle целостность данных поддерживается на двух уровнях -уровне СУБД и уровне ПО. Для таблиц Paradox ссылочная целостность данных поддерживается только на уровне ПО.
На уровне СУБД целостность данных поддерживается путем создания ограничений (constraints). Используемые ограничения перечислены ниже:
- Первичные (primary) ключи. Практически все первичные ключи -"реальные", то есть несут смысловую нагрузку. Например, в таблице эмиссий ценных бумаг ключ состоит из полей "№ лицензии КО, № эмиссии". Фиктивные ключи - идентификаторы, заполняющиеся уникальными значениями из последовательностей используются редко. Такой подход делает схему БД более интуитивно понятной для пользователей, имеющих желание составлять SQL-запросы самим, хотя использование составных ключей имеет определенные недостатки (напр., увеличивается размер таблиц и индексов).
- Уникальные (unique) ключи. Поскольку приходящая информация содержит в себе достаточно много ошибок, создание осмысленных уникальных ключей позволяет эффективно эти ошибки отфильтровывать (дублирующиеся записи, не заполненные необходимые поля и многое другое).
- "Проверяющие" ограничения (check constraints). Также используются для фильтрации некорректных данных - обычно дат или числовых значений, выходящих за допустимые пределы.
- Ограничения ссылочной целостности (referential integrity constraints). Все имеют тип "restricted" (запрещение некорректных удалений/вставок/модификаций записей). Данные ограничения обеспечивают корректность связанной информации, находящейся в разных таблицах. Типичным примером является архив документов кредитных организаций. Никакой документ нельзя удалить, пока в БД есть какая-либо связанная с ним информация. В свою очередь, пока не удалены все документы какой-либо КО, ее удалить также нельзя. Таким образом обеспечивается логическая целостность всей БД.
На уровне ПО осуществляются практически те же проверки. Однако проверка корректности действий пользователя, реализованная на уровне ПО, обладает тем преимуществом, что можно осуществлять превентивные действия. Например, если выполнение некоторой операции в данном случае некорректно, кнопку, инициирующую эту операцию можно временно "отключить" (disable) или при нажатии на нее, не выполняя операцию, выдавать соответствующее сообщение. Такой подход позволяет организовать более "дружественный" интерфейс пользователя (при осуществлении проверки только на уровне СУБД, пользователь уже после попытки выполнения операции получит сообщение, что операция не была выполнена).
3. Структура БД должна обеспечивать высокую производительность работы с данными.
После первичного обследования объекта автоматизации была создана предварительная нормализованная структура БД. Далее эта нормализованная структура была подвергнута исследованиям на предмет производительности [33]. Учитывался интерфейс будущих приложений, анализировались действия, которые пользователи будут производить наиболее часто, продумывались типовые цепочки событий при работе с приложениями. После этого в БД вносились следующие изменения:
- Некоторая избыточность. Типичный пример: в нормализованной БД все кредитные организации разбиты по регионам регистрации. Все эмиссии ценных бумаг связаны с кредитными организациями-эмитентами.
Ценные бумаги связаны с эмиссиями. Типичная операция пользователя - выбрать все ценные бумаги КО, эмитированные в выбранном регионе - реализуется SQL-запросом по 4-м связанным таблицам. Если в Oracle данный запрос может выполниться за приемлемое время (в зависимости от количества данных), то в Paradox - точно нет. Единственным выходом является добавление индексированного поля "регион регистрации" в таблицу ценных бумаг. В этом случае требуемая выборка будет получена практически мгновенно.
- Добавочные индексы. Поскольку объем данных в БД измеряется гигабайтами, вопрос правильного индексирования таблиц в БД стоял очень остро. Подробно индексирование как средство повышения производительности описывается в п.2.1.6.
- Дробление таблиц. Таблицы, содержащие много полей, иногда делились на несколько частей. Поля в результирующих таблицах группируются по критерию частоты обращения к ним. Это позволяет значительно снизить как сетевой трафик, так и нагрузку на сервер БД.
4. В БД должен храниться как полный архив документов, так и срез всей необходимой информации на текущую дату. В результате БД состоит из трех частей:
Выбор средств информационного моделирования
Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозитории. В состав Designer/2000 входят следующие компоненты [12]:
- Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
- Repository Object Navigator - средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
- Process Modeller - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Process Reengineering);
- Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy
Diagrammer), диаграмм потоков данных (Data Flow Diagrammed и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
- Systems Designer - набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);
- Server Generator - генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов Oracle, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
- Forms Generator (генератор приложений для Oracle Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
- Repository Reports - генератор стандартных отчетов, интегрированный с Oracle Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.
Репозиторий Designer/2000 представляет собой хранилище всех проектных данных и может работать в многопользовательском режиме, обеспечивая параллельное обновление информации несколькими разработчиками. В процессе проектирования автоматически поддерживаются перекрестные ссылки между объектами словаря и может генерироваться большое количество стандартных отчетов о моделируемой предметной области [12]. Физическая среда хранения репозитория - база данных Oracle. Генерация приложений, помимо продуктов Oracle, выполняется также для Visual Basic. Взаимодействие с другими средствами
Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface).
Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств Oracle Client Adapter для ODBC, Oracle Open Gateway и API [12]. Среда функционирования Среда функционирования Designer/2000 - Windows 95, Windows NT.
В совокупности со средствами разработки приложений Developer/2000 это CASE-средство обеспечивает поддержку полного ЖЦ ПО для систем, использующих СУБД Oracle [8]. В проекте по созданию АС ДКДКОФР Designer/2000 использовался исключительно как средство информационного моделирования для выполнения следующих работ [30, 31]: - В ходе предпроектного обследования была создана модель бизнес-процессов (BPM-diagram); - В процессе анализа была построена модель информационных потребностей (диаграмма "сущность-связь" - ERD); - На этапе проектирования была создана схема реляционной БД (диаграмма структуры данных - DSD); - На этапе разработки была создана БД; - На всех этапах создавалась соответствующая проектная документация.
Несомненно, одной из главных причин выбора именно этого CASE-средства послужило то, что в качестве базовой СУБД планировалось использовать Oracle. Никакое другое CASE-средство не обладает столь полной интеграцией с этой СУБД. Также немаловажно то, что ситуация, когда возможности CASE-средства в будущем начнут отставать от возможностей СУБД, в данном случае исключена. И при необходимости перехода, например, к Oracle 8, не потребуется переход к другому CASE-средству [49].
Помимо этого, не последнюю роль сыграл мощный графический аппарат построения диаграмм и многопользовательский репозиторий
Функциональная структура ПО
Функциональные возможности заказных модулей приведены ниже. Универсальные модули описаны отдельно более подробно.
Модуль просмотра и обработки данных
Модуль просмотра и обработки данных является центральным в системе и служит для просмотра, редактирования, анализа данных, хранящихся в БД ДКДКОФР, а также формирования разнообразных отчетов. Функции программы рассмотрены ниже. Интерфейс пользователя и общие функции
При разработке программы были использованы многие стандартные элементы пользовательского интерфейса операционной системы Windows 95 (или Windows NT 4.0). Большинство форм проектировалось таким образом, чтобы облегчить пользователю работу с программой. Формы имеют схожий внешний вид, набор компонент и типовую схиму их расположения.
Типичная форма имеет (сверху вниз) системное меню на заголовке формы, меню формы, набор "закладок", таблицу с данными, счетчик количества записей, окно быстрого поиска, строку состояния, навигатор. У некоторых форм те или иные компоненты отсутствуют.
Системное меню помимо стандартных пунктов может содержать следующие пункты, расширяющие стандартные возможности интерфейса Windows 95/NT: - "Распечатать окно". Служит для печати текущей формы в том виде, в котором она видна на экране; - "Экспорт таблицы с данными". Служит для вывода в редактор MS Word таблицы с данными текущей формы (с учетом наложенных фильтров).
Стандартное меню формы включает в себя пункты: - "Информация". Обычно служит для получения детальной информации по выбранной строке таблицы или для вызова логически связанных с текущей форм; - "Упорядочить". Служит для сортировки данных в таблице по различным критериям; - "?". Получение справки о данной форме; - "Закрыть".
Закладки формы предназначены для получения более детальной информации по выбранной строке таблицы. Закладки могут быть многоуровневыми.
На каждой основной форме присутствует закладка "Выбор". Данная закладка реализует гибкий механизм фильтрации таблицы на форме по набору критериев. Этот набор зависит от формы. Пример закладки "Выбор" показан на Рис. 8.
. Пример закладки "Выбор"
Условия фильтрации могут быть следующими , равно, не равно, больше, меньше, принадлежит (подстрока входит в строку), не принадлежит (подстрока не входит в строку), принадлежит списку (напр., регионов).
После выполнения сложной выборки появляется CheckBox "Выборка из выборки". При его установке следующая выборка с новым условием будет сделана из уже отобранных записей. Это может значительно ускорить процесс фильтрации, особенно при работе с таблицами Paradox.
Таблица с данными для каждой формы содержит свой набор данных в табличной форме.
Счетчик количества записей обычно расположен справа под таблицей и показывает количество строк в ней с учетом наложенного фильтра.
Окно быстрого поиска служит для быстрого поиска строки в таблице. После ввода каждого следующего символа в окно быстрого поиска текущей строкой становится строка, у которой значение поискового поля наиболее близко к значению в окне быстрого поиска.
Строка состояния расположена внизу формы и содержит справочную информацию о выбранной записи.
Навигатор служит для перемещения по таблице с данными. Набор кнопок в навигаторе может меняться от формы к форме. На форме может находиться несколько навигаторов, каждый - для своей таблицы.
Многие из форм могут вызываться как напрямую (напр., из главного меню), так и из других форм. При этом в случае необходимости на вызываемой форме автоматически устанавливается фильтр в соответствии с условиями, при которых она была вызвана.
Во многих формах системы существует возможность формирования выходных документов. На некоторых формах данная возможность обозначена как "печать". Реально в большинстве случаев документы формируются в формате RTF7 и открываются в MS Word (или в любом другом редакторе, зарегистрированном в MS Windows в качестве обработчика RTF-файлов). Для формирования RTF-файлов используется динамическая библиотека (DLL), написанная автором на языке С.
