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

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

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

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

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

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

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

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

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

• 1. Название — как видно из пункта 2.2.2 (далее вся информация о данных классов будет взята оттуда), где приведен пример построения модели изделия, у изделия, как и у всех остальных элементов модели есть название;
• 2. Состояния — у изделия есть список состояний, в котором обязательно должно быть минимум два состояния — состояние отказа и работы.
• 3. Режимы — у изделия есть список режимов, в котором необходим минимум один режим;
• 4. Начальное состояние — у изделия необходимо выбрать одно начальное состояние (не отказа);
• 5. Начальный режим — у изделия есть начальный режим, являющийся обязательным требованием;
• 6. Тип контроля — поле, отвечающее за способ перехода изделия между состояниями: по функции или закону распределения. Но так как изделие всегда работает по функции, то данное поле избыточно;
• 7. Таблица перехода состояний — таблица, отображающая возможности перехода изделия из одного состояния в другое.

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

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

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

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

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

• — выделить общие данные из классов «компонент» и «изделия» в третий класс и агрегировать его внутри первых двух;
• — класс «выражения» выполняет функцию сразу двух реальных объектов: функции и переключателя. Значит, необходимо перевести его в разряд абстрактных и наследовать от него два новых класса реализующих функции и переключатели.