38
Delphi
Delphi – хороший объектно-ориентированный язык программирования,
когда требуется разработать ПО в максимально сжатые сроки и обеспечить
хороший рефакторинг (читабельность, модифицируемость, удобство и
оптимизацию) кода приложения. Код хорошо структурируется, названия всех
функций по сути есть сокращения английских слов (IntToStr – целое в
строку; Now – возвращает дату и время сейчас; UpperCase – приводит к
верхнему регистру и тд), хорошая модульность и видимость кода – все это
способствует скорости разработки, а также позволяет производить ее в
командном режиме более эффективно.
Существенным преимуществом делфи является низкий порог
вхождения. То есть язык легко усваивается, интуитивно понятен. Сейчас его
продвигают в сторону кросс-платформенности, хотя раньше такого не было..
Более того, большое комьюнити Delphi кодеров (в котором больше
непрофессионалов в силу легкости языка) порождает в Интернете большое
количество справочной информации в самых разных областях
программирования.
Подведем итоги в таблице 1.2.
Таблица 1.2
Сравнение характеристик языков программирования
Характеристика
С++
Delphi
Pyph
on
Сложность
изучения
большая (-)
маленькая
(+)
Средняя(+-)
Количество
специалистов-
профессионалов
много (+)
мало (-)
Много(+)
Восприятие кода
плохое (-)
хорошее (+)
Плохое(-)
Рефакторинг
средний (+-)
хороший (+)
Средний(+-
)
Скорость работы
приложения
отличная
(++)
хорошая (+)
Средняя(+-)
Скорость
разработки
решения
маленькая (-)
очень
высокая (++)
Маленькая(-
)
Наличие
документации
много (+)
MSDN не
содержит примеров
Много(+)
39
кода на pascal (+-)
Необходимость в
будущем, ввиду
конкуренции с
языками C#,VB,
Java
маленькая (–)
средняя (-)
Маленькая(-
)
Популярность(на
январь 2020)
4 место
12 место
3 место
Итого
5+/5-
7+/3-
5+/5-
На основании вышеприведенных данных для разработки модуля было
решено использовать продукт Delphi 10.
БД – база данных. Под этим термином понимается информация,
которую надо сохранить.
СУБД – система управления базой данных. Это программа, которая
предоставляет доступ внешним приложениям к базе данных, обеспечивает ее
работу.
База данных проектируется и создается для каждого конкретного
проекта, СУБД же выбирается из небольшого списка стандартных средств.
В качестве возможных вариантов рассматриваются MySQL против
Firebird и MS SQL Server
MySQL - сервер, который работает с MYISAM и InnoDB таблицами.
Как изветсно,InnoDB, это научная работа Хейки Туури в Хельсинском
универе (1994-2000) в области высокопроизводительных технологий БД.
В серверах на Linux, mysql это практически стандарт де факто. А
Firebird, де факто,БД для Windows в небольших корпорациях стран СНГ. А
вот за границей его применяют в основном как БД накопления и хранения
данных в пользовательских приложениях удаленных сотрудников и
малопользовательских CRM.
Основные недостатки Firebird:
подходит только для простых и не глобальных решений
нет автоинкремента потому приходится создавать генератор
(использование которого аукается некоторыми весьма неприятными
последствиями). А именно в FireBird для поля введён некий генератор. т. е.,
40
чтобы всё-таки получить очередное уникальное значение, сначала
потребуется увеличить значение генератора. Нужно создать запрос, получить
результат, обработать его в программе, и уже с ним генерить второй запрос
INSERT INTO catalog VALUES(, 'text value');таким образом получаем два
запроса к БД вместо одного, и два обработчика на стороне клиента. Иными
словами, получаем двойные накладные расходы на каждом запросе записи.
Элементарный и наиболее часто используемый запрос выбора всех
записей таблицы типа SELECT * FROM driver WHERE id = 1 сразу
возвращает все что нам нужно и цифровые и текстовые данные,но Firebird не
делает этого -вместо ожидаемого текста возвращается идентификатор
(BLOB_ID), с помощью которого (и дополнительного запроса!) можно
получить значение поля. а если всё-таки нужно получать текст, то полю
назначается другой тип: VARCHAR(32765). Как итог накладные расходы на
селект выростают в 4 раза. По сравнению с другими БД.
А нам как раз нужно совершать огромное количество именно SELECT.
Невозможно себе позволить такие накладные расходы. БД Firebird не
подходит однозначно.
Лучшая по результатам линейных SELECT всегда была и остается
MySql обгоняя любые другие БД. MySql проигрывает почти всем при
выполнении сложных составных запросов, требующих промежуточных
вычислений самой БД, но в программах документооборота таких нет. По
крайне мере всегда можно согласиться в одном или двух местах на некоторое
увеличение накладных расходов, но это не будут постоянные и
неоправданные расходы при всех SELECT которые неизбежны с Firebird.
Единственное преимущество Firebird в том что на него можно возложить
обработку запросов которые имеют данные связанные между собой, но
находящиеся в разных таблицах. В нем нет нет хранимых процедур,
триггеров и еще много чего. Но все это можно сделать внутри приложения.
Будет немного больше кода, но оно с лихвой окупается малыми накладными
расходами процессора, памяти, времени обработки в конце концов.
41
Firebird необходим при массовой вставке записей, при работе с
индексами, файловое кэширование, коэф. сжатия записей, управление
памятью сортировок, но для документооборота это не используется.
Firebird применяется в основном для небольших и средних
встраиваемых приложений, то есть когда сервер ставится в комплекте
какого-то приложения (бухгалтерского или складско-учетного) и работает в
"невидимом" для пользователей режиме.
MS SQL
Достоинства:
-СУБД масштабируется, поэтому работать с ней можно на портативных
ПК или мощной мультипроцессорной технике. Процессор может
одновременно обрабатывать большой объем запросов
-СУБД поддерживает работу с другими продуктами Microsoft: Access,
MS Excel
Недостатки:
-Зависимость от операционной среды: СУБД работает только с
системой Windows.
-Высокая цена программы.
Сравнение СУБД
Таблица 1.3
Максималь
ный вес
таблицы
Максималь
ный
размер
страницы
Максималь
ный
размер БД
Язык
программиро
вания
Максимал
ьное
число
пользоват
елей БД
MySQ
L
524,272 ТБ
30,000
524,272 ТБ
(32627
файлов *
16ТБ
максимальн
ый размер
файла)
C++
1000
Firebi
rd
36.7 ГБ
16,386
7 ТБ
С++
300-500
MS
SQL
Serve
MyISAM=25
6ТБ,
InnoDB =64
4,096
Не огр.
Transact SQL
Не огр.
42
r
ТБ
Оптимальным вариантом является MySQL. Данная программа не
сильно нагружает систему. Данная СУБД широко распространена, поэтому
будет не сложно найти того, кто сможет ее обслуживать
На основании вышеприведенных доводов решено в качестве СУБД
MySQL.
1.4.3. Обоснование проектных решений по техническому
обеспечению
С учетом выбора оптимальной БД для обеспечения работы АИС
требуется определиться с серверной инфраструктурой – «фундаментом» от
которого будет зависеть отказоустойчивость, доступность и
работоспособность данной информационной системы.
В качестве серверной инфраструктуры выбрана конфигурация
имеющегося кластерного решения, включающего сервер Dell PowerEdge
R740 Server в количестве 3-х штук, коммутатора Huawei S6720-16X-LI-16S-
AC, необходимых модулей SFP+ для взаимодействия кластера средствами
ВОЛС, ИБП APC Smart-UPS 1500VA/980W, RM 2U.
Ниже приведена конфигурация сервера Dell PowerEdge таблица 1.4.
Таблица 1.4
Конфигурация сервера Dell PowerEdge
Комплектующи
е
Название комплектующих
Кол-
во
Корпус
Chassis with up to 16 x 2.5" SAS/SATA Hard
Drives for 2CPU Configuration
1
Процессор
Intel Xeon Gold 6254 3.1G, 18C/36T, 10.4GT/s,
24.75M Cache, Turbo, HT (200W) DDR4-2933
2
Объем
32GB RDIMM, 2933MT/s, Dual Rank
4
43
оперативной
памяти
Диски "Тип 1"
600GB 10K RPM SAS 12Gbps 512n 2.5in Hot-
plug Hard Drive
2
Диски "Тип 2"
900GB 15K RPM SAS 12Gbps 512n 2.5in Hot-
plug Hard Drive
4
Сетевой
контроллер
Broadcom 5720 Quad Port 1GbE BASE-T, rNDC
1
Сетевой
оптический
контроллер
Broadcom 57414 Dual Port 10/25GbE SFP28
Adapter, PCIe Full Height
1
Данное кластерное решение управляется системой виртуализации с
открытым исходным кодом Proxmox.
В качестве АИС для разрабатываемой программы необходимо
использовать персональные компьютеры со следующей минимальной
конфигурацией:
Частота процессора 2,8 ГЦ и выше
Оперативная память объемом 2048 или выше
·Жесткий диск 200,0 Gb или выше.
Привод DVD.
Монитор 17" или выше
ИБП APC Back-CS500VA, аналогичный или лучше.
Таким образом, подводя итог первой главы можно сказать, что в ООО
"Метро Кэш Энд Керри" линейная структура управления. На предприятии
для подключения всех ПК к сети СПД используется топология «Звезда».
В данной главе была разработана контекстная диаграмма. В данной
главе приведены нормативно-правовые и организационно-распорядительные
документы для информационной безопасности предприятия.
Рассмотрены существующие программы по указанной теме - и
приведены их недостатки.
44
Для разработки клиентской части программного обеспечения АИС
было решено использовать продукт Delphi 10.3. В качестве СУБД решено
использовать MySQL.
45
2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
На современном этапе наиболее распространенными моделями
жизненного цикла информационных систем (далее - ЖЦ ИС) являются
следующие [7]:
1. каскадная;
2. спиральная;
3. инкрементная.
Каскадная модель ЖЦ ИС или «модель водопада» (англ, waterfall
model), предложенная в 1970 году Уинстоном Ройсом, предполагает
последовательное выполнение всех этапов проекта в строго фиксированном
порядке. Переход к следующему этапу происходит только после полного
выполнения всех работ предыдущего этапа. Все требования и основные
положения фиксируются в техническом задании и являются неизменными на
протяжении всего времени разработки проекта. Завершение каждой стадии
сопровождается выпуском полного комплекта документации для того, чтобы
разработка информационной система могла быть продолжена на
последующих этапах [8]. В общем виде данная модель представлена на
рисунке 6.
Рисунок 6. Графическая интерпретация каскадной модели ЖЦ ИС
46
Спиральная модель, автором которой является Барри Боэмом, была
разработана в 1988 году. Она основана на классическом цикле Деминга
PDCA (plan-do-check-act). При использовании этой модели информационная
система создается в несколько итераций наподобие витков спирали [8]. На
каждом витке спирали осуществляется непосредственное создание очередной
части информационной системы, уточняются существующие или
формируются новые требования проекта, определяется качество проделанной
работы и формируется план работы на следующем витке спирали [7]. При
этом на каждой итерации оцениваются:
вероятность превышения сроков и бюджета проекта
необходимость выполнения еще одной итерации
степень полноты и точности понимания требований к системе
4. целесообразность прекращения проекта.
Графическая интерпретация модели представлена на рисунке 7.
Рисунок 7. Графическая интерпретация спиральной модели ЖЦ
НС
В инкрементной модели ЖЦ ИС (англ, increment - увеличение,
приращение) разработка информационной системы осуществляется с ли-
нейной последовательностью стадий, но в несколько инкрементов (версий),
т. е. с запланированным улучшением продукта.
В начале работы над проектом определяются все основные требования
к системе, после чего выполняется ее разработка в виде последовательности
версий. При этом каждая версия является законченным и работоспособным
продуктом. Первая версия реализует часть запланированных возможностей,
47
следующая версия реализует дополнительные возможности и т. д., пока не
будет получена полная система [8]. Графически данная модель показана на
рисунке 8.
Рисунок 8. Графическая интерпретация инкрементной модели ЖЦ
НС.
Сравнительная характеристика моделей, описанных выше, приведена в
таблице 2.1.
Таблица 2.1
Сравнение моделей ЖЦ ИС
Рассмотрев модели жизненного цикла, для разрабатываемой АИС
выберем спиральную модель. Это можно объяснить тем, что специалисты,
занятые эксплуатацией АИС, постоянно будут разрабатывать новую версию
своей сети, проходя в такой работе на каждом витке спирали стандартные
этапы и не дожидаясь, когда эффективность системы опустится ниже
заданного порога или система не сможет удовлетворять постоянно растущим