Название: Помогите определиться с архитектурой приложения. Отправлено: brucemax от Декабрь 07, 2012, 09:43 Ребят, помогите определиться с архитектурой приложения. Оно представляет собой программу для мониторинга и управления некоторыми станциями (связь через ethernet)(при том не известно сколько их конкретно будет.. но в пределах 2 - 10). Планируется, что будет так: на главном окне в центре присутствует схема установки, на которой рисуются некоторые параметры. Вверху ряд кнопок для выбора одной из установок для отображения. То есть схема всегда привязана к выбранной установке. Плюс ещё есть окошко с параметрами и настройками для выбранной установки. Опыта именно в проектировании структуры приложения у меня никакого. Может пнёте в сторону каких-либо конкретных паттернов.. или у кого была похожая задача ???
Название: Re: Помогите определиться с архитектурой приложения. Отправлено: kuzulis от Декабрь 07, 2012, 10:33 Use any SCADA, Luke!
Название: Re: Помогите определиться с архитектурой приложения. Отправлено: ssoft от Декабрь 07, 2012, 11:48 Самое простое, что могу предложить (если не пользоваться готовыми RPC решениями):
На каждой станции, которой нужно управлять должна постоянно работать программа-агент, через которую можно уже управлять этой станцией или собирать необходимые параметры. Программа-агент должна иметь tcp сокет для взаимодействия в качестве сервера, тогда к ней подключается приложение мониторинга, либо клиента, тогда она сама должна подключаться к приложению мониторинга. И тот и другой вариант возможен, все зависит от контекста использования. Я предпочитаю первый, тогда можно из разных программ мониторить и управлять удаленной станцией. Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть). Можно организовать удаленное сигнал-слот взаимодействие, используя например http://sourceforge.net/projects/qexremint/ (http://sourceforge.net/projects/qexremint/). Название: Re: Помогите определиться с архитектурой приложения. Отправлено: brucemax от Декабрь 07, 2012, 12:17 Самое простое, что могу предложить (если не пользоваться готовыми RPC решениями): Спасибо за помощь! В принципе это и предпологается.. я больше интересовался именно архитектурой вот этого приложения для мониторинга.. что представлять ввиде классов.. каким способом реализовтать политику "модель-представление" и т.п. Но ваша инфа тоже полезна! Спасибо!На каждой станции, которой нужно управлять должна постоянно работать программа-агент, через которую можно уже управлять этой станцией или собирать необходимые параметры. Программа-агент должна иметь tcp сокет для взаимодействия в качестве сервера, тогда к ней подключается приложение мониторинга, либо клиента, тогда она сама должна подключаться к приложению мониторинга. И тот и другой вариант возможен, все зависит от контекста использования. Я предпочитаю первый, тогда можно из разных программ мониторить и управлять удаленной станцией. Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть). Можно организовать удаленное сигнал-слот взаимодействие, используя например http://sourceforge.net/projects/qexremint/ (http://sourceforge.net/projects/qexremint/). Название: Re: Помогите определиться с архитектурой приложения. Отправлено: ssoft от Декабрь 10, 2012, 07:31 С приложением мониторинга все достаточно просто.
Нужно выделить взаимодействие с каждой станцией в отдельный независимый функционал (класс). Тогда на стороне мониторинга для каждой станции требуется: 1. Клиент - TCP сокет (свой экземпляр) - логика соединения, пересоединения в случае разрыва сети, ошибки и т.д. - логика взаимодействия с сервером (протокол) На другой стороне: 1. TCP сервер, содержащий логику соединений с клиентами 2. Представитель клиента на стороне сервера, содержащий: - TCP сокет (указатель от сервера) - логика удаления в случае разрыва сети, ошибки и т.д. - логика взаимодействия с клиентом (протокол) 3. Менеджер, осуществляющий функции мониторинга (м.б. сам сервер или объект с ним тесно взаимодействующий через агрегацию или инстанцирование) Вроде все, особо писать больше нечего. На стороне программы мониторинга можно завести объект, который владеет данными о станции (ях), либо это м.б. сам клиент (все зависит от объема данных и желания программиста). Идиому "модель-представление" или вернее "модель-контроллер-представление" применяют при представлении (обычно отображении) данных различными способами. Если интересует табличное, тогда QAbstractItemModel - QAbstractItemView. Если другое, тогда инстанцирование объекта, управляющего данными (контроллер) в GUI. В виде классов представляют отдельно: - данные ... - данные ... - логику формирования ... (ридеры, парсеры и т.п.) - логику изменения ... (редакторы и т.п.) - логику ... - представление (GUI, графики, звук, видео и т.п.) - представление ... - служебные обслуживающие структуры, облегчающие взаимодействия между предыдущими. Можно почитать готовые решения (паттерны проектирования) на разные случаи взаимодействия. Какую схему применять зависит от программиста и контекста (тонкостей) задачи. Название: Re: Помогите определиться с архитектурой приложения. Отправлено: xokc от Декабрь 10, 2012, 10:39 Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть). Для таких задач существует SNMP протокол.Название: Re: Помогите определиться с архитектурой приложения. Отправлено: brucemax от Декабрь 10, 2012, 10:50 Цитировать С приложением мониторинга все достаточно просто.... Спасибо за развёрнутый ответ! По паттернам сча вкуриваю книжку банды четырёх.. .... Цитировать Идиому "модель-представление" или вернее "модель-контроллер-представление" применяют при представлении (обычно отображении) данных различными способами. Я имел ввиду следующее: будет главная схема - "представление" (т.к. станции одинаковые, то она(схема) меняться не будет и в процессе отображения той или иной станции схеме будут кидаться соотвтетсвующие данные для отображения..). Вот меня и интересует, как именно реализовать такую архитектуру.. (но думаю справлюсь :)) Может я непонятно объясняю, но как могу. Спасибо ещё раз! Название: Re: Помогите определиться с архитектурой приложения. Отправлено: brucemax от Декабрь 10, 2012, 10:51 Между приложением мониторинга и приложением агентом необходимо организовать взаимодействие по своему протоколу (или взять готовый, если есть). Для таких задач существует SNMP протокол. |