Привет. Возник у меня с коллегами спорчик по одному не сложному, но и не тривиальному вопросу. Прошу по возможности не привязываться к , к какой-то конкретной операционке и даже к ПК (это может быть любое устройство), вопрос по общему подходу.
Допустим ситуция такая. Я поставляю закашчику 5 независимых программ. Они в чем-то похожи, где-то считывают данные с одного интерфейса, где-то выполняют похожую функцию, но в целом это абсолютно разные экзешки, которые одновременно работать не будут. В будущем этих программ может стать 10 или 15... Но присутствует модуль, который является абсолютно идентичным во всех этих программах. Этот модуль запускается нечасто. Ну например:
1) Ввод имени пользователя и пароля при старте
2) Калибровка
3) Настройка генератора "под себя"
4) Выскакивает инфо о фирме или какой-то хелп
В общем, случаев может быть много. Но этот модуль должен получить какие-то данные от главной программы и какие-то данные ей отдать, возможно еще приостановить один из ее потоков и т. д. Вопрос собственно по реализации данного модуля:
1) ВНУТРИ. Просто подпрограмма, которая добавляется отдельно к каждой программе. Если через месяц найдется ошибка, нужно будет перекомпиливать и переделывать целый комплекс программ.
2) СНАРУЖИ. Отдельный экзе файл, который открывается когда надо, делает свою работу и закрывается. Тут теряется целостность, добавляется гемморой с синхронизацией (если обе экзешки общаются по одному интерфейсу), ну и т.п.
Вотс и все пожалуй. Прошу просвятить по данному вопросу.
Подход: построение комплекса программ
-
Forward
- professional
- Сообщения: 337
- Зарегистрирован: 03 мар 2008, 12:41
- Награды: 3
- Версия LabVIEW: 2010
- Откуда: Кишинев
- Контактная информация:
Подход: построение комплекса программ
Последний раз редактировалось Forward 09 июл 2009, 12:51, всего редактировалось 1 раз.
-
Eugen Graf
- guru
- Сообщения: 6502
- Зарегистрирован: 13 ноя 2007, 02:20
- Награды: 4
- Версия LabVIEW: 2009
- Откуда: Saarbrücken
- Контактная информация:
Re: Подход: построеиние комплекса программ
Я бы однозначно сделал внутри, т.к. целостность программы это очень очень важный критерий. А перекомпиляция это минутное дело.
-
Konstantin Sumenko
- expert
- Сообщения: 1439
- Зарегистрирован: 17 июл 2008, 12:20
- Награды: 2
- Версия LabVIEW: 2010
- Откуда: Moscow
- Поблагодарили: 1 раз
- Контактная информация:
Re: Подход: построеиние комплекса программ
В данном случае (снаружи возможен вариант только в виде экзешника) я бы выбрал подход с внутренним модулем. Если рассматривать детально, то возможны случаи с внешним экзешником, например калибровку я бы делал отдельной, или менеджер лицензии и т.п.
-
Pavel Krivozubov
- professor
- Сообщения: 4422
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Подход: построеиние комплекса программ
Вероятность того что ошибка обнаружится, все же меньше, чем более возможные проблемы с синхронизацией и передачей данных. Да и по времени насколько я понял внутренний модуль реализовать будет быстрее. Вообщем я тоже голосую за вариант "ВНУТРИ".
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
- professional
- Сообщения: 390
- Зарегистрирован: 07 мар 2008, 09:26
- Награды: 3
- Версия LabVIEW: 6i-16
- Откуда: Санкт-Петербург
- Контактная информация:
Re: Подход: построеиние комплекса программ
А почему не сделать динамически подгружаемые модули?
В случае с LabView сохраняем VI без блок диаграммы и вуаля. А внутри каждой отдельной программы делаем динамический запуск VI из пути где лежит EXE. При обнаружении ошибки, достаточно выслать исправленную VI без блок диаграммы.
???
В случае с LabView сохраняем VI без блок диаграммы и вуаля. А внутри каждой отдельной программы делаем динамический запуск VI из пути где лежит EXE. При обнаружении ошибки, достаточно выслать исправленную VI без блок диаграммы.
???
-
Pavel Krivozubov
- professor
- Сообщения: 4422
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Подход: построеиние комплекса программ
но ведь в этом случае на машине заказчика должна быть установлена и сама LabVIEW?toto писал(а):А почему не сделать динамически подгружаемые модули?
В случае с LabView сохраняем VI без блок диаграммы и вуаля. А внутри каждой отдельной программы делаем динамический запуск VI из пути где лежит EXE. При обнаружении ошибки, достаточно выслать исправленную VI без блок диаграммы.
???
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Forward
- professional
- Сообщения: 337
- Зарегистрирован: 03 мар 2008, 12:41
- Награды: 3
- Версия LabVIEW: 2010
- Откуда: Кишинев
- Контактная информация:
Re: Подход: построеиние комплекса программ
Да динамические модули - оч. хороший вариант, однако в моем случае не подходит из-за возникающих больших проблем с дебагом.
-
Forward
- professional
- Сообщения: 337
- Зарегистрирован: 03 мар 2008, 12:41
- Награды: 3
- Версия LabVIEW: 2010
- Откуда: Кишинев
- Контактная информация:
Re: Подход: построение комплекса программ
Я сначало понял имелись ввиды динамически подгружаемые библиотеки, в винде dll, в unix - so... И моя предыдущая мессага относилась именно к ним.Indey писал(а):но ведь в этом случае на машине заказчика должна быть установлена и сама LabVIEW?
Сейчас почитал повнимательнее. И честно говоря вариант немного мутный .
Последний раз редактировалось Forward 09 июл 2009, 09:47, всего редактировалось 1 раз.
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Подход: построеиние комплекса программ
Это, отчасти, определяется внутренней архитектурой программы. Если программа представяет из себя набор конечных автоматов, общающихся сообщениями - то это зависит от механизма обмена (он же механизм синхронизации). Я бы с самого начала закладывал механизм, который позволяет обмениваться сообщениями в не зависимости от того в одном ли исполняемом модуле, на одном ли хосте сидят отправитель и получатель.
Так это выглядит в реальности (Это - вырезка из документации на последний проект)
2 исключения: если этот модуль как-то завязан на безопасность (проверка пароля, настойка защиты итд итп). Тогда - IMHO - только внутрь
и если модуль предназначен для работы в hard real-time. Тогда, скорее всего, тоже внутрь.
Так это выглядит в реальности (Это - вырезка из документации на последний проект)
2 исключения: если этот модуль как-то завязан на безопасность (проверка пароля, настойка защиты итд итп). Тогда - IMHO - только внутрь
и если модуль предназначен для работы в hard real-time. Тогда, скорее всего, тоже внутрь.
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows