Здравствуйте, подскажите пожалуйста методики и софт для проектирования, построения моделей действия пользователей
Проблема - пишем ИС, делаем различные фичи, затем приходится писать в три раза больше что бы запретить пользователям обходить эти фичи или использовать их во вред, хотелось бы узнать есть ли что-то, что могло бы решить эту проблему, например инструмент, позволяющий построить модель действий пользователей на определённом интерфейсе, что бы ясно и чётко видеть как должны действовать пользователи, и где могут у них возникнуть трудности при пользовании интерфейсом, или прикрыть им возможность совершить вредоносные действия... Есть что-нибудь такое?

СидRMagistr2015,

И, конечно же, данный инструмент должен быть в курсе всех фич вашей ИС и самостоятельно определять степень полезности действий пользователей?
Защиту от дурака никто не отменял. И проектирование, чтобы пользователи просто физически не могли сделать что-то вредное. Можно же просто не показывать бухгалтеру кнопку "Удалить все данные и бэкапы", правда?

)))) Ну я имел ввиду наличие какой-нибудь описательной методики с софтом для отображения всего этого в виде сущностей и связей между ними - это как пример, эти сущности можно самому добавлять в общую схему и настраивать связи с остальными элементами интерфейса, заранее добавленными в общую схему в виде других сущностей, ну как-то так рисуется в моём представлении )))
А как на самом деле обстоят дела? Есть какой-нибудь инструмент или методика для решения подобной проблемы? Ну может какой-нибудь инструмент для описания "карты действия пользователей"... Что-то в этом роде....?

СидRMagistr2015,

Я обычно при разработке задаю себе и другим вопросы:
1) кому это надо?
2) зачем это надо?
3) что такое хорошо?
4) что такое плохо?
5) а что если какой-то $%& сделает то, что мы не предусмотрели?

Собственно, задача разработчика ИС - предусмотреть все возможные варианты, все невозможные и пару сотен невероятных ещё на этапе проектирования. И отсекать всё лишнее, чтобы упомянутые кнопки не возникали у пользователей, которым они не нужны в работе.

Что касается модели поведения, я её обычно рисую на клочке бумаги в наиболее понятном для себя виде. Это если в голове не умещается.

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

СидRMagistr2015,

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

Кстати, ещё один момент, который автоматически даст ответы на кучу вопросов начиная от логики и заканчивая UI и юзабилити. Когда запилили фичу, начните ей активно пользоваться. Если подразумевается рутинная работа, попробуйте сделать однотипное действие 100 раз подряд. Ставьте различные и порой нестандартные задачи и сами попытайтесь их решить при помощи ИС. Если всё получится и ничего не взбесит, можно запускать в эксплуатацию)))

Спасибо Вам большое за помощь, очень Вам благодарен
Есть ещё один вопрос, у нас в системе разрабатываются модули, и практически каждый из них обладает большим функционалом
Есть ли способы или методики описания этих модулей, так, что бы все эти возможности были наглядно представлены, в них было легко ориентироваться, отслеживать и контролировать связи с другими модулями, при этом что бы не было похоже на большую запутанную паутину....?

СидRMagistr2015,

Вот это довольно сложно и просто на словах не описать. Может, лучше посадить реального пользователя, а не профессионального тестировщика, чтобы он задал вопросы и может быть подсказал, что, по его мнению, сделает модуль очевидным? Может, там надо всего лишь добавить 1 колонку в табличку, а половину остального удалить))) я работаю на внутреннего заказчика, и вижу в этом подходе кучу плюсов. Когда работал нв внешнего, да и под руководством ПМ, было гораздо тяжелее.
Сложные взаимосвязи, как вариант, обыграть интерфейсом, чтобы казалось, будто там всё и ежу понятно))

Ясно, спасибо за понимание ))
Если говорить в целом, то на сегодняшний день у нас проблема следующая - Есть большая, уже разросшаяся система, кое как на спех написанные инструкции и три программера, каждый из которых делает сугубо свой кусок системы и о соседнем мало что знает - в связи с этим возникает много проблем, одна из которых сложность донесения информации о строении "соседней" части системы до данного программера, т.е. практически ни кто не знает как система работает, но вопросы возникают, и на них нужно отвечать оперативно
Решили как-то описать систему, но как?
стали описывать с помощью сущностей (модули системы) - получилась огромная паутина с множеством связей, которые в принципе не уберёшь, потому как они являются критичными для понимания функционирования определённого модуля, а при этом хочется достичь результата абсолютной прозрачности в описании, что бы необходимая информация находилась за минимум времени, и таки положить в голову всех программеров общий функционал системы, что бы все всё понимали
Как-то так ((

СидRMagistr2015,

Мне такая проблема только предстоит, я и сам заранее ломаю голову, как это всё будет. Сейчас работаю один, начиная от совещаний с руководством и пользователями, и заканчивая собственно разработкой и поддержкой ИС. Всё в одном. Есть планы по расширению влияния нашей ИС, и проблема, когда несколько человек делают отдельные модули, тоже встанет остро)))
Случай из прошлого: работали мы как-то в паре с одним товарищем над всё той же системой, и дал нам ПМ задачки не зависимо друг от друга. И так получилось, что мы тронули один и тот же модуль, после чего пошло это всё дружно в продакшн, естественно, наложившись друг на друга. Тогда у заказчика работу целого отдела парализовали на полдня)))
Теперь по теме. Реально нужно программистам вкладывать в голову, как работает система. Начиная от текущего куска, и дальше вглубь по взаимосвязям с другими модулями. Пусть уделяют этому больше времени (будут собственными же юзерами, которым отвечатель-на-вопросы всегда поможет). Без понимания, как это всё работает сейчас и как должно работать в будущем, вообще нельзя писать или править код. Вопрос лишь в том, насколько глубоко нужно знать взаимосвязи для текущей задачи.
Ответы на вопросы - это самый простой и удобный способ (ИМХО). В документации всё равно не опишешь вообще всё, что там наворочено. А даже если опишешь, то программист может не понять или неправильно понять терминологию, какие-то фразы, а может просто не найти нужное только потому, что написано другими словами (опять же ИМХО).
Я на примере нашей ИС (медицинской) даже не представляю, сколько всего нужно засунуть в документацию, которой, кстати, тоже пока нет, и мы ещё мечтаем о специальном человеке, который всё опишет (и задаст по пути 100500 вопросов, на которые мне же и придётся отвечать... хнык!)
Вполне возможно, что проблему решит немножко другая организация работы. А именно - наличие 100% доступного отвечатель-на-вопросы-программистов, который знает всю систему и не выезжает на всяческие совещания, в командировки и т.д. Есть вопрос - получи ответ немедленно. Иначе работа программиста просто встаёт, он ждёт возврата отвечателя-на-вопросы, т.к. от его ответа зависит вообще всё.

Напиши мне, брат, мы вместе решим эту проблему
R-Magistr2015@yandex.ru
поделимся опытом и реализуем и твои и мою системы ))))

Напиши в теме что ты с форума )))

hVosttRMagistr2015,

Разрабатывать по принципу: всё, что явно не разрешено -- запрещено.

Ну мы в принципе так и делаем, поэтому приходится вешать ещё кучу проверок на кодд ))) Спасибо большое )))

BoatmanНе до конца понятна проблема.
На том уровне, как я ее понял: вам нужны сценарии вариантов использования с детальным анализом альтернативных сценариев.
Мануал: А.Коберн, Современные методы описания функциональных требований к системам
Спасибо большое, обязательно прочитаю )))

hVosttdimonz80Надо иметь 2 API: внутренний и внешний. Внутренний - для реализации бизнес логики без оглядки на безопасность. Внешний - для пользователей, т/е некоторое представление возможных действий пользователя. Классический случай - MVC. Модель имеет внутренний API. Контроллер - внешний. Где-то в районе контроллера реализуется слой безопасности. Кроме того, внешний API - это то, что надо можно смело тестировать на защиту от дурака.

А ещё можно внедрить ABAC, который позволяет реализовывать бизнес-правила безопасности, а не только на уровне ролей, клеймов, CRUD-матриц у других атрибутов безопасности. И это будет один единственный модуль на все-все случаи.
Круто, спасибо большое, обязательно попробую )))

dimonz80hVosttпропущено...


Поэтому надо убирать «кучу проверок» и внедрять один единственный изолированный модуль безопасности, который будет отвечать можно, или нельзя. И ответ «нельзя», это ответ по умолчанию.

+2

Надо иметь 2 API: внутренний и внешний. Внутренний - для реализации бизнес логики без оглядки на безопасность. Внешний - для пользователей, т/е некоторое представление возможных действий пользователя. Классический случай - MVC. Модель имеет внутренний API. Контроллер - внешний. Где-то в районе контроллера реализуется слой безопасности. Кроме того, внешний API - это то, что надо можно смело тестировать на защиту от дурака.

ТС, поделись хоть технологиями, на который верстаешь свой шыдевр. Может проблема-то уже и решена.
Это чисто на T-SQL )))

alex55555RMagistr2015Проблема - пишем ИС, делаем различные фичи, затем приходится писать в три раза больше что бы запретить пользователям обходить эти фичи или использовать их во вред
Решение - грамотное проектирование. Но вам, конечно же, по прежнему ничего не понятно? Ну что-ж поделаешь - либо вы становитесь грамотным проектировщиком (лет через цать), либо вы находите способ убедить себя в том, что некий кандидат Вася Пупкин и есть тот самый гений (за те самые деньги, которые вам не жалко ему отдать).

Дело было на прошлой работе ))))

RMagistr2015alex55555пропущено...

Решение - грамотное проектирование. Но вам, конечно же, по прежнему ничего не понятно? Ну что-ж поделаешь - либо вы становитесь грамотным проектировщиком (лет через цать), либо вы находите способ убедить себя в том, что некий кандидат Вася Пупкин и есть тот самый гений (за те самые деньги, которые вам не жалко ему отдать).

Дело было на прошлой работе ))))
Не я за это отвечал ))) И слава богу ))

dimonz80hVosttпропущено...

Что значит притягивать? Если не обеспечить прозрачный доступ к атрибутам, то будет трудно работать с безопасностью в любом случае, если захочется иметь централизованную безопасность. А роли/клеймы слишком деревянные и редко когда соответствую реалиям, поэтому начинается жёсткое "внедрение" безопасности прямо в недра кода. Пока что ничего удобнее ABAC, с достаточной гибкостью, не встречал.

Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))


Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))


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

Продукт устаревший - Lexema 5.5 Делфийная приблуда с БД на MS-SQL
В общем-то если там конкретно рассматривать объекты, то это кнопки поля,списки, документы, правила, отработки, отчёты, запросы. Код пишется прям в кнопке и хранится в полях БД, где ему можно спокойно делать Update, выносить в процедуры пробовал, и давать на них права то же, потом устаёшь искать где какой код применён в документе, так как опять же если что-то просят поправить, то это нужно делать быстро и без встроенной системы поиска в самой Lexemа не обойтись, а она не ищет в процедурах, нужно свой инструмент клацать под это. в общем тут сложности
Отсюда и сложность с доступам к объектам, как например нужно что-то совместить среднее с быстрым поиском кода для его правки и централизованным администрированием этих самых правил.

dimonz80hVosttпропущено...


Что значит притягивать? Если не обеспечить прозрачный доступ к атрибутам, то будет трудно работать с безопасностью в любом случае, если захочется иметь централизованную безопасность. А роли/клеймы слишком деревянные и редко когда соответствую реалиям, поэтому начинается жёсткое "внедрение" безопасности прямо в недра кода. Пока что ничего удобнее ABAC, с достаточной гибкостью, не встречал.

Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))


Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))


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

Но мы немного отошли от темы, вопрос был о том, как предугадать какие действия может совершать пользователь? Как смоделировать его действия? Описать в автоматическом режиме сценарии его поведения...? Есть ли такой софт?

hVosttdimonz80Притягивать значит сопоставлять атрибуты объекта и субъекта, чтобы определиться что можно а что нельзя. Атрибутов мильон зачастую особенно у объекта. Кроме того, если наша система атрибутного доступа позволяет дергать атрибуты атрибутов атрибутов, то может лихо просесть по произволительности. А так да - гибкость жуткая. И сложность реализации тоже))

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


dimonz80Лично мне думается что система прав доступа должна быть максимально плоской. Например для веба это что-то типа фильтрации по URL например "редактировать документа с id = <id> значить дергать URL /document/<id>/edit".
Если возникает проблема что надо редактировать документ с датой создания не ранее месяца назад (вот он атрибутный доступ, да) то придется расширять пользовательский API и добавлять URL /document/<id>/editLastMonth например и прописывать правила доступа для него. Достаточно "жёсткое "внедрение" безопасности прямо в недра кода"))))

Представь, что:

1) самых разных политик много
2) политики меняются почти каждый день, это естественный жизненный цикл
3) политики могут быть очень сложные, накладываться друг на друга, одни политики могут исключать или дополнять другие
4) периодически надо совершенно определённо сказать, что можно и что нельзя
5) ещё часто надо сказать, а на каком основании вот это можно или нельзя, кто так решил? почему? когда?

Теперь соотнеси это с безопасностью, описанной в коде. Для несложной системы подойдут роли, для системы по-сложнее подойдут клеймы, для CRUD-приложений подойдут матрицы безопасности. Но все эти модели деревянные и не решают ни один из приведённых мною пунктов.

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

Поэтому мы отказались от затеи разделять правила бизнес-логики и системы безопасности. Всё одно.
Мы то же пробовали отказаться от такого разделения, в итоге пришли к каше ))) Где все вместе валяется и непонятно когда всё это закончится, а самое главное,как в этом разобраться. Это конечно хорошо, программер всегда трудоустроен, но вот надо же как-то разбирать этот бардак, а то так недолго и с работы вылететь за несвоевременное выполнение обязанностей, как например - вспомнить что где лежит, кто это придумал, а потом передумал в самом далёком отделе, в самом удалённом кустке системы 3-и года тому назад? И ответ чтоб был через 5-ть минут, потому как тут инвесторы приехали, и им надо знать сейчас же... Как быть?

[quot dimonz80]RMagistr2015Если не хотите переделывать как положено, то можно использовать автокликеры, например такие
Вы уже пробовали использовать эти автокликеры? Настраивать их что-то с ними делать? Как-то разрабатывать их?

hVosttRMagistr2015Но мы немного отошли от темы, вопрос был о том, как предугадать какие действия может совершать пользователь? Как смоделировать его действия? Описать в автоматическом режиме сценарии его поведения...? Есть ли такой софт?

Есть такое понятие, как «тестирование». Садишь команду тестировщиков и они ищут баги, дыры, проверяют все возможные сценарии использования. Интеграционные тесты пишутся вручную и проверяются конкретные кейсы, искусственного интеллекта для тестирования пока не разработали.

А вообще каие нейронные сети можно натаскать на подобного рода задачи?
Какого вида эти нейронные сети существуют и какие из них больше всего подходят под решение подобных задач как например автокликанье и проверка всех сценариев пользователя?

dimonz80пропущено...


Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )

RMagistr2015dimonz80пропущено...


Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )
Госпада, не жадничайте знаниями, помните, что чем больше вы отдаёте знаний во время обсуждений,тем больше истины приходит к вам, потому как идёт проверка на неадекватность Ваших же знаний, а в итоге расширяются горизонты, и вы сможете узнать, понять, а в итоге и предложить как специолист гораздо больше )))))
Так что не жадничайте знаниями )))) Делитесь опытом ))) И бродите по планете ))))

RMagistr2015dimonz80пропущено...

Пробовали как раз для эмуляции действий пользователей пару лет назад.
Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )

Так же для особо жадных на знания хочу напомнить, что любая Ваша мысль высказаная другим человеком вперёд Вас, Вам уже не принадлежит, а соответственно, не вы будете принимать участие в её реализации )))) Так что прежде чем смолчать, всегда подумайте ))) А стоит ли это того ))))))))))

dimonz80RMagistr2015пропущено...

Что пробовали? какой результат получился? Поделитесь пожалуйста опытом... )

Использовали AutoHotKey. Там делаешь скрипт, компилишь в Exe. Запускаешь exe. Запускаешь свою прогу и по хоткею, заданному в скрипте, запускаешь некоторые действия типа нажатия кнопок, кликов мышей etc. Просто читаем мануал и делаем - все просто. Никакой магии.
Для веб приложений она то же подойдёт? Есть в ней нейронка?
Использовали ли кто-нибудь нейронные сети для этих задач?

Никанор КузьмичRMagistr2015А вообще каие нейронные сети можно натаскать на подобного рода задачи?Вы основы PL/SQL неспособны осилить, куда вам в нейросети...

Это совсем другая тема )) Человек всегда учится и всегда развивается ))) На что человек способен на что нет, решает только он сам, Вам спасибо большое за помощь в других моих темах )))
Можно ли к предложенному Вами инструменту прикрутить нейронку?))

dimonz80RMagistr2015пропущено...

Для веб приложений она то же подойдёт? Есть в ней нейронка?
Использовали ли кто-нибудь нейронные сети для этих задач?

Для web использовал iMacros - это плагин для броузеров, очень простой в использовании. И селениум для авто тестов.
Какие нейронные сети??? Один брякнул, второй раскрывши рот слушает))). Не нужны тут нейронные сети. Никак!

Общий смысл автокликеров - проиграть сценарий и (опционально) - проанализировать получившийся результат. И все.
Ну как бы да, вот только писать каждый раз новые сценарии очень затруднительно, пусть он сам учится на основе полученного опыта о том, как ему тестировать новый разработанный и подсунутый ему интерфейс. Так он станет умнее, и будет тестировать все и на все варианты ))) А это только нейронка ))

RMagistr2015dimonz80пропущено...


Для web использовал iMacros - это плагин для броузеров, очень простой в использовании. И селениум для авто тестов.
Какие нейронные сети??? Один брякнул, второй раскрывши рот слушает))). Не нужны тут нейронные сети. Никак!

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