ГОСТ Р ИСО/МЭК 15414—2017
дейст вия (проводки)
между электронной системой и
объ ект ам и
в
среде производст ва,
такими как запрос цен
(прайсов), добавление позиции к заказу или выставление требований ло оплате.
В.1.6.2 Процесс [6.3.6]
Спецификация сообщества inventoryMaintenance включает в себя спецификацию процесса reoroerProcess.
Этот
п р о ц е сс
задействует
объ ект ы
orderPlacer (размещение инвентаря), ресивер (приемка инвентаря) и
InventoryKeeper (журнал инвентаризации), а также инициирует
роп ь
поставщика. Один
ш аг
в этом
процессе —
дейст вие,
в рамках которого orderPlacer размещает заказ. Процесс размещения заказа продолжается таким же
образом для любого объекта eupplIerSystem при выполнении роли поставщика.
Для обработки товаров при завершении процедуры их получения в спецификацию для роли
сообщ ест ва
InventoryMaintenance включена спецификация процесса receivmgProcess. Этот
процесс
реализует
разве т вл яю щ е
еся дейст вие.
После разветвления в одной
цепи
InventoryKeeper регулирует
инвент арь,
в другой цепи orderPlacer
регулирует выдачу заказов.
Ш аги
этих двух целей выполняются как
совм ест ное дейст вие,
и это сопровождается
ш
агам и,
завершающими процесс receivIngProcess.
В.1.6.3 Нарушение [6.3.8 и 7.8.6]
Д ейст вие
подсистемы secuntySubsystem. которая запрещает объекту аудитора исследовать определенный
отчет, является
наруш ением правила,
упомянутого в В.1.7.2 (далее по тексту), поскольку
ст орона
в роли аудитора
уполном очена
исследовать любой отчет в системе электронной коммерции.
Д ейст вие
программы, выполненной
объ ект ом
databaseAdministrator. который показывает зарплатусотрудника, является
наруш ением правила,
упомя
нутого в В.1.7.5. который запрещает показ отчета о зарплате кому-либо за исключением
объект ов,
выполняющих
определенные
роли.
Например, заказ принят до 16:00 часов, но заказанные виджеты, которые находятся в запасе (на складе), но
не намечены для отгрузки во время принятия этого заказа, не являются намеченными для отгрузки в тот же самый
день. Такое поведение подсистемы shippingSubsystem является
наруш ением правила,
упомянутого в
0В.1.7.3 (далее ло тексту), которое обязывает shippingSubsystem намечать такие поставки в тот же день.
В.1.7 Обязательные понятия
В.1.7.1 Обязательные маркеры
Многиепримеры, приведенные выше, включают в себядействия, которые присвоены маркерам разрешения,
запрета или обязательства. Например, действие orderWldget(заказ виджета) включает в себя и разрешения, и обя
зательства; так определено, чтобы быть речевым актом, и электронный системный объект должен получить нор
мативный маркер
разреш ения,
прежде чем он сможет участвовать в действии в
рол и
приемщика заказов
(orderTaker). Выполнение действия приводитк созданию деонтического маркера обременения, выражающего обя
зательство поставить фиолетовый виджет. Первоначально это осуществляется объектом в роли orderTaker. но он
можетбытьпереданкакформепоследующегоделегированияподсистемезМрртдЗиЬбувГет.Другое обременение
в форме обязательства по осуществлению платежа создается действием
объ ект а — пост авщ ика.
В.1.7.2 Разрешение [6.6.7.8.8.4J
С пециф икация п редприят ия
системы электронной коммерции включает в себя
правило,
которое предписы
вает, чтобы
объект
аудитора (то есть
ст орона,
выполняющая
р ол ь
аудитора), был
уполном очен
исследовать
любой отчет в системе; это смоделировано в форме аудитора, содержащего нормативный маркер
разреш
ение.
Другое
правил о
предписывает, чтобы
объект
databaseAdmimstrator был
уполном очен
показывать
отчеты после проверки статуса операции спомощью dataManagementSubsystem, что также моделируется
спомощью деонтичес кого маркера
разреш ения.
В.1.7.3 Обязательство [часть 2-11.2.4]
С пециф икация предприят ия
включает в себя
правило,
которое предписываетдля любого заказа, принятого
до 16.00. назначить отгрузку в тотже день всех заказанных виджетов, имеющихся на складе, и еще не намеченных
для отгрузки до момента принятия этого заказа. Это
правил о
моделируется как
обязат ельст во
подсистемы
shippingSubsystem в терминах связанного деонтического маркера обременения, созданного
речевы м акт ом
orderWldget иделегированного подсистемой shippingSubsystem.
В.1.7.4 Разрешение [часть 2-11.2.5]
Спецификация
предприят ия
включает в себя
правила
о том. что определенные
подсист ем ы
могут устано
вить связь с
объ ект ам и
вне
дом ена б езопасност и
е.сот. Эти
правил а сузь разреш ения
и представляются
в
форме
деонтического маркера
разреш ения.
С пециф икация предприят ия
предопределяет, что объекты в
рол и
orderPlacer (размещение заказа) имеют
разреш ение уст ановит ь связь со б ъ е кт а м и
вне
дом ена безопасност и
е.сот. Объект в ролиorderPlacerиницииру ет
установление
связи с объ ект ом ,
представляющим конкретного поставщика. Подсистема безопасности
secuntySubsystem препятствует установлению этой
ком м уникац ии
по причине наличия временного специального
запрет а,
представленного какнормативный маркер запрещения (эмбарго) на основании наличия
связи (проводки)
с
этим
объ ект ом -пост авщ иком
supplierSystem. потому что в этот момент есть признаки постороннего управления, что
инициирует отказ в обслуживании на е.сот. Э
тот
случай не является
наруш ением разр е ш е ни я
для
объект а
orderPlacer.
В.1.7.5 Запрет [часть 2-11.2.6]
С пециф икация предприят ия
системы электронной коммерции включает в себя
правило,
которое запрещает
сотруднику назначение новой партии к роли widgetSupplier. в то время как этот сотрудник находится под расследо-
36