Помогите определиться с архитектурой приложения.

[brucemax]

Ребят, помогите определиться с архитектурой приложения.  Оно представляет собой программу для мониторинга и управления некоторыми станциями (связь через ethernet)(при том не известно сколько их конкретно будет.. но в пределах 2 - 10). Планируется, что будет так:  на главном окне в центре присутствует схема установки, на которой рисуются некоторые параметры. Вверху ряд кнопок для выбора одной из установок для отображения.  То есть схема всегда привязана к выбранной установке. Плюс ещё есть окошко с параметрами и настройками для выбранной установки. Опыта именно в проектировании структуры приложения у меня никакого. Может пнёте в сторону каких-либо конкретных паттернов..  или у кого была похожая задача 

[kuzulis]

Use any SCADA, Luke!

[ssoft]

Самое простое, что могу предложить (если не пользоваться готовыми RPC решениями):

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

Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть).
Можно организовать удаленное сигнал-слот взаимодействие, используя например http://sourceforge.net/projects/qexremint/.

[brucemax]

Самое простое, что могу предложить (если не пользоваться готовыми RPC решениями):

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

Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть).
Можно организовать удаленное сигнал-слот взаимодействие, используя например http://sourceforge.net/projects/qexremint/.

Спасибо за помощь! В принципе это и предпологается.. я больше интересовался именно архитектурой вот этого приложения для мониторинга..  что представлять ввиде классов..  каким способом реализовтать политику "модель-представление"  и т.п.  Но ваша инфа тоже полезна! Спасибо!

[ssoft]

С приложением мониторинга все достаточно просто.
Нужно выделить взаимодействие с каждой станцией в отдельный независимый функционал (класс).

Тогда на стороне мониторинга для каждой станции требуется:
1. Клиент
  - TCP сокет (свой экземпляр)
  - логика соединения, пересоединения в случае разрыва сети, ошибки и т.д.
  - логика взаимодействия с сервером (протокол)

На другой стороне:
1. TCP сервер, содержащий логику соединений с клиентами
2. Представитель клиента на стороне сервера, содержащий:
  - TCP сокет (указатель от сервера)
  - логика удаления в случае разрыва сети, ошибки и т.д.
  - логика взаимодействия с клиентом (протокол)
3. Менеджер, осуществляющий функции мониторинга (м.б. сам сервер или объект с ним тесно взаимодействующий через агрегацию или инстанцирование)

Вроде все, особо писать больше нечего.

На стороне программы мониторинга можно завести объект, который владеет данными о станции (ях), либо это м.б. сам клиент (все зависит от объема данных и желания программиста).
Идиому "модель-представление" или вернее "модель-контроллер-представление" применяют при представлении (обычно отображении) данных различными способами.
Если интересует табличное, тогда QAbstractItemModel - QAbstractItemView. Если другое, тогда инстанцирование объекта, управляющего данными (контроллер) в GUI.

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

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

[xokc]

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

Для таких задач существует SNMP протокол.

[brucemax]

С приложением мониторинга все достаточно просто....
....

Спасибо за развёрнутый ответ!   По паттернам сча вкуриваю книжку банды четырёх..

Идиому "модель-представление" или вернее "модель-контроллер-представление" применяют при представлении (обычно отображении) данных различными способами.

Я имел ввиду следующее:  будет главная схема - "представление"  (т.к. станции одинаковые, то она(схема) меняться не будет и в процессе отображения той или иной станции схеме будут кидаться соотвтетсвующие данные для отображения..). Вот меня и интересует, как именно реализовать такую архитектуру..  (но думаю справлюсь ) Может я непонятно объясняю, но как могу.
Спасибо ещё раз!

[brucemax]

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

Для таких задач существует SNMP протокол.

Спасибо, посмотрим!