Подход: построение комплекса программ

Общие принципы, проектирование, модуляризация, темплейты и шаблоны
Ответить
Аватара пользователя
Forward

Activity Tutorials Black
professional
professional
Сообщения: 337
Зарегистрирован: 03 мар 2008, 12:41
Награды: 3
Версия LabVIEW: 2010
Откуда: Кишинев
Контактная информация:

Подход: построение комплекса программ

Сообщение Forward »

Привет. Возник у меня с коллегами спорчик по одному не сложному, но и не тривиальному вопросу. Прошу по возможности не привязываться к :labview: , к какой-то конкретной операционке и даже к ПК (это может быть любое устройство), вопрос по общему подходу.
Допустим ситуция такая. Я поставляю закашчику 5 независимых программ. Они в чем-то похожи, где-то считывают данные с одного интерфейса, где-то выполняют похожую функцию, но в целом это абсолютно разные экзешки, которые одновременно работать не будут. В будущем этих программ может стать 10 или 15... Но присутствует модуль, который является абсолютно идентичным во всех этих программах. Этот модуль запускается нечасто. Ну например:
1) Ввод имени пользователя и пароля при старте
2) Калибровка
3) Настройка генератора "под себя"
4) Выскакивает инфо о фирме или какой-то хелп
В общем, случаев может быть много. Но этот модуль должен получить какие-то данные от главной программы и какие-то данные ей отдать, возможно еще приостановить один из ее потоков и т. д. Вопрос собственно по реализации данного модуля:
1) ВНУТРИ. Просто подпрограмма, которая добавляется отдельно к каждой программе. Если через месяц найдется ошибка, нужно будет перекомпиливать и переделывать целый комплекс программ.
2) СНАРУЖИ. Отдельный экзе файл, который открывается когда надо, делает свою работу и закрывается. Тут теряется целостность, добавляется гемморой с синхронизацией (если обе экзешки общаются по одному интерфейсу), ну и т.п.

Вотс и все пожалуй. Прошу просвятить по данному вопросу.
Последний раз редактировалось Forward 09 июл 2009, 12:51, всего редактировалось 1 раз.
Аватара пользователя
Eugen Graf

Activity Professionalism Silver Black
guru
guru
Сообщения: 6502
Зарегистрирован: 13 ноя 2007, 02:20
Награды: 4
Версия LabVIEW: 2009
Откуда: Saarbrücken
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение Eugen Graf »

Я бы однозначно сделал внутри, т.к. целостность программы это очень очень важный критерий. А перекомпиляция это минутное дело.
Аватара пользователя
Konstantin Sumenko

Activity Bronze
expert
expert
Сообщения: 1439
Зарегистрирован: 17 июл 2008, 12:20
Награды: 2
Версия LabVIEW: 2010
Откуда: Moscow
Поблагодарили: 1 раз
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение Konstantin Sumenko »

В данном случае (снаружи возможен вариант только в виде экзешника) я бы выбрал подход с внутренним модулем. Если рассматривать детально, то возможны случаи с внешним экзешником, например калибровку я бы делал отдельной, или менеджер лицензии и т.п.
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение Pavel Krivozubov »

Вероятность того что ошибка обнаружится, все же меньше, чем более возможные проблемы с синхронизацией и передачей данных. Да и по времени насколько я понял внутренний модуль реализовать будет быстрее. Вообщем я тоже голосую за вариант "ВНУТРИ".
toto

Activity Gold Black
professional
professional
Сообщения: 390
Зарегистрирован: 07 мар 2008, 09:26
Награды: 3
Версия LabVIEW: 6i-16
Откуда: Санкт-Петербург
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение toto »

А почему не сделать динамически подгружаемые модули?
В случае с LabView сохраняем VI без блок диаграммы и вуаля. А внутри каждой отдельной программы делаем динамический запуск VI из пути где лежит EXE. При обнаружении ошибки, достаточно выслать исправленную VI без блок диаграммы.

???
Аватара пользователя
Pavel Krivozubov

Activity Bronze
professor
professor
Сообщения: 4421
Зарегистрирован: 07 фев 2008, 16:39
Награды: 3
Версия LabVIEW: 7.0 - 2013
Откуда: г. Электросталь
Благодарил (а): 24 раза
Поблагодарили: 9 раз
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение Pavel Krivozubov »

toto писал(а):А почему не сделать динамически подгружаемые модули?
В случае с LabView сохраняем VI без блок диаграммы и вуаля. А внутри каждой отдельной программы делаем динамический запуск VI из пути где лежит EXE. При обнаружении ошибки, достаточно выслать исправленную VI без блок диаграммы.

???
но ведь в этом случае на машине заказчика должна быть установлена и сама LabVIEW?
Аватара пользователя
Forward

Activity Tutorials Black
professional
professional
Сообщения: 337
Зарегистрирован: 03 мар 2008, 12:41
Награды: 3
Версия LabVIEW: 2010
Откуда: Кишинев
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение Forward »

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

Activity Tutorials Black
professional
professional
Сообщения: 337
Зарегистрирован: 03 мар 2008, 12:41
Награды: 3
Версия LabVIEW: 2010
Откуда: Кишинев
Контактная информация:

Re: Подход: построение комплекса программ

Сообщение Forward »

Indey писал(а):но ведь в этом случае на машине заказчика должна быть установлена и сама LabVIEW?
Я сначало понял имелись ввиды динамически подгружаемые библиотеки, в винде dll, в unix - so... И моя предыдущая мессага относилась именно к ним.

Сейчас почитал повнимательнее. И честно говоря вариант немного мутный :vampire:.
Последний раз редактировалось Forward 09 июл 2009, 09:47, всего редактировалось 1 раз.
Аватара пользователя
mzu2006

Professionalism Tutorials Black
doctor
doctor
Сообщения: 2456
Зарегистрирован: 16 авг 2008, 02:12
Награды: 3
Версия LabVIEW: 7.1 10 11 12
Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
Контактная информация:

Re: Подход: построеиние комплекса программ

Сообщение mzu2006 »

Это, отчасти, определяется внутренней архитектурой программы. Если программа представяет из себя набор конечных автоматов, общающихся сообщениями - то это зависит от механизма обмена (он же механизм синхронизации). Я бы с самого начала закладывал механизм, который позволяет обмениваться сообщениями в не зависимости от того в одном ли исполняемом модуле, на одном ли хосте сидят отправитель и получатель.
Clipboard01.png

Так это выглядит в реальности (Это - вырезка из документации на последний проект)

2 исключения: если этот модуль как-то завязан на безопасность (проверка пароля, настойка защиты итд итп). Тогда - IMHO - только внутрь
и если модуль предназначен для работы в hard real-time. Тогда, скорее всего, тоже внутрь.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Модели программирования»