Помощь в архитектуре ПО?

Друзья, нужны советы в проектировании архитектуры ПО, чтоб потом не было мучительно больно.
Программа, которая управляет стендом для тестирование некоторых железок.
Подсистемы планируются примерно такие:
  1. Печать этикеток
  2. Управление стендом по ModBus
  3. Запрос серийного номера с сервера
  4. Отправка отчета на сервер
  5. Логирование исключительных ситуаций
  6. Логирование хода теста
  7. Графическое отображение хода теста
  8. Сам тест

Для удобства работы думаю использовать паттерн "Фасад", не знаю впишется или нет.
Самая важная часть это тест оборудования, который может состоять из многих подтестов. Думаю сделать интерфейс типа ITest:
interface ITest
{
    void Run();
    Result Result();
}

И реализовывать его в классах подтестов.
Устройств много, для того или иного устройства нужно использовать разные подтесты. При чем включать/отключать подтесты нужно без изменения кода. Думаю может описать интерфейс:
interface IDeviceForTest
{
   bool SelfTest {get; set;}
   bool PowerTest {get; set;}
   ...
   void Test();
}

Потом реализовать интерфейс
class Device1 : IDeviceForTest
{
    public bool SelfTest {get; set;} = true;
    public bool PowerTest {get; set;} = true;
    public void Test() 
   {
       if (SelfTest)
       {
            var selftest = new SelfTest();
            selftest.Run();
       }
...
   }
}

Сериализовать объекты устройств в json и во время запуска восстанавливать объект с возможными правками (вкл/откл) json-файла подтеста.
В общем неуклюже И не очень понятно, как лучше получать результат теста, чтобы логику обработки результата не делать в классе устройства. Тестирование всего устройства нужно останавливать, если какой-то подтест не пройден. Что посоветуете?
  • Вопрос задан
  • 319 просмотров
Решения вопроса 1
Если правильно понял задачу, то:
1) Создаем интерфейс ITestDevice, который будет единым для всех железок.
2) Для каждой железки создается свой адаптер, который реализует ITestDevice. В нем учитываются особенности каждой железки, и подгоняются под единый интерфейс.
3) Каждый девайс должен иметь свой уникальный Id (GUID/int32/string). Инициализируется этот Id в адаптере, или в классе устройства, который используется в адаптере.

4) Создается интерфейс ITest. Он единый для всех тестов.
5) Создаем тесты.

6) Забиваем пары Id_testDevice - Id_test в храналище данных.
7) Запускаем приложение, оно читает данные из хранилища, и передает каждому ITestDevice свои списки тестов, затем запускает их.

ITestDevice - имеет список тестов (ITest) которые он запускает.
ITest - может быть как атомарным тестом (1 шт), так и композитным (внутри себя содержит список других тестов, без фанатизма и рекурсий)).
Если есть тесты только для конкретных девайсов, то тестам можно прописать типы, и проверять их (иерархией или полем type).

А) Если тест не пройдет, то девайс завершает прогон. Это делает сам дейвайс, который смотрит на возвращаемое значение каждого теста, перебирая их в цикле. У теста может быть булево свойство Success.
Б) Или можно сделать TestManager, который получает ITestDevice и его список ITest, и по одной штуке в цикле начинает скармливать тесты девайсу (например в метод ITestDevice.Run(ITest test)), проверяя результат, записывая в лог и решать продолжить тестирование или перейти к следующему дейвасу. Такой подход отделит правила прохода набора тестов от самого девайса, менеджер может получать их из хранилища.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
от 130 000 до 200 000 ₽
ITM Холдинг Екатеринбург
от 60 000 до 80 000 ₽
GD Company Санкт-Петербург
от 120 000 до 150 000 ₽
07 апр. 2020, в 14:26
5000 руб./за проект
07 апр. 2020, в 13:42
1000 руб./за проект
07 апр. 2020, в 13:40
700 руб./в час