58
присутствует в рейтингах. Кроме того, AJAX потребляет некоторое количество
ресурсов самого пользовательского ПК, поэтому при отображении большого и
красочного сайта возможны повисания и некоторое снижение активности
системы.
15. XML является иерархической технологией для хранения данных в
текстовой виде. В какой-то мере написание скриптов на XML можно относить к
объектно-ориентированному программированию. Можно выделить множество
объектов, которые обладают собственным набором свойств и обычно является
либо элементом управления, либо подключаемым модулем. Для настройки
каждого объекта используется описание его параметров с учетом вложенности
свойств, которые зачастую имеют также свои свойства. XML является строгим
языком и отдельно практически не используется, а применяется как составная
часть динамической технологии визуализации страницы или для разработки
собственной базы данных [11].
Таким образом, определив плюсы и минусы рассмотренных выше языков,
выбор был таков: HTML – для разметки страниц сайта, CSS – для оформления
стиля страницы, JavaScript и базирующийся на нем AJAX – для быстрой работы
сайта и проверки переданных данных на корректность, PHP – как основного
языка проекта, поскольку он предназначен для создания подобных разработок
[5], а также по нему всегда можно найти большое количество информации в
интернете, сам язык нельзя назвать сложным, существует много сред для
разработки на нем, результат работы можно видеть в режиме реального времени
на своем домашнем ПК без обращения к удаленному серверу.
Определение самой подходящей СУБД является труднореализуемой
задачей с различными требованиями и параметрами, но становится по сути
самым важным этапом в процессе создания приложений БД. Определенный по
факту программный продукт обязан удовлетворять настоящим и будущим
требованиям фирмы, а сам выбор должен учесть и возможные денежные затраты
на покупку оборудования, создание ПО, установку системы с последующим
обучением сотрудников. Также важно понимать, что созданная СУБД даст
фирме реальный доход .
59
Самый простой способ выбора СУБД основан на оценке того, в какой
мере уже существующие системы удовлетворят основным требованиям
создаваемого проекта ИС. Более сложным, но и боле эффективным и
показательным можно назвать дорогостоящий вариант, который предполагает
создание тестовой конфигурации на основе нескольких СУБД и дальнейший
выбор одного из предложенных кандидатов. Но даже в таком случае необходимо
серьезно ограничивать крут рассматриваемых систем путем применения
некоторых групп критериев, например [6]:
• Особенности архитектуры и функциональность;
• Моделирование данных;
• Особенности разработки приложений;
• Надежность;
• Максимальная производительность;
• Требования к рабочей среде;
• Методики осуществления контроля работы системы;
• Другие смешанные критерии.
Главным принципом выбора СУБД принято считать определение
продукта, максимально удовлетворяющего предъявляемым требованиям. Но
решить такую задачу не так просто. Все потому, что к СУБД применяется
большое количество требований, которые со временем изменяются, также СУБД
имеют огромное число параметров, которые значительно усложняют сравнение,
а информация о таких системах часто носит лишь рекламный характер и никак
не соответствует действительности.
Стандартно, процедуру выбора СУБД лучше проводить в 3 этапа:
1. Оценить предлагаемые программные продукты на предмет их
адекватности на качественном уровне;
2. Оценить технические возможности выбранных систем;
3. Оценить производительность в реальных задачах.
Важно помнить, что к числу показателей пригодности ПО обычно относят
следующее [8]:
• Вид рассматриваемого программного продукта;
• Реализованные категории пользователей:
60
Профессиональные программисты;
Администраторы баз данных;
Конечные пользователи;
Разрабатывающие приложения;
Квалифицированные пользователи;
• Простота и удобство использования - понятная процедура
установки программы, логичный и простой интерфейс, логичность выполнения
базовых операций: создание БД и записей в ней, навигации, модификации,
проверки и подготовки данных, выполнение запросов, наличие системы
подсказок с примерами.
• Наличие модели представления данных (обычно это реляционная
модель). Самыми перспективными являются модели с объектной ориентацией,
поскольку обладают возможностями отражения семантики предметной области;
• Качество использованных средств разработки. В такой оценке
принято учитывать следующее: возможность создания интерфейса пользователя,
определение мощности языка создания программы, а также автоматизации
разработки разных объектов – отчетов, форм, запросов. В итоге выбор делается в
пользу систем с полнофункциональным генератором, который обеспечивает
удобство пользовательской работы;
• Используемые средства для защиты БД и проверки ее корректности.
Доступ к таким средствам должен предоставляться как на уровне средств
разработки, так и пользовательском уровне. Самыми важными функциями
контроля корректности являются: уникальна запись по первичному ключу в БД,
целостность связей между таблицами во время обновления, удаления и вставки
информации;
• Качество используемых средств коммуникации. Обычно при оценки
их качеств основное внимание обращают на следующие свойства ПО:
Поддержка стандартных интерфейсов БД и сетевых протоколов;
Возможность групповой работы с данными в БД;
Возможность модификации и использования БД других форматов
без дополнительного преобразования;
61
• Фирма-разработчик ПО. Обычно чем известнее и солиднее
компания, тем больше преимущества от сотрудничества, а именно:
Отличное качество готового продукта;
Наличие всей документации на понятном языке;
Телефонная «горячая линия» и круглосуточная техническая
поддержка.
Чтобы выбрать СУБД, проведем анализ уже существующих решений. Для
начала выберем часто используемые языки и сделаем небольшое сравнение.
Выбор СУБД обычно представляет из себя сложную задачу, для решения
которой важно всегда учитывать множество параметров и факторов. Данная
проблема является наиболее значимой на этапе разработки приложения.
Выбранный в итоге программный продукт должен обязательно удовлетворять
текущим и будущим потребностям компании, при этом выбор должен учитывать
все финансовые затраты на приобретение оборудования, системы, разработку
необходимого ПО и последующее обучение персонала. Кроме того, важно
убедится, что разработанная СУБД принесет компании реальные выгоды.
Обычно, перечень требований к СУБД может меняться в зависимости от
поставленных целей. Но все равно всегда можно выделить несколько групп
критериев:
• Функциональные возможности;
• Производительность системы;
• Требования к рабочей среде;
• Структура расположения данных;
• Особенности разработки приложений.
Рассмотрим каждый из перечисленных критериев более подробно.
1. Функциональные возможности – обычно в данной группе
выделяются следующие критерии мобильность (независимо от самой системы и
среды, в которой она работает), сетевые возможности, триггеры, а также
масштабируемость (сможет ли выбранная система соответствовать текущему
росту ИС в дальнейшем).
2. Производительность – является одним из самых важных
показателей, используемых в статье в качестве основного критерия при выборе
62
СУБД. Всего выделяют несколько факторов, которые относят к
производительности системы, и которые могут учитываться при ее оценке.
Такими факторами являются рейтинг TCP (Transactions per Cent), поддержка
параллельной архитектуры и оптимизация запросов.
3. Требования к рабочей среде – в данной группе не так много
требований, поэтому выделяют следующие: поддерживаемые аппаратные
платформы, требования к операционной системе и периферийному
оборудованию.
4. Структура расположения данных – выделяют следующие
требования: применяемая модель данных (вопрос о использовании той или иной
модели решается еще на начальном этапе проектирования ИС),
предусматриваемые типы данных.
5. Особенности разработки приложений. Сегодня многие
производители СУБД стараются выпускать такие средства для своих систем.
Обычно такие прикладные программы способны наилучшим образом
реализовать все возможности сервера, поэтому при анализе СУБД следует
рассматривать и возможности идущих с ними средств разработки приложений. К
данной группе можно отнести такие требования, как мульти языковая
поддержка, возможности разработки веб-приложений и встроенные средства
проектирования.
Рассмотрим 5 различных реляционных СУБД. Согласно методу анализа
иерархий, предложенному Т. Саати, проводится попарное сравнение всех СУБД
по каждому критерию, в результате чего получается 5 матриц попарных
сравнений альтернатив.
В качестве альтернатив рассмотрим следующие СУБД:
1) DB2;
2) Oracle;
3) Microsoft SQL Server;
4) MySQL;
5) PostgreSQL.
На основании данного сравнения выбираем для использования СУБД
MySQL [7].
63
Преимущества MySQL:
• наилучшая скорость обработки данных на объеме до 500000
записей;
• бесплатные открытые лицензии;
• простота использования;
• поддержка большинством хостинговых компаний;
• возможность использования на различных платформах (Unix,
Windows, др.).
1.4.3 Обоснование проектных решений по техническому обеспечению
Техническое обеспечение включает в себя ПК, оргтехнику, линии связи,
сетевое оборудование. Вид ИТ, зависящий от технической оснащенности
(автоматизированный, удаленный или ручной) оказывает влияние на сбор,
обработку и передачу данных.
В совокупность технических средств включаются [14]:
• ПК;
• устройства сбора, хранения, обработки, передачи и вывода данных
– жесткие диски, сканеры, принтеры, факсимильные аппараты;
• устройства передачи данных и линий связи – коммутаторы,
маршрутизаторы;
• эксплуатационные материалы – оптические носители, бумага и т. п.
В процессе выбора ПК важно опираться на ряд характеристик. К ним
относятся надежность, итоговая стоимость, мощность, простота использования и
др. От указанных параметров зависит доступность работы с необходимым ПО, и
как следствие, успех создания системы.
Каждый элемент данной схемы имеет перечень критериев, которые
оказывают особое влияние при выборе технического обеспечения. К ним
относятся:
• Частота работы процессора;
• Максимальное разрешение монитора;
• Общий объем ОЗУ.
64
Для решения поставленной задачи необходимо использовать
персональный компьютер с уровнем вычислительной мощности AMD 2000 Мгц,
либо Intel 2000 Мгц, с объемом оперативной памяти от 2 Гб. Система
оптимизирована для работы в экранном разрешении 1024х768 на мониторе с
диагональю 17 дюймов. Все эти технические средства обладают достаточной для
решения задачи конфигурацией.
В настоящее время разрозненный парк персональных компьютеров
создает сложности с их техническим обслуживанием, ремонтом, поэтому
необходимо его унифицировать и закупить одинаковые рабочие станции.
Технические характеристики подходящей рабочей станции приведены в
таблице 1.6:
Таблица 1.7
Характеристики рабочей станции
Производитель
Hugel
Модель процессора
Intel Atom Single Core N270 - 1.66GHz
Оперативная память
2048Mb
Жесткий диск
160 Gb
Оптический привод
DVD-RW
Видеоадаптер
Интегрирован в чипсет
Разъемы на материнской плате
7 USB, выход S/PDIF, 2xCOM, D-Sub,
DVI, Ethernet, PS/2 (клавиатура), LPT
Корпус
mATX 250W
Операционная система
Не установлена
Размеры (ШхГхВ)
283 х 282 х 95 (мм)
Кроме того, для работы файл-сервера необходимо закупить
специализированной серверное оборудование, например Team Server 3420P ,
характеристики которого приведены в таблице 1.7.
Таблица 1.8
Технические характеристики рекомендуемого сервера
типичное применение
интернет/интранет-службы, терминальные службы,
65
контроллер домена, файловый сервер,
универсальный сервер рабочей группы или
небольшой МАОУ Сергеевская СОШ
процессоры
Один четырехядерный процессор Intel Xeon 3400
кэш-память процессора
64KB кэш-памяти 1-го уровня для каждого ядра
256KB кэш-памяти 2-го уровня для каждого ядра
8 МБ общей для всех ядер кэш-памяти 3-го уровня
серверная платформа
Intel S3420GP
набор микросхем
чипсет Intel 3420
оперативная память
до 32 ГБ ECC Registered DIMM DDR3 800/1066/1333
сетевой контроллер
два интегрированных однопортовых Intel Gigabit
Ethernet
дисковый контроллер/
RAID-контроллер
интегрированный 6-ти портовый Serial ATA II RAID
контроллер (уровни 0, 1, 10)
дисковод/оптический
привод
привод SATA DVD-RW
максимальное
количество внутренних
дисковых отсеков
6 Serial ATA II или SAS
возможность "горячей"
замены дисков
Да
максимальная емкость
внутренних накопителей
6 ТБ SATA (6x1000 ГБ)
6 ТБ SAS (6x1000 ГБ)
интерфейсы
6 портов USB 2.0, Serial port, монитор
графический адаптер
интегрированный видеоконтроллер LLC Pilot II с 64
MB видеопамяти (VGA DB-15)
Таким образом, техническое оборудование сервера соответствует
предъявляемым требования и в модернизации не нуждается.
В данном виде информационная система будет готова в внедрению
автоматизированной системы контроля знаний.
66
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Методология проектирования ИС включает в себя описание процесса
создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС,
отождествляя его с некоторой последовательностью стадий и исполняемых на
них процессов. Для каждой стадии выявляется состав и последовательность
производимых работ, итоговые результаты, методы и средства, нужные для
реализации работ, ответственность и роль участников и т.д. Подобное
формальное описание ЖЦ ИС дает возможность спланировать и подготовить
процесс совместной разработки и поддерживать управление этим процессом.
Жизненный цикл (ЖЦ) ИС представляется, как ряд событий,
случающихся с системой с момента ее внедрения и до окончания использования.
Модель ЖЦ отражает различные состояния системы, от момента
возникновения необходимости в данной ИС и до момента ее окончательного
вывода из эксплуатации. Модель жизненного цикла представлена некой
структурой, которая содержит процессы, действия и задачи, реализуемые в ходе
создания, работы и сопровождения ПО в течение всей жизни системы, от
выявления требований до окончания ее использования.
Сегодня известны и применимы следующие модели жизненного цикла:
• Каскадная модель включает в себя последовательную реализацию
всех этапов проекта в заранее определенном порядке. Начало следующего этапа
говорит о полном завершении работ на предыдущем этапе.
• Поэтапная модель с периодичным контролем. Создание ИС
реализовано в виде итераций с циклами обратной связи между этапами.
Межэтапные проверки позволяют учесть реально существующее взаимовлияние
итогов разработки на различных этапах; ЖЦ каждого из этапов продлевается на
весь срок разработки.
• Спиральная модель. На любом витке спирали выполняется
генерация очередной версии продукта, корректируются требования проекта,
67
выражается его качество и планируются работы уже следующего витка. Особое
внимание при этом обращается на начальные этапы разработки - анализ и
проектирование, где возможность создания тех или иных технических решений
обосновывается и проверяется благодаря построению прототипов.
Каскадный подход отлично зарекомендовал себя в процессе создания
относительно простых ИС, когда в самом начале разработки можно с большой
точностью и полнотой составить все требования к системе. Главным
недостатком такого подхода является то, что основной процесс разработки
системы не может полностью уложится в такие жесткие рамки, постоянно есть
потребность в возврате к уже завершенным этапам для уточнения или изменения
ранее принятых решений. В итоге реальный процесс разработки ИС становится
соответствующим поэтапной модели с периодичным контролем.
Для разработки документооборота материально-технического
оборудования выбираем каскадную модель.
Все стадии создания системы предусматривают выполнение некоторого
объема работ, представляемых в виде процессов ЖЦ. Процесс выражается как
совокупность объединенных действий, изменяющих входные данные в
выходные. Описание любого процесса состоит из перечня решаемых задач,
исходных данных и итоговых результатов.
Есть целый ряд стандартов, определяющих ЖЦ ПО, а в отдельных случаях
и процессы разработки.
Среди самых известных стандартов выделяют следующие:
• ГОСТ 34.601-90 - распространяется на АИС и указывает в себе
стадии и этапы их создания. Также в нем имеется описание содержания работ на
всех этапах. Стадии и этапы работы, отраженные в стандарте, зачастую
соответствуют каскадной модели жизненного цикла.
• ISO/IEC 12207:1995 - стандарт на процессы и реализацию
жизненного цикла. Применяется ко всем видам заказного ПО. Стандарт не имеет
описания стадий, фаз и этапов.
• Custom Development Method по созданию прикладных ИС -
технологический материал, углублённый до уровня заготовок проектных
документов, которые рассчитаны на применение в проектах совместно с Oracle.