Разработка интерфейса программы имитационного моделирования вычислительной системы наземного комплекса

Размещено на http://www.allbest.ru/

Федеральное государственное автономное образовательное учреждение высшего образования «Национальный исследовательский университет» «Высшая школа экономики»

Выпускная квалификационная работа

«Информатика и вычислительная техника»

Рецензент

В.В. Эаднов

Научный руководитель

С.Н. Полесский

Москва 2017 г



Оглавление

Введение

1. Постановка задачи

2. Анализ предметной области

2.1 Анализ существующих технических решений объекта разработки

2.2 Анализ методов расчета надежности

3. Обоснование выбора методов решения поставленных задач

3.1 Обоснование выбора языка программирования

3.2 Обоснование выбора системы разработки графического интерфейса

3.3 Обоснование выбора подходов разработки

3.4 Обоснование выбора вспомогательных библиотек

4. Разработка архитектуры программного продукта

4.1 Декомпозиция на классы

4.2 Проектирование пользовательского представления

4.3 Примените паттерна проектирования

4.4 Алгоритм работы

Заключение

Список используемых источников

Аннотация

Приложение



Введение

Развитее электроники, а также её использования в сферах требующих высокой точности и надежности привело к значительному усложнению проектирования радиоэлектронной аппаратуры (далее - РЭА) и как следствие, усложнению систем автоматизированного проектирования (далее - САПР). Однако современные САПР зачастую не позволяют корректно рассчитать надежность проектируемой системы, что приводит к неверной оценке долговечности и отказоустойчивости аппаратуры. Некоторые САПР, а также специально разработанные Product Life Management системы позволяют оценить показатели надежности и даже предлагают мероприятия по их повышению (PTC Windchill Quality Solution), однако подобные системы либо дорогие, либо имеют очень широкий спектр задач, что может повлечь за собой значительное повышение времени проектирования. Более же простые способы оценки надежности обычно не способны учесть случайные воздействия на систему, а также имеют большую погрешность при расчете сложных систем.

Система АСОНИКА-К-РЭС, разработанная А.Н. Тихменевом, создана для расчета показателей надежности сложных РЭА и позволяет быстро описать монотонные структуры. Однако, система требует изучения синтаксиса языка моделирования (также разработанного Тихменевым), а также имеет большое количество проблем с привязкой к этому языку:

- значительное время на ввод уникальных компонентов РЭА (не уникальные “дубли” можно просто скопировать);

- сложность в отладке спроектированной модели РЭА (с повышением сложности в зависимости от объема).

Помимо проблем, связанных с языком моделирования, стандартный интерфейс К-РЭС имеет некоторое количество проблем таких как:

- неверно определяющиеся строки, содержащие ошибку в описании модели, либо синтаксическую ошибку;

- неудобный способ оценки адекватности модели путем верефикации;

- интерфейс и расчетное ядро программы работает в едином потоке, что приводит неадекватной реакции программы на действия пользователя при расчете (особенно при большем количестве экспериментов);

- перегруженные обязанностями классы, что значительно усложняет создание для них интерфейсов и реализацию современных принципов программирования.



1. Постановка задачи

Цель: разработать интерфейс для системы АСОНИКА-К-РЕС, реализующий заявление оригиналом возможности: разработка модели РЭА; верефикация модели; расчет показателей надежности аппаратуры (вероятность безотказной работы и наработки на отказ), а также исключающий ошибки, связанные с синтаксисом.

Задачи:

- Обзор аналогов;

- Обоснование выбора системы Windows Presentation Foundation и языка программирования C#;

- Обоснование выбора программных библиотек;

- Разработка концепта интерфейса и механизма его работы;

- Реализация первой версии интерфейса.

В разрабатываемой системе необходимо реализовать следующие возможности:

- добавление, редактирование, удаление и дублирование компонентов;

- сортировка компонентов по узлам;

- изменение местоположения компонентов между узлами;

- добавление, редактирование и удаление различных логических выражений: функций и переключателей;

- информирование и взаимодействие с пользователем для исключения ошибок моделирования;

- возможность верефикации модели;

- передача готовой модели в расчетный модуль К-РЭС;

- сохранение спроектированной модели;

- распечатка результатов расчета.

Для повышения масштабируемости разрабатываемого интерфейса разработку необходимо проводить, опираясь на модульность итоговой системы. Модульность итоговой системы, позволяет значительно ускорить и упростить добавление новых функций, с соблюдением различных паттернов программирования. Для реализации модульности необходимо выбрать один из паттернов (шаблонов) проектирования приложений, подразумевающих разделения логики и визуального представления.

Итоговый результат разработки - интерфейс, интегрированный с системой АСОНИКА-К-РЭС, спроектированный с использованием современных паттернов программирования, реализующих принцип модульности и отвечающий современным требованиям эргономики.



2. Анализ предметной области

Перед непосредственной разработкой интерфейса необходимо провести множество различных подготовительных мероприятий. Важно понимать, что помимо рассмотрения и изучения инструментарий для разработки необходимо рассмотреть и провести анализ существующих в выбранной предметной области решений и методов. Подобная необходимость связана с составлением требований к разрабатываемому интерфейсу - без полного понимания предметной области возможны упущения в итоговом продукте. Кроме того, изучение аналогов позволит сократить время на исследование и разработку наиболее удобных для пользователя шаблонов поведения программы.

Помимо функциональной необходимости, анализ существующих решений позволит наиболее точно определить уровень, на котором должен быть готовый интерфейс для его конкурентоспособности.

2.1 Анализ существующих технических решений объекта разработки

Windchill Quality Solution

WQS содержит множество различных модулей для проведения анализа надежности [1], но мы рассмотрим только те, что нацелены непосредственно на расчет таких показателей надежности как вероятность безотказной работы и наработка на отказ:

- Prediction;

- Reliability Block Diagram (RBD);

- Weibull;

- Markov.

Модуль Prediction, в основе которого лежат стандарты министерства обороны США, позволяет проводить анализ таких характеристик как среднее время наработки до отказа, вероятность безотказной работы и прочие показатели надежности, однако он не позволяет точно оценить надёжность сложной системы, поэтому он не является подходящим в данном случае.

Модуль RBD - гибкий модуль, совмещает в себе структурные схемы надежности (ССН) со средствами имитационного моделирования. Данный модуль часто применяют для вычисления готовности сложных систем, параметров надежности, ремонтных ресурсов и запасных частей.

Модуль Weibull позволяет рассчитать надежность на основании статистического метода. Для точной оценки необходимо собирать статистические данные на протяжении всего жизненного цикл изделия.

Модуль Markov позволяет оценить надежность изделия на этапе проектирования. Данный модуль работает на основании состояний и может учитывать состояние системы, связи между этими состояниями и скорость перехода между ними. Данный модуль наиболее точно отражает метод функционирования К-РЭС.

WQS позволяет экспортировать информацию из одного модуля в другой, что обеспечивает большую гибкость в расчете показателей надежности. Для решения поставленной задачи необходимо ввести в систему модель РЭА, используя модуль Prediction рассчитать показатели надежности составных частей (задав им такие показатели как приемка, параметры среды и пр.), экспортировать полученные данные в модуль RBD и построить логическую схему РЭА используя инструментарий Windchill.

На рис. 1 показано дерево РЭА.

Рис. 1. Windchill Prediction: Дерево системы

На рис. 2 и 3 показаны таблицы деталей (ТД), которые составляют основу любого проекта в Windchill.

Рис. 2. Windchill Prediction: Таблица деталей

Рис. 3. Windchill Prediction: Таблица деталей

В ДС задается иерархия РЭА (например, система - системный блок персонального компьютера, а подсистема - материнская плата), а также детали, содержащиеся в подсистемах. В ТД задаются параметры деталей (наименование, категория и т.д.), выбирается стандарт расчета (PRISM, MIL-HDBK и пр.), а также добавляются характеристики для модуля Prediction (температура, данные о среде, рабочий цикл, закон распределения и пр.). После указания характеристик каждой СЧ модуль Prediction проводит расчет искомых характеристик (интенсивность отказов и пр.).

Для модуля RBD необходимо построить ССН РЭА (см. рис. 5) и привязать данные расчета модуля Prediction к каждому блоку.

Рис. 4. Windchill RBD: ССН РЭА

Подобный метод позволяет решать нетривиальные задачи с использованием резервирования компонентов. Как только проектирование будет завершено, одним кликом “Рассчитать” можно получить результаты расчета каждого модуля. Также PTC Windchill укомплектован генератором отчетов, который позволяет получить полный отчет по результатам работы каждого модуля.

RAM Commander

Также, как и продукт компании PTC, RAM Commander содержит модули Prediction, RBD и Markov [2] и в целом не уступает по количеству и по качеству реализации модулей. Кроме того, Commander имеет принципиально схожий с Windchill интерфейс (см. рис 5).

Рис. 5. RAM Commander: Дерево системы

Каждая деталь в ДС имеет свойства, выбираемые в контекстном меню детали, в которых можно задать параметры самой детали, а также характеристики для модуля Prediction.

Модуль RBD позволяет импортировать результаты расчетов из других модулей (в частности, из Prediction), и делать гибкие расчеты. Однако в сравнении с WQS, RAM Commander имеет автоматизированный процесс проектирования и требует больше времени на разработку одного проекта.

АСОНИКА-К

Программный комплекс АСОНИКА-К - отечественная разработка в сфере расчета и анализа надежности [3]. В отличии от аналогов, данная система создана исключительно для проектирования РЭА с использованием российских стандартов (помимо иностранных).

ПК АСОНИКА-К позволяет проводить расчеты надежности РЭА с учетом резервирования и прочих механизмов повышения надежности, которые являются обязательными для современного проектирования.

ПК АСОНИКА-К удобен тем, что поэтапно просит пользователя задать данные для проектирования сопоставимые с классом устройства выбранным пользователем из предложенных стандартов. Подобный подход позволяет снизить время добавления новых элементов в проект.

Кроме того, система АСОНИКА-К-РЭС позволяет рассчитать надежность реконфигурируемой РЭА, используя метод имитационного моделирования [4, 5]. В данный момент система требует знания языка моделирования для программирования модели РЭА и укомплектована простейшим интерфейсом, состоящим из текстового редактора, панели управления компиляцией, верификацией и моделированием (см. рис. 6) и панелью вывода.

Рис. 6 Интерфейс программы АСОНИКА-К-РЭС

Несмотря на превосходство метода имитационного моделирования над аналитическим (используемым в модуле Prediction таких продуктов как WQS и RAM Commander), текущий интерфейс К-РЭС мешает коммерциализации этого продукта и требует значительной модификации [6].

Результаты анализа

Для выявления положительных и отрицательных сторон интерфейсов рассмотренных систем, нужно выделить критерии оценки удобства интерфейса и применить их к рассмотренным средствам проектирования.

Первый критерий - наглядность интерфейса. Данный критерий отвечает за количество, кликов которое надо сделать, чтобы получить информацию о деталях проекта или инициализировать какие-либо расчеты с помощью модулей.

Второй критерий - возможности интерфейса. Так как интерфейс отвечает за взаимодействие пользователя с расчётным ядром системы АСОНИКА-К-РЭС, необходимо чтобы он реализовывал весь функционал, необходимый пользователю:

- наглядный интерфейс, позволяющий конфигурировать модель РЭА без изучения языка моделирования;

- сохранение проектов, с возможностью дальнейшего переноса проектов на другую рабочую станцию;

- формирование полноценных отчетов.

Третий критерий - визуальная составляющая интерфейса. Необходимо, чтобы интерфейс был визуально привлекательным, чтобы не утомлять пользователя, осуществляющего проектирование.

Оценим каждый продукт по предложенным критериям:

WQS - самый наглядный интерфейс: всего в пару кликов можно подключить или отключить любой модуль, провести расчет любого элемента или всей системы, а также получить доступ к любым характеристикам СЧ (можно задать стандартные значения для неизвестных параметров); у каждого модуля есть своя обертка: у RBD - это средство построение и редактирования диаграмм, у Prediction - набор таблиц; Интерфейс можно сделать более или менее развернутым, тем самым регулировать визуальную нагрузку на пользователя;

RAM COMMANDER - в целом не уступает WQS за исключением менее удобного модуля построения диаграмм, а также запутанного доступа к характеристикам СЧ (что примечательно, в отличии от WQS многие характеристики не имеют стандартных значений и требуют обязательного заполнения). Интерфейс имеет мало возможностей настройки (практический не имеет) и при проектировании больших систем способен создавать значительную нагрузку на пользователя;

ПК АСОНИКА-К - наиболее дружелюбная к новичку в PLM-системах, позволяет быстро создать и сконфигурировать проект, благодаря поэтапному добавлению элементов. Несмотря на это интерфейс имеет ряд недостатков, таких как отсутствие системы сохранения проекта в единый файл, а также невозможность конфигурировать дерево проектов (даже просто менять очередность элементов).

В итоге было решено при разработке собственного интерфейса для системы АСОНИКА-К-РЭС опираться на систему компании PTC, но с функциональными доработками: в WQS для схожего по функционалу с К-РЭС модуля Markov используются диаграммы состояний, однако подобный подход не учитывает особенность системы перехода состояний, которая при проектировании массивных РЭА может быть весьма громоздкой в визуальном исполнении. Для решения этой проблемы, вместо диаграмм, будут использоваться табличные шаблоны, генерирующиеся на основании показателей, заданных пользователем. В дальнейшем, возможно развитие проекта на интеграцию с другими модулями АСОНИКИ в единый программный комплекс, на подобие зарубежных аналогов.

Помимо функциональной оценки необходимо упомянуть, что на данный момент зарубежные аналоги слабо адаптированы для использования их на территории России. Часть из них не имеют русской локализации, не имеют внесённых по умолчанию российских стандартов и очень дорогие за счет множества модулей, который зачастую не нужны или их функционал не реализуем на отечественных предприятиях, а отказаться от них нельзя.

2.2 Анализ методов расчета надежности

Для более глубокого понимания предметной области помимо обзора налогов необходимо рассмотреть методы расчета надежности, в частности статистический метод, который используется в К-РЭС. Помимо необходимых знаний предметной области, это позволит получить необходимый опыт работы с системой для которой разрабатывается интерфейс и ознакомиться с действиями, с которыми наиболее часто сталкивается пользователь, для дальнейшей их автоматизации.

При расчете показателей надежности радиоэлектронной аппаратуры (РЭА), в первую очередь, необходимо, согласно ОСТ 4Г 0.012.242-84 [7], составить структурную схему надежности (ССН), основываясь на анализе выполняемых функций, конструктивных особенностей и с учетом критериев отказа изделий. Для расчета показателей используется три группы методов: аналитические, статистические и комбинированные.

Аналитический метод - метод в основном применимый для расчета простых, статичных систем, в которых исключается фактор случайности. В то время как статистический метод - численный метод для статистических испытаний (к примеру, метод Монте-Карло), применяется для имитации процессов, происходящих в системах подверженных случайным воздействиям. Целью данной работы является выявление наиболее точного метода для расчета ССН с использованием резервирования. Источником формул для аналитического метода является отраслевой стандарт 0.012.242-84, а для проведения статистического эксперимента будет использован один из языков моделирования.

Аналитический метод

Для сравнения будут рассчитаны две структурные схемы надежности невосстанавливаемых РЭА с применением резервирования: резервирование из 1 основного и 3 резервных элементов (см. Рис. 7) и мажоритарная схема “2 из 3” (См. Рис. 8).

В качестве расчетного показателя была выбрана вероятность безотказной работы, показывающей, что на при заданном временем интервале (87600 сек) и заданной интенсивности отказов отказа не возникнет. Для расчета нагруженного резерва была принята формула (2) из таблицы 1 отраслевого стандарта:



Рис. 7. Нагруженный резерв из 1 основного и 3 резервных элементов

Рис. 8. Мажоритарная группа “2 из 3”

(1)

где - число сочетаний из N по i; л - интенсивность отказов (4*10-6); n - кол-во основных элементов (1 элемент); m - резервных элементов (3 элемента); N - общее кол-во элементов (4 элемента); t - временной интервал 87600 сек.

Расчет производился в системе автоматизированного проектирования Mathcad (см. Рис. 9):

Рис. 9. Расчет нагруженного резерва в САПР Mathcad



Мажоритарная группа является уже более сложным ССН: помимо 3х составных частей (СЧ), в неё входит компаратор ЭС, на вход которому подключены все 3 элемента, а на выход подается логическая единица, если 2 элемента из 3 находятся в рабочем состоянии и 0, если в рабочем состоянии менее 2 элементов. Формула мажоритарной группы (4):

,

где - интенсивность отказов СЧ1, СЧ2, СЧ3(4*10-6), л_2 - интенсивность отказов компаратора ЭС(5*10-7).

Рис. 10 Расчет мажоритарной группы в САПР Mathcad

Получение расчетное значение вероятности безотказной работы получилось довольно низким, что не очень соотносится с требованиями к подобным схемам. такие значение может означать неточность в используемом метода, что логично, ведь исходя из обычного круга задач, данный метод используется для тривиальных и в большинстве своем не резервируемых схем [8]. Однако, прежде чем сделать выводы о точности метода в решении подобных задач, необходимо сравнить его с более точным статистическим методом [9].

Имитационное моделирование

Вначале разработки модели необходимо задать законы распределения вначале для задачи с нагруженным резервом:

distribution Dis_D_Normal (4e-6);

Далее описываются составные части - для этого указываются возможные состояния, режимы работы и законы распределения:

knot D_1

{

state: Fail, Work;

mode: Normal;

startState: Work;

startMode: Normal;

cntrlMode: undistribution;

tabledistribution:

| Normal|

Work| Dis_D_Normal;

tableStateChange:

Normal

Work| Fail;

}

knot D_2

{

state: Fail, Work;

mode: Normal;

startState: Work;

startMode: Normal;

cntrlMode: undistribution;

tabledistribution:

| Normal|

Work| Dis_D_Normal;

tableStateChange:

Normal

Work| Fail;

}

Подобная модель описывает СЧ1 и СЧ2, однако модели для других элементов будут аналогичны, поэтому не будут приведены здесь.

Далее задается модель РЭА, но в ней вместо интенсивности отказов задается логическая функция и пока на выходе функции логическая единица - изделие функционирует.

general knot REA

{

state: Fail, Work;

mode: Normal;

startState: Work;

startMode: Normal;

cntrlMode: unFunction;

tableStateChange:

Normal

Work| FuncREA ;

};

И последняя часть моделирования - логическое выражение для определения критерия функционирования РЭА:

function FuncREA

{

return (D_1: Work | D_2: Work | D_3: Work | D_4: Work);

};

Данное выражение означает, что пока активен хотя-бы один элемент, вся схема работает. Итоговый результат расчета вероятности безотказной работы 0,9919.

Для создания модели мажоритарной группы необходимо модифицировать код, задавай другой закон распределения для СЧ и ввести новый для компаратора, добавить элемент comp для моделирования самого элемента сравнения и усложнить логическое выражение:

distribution Dis_D_Normal (4e-6);

distribution Dis_comp (5e-7);

knot comp

{

state: Fail, Work;

mode: Normal;

startState: Work;

startMode: Normal;

cntrlMode: undistribution;

tabledistribution:

| Normal|

Work| Dis_comp;

tableStateChange:

Normal

Work| Fail;

};

function FuncREA

{

return (((D_1: Work & D_2: Work) | (D_1: Work & D_3: Work) | (D_2: Work & D_3: Work)) & comp);

};

Использование логических выражений позволяет довольно наглядно оценить логику работы ССН - в данном случае сразу видно, что изделие работает до тех пор, пока работают хотя-бы два элемента и компаратор, что отвечает поставленной задаче. Итоговое значение ВБР - 0,7556.

Результаты анализа

В итоге приняв за эталон результаты получение методом имитационного моделирования, рассчитает погрешность аналитического метода (метод построения модели по формуле полной вероятности) (таблица 1).



Таблица 1. Результаты расчета

Метод	Значение ВБР для первой схемы	Значение ВБР для второй схемы	Относительная погрешность по ВБР
			Первая схема	Вторая схема
Аналитический	0,9924	0,4749	0,0005	0.3714
Статистический	0,9919	0,7556	0	0

В результате если погрешность при расчете довольно простой схемы с нагруженным резервом невелика, то погрешность при расчете более сложной схемы - мажоритарной, значительно выше. Исхода из работы А.Н. Тихменева [10] в более сложных ССН погрешность при использовании аналитического метода может возрастать еще сильнее. В качестве альтернативы - можно использовать более сложные методы, такие как метод перебора гипотез, однако приведённые в данной работе расчеты показывают, что после изучения языка моделирования возможно быстро и точно описать модель РЭА любой сложности и получить точные значения показателей надежности.



3. Обоснование выбора методов решения поставленных задач

При разработке важно ответвлённо подойди к выбору методов и инструментов разработки. Неверно выбранный методы (что может быть связанно, с недооценкой предметной области и требований по масштабируемости и пр.) могут привести к значительному усложнению и продлению разработки, что в свою очередь увеличит стоимость проекта. Правильный выбор методов и инструментов особенно критичен в разработке программных продуктов, языки программирования высокого уровня, framework'и и паттерны обычно используются для решения определенных задач. Это не исключает возможность решения проблемы посредством использования языка или паттерна, спроектированного под отличную от решаемой задачи, однако использование наиболее подходящих методов решения поставленной задачи позволяют провести разработку с максимальным соответствием поставленной задаче [10].

3.1 Обоснование выбора языка программирования

Разнообразие языков программирования способно значительно усложнить нахождения наиболее подходящего для решения поставленной задачи. Для каждого языка обычно оцениваются следующие показатели:

- платформа;

- тип разрабатываемого проекта;

- гибкость;

- затраты на разработку;

- надежность;

- сообщество и поддержка.

Исходя из задания - необходимо разработать интерфейс для программы расчета надежности нетривиальных систем. Так как продукт ориентирован на отечественные предприятия, то целевая платформа - Windows XP/7/8/10. И так как интерфейс должен быть интегрирован с расчетным модулем К-РЭС, то итоговый тип разрабатываемой системы - приложение для настольного компьютера с использованием графического интерфейса.

Существует несколько наиболее распространенных языков для построения настольных приложений: Java, C++ и C#. Однако, несмотря на то, что C++ имеет преимущества в скорости и безопасности, он зачастую требует гораздо большего времени на разработку, особенно когда речь идет о модульных приложениях. Поэтому в дальнейшем идет выбор между C# и Java. Java является наиболее распространенным языком обеспечивающим кроссплатформенность посредством платформы Java Virtual Machine. Кроме того, Java имеет одно из самых больших сообществ разработчиков среди прочих языков программирования (и значительно большее по сравнению, с C#), что позволяет в любой момент задать вопрос сообществу, что способно значительно сократить время решения проблем, которые могут возникнуть в ходе разработки. Распространённость и популярность этого языка практический во всех возможных направлениях позволяет найти множество готовых решений, инструкций и примеров.

С другой стороны, C# в своем стандартном виде лишен кроссплатформенности - платформа .NET Framework поддерживается только Windows, но позволяет использовать такие системы как Windows Forms и Windows Presentation Foundation (WPF) с максимальной эффективностью. Эти системы идеально адаптированы для работы на платформе Windows, поэтому в сравнении с Java разработка приложений для Windows значительно проще и быстрее при использовании C#. Единственный значительный плюс Java по сравнению с C#, помимо большего сообщества - кроссплатформенность, реализована в .NET Core, поэтому не является уникальной особенностью. Большое сообщество Java компенсируется простотой разработки приложений под Windows.



3.2 Обоснование выбора системы разработки графического интерфейса

Основный технологии, использующиеся для разработки графического интерфейса на C#: Windows Forms, WPF, UWP (Universal Windows Platform) и Xamarin.

Windows Forms - первая версия графической системы используемой для разработки приложений с графическим интерфейсом на C#. Система очень проста и позволяет разрабатывать многофункциональные приложения с использованием большинства паттернов. Однако WinForms имеет несколько недостатков которые делают его малоприменимым в текущей разработке: недостаточная гибкость предоставляемых “controlов” (элементов интерфейса) и сложность реализации модульности при использовании данной системы.

WPF - система пришедшая на смена Windows Forms. Интерфейс в данной системе строится на основании языка разметки XAML, который позволяет получить доступ к базовым элементам и переопределить существующие controlы или создать собственные, что обеспечивает высокую гибкость данной системы. Помимо этого, WPF привнес технологию “привязок” (bindings), которая позволяет быстро связать интерфейс и логику его работы. Минус системы - высокая сложность, что повышает требования к предварительной подготовке перед непосредственной разработкой.

Xamarin - кроссплатформенная система построенная на базе .NET Mono. Как и WPF, интерфейс в данной системе строится на языке XAML, однако Xamarin гораздо слабее WPF и имеет сложности в редактировании встроенных controlов. UWP - развитие WPF, ориентирующиеся на разработку приложений под Windows 10. В отличии от WPF, который с годами практический перестал обновляться разработчиками, UWP - новая и быстроразвивающаяся технология. Однако в виду её привязки к одной, непопулярной на отечественных предприятиях, платформе использование данной системы нецелесообразно.

Исходя из приведенной выше информации, WPF является наиболее подходящей системой для решения поставленной задачи. В дальнейшем возможен переход на UWP.

3.3 Обоснование выбора подходов разработки

В современном проектировании ПО есть множество различных паттернов, которые разработаны с целью облегчить процесс разработки и сопровождения. Однако не все паттерны применимы в одном проекте, а некоторые исключают использование других, поэтому перед применением паттернов необходимо предварительно оценить необходимость в их применении и их совместимость.

Метод и паттерн проектирования

Основа модульного программирования лежит в разработке модулей - законченного набора функциональных элементов служащего для решения определенной задачи [12].

Основными плюсами данного подхода считается возможность разработки модулей независимо друг от друга, а также простота их дальнейшего сопровождения. Помимо этого, модульная концепция подразумевает возможность объединения множества (в теории, неограниченного количества) модулей в единой программе, что позволяет разрабатывать системы с практически неограниченной расширяемостью. Кроме того, каждый отдельно взятый модуль проще тестировать, чем программу с встроенным в неё функционалом всех этих модулей.

Обычно при проектировании приложения на каждый модуль выделяется свой функционал, который заранее определяется в ходе декомпозиции приложения. Декомпозиция - это процесс разбиения системы с некоторым функционалом на подсистемы, которые выполняют ограниченное число функций оригинальной системы, обычно объединённых единой логикой.

После декомпозиции приложения на модули проводят декомпозицию на классы - иначе говоря, проектируются классы в составе модуля и им делегируются различные функции модуля.

Помимо метода проектирования необходимо выбрать паттерн, который позволит придерживаться определенной структуры проектирования. При разработке приложений с графическим представлением наиболее распространены два паттерна: Model-View-Controller (MVC или MVP в случае Model-View-Presenter) и Model-View-ViewModel (MVVM).

Рис. 11. Принцип MVVM

MVC - паттерн описывающий взаимодействие графического представления (View) и модели данных (Model) через контроллер (или презентер), в то время как MVVM связывает представление с моделью-представления (ViewModel) через которую уже идет связь с моделью. Система WPF была разработана в соответствии с MVVM, что позволяло использовать одну из основных особенностей WPF, Data Binding и связывать модель с представлением через бизнес-логику, в то время как MVC является антиподом MVVM и не очень походит для использования в WPF.

Метод инверсии управления

Inversion of Control (IoC) или инверсия управления - принцип проектирования, позволяющий передавать (делегировать) обязанности по выполнению функций программы за счет инвертирования потока управления “третьей” стороне.

Service Locator - паттерн, основанный на заранее прописанных зависимостях и позволяющий вызывать непосредственное инжектирование в создание объекты. Dependency injection или инжектирование зависимостей - реализация принципа инверсии управления существующая в трех видах: через конструктор, метод или интерфейс.

Одна из причин развития инжектирования зависимостей - необходимость снижения ответственности классов и соблюдения принципа закрытости.

Ответственность класса - это принцип который должен выполнять класс. Наиболее распространен принцип единственной ответственности класса - каждый класс имеет одну ответственность. Например, есть класс-коллекция, содержащая коллекцию из классов, наследуемых от единого абстрактного класса. Первичная ответственность этого класса-коллекции - хранение коллекции класса и некоторой дополнительной информации. Вторичная ответственность - валидация всех объектов в коллекции по условиям уникальным для каждого класса. В данном случае, необходимо отделить функцию валидации от класса-коллекции и передать новому классу, иначе расширение разнообразия коллекции может провести к нарушению принципа закрытости и усложнению проектирования.

Принцип закрытости - принцип по которому исходный код класса или библиотеки должен быть закрыт для изменений, но открыт для расширения. Для этого используются различные абстракции: абстрактные классы и интерфейсы.

Возвращаясь к инжектированию зависимостей, возможно следующая ситуация - существует класс А который посылает информацию, собранную классом Б, через класс В. Подобная связь говорит о том, что класс А должен создавать внутри себя объекты класса Б и В, что может привести к проблемам при изменении конструкторов Б и В. Кроме того, если мы захотим использовать другой источник пересылки данных, то нам придётся изменить класс В.

Один из способов ухода от данной проблемы - это вынести функции передачи и сбора информаций из классов Б и В отдельные интерфейсы и передавать в конструктор класса А. Таким образом класс А будет завесить уже не от объектов других классов, а от интерфейсов.

3.4 Обоснование выбора вспомогательных библиотек

Так как реализация паттерна MVVM и IoC вручную чаще всего приводит к значительному усложнению программирования и увеличении количества программного кода, чаще всего используют одну из вспомогательных библиотек, которая также предоставляет средства для реализации метода инверсии управления. Наиболее популярными библиотекам в данном случае являются Prism и MVVM Light Toolkit.

MVVM Light Toolkit - это, как ясно из названия, библиотека для имплементации паттерна MVVM, предоставляющая шаблоны проектов, а также библиотеки реализующие паттерны IoC и Service Locator в упрощенном виде. Благодаря своей простоте и скорости разработки данная библиотека очень распространена и имеет довольно большое сообщество.

Prism, в отличии от Light, предоставляет средства для реализации слабосвязанных и расширяемых приложений (что сложно реализуемо в Light) в MVVM Toolkit. Однако данная библиотека является одним из самых сложных средств реализации MVVM из все существующих и не умеет автоматический делать те вещи, которые умеет Light, что не говорит в пользу скорости разработки. Поэтому для решения поставленной задачи наиболее подходящим является MVVM Light Toolkit.

Также помимо наборов инструментов, помогающих реализовывать паттерны есть множество библиотек, которые способны сделать проще практически любой этап разработки, в частности, разработку графического представления. Среди подобных библиотек для WPF выделяется Xceed WPF Extended. Абсолютное большинство библиотек, реализующих различные controlы распространяются по платной лицензии и потому не являются предпочтительными. Также controlы можно разрабатывать самому, но подобное утверждение верно для простых controlов, в то время как сложные, типа, встроенного в Xceed AvalonDock, являются комплексным controlом реализующим концепцию “окон внутри окон”, когда внутри основного окна приложения есть еще несколько поменьше, каждое из которых выполняет свою собственную функцию и может быть перемещено внутри разграниченной области.

Последним необходимым инструментом является библиотека, работающая с файлами формата документов, для распечатки отчета о выполненном расчете. Наиболее подходящим форматом документов являются документы Microsoft Office - самой распространенной в мире офисной системы.

Для решения данной проблемы обычно используют один из двух методов:

- Component Object Model (COM);

- Библиотеки, непосредственно работающие с office форматами.

В случае с COM объектами возможно обойтись встроенным в .NET библиотеками, но сама концепция в данном случае не удачная. Для того чтобы просто сохранить отчет программа должна связаться с установленной в той же системе версией Office, запустить её в фоновом режиме и с помощью указанных в коде взаимодействий, заполнить таблицу. Данный метод плох сразу по нескольким причинам:

- запуск в фоновом режиме требует выделения ресурсов компьютера, что плохо скажется на производительности;

- на системе должна стоять указанная в исходном коде версия Office;

- заполнение денных происходит в реальном времени, поэтому пользователь или сторонняя программа, может случайно или преднамеренно вмешаться в процесс.

В тоже время библиотеки позволяют генерировать документ на основе кода, не требуя запуска на фоне или установленных приложений. Наиболее распространенной библиотекой для работы с office форматом является OpenXML. Это быстрый и простой набор инструментов для генерации всех основных открытых форматов документов: XLSX, DOCX и PPTX.



4. Разработка архитектуры программного продукта

После завершения подготовительных мероприятий, перед непосредственной разработкой, нужно спроектировать архитектуру приложения. Первый пункт в проектировании архитектуры - декомпозиция (см. пункт 3.3.1) графический интерфейс программный мажоритарный

Две основные функции итогового приложения - проектирование модели РЭА, через доступный интерфейс и дальнейшая её обработка и расчет показателей надежности. Следовательно, можно разделить приложение на два модуля: модуль обеспечивающий бизнес-логику и представление, и расчетный модуль. Однако, так как расчетный модуль уже был разработан, то в его дальнейшей декомпозиции нет нужды и дальнейшая работа будет вестись с первым модулем.

4.1 Декомпозиция на классы

Следующим этапом проектирования является декомпозиция на классы. Первым пунктом необходимо выделить все доступные пользователю действия, а также их связь друг с другом. Для этого используется язык графического описания Unified Module Language (UML) и диаграмма Use Case (вариантов использования, см. рис. 12). На данный диаграмме описывается актер (пользователь) и доступные ему действия. Если одно действие подразумевает выполнение другого, то они связываются пометкой includes, а если для доступа к действию нужно вначале выполнить другое - пометкой extends [13].

Выбранные действия необходимо делегировать классам, каждый из которых объединяет логически связанные данные и методы их взаимодействия. Однако при дальнейшем проектирование нужно учесть, что стандартное проектирование подразумевает прямо взаимодействие данных и представления в то время как паттерн MVVM разделяет их с помощью viewModel, поэтому в дальнейшем необходимо преобразовать диаграмму классов (см. рис. 13) в новый вид.

Рис. 12. Диаграмма Use Case разрабатываемого интерфейса

Рис. 13. Первичная диаграмма классов

В своем первичен виде модуль содержит всего 3 класса:

- Изделие - основной класс, агрегирующий классы “Выражение” и “Компонент”, а также реализующий интерфейс “Расчетные данные”. Содержит в себе методы по обработке списков выражений и компонентов (добавление, удаление, изменение и валидация);

- Расчетные данные - интерфейс, обеспечивающий взаимодействие расчетного модуля и модуля бизнес логики. Содержит в себе методы расчета и верефикации, которые имплементируются классом “Изделие”;

- Выражение - класс, представляющий функции и переключатели описание языком моделирования К-РЭС. Метод проверки условия необходим изделию чтобы сформировать ответ для расчетного модуля о готовности данного выражения к использованию в модели;

- Компоненты - класс, представляющий компоненты изделия описание языком моделирования К-РЭС. Имеет аналогичный выражению метод проверки.

Исходя из анализа предметной области необходимо выделить поля содержащие данные каждого класса. Для начала “Изделие”:

1. Название - как видно из пункта 2.2.2 (далее вся информация о данных классов будет взята оттуда), где приведен пример построения модели изделия, у изделия, как и у всех остальных элементов модели есть название;

2. Состояния - у изделия есть список состояний, в котором обязательно должно быть минимум два состояния - состояние отказа и работы.

3. Режимы - у изделия есть список режимов, в котором необходим минимум один режим;

4. Начальное состояние - у изделия необходимо выбрать одно начальное состояние (не отказа);

5. Начальный режим - у изделия есть начальный режим, являющийся обязательным требованием;

6. Тип контроля - поле, отвечающее за способ перехода изделия между состояниями: по функции или закону распределения. Но так как изделие всегда работает по функции, то данное поле избыточно;

7. Таблица перехода состояний - таблица, отображающая возможности перехода изделия из одного состояния в другое.

Поля “Компонента” с первого по пятый, а также седьмой пункт совпадают с полями “Изделия”, но дальше имеются отличия:

1. Тип контроля - обычный компонент может подобно изделию работать по функции, но также и по закону распределения;

2. Таблица распределений - в случае выбора контроля по распределению, необходимо указать закон распределения для каждого состояния.

Поля “Выражения” имеют только одно общее с другими классами поле - название. Остальные поля зависят от типа выражения:

- при выборе выражения-функции, необходимо указать логическое выражение, при выполнении которого компонент или изделие функционирует;

- при выборе выражении-переключателя, необходимо указать логическое выражение, при выполнении которого будет срабатывать переключатель и изделия и компоненты, которые будут переключаться в целевое состояние или режим.

Как видно из приведенных выше данных данная схема классов не является оптимальной, однако дальнейшую доработку стоит производить с оглядкой на требования MVVM. Исходя из проектирования, следующие улучшения могут быть сделаны:

- выделить общие данные из классов “компонент” и “изделия” в третий класс и агрегировать его внутри первых двух;

- класс “выражения” выполняет функцию сразу двух реальных объектов: функции и переключателя. Значит, необходимо перевести его в разряд абстрактных и наследовать от него два новых класса реализующих функции и переключатели.



4.2 Проектирование пользовательского представления

Проектирования пользовательского представления (ранее View) - это проектирование логики расположения controlов, их взаимодействия и привязанных к ним данных. При проектировании обычно выделяют по представлению на каждое окно в приложении (например, для главного окна программы - одна представление, для окна настроек - второе представления и тд), поэтому необходимо выяснить количество представлений и их предназначение [14].

Первое представление - это главное окно программы, содержащее основную информацию и главные рабочие controlы приложения, такие как: список копонентов, список выражений, свойства компонентов, свойства выражений, а также controlы меню программы, позволяющие получать доступ к основным функциям приложения, а также к другим окнам программы.

Второе представление - это окно верефикации модели, содержащий такие controlы как: control отображающий переход компонентов из одного состояния в другое с заданным пользователем интервалом, control позволяющий принудительно перевести компонент в заданное состояние (если компонент не находится в состоянии отказа).

Третье представление - окно “О программе”. Самое маленькое представление, отображающее данные о версии программы, разработчике и контактные данные.

После выделения представлений необходимо выбрать подходящие controlы из системы WPF для отображения и манипуляции со всеми данными выбранными при декомпозиции на классы. Для этого стоит последовательно пройти по всем представлениям.

Первое представление, по умолчанию называемое в WPF “MainWindow”, должно содержать следующие controlы:

- control панели инструментов - данный control реализует панель инструментов в которой содержится панель быстрого доступа и меню программы. Меню позволяет получить доступ практически ко всем функциям программы таким как, открытие, закрытие, сохранение, расчет проекта и тд. Панель быстро доступа позволяет получить быстрый доступ к различным функциям меню. Для реализации панели инструментов в WPF используется control DockPanel, для меню - Menu и MenuItem и для панели быстрого доступа - Toolbar;

- control рабочего поля - WPF работает с иерархией “визуальное дерево”, которая требует, чтобы controlы размещались внутри других специально спроектированных controlов-контейнеров. Обычно для размещения используют control Grid позволяющий реализовать большое количество различных видов сетки (от визуальных таблиц до большой коллекции контров каждый из которых выполняет свою функцию). Однако, в связи с агрономическими требованиями современных приложений, у пользователя должна быть возможность изменять размеры controlов рабочего поля, менять их местоположение и скрывать при отсутствии в них необходимости. Реализация подобного controlа своими силами достойна отдельной дипломной работы, поэтому было решено использовать распространяющийся по открытой лицензии котрол DockingManager библиотеки AvalonDock являющейся частью Xceed Toolkit. В дальнейшем все controlы использующиеся внутри рабочего поля будут обернуты в LayoutAnchorable и LayoutDocument - controlы-контейнеры для содержимого DockingManager;

- control дерева компонентов - данный control содержит в себе список компонентов, изделия и узлов, а также позволяющий производить различные действия над компонентами. В WPF существует control TreeView разработанный специально для отображения элементов в виде дерева. Кроме того, TreeView является наследником UIElement - класса, содержащего широкий набор возможностей. Одной из этих возможностей является использование контроля ContextMenu для введения быстрого доступа к различным функциям работающими с данными внутри controlа. Аналогично этому controlу работает control дерева выражений;

- control свойств компонента - комплесный control состоящий из множества других. Для добавления состояний и режимов необходим control TextBox осуществляющий ввод текста. Сохраненные режимы и состояния отображаются в ListBox - control схожий с TreeView, но без учета иерархий. Для выбора из одного (тип контроля, начальное состояний/режим) - RadioButton. И для таблиц - DataGrid, control являющийся самым многофункциональным controlом таблиц в WPF. Позволяет создавать свои собственные типы столбцов и ячеек, а также привязывать к нему свои классы и предоставляет возможность внешнего изменения пользователем;

- control свойств выражений - control, частично схожий с свойствами компонентов. Также является комплексным, но содержит в себе CheckBox - control для выбора одного пункта из списка для выбора типа выражения (функция/переключатель); ListBox для отображения логического выражения и ListBox для отображения переключателей (в режиме переключателя).

Рис. 15. Макет главного окна

Второе и третье представления - значительно проще и не нуждаются в детальном рассмотрении.



4.3 Примените паттерна проектирования

Для дальнейшего проектирования разработанные ранее классы и представления необходимо преобразовать и связать с помощью паттерна MVVM.

Как ранее было сказано, данный паттерн является идеальным для проектирования приложения с применением системы WPF, так как изначально WPF разрабатывался как способ реализации MVVM. Инструментом реализации принципа раздельной от представления бизнес-логики можно назвать Data Bindings - мощный инструмент связи полей (а точнее свойств) и команд (средство, реализующее методы) различных классов и пользовательских представлений. Для реализации привязки необходимо указать объект из которого будет взято свойство и само свойство (однако на этом возможности настройки привязки не заканчиваются). При привязке данных, по умолчанию интерфейс реализуют одностороннюю привязку - изменения регистрируются только при взаимодействии с controlом, но если изменить свойство внутри программным взаимодействием (например, методом), то представление не воспримет это изменение и останется неизменным. Для решения этой проблемы была придумана технология двусторонней привязки и интерфейс INotifyPropertyChanged, который вызывает событие PropertyChanged при изменении подписанного на него свойства.

Упомянутые ранее команды - это реализация методов через привязку к свойствам. Для этой цели в WPF есть интерфейс ICommand предлагающий пользователю имплементировать под каждую команду два метода Execute (выполнение) и CanExecute (возможность выполнения). Стандартный класс визуального дерева WPF UIElement умеет реагировать на недоступность команды путем проверки CanExecute и если этот метод возвращает логический ноль, то этот элемент становится недоступны пользователю, что позволяет не делать пользователю вызвать функцию, к которой, по логике приложения, пользователь не должен иметь доступ в данный момент.

Применимо к текущему проектированию, класс компонент, являющийся моделью данных по определению паттерна, не должен напрямую привязываться к представлению. Поэтому для каждого окна и controlа содержащего список, либо комплексного controlа необходимо создать свой viewModel (возможна реализация всего функционала viewModel для каждого контроля в рамках объединяющего их окна, однако подобная практика распространена только в случае малого количества таких controlов). В связи с этой информацией, необходимо доработать диаграмму классов, до усовершенствованной диаграммы (см. рис. 16).

Рис. 16. Итоговая версия диаграммы классов

4.4 Алгоритм работы

Алгоритм работы проектируемой системы нацелен на недопущение ошибок при вводе, путем повышенной интерактивности. Иначе говоря, помимо реализации привязок модели и сбора данных с интерфейса необходимо, чтобы данные проверялись при вводе пользователем и отклонялись с информированием о причине отказа.

Одним из средств обеспечения подобной интерактивности является интерфейс IDataErrorInfo. Он основан на слежении за всеми привязанным через control ValidationRools свойствами. Для каждого свойства можно задать проверку средствами C# (см. рис. 17) и в случае несоответствия условия интерфейс выводит всплывающую подсказку (возможны и другие формы информирования).

Рис. 17. Пример реализации интерфейса IDataErrorInfo

Другим методов является ограничения доступной к вводу информации. Например, при добавлении нового выражения пользователь может указать условия перехода компонента А из состояния X в состояния Y. Ошибкой в данном случае будет указать переход из состояния X в состояние X. Чтобы исключить такую ошибку, необходимо при формировании списка доступных целевых состояний исключить первичное состояние.

Концепция “все что вы вводите - верно”, является основой алгоритма работы интерфейса. Сам по себе алгоритм взаимодействия классов очевиден из итоговой диаграммы классов, взаимодействия на уровне ниже, чем view-viewModel регламентируются библиотекой MVVM Light Toolkit и системой .NET Framework.



Заключение

В результате выполнения данной работы был разработан интерактивный интерфейс, интегрированный с модулем расчета К-РЭС. Во время проектирования и разработки использовались самые современные технологии и паттерны, которые обеспечивают высокий уровень таких показателей как:

...