57
приложений баз данных. Выбранный программный продукт должен удовлетворять
как текущим, так и будущим потребностям предприятия, при этом следует
учитывать финансовые затраты на приобретение необходимого оборудования, са-
мой системы, разработку необходимого программного обеспечения на ее основе, а
также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД
способна принести предприятию реальные выгоды[2.стр.34].
Наиболее простой подход при выборе СУБД основан на оценке того, в какой
мере существующие системы удовлетворяют основным требованиям создаваемого
проекта информационной системы. Более сложным и дорогостоящим вариантом
является создание испытательного проекта на основе нескольких СУБД и
последующий выбор наиболее подходящего из кандидатов. Но и в этом случае
необходимо ограничивать круг возможных систем, опираясь на некие критерии от-
бора. В данном случае можно выделить несколько групп критериев:
- Моделирование данных
- Особенности архитектуры и функциональные возможности
- Контроль работы системы
- Особенности разработки приложений
- Производительность
- Надежность
- Требования к рабочей среде
- Смешанные критерии
Основным принципом выбора СУБД следует считать определение
программного продукта, в наибольшей мере соответствующего предъявляемым
требованиям. Эту задачу решить не очень просто. Во-первых, к СУБД
предъявляется большое число требований, которые с течением времени изменяют-
ся, во-вторых, СУБД имеют большое число параметров, что затрудняет их сравне-
ние. Кроме того, информация о СУБД часто носит рекламный характер, не
позволяющий сделать правильное суждение.
Процедуру выбора СУБД следует проводить в три этапа:
- На качественном уровне оценить предлагаемые программные продукты на пред-
мет пригодности;
- Оценка технических характеристик отобранных систем;
58
- Оценка производительности программных продуктов.
К числу основных показателей пригодности программных продуктов отно-
сятся:
- вид программного продукта;
- категории пользователей (профессиональные программисты, администраторы БД,
квалифицированные пользователи, разрабатывающие приложения, конечные поль-
зователи, различные комбинации перечисленных категорий);
- удобство и простота использования (понятные процедуры установки программ-
ных продуктов, удобный и унифицированный интерфейс конечного пользователя,
простота выполнения обычных операций: создания БД, навигации, модификации,
подготовки данных, выполнения запросов и отчетов и ряда других; наличие интел-
лектуальных подсистем подсказок, помощи в процессе работы и обучения, вклю-
чая примеры);
- модель представления данных. Наиболее распространенной является реляционная
модель данных. Перспективными являются модели с объектной ориентацией,
поскольку они обладают большими возможностями отражения семантики пред-
метной области;
- качество средств разработки. При оценке качества средств разработки учитывает-
ся следующее: возможности создания пользовательских интерфейсов, мощность
языка создания программ, автоматизация разработки различных объектов: экран-
ных форм, отчетов, запросов. Предпочтение отдается системам, имеющим
полнофункциональные генераторы и обеспечивающим удобство работы
пользователя;
- качество средств защиты и контроля корректности базы данных. Доступ к функ-
циям защиты должен предусматриваться на уровне средств разработки программ и
на уровне пользователя. К важнейшим функциям контроля корректности относят-
ся: обеспечение уникальности записей БД по первичному ключу, автоматический
контроль целостности связей между таблицами во время выполнения операций об-
новления, вставки и удаления записей, проверка корректности значений в БД;
- качество коммуникационных средств. При оценке качества коммуникационных
средств обращают внимание на следующие свойства программных продуктов:
- поддержку сетевых протоколов,
59
- поддержку стандартных интерфейсов с БД,
- наличие средств групповой работы с информацией БД,
- способность использовать и модифицировать БД других форматов без импорти-
рования или преобразования;
- фирма – разработчик. Солидность фирмы-разработчика пакета, как правило, дает
следующие преимущества:
- высокое качество продукта,
- наличие документации и методических материалов
- наличие «горячей линии» для консультаций по возникающим проблемам
При выборе продукта следует обратить внимание на дату его появления. В
качестве показателей «благополучия» можно использовать: твердое финансовое
положение, перспективная динамика развития аппаратно-программных средств,
годовой оборот, численность состава, объем продаж и т.д. - стоимость. На стои-
мость программных продуктов в основном влияют вид программного продукта и
фирма - разработчик. Стоимость полнофункциональных СУБД обычно колеблется
в пределах $ 500 - $ 1000. Общая стоимость включает в себя стоимость
прикладного инструментария, средств настройки конфигурации системы,
администрирования БД и сопровождения. Иногда общая стоимость крупных си-
стем, построенных на базе реляционных БД, достигает миллионов долларов. Ос-
новным фактором, определяющим общую стоимость системы, чаще всего является
число поддерживаемых пользователей[31.стр.516].
На уровне технических характеристик разнообразие СУБД еще больше, чем
на качественном уровне. К техническим характеристикам относятся:
- общие параметры (операционная среда, потребность в оперативной памяти,
ограничения на максимальный объем БД и др.);
- ограничения на операции над данными;
- типы данных;
- возможности средств формулировки и выполнения запросов;
- работа в многопользовательских средах;
- инструментальные средства разработки приложений;
- импорт и экспорт.
60
Оценка производительности производится методом тестирования с помощью
эталонных тестов из набора AS3AP (ANSI SQL Standard Scalable and Portable). В
них контролируется широкий спектр часто встречающихся операций БД и модели-
руются однопользовательские и многопользовательские среды.
Ниже, в таблице 1.10. приведена сравнительная таблица трех распространенных
систем управления базами данных, конкурирующих на рынке программного обес-
печения по основным показателям.
Таблица №1.8
Сравнение СУБД
Показатели
Microsoft SQL Server
2008
MySQL 5.1
PostgreSQL 8.4
Поддерживаемые опе-
рационные системы
Windows
Desktop/Server
Windows Desk-
top/Server ,
Linux, Unix,
Mac
Windows1 Desk-
top/S22erver, Linux,
Unix, 2Mac
Условие
лицензирования
Коммерческий продукт
с закрытым исходным
кодом. Есть бесплатная
версия с ограничением
оперативной памяти до
4 Гб.
Коммерческая
лицензия и
GNU GPL.
Лицензия BSD Open
Source.
Наличие предустанов-
ленных драйверов в
ОС семейства
Windows
Да
Нет
Нет
Наличие драйверов
ODBC, JDBC, ADO
.NET
Да
Да
Да
Поддержка
репликации
Да, встроенная и раз-
ных типов. Но внесе-
ние структурных
изменений после нача-
ла репликаци - очень
сложный процесс.
Да, включая
mater-master
репликацию.
Да, но с помощью
сторонних продук-
тов с открытым ис-
ходным кодом. Ре-
пликация всех типов
.
Возможность писать
хранимые функции на
разных языках про-
граммирования
Да, теоретически на
любом языке, поддер-
живающим CLR,
например
VisualBasic.NET, C#,
IronPython, но сначала
надо скомпилировать
код в библиотеку dll.
Нет (кроме C и
Pl/SQL)
Да, наиболее полная
поддержка из всех
рассматриваемых.
61
Продолжение таблицы №1.8
Возможность созда-
вать пользовательские
агрегированные ф-ци
Да - любой .NET язык,
кроме TRANSACT
SQL.
Да, только на С
Да - на PL language и
встроенных C, SQL,
PLPgSQL.
Поддержка даты и
времени
Да
Да (но без
временной зо-
ны)
Да
Аутентификация
Средствами БД и
ActiveDirectory
Средствами БД
Много разных
методов, включаю-
щих предыдущие
Разграничение досту-
па к столбцам
Да
Да
Да
Поддержка DISTINCT
ON
Нет
Нет
Да
Поддержка WITH
ROLLUP
Да
Да
Да
Поддержка WITH
CUBE
Да
Нет
Нет
Поддержка функций
OVER..PARTITION
BY
Да
Нет
Да, причем лучше,
чем в MS SQL
Поддержка рекурсив-
ных запросов
Да
Нет
Да
Производительность
планировщика запро-
сов для сложных за-
просов
Средняя (умеет парал-
лельные запросы «из
коробки»)
Очень хорошая
Плохая
Таким образом, для проекта, рассматриваемого в данном дипломном проекте
наиболее приемлема СУБД MS SQL.
Для реализации приложения пользователя выбран язык программирования ASP.
ASP (англ. Active Server Pages - «активные серверные страницы») -
технология, разработанная компанией Microsoft, позволяющая легко создавать
приложения для World Wide Web. ASP работает на платформе операционных си-
стем линии Windows NT и на веб-сервере Microsoft IIS[39.стр. 51].ASP не является
языком программирования - это лишь технология предварительной обработки, поз-
воляющая подключать программные модули во время процесса формирования веб-
страницы. Относительная популярность ASP основана на простоте используемых
языков сценариев (VBScript или JScript) и возможности использования внешних
COM-компонентов.
62
Технология ASP получила своё развитие в виде ASP.NET - новой технологии
создания веб-приложений, основанной на платформе Microsoft .NET.
ASP.NET - технология создания веб-приложений и веб-сервисов от компа-
нии Майкрософт. Она является составной частью платформы Microsoft .NET и
развитием более старой технологии Microsoft ASP. На данный момент последней
версией этой технологии является ASP.NET 4.0b.
ASP.NET внешне во многом сохраняет схожесть с более старой технологией
ASP, что позволяет разработчикам относительно легко перейти на ASP.NET. В то
же время внутреннее устройство ASP.NET существенно отличается от ASP, по-
скольку она основана на платформе .NET и, следовательно, использует все новые
возможности, предоставляемые этой платформой.
Хотя ASP.NET берёт своё название от старой технологии Microsoft ASP, она значи-
тельно от неё отличается. Microsoft полностью перестроила ASP.NET, основываясь
на Common Language Runtime (CLR), который является основой всех приложений
Microsoft .NET. ASP.NET имеет преимущество в скорости по сравнению со скрип-
товыми технологиями, так как при первом обращении код компилируется и
помещается в специальный кэш, и впоследствии только исполняется[19.стр.79].
Вместе с тем следует учитывать, что указанное преимущество не всегда мо-
жет быть реализовано. Это связано с тем, что на скорость работы реального проек-
та влияют множество факторов.
63
II. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий методологии
проектирования информационных систем. Жизненный цикл информационной си-
стемы представляет собой непрерывный процесс, начинающийся с момента
принятия решения, о создании информационной системы и заканчивается в момент
полного изъятия ее из эксплуатации.
Жизненный цикл информационной системы охватывает все стадии и этапы
ее создания, сопровождения и развития:
- исследование предметной области с последующим формированием функциональ-
ной и информационной моделей объекта, для которого предназначена информаци-
онная система;
- проектирование системы, заключающееся в разработке проектных решений, удо-
влетворяющих всем требованиям ТЗ;
- разработку системы (в том числе программирование и тестирование прикладных
программ на основании проектных спецификаций подсистем, выделенных на ста-
дии проектирования);
- тестирование информационной системы и выявление сбоев с последующим их
устранением;
- эксплуатацию системы и ее сопровождение;
- развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых
случаях и процессы разработки[6.стр.44].
Среди наиболее известных стандартов можно выделить следующие:
- ГОСТ 34.601-90 - распространяется на автоматизированные системы и
устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится
описание содержания работ на каждом этапе. Стадии и этапы работы,
закрепленные в стандарте, в большей степени соответствуют каскадной модели
жизненного цикла[13].
64
- ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла.
Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз,
стадий и этапов.
- Custom Development Method (методика Oracle) по разработке прикладных
информационных систем - технологический материал, детализированный до
уровня заготовок проектных документов, рассчитанных на использование в проек-
тах с применением Oracle. Применяется CDM для классической модели ЖЦ
(предусмотрены все работы/задачи и этапы), а также для технологий "быстрой раз-
работки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых
проектов.
- Rational Unified Process (RUP) предлагает итеративную модель разработки,
включающую четыре фазы: начало, исследование, построение и внедрение. Каждая
фаза может быть разбита на этапы (итерации), в результате которых выпускается
версия для внутреннего или внешнего использования. Прохождение через четыре
основные фазы называется циклом разработки, каждый цикл завершается генера-
цией версии системы. Если после этого работа над проектом не прекращается, то
полученный продукт продолжает развиваться и снова минует те же фазы. Суть
работы в рамках RUP - это создание и сопровождение моделей на базе UML.
- Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы:
анализ, проектирование, разработка, стабилизация, является итерационной,
предполагает использование объектно-ориентированного моделирования. MSF в
сравнении с RUP в большей степени ориентирована на разработку бизнес-
приложений.
- Extreme Programming (XP). Экстремальное программирование (самая новая среди
рассматриваемых методологий) сформировалось в 1996 году. В основе
методологии командная работа, эффективная коммуникация между заказчиком и
исполнителем в течение всего проекта по разработке ИС, а разработка ведется с
использованием последовательно дорабатываемых прототипов.
- Стандарт ISO/IEC серии 15288
В стандарте ISO/IEC 12207 не предлагается конкретной модели жизненного
цикла и методов разработки, его рекомендации являются общими для любых моде-
лей жизненного цикла. Под моделью обычно понимается структура, определяющая
65
последовательность выполнения и взаимосвязи процессов, действий и задач на
протяжении жизненного цикла[25].
В настоящее время существует две основные модели жизненного цикла - это
каскадная и спиральная модели. В каскадной модели процесс разработки идет по-
этапно, шаг за шагом. Переход к следующему этапу происходит только после
завершения предыдущего. В спиральной модели разработка проходит по нараста-
ющей. На начальном этапе разрабатывается система с высоким уровнем абстрак-
ции, а на последующих витках эта разработка все больше и больше конкретизиру-
ется. Для жизненного цикла текущего проекта была выбрана каскадная модель, так
как для разрабатываемой системы больше подходит поэтапная разработка. Переход
к следующему этапу происходит только после завершения всех работ на предыду-
щем этапе (Рис. 2.1), включая подготовку полного пакета документации,
достаточной для того, чтобы разработка могла быть продолжена другой группой
разработчиков и есть возможность планирования сроков завершения работ и затрат
на их выполнение.
66
Рисунок №2.1 Каскадная схема разработки ПО.
Каскадный метод хорошо подходит для построения систем, где в самом
начале разработки можно достаточно точно и полно сформулировать все требова-
ния, с тем, чтобы предоставить разработчикам свободу реализовывать их как
можно лучше с технической точки зрения. Однако в случае, если в середине
разработки вскрываются ошибки, допущенные в начале, то приходится прибегать к
энтраверсии проекта и реальная схема каскадной модели приобретает другой вид.
Таким образом, каскадный метод более всего подходит к конкретной разработ-
ке[11.стр.254].