Файл: Разработка автоматизированного рабочего места библиотекаря (на примере Университета Синергия).docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 26.10.2023
Просмотров: 602
Скачиваний: 28
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Таблица 5
Сравнение характеристик языков программирования С++ и Delphi
Характеристика | С++ | Delphi |
Сложность изучения | большая (-) | маленькая (+) |
Количество специалистов-профессионалов | много (+) | мало (-) |
Восприятие кода | плохое (-) | хорошее (+) |
Рефакторинг | средний (+-) | хороший (+) |
Скорость работы приложения | отличная (++) | хорошая (+) |
Скорость разработки решения | маленькая (-) | очень высокая (++) |
Наличие документации | много (+) | MSDN не содержит примеров кода на pascal (+-) |
Необходимость в будущем, ввиду конкуренции с языками C#,VB, Java | маленькая (–) | средняя (-) |
Итого | 5+/5- | 7+/3- |
На основании вышеприведенных данных для разработки модуля было решено использовать продукт Delphi 10.
Современные базы данных — один из тех объектов в сфере информатизации, от которых иногда требуется особенно высокое качество и наличие возможности его оценки.
БД – база данных. Под этим термином понимается информация, которую надо сохранить.
СУБД – система управления базой данных. Это программа, которая предоставляет доступ внешним приложениям к базе данных, обеспечивает ее работу.
База данных проектируется и создается для каждого конкретного проекта, СУБД же выбирается из небольшого списка стандартных средств.
В качестве возможных вариантов рассматриваются MySQL против PostgreSQL.
MySQL — одни из самых популярных реляционных систем управления базами данных (РСУБД). Рассмотрим функциональные различия между ними и сравним их производительность, чтобы выбрать лучшую СУБД для АРМ.
PostgreSQL и MySQL: сравнение производительности
Проведение тестов будет честным, если сравнивать две чистых системы, то есть решения «из коробки». Тестирование с индексом дает следующие результаты:
При добавлении MySQL оказывается более чем в 2,7 раза быстрее, обрабатывая БД на 400 тыс. записей за 5,5 секунд против 15 сек. у Postgres.
При внутреннем объединении MySQL обрабатывает 400 тыс. записей за 1,1 сек., а Postgres за 2,8 сек., что дает выигрыш более чем в 2,5 раза.
При сортировке с индексом аналогичное количество записей MySQL обрабатывает за 0,9 сек., а Postgres — за 1,5 сек.
Показатели при группировке следующие (БД аналогичная, на 400 тыс. записей): у MySQL — 0,35 сек., у Postgres — 0,52 сек.
Выборка с индексом дает преимущество «MySQL» в 2 раза: 0,6 сек. против 1,2 сек.
Что касается обновления в БД, то здесь MySQL демонстрирует постепенный рост по мере увеличения количества записей, а вот Postgres обрабатывает их за примерно одно и то же время, начиная со 100 тыс. записей. Это связано с разной реализацией хранения данных. Тем не менее преимущество у MySQL даже на больших объемах данных существенное: 3,5 против 9,5 сек. на 400 тыс. записей, то есть более чем в 2,7 раза.
При отмене индексов MySQL также выдает на удивление высокую производительность, обрабатывая БД на 400 тыс. записей за 1,3, 0,7 и 2,2 сек. при внутреннем объединении, выборке и обновлении соответственно.
Таким образом, производительность MySQL оказывается выше в среднем в 2 раза (2,06).
Для наглядности представим главные особенности обеих систем в виде таблицы 6:
Таблица 6
Сравнение СУБД
Характеристики | PostgreSQL | MySQL |
Соответствие стандарту SQL | почти полное | частичная совместимость |
Поддерживаемые ОС | Solaris, Windows, Linux, OS X, Unix, Hp-UX | Solaris, Windows, Linux, OS X, FreeBSD |
Применение | Массивные базы данных со сложными запросами (например, Big Data) | Более легкие базы данных (например, веб-сайтов и приложений) |
Типы данных | Поддерживает расширенные типы данных, включая массивы, hstore | Поддерживает стандартные типы данных SQL |
Наследование таблиц | Да | Нет |
Триггеры | Поддерживает триггеры по большому количеству команд | Ограниченная поддержка триггеров по командам |
Движки для хранения данных | Один (Storage Engine) | Разные |
Таким образом, для проекта, рассматриваемого в данной работе наиболее приемлема СУБД MySQL.
На данный момент актуальная версия данной СУБД – MySQL 8.0.33. Именно она и будет использоваться в данной работе.
1.4.3Обоснование проектных решений по техническому обеспечению
В качестве АРМ необходимо использовать персональные компьютеры со следующей минимальной конфигурацией:
-
Частота процессора 2,8 ГЦ и выше -
Оперативная память объемом 2048 или выше -
·Жесткий диск 200,0 Gb или выше. -
Привод DVD. -
Монитор 17" или выше
ИБП APCBack-CS500VA, аналогичный или лучше.
Для вывода отчета на печать необходимо наличие подключенного принтера или МФУ.
Перечисленное оборудование является минимальным для функционирования разработанного АРМ.
На данный момент имеющееся оборудование удовлетворяет всем перечисленным требованиям.
II Проектная часть
-
Разработка проекта автоматизации
-
Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий методологии проектирования информационных систем. Жизненный цикл информационной системы представляет собой непрерывный процесс, начинающийся с момента принятия решения о создании информационной системы и заканчивающийся в момент полного изъятия ее из эксплуатации.
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
В состав ЖЦ ПО обычно включаются следующие стадии:
-
формирование требований к ПО -
проектирование (разработка системного проекта) -
реализация (может быть разбита на подэтапы: детальное проектирование, кодирование) -
тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию) -
ввод в действие (внедрение) -
эксплуатация и сопровождение -
снятие с эксплуатации
Процесс жизни любой системы или программного продукта может быть описан посредством модели жизненного цикла, состоящей из стадий. Модель жизненного цикла представляется в виде последовательности стадий, которые могут перекрываться и (или) повторятся циклически в соответствии с областью применения, размером, сложностью, потребностью в изменениях и возможностями. Каждая стадия описывается формулировкой цели и выходов. Процессы и действия жизненного цикла отбираются и исполняются на этих стадиях для полного удовлетворения цели и результатов этой стадии.
Каскадная модель предусматривает последовательную организацию работ. Демонстрируется классический подход к разработке различных систем из любой ПО.
В ранее существовавших ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
. В общем виде данная модель представлена на рисунке 17.
Рисунок 17 - . Основные этапы разработки по каскадной модели
Спиральная модель предлагает итерационный процесс разработки ИС. Основной упор делается на начальные этапы ЖЦ – анализ и проектирование, так как именно здесь проверяется и обосновывается реализуемость технических решений путем создания прототипов(рис. 18).
Рисунок 18 - Спиральная модель ЖЦ
Схема работы спиральной модели выглядит следующим образом.
Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом начальные стадии, связанные с анализом и планированием, представлены более подробно с добавлением новых элементов. В каждом цикле выделяются четыре базовые фазы:
-
определение целей, альтернативных вариантов и ограничений, -
оценка альтернативных вариантов, идентификация и разрешение -
рисков, -
разработка продукта следующего уровня, -
планирование следующей фазы
Инкрементная стратегия (англ. increment – увеличение, приращение) подразумевает разработку информационной системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта.
В начале работы над проектом определяются все основные требования к системе, после чего выполняется ее разработка в виде последовательности версий. При этом каждая версия является законченным и работоспособным продуктом. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система.
Данная модель жизненного цикла характерна при разработке сложных и комплексных систем, для которых имеется четкое видение (как со стороны заказчика, так и со стороны разработчика) того, что собой должен представлять конечный результат (информационная система). Разработка версиями ведется в силу разного рода причин:
- отсутствия у заказчика возможности сразу профинансировать весь дорогостоящий проект;
- отсутствия у разработчика необходимых ресурсов для реализации сложного проекта в сжатые сроки;
- требований поэтапного внедрения и освоения продукта конечными пользователями. Внедрение всей системы сразу может вызвать у ее пользователей неприятие и только «затормозить» процесс перехода на новые технологии. Образно говоря, они могут просто «не переварить большой кусок, поэтому его надо измельчить и давать по частям».
Достоинства и недостатки этой стратегии такие же, как и у классической. Но в отличие от классической стратегии заказчик может раньше увидеть результаты. Уже по результатам разработки и внедрения первой версии он может незначительно изменить требования к разработке, отказаться от нее или предложить разработку более совершенного продукта с заключением нового договора. [21]. Графически данная модель показана на рисунке 19.
Рисунок 19 -