Есть электронный прибор с микропроцессорным управлением.
К прибору могут прикладываться самые разные люди, с разной квалификацией и полномочиями. Для этого я ввожу в систему такое понятие как уровень доступа (Level_0, Level_1, Level_2,..Level_Х)
Но помимо этого у прибора есть определённый функционал, функции которого обрабатывают например клавиатуру, датчики, ЖПС модуль, элементы индикации, исполнительные ус-ва, реле и т.д.
С разных уровней доступа, человек который работает с прибором, может рассчитывать на разный функционал. Другими словами сами логика и правила управления прибором должны учитывать уровень доступа пользователя в системе.
Скажите, как правильнее реализовать (запрограммировать) обработку и функционала и уровня доступа? Я говорю о решении ,которое будет удобно тестировать и отлаживать.

У меня есть идея поместить управление всеми элементами индикации, всеми реле и другими исполнительными устройствами в одну фукнцию, а перед всеми входными воздействиями поставить как своего рода фильтр другую функцию. И тогда уже внутри этих функций, в соответствии с уровнем доступа, принимать решения о функционале в соответствующем уровне.
Что это даст:
а) я пишу функционал так как будто нет никаких уровней доступа (но в тех местах где я что-то получаю либо чем-то управляю из алгоритма, делаю это не напрямую, а через эти функции "пробки")
б) я экономлю на объеме кода (оч. актуально в моем случае)
в) сопровождать/править/отлаживать легче

Не факт что так правильно, но если че поправьте. Спасибо!

ну так просто и организуйте - глобальная переменная access_mode определяет уровень доступа, в нужных местах проверяется и в зависимости от значения выполняется конкретная ветка кодаа вот это не стоит делать. Программу лучше делить на максимально независимые модули - так намного легче тестировать, модифицировать и т.д. Проверено на собственной шкуре

глобальная переменная естественно будет, но зачем проверять ее значение на каждом повороте алгоритма? Выписывать все эти ифы на каждом углу? Не правильнее ли вынести принятие решения в две функции: одна из которых отфильтрует входные данные в систему ,а вторая ограничит список выходных данных из системы?

Ну например: админ имеет уровень доступа 4, это максимально возможный уровень, а простой пользователь уровень 2.
Админ может перепрограммировать время на которое будет включен например соленоид, а юзер не имеет таких прав.

Вы предлагаете в функции, которая может изменить время сработки, установить проверку уровня доступа, и только лишь пользователям с 4м уровнем (админам) разрешать ее выполнение? А почему эта функция вообще выполняется? Может быть сам вызов ее для пользователя с 2м уровнем запретить? Мы ведь можем просто не пропустить далее по алгоритму эту попытку, имея фильтр на входных воздействиях!
Понимаете что я вообще имею в виду?

в таком случае для переменных пишется табличка с битовыми масками уровня доступа, при просмотре/редактировании маска переменной сравнивается с текущим уровнем доступа и решается нужно ли отображать/редактировать переменную. Никаких проверок на каждом углу, только в одном месте

хм. вся фильтрация осуществляется еще на уровне юзверьского междумордия. и именно в этом модуле принимается решение о манипулировании настройками и даже показом пунктов меню. весь остальной алгоритм пребывает в счастливом неведении об уровнях доступа и прочей ереси. пришла команда зажечь светик - сделано. а вся забота о разграничении прав подать такую команду - на UI (user interface) и связанном с ним модулем разграничения доступа...

Все верно, но встречаются (в частности у меня) ситуации, когда входными, по отношению к системе, являются не только данные с клавиатуры! Ну например асинхронный канал связи по которому передаются команды в систему, ну например информация с датчиков, органов управления и т.д.
получается, что необходимо встраивать механизм разграничения по правам в каждый из этих входных каналов связи?
А выходными параметрами системы никак по Вашему не нужно управлять в разрезе прав доступа?
А как быть если например прибор находится в состоянии с уровнем доступа для пользователя, и этот самый пользователь, нажимая кнопки на приборе, поворачивает стрелу крана, а с правами администратора те же кнопки нужны для навигации по меню и/или переконфигурировании прибора?
Или вот например у меня права доступа "все прочие" должны обязательно сопровождаться отсутствием какой либо индикации на приборе! В конце концов прибор может сформировать результат некоего внутреннего вычисления, исследования, замера но результатом поделиться только лишь с соответствующими пользователями. Можно еще много всего придумать, я уверен, что выходные параметры прибора должны быть под надзором системы разделения прав.

А может все таки наложить некую комбинацию "фильтров" на входные и выходные воздействия системы в соответствии с правами пользователей?

входное воздействие - интерфейс [суть способ преобразования, в т.ч. алгоритм, в т.ч. контроль прав] - внутренние параметры устройства

внутренние параметры - интерфейс [суть способ преобразования, в т.ч. алгоритм, в т.ч. контроль прав] - данные наружу

---

внутренняя работа, функционал как таковой - зависит только от внутренних параметров.
любое внешнее воздействие попадает на вход интерфейса; больше ни на что не влияет.
внутренние параметры изменяются только через интерфейс; больше никак.
внутренние параметры сами по себе снаружи не видны.

интерфейс = способ преобразования внешнего воздействия, данных - в внутренние параметры. и/или обратно.
любой способ. хотя бы даже и махание стрелой крана.

... махание стрелой крана - не интерфейс, а внутренняя работа, функционал как таковой.
который зависит только от внутренних параметров.
которые могут изменяться только через интерфейс.
в котором уже проверены права.

Сообщение отредактировал нечитатель - Apr 22 2011, 04:03

Все хорошо, вот только термина "функционал" в родном русском языке - нет!!!
А вот здесь он есть: http://iosifk.narod.ru/slovar_feni.pdf
Почитайте, может пригодится...
Удачи!

Мне всегда все эти поползновения борцов за чистоту языка, напоминали усилия Геббельса направленные в русло работы с чистотой нации.
Спасибо большое за ссылку, но меня интересовали вопросы функционала и прав доступа в одной системе.

У меня есть меню, набор элементов в нем зависит от кода доступа.
Реализуется это абсолютно очевидно, при входе ставятся соответствующие флаги и все входы заносятся в журнал:


Эти флаги потом тупо и банально анализируются при хождении по меню.


Короче, простое и тупое программирование.
Успехов

Нет, это не правильный подход как мне кажется. А что если права доступа кучерявые, а что если пунктов меню тысячи? Я с трудом вкуриваю такие алгоритмы.

Значит вот что я решил:
все входные, по отношению к системе, воздействия я "завожу" в функцию "А", которая просто фильтрует эти воздействия в соответствии с правами доступа. Другими словами не пропускает далее по алгоритму ничего кроме того, что соответствует уровню доступа. Таким образом мы убираем лишние процессорные проверки и издержки в алгоритмах. Далее отфильтрованные воздействия попадают на функцию "Б" ,которая в зависимости от прав доступа и входного воздействия формирует команду. Функционал построен по смыслу, как обработчик команд и что важно построен для максимально возможных прав. Никаких проверок на права доступа в функциях и алгоритмах, все вынесено на вход системы. По поводу выходных интерфейсов ,пока не ясно , нужно применительно к задаче будет решать. В текущей работе можно обойтись и приведенной моделью.
Функцию А и Б можно было бы совместить, но явно просматривается необходимость просто фильтровать воздействие и строить команды на основе конкретного входного воздействия в совокупности с информацией о уровне доступа.

Тогда жаль

Если права доступа растут монотонно, то нет проблем - мы их нумеруем по порядку возрастания прав, а каждому пункту меню присваеваем минимальный разрешенный "идентификатор права", с которым выполняется этот пункт. Если существующий идентификатор меньше - пункт не выполняется, если равен или больше - выполняется.
У меня и механизмы все заложены, нет только потребности.

Для настройки кучерявых прав нужен кучерявый человек. Который будет профессионально специализироваться на их настраивании.
А лошадь в вакууме умрёт, хоть даже она и сферическая. Потому что дышать нечем.

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



Реализация конкретно меню пользователя это одна из возможных комбинаций функционала и прав доступа, и конкретно этим вопросом я пока не занимался. Однако ,как мне кажется, проверки на каждой из веток не оч. хорошая реализация. Но чтоб с уверенностью что-то сказать ,нужно сделать лучше.
Спасибо за участие в моем вопросе.

"Как мне кажется", в последнем своем сообщении я не говорил о проверке в каждой ветке.
Ветка имеет свойство "идентификатор доступа", а проверять его можно в одном месте, при переходе на ветку.
Спасибо, что выслушали