Разработка и сопровождение открытых СУБД приложений

• Автор: Куделя, Сергей Викторович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2000
• Место защиты: Ростов-на-Дону
• Количество страниц: 214 с. : ил.

СОДЕРЖАНИЕ
Введение
Г лава 1. Способы и средства построения СУБД приложений
Глава 2. Открытость СУБД приложения как ключевой фактор
сопоовождения
Г лава 3. Основные элементы предлагаемой технологии
Г лава 4. Модель открытого СУБД приложения
Глава 5. Спецификация открытого СУБД приложения
Глава 6. Механизмы работы со спецификацией
Г лава 7. Применение технологии разработки открытых СУБД приложений 118 Заключение
Литература
Схема 1. Структура элементов программного фонда
Приложение 1. Базовые объекты модели приложения
Приложение 2. Структура специализированного репозитория
спецификации. Пример текстовой спецификации
Приложение 3. Структура мета-базы данных инструментария разработки
приложений в среде Delphi Приложение 4. Использование инструментария на примере ИИС
Приложение 5. Структура мета-базы данных СУБД приложения при
использовании технологии ASP
Приложение 6. Интерфейс реализации СУБД приложения в ASP
технологии
Приложение 7. Реализация основных элементов приложения в
технологии ASP

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

Современные средства разработки СУБД приложений, а особенно средства визуального проектирования, достигли того уровня, когда процесс создания приложения сведен к работе с высокоуровневыми визуальными объектами и состоит в построении интерфейса работы с базой данных. Изучение таких средств разработки не требует много времени и может протекать в процессе создания приложения. Создание простого СУБД приложения занимает несколько часов, иногда несколько дней. Результатом подобной работы и обучения является тот факт, что на первом этапе знакомства со средством разработки отсутствует явная необходимость написания и проектирования инструментария для разработки приложений. В процессе дальнейшей работы для облегчения процесса проектирования возникает необходимость описать в виде функций или визуальных компонент часто вызываемые формы или операции, или воспользоваться стандартными средствами, такими как репозитории [32, 39, 74, 91, 100]. Многим разработчикам вполне достаточно описанного выше подхода, чтобы создавать приложения и успешно использовать их в работе. Но стадия разработки приложения не является окончательной. Работа с приложением переходит на другой уровень - сопровождения и модификации, и требует использования дополнительных технологических принципов, обеспечивающих максимальную эффективность этого процесса.
Рассмотрим понятия срока жизни приложения и его совокупной стоимости. Эти понятия тесно взаимосвязаны. Под сроком жизни приложения понимается общее время его функционирования. За начальную точку принимается момент установки приложения заказчику. Конечной точкой считается тот момент, когда функциональная часть приложения не удовлетворяет требованиям заказчика или ограничения технологии, в которой реализовано приложение, не дают заказчику выполнять свои функциональные обязанности. Совокупная стоимость приложения рассматривается с двух сторон. Первая - это сторона заказчика или пользователя программного обеспечения. Она определяется количеством и частотой вложения денег в программное обеспечение и содержанием

Масштабируемость, т.е. возможность наращивания количества ежедневно обрабатываемых транзакций или подключения дополнительных пользователей за счет увеличения производительности системы. Последнее достигается модернизацией существующего оборудования или заменой его на более производительное. Этот критерий, хотя во многом и может быть сведен к требованию мобильности, заслуживает отдельного упоминания.
Адаптируемость. Эта характеристика не имеет простого определения и может быть интерпретирована как совокупность следующих возможностей системы:
• модульность, т. е. возможность выбора произвольной конфигурации из набора имеющихся модулей в зависимости от потребностей заказчика;
• параметризуемость в соответствии с потребностями заказчика или требованиями регулирующих органов;
• возможность модификации работающей системы при изменении потребностей заказчика или регулирующих нормативов
Способность к наращиванию возможностей. Частично это требование может быть удовлетворено за счет подключения внешних систем, взаимодействующих с данной системой. Однако во многих случаях подобные проблемы решаются проще при наличии в системе встроенных средств, позволяющих создавать дополнительные структуры данных и/или процедур их обработки.
Способность к развитию. Это требование обеспечивается разумным выбором архитектуры системы и технологий, на которые она опирается. Может показаться, что данное требование мало отличается от предыдущего, однако в действительности оно касается стратегического развития системы, которое определяется общими тенденциями бизнеса в отличие от специфических дополнительных требований конкретного банка.
В статье Б. Бабаяна [7] дано следующее определение: открытая система должна иметь стандартный, документированный интерфейс для взаимодействия с другими системами. Иными словами, открытость предполагает простоту и безопасность взаимодействия.