Содержание к диссертации
Введение
Глава 1. Жизненный цикл промышленных комплексов моделирования 12
1.1. Смена парадигм разработки ПО по мере развития аппаратного и программного обеспечения ЭВМ 13
1.2. Облачный подход как развитие клиент-серверной архитектуры 19
1.3. Автоматизированная система диспетчерского управления ЕСГ 22
1.4. Обзор некоторых эксплуатируемых ПВК в АСДУ 23
1.5. Общие направления развития ПВК в АСДУ 30
1.6. Регламентирующие документы по разработке ПВК в АСДУ 32
1.7. Выводы по главе 1 35
Глава 2. Моделирование работы РКС и оценка параметров её функционирования 37
2.1. Моделирование компонентов РКС и их взаимодействия 37
2.1.1. Раскрашенные сети Петри 38
2.1.2. Моделирование РСП в CPN Tools 40
2.1.3. Модель взаимодействия толстых клиентов на примере сетевого тренажёра ПВК «Веста» 41
2.1.4. Модель работы сетевого менеджера в гетерогенной среде 43
2.2. Оценка параметров функционирования РКС 46
2.2.1. Модели расчётного комплекса и системных компонентов 49
2.2.2. Модель тонкого клиента 51
2.2.3. Взаимосвязь компонентов РКС 52
2.2.4. Показатели эффективности работы РКС 53
2.3. Выводы по главе 2 55
Глава 3. Выбор технологий разработки компонентов РКС 57
3.1. Разработка менеджера схем 57
3.2. Разработка серверных компонентов web-приложения
3.2.1. Критерии выбора платформы разработки серверных компонентов 58
3.2.2. Платформы разработки серверных компонентов 59
3.2.3. Сводные результаты по сравнению платформ разработки серверных приложений 64
3.3. Разработка клиентских приложений 66
3.3.1. Критерии выбора платформы разработки клиентских приложений 66
3.3.2. Платформы разработки клиентских приложений и работы с web-графикой 67
3.3.3. Сводные результаты по сравнению платформ разработки клиентских приложений 76
3.4. Инструменты разработки динамических web-интерфейсов 77
3.4.1. Критерии выбора JavaScript-инструмента 79
3.4.2. Краткий анализ основных инструментов работы с JavaScript 79
3.4.3. Сводные результаты по анализу инструментов работы с JavaScript 81
3.4.4. Работа с web-графикой в HTML5 82
3.4.5. Механизм асинхронной передачи данных AJAX 83
3.5. Выводы по главе 3 85
Глава 4. Программная реализация РКС для АСДУ 86
4.1. Общая архитектура РКС 86
4.2. Менеджер схем 87
4.3. Тонкие клиенты 89
4.4. Web-приложение
4.4.1. Основные классы и методы 94
4.4.2. Настройка web-приложения 96
4.5. Оценка сопровождаемости разработанной РКС 101
4.6. Рекомендации по интеграции ПВК в РКС 103
4.6.1. Модификация ПВК 103
4.6.2. Написание шаблонов преобразования данных 105
4.6.3. Развёртывание системы 107
4.6.1. Обеспечение конфиденциальности передаваемых данных 108
4.7. Пример разработки тонкого клиента для диспетчера ЛПУ МГ 109
4.8. Выводы по главе 4 112
Заключение 113
Список используемых сокращений 115
Общие термины и определения 117
Список литературы
- Автоматизированная система диспетчерского управления ЕСГ
- Модель взаимодействия толстых клиентов на примере сетевого тренажёра ПВК «Веста»
- Критерии выбора платформы разработки клиентских приложений
- Оценка сопровождаемости разработанной РКС
Введение к работе
Актуальность темы исследования. В последнее десятилетие разработка программного обеспечения (ПО) перешла от разработки стационарных программ к разработке ПО как услуг (Software as a Service, SaaS) на основе облачных технологий. Данный переход является результатом совокупности факторов:
-
Появление и широкое распространение многоядерных процессоров привело к противоречию существующей массовой парадигмы программирования — создание последовательных программ – с многоядерностью и многопроцессорностью.
-
Увеличение разрыва в производительности клиентских и серверных электронно-вычислительных машин (ЭВМ). Создание высокопроизводительных центров обработки данных (ЦОД) позволяет не только снизить требования к клиентским устройствам, но и решать задачи, превосходящие ресурсоемкостью возможности отдельных рабочих станций.
-
Ускорение цикла разработки ПО до практически непрерывного: разработчики стараются по возможности поддерживать контакт с пользователями для улучшения своего продукта. Идёт взаимовыгодное сотрудничество: пользователи оперативно получают обновления, а разработчики – отчёты об ошибках и пожелания. Однако это ведёт к проблеме быстрого и прозрачного для пользователей получения обновлений.
-
Развитие мобильных устройств и сетей передачи данных, методов и средств защиты информации даёт возможность организации удалённого доступа к информации практически в любой момент.
-
Расширение списка клиентских устройств за счет мобильных телефонов и планшетных компьютеров, имеющих отличные от персональных компьютеров характеристики и программно-аппаратную платформу, усугубило проблему переносимости ПО с одной платформы на другую.
В РФ актуальности проблеме кроссплатформенности добавляет курс на импортозамещение, вводящий ограничения на закупки товаров, работ и услуг иностранного происхождения, в том числе ПО и операционных систем (ОС).
Решением указанных проблем является концепция открытых стандартов и спецификаций для разработчиков ПО и развертывание ПО в высокопроизводительных ЦОД (облаках) с предоставлением доступа к его функциональности через тонкие клиенты.
В то же время в крупных компаниях эксплуатируется ряд специализированных программных продуктов, использование которых критично для выполнения бизнес-задач. К такому ПО относятся программно-вычислительные комплексы (ПВК) моделирования, каждый из которых является уникальным для соответствующей отрасли. Поскольку разработка ПВК «с нуля» – ресурсоёмкий процесс, неизбежно сопровождающийся появлением новых ошибок, необходимо решать проблему модернизации существующих комплексов, что также является нетривиальной задачей. Переход на новую концепцию осложняется как необходимостью сохранения сколь угодно сложной бизнес-логики ПВК, так и размерами организации, включая территориально распределённые филиалы и дочерние компании. Возможным решением проблемы является изменение способа организации взаимодействия с ПВК путём создания распределённой компьютерной среды (РКС), обеспечивающей удалённый доступ к вычислительным ресурсам через кроссплатформенных тонких web-клиентов. В таком случае необходимо обеспечить согласованную работу как существующих программ – толстых клиентов, так и внедряемых тонких.
В диссертации рассматривается задача создания гетерогенной РКС, обеспечивающей возможность организации удалённого доступа к существующему прикладному ПО через кроссплатформенные тонкие клиенты. Данная задача решается на примере ПВК моделирования задач газотранспортной отрасли. Выбор данной отрасли определен следующими факторами:
-
Единая система газоснабжения (ЕСГ) России принадлежит одной компании: ПАО «Газпром», следовательно, все рассматриваемые в работе ПВК подчиняются единым стандартам и требованиям. При этом в рамках одной системы функционируют программные средства разных разработчиков, решающие схожие задачи, но имеющие собственные форматы данных. Распределённость, гетерогенность и иерархия ЕСГ обуславливают необходимость соответствующей системы управления, однако результаты расчёта одного ПВК возможно использовать в другом только после ручного переноса данных.
-
Проблема кроссплатформенности: по историческим причинам большинство эксплуатируемых ПВК корпоративного сектора работают только под управлением ОС Windows от Microsoft. Таким образом, замена ОС Windows на рабочих станциях пользователей приведёт к неработоспособности ПВК. Кроме того, на данный момент не поддерживаются мобильные клиентские устройства.
-
Проблема поддержки ПВК в актуальном состоянии: непрерывный цикл разработки и постоянное внесение изменений в ПВК требует регулярного обновления всех установленных в организации комплексов, при этом механизмы автоматического обновления развиты недостаточно.
-
Перегруженность графического интерфейса пользователей: постоянное наращивание функциональности приводит к избыточности элементов управления, в то время как отдельным категориям пользователей требуется доступ только к определенному набору задач.
С учётом изложенного, проблема разработки РКС, обеспечивающей удалённый доступ к специализированным прикладным ПВК с помощью кроссплатформенных клиентов, является актуальной для обеспечения функционирования и сопровождения ПО корпоративного сектора в целом, и газотранспортной отрасли, в частности.
Степень разработанности темы исследования. В ходе работы был
изучен и проанализирован вклад отечественных и зарубежных учёных в
областях науки, связанных с темой диссертационного исследования: Бермана Р.Я., Васильева А.В., Вентцель Е.С., Воеводы А.А., Григорьева Л.И., Коротикова С.В., Котова В.Е., Леонова Д.Г., Митичкина С.К., Овчарова Л.А., Панкратова В.С., Питерсона Дж., Сарданашвили С.А., Селезнева В.Е., Ставровского Е.Р., Стёпина Ю.П., Сухарева М.Г., Трахтенгерца Э.А., Шалыто А.А., Швечкова В.А. и др.
Целью диссертационной работы является исследование моделей, методов и программных средств организации и анализа взаимодействия специализированных вычислительных комплексов для создания гетерогенной РКС, обеспечивающей удалённый доступ к промышленным программным комплексам моделирования через кроссплатформенных тонких клиентов, а также программная реализация компонентов РКС для ПВК газотранспортной отрасли.
Для достижения цели были поставлены следующие задачи:
-
Построение модели функционирования РКС для определения компонентного состава и протоколов взаимодействия.
-
Построение модели функционирования РКС для анализа и оценки параметров эффективности её работы.
-
Разработка архитектурных решений и программная реализация компонентов гетерогенной РКС для газотранспортной отрасли, с учётом современных принципов и технологий проектирования и программирования распределённых систем, а также текущего состояния и направлений развития автоматизированной системы диспетчерского управления (АСДУ).
-
Разработка инструментария для создания тонких web-клиентов с произвольным набором функциональности, предусматривающую возможность расширения до разработки мобильных приложений.
-
Разработка рекомендаций по интеграции ПВК в РКС, доработка соответствующего инструментария, а также интеграция одного из используемых в АСДУ ПВК, ПВК "Веста", и проверка работоспособности
разработанной РКС на примере реализации профессионального калькулятора диспетчера.
Методы исследования
При решении поставленных задач были использованы принципы системного
анализа, объектно-ориентированного проектирования и программирования,
построения распределённых систем, а также модели и методы теории сетей
Петри, теории принятия решений, теории марковских цепей и динамики средних.
Научная новизна результатов работы заключается в следующем:
построены модели, позволяющие определить набор компонентов РКС и протоколы их взаимодействия между собой;
предложены модели функционирования РКС для анализа и оценки эффективности работы отдельных компонентов и РКС в целом;
разработаны архитектурные решения РКС, обеспечивающей удалённое подключение к специализированным программным комплексам тонких кроссплатформенных клиентов с заданным набором функциональности.
Положения, выносимые на защиту:
модель РКС для определения её компонентного состава и протоколов взаимодействия;
математическая модель для анализа и оценки параметров работы РКС;
архитектурные решения и технологии разработки компонентов РКС и инструментария для создания тонких клиентов.
Практическая ценность работы заключается в построении гетерогенной РКС, обеспечивающей удалённое подключение к специализированному ПО тонких клиентов и доступ к данным и расчётным задачам в доверенной сети, а также позволяющую разрабатывать кроссплатформенные тонкие клиенты с заданным набором функциональности и способом визуализации данных под нужды конкретной организации.
Тонкие клиенты могут использоваться как самостоятельное ПО, а также встраиваться в специализированное ПО сторонних разработчиков.
Для АСДУ разработанная РКС является одним из ключевых компонентов инфраструктуры, обеспечивающей переход на распределённую обработку данных и создание открытой интеграционной платформы (ОИП) для ПВК различных разработчиков. Переход к распределённой структуре даёт принципиальную возможность моделирования задач, по ресурсоемкости превосходящих возможности отдельных рабочих станций.
Разработанный в качестве примера профессиональный калькулятор диспетчера предоставляет доступ к набору расчётных задач ПВК «Веста» с любого устройства, в том числе мобильного, находящегося в доверенной сети. Таким образом, значительно снижаются требования к клиентским устройствам и отсутствует необходимость покупки и установки специализированного ПО на каждом рабочем месте.
Апробация работы
Основные результаты работы обсуждались на следующих конференциях: 66-я международная молодежная научная конференция «Нефть и газ — 2012» (г. Москва), «Компьютерные технологии поддержки принятия решений в диспетчерском управлении газотранспортными и газодобывающими системами DISCOM-2012» (г. Москва), «Новые технологии в газовой промышленности (газ, нефть, энергетика)» (г. Москва, 2013), «Компьютерные технологии поддержки принятия решений в диспетчерском управлении газотранспортными и газодобывающими системами DISCOM-2014» (г. Москва), «Новые технологии в газовой промышленности (газ, нефть, энергетика)» (г. Москва, 2015), XI Всероссийская научно-техническая конференция «Актуальные проблемы развития НГК России», 2016 (г. Москва).
Публикации
Основное содержание работы отражено в 11 печатных работах, из них 5 —
в журналах перечня ВАК [1-5], из них 4 — в журналах группы специальностей
05.13.00 «Информатика, вычислительная техника и управление» [1-3, 5].
Структура и объем работы
Автоматизированная система диспетчерского управления ЕСГ
Несмотря на широкое распространение облачных систем в различных сферах жизни, до сих пор отсутствует стандарт, определяющий понятие «облако». Наиболее распространённое определение облачным технологиям было сформулировано в 2011 г. в рекомендациях Национального института стандартов и технологий США [52]. Согласно данным рекомендациям [62], облако должно удовлетворять следующим критериям: самообслуживание по требованию (self-service on demand); доступ по сети для любых тонких и толстых клиентов; объединение ресурсов (англ. resource pooling); эластичность, или масштабируемость; учёт объёма предоставленных услуг. Таким образом, облако даёт возможность потребителю самостоятельно получать доступ с практически любого клиентского устройства в тот момент времени и к тому набору услуг, когда ему это необходимо, без необходимости взаимодействия с поставщиком услуг.
В свою очередь поставщики услуг объединяют ресурсы в единый пул, с возможностью динамического перераспределения ресурсов в зависимости от количества клиентов. Объём предоставляемых услуг конкретному клиенту контролируется, как правило, автоматически и может быть изменен по требованию клиента. При этом поставщиком ведется учёт объёмов предоставленных услуг.
С технической точки зрения, главная идея облачного подхода – отделение хранения и обработки данных от их визуализации (Рисунок 2). Он исходит из двух предпосылок: во-первых, компьютеры отдельных пользователей территориально распределены; во-вторых, есть возможность использования вычислительных ресурсов ЦОД.
Применительно к корпоративному сектору подразумевается, что в облаке находятся специализированное ПО и данные (для АСДУ, в частности, это может быть репозиторий расчётных схем, учебно-тренировочные задачи (УТЗ), отчеты о выполнении УТЗ и прочие данные), доступ к которым предоставляет тонкий клиент через единую точку входа удалённых пользователей, скрывая распределённую вычислительную часть. Расчёт моделей, решение задач оптимизации, адаптации и других ресурсоемких операций в облаке повышают эффективность использования имеющихся ресурсов. При этом расширяется спектр поддерживаемых клиентских устройств от стационарных рабочих станций до планшетных компьютеров и смартфонов, так как конечным пользователям поступает обработанная и агрегированная информация, которую нужно только отобразить. Уровень детализации получаемой информации зависит от возможностей устройства и потребностей пользователя и может варьироваться от отображения полной технологической схемы на стационарных и планшетных компьютерах до табличной сводки основных параметров режима на мобильном телефоне.
Наличие в организациях уже разработанных и проверенных ПВК делает нецелесообразным построение вычислительной среды «с нуля». Отсюда возникает проблема построения РКС как части облачной архитектуры на базе существующих стационарных ПВК.
Построение распределённой среды на базе существующих стационарных ПВК в общем случае требует решения нескольких проблем: преодоление различий программно-аппаратных архитектур: многие эксплуатируемые ПВК разработаны на базе 32-битной архитектуры (Win32), включая однопроцессорную, накладывающую определенные ограничения на потребляемые ресурсы, в то время как высокопроизводительные системы работают под управлением многопроцессорных 64-битных версий; организация сетевого взаимодействия со стационарным комплексом; минимизация влияния блокирующих ресурсоемких операций и обеспечение актуализации данных пользователей; обеспечение конфиденциальности данных при передаче по сети. Решение этих задач актуально для многих отраслей промышленности, в частности, для газотранспортной отрасли, управление которой осуществляется сложной иерархической автоматизированной системой диспетчерского управления.
ЕСГ РФ – крупнейшая в мире газотранспортная сеть, принадлежащая ПАО «Газпром». В ее состав входят технологические объекты добычи, транспорта, хранения и распределения газа и средства управления ими: системы автоматики, телемеханики, АСДУ.
В соответствии с распределённым и иерархическим характером ЕСГ диспетчерское управление (ДУ) делится на четыре уровня [5]: 1. Департамент 310 (ЦПДД) ПАО «Газпром» – высший орган диспетчерского управления ЕСГ РФ. 2. ПДС ЭО ПАО «Газпром», центрально-производственная диспетчерская служба (ЦПДС) ООО «Газпром ПХГ», ЦПДС ООО «Газпром Переработка» (ПДС ЭО), оперативно-диспетчерская служба (ОДС) ООО «Межрегионгаз» и ОДС региональных компаний по реализации газа (ОДС ООО «Межрегионгаз»), диспетчерские центры независимых организаций. 3. Диспетчерские службы Филиалов эксплуатирующих организаций (ЭО). 4. Персонал Филиалов ЭО, осуществляющий непосредственное управление режимом транспорта газа. На каждом уровне применяются специализированные прикладные программные средства АСДУ (п. 10.3.1) [6]. Важной частью АСДУ являются программно-вычислительные комплексы, решающие такие задачи, как (п. 8.1.4): структурированное хранение данных; направленный поиск и представление в произвольной форме информации для анализа текущих и ретроспективных режимно-энергетических показателей работы ЕСГ; решение режимно-технологических задач адаптивного моделирования, оптимального планирования и прогнозирования режимов работы объектов и подсистем ЕСГ. В дополнение к ним используются программные тренажёрные комплексы для обучения и повышения квалификации персонала.
В основе АСДУ лежат исследования в областях системного анализа, автоматического и автоматизированного управления, теории принятия решений, оптимального управления сложными системами, современных информационных технологий (п. 5.4). Теоретические основы были разработаны несколько десятилетий назад, когда началось создание и внедрение первых специализированных систем. Часть внедрённых ПВК эксплуатируется и в настоящее время, развиваясь и совершенствуясь. Несколько десятилетий происходит регулярное расширение возможностей ПВК, решаются новые задачи: большей размерности, с большей точностью, при этом практически не уделяется внимание вопросам проектирования ПВК: в них заложены принципы, актуальные на момент начала разработки и не отражающие в полной мере текущее состояние информационных технологий. В некоторых случаях архитектурные решения накладывают ограничения на расширение функциональности и эффективность использования ПВК.
Модель взаимодействия толстых клиентов на примере сетевого тренажёра ПВК «Веста»
Специфика нестационарного режима заключается в том, что расчёт осуществляется с заданным шагом моделирования вне зависимости от действий обучающихся, в то время как в стационарном режиме расчёт происходит в ответ на действия пользователя. Поскольку на начальном этапе проектирования РКС важно выделить набор необходимых компонентов системы и протоколы взаимодействия между ними, а не воспроизвести полностью функциональность, модель строилась исходя из логики работы в стационарном режиме.
Главным отличием РКС от тренажёра является переменное количество не только клиентов, но и ПВК, поэтому необходимо решать задачу запуска ПВК по требованию клиента. Это, в свою очередь, приводит к необходимости добавления в систему нового компонента: менеджера схем, обеспечивающего по запросу клиентов запуск расчётных модулей с заданной расчётной схемой.
Первичное моделирование показало, что для корректной маршрутизации потоков сообщений от разнородных компонентов необходимо введение понятия «Тип клиента» (Рисунок 14):
Регистрация клиентов, общий случай Клиент должен хранить идентификатор соответствующего ПВК: colset ClientInfo = record selfId:INT pairId:INT t:ClType; Для маршрутизации потоков сообщений в сетевом менеджере необходимо предусмотреть отдельные очереди для каждого типа клиентов: colset MSG = record to:INT from:INT t:ClType data:STRING; В целом работа каждой новой пары «клиент-расчётный модуль» разбивается на несколько шагов (Рисунок 15):
Рисунок 16 - РСП взаимодействия разнородных клиентов и расчётных модулей Данная схема справедлива для работы толстых клиентов. В случае тонких клиентов требуется ещё один промежуточный модуль для преобразования данных в нужный формат. Фактически необходим web-сервер, который бы обслуживал удалённых тонких web-клиентов. Тогда процесс функционирования всех компонентов РКС упрощенно можно представить раскрашенной сетью Петри на рисунке 17.
Модель на основе сети Петри отражает структуру РКС, но не учитывает поведение системы во времени, в том числе возможные отказы, как программные, так и аппаратные. С этой точки зрения, функционирование ПВК и компонентов РКС может быть описано с помощью марковских случайных процессов с дискретными состояниями и непрерывным временем [2, 40], поскольку элементы системы переходят из состояния в состояние независимо друг от друга, как ввиду частоты и характера запросов на вычисления, так и ввиду технического состояния элементов ПО. При работе со стационарным ПВК система в целом может иметь три состояния: система работает, система не работает (вследствие программных или аппаратных ошибок) или находится в состоянии перезапуска (Рисунок 18).
Невозможность перезапуска ПВК происходит в случае аппаратной ошибки, то есть отказа оборудования (21). Наиболее распространёнными отказами являются отказы жёсткого диска и перебои с электроснабжением.
Как правило, статистику по отказам аппаратного обеспечения собирают поставщики оборудования и компании, предоставляющие услуги на основе облачных технологий, являющиеся крупными потребителями. Например, компания Backblaze, предоставляющая услуги по резервному копированию пользовательских данных, проводит различные исследования по надёжности жёстких дисков на основе статистики, собранной с около 50 тысяч жёстких дисков [86]. Согласно их исследованиям, после 3 лет работы количество отказов резко возрастает – с 1,4% в период 1,5-3 года до 11,8% после 3 лет (Рисунок 19).
При использовании сертифицированных ЦОД возможно значительно снизить количество отказов аппаратного обеспечения ( 0.1%) по сравнению с использованием персональных рабочих станций за счёт резервирования [42].
Однако переход на облачную архитектуру и использование ЦОД требует добавление новых системных компонентов, поэтому необходимо учитывать их влияние на работу системы в целом и целесообразно рассматривать несколько взаимосвязанных случайных процессов (Рисунок 20).
Критерии выбора платформы разработки клиентских приложений
К недостаткам ASP.NET MVC можно отнести небольшое количество сторонних библиотек компонентов, однако этот недостаток скорее всего носит временный характер. Также разработчику необходимо владеть сразу набором технологий, используемых в разных частях приложения, либо одно приложение должна разрабатывать группа программистов с различными специализациями. ASP.NET MVC 6 В выпущенной в 2015 г. ASP.NET 5 все технологии разработки web-приложений объединены в одну платформу, получившую название ASP.NET MVC 6.
В новой версии среда выполнения проектов – Core CLR – оптимизирована для работы в облаке (cloud-optimized runtime). Core CLR является полностью модульной и даёт возможность подключать только необходимые функции библиотеки. Использование Core CLR позволяет собрать в единый пакет развёртывания приложение со всеми зависимостями, то есть появляется возможность запускать MVC-приложения вне IIS, следовательно, приложения могут работать не только под управлением ОС Windows, но и OSX и Linux. Также добавлена поддержка AngularJS для создания одностраничных клиентских web-приложений, который в дальнейшем будет рассмотрен подробнее. HTML5 + CSS3 + JavaScript Динамичность и интерактивность ГИП в ASP.NET MVC реализовывается тройкой языков HTML5 + CSS3 + JavaScript, являющихся на настоящий момент основным механизмом разработки современных web-ресурсов.
Специфика мобильных устройств и их распространение привели к пересмотру языка структурирования интернет-страниц HTML (HyperText Markup Language). Пятая версия языка разработана совместными усилиями WHATWG (Web Hypertext Application Technology Working Group) и W3C (World Wide Web Consortium) и ориентирована на упрощение разработки кроссплатформенных интернет-проектов. В ней существенно расширена работа с мультимедиа, с базами данных, с геолокационными данными и добавлены другие новые механизмы. HTML5 официально был рекомендован в октябре 2014 г. [56], однако его поддержка в браузерах началась ещё до завершения процедуры сертификации – с 2013 г. HTML5 фактически является рабочим стандартом. Технология активно развивается, ещё до официального выхода пятой версии была начата работа над версией 5.1.
Внешний вид html-объектов определяется CSS (Cascading Style Sheets, каскадные таблицы стилей). В css-файле возможно задание размеров, цвета, параметров шрифта и другие свойства. В третьем поколении CSS добавилась работа с градиентами, тенями, а также возможность описания не только статичных свойств объекта, но и создание анимации без использования JavaScript.
JavaScript – язык сценариев, выполняемых браузером, обеспечивающий динамичность и интерактивность web-страниц. Для JavaScript реализовано достаточное количество библиотек, как элементов управления, так и реализующие различную функциональность. На основе JavaScript разработан популярный формат передачи объектов JSON (JavaScript Object Notation), который на самом деле не зависит от JavaScript и может быть использован с другими языками программирования.
Недостатком JavaScript являются потенциальные угрозы внедрения в сценарии вредоносного кода, поэтому некоторыми пользователями он блокируется.
Из недостатков HTML5 и CSS3 можно отметить несовместимость со старыми версиями браузеров.
Так как все составляющие страницы имеют текстовый формат, то результат дает высокую скорость загрузки и небольшой объём трафика в сети. Это может быть актуально при использовании мобильных сетей передачи данных. Поскольку каждый из языков поддерживается всеми современными браузерами, в том числе, для мобильных устройств, связка HTML5 + CSS3 + JavaScript позволяют быстро построить платформонезависимое приложение. Недостатком данного подхода является невозможность использования специфических характеристик мобильных устройств и меньшая производительность, по сравнению с мобильными приложениями. Гибридные мобильные приложения Говоря о приложениях для мобильных устройств, можно выделить три их типа: нативные (native), web-приложения и гибридные.
Нативные приложения являются лучшим решением с позиций производительности и использования возможностей устройства. Недостатком является необходимость разработки отдельных приложений для каждой платформы отдельно: на Objective C/Swift для устройств Apple, на Java для устройств на ОС Android, на C# для Windows Phone.
Web-приложения, рассмотренные выше, работают в браузере. Их не нужно предварительно устанавливать на устройство, следовательно, они не занимают постоянную память устройства, позволяют использовать один код на всех типах устройств. Однако для их работы необходимо постоянное подключение к сети передачи данных и невозможно в полной мере использовать функции устройства. Данный вариант хорошо подходит на начальном этапе разработки или при невозможности установки приложений, например, из-за ограничений политики безопасности организации.
В результате появилась концепция гибридных мобильных приложений, сочетающая преимущества нативных и web-приложений и частично устраняющая их недостатки. Основная идея гибридных приложений: использование единого кода, описывающего логику приложения, с дополнением кода, учитывающим характеристики конкретного устройства при построении интерфейса.
Оценка сопровождаемости разработанной РКС
Особенностью разрабатываемой среды является предоставление доступа к функциональности ПВК через посредников – вычислительные центры отдельных организаций. Следовательно, помимо конечных пользователей – диспетчерский персонал, пользователями ПВК являются так же и организации газотранспортной отрасли. Для обеспечения поддержки в автоматизированном режиме, раздачи обновлений, актуальных для конкретной организации и категории пользователей, необходима идентификация пользователей.
Для идентификации необходимо пройти процедуру активации, в процессе которой осуществляется привязка серийного номера пользователя (сотрудника организации, ответственного лица) к идентификатору рабочей станции (сервера). С каждым серийным номером связано возможное количество активаций, флаг возможности активации без подтверждения со стороны разработчика, счетчик проведенных активаций и идентификаторы двух типов: идентификатор организации; идентификатор рабочей станции. Идентификатор организации определяет газотранспортное предприятие, в котором используется комплекс, что позволяет задать набор специфических обновлений, таких как технологические схемы и учебно-тренировочные задачи. Каждой организации выделяется блок серийных номеров, идентификатор организации входит составной частью в каждый серийный номер.
Идентификатор рабочей станции привязывается к серийному номеру в момент завершения процедуры активации продукта. Активированный идентификатор рабочей станции используется в дальнейшем при автоматических обращениях к системе поддержки пользователей. Эта процедура также препятствует несанкционированному распространению и использованию ПО, поскольку даже в случае успешного несанкционированного копирования ПО и локального обхода механизмов защиты доступ к системе поддержки становится невозможным.
Активация продукта требуется только один раз, при первой установке. При наличии подключения к интернету передача данных на сервер осуществляется автоматически и прозрачно для пользователя, которому необходимо лишь ввести серийный номер продукта и имя ответственного лица. В противном случае для активации необходимо получение кода активации любым доступным способом – запросом по почте, телефону или заполнив web-форму (Рисунок 32).
На основании информации о компьютере с помощью одностороннего хеширования формируется идентификатор рабочей станции, который вместе с серийным номером отправляется сервер (Рисунок 33).
На сервере производится анализ запроса, проверяется уникальность идентификатора машины K и количество доступных активаций для данного серийного номера. Если данные удовлетворяют условиям, то с помощью генератора G вычисляется код активации A, который возвращается клиенту. Одновременно в базе данных создается запись о новой активации и происходит корректировка количества доступных активаций. После успешного получения кода активации приложение переходит к запуску в штатном режиме.
Одной из основных характеристик облачных технологий является гибкость в распределении доступа к предоставляемым услугам (задачам). Доступ к задачам для различных организаций (или для различных пользователей, если рассматривать процедуру в рамках одной организации) регламентируется матрицей полномочий М (таблицей полномочий). В матрице полномочий строками являются идентификаторы пользователей, а столбцами – идентификаторы задач. Элементы матрицы содержат описания полномочий для конкретного пользователя к конкретному ресурсу: элемент матрицы принимает значение 0, если доступ запрещён, и 1 – в противном случае (Таблица 11). Распределение полномочий осуществляется администратором.
Оценка качества ПО регламентируется ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» [4].
Одной из важных внутренних характеристик ПО является сопровождаемость - набор атрибутов, относящихся к объёму работ, требуемых для проведения конкретных изменений.
Для количественной оценки сопровождаемости используется комплексный показатель - индекс сопровождаемости, вычисляемой по эмпирической зависимости следующий образом [80]: Ml = 111 - 5.2 ln(HK) - 0.23СС - 16.21n(LoC) + 50sinV2.46COM, где HV - метрика Холстеда (Halstead s Volume), характеризующая количество операторов в программе; СС - структурная сложность кода (Cyclomatic Complexity), соответствующая количеству ветвей в коде; LoC - количество строк кода (Lines of Code); СОМ- процент комментариев. Другими количественными оценками являются глубина наследования (depth of inheritance) для каждого класса и зависимость классов между собой (class coupling). Правильное проектирование программного обеспечения предполагает небольшое количество связанных классов. Чем их больше, тем сложнее в дальнейшем поддерживать и повторно использовать класс из-за большого количества зависимостей.
Интегрированная среда разработки MS Visual Studio содержит встроенные средства вычисления данных оценок. Индекс сопровождаемости рассчитывается как метрика относительной сложности поддержки кода на основе приведённой выше формулы, но без слагаемого, учитывающего количество комментариев, и может принимать значения от 0 до 100: