Эдуард, я буду комментировать тут, поскольку Владислав сформулировал точнее
Владислав Жаринов писал(а):
В принципе должность - это роль, да. Правда, ДИ регламентирует не только импер-часть (суть деятельности), но и всё остальное (предметы/результаты, средства деятельности, взаимоотношения и связи).
Именно всё как в жизни. Есть роль (куча метаинформации от формы одежды до выражения лица), и есть её алгоритмическая часть, в народе называемая сценарием
Обратите внимание - обычно сценарий служит для синхронизации процессов каждого исполнителя.
А программирование идёт с другой стороны - программируется именно отдельный исполнитель (вернее, роль). И алгоритм (действий исполнителя) - как раз и есть часть общего сценария, обусловленная ролью конкретного исполнителя.
Можно сказать и чуть по-другому: алгоритмическая часть роли есть часть общего сценария для одного исполнителя (актора).
Что мы видим на маршрутной схеме?
Мы видим там сценарий (алгоритмические составляющие ролей).
Всё остальное - зависит от задачи, которую мы хотим решить при помощи данного представления. И, соответственно, от рассматриваемой нами системы.
1) Если мы хотим показать сценарий (какой-либо системы - предприятия, подразделения и т.п.) - то логично на одной диаграмме показывать совокупность ролей (в т.ч. укрупнённо). Тогда в "силуэте" одной роли однозначно отводится одна ветка. Детализация каждой роли здесь несущественна, но её можно провести - внутри своей ветки. А можно и в отдельную схему вынести.
Кстати, по определению такая общая схема допускает много экземпляров исполнителей (акторов, рабочих точек) и их маршрутов.
2) Но мы можем также сконцентрироваться на конкретном экземпляре исполнителя. Тогда алгоритмическая схема его деятельности может включать несколько ролей и переходов между ними, и такое отображение будет по смыслу ближе к диаграмме состояний. Тогда каждая ветка "силуэта" будет отображать конкретное состояние (роль) актора. Опять же, детализация каждой роли здесь несущественна, но её можно провести - внутри своей ветки. А можно и в отдельную схему вынести. Кстати же, такая схема по определению однозадачна (допускается единственный эк
Итак, первая диаграмма (отображение системы!) представляет собой совокупность
всех ролей в системе, без особой связи и без переходов между ними. Вторая же диаграмма представляет собой совокупность всех
ролей, доступных данному актору (здесь системой будет не предприятие или подразделения, а конкретный актор). При этом роли алгоритмически связаны, и в соответствии с диаграммой состояний определены возможные переходы между ними.
Обратите внимание, что в обоих случаях:
- на диаграмме представляется только алгоритмическая часть (сценарий) системы;
- система (представленная на общей диаграмме) рассматривается как совокупность ролей;
- каждая роль обособляется в отдельной ветке, поскольку представляет собой объект в рамках системы;
- алгоритмическая часть сценария, которая образует конкретные роли, на общей схеме несущественна, и может быть опционально развёрнута внутри своей ветки (либо вынесена в отдельную схему).
Владислав Жаринов писал(а):
Ну, о допустимости следует говорить в отношении - представляется ли тем или иным синтаксисом (напр., графическим) реальная математическая модель предметки? Не знаю, что имел в виду Алексей...
Ну вот и объяснил вроде подробно, хотя и совсе не формально.
Как видите, синтаксис допускает много чего, и во всех случаях он практически одинаковый.
А вот смысл представленного - зависит от задачи.
В соответствии с задачей формализуем отношения субъектов - получаем модель системы с разных точек зрения.
При этом нас могут легко запутать такие не очевидные для непрограммиста понятия, как исполнитель и экземпляр исполнителя, должность и роль, сценарий и должностная инструкция. В реальной жизни они зачастую путаются. Например, мало кто осознаёт, что должность - это не одна роль, а совокупность ролей; что одни и те же роли могут исполняться разными должностями, что конкретный экземпляр исполнителя (в определённой должности) формально обязан, но фактически не всегда может выполнять все свои роли одинаково хорошо, и т.д. и т.п.
Можно спросить, как всё сказанное соотносится с тем, что пишет Усов о предприятии как системе.
На это можно ответить, что по содержанию система остаётся описанной в едином формализме, как и предлагает Усов. Все возможные проблемы кроются в степени детализации.
Так, даже подробные управленческие модели обычно останавливаются на уровне должности. При этом система (модель то есть) получается красивой, идеально соответствующей замыслу архитектора - но, увы, бюрократической и плохо работающей. Оказывается, что должность должностью, но хороший хозяин будет смотреть глубже - на уровень не абстрактной должности, а конкретного "экземпляра исполнителя" дяди Васи.
Но все рассмотренные формализмы (ресурсы, возможности, потребности и т.п.) будут теми же и на этом уровне.
Алгоритмическая часть ролей (сценарии), как это ни странно, будут иметь далеко не главную роль, чтобы так сильно ими заморачиваться... Имхо, конечно