Краткое введение в моделирование бизнес-процессов
Часть 3. Разграничение доступа к данным
Разграничение доступа к данным: требования
Разграничение доступа к данным: возможные реализации
В предыдущих статьях данного цикла (см. КомпьютерПресс № 8 и 9’2007) мы обсудили области применения моделирования бизнес-процессов, перечислили основные методологии моделирования и наиболее часто применяемые в нашей стране инструменты моделирования, а также некоторые аспекты моделирования общего характера, касающиеся создания целостного непротиворечивого набора моделей и методов хранения самих моделей. В настоящей статье мы продолжим обсуждение технических аспектов моделирования бизнес-процессов, а именно вопросов разграничения доступа к данным.
Разграничение доступа к данным: требования
Мы уже знаем, что для всестороннего описания деятельности даже небольшого предприятия нужны сотни моделей. Но если задача, решаемая с помощью моделирования, и не преследует цели всестороннего описания деятельности компании, как правило, она все равно решается путем применения отнюдь не одной-единственной модели — не зря же придумано так много разных типов этих самых моделей.
Как только число моделей бизнес-процессов, требующихся для решения задач предприятия, превышает десяток, а авторов моделей становится больше чем один, вопрос разграничения доступа авторов моделей к данным становится весьма актуальным.
Во-первых, разграничение доступа к данным снижает возможный ущерб от неумышленного их повреждения теми же авторами моделей. Это означает, что при организации работ по моделированию нужны средства, разрешающие или запрещающие определенным пользователям или группам пользователей редактировать конкретные модели.
Во-вторых, нередко данные, которые используются при моделировании, могут носить конфиденциальный характер (например, организационная структура предприятия, информационные системы, применяемые при автоматизации ключевых процессов, сведения о топологии локальной сети) и их желательно предоставлять ограниченному числу пользователей. Это означает, что нужны средства, позволяющие разрешить или запретить пользователям не только редактировать определенные модели, но и просматривать их, а в ряде случаев — и знать об их существовании.
В-третьих, при решении ряда задач могут потребоваться не все предоставляемые выбранным средством моделирования типы моделей, объектов, связей между ними, и в этом случае было бы желательно ограничить доступ пользователей к этим типам, дабы у них не возникло соблазна создать модель или объект, относящийся к не предусмотренному проектом типу — например сделать недоступными соответствующие интерфейсные элементы или элементы списков в средстве моделирования.
 |
|
Разграничение доступа к данным: возможные реализации
Как учесть перечисленные выше требования? Одним из вариантов реализации первого и второго требований при использовании средств моделирования, хранящих модели в отдельных файлах, может быть применение средств разграничения доступа к файлам, предоставляемым операционной системой соответствующего файлового сервера. В этом случае средства управления доступа к моделям представляют собой средства администрирования операционной системы. Это означает следующее: либо задачи по разграничению доступа к моделям возлагаются на системного администратора, либо права администрирования соответствующих папок предоставляются кому-то из членов проектной группы. Оба организационных решения имеют свои достоинства и недостатки, однако, поскольку подавляющее большинство современных средств моделирования (включая и такой популярный в нашей стране инструмент, как Microsoft Visio) по-прежнему хранит свои модели в отдельных файлах, они применяются достаточно широко.
Если же средство моделирования хранит данные в серверной СУБД, задача по разграничению доступа к моделям, как правило, решается отнюдь не средствами администрирования СУБД. Причина этого заключается в следующем. С одной стороны, разграничение доступа к данным пользователей СУБД обычно осуществляется на уровне таблиц, представлений и процедур. С другой стороны, модель данных такой СУБД, какой бы подход к ее созданию ни был выбран, все же вряд ли окажется спроектированной таким образом, что для каждой модели будет создана отдельная таблица. Подобный подход к проектированию противоречит всем разумным принципам, включая принцип нормализации данных, а ведь он так популярен именно потому, что следование ему упрощает их ввод и сопровождение. Скорее всего, в гипотетической базе данных, хранящей модели, должна быть таблица со списком моделей. Разграничение доступа к моделям в этом случае означает, что разным пользователям нужны различные права на разные записи в этой таблице, а средства администрирования СУБД такой возможности не предоставляют.
Существуют различные способы решения этой задачи: от создания в базе данных представлений, зависящих от учетной записи пользователя, обращающегося к этому представлению, до реализации подобных средств защиты вне СУБД в серверах промежуточного звена. При любом способе реализации разграничения доступа к данным, выбранном разработчиками средства моделирования, ими же поставляются и соответствующие средства управления учетными записями и правами пользователей.
Примером реализации ограничения доступа к данным с помощью сервера промежуточного звена являются средства моделирования семейства ARIS компании IDS Scheer. Как мы уже упоминали в предыдущей статье данного цикла, продукты данного семейства осуществляют хранение моделей в серверной СУБД, доступной клиентским приложениям посредством обращения к серверу промежуточного звена. Средства управления учетными записями и правами пользователей встроены в сами инструменты моделирования этого семейства (рис. 1).
Рис. 1. Средства управления учетными записями в ARIS Business Architect
Для реализации третьего требования при моделировании тоже можно применять различные технологии. Так, для Microsoft Visio можно формировать наборы символов для конкретного проекта и рекомендовать авторам моделей использовать только их. Но намного более надежной является реализация, не предполагающая никаких рекомендаций, то есть технически ограничивающая доступ к типам моделей и объектов. Подобная возможность реализована, к примеру, во всё тех же инструментах семейства ARIS. Она заключается в создании так называемых методологических фильтров — XML-документов, содержащих допустимые списки моделей, объектов, символов и связей. Подобные фильтры создаются исходя из потребностей конкретного проекта, а затем пользователям присваиваются права на доступ к моделям с применением этих фильтров. Таким образом, пользователю при моделировании становятся доступны только типы моделей, объектов и связей, заранее определенные в фильтре, через который он «видит» модели в базе данных, с которой работает (рис. 2 и 3).
Рис. 2. Средства создания методологического фильтра в ARIS Business Architect: ограничение доступных пользователю типов моделей
Рис. 3. Средства создания методологического фильтра в ARIS Business Architect: ограничение доступных пользователю символов для выбранных типов моделей
Фильтр содержит константы — коды типов моделей, объектов, связей, символов, разрешенных к применению пользователем, который обращается к данным посредством этого фильтра. Ниже приведен фрагмент подобного фильтра:
<!DOCTYPE ArisFilter SYSTEM “ArisFilterExport.dtd”>
<ArisFilter version=“1.0" arisversion=“7.0.1.169217">
<Guid>f98555a9-6158-11d4-8582-00005a4053ff</Guid>
<InfoData>
<Info LocaleId=”1033" Name=”Easy Filter” Desc=”This filter offers a selection of basic model types of the requirements definition.”/>
<Info LocaleId=”1049" Name=”Простой фильтр” Desc=”Фильтр содержит основные модели, относящиеся к уровню определения требований.”/>
</InfoData>
<FilterData FilterType=”method” Key=”EASYFILTER”>
<ModelList>
<Model ModelTypeNum=”1">
<Symbols>3,0 2,1 58,2 143,3 12,4 209,5 145,6</Symbols>
<CxnOcc CxnBaseTypeNum=”296">209,209,31</CxnOcc>
<CxnOcc CxnBaseTypeNum=”17">209,3,27</CxnOcc>
...
<Attributes>1,1 55,2 9,3 942,4 152,5 938,6 381,7 389,8</Attributes>
<NCAttributes></NCAttributes>
</Model>
...
</ModelList>
<ObjectList>
<Object ObjTypeNum=»17">
<Attributes>1,1 55,2 28,3 9,4 8,5 942,6 152,7 938,8 943,9 153,10 939,11 389,12 1009,13</Attributes>
<NCAttributes></NCAttributes>
<Assigns>158</Assigns>
</Object>
...
Создав необходимый набор фильтров, можно указать, какие из них разрешены к применению конкретным пользователем, — в результате он просто будет лишен технической возможности создать модель, объект или связь, не предусмотренную в фильтрах, которые ему разрешено применять (рис. 4). Запрещенные к применению модели, объекты и связи просто перестанут появляться в списках мастеров создания моделей, в диалоговых панелях установки свойств связи, на палитре инструментов, используемой при рисовании моделей.
Рис. 4. Средства присвоения пользователю прав на методологические фильтры в ARIS Business Architect
Реализация разграничения доступа к данным в ARIS является сегодня, видимо, наиболее близкой к идеальной. Отметим, однако, что подобная реализация наиболее интересна и нужна в крупномасштабных проектах, в которых имеется как минимум несколько участников и число моделей хотя бы превышает десяток. При решении же менее масштабных задач моделирования подобные средства могут оказаться избыточными.
В целом отметим, что, выбирая инструмент, очень важно оценить возможный масштаб работ, нужный для решения как текущих задач, так и задач в последующих проектах. Ведь случаи, когда компания начала с пяти моделей Visio, а закончила огромным архивом из нескольких сотен подобных моделей, сопровождение которого (включая и обеспечение разграничения доступа к данным) стоило огромных усилий, известны многим консультантам по моделированию бизнес-процессов…
* * *
В следующей статье данного цикла мы продолжим обсуждение технических аспектов моделирования бизнес-процессов, а именно вопросов создания решений на основе средств моделирования.
|
|
