Микросервисы

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное автономное образовательное учреждение высшего образования «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ» ДОПУСТИТЬ К ЗАЩИТЕ Заведующий кафедрой № 43 Зав. кафедрой, к.т.н., проф М. Ю. Охтилев должность, уч. степень, звание подпись, дата инициалы, фамилия МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ на тему Генерация архитектурных шаблонов на основе спецификации требований выполнена Львовой Ириной Валерьевной фамилия, имя, отчество студента в творительном падеже по направлению подготовки 09.04.04 Программная инженерия код наименование направления наименование направления направленности 01 код наименование направленности Разработка программно-информационных систем наименование направленности Студентка группы № И.В. Львова 4630М подпись, дата инициалы, фамилия Руководитель проф. каф. 43, д.т.н., проф. должность, уч. степень, звание Ю. А. Скобцов подпись, дата инициалы, фамилия Санкт-Петербург 2018 1 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное автономное образовательное учреждение высшего образования «САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ АЭРОКОСМИЧЕСКОГО ПРИБОРОСТРОЕНИЯ» УТВЕРЖДАЮ Заведующий кафедрой № 43 Зав. кафедрой, к.т.н., проф. М. Ю. Охтилев должность, уч. степень, звание подпись, дата инициалы, фамилия ЗАДАНИЕ НА ВЫПОЛНЕНИЕ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ студентке группы № 4630М Львовой Ирине Валерьевне (фамилия, имя, отчество) на тему Генерация архитектурных шаблонов на основе спецификации требований утвержденную приказом ГУАП от Цель исследования: № 07-277/18 03.04.2018 Автоматическая генерация архитектурных шаблонов на основе требований к производительности и надежности Задачи исследования: изучить основные нефункциональные требования к программным средствам и технологии их реализации, проанализировать и выбрать алгоритмы анализа спецификации требований, принятия решений и автоматической генерации текстов программ Содержание диссертации (основные разделы): Изучение предметной области, описание используемых алгоритмов и технологий, подсистема генерации шаблонов программ заданной архитектуры Срок сдачи диссертации « 22 » мая 2018 Руководитель проф. каф. 43, к.т.н., проф. должность, уч. степень, звание Ю. А. Скобцов подпись, дата инициалы, фамилия Задание приняла к исполнению студентка группы № 4630М И. В. Львова подпись, дата инициалы, фамилия 2 РЕФЕРАТ Выпускная квалификационная работа 158 с., 45 рис., 6 табл., 44 источников, 4 прил. Ключевые слова: Экспертная система, программная архитектура, автоматический подбор архитектур, генерация шаблонов, анализ требований, деревья решений, автоматическая генерация кода, порождающее программирование, семантический анализ, виды СУБД, безопасность, отказоустойчивость. Цель работы: автоматическая генерация архитектурных шаблонов на основе требований к производительности и надежности. Объектом исследования и разработки является экспертная система автоматической генерации архитектурных шаблонов на основе спецификации требований. В процессе работы использовались программные средства: − Sybase PowerDesigner 16; − Microsoft Visual Studio 2015; − Microsoft Visio 2016. Полученные результаты и их новизна: В результате исследований разработана экспертная система автоматической генерации архитектурных шаблонов со следующими основными функциональными возможностями: − подбор архитектуры проекта по спецификации требований; − генерации шаблона проекта в соответствии с выбранной архитектурой. Область применения: разработка программных средств, программная инженерия. Экономическая эффективность/значимость работы: экспертная система автоматической генерации архитектурных шаблонов, благодаря возможности автоматического подбора архитектур и технологий для разрабатываемых систем, 3 позволяет снизить вероятность ошибок выбора каркаса программы, что позволяет модернизировать системы без полного переписывания программ. В будущем планируется: − расширить набор рассматриваемых технологий; − добавить программные шаблоны для различных языков программирования; − расширить базу программных шаблонов; − добавить семантические деревья для более детальной генерации программных шаблонов; − сделать приложение мультиязычным. 4 ABSTRACT Graduation work 158 pp., 45 images, 6 tables, 44 sources, 4 applications. Keywords: Expert system, software architecture, automatic architecture selection, template generation, requirements analysis, decision trees, automatic code generation, generating programming, semantic analysis, DBMS types, security, fault tolerance. The aim of this study is expert system of automatic generation of architectural templates based on specification requirements. The object of this study is the industrial control system for projects. Software was used during the work: − Sybase PowerDesigner 16; − Microsoft Visual Studio 2015; − Microsoft Visio 2016. The results and their novelty: As a result of the research, an expert system of automatic generation of architectural templates with the following basic functionalities was developed: − selection of the project architecture for specification of requirements; − generating a project template according to the chosen architecture. Use area: software development, software engineering. Cost-effectiveness/importance of work: expert system of automatic generation of architectural templates, due to the possibility of automatic selection of architectures and technologies for the developed systems, allows reducing the probability of errors in the selection of the program framework, which allows upgrading the systems without completely rewriting the programs. Plans include: − expand the range of technologies under consideration; − add program templates for different programming languages; − expand the base of program templates; − add semantic trees for more detailed generation of program templates; 5 − make the application multilingual. 6 СОДЕРЖАНИЕ ОПРЕДЕЛЕНИЯ...................................................................................................... 10 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ .................................................................... 11 ВВЕДЕНИЕ.............................................................................................................. 12 1 ИЗУЧЕНИИ ПРЕДМЕТНОЙ ОБЛАСТИ ....................................................... 17 1.1 Архитектура программных систем ................................................................. 17 1.2 Система управления базами данных ............................................................... 20 1.3 Требования к безопасности .............................................................................. 25 1.3.1 Требования к аутентификации и авторизации ............................................ 25 1.3.2 Требования к безопасности передачи данных ............................................ 28 1.4 Отказоустойчивость .......................................................................................... 30 1.4.1 Отказоустойчивая архитектура..................................................................... 30 1.5 Система передачи сообщений.......................................................................... 34 Выводы по разделу 1............................................................................................... 37 2 ОПИСАНИЕ ИСПОЛЬЗУЕМЫХ АЛГОРИТМОВ И ТЕХНОЛОГИЙ ....... 39 2.1 Методы автоматического подбора программных архитектур ..................... 39 2.2 Построение дерева решений для выбора архитектуры программных средств ................................................................................................................................ 41 2.3 Построение дерева решений для выбора базы данных проекта .................. 44 2.4 Построение дерева решения для выбора средств аутентификации и авторизации пользователей в системе ............................................................................ 46 2.5 Построение дерева решений для выбора отказоустойчивой архитектуры . 48 2.6 Построение дерева решений для выбора архитектуры канала связи .......... 50 2.7 Алгоритмы генерации программных шаблонов ............................................ 52 7 Выводы по разделу 2............................................................................................... 57 3 ПОДСИСТЕМА ГЕНЕРАЦИИ ШАБЛОНОВ ПРОГРАММ ЗАДАННОЙ АРХИТЕКТУРЫ ................................................................................................................ 58 3.1 BPMN-нотация ................................................................................................ 58 3.2 Выбор программно-технических средств для разработки ............................ 60 3.3 Логическая структура программы ................................................................ 64 3.4 Диаграмма-классов ......................................................................................... 65 3.4.1 Классы графического интерфейса ............................................................. 65 3.4.2 Классы сбор и анализ данных о системе ..................................................... 68 3.4.3 Классы генерация шаблонов ......................................................................... 70 3.4.4 Паттерн «Мост» .............................................................................................. 71 3.5 Описание ресурсов ......................................................................................... 73 3.6 Структура шаблонов ...................................................................................... 74 3.7 Описание пользовательского интерфейса ................................................... 74 3.8 Пример работы программы .............................................................................. 85 3.8.1 Монолитное приложение .............................................................................. 86 3.8.2 Трехмодульная система ................................................................................. 87 3.8.3 Многомодульная система .............................................................................. 90 Выводы по разделу 3............................................................................................... 95 ЗАКЛЮЧЕНИЕ ....................................................................................................... 97 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ ................................................. 100 ПРИЛОЖЕНИЕ А Граф выбора архитектуры проекта .................................... 104 ПРИЛОЖЕНИЕ Б Карта кода экспертной системы .......................................... 105 ПРИЛОЖЕНИЕ В Пример автоматически сгенерированного кода................ 106 ПРИЛОЖЕНИЕ Г Текст программы .................................................................. 108 8 Г.1 Класс MainWindow ......................................................................................... 108 Г.2 Класс Interview ................................................................................................ 123 Г.3 Класс CheckAnswer ......................................................................................... 130 Г.4 Класс SystemInfo ............................................................................................. 141 Г.5 Класс ProjectParsing ........................................................................................ 147 9 ОПРЕДЕЛЕНИЯ Программная система – система, состоящая из программного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения. Программное средство – компьютерная программа или логически связанная совокупность программ, предназначенная для автоматизации в определённой области профессиональной деятельности. Функциональные требования – требования, описывающие функции, которые должна выполнять разрабатываемая система. Нефункциональные описывающие, как требования должна работать (атрибуты система, характеристиками она должна обладать. 10 качества) и какими –требования, свойствами и ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ БД – база данных. СУБД – система управления базами данных. API (application programming interface)  интерфейс программирования приложений. EDA – event-driven architecture. EDI – electronic data interchange. GMS – Groupe Spécial Mobile. HTTP – HyperText Transfer Protocol. HTTPS – HyperText Transfer Protocol secure. ISDN – Integrated Services Digital Network. PaaS – platform as a service. PDN – page discovery network. PSTN – Public Switched Telephone Network. REST – Representational State Transfer. RPC – remote procedure call. SaaS – software as a service. SHA – Secure Hash Algorithm. SOA – service-oriented architecture. SOAP – Simple Object Access Protocol. SSL – Secure Sockets Layer. WCF – Windows Communication Foundation. WPF – Windows Presentation Foundation. UML (Unified Modeling Language)  унифицированный язык моделирования. 11 ВВЕДЕНИЕ Современное общество можно назвать постиндустриальным, для которого характерно использование информации и информационных ресурсов в различных областях человеческой деятельности. Работа любой организации или групп людей связана с использованием и осмыслением информации, а затем — с выполнением определенных действий, т. е. управлением [1]. На сегодняшний день экономический успех IT-производства во многом зависит от способности быстро адаптироваться к происходящим изменениям и возрастающим требованиям внешней среды. [3]. В странах с развитой рыночной экономикой конкурентная борьба обусловила разработку программ повышения качества. На этом фоне остро встает вопрос необходимости эффективного проектирования программных средств. Жизненный цикл разработки программного продукта включает в себя следующие основные итерации: − разработка требований; − проектирование; − реализации; − тестирование; − ввод в эксплуатацию. Процесс проектирования программного обеспечения состоит из сбора и анализа пользовательских требований и создания каркаса проекта в соответствие с требованиями. Успешная разработка программного проекта обеспечивается выбором оптимальной и надежной архитектуры, что требует значительного опыта в теоретических и практических вопросах, необходимого для преобразования неоднозначных требований бизнеса в надежные и практичные рабочие проекты [4]. Современное программное обеспечение редко бывает автономным. Как минимум, в большинстве случаев оно будет взаимодействовать с источником данных, например, корпоративной базой данных, предоставляющим информацию, с 12 которой работают пользователи программного обеспечения. Обычно современное программное обеспечение также должно взаимодействовать с другими службами и сетевыми функция для выполнения проверки подлинности, получения и публикации информации и предоставления интегрированных сред работы пользователей. Без соответствующей архитектуры может быть сложно, осуществить развертывание, эксплуатацию, обслуживание и успешную интеграцию с другими системами; кроме того, требования пользователей не будут соблюдены. Архитектуру программного обеспечения можно рассматривать как сопоставление между целью компонента ПО и сведениями о реализации в коде. Правильное понимание архитектуры обеспечит оптимальный баланс требований и результатов. Программное обеспечение с хорошо продуманной архитектурой будет выполнять указанные задачи с параметрами исходных требований, одновременно обеспечивая максимально высокую производительность, безопасность, надежность и многие другие факторы. В зависимости от решаемых задач и расчетной нагрузки архитектура программного продукта может быть существенно различной, а также может отличаться способ администрирования развертывания [4]. Стоимость приложения, внесения его обслуживания изменений и и расширение возможностей приложений влияют на стоимость владения данным продуктом. При создании новых приложений возникает вопрос какие технологии и программное обеспечение использовать. На сегодняшний день затруднено расширение некоторых существующих проектов из-за достижения пиковых значений характеристик используемых технологий или тесной связи всех модулей системы, т.е. когда изменение в одном классе или функции может требовать серьезных изменений в остальной части программы. Разрабатываемая в рамках магистерской диссертации экспертная система способна по конкретным параметрам, например, количеству запросов в секунду, единовременно работающих пользователей и т.д., рекомендовать использовать ту или иную архитектуру проекта [5]. Таким образом, целью работы является спроектировать и разработать экспертную систему, которая решает 2 основные задачи: 13 − По набору базовых требований подбирает для разрабатываемого программного продукта: − архитектуру; − систему управления базами данных; − протоколы обеспечения безопасности; − технологии обеспечения отказоустойчивости системы; − технологии организации каналов связи. − Генерации шаблона проекта в соответствии с выбранной архитектурой. На текущий момент аналогов разрабатываемой системы генерации архитектурных шаблонов на основе спецификации требований, которые решают обе задачи на рынке нет. При этом существует достаточное количество систем, которые позволяют генерировать некоторые шаблоны на основе формального описания системы, как правило, с помощью языка UML. Самыми известными средствами моделирования программных продуктов на сегодняшний день являются: − SAP Power Designer – программное средство, которое позволяет моделировать данные, документировать и управлять архитектурой предприятия. Основным преимуществом SAP Power Designer является сочетание в себе набора уникальных технологий для моделирования данных – традиционные концептуальное, физическое и логическое моделирование с моделями для бизнес-процессов и движения данных. PowerDesigner не заставляет использовать разработчиков какие-либо жестко встроенные методологии или процессы. Каждая компания может разработать и использовать свои собственные процессы, определить роли, ответственности, порядок обработки моделей и документов и т.д. [6]. − MS Visio Studio – программное средство, позволяющее работать со схемами, моделировать процессы и визуализировать данные. Visio позволяет создавать диаграммы, связанные с проектированием систем, разработкой приложений, инженерным 14 проектированием, планированием пространства, устранением неполадок, обслуживанием, управлением активами, технической поддержкой, ИТ-операциями, бизнес-процессами и т. д. [7]. − IBM Rational Rhapsody Developer – программный продукт, который представляет собой среду визуальной разработки, предназначенную для разработки прикладного программного обеспечения на основе языка Unified Modeling Language (UML). Rational Rhapsody Developer позволяет сгенерировать код встроенных приложений, имитационно моделировать и проводить тестирование на основе моделей, вести визуальную разработку, прослеживать требования к проекту [8]. Сравнительный анализ функциональности перечисленных программных продуктов с разрабатываемой системой приведен в Таблица 1. Таблица 1 – Сравнение с аналогами SAP Power MS Visio IBM Rational Автоматизированная Designer Studio Rhapsody система генерации Developer архитектурных шаблонов на основе спецификации требований Подбор - - - + + - + + + + - + архитектуры проекта на основе спецификации требований Возможность генерации шаблонов кода Простота установки и настройки системы 15 Таким образом, только у автоматизированной системы генерации архитектурных шаблонов на основе спецификации требований есть возможность подбора архитектуры проекта, что дает преимущество перед аналогами и делает разработку актуальной. 16 1 ИЗУЧЕНИИ ПРЕДМЕТНОЙ ОБЛАСТИ Перед началом разработки экспертной системы автоматической генерации архитектурных шаблонов необходимо изучить общие тенденции развития технологий разработки программных средств и ограничить округ рассматриваемых архитектур в рамках выпускной квалификационной работы. Следовательно, основными задачами данной главы являются: − изучить основные нефункциональные требования к программным средствам; − изучить технологии реализации рассмотренных требований; − обозначить набор технологий для реализации экспертной системы. 1.1 Архитектура программных систем В настоящие время можно выделить следующие наиболее часто встречающиеся архитектуры программных средств, которые рассматриваются в работе: − Десктопное приложение – содержит все ресурсы на локальном компьютере и не рассчитаны на одновременную работу пользователей [9]. − Клиент-серверное приложение – состоит из ядра системы, которым является сервер баз данных, представляющий собой приложение для управления данными: выполнение запросов, хранение и резервное копирование данных, отслеживание ссылочной целостности, проверку прав и привилегий пользователей, ведение журнала транзакций; и клиентской части, отправляющей запросы по работе с данными [10]. − Web-приложение – подмножество клиент-серверных приложений. Их особенность заключается в том, что Web-приложение развертывается и выполняется на сервере и клиент при этом получает только результаты его работы, которая основывается 17 на получении запросов от пользователя (клиента), их обработке и выдачи результата. Передача запросов и результатов их обработки происходит через сеть, обычно через протокол http и более высокоуровневые протоколы, построенные поверх него (JSON, REST, SOAP и другие). − Приложение как сервис (SaaS) – модель программного обеспечения, при которой поставщик разрабатывает и управляет веб-приложением, предоставляя доступ к нему через интернет подписчикам. Основное преимущество модели для потребителя состоит в отсутствии необходимости установки, обновления и поддержки программного обеспечения, а с точки зрения разработчика, SaaS позволяет упростить техподдержку, а также эффективно бороться с нелицензионным использованием программного обеспечения, поскольку само программное обеспечение не попадает к конечным заказчикам [11]. В основе модели обычно лежит PaaS. − Платформа как сервис (PaaS) – модель программного обеспечения, в которой вычислительные ресурсы предоставляются по запросу, на которых заказчик имеет возможность развернуть и запустить произвольное программное обеспечение. В рамках данной модели заказчик не управляет и не контролирует лежащую в основе физическую инфраструктуру, но имеет контроль над операционными системами и развернутыми приложениями [12]. − Архитектура EDA – способ написания приложений, в котором все сообщения доставляются асинхронно через очередь. В этом случае потребители сообщений имеют возможность всегда обрабатывать количество запросов не более своей расчетной нагрузки, что делает нагрузку на приложение более равномерной. Однако в пиковые моменты работы приложения оно может сильно проигрывает в скорости, а также возможно переполнение очереди сообщений. 18 − Сервис-ориентированная архитектура (SOA) – один из вариантов реализации архитектуры информационной сети EDA, предназначенный предприятия, для создания использующей принципы ориентации на сервисы для достижения тесной связи между бизнесом и поддерживающими его информационными системами, таким образом данная архитектура улучшает взаимосвязь между предприятием и бизнесом, позволяет создавать интегрированные приложения, основанные на существующих сервисах, создает гибкие бизнеспроцессы [13]. − Load balancer – технология, позволяющая распределять нагрузку между сервисами, способными обработать запрос [14]. Одним из наиболее известных способов балансировки является DNS Eound Robin – технология, при которой сервер DNS возвращает каждый раз различный адрес для домена, перечисляя адреса из некоторого набора серверов, которые могут обработать запрос. Сравнительный анализ по допустимой нагрузке приведен в Таблица 2. Таблица 2 – Сравнительный анализ по количеству обрабатываемых запросов Архитектура Количество запросов в секунду Десятки Сотни Тысячи миллионы + + PaaS + + EDA + + Десктопное приложение Клиент-серверное + + Web-приложение + + SaaS + + приложение SOA + + + Load balancer + 19 + Таким образом, выбор архитектуры проекта происходит на основе следующих 4-х требований: 1. Количество обрабатываемых запросов в системе. 2. Есть доступ к Интернет-сети. 3. Планируется ли использовать программный продукт на предприятии. 4. Свободный ли доступ к приложению. Граф анализа для выбора архитектуры приведен в приложении А. Для количества запросов более 1000 в секунду по умолчанию рекомендуется использовать балансировку нагрузки. Например, разрабатываемая система требует многопользовательского режима работы, обработки тысяч запросов в секунду, поддержки работы без доступа к сети Интернет и предполагается распространять ее только с коммерческой лицензией для предприятий, в этом случае, согласно рисунку А.1, выбирается технология SOA. Также учитывается, что количество запросов превышает 1000 и используется балансировка нагрузки. Таким образом, конечной выбранной архитектурой является SOA с балансировкой нагрузки. 1.2 Система управления базами данных На сегодняшний день существует 3 больших различных класса систем управления базами данных (СУБД): − Файл-серверные, в которых файлы данных хранятся централизованно на сервере, а СУБД располагается на каждом рабочей станции. Синхронизация и чтение данных осуществляется через сеть с помощью файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор сервера. К недостаткам можно отнести: потенциально высокую нагрузку локальной сети; затруднённость или невозможность централизованного управления, высокой надёжности, доступности и безопасность. − Клиент-серверные, а которых СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном 20 режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент- серверных СУБД заключается в повышенных требованиях к серверу. Среди достоинств можно выделить: потенциально более низкую загрузку локальной сети, удобство централизованного управления, обеспечение высокой надёжности, доступности и безопасности. Рекомендуется для применения во всех системах, предполагающих одновременную работу нескольких пользователей. − Встраиваемые СУБД, которые могут поставляться как составная часть некоторого программного продукта, не требуя самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Архитектура больше всего подходит для применения в настольных приложениях, также может применяться Webприложениях и SaaS. Файл серверная архитектура систем управления базами данных устарела и не рекомендована к использованию в современных программных системах. Таким образом, выбор типа СУБД производиться в зависимости от необходимости совместного использования данных несколькими пользователями или системами. Если информация должны быть доступна нескольким сервисам или клиентам используется клиент-серверная архитектура, в противном случае можно ограничиться встраиваемой СУБД. Клиент-серверные СУБД в свою очередь разделяются на несколько разных классов. В рамках квалификационной работы будут рассматриваться следующие виды: − Реляционные СУБД (например, Oracle Database, IBM DB2 и Microsoft SQL Server)– система управления базами данных, в которых информация представлена в виде двухмерных таблиц, связанных между собой. Реляционные СУБД ориентированы на реализацию систем операционной обработки данных и мало эффективны в задачах 21 аналитической обработки. Это связано с предположение о том, что данные в реляционной базе упорядочены случайным образом и их упорядочивание требует дополнительных затрат времени на сортировку при каждом обращении к базе данных [15]. − Документоориентированные документно-ориентированная СУБД (например, MongoDB) система управления базами — данных (СУБД) с открытым исходным кодом, написанная на языке C++, которая не является реляционной БД и не требует описания схемы таблиц. Записи в MongoDB представляют собой документ, структура которого состоит из пар field(поле) и value(значение) [16], что позволяет отлично ее масштабировать. Такую структуру рекомендуется применять в системах без большого количества связей. − Строковые СУБД (например, Apache Cassandra) – распределённая система управления базами данных, относящаяся к классу NoSQLсистем и рассчитанная на создание высоко масштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша. Преимуществами такой СУБД являются высокая масштабируемость и надежность и высокая пропускная способность чтения и записи [17]. Высокая степень надежности достигается за счет отсутствуя единой точки отказа и настраиваемым согласованности данных [18]. Дерево классификации СУБД представлено на Рисунок 1. 22 уровнем СУБД Встраиваемые Клиентсерверные Документоориетнированные Реляционные Строковые Рисунок 1 – Дерево классификации СУБД Таким образом, выбор наиболее подходящей базы данных осуществляется по следующим критериям: − необходимость доступа к одним данным нескольких пользователей; − большая масштабируемость данных; − критически недопустима потеря данных; − высокая пропускная способность чтения и записи; − сильная связанность данных; − согласованность данных. В Таблица 3 представлен выбор подходящей СУБД в зависимости от предъявляемых требований. 23 Таблица 3 – Выбор подходящей СУБД в зависимости от требований Встраиваемая Реляционная Документо- Строковые СУБД СУБД СУБД ориентированная СУБД необходимость - + + + - - + + - - - + + - - + + + - - + - - + доступа к одним данным нескольких пользователей большая масштабируемость данных критически недопустима потеря данных высокая пропускная способность чтения и записи сильная связанность данных согласованность данных Например, если в разрабатываемой системе не требуется доступ к одним и тем же данных нескольких пользователей, т.е. хранящиеся данные в системе индивидуальны для каждого пользователя, то, согласно Рисунок 2, выбирается встраиваемая СУБД. 24 Требуется ли хранить какие-либо данные в системе? да нет База данных не требуется да да нет Документоориентирова нная СУБД Предполагается ли большая связность данных в проекте? нет Требуется ли большая масштабируемость данных? Критична ли потеря данных при сбоях? нет Требуется ли доступ к одним и тем же данным нескольких пользователей? да да Требуется ли согласованность данных при сбоях? да Встраиваемая СУБД нет Критична ли потеря данных при сбоях? Строковая СУБД да нет да нет нет Предполагается ли большая связность данных в проекте? Требуется ли согласованность данных при сбоях? нет да Реляционная СУБД Рисунок 2 – Граф выбора СУБД 1.3 Требования к безопасности 1.3.1 Требования к аутентификации и авторизации Практически в любых компьютерных системах существует необходимость процедуры аутентификации, в ходе которой информационная система проверяет, действительно ли пользователь тот, за кого себя выдает. Для того, чтобы получить доступ к компьютеру, в Интернет, к системе удаленного управления банковским счетом и т. д., пользователю необходимо убедительно доказать свою подлинность с помощью предоставления системе некоторой специальной информации, на основании которой модуль аутентификации сможет принять решение о предоставлении доступа к требуемому ресурсу. Для реализации аутентификации и авторизации пользователя сразу в нескольких сервисах или системах используется технология единого входа (SSO) – механизм единого входа в систему или в приложение, основанный на распознавании 25 любого интерфейса процесса аутентификации и автоматического заполнения формы ввода пароля для каждого приложения [19], главным преимуществам которого является обеспечение безопасности передачи аутентификационных данных. На текущий момент известно 2 стандарта реализации SSO технологии: − SAML (язык разметки декларации безопасности) – открытый стандарт обмена данными аутентификации и авторизации между участниками, в частности, между поставщиком учётных записей и поставщиком сервиса, основанный на языке разметки XML и использовании SOAPпротокола [20]. − OpenId – это открытая децентрализованная система, которая позволяет пользователю использовать единый аккаунт для аутентификации на множестве не связанных друг с другом информационных ресурсов [21]. Для реализации стандарта можно использовать собственный или готовый провайдер идентификации. Промышленным предприятиям свойственно иметь собственного провайдера идентификации на основе стандарта SAML, который может быть связан с сервисом каталогов компании, реализованным, например, с помощью таких средств, как Lightweight Directory Access Protocol (LDAP) – протокол, определяющий методы, посредством которых осуществляется доступ к данным каталога. Он определяет и описывает представление, чтение и запись данных в службе каталогов, но не определяет как происходит хранение и манипулирование данными [22]. На текущий момент главной проблемой использования технологии OpenID является отсутствие поддерживающих его провайдеров идентификации. Для просмотра открытых сайтов может подойти использование в качестве провайдера OpenID Connect – спецификацию, которая организует процесс обмена данными через протокол OAuth 2.0 (открытый протокол авторизации, который позволяет предоставить стороннему сервису ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать логина и пароля [23]) между поставщиками учетных данных и проверяющими сторонами без необходимости вводить многочисленные данные [24]. Но для внутренних систем или систем, в 26 которых требуются повышенный контроль и отображение того, как и где устанавливаются ваши данные, понадобится собственный провайдер идентификации. Для систем, состоящих из одного модуля, удобнее использовать пару логин – пароль для входа в систему, используя хеширование – преобразование произвольных данных в некоторую последовательность фиксированной длины с использованием специальной хеш-функции, например, SHA-512. На Рисунок 3 представлена классификация технологий аутентификации и авторизации. Аутентификация и авторизация Логин Пароль SSO SAMP (на основе SOAP) OpenID (На основе Auth 2.0) Хеширование LDAP Собственный провайдер OpenID Connect Собственный провайдер Рисунок 3 – Классификация средств аутентификации и авторизации Таким образом, выбор стандарта для аутентификации и авторизации происходит на основе таких требований, как: 1. необходимость повышенного контроля к защите данных; 2. необходимость авторизации в нескольких системах; 3. возможность написания собственного провайдера идентификации. Граф выбора технологии аутентификации и авторизации пользователей в системе представлен на Рисунок 4. 27 да Количество модулей в системе 1 Логин-Пароль + Хэширование да да Требуется ли аутентификация пользователей в системе? нет >1 Не требуется Авторизация используется только для Web-модулей? Есть ли возможность написания собственного провайдера аутентификации нет и авторизации? Собственный провайдр на основе OpenID OpenID Connect нет да Есть ли возможность написания собственного провайдера аутентификации и авторизации? Собственный провайдр на основе SAMP нет LDAP Рисунок 4 – Граф выбора технологии авторизации и аутентификации Например, в разрабатываемой системе 3 модуля, которые используют авторизацию для различных типов узлов, и есть возможно разработки собственного провайдера аутентификации, в этом случае наиболее подходящим вариантом, согласно Рисунок 4, является собственный провайдер на основе SAMP. 1.3.2 Требования к безопасности передачи данных Наравне с процедурой аутентификации и авторизации в системе важен и процесс безопасной передачи запросов. Для этого можно использовать одну из следующих технологий шифрования данных при передаче запроса через HTTP протокол: − TLS – протокол транспортного уровня, основанный на протоколе SSL и предназначен для предоставления трёх услуг всем приложениям, работающим над ним: шифрование, аутентификацию и целостность [25]. − Kerberos – передавать сетевой протокол аутентификации, который позволяет данные через незащищённые 28 сети для безопасной идентификации. Ориентирован на клиент-серверную архитектуру и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов протокола аутентификации Нидхема — Шрёдера на основе доверенной третьей стороны [26]. Протокол основан на понятии Ticket (билет) – зашифрованном пакете данных, который выдается доверенным центром аутентификации. Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности доверенный центр выдает первичное удостоверение пользователя для доступа к сетевым ресурсам (TGT). В дальнейшем, при обращении к отдельным ресурсам сети, пользователь, предъявляя TGT, получает от доверенного центра удостоверение для доступа к конкретному сетевому ресурсу. − HMAC – код проверки подлинности сообщений на основе хеш-функции. При использовании HMAC тело запроса хешируется закрытым ключом и получившийся хеш отправляется вместе с запросом, после чего сервер использует собственную копию закрытого ключа и тело запроса для воссоздания хеша. При совпадении запрос принимается. Таким образом, если где-нибудь на дистанции кто-то проведет какие-либо манипуляции с запросом, хеш не совпадет и сервер будет знать, что запрос был подделан. А закрытый ключ в запросе никогда не пересылается, поэтому он не может быть скомпрометирован в пути [27]. Альтернативой использования протокола HTTP с дополнительным шифрованием данных является HTTPS – расширение протокола передачи данных HTTP для поддержки шифрования в целях повышения безопасности за счет передачи данных поверх криптографических протоколов SSL или TLS. На Рисунок 5 представлена классификация протоколов передачи данных и шифрования. 29 Передача данных HTTP TLS HTTPS Kerberos HMAC Рисунок 5 – Классификация технологий безопасной передачи данных Так как указанные технологии равнозначны в решении задачи безопасной передачи данных, то выбор той или иной технологии зависит от предпочтений разработчика системы и не может быть рекомендован автоматической системой генерации шаблонов на основе спецификации требований. 1.4 Отказоустойчивость Отказоустойчивость – это способность вычислительной системы продолжать выполнять заданные функциональные и нефункциональные требования, после возникновения неисправностей. На сегодняшний день существует несколько способ обеспечивать работоспособность приложения: 1. использовать отказоустойчивое оборудование; 2. применять отказоустойчивые архитектурные решения; 3. придерживаться принципов защитного программирования. В рамках работы будут рассмотрены только отказоустойчивые архитектурные решения. 1.4.1 Отказоустойчивая архитектура Отказоустойчивая архитектура с точки зрения инженерии — это метод проектирования отказоустойчивых систем, 30 которые способны продолжать выполнение запланированных операций при отказе их компонентов [28]. Существует 2 основных направления для достижения отказоустойчивости: − Аварийное восстановление – обеспечение надежности системы, за счет возможности ее полного восстановления, в том числе на другой физической платформе, после сбоя [29]. − Избыточность – использование избыточного количества необходимых компонентов для работы приложения, что бы в случае отказа одного из них система сохраняла работоспособность. При таком подходе к проектированию можно выделить 2 стратегии [29]: − Active-active – подход, когда в системе одновременно работают два идентичных компонента. В таком случае при падении одного из компонентов система останется полностью работоспособной. В качестве недостатков такого подхода можно отметить увеличение потребляемых ресурсов и возможное задвоение данных [29]. − Active-passive – подход, при котором в системе находится только один постоянно работающий компонент и в случае его сбоя запускается другой [29]. Такая архитектура с одной стороны, позволяет экономить потребляемые ресурсы, с другой требует реализации дополнительных требование: мониторинг и проверки корректного функционирования. Для реализации такого подхода рекомендуется использовать готовые решения. − Балансировка нагрузки – технология, при которой в системе есть несколько идентичных компонентов, между которыми достаточно равномерно распределяется вся нагрузка. В отличие от activeactive стратегии, здесь каждую задачу выполняет только один компонент, благодаря чему, не возникает ошибок, связанных с задвоением данных. Данная технология идеально подходит для stateless-компонент (компонент без сохранения состояния). В остальных случаях для отказоустойчивости постоянно синхронизировать состояние. 31 необходимо − Низкоуровневые сервисы отказа устойчивости – принцип, при котором, система разбивается на независимые отказоустойчивые компоненты. Такая технология подходит для микросервисных архитектур [29]. На Рисунок 6 представлена классификация технологий создания отказоустойчивой архитектуры системы. Отказоустойчивые архитектурные решения Аварийное восстановление Балансировка нагрузки Избыточность Active-active Низкоуровневые сервисы отказоустойчивости Active-Passive Рисунок 6 – Технологии создания отказоустойчивой архитектуры Таким образом, для выбора подходящей отказоустойчивой системы нужно проанализировать следующие требования: − возможность увеличения потребляемых ресурсов в 2,5 раза; − необходимость синхронизации данных; − наличие средств мониторинга в системе; − наличие средств для аварийного восстановления; − использование монолитной архитектуры. Сравнительный анализ отказоустойчивых архитектур проекта представлен в Таблица 4. 32 Таблица 4 – Сравнительный анализ отказоустойчивой архитектуры проекта увеличение Синхрони- Монито- аварийное потребля- зация восстановление ной емых данных ринг архитек- ресурсов Аварийное Монолит- тура - + + + + + + + +- - - + + +- - - + - +- - +- +- +- +- - восстановление Active-active избыточность Active-passive избыточность Балансировка нагрузки Низкоуровневые сервисы отказа устойчивости Граф выбора подходящей отказоустойчивой архитектуры проекта представлен на Рисунок 7. 33 Ограничены ли ресурсы? да да Требуется ли постоянная синхронизация данных? нет Требуется ли постоянная синхронизация данных? нет да >1 да Количество модулей в системе Допустима ли потеря данных в системе Количество модулей в системе 1 1 Количество модулей в системе >1 1 Количество модулей в системе >1 >1 Аварийное восстановление Допустима ли потеря данных в системе да нет 1 нет нет Аварийное восстановление Допустима ли потеря данных в системе да да Балансировка нагрузки нет Active-passive избыточность Допустима ли потеря данных в системе Низкоуровневые сервисы отказа устойчивости Балансировка нагрузки нет Active-active избыточность Низкоуровневые сервисы отказа устойчивости Рисунок 7 – Граф выбора отказоустойчивой архитектуры проекта 1.5 Система передачи сообщений Для взаимодействия внутри системы и с внешними приложениями используются различные технологии. В рамках квалификационной работы будут рассмотрены следующие варианты организации каналов связи, представленные на Рисунок 8: − Web API – интерфейс для интернет-приложений, который включает в себя следующие инструменты: − REST – стиль взаимодействия компонентов распределённого приложения, на основе URL-адресов и HTTP-методов. Одной из особенностей REST-архитектуры является гибкий способ обеспечения взаимодействия различных приложений в стандартном формате, что позволяет выполнить требования к интеграции. − SOAP – стандартизированный протокол обмена данными в XMLформате, который поддерживает SSL-шифрование и двухфазное принятие транзакций, что обеспечивает защиту целостности и подлинности данных [30]. − EDI – стандарты безопасной передачи регламентированных данных между организациями, использующий текстовый формат, который 34 подходит для описания плоских табличных данных. EDI включает в себя следующие технологии организации передачи данных: − Apache Kafka – распределённый программный брокер сообщений, который позволяет передавать любые сообщения по сети за счет передачи байтовых последовательностей. Так же к особенностям технологии Kafka можно отнести многопотоковый отказоустойчивый механизм обработки сообщений [31]. − Redis – хранилище данных в памяти, которое поддерживает разнотипные структуры данных. Redis имеет встроенную репликацию, Lua-скриптинг, выключение LRU, транзакции, а также обеспечивает высокую доступность через Redis Sentinel и автоматическое разбиение на разделы с помощью Redis Cluster [32]. − Rabbit MQ – брокер очереди сообщений, который позволяет вебсерверам быстро реагировать на запросы без необходимости выполнять сложные операции. Очередь сообщений позволяет распространять сообщение нескольким получателям для потребления или для балансировки нагрузок между рабочими [33]. − GMS – стандарт цифровой мобильной, связи предназначенных для применения в различных сферах: для передачи речевых сообщений и данных, вызывных и аварийных сигналов; подключаться к телефонным сетям общего пользования (PSTN), сетям передачи данных (PDN) и цифровым сетям с интеграцией служб (ISDN). Для защиты от ошибок в радиоканалах при передаче информационных сообщений применяется блочное и свёрточное кодирование с перемежением. В стандарте GSM достигается высокая степень безопасности передачи сообщений; осуществляется шифрование сообщений по алгоритму шифрования с открытым ключом (RSA) [34]. − Удаленный вызов компонент (RPC) – технология локального вызова с удаленного сервиса, скрывающая 35 организацию вызова, которую возможно быстро развернуть. RPC-технология имеет также свои недостатки, например, платформозависимость, потребность единовременного развертывания клиентской и серверной части, а так же большего количества ресурсов по сравнению с организацией локальных вызовов [35]. Исходя из вышесказанного, выбор использования RPCтехнологии требует экспертного мнения и в рамках работы рекомендоваться не будет. − WebSocket – двунаправленная технология обмена данными в режиме реального времени, которую рекомендуют использовать для интернет приложений и многопользовательских игр. Технологии канала связи Web API REST EDI SOAP Kafka Redis Web Socket Redis MQ GMS Рисунок 8 – Технологии организации канала связи Дерево выбора технологии организации канала связи представлено на Рисунок 9. Таким образом, выбор системы передачи сообщений зависит от архитектуры связываемых каналов и необходимости обмена данными в режиме реального времени. Например, канал связывает 2 модуля, один из которых с архитектурой SOA, второй – Web-приложение, поддержка передачи данных в режиме реального времени не требуется, в этом случае самой подходящей архитектурой канала связи, согласно Рисунок 9, является EDI. 36 Архитектура одного из связывающих модулей EDA или SOA да EDI да нет Обязателем ли обмен данными в режиме реального времени между модулями Web Socket нет Web API Рисунок 9 – Дерево выбора технологии организации канала связи Выводы по разделу 1 1. В результате изучения предметной области тенденций развития разработки программных средств выбраны результирующие технологии для анализа экспертной системой: технологии архитектура аутентификации и программного средства, авторизации СУБД, пользователей, отказоустойчивая архитектура, архитектура каналов связи. 2. Для осуществления анализа экспертной системой в рамках работы ограничен набор результирующих решений экспертной системы. Для выбора архитектуры программного средства выбраны: настольное приложение, клиент-серверное приложение, web-приложение, SaaS, PaaS, SOA, EDA. Для выбора системы управления базами данных выбраны встраиваемые, строковые, документоориентированные и реляционные СУБД. 3. Для подбора технологий, обеспечивающих безопасность и надежность разрабатываемых систем выбран ограниченный набор современных решений. В качестве технологии аутентификации и авторизации пользователей выбраны LDAP, OpenId Connect и собственный провайдер. Для реализации отказоустойчивые архитектуры выбраны такие решения, 37 как аварийное восстановление, active-active, active-passive, балансировка нагрузки, низкоуровневые сервисы отказа устойчивости. Для организации архитектуры каналов связи ограничен круг следующим набором: IDE, Web API и Web Socket. 38 2 ОПИСАНИЕ ИСПОЛЬЗУЕМЫХ АЛГОРИТМОВ И ТЕХНОЛОГИЙ Для оптимальной реализации экспертной системы автоматической генерации архитектурных шаблонов, необходимо использовать наиболее подходящие алгоритмы для обеспечения функциональных требований. Таким образом, основными задачами данного раздела являются: − изучение алгоритмов принятия решений; − изучение алгоритмов автоматической генерации кода; − выбор наиболее подходящих алгоритмов; − описать математическую модель экспертной системы. 2.1 Методы автоматического подбора программных архитектур Задача автоматического подбора архитектуры программных средств относится к задачам классификации: отнесения объектов к одному из заранее известных классов по заданным признакам, поэтому наиболее подходящей математической моделью является дерево решений. Деревья решений – это способ представления правил в иерархической, последовательной структуре, где каждому объекту соответствует единственный узел, дающий решение. Под правилом понимается конструкция, представленная в логическом виде "если ... то ..." [36]. Дерево состоит из «листьев» и ребер – «веток». На ребрах дерева решения записаны атрибуты, от которых зависит целевая функция, в «листьях» записаны значения целевой функции, а в остальных узлах — атрибуты, по которым различаются случаи. Целью процесса построения дерева принятия решений является создание модели, по которой можно было бы решить, какие значения может принимать целевая функция, имея на входе несколько переменных [37]. Общая схема построения дерева принятия решений выглядит следующим образом: − Выбирать атрибут Q и поместить его в корень дерева. 39 − Для всех его значений i оставить из тестовых примеров только те, у которых значение атрибута Q равно i. − Рекурсивно построить дерево в этом потомке. Рекурсия завершается тогда, когда подмножество в узле имеет те же значения целевой переменной, таким образом, оно не добавляет ценности для предсказаний. Для каждой задачи автоматического подбора архитектуры и технологий программных средств строится отдельное дерево решений. В целом в системе анализируется 18 уникальных атрибутов: А1 – Предполагаемое количество запросов в секунду. A2 – Приложение для коммерческого использования. A3 – Наличие доступа к Интернет-сети во время работы приложения. A4 – Лицензия программного средства. A5 – Необходимость хранить данные в системе. A6 – Необходимость доступа к одним данным нескольких пользователей. A7 – Большая масштабируемость данных. A8 – Критически недопустима потеря данных. A9 – Сильная связанность данных. A10 – Согласованность данных. A11 – Требуется ли аутентификация пользователей в системе. A12 – Количество модулей в системе. A13 – Использование авторизации и аутентификации только для Web. A14 – Наличие возможности написать собственный провайдер авторизации и аутентификации пользователей в системе. A15 – Возможность увеличения потребляемых ресурсов в 2.5 раза. А16 – Требуется канал связи. А17 – Архитектура связываемых модулей. А18 – Передача данных в режиме реального времени. Атрибуты A8, А10, A12 общие и используются для построения нескольких деревьев решений, остальные атрибуты специфические для построения того или 40 иного дерева решений. Значение атрибута А17 автоматически генерируется при выполнении анализа и не доступно для ввода пользователем. 2.2 Построение дерева решений для выбора архитектуры программных средств Дерево решений для выбора архитектуры программных средств строится на основе 4 атрибутов: Q1 – Предполагаемое количество запросов в секунду. Q2 – Приложение для коммерческого использования. Q3 – Наличие доступа к Интернет-сети во время работы приложения. Q4 – Лицензия программного средства. Атрибуты Q2, Q3 и Q4 имеют классовые значения и каждый делит дерево решений на 2 поддерева. Атрибут Q1 принимает целочисленные значения и является интервальной характеристикой. Q1 используется дважды при построении дерева: 1. В качестве первого атрибута для отсечения ветки настольного приложения. 2. В качестве последнего (пятого) атрибута для окончательного выбора архитектуры. Q1 разбивает дерево по интервалам: − 0 – 10 запросов; − 10 – 100 запросов; − 100 – 1000 запросов; − 1 000 – 1 000 000 запросов; − > 1 000 000 запросов. В качестве второго атрибута для анализа используется Q2, который принимает бинарные значения: − да; − нет. В качестве третьего атрибута для анализа используется Q3, который принимает бинарные значения «да» и «нет», аналогично атрибуту Q2. 41 Четвертым атрибутом в анализе используется Q4, который принимает 2 значения: − свободная; − частная. Целевая функция Y ограничена и может принимать следующие значения: Y1 = Настольное приложение. Y2 = Web-приложение. Y3 = Клиент-серверное приложение. Y4 = SOA. Y5 = SOA + балансировка нагрузки. Y6 = SaaS. Y7 = SaaS + балансировка нагрузки. Y8 = PaaS + балансировка нагрузки. Y9 = EDA + балансировка нагрузки. Таким образом, дерево принятия решений имеет следующий вид: − Если Q1 ϵ [0;10], то Y = Настольное приложение; − Иначе, если Q2 = Да, то: − Если Q3 = Да, то: − Если Q4 = Свободная, то: − Если Q1 < 1000, то У = SOA; − Если Q1 ϵ [1000; 1 000 000], то У = SOA + балансировка нагрузки; − Если Q1 > 1 000 000, то Y = EDA + балансировка нагрузки. − Если Q4 = Частная, то: − Если Q1 < 100, то У = Клиент-серверное приложение; − Если Q1 ϵ [100; 1 000], то У = SOA; − Если Q1 ϵ [1000; 1 000 000], то У = SOA + балансировка нагрузки; 42 − Если Q1 > 1 000 000, то Y = PaaS + балансировка нагрузки. − Если Q3 = Нет, то: − Если Q4 = Свободная, то: − Если Q1 < 1000, то У = SOA; − Если Q1 ϵ [1000; 1 000 000], то У = SOA + балансировка нагрузки; − Если Q1 > 1 000 000, то Y = EDA + балансировка нагрузки. − Если Q4 = Частная, то: − Если Q1 < 100, то У = Клиент-серверное приложение; − Если Q1 ϵ [100; 1 000], то У = SOA; − Если Q1 ϵ [1000; 1 000 000], то У = SOA + балансировка нагрузки; − Если Q1 > 1 000 000, то Y = EDA + балансировка нагрузки. − Иначе, если Q2 = Нет, то − Если Q3 = Да, то: − Если Q1 < 100, то У = Web-приложение; − Если Q1 ϵ [100; 1 000], то У = SaaS; − Если Q1 ϵ [1000; 1 000 000], то У = SaaS + балансировка нагрузки; − Если Q1 > 1 000 000, то Y = PaaS + балансировка нагрузки. − Если Q3 = Нет, то: − Если Q4 = Свободная, то: − Если Q1 < 100, то У = Клиент-серверное приложение; − Если Q1 ϵ [100; 1 000], то У = SOA; − Если Q1 > 1000, то Y = EDA + балансировка нагрузки. − Если Q4 = Частная, то: − Если Q1 < 100, то У = Клиент-серверное приложение; 43 − Если Q1 ϵ [100; 1 000], то У = SOA; − Если Q1 ϵ [1000; 1 000 000], то У = SOA + балансировка нагрузки; − Если Q1 > 1 000 000, то Y = PaaS + балансировка нагрузки. Дерево принятия решений для выбора архитектуры программного средства представлено на Рисунок 10. Q1 [0; 10] >10 Q2 Да Y1 Нет Q1 < 100 Свободная Свободная Q4 Частная Q4 Частная <1000 > 1 000 000 [1000; 1 000 000] Y4 Y5 Y9 < 100 Q1 > 1 000 000 [1000; 1 000 000] [100; 1000] Y3 Y4 Y5 Y7 Q1 > 1 000 000 <1000 < 100 Y5 Y9 Y3 Y4 Q4 Свободная Y6 Y7 Частная Y8 Q1 Q1 > 1 000 000 Y5 Y9 [100; 1000] Y3 Y4 > 1 000 000 < 100 > 1000 < 100 [1000; 1 000 000] [100; 1000] [1000; 1 000 000] Y4 Q1 > 1 000 000 Нет [1000; 1 000 000] [100; 1000] Y2 Q1 Q3 Да Q3 Да Нет Y7 [1000; 1 000 000] [100; 1000] Y3 Y4 Y5 Y7 Рисунок 10 – Дерево выбора архитектуры проекта 2.3 Построение дерева решений для выбора базы данных проекта Дерево решений для выбора типа базы данных программного проекта строится на основе 6 атрибутов: Q1 – необходимость хранить данные в системе; Q2 – необходимость доступа к одним данным нескольких пользователей; Q3 – большая масштабируемость данных; Q4 – критически недопустима потеря данных; Q5 – сильная связанность данных; Q6 – согласованность данных. Все атрибуты принимают логические значения «false» или «true», таким выбор системы управления базой данных происходит на основе бинарного дерева принятия решений. При этом целевая функция Y ограничена и может принимать следующие значения: 44 Y1 = СУБД не требуется. Y2 = Встраиваемая СУБД. Y3 = Строковая СУБД. Y4 = Документоориентированная СУБД. Y5 = Реляционная СУБД. Дерево принятия решений имеет следующий вид: − Если Q1 = true, то: − Если Q2 = true, то: − Если Q3 = true, то: − Если Q4 = true, то Y = Y3. − Если Q4 = false, то: − Если Q5 = true, то: − Если Q6 = true, то Y = Y3. − Если Q6 = false, то Y = Y4. − Если Q5 = false, то Y = Y4. − Если Q3 = false, то: − Если Q4 = true, то Y = Y3. − Если Q4 = false, то: − Если Q5 = true, то: − Если Q6 = true, то Y = Y3. − Если Q6 = false, то Y = Y5. − Если Q5 = false, то Y = Y5. − Если Q2 = false, то Y = Y2. − Если Q1=false, то Y = Y1. Дерево принятия решений для выбора системы управления базой данных программного средства представлено на Рисунок 11. 45 Q1 true false Q2 true Y1 false Q3 true true Y3 Q4 Y2 false Q4 false false true Q5 true Y3 true Q5 false false Q6 Y3 Y4 Y4 Q6 Y3 Y5 Y5 Рисунок 11 – Дерево решений для выбора СУБД 2.4 Построение дерева решения для выбора средств аутентификации и авторизации пользователей в системе Дерево решений для выбора технологии реализации функционала авторизации и аутентификации пользователей в программной системе строится на основе значений 4 атрибутов: Q1 – Требуется ли аутентификация пользователей в системе. Q2 – Количество модулей в системе. Q3 – Использование авторизации и аутентификации только для Web. Q4 – Наличие возможности написать собственный провайдер авторизации и аутентификации пользователей в системе. 46 Атрибуты Q1, Q3 и Q4 имеют логические значения «true» и «false». Атрибут Q2 принимает положительные целочисленные значения и является интервальной характеристикой, принятие решения происходит по логическому значению сравнения атрибута с 1. Таким образом, каждый атрибут делит дерево на 2 поддерева. Целевая функция Y ограничена и может принимать следующие значения: Y1 = Авторизация и аутентификация пользователей не требуется. Y2 = Логин-пароль + хеширование. Y3 = Собственный провайдер на основе технологии OpenID. Y4 = OpenID Connect. Y5 = Собственный провайдер на основе технологии SAMP. Y6 = LDAP. Таким образом, дерево принятия решений имеет следующий вид: − Если Q1 =true, то: − Если Q2 = 1, то Y = Y2. − Если Q2 > 1, то: − Если Q3 = true, то: − Если Q4 = true, то Y = Y3. − Если Q4 = false, то Y = Y4. − Если Q3 = false, то: − Если Q4 = true, то Y = Y5. − Если Q4 = false, то Y = Y6. − Если Q1 = false, то Y = Y1. Дерево принятия решений для выбора технологии для реализации функционала для авторизации и аутентификации пользователей в программной системе представлено на Рисунок 12. 47 Q1 true Q2 Q2 = 1 false Y1 Q2 > 1 Y2 Q3 true true Q4 Y3 false Q4 false false true Y4 Y5 Y6 Рисунок 12 – Дерево решений для выбора технологий проверки подлинности пользователей 2.5 Построение дерева решений для выбора отказоустойчивой архитектуры Выбор отказоустойчивой архитектуры проекта происходит в двух случаях: для системы в целом и для каждого программного модуля отдельно. Для системы в целом выбор отказоустойчивой технологии происходит на основе значения одного атрибута Q1 = количество модулей в системе, которой принимает положительные целочисленные значения. Принятие решения происходит на основе результата сравнения значения атрибута Q1 с 1. Целевая функция Y может принимать 2 значения: Y1 = Аварийное восстановление. Y2 = Низкоуровневые сервисы отказа устойчивости. Дерево принятия решения для выбора отказоустойчивой архитектуры представлено на Рисунок 13 и имеет следующий вид: − Если Q1 = 1, то Y = Y1. − Если Q1 > 1, то Y =Y2. 48 Q1 = 1 Q1 Y1 Q1 > 1 Y2 Рисунок 13 – Дерево принятия решений для выбора отказоустойчивой архитектуры для системы в целом Выбор отказоустойчивой архитектуры для каждого модуля происходит на основе значений 4 следующих атрибутов: Q1 – Количество модулей в системе. Q2 – Возможность увеличения потребляемых ресурсов в 2.5 раза. Q3 – Согласованность данных. Q4 – Критически недопустима потеря данных. Атрибут Q1 принимает положительные целочисленные значения и является интервальной характеристикой, принятие решения происходит по логическому значению сравнения атрибута с 1. Атрибуты Q2, Q3, Q4, Q5 и Q6 имеют логические значения «true» и «false». Таким образом, каждый атрибут делит дерево на 2 поддерева. Целевая функция Y может принимать следующий значения: Y1 = Аварийное восстановление. Y2 = Низкоуровневые сервисы отказа устойчивости. Y3 = Active-active избыточность. Y4 = Active-passive избыточность. Y5 = Балансировка нагрузки. Таким образом, дерево принятия решений имеет следующий вид: − Если Q1 = 1, то Y = Y1. − Если Q1 > 1, то: − Если Q2 = true, то: − Если Q3 = true, то: − Если Q4 = true, то Y = Y4. 49 − Если Q4 = false, то Y = Y5. − Если Q3 = false, то: − Если Q4 = true, то Y = Y4. − Если Q4 = false, то Y = Y2. − Если Q2 = false, то: − Если Q3 = true, то: − Если Q4 = true, то Y = Y3. − Если Q4 = false, то Y = Y5. − Если Q3 = false, то: − Если Q4 = true, то Y = Y3. − Если Q4 = false, то Y = Y2. Дерево принятия решений для подбора отказоустойчивой архитектуры каждого модуля в программной системе представлено на Рисунок 14. Q1 Q1 = 1 Q1 > 1 Y1 Q2 true Q3 true Q4 false true false Q4 false Q4 Q4 true Y4 Q3 false true false true Y5 Y4 Y2 Y3 false true false Y5 Y3 Y2 Рисунок 14 – Дерево принятия решений для выбора отказоустойчивой архитектуры для системного модуля 2.6 Построение дерева решений для выбора архитектуры канала связи Для выбора архитектуры канала связи используется значение 3-х атрибутов: 50 Q1 – Требуется канал связи. Q2 – Архитектура связываемых модулей. Q3 – Передача данных в режиме реального времени. Атрибуты Q1 и Q3 бинарные и принимают значения true или false. Значение атрибута Q2 принимает одно из возможных значений целевой функции анализа дерева решений выбора архитектуры модуля и генерируется системой автоматически на основе предыдущего анализа. Целевая функция Y может принимать 4 значения: Y1 – EDI. Y2 – Web API. Y3 – Web Socket. Y4 – Нет канала связи. Таким образом, дерево принятия решений для выбора архитектуры канала связи между двумя модулями системы имеет следующий вид. − Если Q1 = true, то: − Если ∃ Q2 ϵ {SOA, EDA} (архитектура хотя бы одного из связываемых модулей SOA или EDA), то Y = Y1. − Если не ∃ Q2 ϵ {SOA, EDA}, то: − Если Q3 = true, то Y = Y3. − Если Q3 = false, то Y = Y2. − Если Q2 = false, то Y = Y4. Дерево выбора архитектуры канала связи представлено на Рисунок 15. 51 Q1 Q1 = true Q2 Q1 = false Y4 ! Q2 ϵ {SOA, EDA} Q2 ϵ {SOA, EDA} Q3 Y1 true false Y3 Y2 Рисунок 15 – Дерево решений выбора архитектуры канала связи 2.7 Алгоритмы генерации программных шаблонов На сегодняшний день известно несколько способов автоматически сгенерировать программный шаблон, некоторые из них: 1. Генерация текстов на основе шаблонов – алгоритм генерации текста, основанный на текстовом шаблоне и базе данных. База данных используется для построения различных конструкций из шаблонов. Она состоит из объектов, которые связаны с различными присущими им состояниями, при этом каждая связь имеет свой вес [38]. Например, необходимо составить предложение по шаблону «namespace %%name;». В этом случае %%name = GenerateArhTemplates будет иметь характеристику %X = 1, так как состоит из одной части, а %%name = GenerateArhTemplates.Templates – %X = 2. Таким образом, в шаблоне можно указать «namespace %%name.X1;», что будет означать подстановку имени шаблона, состоящей из одной части. Данный метод наиболее часто используется для автоматической генерации текстов на естественном языке. 52 2. Способ генерации кода, основанный на построении графа переходов и последовательности смены состояний. Общий алгоритм генерации кода на основе конечного автомата состоит из следующих частей: − преобразование графической модели в программное представление; − изоморфное преобразование программной модели в общий формат – удобный формат для чтения, хранения и преобразования данных различными программами; − преобразование из общего представления в исходный код программы [39]. Для изображения графа переходов необходимо использовать строго заданный специализированный формат, который использует все типы элементов, используемые на графе переходов. Генерация исходного кода, как правило, основывается на методах порождающего программирования. 3. Порождающие программирование – парадигма технологии разработки программного обеспечения, основанная на моделировании семейства программных систем, на основе которых можно по конкретным техническим требованиям автоматически получить промежуточный или конечный программный продукт из элементарных, многократно используемых компонентов реализации с помощью базы знаний о конфигурациях [40]. Основными этапами разработки в рамках порождающего программирования: − определение предметной области; − моделирование характеристик и понятий; − проектирование общей архитектуры; − определение предметно-ориентированных нотаций; − установление знаний о конфигурации; − реализация компонентов реализации; − реализация предметно-ориентированной нотации; − реализация знаний о предметной области при помощи генераторов [40]. 53 В настоящее время в рамках порождающего программирования можно выделить следующие методы генерации кода: − Метод подстановки основан на создании шаблона кода и набора данных в специальном формате, после этого с помощью вспомогательной программы выполняется подстановка этих данных в шаблон. Набор используемых в шаблоне подстановок может быть статическим или динамически. Такой подход весьма нагляден и прост в использовании, однако имеет весьма ограниченную область применения и требует предварительной подготовки передаваемых для подстановки данных [39]. − Метод подстановки с исполнением кода – этот вид генерации отличается от простого метода подстановки возможностью применять в шаблоне вставки исполняемого кода, оперирующего переданными в шаблон данными. Исполняемый код чаще всего использует язык, который специально создан для конкретного типа шаблонов и включает основные алгоритмические конструкции. Необходимо отметить, что по мере усложнения конструкций, применяемых в шаблоне, уменьшается наглядность самих шаблонов [39]. − Метод генерации кода, основанный на обработчики данных регулярной структуры предполагает полное разделение данных и их представления. В этом случае шаблон играет роль обработчика данных и пишется на специальном метаязыке. Примером такого подхода является XSLTобработка данных, представленных в XML-формате [39]. Перечисленные способы автоматической генерации кода пересекаются по используемым технологиям. Так же каждый из них имеет свои преимущества и недостатки. Сравнительный анализ способов программного кода представлен в Таблица 5. 54 автоматической генерации Таблица 5 – Сравнительный анализ способов автоматической генерации кода Генерация Генерация кода Порождающие текстов на основе на основе графа программирование шаблонов переходов Необходимость изначального + + + + - + + + - - + + + +- +- задания шаблонов Использование метода подстановок Необходимость алгоритмов дополнительного контроля Использование формального представления программной системы Понятность алгоритмов обработки данных Из Таблица 5 следует, что: − Генерация текстов на основе шаблонов реализуется с помощью понятных алгоритмов, и при этом требует формальное представление программной системы. 55 − Генерация кода на основе графа переходов и порождающее программирование в больших системах могут реализовываться с помощью сложных и запутанных алгоритмов, что усложняет внесения изменений в логику экспертной системы. − Генерация кода на основе графа переходов не использует подстановки, из этого следует, что каждый класс программы необходимо описывать с помощью формальных грамматик. В данном случае это приводит к масштабному разрастанию кода при добавлении нового архитектурного шаблона. − Порождающее программирование требует дополнительного контроля сгенерированного текста, что требует встраивать в разрабатываемую экспертную систему алгоритмы синтаксического разбора, что, в свою очередь, приводит к увеличению ресурсов необходимых на внесение изменений в логику работы системы. Исходя из выше сказанного, для реализации функции автоматической генерации программных шаблонов в разрабатываемой системе используется гибридный алгоритм, основанных на преимуществах каждого из рассмотренных способов. Алгоритм состоит из следующих этапов: − получении формального описания программной системы на основе диаграммы пакетов; − выбор наиболее подходящего шаблона для каждого пакета на основе его характеристик; − генерация исходного кода с помощью метода подстановок порождающего программирования. Такой подход позволяет расширять возможности системы без переписывания основных алгоритмов работы, при этом требует сознания индивидуальных шаблонов тестов программ для каждого поддерживаемого языка программирования. 56 Выводы по разделу 2 1. В результате проведения исследования для анализа требований и выбора наиболее подходящих технологий и архитектур выбран метод, основанных на анализе атрибутов и построении деревьев решений. 2. Проведен анализ технологий генерации программных шаблонов: генерация текстов на основе шаблонов; способ генерации кода, основанный на построении графа переходов и последовательности смены состояний; порождающие программирование. Главным недостатком первого метода является отсутствие формализованного представления шаблона, следующих двух – значительное уменьшение читабельности кода для сложных систем, что увеличивает стоимость внесения изменений в алгоритмы построения решений. 3. Для генерации шаблонов текстов программ разработан новый алгоритм, основанный на преимуществах следующих подходов: генерация текстов на основе шаблонов; способ генерации кода, основанный на построении графа переходов и последовательности смены состояний; порождающие программирование. 57 3 ПОДСИСТЕМА ГЕНЕРАЦИИ ШАБЛОНОВ ПРОГРАММ ЗАДАННОЙ АРХИТЕКТУРЫ Для подтверждения эффективности выбранной математической модели для работы экспертной системы необходимо проверить их на практике, т.е. реализовать основные функциональные требования экспертной системы автоматической генерации архитектурных шаблонов. Следовательно, возникают задачи: − описать бизнес-процессы, в которых предполагается использование разрабатываемой системы; − описать логическую и физическую модели разрабатываемой системы; − выбрать программно-технические средства разработки; − реализовать экспертную систему; − протестировать соответствие полученного экспертного решения разрабатываемой системой описанной математической модели. 3.1 BPMN-нотация Разрабатываемая экспертная система предназначена для реализации следующих бизнес-процессов: − выбор архитектурных шаблонов для реализации программного обеспечения; − генерации архитектурных шаблонов. Для выбора архитектурных шаблонов и технологий проекта пользователю необходимо выполнить следующую последовательность действий: − Импортировать данные о проекте или создать новый проект, ввести количество модулей и название системы, пройти анкетирование. − Проверить полноту данных: − если данных достаточно, происходит переход к подбору технологий и архитектур системы; − если данных недостаточно, продолжается анкетирование пользователя. 58 − После подбора архитектур и технологий проекта происходит проверка рекомендаций: − если пользователь согласен с рекомендациями системы, список рекомендуемых параметров сохраняется в специальном файле. − если требуется внести коррекции в полученный список архитектур и технологий, пользователь вносит их, сохраняет изменения и далее может: − вернуться к подбору технологий и архитектур проекта с учетом внесенных изменений; − сохранить список рекомендуемых технологий и архитектур проекта. После получения списка рекомендуемых технологий и архитектур бизнеспроцесс заканчивается. BPMN- модель выбора архитектурных шаблонов для реализации программного обеспечения представлена на Рисунок 16. Рисунок 16 – Выбор архитектурных шаблонов для реализации программного обеспечения Для генерации шаблонов кода пользователь задает проект и указывает путь к набору текстовых шаблонов. Затем система автоматические генерирует шаблоны кода для выбранной системы, после чего пользователь может сохранить результат. BPMN- модель генерации шаблонов кода представлена на Рисунок 17. 59 Рисунок 17 – Генерации архитектурных шаблонов 3.2 Выбор программно-технических средств для разработки На текущий момент наиболее популярными операционными системами являются системы семейства Windows, так же популярны Linux и Mac OS. В связи с этим приложение разрабатывается для Windows, как для основной операционной среды, с возможностью дальнейшего переноса на другие системы. Кроссплатформенность приложения позволит разрабатывать и реализовывать проект на наиболее подходящей платформе. Таким образом повышается лояльность клиентов к предоставляемой продукции. При выборе средств для разработки крупного программного проекта необходимо учесть множество различных факторов, наиболее важным, из которых является язык программирования, потому что он в значительной степени определяет другие доступные графического средства. интерфейса Например, для разработчикам разработки пользовательского необходима GUI-библиотека, предоставляющая готовые элементы интерфейса, такие, как кнопки и меню. Так как используемая графическая библиотека оказывает большое влияние на разработку проекта, часто ее выбор осуществляется первым, а язык программирования определяется из числа доступных для этой библиотеки языков [41]. Проектирование продукта производиться с помощью UML-диаграмм и блоксхем. Язык UML позволит представить в графическом и понятном виде бизнес60 процессы, выбранные для автоматизации, предметную область и взаимодействия между объектами предметной области. С помощью блок схем представлены основные алгоритмы обработки информации. Для разработки программного обеспечения на сегодняшний день используются такие языки программирования, как C#, Java, C++. К достоинствам языка Java относят кроссплатформенность и безопасность, которые достигаются переводом программного кода в байт-код. Из недостатков можно выделить более низкую скорость работы, большое потребление памяти и отсутствие прямого доступа к памяти. Язык С++ поддерживает несколько парадигм программирования, в том числе и объектно-ориентированное. Также существует возможность работы с указателями и ссылками, прямой доступ к памяти. Более новым языком программирования является C#. В нем существует несколько библиотек для разработки графического интерфейса, встроенный сборщик мусора и обеспечивается более быстрая работа по сравнению с языком Java. Для наглядности основные возможности перечисленных языков представлены в Таблица 6. Таким образом, для разработки программного обеспечения выбран объектноориентированного программирования C#, который позволит в дальнейшем адаптировать разработанный код под другие операционные системы без переписывания программы. Так же язык C# обладает следующими ключевыми особенностями: а) не требуется использовать указатели; б) автоматическое управление памятью посредством сборки мусора; в) формальные синтаксические конструкции для классов, интерфейсов, структур, перечислений и делегатов; г) возможность перегрузки операций для специальных типов; д) поддержка программирования на основе атрибутов [42]. 61 Таблица 6 – Сравнительный анализ языков программирования Возможность Язык программирования C++ C# Java Типизация Статическая типизация + + + данных Динамическая типизация + - + Неявная типизация + + - приведение + + + + - на + + - управление + + - + + + + - Неявное типов без потери данных Неявное приведение + типов в неоднозначных ситуациях Управление Создание памятью стеке объектов Ручное памятью Сборка мусора предполагается сборка мусора для интеллектуальны х указателей Типы и Кортежи структуры Многомерные массивы + + + данных Динамические массивы + + + Ассоциативные массивы + + + Интерфейсы + + + + - - Шаблоны + + + Перегрузка функций + + + Значения параметров по умолчанию + + - Именованные параметры + + - Объектно- ориентированные Множественное возможности наследование 62 Для создания графического интерфейса настольного пользовательского приложения на языке C# существует несколько технологий: ADO.NET, WCF и WPF. Технология ADO.NET нацелена на автономную работу с помощью объектов DataSet. Эти типы представляют локальные копии любого количества взаимосвязанных таблиц данных. Технология WCF специально предназначена для построения распределенных систем и предлагает единую, унифицированную и расширяемую использоваться объектную для модель для взаимодействия программирования, ранее разрозненных которая может распределенных технологий. Инфраструктура WPF создавалась для того, чтобы объединить все ранее несвязные задачи программирования в единую объектную модель. Так как в рамках выпускной квалификационной работы для реализации графического интерфейса пользователя выбрана технология WPF, которая обладает такими основными функциональными возможностями как: а) множество диспетчеров компоновки для обеспечения исключительно гибкого контроля над размещением и изменением позиций содержимого; б) использование расширенного механизма привязки данных для связи содержимого с элементами пользовательского интерфейса разнообразными способами; в) встроенный механизм стилей для приложений WPF; г) применение векторной графики, которая позволяет автоматически изменять размеры содержимого соответствуя размеру и расширению экрана, размещающего приложение; д) развитый графический API-интерфейс, поддерживающий документы XML Paper Specification, фиксированные документы, документы не фиксированного формата и аннотации в документах; е) поддержка взаимодействия с унаследованными моделями графических пользовательских интерфейсов [42]. Использование полнофункциональные языка C# настольные и технологии приложения 63 WPF с позволяет удобным и создавать простым в использовании графическим пользовательским интерфейсом, сопровождаемые документацией. 3.3 Логическая структура программы Разрабатываемую экспертную систему условно можно разбить на 4 части: − Графический интерфейс – интерфейс взаимодействия с пользователем. − Сбор и анализ данных о системе – часть программы, которая генерирует вопросы для анкетирования пользователя, обрабатывает ответы пользователя и выбирает наиболее подходящие архитектуры и технологии для программной системы. − Генерация шаблонов – часть программы, которая на основе информации о разрабатываемой системе генерирует шаблоны кода. − Мост – набор классов, связывающий логическую и графическую часть экспертной системы. Пользователь взаимодействует с экспертной системой через графический интерфейс. Мост связывает графическую и логическую части системы: с одной стороны, графический интерфейс, с другой стороны, сбор и анализ данных о системе и генерацию шаблонов. При этом, модуль генерации шаблонов использует заранее заготовленные текстовые паттерны, а модуль сбора и анализа данных о системе использует словари ресурсов. Логика работы разрабатываемой экспертной системы в графическом виде изображена на Рисунок 18. 64 Рисунок 18 – Логика работы экспертной системы 3.4 Диаграмма-классов Разрабатываемая программа состоит 19 классов, которые логически разделяются на 3 блока: − Классы графический интерфейс – описывают визуализацию системы и ее реакцию на действия пользователей. − Классы сбор и анализ данных о системе – описывают алгоритмы анкетирования пользователя и работу с деревьями решений для подбора наиболее подходящий архитектуры и технологий для разрабатываемой программной системы. − Классы генерация шаблонов – описывают алгоритмы выбора и преобразования шаблонов кода. − Классы реализации паттерна мост – набор классов, связывающий логическую и графическую часть экспертной системы. 3.4.1 Классы графического интерфейса Для поддержки работы графического интерфейса в разрабатываемой экспертной системе реализованы 7 классов: 65 − MainWindow – класс главной формы графического интерфейса, который позволяет вызвать остальные графические формы проекта и описывает работу с главным меню приложения. Программный текст класса представлен в приложении Г в разделе Г.1. − AddNewModul – класс формы, позволяющей добавить новый модуль в систему. − DeleteModul – класс формы, позволяющей выбрать модуль для удаления из системы. − GenerateChannel – класс формы, позволяющей редактировать, создавать и удалять каналы связи между модулями системы. − ModulPakageGrid – вспомогательный класс для отображения рекомендуемых технологий для каждого модуля системы в графическом виде. − FoldersWork – класс, содержащий методы вызова диалоговых окон для сохранения и загрузки данных в проект. − CodeGenerate – класс, позволяющий вывести на экран автоматически сгенерированный код. 66 Диаграмма классов графического интерфейса представлена на Рисунок 19. Рисунок 19 – Диаграмма классов графического интерфейса 67 3.4.2 Классы сбор и анализ данных о системе Для реализации функционала анкетирования пользователя, проверки и анализа полученных данных, а также подбора и рекомендации архитектур и технологий в экспертной системе реализованы следующие 7 классов: − Channel – класс, описывающий канал связи между модулями системы. − CheckAnswer – статический класс, обрабатывающий результат анкетирования пользователей. Методы данного класса определяют значения атрибутов системы на основе ответов пользователя и выбирают наилучшую технологию или архитектуру по заданным деревьям принятия решений. Программный текст данного класса представлен в приложении Г в разделе Г.3. − UserChanges – класс, содержащий методы для корректировки информации о системе и значения атрибутов при работе с графическим представлением описания системы. − SpecMath – статический класс, содержащий специальные математические методы для вычисления параметров системы, например, расчета количества возможным каналов связи или поиска канала по названиям связующих модулей. − Interview – класс, определяющий следующий вопрос в анкетировании пользователя и возможные варианты ответа. Программный текст данного класса представлен в приложении Г в разделе Г.2. − SystemInfo – статический класс, содержащий общие сведения о текущем проекте: название системы, количество модулей и каналов связей, отказоустойчивую архитектуры для системы в целом и т.д. . Программный текст данного класса представлен в приложении Г в разделе Г.4. − Modul – класс, содержащий значение атрибутов, рекомендуемые технологии и архитектуры для конкретного модуля системы. Диаграмма классов сбора и анализа данных о разрабатываемой системе представлена на Рисунок 20. 68 Рисунок 20 – Диаграмма классов сбора и анализа данных о системе 69 3.4.3 Классы генерация шаблонов Для реализации функционала автоматической генерации шаблонов кода и для отработки текстовых данных в экспертной системе реализованы следующие классы: − CodeGenerate – статический класс, содержащий методы для выбора файлов шаблонов кода в зависимости от параметров разрабатываемой системы. − TextConverter – класс, содержащий методы преобразования текстовых данных, например, методы трансляции русского текста в английский, функции заметы текстовых фрагментов по шаблону и т.д. − ProjectParsing – статический класс, позволяющий преобразовать все данные о разрабатываемой системе в текстовый файл и, наоборот, на основе текстовых разрабатываемой данных системы. расставить параметры Программный текст и атрибуты данного класса представлен в приложении Г в разделе Г.5. − FileInform – класс, содержащий информацию о конкретном автоматически сгенерированном шаблонном файле кода: разрешение, сгенерированный код и название класса. Диаграмма классов генерации шаблонов кода представлена на Рисунок 21. 70 Рисунок 21 – Диаграмма классов генерации шаблонов кода 3.4.4 Паттерн «Мост» Для разделения графической и логической частей экспертной системы используется структурный шаблон проектирования «Мост». Такое решение позволяет изменять логику работы системы и графический интерфейс независимо друг от друга. Для реализации шаблона «Мост» в системе реализован класс Bridge, который представлен на Рисунок 22 и содержит пользовательского интерфейса. 71 методы отработки запросов Рисунок 22 – Класс Bridge На Рисунок 23 изображена диаграмма классов проекта, где показано, что классы графического интерфейса используют классы логической части экспертной системы только через структурный шаблон «Мост». 72 Рисунок 23 – Диаграмма классов проекта 3.5 Описание ресурсов Для хранения списка вопросов, названия технологий и архитектур в экспертной системе используются файлы ресурсов. Такой подход позволяет: − изменять формулировку текстовой строки (ресурса) инкапсулировано от прикладного кода; − поддерживать несколько языков разрабатываемого приложения; − разрабатывать приложение без использования базы данных для хранения статических таблиц. В разрабатываемом приложении используется 7 файлов ресурсов: − ArhitectureStyles – список возможных программных архитектур. − AutentificationTypes – список поддерживаемых для анализа технологий авторизации и аутентификации пользователей в системе. − ChannelSecurity – список возможный технологий реализации безопасной передачи данных. − DB – список поддерживаемых СУБД. − FaultTolerancesStyle – список возможным отказоустойчивых архитектур как для системы в целом, так и для каждого отдельного модуля. 73 − Questions – список вопросов и фрагменты предложений для анкетирования пользователей. − TypesOfChannel – список поддерживаемых архитектур реализации каналов связей между модулями системы. Файлы ресурсов используются в части программы, отвечающей за сбор и обработку требований к программной системе, а также подбора наиболее подходящих технологий и архитектур. Карта кода проекта представлена в приложении Б. 3.6 Структура шаблонов Текстовые шаблоны кода, используемые для автоматической генерации классов программ, хранятся в заданном иерархическом виде. Название каталога должно совпадать с наименованием ресурса в приложении. Внутри каталога хранятся файлы классов в формате txt c универсальным смысловым названием. Количество файлов зависит от технологии, для реализации одних архитектур требуется всего один класс, для реализации других – несколько, связанных между собой шаблонов. На сегодняшний день разрабатываемая система генерирует шаблоны кода для следующих технологий и архитектур: − балансировка нагрузки; − клиент-серверные приложения; − настольные приложения; − EDA-архитектура; − PaaS-приложения; − SOA – архитектура; − Web-приложения. 3.7 Описание пользовательского интерфейса Главный экран приложения, представленный на Рисунок 24, состоит из 2 частей: основного меню программы и рабочей области. 74 Рисунок 24 – Главный экран приложения Главное меню приложения состоит из 4 пунктов: − файл; − проект; − редактировать; − справка. Меню «Файл», представленное на Рисунок 26, позволяет: − Создать новый проект с помощью кнопки «Новый проект». − Открыть для редактирования ранее созданный проект с помощью кнопки «Открыть». − Сохранить текущий проект с помощью кнопки «Сохранить». − Закрыть приложение с помощью кнопки «Выйти». Открытие и сохранение файлов происходит с помощью стандартной формы операционной системы Windows, представленной на Рисунок 25. 75 Рисунок 25 – Форма открытия и сохранения проекта Рисунок 26 – Меню "Файл" Меню «Проект» позволяет изменять текущий вид отображения данных: − Анкетирования – часть экспертной системы, в которой пользователь вводит данные о системе с помощью ответов на вопросы. Примеры экранов анкетирования представлена на рисункахРисунок 24,Рисунок 34,Рисунок 35. − Архитектура проекта – позволяет просматривать и редактировать выбранные технологии и архитектуры для каждого модуля и для информационной системы в целом. Пример отображения архитектуры проекта представлен на Рисунок 36. 76 − Пункт меню «Сгенерировать код» позволяет открыть дополнительный экран экспертной системы с набором автоматически сгенерированных шаблонов классов для текущего проекта. В приложении введено 2 ограничения на запуск автоматической генерации кода: − информация о каждом модуле анализируемой системы должна быть полной, т.е. определены все анализируемые технологии; − открыто не более 5 экранов автоматической генерации кода. Пример экрана автоматического генератора кода представлен на Рисунок 38. Рисунок 27 – Меню "Проект" Пункт меню «Редактировать» позволяет корректировать количество модулей в анализируемой системе и связи между ними. Подпункт «Добавить модуль» создает дополнительный модуль в системе, при этом пользователь видит на экране дополнительное окно, представленное на Рисунок 28, в которое необходимо ввести название нового модуля анализируемой системы. 77 Рисунок 28 – Добавить модуль Подпункт «Удалить модуль» позволяет убрать один модуль из анализируемой системы, при условии, что количество модулей в системе больше одного. Пример экрана удаления модуля представлен на Рисунок 29 и состоит из списка модулей анализируемой системы и 2 кнопок: удалить, которая удаляет выбранный модуль из анализа, отмена – возвращает пользователя на основной экран приложения. Рисунок 29 – Удалить модуль Подпункт «Редактировать связь» доступен только для анализа многомодульных систем и позволяет изменять параметры: флаг существования канала и необходимости передачи данных в режиме реального времени – для каждого канала связи анализируемой системы. Пример экрана редактирования каналов связи анализируемой системы представлен на Рисунок 30. 78 Рисунок 30 – Редактирования каналов Пример меню «Редактирование» представлен на Рисунок 31. Рисунок 31 – Меню "Редактировать" Меню «Справка», представленное на Рисунок 32, в текущей версии экспертной системы состоит из одного подпункта «О Программе», который позволяет пользователю просмотреть информацию о версии экспертной системы, разработчике и лицензии. Пример окна с информацией о программе представлен на Рисунок 33. 79 Рисунок 32 – Меню "Справка" Рисунок 33 – О программе Рисунок 34 – Вопрос с вариантами выбора ответа 80 В любой момент работы с приложением пользователь может видеть данные в одной из форм: анкетирование или архитектура проекта. Анкетирование – форма, состоящая из вопроса о анализируемой системе и вариантами ответа или полем для ввода. Данный режим доступен, если системе требуется уточнить значение атрибутов деревьев решений для выбора наиболее подходящих технологий. Если анкетирование закончено, т.е. у системы достаточно данных для выбора технологий, на экране появляется соответствующие предупреждение и экспертная система переходит в режим «Архитектура проекта». Примеры работы приложения в режиме «Анкетирование» представлены на рисункахРисунок 24,Рисунок 34 иРисунок 35. Рисунок 35 – Вопрос с вариантами выбора ответа "Да-Нет" Архитектура проекта – режим просмотра и редактирования подобранных технологий проекта. В данном режиме экран разделяется на 3 логические части: − Данные о системе в целом: название проекта и набор общих технологий для всех модулей анализируемой системы, например, отказоустойчивая технология для системы в целом, технология аутентификации и авторизации пользователей, протокол безопасной передачи данных. 81 − Данные о каждом модуле системе: архитектура, база данных, отказоустойчивая архитектура. Информация по одному модулю визуально отображается в виде пакета. Пользователь может выбрать отличную от решения экспертной системы технологию и зафиксировать ее с помощью флага Fix. В этом случае, экспертная система будет делать выбор технологий с учетом корректировок пользователя. − Информация о существующих каналах связи: данные о том, какие модули соединены между собой и какая архитектура канала выбрана. На экране представлено 3 кнопки: − Сохранить – позволяет сохранить зафиксированные технологии, выбранные пользователем, и повторно произвести расчет наиболее подходящих технологий с учетом внесенных коррекций. − Проверка связей – позволяет проверить, что в многомодульной системе каждый модуль связан хотя бы с одним другим и не существует обособленных групп модулей внутри анализируемой системы, т.е. на неориентированном графе модулей существует путь из каждого модуля в любой другой. − Сгенерировать код – открывает окно с автоматически сгенерированными классами анализируемой системы. Пример режима архитектура проекта представлен на рисункахРисунок 36 иРисунок 37. 82 Рисунок 36 – Пример отображения архитектуры проекта Рисунок 37 – Пример отображения архитектуры проекта для многомодульной системы 83 Окно автоматического генератора кода построено на вкладках. Для упрощения работы верхний уровень вкладок состоит из одноименных закладок модулям системы, для которых был автоматически сгенерирован код. Каждая вкладка модуля состоит из вкладок – классов, сгенерированных для данного модуля. Весь автоматически сгенерированный код можно сохранить в выбранной папке с помощью кнопки «Сохранить все файлы». Примеры экрана автоматической генерации рисункахРисунок 38 иРисунок 39. 84 кода представлены на Рисунок 38 – Генератор кода Рисунок 39 – Экран генератора кода для многомодульной системы 3.8 Пример работы программы В качестве анализа работы экспертной системы рассматриваются 3 примера: 85 − монолитное приложение; − трехмодульная система; − многомодульная система. 3.8.1 Монолитное приложение Например, необходимо разработать одномодульное приложение «Тест» со следующими параметрами: − Нагрузка системы: 1000 – 1 млн. запросов в секунду. − Только для личного использования. − Есть доступ к Интернет-сети во время работы приложения. − Требуется хранить данные в системе. − Не требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется аутентификация пользователей в системе. В этом случае экспертная система предлагает использовать: − SaaS – архитектуру с балансировкой нагрузки. − Встроенную базу данных. − Аварийное восстановление в качестве отказоустойчивой архитектуры. − Авторизация пользователей с помощью логина и использованием технологии хеширования. − Для передачи данных использовать https-протокол. Результат работы экспертной системы представлен на Рисунок 40. 86 пароля с Рисунок 40 – Результат работы экспертной системы для монолитного приложения 3.8.2 Трехмодульная система В качестве примера создается трехмодульная система «Бизнес» следующими атрибутами: − Требуется авторизация и аутентификация пользователей в системе. − Нет возможности написания собственного провайдера. − Использование аутентификации для разных систем (не только Web). К модулю 1 «Главный» предъявляются следующие требования: − Нагрузка системы: 1000 – 1 млн. запросов в секунду. − Предназначен для личного и коммерческого использования. − Есть доступ к Интернет-сети во время работы приложения. − Требуется хранить данные в системе. 87 со − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Не допустима потеря данных. − Предполагается большая связность данных. − Требуется постоянная синхронизация данных. − Есть ограничение ресурсов. − Бесплатное приложение. К модулю 2 «Отчетность» предъявляются требования: − Нагрузка системы: 100-1000 запросов в секунду. − Предназначен только для коммерческого использования. − Нет доступа к Интернет-сети во время работы приложения. − Требуется хранить данные в системе. − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Допустима потеря данных при сбоях. − Предполагается большая связность данных. − Нет ограничений ресурсов. − Требуется постоянная согласованность данных. − Выпускается под коммерческой лицензией. К модулю 3 «Дизайн» предъявляются такие требования, как: − Нагрузка системы: тысячи запросов в секунду. − Предназначен только для личного использования. − Есть доступ к Интернет-сети во время работы приложения. − Требуется хранить данные в системе. − Не требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Не требуется постоянная согласованность данных. − Существует ограничение ресурсов. 88 − Выпускается под коммерческой лицензией. Так же модуль «Главный» связан каналами с модулями «Отчетность» и «Дизайн». Связь «Главный» – «Отчетность» требует передачи данных в режиме реального времени, к каналу связи «Главный» – «Отчетность» такого требования не предъявляется. На основе указанных атрибутов экспертная система рекомендует использовать: − Для системы в целом: − LDAP технологию аутентификации и авторизации пользователей; − низкоуровневые сервисы отказоустойчивости; − https протокол для безопасной передачи данных. − Для модуля «Главный»: − SOA – архитектуру с балансировкой нагрузки; − строковую СУБД; − active-passive отказоустойчивую архитектуру. − Для модуля «Отчетность»: − SOA – архитектуру; − реляционную СУБД; − active-passive отказоустойчивую архитектуру. − Для модуля «Главный»: − SaaS – архитектуру; − строенную СУБД; − низкоуровневые сервисы отказоустойчивости. − Тип канала связи между модулями: IDE. Результат анализа экспертной системы представлен на Рисунок 41. Пример автоматически сгенерированного кода балансировки нагрузки для модуля «Дизайн» представлен в приложении В. 89 Рисунок 41 – Пример результата анализа трехмодульной системы 3.8.3 Многомодульная система В качестве примера создается серьезная корпоративная система «Предприятие», состоящая из 5 модулей, к которой предъявляются следующие требования: − Требуется авторизация и аутентификация пользователей в системе. − Есть возможности написания собственного провайдера. − Использование аутентификации для разных систем (не только Web). − Распространение всех модулей под коммерческой лицензией. − Ограничение Интернет-сети при работе с корпоративной системой. − Ограниченность ресурсов. К модулю 1 «Главный» предъявляются следующие требования: 90 − Нагрузка системы: миллионы запросов в секунду. − Требуется хранить данные в системе. − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Не допустима потеря данных. − Требуется большая масштабируемость данных. − Требуется постоянная синхронизация данных. К модулю 2 «Архив» предъявляются следующие требования: − Нагрузка системы: тысячи запросов в секунду. − Требуется хранить данные в системе. − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Не допустима потеря данных. − Требуется большая масштабируемость данных. − Требуется постоянная синхронизация данных. − Предполагается большая связность данных. К модулю 3 «Отдел кадров» предъявляются следующие требования: − Нагрузка системы: сотни запросов в секунду. − Требуется хранить данные в системе. − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Не допустима потеря данных. − Требуется большая масштабируемость данных. − Требуется постоянная синхронизация данных. К модулю 4 «Разработка» предъявляются следующие требования: − Нагрузка системы: тысячи запросов в секунду. − Требуется хранить данные в системе. 91 − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Не допустима потеря данных. − Требуется большая масштабируемость данных. К модулю 5 «Бухгалтерия» предъявляются следующие требования: − Нагрузка системы: тысячи запросов в секунду. − Требуется хранить данные в системе. − Требуется одновременный доступ к одним и тем же данным нескольких пользователей. − Требуется согласованность данных при сбоях. − Не допустима потеря данных. − Требуется постоянная синхронизация данных. − Предполагается большая связность данных. В системе предполагаются следующие каналы связи: − «Главный» – «Архив»; − «Главный» – «Отдел кадров»; − «Главный» – «Разработка»; − «Главный» – «Бухгалтерия»; − «Архив» – «Отдел кадров»; − «Архив» – «Разработка»; − «Архив» – «Бухгалтерия»; − «Отдел кадров» – «Разработка»; − «Отдел кадров» – «Бухгалтерия». Связь с модуль «Архив» происходит в режиме реального времени. Для наглядности граф каналов связей между модулями системы представлен на Рисунок 42. 92 Бухгалтерия Главный Архив Отдел кадров Разработка Рисунок 42 – Граф каналов связей между модулями системы В результате анализа экспертная система предлагает использовать следующие технологии: − Для системы в целом: − Использовать собственный провайдер аутентификации авторизации пользователей на основе SAMP стандарта; − низкоуровневые сервисы отказоустойчивости; − https протокол для безопасной передачи данных. − Для модуля «Главный»: − EDA – архитектуру с балансировкой нагрузки; − строковую СУБД; − active-passive отказоустойчивую архитектуру. 93 и − Для модуля «Архив»: − SOA – архитектуру с балансировкой нагрузки; − строковую СУБД; − active-passive отказоустойчивую архитектуру. − Для модуля «Отдел кадров»: − SOA– архитектуру; − строковую СУБД; − active-passive отказоустойчивую архитектуру. − Для модуля «Разработка»: − SOA – архитектуру; − строковую СУБД; − active-passive отказоустойчивую архитектуру. − Для модуля «Бухгалтерия»: − SOA – архитектуру с балансировкой нагрузки; − строковую СУБД; − active-passive отказоустойчивую архитектуру. − Для всех каналов связей в системе рекомендовано использовать IDE архитектуру. Результат анализа атрибутов экспертной системой представлен на Рисунок 43. 94 Рисунок 43 – Результат анализа атрибутов многомодульной системы Выводы по разделу 3 1. Для определения среды, в которой предполагается использовать экспертную систему автоматической генерации архитектурных шаблонов использована BPMN-нотация. 2. Экспертная система реализована на языке C# с использованием технологии WPF для реализации пользовательского интерфейса. Для хранения вопросов анкетирования пользователя и списков технологий используются файлы ресурсов, что позволяет редактировать текстовое содержание вопросов и поддерживать мультиязычность приложения без внесения изменений в код. Шаблоны программного кода хранятся в текстовых файлах, что также позволяет их редактировать отдельно прикладной реализации экспертной системы. 3. Логически структура экспертной системы разделена на 4 части: графический интерфейс, сбор и анализ данных о системе, генерация 95 шаблонов, мост. Физическая модель разрабатываемой системы представлена с помощью диаграмм классов. 4. Таким образом, разработанная экспертная система соответствует предъявляемым к ней требованиям: подбирает архитектуру и технологии для программных систем на основе нефункциональных требований и генерирует программные шаблоны на основе выбранных технологий. 96 ЗАКЛЮЧЕНИЕ В современном мире требования к программному обеспечению становятся все более и более сложными, так как растут пользовательские ожидания к новым продуктам и увеличивается конкуренция на рынке прикладных программ. Современные тенденции в разработке программного обеспечения заключаются в том, что приложения уходят в Интернет и становятся доступны миллионам пользователей через сеть или мобильные клиенты. Появляются новые технологии. В зависимости от решаемых задач и расчетной нагрузки архитектура программного продукта может быть существенно различной, а также может отличаться способ развертывания приложения, его обслуживания и администрирования. При создании новых приложений возникает вопрос какие технологии и программное обеспечение использовать. Таким образом, возникает задача разработки программных средств для поддержки принятия решений об используемых программным обеспечением архитектурах. В начале работы была поставлена цель разработать экспертную систему, решающую 2 задачи: 1. Подбор архитектуры проекта по спецификации требований. 2. Генерации шаблона проекта в соответствии с выбранной архитектурой. В рамках работы рассматриваются следующие технологии и архитектуры: − архитектура программных средств; − СУБД; − аутентификация и авторизация пользователей в системе; − отказоустойчивые архитектуры для системы в целом и каждого модуля в отдельности; − архитектуры каналов связей. Выбор наиболее подходящих архитектур и технологий экспертная система использует алгоритмы, основанные на анализе значений атрибутов и статичных деревьев решений. В общей сложности экспертная система использует 18 97 уникальных атрибутов, среди которых 3 атрибута используются для построения нескольких деревьев одновременно: − Критически недопустима потеря данных. − Согласованность данных. − Количество модулей в системе. Значение атрибута «Архитектура связываемых модулей» генерируется автоматически и не доступно для ввода пользователем. Для реализации функции автоматической генерации программных шаблонов в разрабатываемой системе используется гибридный алгоритм, основанных на преимуществах следующих подходов: − генерация текстов на основе шаблонов; − способ генерации кода, основанный на построении графа переходов и последовательности смены состояний; − метод подстановки с исполнением кода. Алгоритм состоит из следующих этапов: − получении формального описания программной системы на основе диаграммы пакетов; − выбор наиболее подходящего шаблона для каждого пакета на основе его характеристик; − генерация исходного кода с помощью метода подстановок порождающего программирования. Такой подход позволяет расширять возможности системы без переписывания основных алгоритмов работы, при этом требует сознания индивидуальных шаблонов тестов программ для каждого поддерживаемого языка программирования. Автоматическая генерация шаблонов классов осуществляется для следующих технологий: − балансировка нагрузки; − клиент-серверные приложения; − настольные приложения; − EDA-архитектура; 98 − PaaS-приложения; − SOA – архитектура; − Web-приложения. Таким образом, цель работы достигнута. Разработанная экспертная система может использоваться на этапе проектирования программных систем специалистами разного уровня. 99 СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 1. Мезенцев К.Н. Автоматизированные информационные системы : учебник для студ. учреждений сред. проф. образования. 4th ed. Москва: Издательский центр «Академия», 2013. 176 с. 2. Гаврилов. А.В. Автоматизированная система планирования и управления ITпроектами // ФГБОУ ВПО «Марийский государственный университет». 2014. 8 с. 3. Что такое архитектура программного обеспечения? [Электронный ресурс] // Developer Network: [сайт]. [2017]. URL: https://msdn.microsoft.com/ru-ru/ hh144976.aspx (дата обращения: 22.10.2017). 4. Львова И.В., Степанов П.А. 70-я международная студенческая научная конференция ГУАП // Автоматическая генерация шаблонов проектов на основе формальных требований. Санкт-Петербург. 2017. 3 с. 5. Львова И.В., Степанов П.А. Научной сессии ГУАП по кафедре 43 // Алгоритмы автоматической генерации шаблонов программных. СПб. 2018. 11 с. 6. Sybase. Что такое PowerDesigner // Компания Сайбейс. 2009. URL: https:// www.sybase.ru/system/files/pdf/2009_what_pd_v10.pdf (дата обращения: 17.02.2018). 7. Microsoft. Visio // Microsoft. 2018. URL: https://products.office.com/ru-ru/visio/visioscenarios (дата обращения: 17.02.2018). 8. IBM. Rational Rhapsody Developer // IBM. 2018. URL: https://www-03.ibm.com/ software/products/ru/ratirhap (дата обращения: 17.02.2018). 9. Молчанов Ю. Системное программное обеспечение. 3rd ed. СПБ: ПИТЕР, 2010. 400 с. 10. Елманова. Перенос приложений C++ Builder в архитектуру клиент/сервер // CITForum. 2015. URL: http://citforum.ru/programming/application/builder_cs3.shtml (дата обращения: 02.04.2017). 11. Software as a service [Электронный ресурс] // TADVISER: [сайт]. [2016]. URL: 100 http://www.tadviser.ru/index.php (дата обращения: 08.04.2017). 12. ОБЛАЧНЫЕ СЕРВИСЫ ИЛИ ЧТО ТАКОЕ IAAS? ОТЛИЧИЕ ОТ SAAS И PAAS [Электронный ресурс] // IT-Grad: [сайт]. [2014]. URL: http://www.it-grad.ru/ tsentr_kompetentsii/blog/33/ (дата обращения: 08.04.2017). 13. Обзор терминологии SOA: Часть 1. Сервис, архитектура, управление и бизнестермины [Электронный ресурс] // IBM DewelorWorks: [сайт]. [2008]. URL: https:// (дата www.ibm.com/developerworks/ru/library/ws-soa-term1/ обращения: 02.04.2017). 14. Владимир. Микросервисы (Microservices) [Электронный ресурс] // Хабрахабр: [сайт]. [2015]. URL: https://habrahabr.ru/post/249183/ (дата обращения: 08.04.2017). 15. Реляционная СУБД [Электронный ресурс] // tadviser: [сайт]. [2010]. URL: http:// tadviser.ru/a/53792 (дата обращения: 24.09.2017). 16. MongoDB, Inc. Introduction to MongoDB // MongoDB. URL: https:// docs.mongodb.com/manual/introduction/ (дата обращения: 13.05.2016). 17. Погружение в СУБД Apache Cassandra [Электронный ресурс] // IBM DeveloperWorks: [сайт]. [2013]. URL: https://www.ibm.com/developerworks/ru/ library/os-apache-cassandra/index.html (дата обращения: 24.09.2017). 18. Как устроена apache cassandra [Электронный ресурс] // habrahabr: [сайт]. [2012]. URL: https://habrahabr.ru/post/155115/ (дата обращения: 24.09.2017). 19. Технология единого входа [Электронный ресурс] // CryptoWiki: [сайт]. [2013]. URL: http://cryptowiki.net/index.php (дата обращения: 06.09.2017). 20. OASIS Security Services (SAML) TC [Электронный ресурс] // OASIS: [сайт]. [2017]. URL: https://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=security (дата обращения: 09.09.17). 21. Безопасность при авторизации на сайтах по OpenID [Электронный ресурс] // Хабрахабр: [сайт]. [2012]. URL: https://habrahabr.ru/post/142925/ (дата обращения: 05.06.2017). 101 22. Понятия и обзор LDAP [Электронный ресурс] // Pro-LDAP: [сайт]. [2015]. URL: http://pro-ldap.ru/tr/zytrax/ch2/ (дата обращения: 05.06.2017). 23. D. Hardt E. The OAuth 2.0 Authorization Framework. Microsoft, 2012. 24. Welcome to OpenID Connect [Электронный ресурс] // OpenID: [сайт]. [2017]. URL: http://openid.net/connect/ (дата обращения: 09.09.17). 25. GRIGORIK L. High Performance Browser Networking. O'Reilly Media, 2013. 400 с. 26. Принципы аутентификации по протоколу Kerberos [Электронный ресурс] // ITBand: [сайт]. [2010]. URL: http://itband.ru/2010/12/kerberos1/ (дата обращения: 06.06.2017). 27. Ньюмен С. Создание микросервисов. Спб: Питер, 2016. 304 с. 28. Y. Ting F.M.S.W.B.L.C.H.C. Implementation and evaluation of failsafe computercontrolled systems // Computers and Industrial Engineering - 26th International conference on computers and industrial engineering, Jun 2002. с. 401-415. 29. Построение отказоустойчивой (fault tolerant) системы [Электронный ресурс] // habrahabr: [сайт]. [2011]. URL: https://habrahabr.ru/post/118496/ (дата обращения: 17.09.2017). 30. REST Vs SOAP, The Difference Between Soap And Rest [Электронный ресурс] // spf13: [сайт]. [2010]. URL: http://spf13.com/post/soap-vs-rest/ (дата обращения: 21.10.2017). 31. Apache Kafka a distributed streaming platform [Электронный ресурс] // kafka.apache.org: [сайт]. [2016]. URL: https://kafka.apache.org/intro (дата обращения: 01.10.2017). 32. Introduction to Redis [Электронный ресурс] // Redis: [сайт]. [2017]. URL: https:// redis.io/topics/introduction (дата обращения: 21.10.2017). 33. Part 1: RabbitMQ for beginners - What is RabbitMQ? [Электронный ресурс] // cloudamqp: [сайт]. [2015]. URL: https://www.cloudamqp.com/blog/2015-05-18-part1rabbitmq-for-beginners-what-is-rabbitmq.html (дата обращения: 21.10.2017). 34. GSM - технология. [Электронный ресурс] // Образовательный портал о 102 технологиях мобильной связи: [сайт]. [2016]. URL: http://www.dom-spravka.info/ _mobilla/mi_gsm.html (дата обращения: 21.10.2017). 35. Ньюмен С. Создание микросервисов. СПб: Питер, 2016. 304 с. 36. Акобир Ш. Деревья решений — общие принципы работы // basegroup.ru. 2006. URL: (дата https://basegroup.ru/community/articles/description обращения: 26.03.2018). 37. Деревья решений и алгоритмы их построения // datareview. 2014. URL: http:// (дата datareview.info/article/derevya-resheniy-i-algoritmyi-ih-postroeniya/ обращения: 25.03.2018). 38. AlexPancho. Генератор текстов на основе патернов, Курочка Ряба и Звездные войны // habrahabr. 2012. URL: https://habrahabr.ru/post/163727/ (дата обращения: 29.03.2018). 39. Канжелев С.Ю., Шалыто А.А. Software Engineering Conference (Russia) – 2006 // Автоматическая генерация кода программ с явным выделением состояний. 2006. с. 60-63. 40. Айзенекер У., Чарнецки К. Порождающее программирование: методы, инструменты, применение. для профессионалов ed. СПб: Питер, 2005. 876 с. 41. Dalheimer M.K. A Comparison of Qt and Java 2012. URL: http:// turing.iimas.unam.mx/~elena/PDI-Lic/qt-vs-java-whitepaper.pdf (дата обращения: 2016.05.01). 42. Троелсен Э. Язык программирования С# 5.0 и платформа.NET 4.5. Москва – Санкт-Петербург – Киев: Apress, 2014. 1312 с. 43. Хетагуров Я.А. Проектирование автоматизированных систем обработки информации и управления (АСОИУ). Москва: БИНОМ, 2015. 644 с. 44. Microsoft Developer Network. Обзор проектирования архитектуры [Электронный ресурс] // Microsoft Developer Network: [сайт]. [2017]. URL: msdn.microsoft.com/ru-ru/hh144976.aspx (дата обращения: 02.04.2017). 103 https:// ПРИЛОЖЕНИЕ А Граф выбора архитектуры проекта Предполагемое количесто обрабатываемых запросов в секунду? 0 Десктопное приложение 10 - 100 Предполагемое количесто обрабатываемых запросов в секунду? Есть доступ к Интернетсети? Доступ к модулю свободный (не контролируется да лицензией)? >1 000 000 Предполагается использовать на производстве? да да нет >10 нет да Предполагемое количесто обрабатываемых запросов в секунду? 10 – 1 000 000 > 1 000 000 Доступ к модулю свободный (не контролируется лицензией)? SOA PaaS EDA да Предполагемое количесто обрабатываемых запросов в секунду? 10 - 100 Доступ к модулю свободный (не контролируется лицензией)? нет нет 100-1 000 000 Клиентсерверная архитектра 10 - 100 > 1 000 EDA Клиентсерверное приложение SOA Рисунок А.1 – Дерево выбора архитектуры проекта 104 SaaS PaaS Предполагемое количесто обрабатываемых запросов в секунду? 100-1 000 SOA > 1 000 000 да Web Предполагемое количесто обрабатываемых запросов в секунду? >1 000 000 10 - 100 100 – 1 000 000 SOA Есть доступ к Интернетсети? нет 100 – 1 000 000 Клиентсерверная архитектра нет EDA ПРИЛОЖЕНИЕ Б Карта кода экспертной системы Рисунок Б.1 – Карта кода экспертной системы 105 ПРИЛОЖЕНИЕ В Пример автоматически сгенерированного кода using System; using Eneter.Messaging.MessagingSystems.MessagingSystemBase; using Eneter.Messaging.MessagingSystems.TcpMessagingSystem; using Eneter.Messaging.Nodes.LoadBalancer; namespace Dizayn { class DizaynLoadBalanser { static void DizaynLoadBalanserMain(string[] args) { // Create TCP messaging for the communication with the client // and with services performing requests. IMessagingSystemFactory aMessaging = new TcpMessagingSystemFactory(); // Create load balancer. // It receives requests from the client and forwards them to available services // to balance the workload. ILoadBalancerFactory aLoadBalancerFactory = new RoundRobinBalancerFactory(aMessaging); ILoadBalancer aLoadBalancer = aLoadBalancerFactory.CreateLoadBalancer(); // Addresses of available services. string[] anAvailableServices = { 106 "tcp://127.0.0.1:8071/", "tcp://127.0.0.1:8072/", "tcp://127.0.0.1:8073/" }; // Add IP addresses of services to the load balancer. foreach (string anIpAddress in anAvailableServices) { aLoadBalancer.AddDuplexOutputChannel(anIpAddress); } // Create input channel that will listen to requests from clients. IDuplexInputChannel anInputChannel = aMessaging.CreateDuplexInputChannel("tcp://127.0.0.1:8060/"); // Attach the input channel to the load balancer and start listening. aLoadBalancer.AttachDuplexInputChannel(anInputChannel); Console.WriteLine("Load Balancer is running.\r\nPress ENTER to stop."); Console.ReadLine(); // Stop lisening. aLoadBalancer.DetachDuplexInputChannel(); } } } 107 ПРИЛОЖЕНИЕ Г Текст программы Г.1 Класс MainWindow using System; using System.Collections; using System.Collections.Generic; using System.Globalization; using System.Linq; using System.Text.RegularExpressions; using System.Windows; using System.Windows.Controls; namespace GenerateArhTemplates { /// <summary> /// Логика взаимодействия для MainWindow.xaml /// </summary> public partial class MainWindow : Window { static int codewindowsnumber; List<ModulPakageGrid> ModulGrids; void NewProjectInit() { codewindowsnumber = 0; StartQuestionGrid.Visibility = Visibility.Visible; SpecInterview.Visibility = RezultTextGrid.Visibility = Visibility.Hidden; Bridge.InitProgect(1); Init_Moduls(); } 108 public MainWindow() { InitializeComponent(); NewProjectInit(); SecuritycomboBox.ItemsSource = ChannelSecurity.ResourceManager.GetResourceSet( CultureInfo.CurrentCulture, true, true ).Cast<DictionaryEntry>().Select(a => a.Value.ToString()); AutentificationComboBox.ItemsSource = AutentificationTypes.ResourceManager.GetResourceSet( CultureInfo.CurrentCulture, true, true ).Cast<DictionaryEntry>().Select(a=>a.Value.ToString()); } private void Answer_Checked(object sender, RoutedEventArgs e) { if (Answer_v1.IsChecked.Value Answer_v3.IsChecked.Value || || Answer_v2.IsChecked.Value Answer_v4.IsChecked.Value Answer_v5.IsChecked.Value) ButtonNext.IsEnabled = true; else ButtonNext.IsEnabled = false; } private void Init_Question() { 109 || || Answer_v1.Visibility = Answer_v2.Visibility = Answer_v3.Visibility = Answer_v4.Visibility = Answer_v5.Visibility = Visibility.Visible; Answer_v1.IsChecked = Answer_v2.IsChecked = Answer_v3.IsChecked = Answer_v4.IsChecked = Answer_v5.IsChecked = false; ButtonNext.IsEnabled = false; string[] question = Bridge.InitQuestion(); if (question != null) { Question.Text = question[0]; Answer_v1.Content = question[1]; Answer_v2.Content = question[2]; Answer_v3.Content = question[3]; Answer_v4.Content = question[4]; Answer_v5.Content = question[5]; if (Answer_v3.Content.ToString().Length == 0) Answer_v3.Visibility = Answer_v4.Visibility = Answer_v5.Visibility = Visibility.Hidden; else if (Answer_v4.Content.ToString().Length == 0) Answer_v4.Visibility = Answer_v5.Visibility = Visibility.Hidden; else if (Answer_v5.Content.ToString().Length == 0) Answer_v5.Visibility = Visibility.Hidden; } else { ResultRecomdstions(); string message = "Анкетирование закончено."; string caption = "Анкетирование"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } 110 } void ResultRecomdstions() { StartQuestionGrid.Visibility = SpecInterview.Visibility = Visibility.Hidden; RezultTextGrid.Visibility = Visibility.Visible; SystemNameTextBox.Text = SystemInfo.Name; TotalToleranceLable.Content = SystemInfo.TotalFaultTolerance; } private void Init_Moduls() { AnswerBox.Text = ""; string question= Bridge.StartQuestion(); if(question != "") StartQuestion.Text = question; else { StartQuestionGrid.Visibility = Visibility.Hidden; SpecInterview.Visibility = Visibility.Visible; ButtonNext.IsEnabled = false; Bridge.ResetModul(); Init_Question(); } } private int AnswerCheck() { if (Answer_v1.IsChecked == true) return 1; else if (Answer_v2.IsChecked == true) return 2; else if (Answer_v3.IsChecked == true) 111 return 3; else if (Answer_v4.IsChecked == true) return 4; else return 5; } private void ButtonNext_Click(object sender, RoutedEventArgs e) { int answer = AnswerCheck(); Bridge.CheckAnswers(Question.Text, answer); Init_Question(); } private void NextStartButton_Click(object sender, RoutedEventArgs e) { Bridge.NextStart(AnswerBox.Text); Init_Moduls(); } readonly Regex GetNotDigits = new Regex(@"[^\d]+"); private void AnswerBox_TextChanged(object sender, TextChangedEventArgs e) { if (StartQuestion.Text == Bridge.StartQuestion()) AnswerBox.Text = GetNotDigits.Replace(AnswerBox.Text, ""); if (AnswerBox.Text.Length == 0) NextStartButton.IsEnabled = false; else NextStartButton.IsEnabled = Bridge.CheckModulName(AnswerBox.Text); 112 } private void NewProject_Click(object sender, RoutedEventArgs e) { NewProjectInit(); } private void ExitItem_Click(object sender, RoutedEventArgs e) { string text = "Выйти из программы?"; const string caption = "Выйти из программы"; var result = MessageBox.Show(text, caption, MessageBoxButton.YesNo, MessageBoxImage.Information); if (result == MessageBoxResult.Yes) this.Close(); } private void AboutItem_Click(object sender, RoutedEventArgs e) { string text = "Автоматическая система генерации шаблонов\n © 2017-" + DateTime.Today.Year.ToString() + " Ирина Львова\nВерсия: тестовая 1.0.5\nЛицензия: свободная"; const string caption = "О программе"; MessageBox.Show(text, caption, MessageBoxButton.OK, MessageBoxImage.Information); } private void menuArhitecture_Click(object sender, RoutedEventArgs e) { if (SystemInfo.Moduls.Count > 0) 113 { ResultRecomdstions(); } else { string message = "К сожалению, не получилось сгенерировать архитектуру проекта - недостаточно данных. Пройдите анкетирование и попробуйте еще раз."; string caption = "Архитектура проекта"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void RezultTextGrid_IsVisibleChanged(object sender, DependencyPropertyChangedEventArgs e) { if (RezultTextGrid.Visibility == Visibility.Visible) { ChannesInfoTextbox.Text = SystemInfo.ChannelsInfo(); menuArhitecture.IsEnabled = false; AutentificationComboBox.SelectedValue SystemInfo.AutentificationType; SecuritycomboBox.SelectedValue = SystemInfo.Security; ModulGrids = new List<ModulPakageGrid>(); for (int i = 0; i < SystemInfo.Moduls.Count; i++) { ModulGrids.Add(new ModulPakageGrid(i)); PakageGrid.Children.Add(ModulGrids[i].ModulGrid); } 114 = } else menuArhitecture.IsEnabled = true; button_codeGenerate.IsEnabled = Bridge.CheckAvalibleCodeGeneration(); } private void SpecInterview_IsVisibleChanged(object sender, DependencyPropertyChangedEventArgs e) { if (SpecInterview.Visibility == Visibility.Visible || RezultTextGrid.Visibility = StartQuestionGrid.Visibility == Visibility.Visible) menuAnketa.IsEnabled = false; else menuAnketa.IsEnabled = true; } void Anketa() { foreach (Modul mod in SystemInfo.Moduls) { if (mod.Name == "") { SpecInterview.Visibility = Visibility.Hidden; StartQuestionGrid.Visibility = Visibility.Visible; Init_Moduls(); return; } } RezultTextGrid.Visibility = Visibility.Hidden; 115 StartQuestionGrid.Visibility = SpecInterview.Visibility = Visibility.Visible; ButtonNext.IsEnabled = false; Bridge.ResetModul(); Init_Question(); } void menuAnketa_Click(object sender, RoutedEventArgs e) { Anketa(); } private void button_codeGenerate_Click(object sender, RoutedEventArgs e) { OpenCodeWindow(); } void OpenCodeWindow() { if (codewindowsnumber < 5) { var code = new СodeList(); code.Show(); codewindowsnumber++; } else { string message = "Открыто слишком много окон с кодом. Закроте некоторые из них и попробуйте еще раз."; string caption = "Генерация кода"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } 116 } private void SystemNameTextBox_TextChanged(object sender, TextChangedEventArgs e) { SystemInfo.Name = SystemNameTextBox.Text; } private void SaveSystemButton_Click(object sender, RoutedEventArgs e) { if ((SystemNameTextBox.Text.Length > 0) && UserChanges.CheckChanges(ModulGrids)) { SystemInfo.Name = SystemNameTextBox.Text; if (AutentificationComboBox.SelectedItem == null) SystemInfo.AutentificationType = ""; else SystemInfo.AutentificationType AutentificationComboBox.SelectedValue.ToString(); SystemInfo.Security = SecuritycomboBox.SelectedValue.ToString(); UserChanges.SaveArhChanges(ModulGrids); string message = "Данные сохранены!"; string caption = "Сохранение архетиктуры"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } else { 117 = string message = "Сохранение невозможно! Проверьте, что все модули имеют уникальные имена!"; string caption = "Сохранение архетиктуры"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void AddNewModulItem_Click(object sender, RoutedEventArgs e) { AddNewModul newmodul = new AddNewModul(); newmodul.Show(); } private void DelModulItem_Click(object sender, RoutedEventArgs e) { if (SystemInfo.Moduls.Count > 1) { DeleteModul delmodul = new DeleteModul(); delmodul.Show(); } else { string message = "Нельзя удалить единственный модуль в системе!"; string caption = "Удаление модуля"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } 118 private void Checkbutton_Click(object sender, RoutedEventArgs e) { if (SystemInfo.Moduls.Count < 2) { string message = "Система не предполагает межмодульных связей!"; string caption = "Проверка связей"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } else if ((SystemNameTextBox.Text.Length > 0) && UserChanges.CheckChanges(ModulGrids)) { string text = ""; foreach (var mod in SystemInfo.Moduls) { if (!SystemInfo.Channels.Any(a => a.IsChannel == true && (a.modul1.Name == mod.Name || a.modul2.Name == mod.Name))) text = text + $"\nМодуль {mod.Name} не соединен с остальной системой!"; } if (text.Length == 0) text = "Архитектура корректна!"; string caption = "Проверка связей"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(text, caption, buttons); } else 119 { string message = "Проверка невозможна! Проверьте, что все модули имеют уникальные имена!"; string caption = "Проверка связей"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void CreateChannelItem_Click(object sender, RoutedEventArgs e) { if (SystemInfo.Moduls.Count > 1) { GenerateChannel ch = new GenerateChannel(); ch.Show(); } else { string message = "Одномодульная система не предполагает каналов связей!"; string caption = "Редактирование связей"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void menuCode_Click(object sender, RoutedEventArgs e) { if(Bridge.CheckAvalibleCodeGeneration()) { 120 OpenCodeWindow(); } else { string message = "К сожалению, не получилось сгенерировать код проекта - недостаточно данных. Пройдите анкетирование и попробуйте еще раз."; string caption = "Генерация кода"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void Window_Activated(object sender, EventArgs e) { if (!Bridge.CheckNewStart()) { SystemInfo.Reculc(); if (RezultTextGrid.Visibility == Visibility.Visible) { ChannesInfoTextbox.Text = SystemInfo.ChannelsInfo(); menuArhitecture.IsEnabled = false; AutentificationComboBox.SelectedValue SystemInfo.AutentificationType; SecuritycomboBox.SelectedValue = SystemInfo.Security; ModulGrids = new List<ModulPakageGrid>(); for (int i = 0; i < SystemInfo.Moduls.Count; i++) { ModulGrids.Add(new ModulPakageGrid(i)); PakageGrid.Children.Add(ModulGrids[i].ModulGrid); } 121 = } else { string question = Bridge.StartQuestion(); if (question != "") StartQuestion.Text = question; else { StartQuestionGrid.Visibility = Visibility.Hidden; SpecInterview.Visibility = Visibility.Visible; ButtonNext.IsEnabled = false; Bridge.ResetModul(); Init_Question(); } } } } private void AnswerBox_IsVisibleChanged(object DependencyPropertyChangedEventArgs e) { AnswerBox.Text = ""; } private void SaveItem_Click(object sender, RoutedEventArgs e) { bool? rez = Bridge.SaveProject(); if (rez!= null) { 122 sender, string caption = "Сохранение"; string message; if (rez==true) message = "Проект успешно сохранен!"; else message = "Во время сохранения произошла ошибка!"; MessageBoxButton buttons = MessageBoxButton.OK; MessageBox.Show(message, caption, buttons); } } private void OpenItem_Click(object sender, RoutedEventArgs e) { string file = FoldersWork.OpenProject(); if (file != "") { Bridge.OpenProject(file); Anketa(); } } } } Г.2 Класс Interview namespace GenerateArhTemplates { 123 class Interview { public string[] Question(int modul) { string[] question = null; if (SystemInfo.Moduls[modul].ArhStyle == "" && !SystemInfo.Moduls[modul].fixArhStyle) { if (SystemInfo.Moduls[modul].load == -1) question = QuestionLoad(); else if (SystemInfo.Moduls[modul].businessFlag == null) question = QuestionBusiness(); else if (SystemInfo.Moduls[modul].internetFlag == null) question = QuestionInternet(); else if (SystemInfo.Moduls[modul].isFree == null) question = QuestionFree(); } else if (SystemInfo.Moduls[modul].DBtype == "" && !SystemInfo.Moduls[modul].fixDBtype && SystemInfo.Moduls[modul].useDB != false) { if (SystemInfo.Moduls[modul].useDB == null) question = QuestionData(); else if (SystemInfo.Moduls[modul].MultiUser == null) question = QuestionMultiUser(); else if (SystemInfo.Moduls[modul].scaleDB == null) question = QuestionScaleData(); else if (SystemInfo.Moduls[modul].loseDataFlag == null) question = QuestionLoseData(); else if (SystemInfo.Moduls[modul].cohesionData == null) 124 question = QuestionCohesion(); else if (SystemInfo.Moduls[modul].coherenceData == null) question = QuestionCoherence(); } else if (!SystemInfo.Moduls[modul].fixFaultTol && SystemInfo.Moduls[modul].faultTol=="") { if (SystemInfo.Moduls[modul].limitResourse == null) question = QuestionLimitedResourses(); else if (SystemInfo.Moduls[modul].synhFlag == null) question = QuestionSynhronose(); } else if (modul == SystemInfo.Moduls.Count - 1) { if (SystemInfo.IsAutentification == null) { question = QuestionIsAutentification(); return question; } else if (SystemInfo.IsAutentification == true && !SystemInfo.FixAutentification && SystemInfo.AutentificationType.Length == 0 && SystemInfo.OnlyWebflag == null) { question = QuestionOnlyWebAutentification(); return question; } else if (SystemInfo.IsAutentification == true && !SystemInfo.FixAutentification && SystemInfo.AutentificationType.Length == 0 && SystemInfo.OnlyWebflag != null) { 125 question = QuestionOwnProvider(); return question; } else if (SystemInfo.Moduls.Count > 1) { for (int i = 0; i < SystemInfo.Channels.Count; i++) { if (SystemInfo.Channels[i].IsChannel == null) { question = QuestionIsChannel(SystemInfo.Channels[i].modul1, SystemInfo.Channels[i].modul2); return question; } else if (SystemInfo.Channels[i].IsChannel==true && SystemInfo.Channels[i].type=="" && SystemInfo.Channels[i].IsRealTime==null ) { question = QuestionIsRealTime(SystemInfo.Channels[i].modul1, SystemInfo.Channels[i].modul2); return question; } } } else return null; } if (question!=null) question[0] = AppString(SystemInfo.Moduls[modul].Name) +question[0]; return question; } public string StartQuestion() 126 { return Questions.StartQuestion; } public string SystemNameQuestion() { return Questions.SystemNameQuestion; } public string NameQuestion(int modul) { return Questions.ModullNameQuestion +' '+ (modul+1).ToString() + ':'; } string[] QuestionYesNo(string quest) { string[] question = new string[6]; question[0] = quest; question[1] = "Да"; question[2] = "Нет"; question[3] = ""; question[4] = ""; question[5] = ""; return question; } string[] QuestionLoad() { string[] question = new string[6]; question[0] = Questions.LoadQuestion; question[1] = "0"; question[2] = "10-100"; question[3] = "100-1 000"; question[4] = "1 000-1 000 000"; 127 question[5] = ">1 000 000"; return question; } string[] QuestionData() { return QuestionYesNo( Questions.DataQuestion); } string[] QuestionBusiness() { return QuestionYesNo(Questions.BusinessQuestion); } string[] QuestionInternet() { return QuestionYesNo(Questions.InternetQuestion); } string[] QuestionFree() { return QuestionYesNo(Questions.FreeQuestion); } string[] QuestionLimitedResourses() { return QuestionYesNo(Questions.LimitedResourseQuestion); } string[] QuestionMultiUser() { return QuestionYesNo(Questions.MultiUserQuestion); } string[] QuestionScaleData() { return QuestionYesNo(Questions.ScaleQuestion); 128 } string[] QuestionIsAutentification() { return QuestionYesNo( Questions.IsAutentification); } string[] QuestionLoseData() { return QuestionYesNo(Questions.DataSaveQuestion); } string[] QuestionCohesion() { return QuestionYesNo(Questions.CohesionQuestion); } string[] QuestionCoherence() { return QuestionYesNo(Questions.CoherenceQuestion); } string[] QuestionOnlyWebAutentification() { return QuestionYesNo(Questions.OnlyWebAutentification); } string[] QuestionOwnProvider() { return QuestionYesNo(Questions.OwnProvider); } string[] QuestionSynhronose() { return QuestionYesNo(Questions.SynchronizationQuestion); } 129 string [] QuestionIsChannel(Modul mod1, Modul mod2) { string str = Questions.IsChannel +' '+ mod1.Name + ' ' + Questions.And + ' ' + mod2.Name + '?'; return QuestionYesNo(str); } string [] QuestionIsRealTime(Modul mod1, Modul mod2) { string str = Questions.IsRealTime + ' ' + mod1.Name + ' ' + Questions.And + ' ' + mod2.Name + '?'; return QuestionYesNo(str); } public static string AppString(string name) { if (SystemInfo.Moduls.Count == 1) return ""; else return "Для модуля " + name + ": "; } } } Г.3 Класс CheckAnswer using System.Linq; namespace GenerateArhTemplates 130 { static class CheckAnswer { public static Modul Check(string question, int answer, Modul modul) { if (question == Interview.AppString(modul.Name) + Questions.LoadQuestion) { switch (answer) { case 1: modul.load = 0; modul.ArhStyle = ArhitectureStyles.Desktop; break; case 2: modul.load = 10; break; case 3: modul.load = 100; break; case 4: modul.load = 1000; break; case 5: modul.load = 1000000; break; } } else if (question == Interview.AppString(modul.Name) + Interview.AppString(modul.Name) + Questions.InternetQuestion) { if (answer == 1) modul.internetFlag = true; else modul.internetFlag = false; } else if (question == Questions.BusinessQuestion) 131 { if (answer == 1) modul.businessFlag = true; else modul.businessFlag = false; } else if (question == Interview.AppString(modul.Name) + == Interview.AppString(modul.Name) + Interview.AppString(modul.Name) + Questions.DataQuestion) { if (answer == 1) modul.useDB = true; else { modul.useDB = false; } } else if (question Questions.MultiUserQuestion) { if (answer == 1) modul.MultiUser = true; else { modul.MultiUser = false; modul.DBtype = DB.BuiltIn; } } else if (question == Questions.FreeQuestion) 132 { if (answer == 1) { if (modul.businessFlag == true || modul.internetFlag == false) { if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.ClientServer; else if (modul.load < 1000000) modul.ArhStyle = ArhitectureStyles.SOA; else if (modul.internetFlag == true) modul.ArhStyle = ArhitectureStyles.PaaS; else modul.ArhStyle = ArhitectureStyles.EDA; } else { if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.Web; else if (modul.load<=100000) modul.ArhStyle = ArhitectureStyles.SaaS; else modul.ArhStyle = ArhitectureStyles.PaaS; } } else { if (modul.businessFlag == true) { if (modul.load < 1000000) 133 modul.ArhStyle = ArhitectureStyles.SOA; else modul.ArhStyle = ArhitectureStyles.EDA; } else { if (modul.internetFlag == true) { if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.Web; else modul.ArhStyle = ArhitectureStyles.SaaS; } else if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.ClientServer; else if (modul.load <= 1000) modul.ArhStyle = ArhitectureStyles.SOA; else modul.ArhStyle = ArhitectureStyles.EDA; } } if (modul.ArhStyle != "" && modul.load >= 1000) { modul.ArhStyle = modul.ArhStyle; modul.useBalanser = true; } } else if (question == Interview.AppString(modul.Name) Questions.ScaleQuestion) { 134 + if (answer == 1) modul.scaleDB = true; else { modul.scaleDB = false; } } else if (question == Interview.AppString(modul.Name) + Questions.DataSaveQuestion) { if (answer == 1) { modul.loseDataFlag = true; modul.DBtype = DB.StringDb; } else { modul.loseDataFlag = false; } } else if (question == Interview.AppString(modul.Name) Questions.CohesionQuestion) { if (answer == 1 && modul.scaleDB == false) { modul.cohesionData = true; modul.DBtype = DB.Relasion; } else if (answer == 2 && modul.scaleDB == false) 135 + modul.cohesionData = false; else if (answer == 2 && modul.scaleDB == true) { modul.cohesionData = false; modul.DBtype = DB.Docum; } else if (answer == 2) modul.cohesionData = false; else modul.cohesionData = true; } else if (question == Interview.AppString(modul.Name) + Questions.CoherenceQuestion) { if (answer == 1) { modul.coherenceData = true; modul.DBtype = DB.StringDb; } else { modul.coherenceData = false; if (modul.scaleDB == true) modul.DBtype = DB.Docum; else modul.DBtype = DB.Relasion; } } else if (question == Interview.AppString(modul.Name) Questions.LimitedResourseQuestion) 136 + { if (answer == 1) modul.limitResourse = true; else modul.limitResourse = false; } else if (question == Interview.AppString(modul.Name) Questions.SynchronizationQuestion) { if (answer == 1) modul.synhFlag = true; else modul.synhFlag = false; if (SystemInfo.Moduls.Count == 1) modul.faultTol = FaultTolerancesStyle.DisasterRecovery; else if (modul.loseDataFlag == true && modul.limitResourse == false) modul.faultTol = FaultTolerancesStyle.ActiveActive; else if (modul.loseDataFlag == true) modul.faultTol = FaultTolerancesStyle.ActivePassive; else if (modul.synhFlag == true) modul.faultTol = FaultTolerancesStyle.Balancer; else modul.faultTol = FaultTolerancesStyle.LowService; } else if (question == Questions.IsAutentification) { if (answer == 1) { SystemInfo.IsAutentification = true; 137 + if (SystemInfo.Moduls.Count == 1) SystemInfo.AutentificationType = AutentificationTypes.Simple; } else SystemInfo.IsAutentification = false; } else if (question == Questions.OnlyWebAutentification) { if (answer == 1) SystemInfo.OnlyWebflag = true; else SystemInfo.OnlyWebflag = false; } else if (question == Questions.OwnProvider) { if (answer == 1 && SystemInfo.OnlyWebflag == true) SystemInfo.AutentificationType = AutentificationTypes.OpenId; else if (answer == 1 && SystemInfo.OnlyWebflag == false) SystemInfo.AutentificationType = AutentificationTypes.SAMP; else if (SystemInfo.OnlyWebflag == true) SystemInfo.AutentificationType = AutentificationTypes.OpenIDConnect; else SystemInfo.AutentificationType = AutentificationTypes.LDAP; } else if (question.Length > Questions.IsChannel.Length question.Substring(0, Questions.IsChannel.Length) == Questions.IsChannel) { int channelnumber = ChannelNumber(question, Questions.IsChannel); 138 && Channel channel = SystemInfo.Channels[channelnumber]; if (answer == 1) { SystemInfo.Channels[channelnumber].IsChannel = true; if (channel.modul1.ArhStyle == ArhitectureStyles.EDA || channel.modul1.ArhStyle == ArhitectureStyles.SOA || channel.modul2.ArhStyle == ArhitectureStyles.SOA || channel.modul2.ArhStyle == ArhitectureStyles.EDA) SystemInfo.Channels[channelnumber].type = TypesOfChannel.EDI; } else SystemInfo.Channels[channelnumber].IsChannel = false; } else if (question.Length > Questions.IsRealTime.Length && question.Substring(0, Questions.IsRealTime.Length) == Questions.IsRealTime) { int channelnumber = ChannelNumber(question,Questions.IsRealTime); if (answer == 1) { SystemInfo.Channels[channelnumber].IsRealTime = true; SystemInfo.Channels[channelnumber].type = TypesOfChannel.WebSocket; } else { SystemInfo.Channels[channelnumber].IsRealTime = false; SystemInfo.Channels[channelnumber].type TypesOfChannel.WebAPI; } } 139 = return modul; } static int ChannelNumber(string question, string tempquestion) { int channelnumber = -1; string modname1, modname2; modname1 = modname2 = question.Remove(0, tempquestion.Length + 1); modname1 = modname2 = modname2.Remove(modname2.Length - 1); for (int i = 0; i < SystemInfo.Channels.Count(); i++) { if (SystemInfo.Channels[i].modul1.Name.Length < modname1.Length && SystemInfo.Channels[i].modul1.Name == modname1.Substring(0, SystemInfo.Channels[i].modul1.Name.Length)) if (modname2.Remove(0, SystemInfo.Channels[i].modul1.Name.Length + SystemInfo.Channels[i].modul2.Name) { channelnumber = i; break; } } return channelnumber; } } } 140 Questions.And.Length + 2) == Г.4 Класс SystemInfo using System.Collections.Generic; namespace GenerateArhTemplates { static class SystemInfo { static public List<Modul> Moduls { set; get; } static public List<Channel> Channels { set; get; } static public bool FixAutentification { set; get; } static public bool? IsAutentification { set; get; } static public string AutentificationType { get; set; } static public string TotalFaultTolerance { set; get; } public static bool? OnlyWebflag { get; set; } public static string Name { get; set; } = ""; public static string Security { get; set; } static public void Reculc() { for (int i = 0; i < Moduls.Count; i++) { var modul = Moduls[i]; if((Security == "") ||(Security == ChannelSecurity.Https)) if ((Moduls.Count == 1) && (IsAutentification == false) && Moduls[0].useDB == false) Security = ""; else Security = ChannelSecurity.Https; 141 if (modul.useDB == true && modul.fixDBtype != true) { if (modul.MultiUser == false) modul.DBtype = DB.BuiltIn; else if (modul.loseDataFlag == true) { modul.DBtype = DB.StringDb; } else if (modul.cohesionData == true) modul.DBtype = DB.Relasion; else if (modul.cohesionData == false && modul.scaleDB == false) modul.cohesionData = false; else if (modul.cohesionData == false && modul.scaleDB == true) modul.DBtype = DB.Docum; else modul.DBtype = ""; } else if (modul.fixDBtype != true) modul.DBtype = ""; if (modul.fixArhStyle != true) { if (modul.load == 0) modul.ArhStyle = ArhitectureStyles.Desktop; else if (modul.isFree == true) { if (modul.businessFlag == true || modul.internetFlag == false) { 142 if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.ClientServer; else if (modul.load < 1000000) modul.ArhStyle = ArhitectureStyles.SOA; else if (modul.internetFlag == true) modul.ArhStyle = ArhitectureStyles.PaaS; else modul.ArhStyle = ArhitectureStyles.EDA; } else { if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.Web; else if (modul.load <= 100000) modul.ArhStyle = ArhitectureStyles.SaaS; else modul.ArhStyle = ArhitectureStyles.PaaS; } } else if (modul.businessFlag == true) { if (modul.load < 1000000) modul.ArhStyle = ArhitectureStyles.SOA; else modul.ArhStyle = ArhitectureStyles.EDA; } else { if (modul.internetFlag == true) 143 { if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.Web; else modul.ArhStyle = ArhitectureStyles.SaaS; } else if (modul.load <= 100) modul.ArhStyle = ArhitectureStyles.ClientServer; else if (modul.load <= 1000) modul.ArhStyle = ArhitectureStyles.SOA; else modul.ArhStyle = ArhitectureStyles.EDA; } if (modul.load >= 1000) modul.useBalanser = true; else modul.useBalanser = false; if (SystemInfo.Moduls.Count == 1) modul.faultTol = FaultTolerancesStyle.DisasterRecovery; else if (modul.loseDataFlag == true && modul.limitResourse == false) modul.faultTol = FaultTolerancesStyle.ActiveActive; else if (modul.loseDataFlag == true) modul.faultTol = FaultTolerancesStyle.ActivePassive; else if (modul.synhFlag == true) modul.faultTol = FaultTolerancesStyle.Balancer; else modul.faultTol = FaultTolerancesStyle.LowService; Moduls[i] = modul; } 144 } if (Moduls.Count > 1) TotalFaultTolerance = FaultTolerancesStyle.LowService; else TotalFaultTolerance = Moduls[0].faultTol = FaultTolerancesStyle.DisasterRecovery; for (int i = 0; i < Channels.Count; i++) { if ((SystemInfo.Channels[i].IsChannel == true) && (Channels[i].modul1.ArhStyle == ArhitectureStyles.EDA || Channels[i].modul1.ArhStyle == ArhitectureStyles.SOA || Channels[i].modul2.ArhStyle == ArhitectureStyles.SOA || Channels[i].modul2.ArhStyle == ArhitectureStyles.EDA)) SystemInfo.Channels[i].type = TypesOfChannel.EDI; else if (Channels[i].IsRealTime == true) SystemInfo.Channels[i].type = TypesOfChannel.WebSocket; else SystemInfo.Channels[i].type = TypesOfChannel.WebAPI; } } 145 static public void InitSystem(int num) { Security = ChannelSecurity.Https; FixAutentification = false; IsAutentification = null; AutentificationType = ""; OnlyWebflag = null; Moduls = new List<Modul>(); Channels = new List<Channel>(); for (int i = 0; i < num; i++) Moduls.Add(new Modul()); if (num > 1) { TotalFaultTolerance = FaultTolerancesStyle.LowService; ChannelsInit(); } else TotalFaultTolerance = Moduls[0].faultTol = FaultTolerancesStyle.DisasterRecovery; } static public void ChannelsInit() { int channum = SpecMath.ChannalsNumber(Moduls.Count); List<int[]> list = SpecMath.ModulCombinations(Moduls.Count); for (int i = 0; i < list.Count; i++) Channels.Add(new Channel(Moduls[list[i][0] - 1], Moduls[list[i][1] - 1], i)); } 146 static public string ChannelsInfo() { string rez = ""; for (int i = 0; i < Channels.Count; i++) if (Channels[i].IsChannel == true) rez = rez + "Тип канала связи между модулями " + Channels[i].modul1.Name + " и " + Channels[i].modul2.Name + ": " + Channels[i].type + "\n"; return rez; } } } Г.5 Класс ProjectParsing using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace GenerateArhTemplates.CodeGeneration { public static class ProjectParsing { public static List<string> SaveAll() { List<string> projectinfo = new List<string>(); projectinfo.Add("System Name: " + SystemInfo.Name + ";\n"); projectinfo.Add("AutentificationType: " + SystemInfo.AutentificationType + ";\n"); 147 projectinfo.Add("Moduls: " + SystemInfo.Moduls.Count + ";\n"); projectinfo.Add("Channels: " + SystemInfo.Channels.Count + ";\n\n"); for (int i = 0; i < SystemInfo.Moduls.Count; i++) { projectinfo.Add("Modul Name: " + SystemInfo.Moduls[i].Name + ";\n"); projectinfo.Add("Modul ArhStyle: " + SystemInfo.Moduls[i].ArhStyle + ";\n"); projectinfo.Add("Modul businessFlag: " + " + " + SystemInfo.Moduls[i].businessFlag.ToString() + ";\n"); projectinfo.Add("Modul coherenceData: SystemInfo.Moduls[i].coherenceData.ToString() + ";\n"); projectinfo.Add("Modul cohesionData: SystemInfo.Moduls[i].cohesionData.ToString() + ";\n"); projectinfo.Add("Modul DBtype: " + SystemInfo.Moduls[i].DBtype + ";\n"); projectinfo.Add("Modul faultTol: " + SystemInfo.Moduls[i].faultTol + ";\n"); projectinfo.Add("Modul fixArhStyl: " + " + " + " + SystemInfo.Moduls[i].fixArhStyle.ToString() + ";\n"); projectinfo.Add("Modul fixDBtype: SystemInfo.Moduls[i].fixDBtype.ToString() + ";\n"); projectinfo.Add("Modul fixFaultTol: SystemInfo.Moduls[i].fixFaultTol.ToString() + ";\n"); projectinfo.Add("Modul internetFlag: SystemInfo.Moduls[i].internetFlag.ToString() + ";\n"); projectinfo.Add("Modul isFree: " + SystemInfo.Moduls[i].isFree.ToString() + ";\n"); projectinfo.Add("Modul limitResourse: SystemInfo.Moduls[i].limitResourse.ToString() + ";\n"); 148 " + projectinfo.Add("Modul load: " + SystemInfo.Moduls[i].load.ToString() + ";\n"); projectinfo.Add("Modul loseDataFlag: " + SystemInfo.Moduls[i].loseDataFlag.ToString() + ";\n"); projectinfo.Add("Modul MultiUser: " + scaleDB: " + synhFlag: " + SystemInfo.Moduls[i].MultiUser.ToString() + ";\n"); projectinfo.Add("Modul SystemInfo.Moduls[i].scaleDB.ToString() + ";\n"); projectinfo.Add("Modul SystemInfo.Moduls[i].synhFlag.ToString() + ";\n"); projectinfo.Add("Modul useBalanser: " + SystemInfo.Moduls[i].useBalanser.ToString() + ";\n"); projectinfo.Add("Modul useDB: " + SystemInfo.Moduls[i].useDB.ToString() + ";\n\n"); } for (int i = 0; i < SystemInfo.Channels.Count; i++) { projectinfo.Add("Channel: " + SystemInfo.Channels[i].number.ToString() + "\n"); projectinfo.Add("Modul 1: " + SystemInfo.Channels[i].modul1.Name + ";\n"); projectinfo.Add("Modul 2: " + SystemInfo.Channels[i].modul2.Name + ";\n"); projectinfo.Add("IsChannel: " + SystemInfo.Channels[i].IsChannel + ";\n"); projectinfo.Add("IsRealTime: " + SystemInfo.Channels[i].IsRealTime + ";\n"); projectinfo.Add("Type: " + SystemInfo.Channels[i].type + ";\n\n"); } 149 return projectinfo; } public static bool? OpenProject(List<string> info) { if (info.Count < 4) return false; info.RemoveAll(a => a == "\n"); string name = info[0].Replace("System Name: ", ""); name = name.Replace(";\n", ""); string autentificationtype = info[1].Replace("AutentificationType: ", ""); autentificationtype = autentificationtype.Replace(";\n", ""); string line = info[2].Replace("Moduls: ", ""); line = line.Replace(";\n", ""); int moduls = Convert.ToInt32(line); SystemInfo.InitSystem(moduls); SystemInfo.Name = name; SystemInfo.AutentificationType = autentificationtype; line = info[3].Replace("Channels: ", ""); line = line.Replace(";\n", ""); int channels = Convert.ToInt32(line); int mod = 0; int i; for (i = 4; i < info.Count; i++) { line = info[i]; if (line.StartsWith("Modul Name: ")) { 150 line = line.Replace("Modul Name: ", ""); line = line.Replace(";\n", ""); SystemInfo.Moduls[mod].Name = line; } else if (line.StartsWith("Modul ArhStyle: ")) { line = line.Replace("Modul ArhStyle: ", ""); line = line.Replace(";\n", ""); SystemInfo.Moduls[mod].ArhStyle = line; } else if (line.StartsWith("Modul businessFlag: ")) { line = line.Replace("Modul businessFlag: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].businessFlag = Convert.ToBoolean(line); } else if (line.StartsWith("Modul coherenceData: ")) { line = line.Replace("Modul coherenceData: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].coherenceData Convert.ToBoolean(line); } else if (line.StartsWith("Modul cohesionData: ")) { line = line.Replace("Modul cohesionData: ", ""); line = line.Replace(";\n", ""); if (line != "null") 151 = SystemInfo.Moduls[mod].cohesionData = Convert.ToBoolean(line); } else if (line.StartsWith("Modul DBtype: ")) { line = line.Replace("Modul DBtype: ", ""); line = line.Replace(";\n", ""); SystemInfo.Moduls[mod].DBtype = line; } else if (line.StartsWith("Modul faultTol: ")) { line = line.Replace("Modul faultTol: ", ""); line = line.Replace(";\n", ""); SystemInfo.Moduls[mod].faultTol = line; } else if (line.StartsWith("Modul fixArhStyle: ")) { line = line.Replace("Modul fixArhStyle: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].fixArhStyle = Convert.ToBoolean(line); } else if (line.StartsWith("Modul fixDBtype: ")) { line = line.Replace("Modul fixDBtype: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].fixDBtype = Convert.ToBoolean(line); } else if (line.StartsWith("Modul fixFaultTol: ")) { 152 line = line.Replace("Modul fixFaultTol: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].fixFaultTol = Convert.ToBoolean(line); } else if (line.StartsWith("Modul internetFlag: ")) { line = line.Replace("Modul internetFlag: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].internetFlag = Convert.ToBoolean(line); } else if (line.StartsWith("Modul isFree: ")) { line = line.Replace("Modul isFree: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].isFree = Convert.ToBoolean(line); } else if (line.StartsWith("Modul limitResourse: ")) { line = line.Replace("Modul limitResourse: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].limitResourse = Convert.ToBoolean(line); } else if (line.StartsWith("Modul load: ")) { line = line.Replace("MModul load: ", ""); line = line.Replace(";\n", ""); 153 SystemInfo.Moduls[mod].load = Convert.ToInt32(line); } else if (line.StartsWith("Modul loseDataFlag: ")) { line = line.Replace("Modul loseDataFlag: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].loseDataFlag = Convert.ToBoolean(line); } else if (line.StartsWith("Modul MultiUser: ")) { line = line.Replace("Modul MultiUser: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].MultiUser = Convert.ToBoolean(line); } else if (line.StartsWith("Modul scaleDB: ")) { line = line.Replace("Modul scaleDB: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].scaleDB = Convert.ToBoolean(line); } else if (line.StartsWith("Modul synhFlag: ")) { line = line.Replace("Modul synhFlag: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].synhFlag = Convert.ToBoolean(line); 154 } else if (line.StartsWith("Modul useBalanser: ")) { line = line.Replace("Modul useBalanser: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].useBalanser = Convert.ToBoolean(line); } else if (line.StartsWith("Modul useDB: ")) { line = line.Replace("Modul useDB: ", ""); line = line.Replace(";\n", ""); if (line != "null") SystemInfo.Moduls[mod].useDB = Convert.ToBoolean(line); mod += 1; } else if (mod == SystemInfo.Moduls.Count) break; else return null; } if (channels == SystemInfo.Channels.Count) { int ch = 0; Modul mod1 = new Modul(); Modul mod2 = new Modul(); for (; i < info.Count; i++) { line = info[i]; 155 if (line.StartsWith("Channel: ")) { line.Replace("Channel: ", ""); line = line.Replace(";\n", ""); if (ch == Convert.ToInt32(line)) continue; else return null; } else if (line.StartsWith("Modul 1: ")) { line.Replace("Modul 1: ", ""); line = line.Replace(";\n", ""); mod1 = FindModul(line); if (mod1 == null) return null; } else if (line.StartsWith("Modul 2: ")) { line.Replace("Modul 2: ", ""); line = line.Replace(";\n", ""); mod2 = FindModul(line); if (mod2 == null) return null; } else if (line.StartsWith("IsChannel: ")) { line.Replace("IsChannel: ", ""); line = line.Replace(";\n", ""); if (line != "null") { 156 ch = SpecMath.CulcChannelNumber(mod1.Name, mod2.Name); } else return null; } else if (line.StartsWith("IsRealTime: ")) { line.Replace("IsRealTime: ", ""); line = line.Replace(";\n", ""); if (line != "null") { SystemInfo.Channels[ch].IsRealTime = Convert.ToBoolean(line); } } else if (line.StartsWith("Type: ")) { line.Replace("Type: ", ""); line = line.Replace(";\n", ""); if (line != "null") { SystemInfo.Channels[ch].type = line; } } else return null; } } return true; } 157 static Modul FindModul(string name) { for (int i = 0; i < SystemInfo.Moduls.Count; i++) if (SystemInfo.Moduls[i].Name == name) return SystemInfo.Moduls[i]; return null; } } } 158

Микросервисы

Related documents

Products

Support

Микросервисы

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib