Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »
391
Убрать из 14.5.8.6 первые 2 ограничения.
Я думал о том, что затруднительно описать ограничение, которое бы сказало, что диаграмма "с душком" (например, из-за недетерминированного составного перехода, у которого несколько звеньев заканчиваются в разных исторических псевдосостояниях одного региона). Впрочем, такие сложности не связаны именно с множественностью исторических псевдосостояний, должен признать.

Просто каждый вход в композитное состояние может иметь своё отношение к обработке истории (строго говоря каждый вход внутрь и одно общее на все входы на границу композитного состояния): будет ли учитываться предыдущее посещение композитного состояния и, если да, то что делать, если предыдущего посещения не было.
Попробую так. Конкретный синтаксис с несколькими предысториями допускает толкование, что для каждого способа входить в состояние по предыстории (в Вашем примере от 16.06 таких способов у State1 два -- левый и правый) есть отдельная память, ведущая независимую историю. Т. е. при входе слева срабатывает левая предыстория, справа -- правая. Если бы "вертолётная площадка" была одна, повода для такого толкования не возникало бы.

Когда-то такой знак "вертолётной площадки" и был тэгом на композитном состоянии (без входящих и исходящих переходов),  что означало, что любой повторный вход в композитное состояние означает продолжение с места прерывания. Потом стало ясно, что это слишком узко, что иногда надо продолжить, а иногда и начать по новой.
Замечу, что у Харела (автора предысторий) во всех его примерах в "площадку" обязательно входит звено. То есть, у него это не совсем тэг.

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

В "математических" автоматах финальное состояние играет другую роль: если обработка последовательности сигналов завершилась в финальном состоянии, то последовательность "правильная".
"Математическая" трактовка почти та же, что у протокольных диаграмм состояний. А протокольные финальные состояния нечем не отличаются от обычных.
К финальному состоянию стандарт привязывает специфический аспект -- генерацию события завершения для региона. Схожий с завершением, на мой взгляд, момент связан с терминацией (terminate-псеводостоянием). Только terminate прибивает всю машину. Представим, что есть два вида таких псевдосостояний: первый (обычный) -- для завершения региона, второй (со *) -- для завершения всей машины. Т. е. я хочу подвести к тому, что финальное состояние региона -- это, по смыслу, псевдосостояние, т. к. это условное обозначение.
Рассуждения о том, что финальное состояние -- стабильная вершина, как мне кажется, схоластичны. Если регион достиг финала, то нет никакой разницы, считаем ли мы "текущим" одно из его финальных состояний или никакое из его подсостояний, поскольку он завершён. Понятие стабильной вершины само по себе вызывает вопросы. Простое состояние без do-деятельности с переходом из него, запускаемым по завершению, стабильно лишь фиктивно. При работе машины оно проскакивается. Т. е. стабильность определяется работой автомата, а не на уровне синтаксиса. Псевдосостояния -- это спец. обозначения. Именно этим они отличаются от состояний. То, что псевдосостояния нестабильные вершины, не отделяет их от состояний (которые тоже могут быть нестабильны).

392
Сначала о глобальном - мне нравится, как проходит обсуждение, поэтому появились вопросы:
  • есть ли в интернете другие места (лучше русскоязычные), где обсуждения похожих тем (нюансы языков моделирования) происходят так же конструктивно?
  • почему молчит остальная аудитория форума, варианты:
    • джуниоры пытаются разобраться в том, что все уже давно знают - пусть разбираются сами, лучше усвоят;
    • очень важная, но сложная тема - сказать по ходу нечего, дождёмся результатов;
    • то, что обсуждают, никому никогда не понадобится, но влезать - себе дороже?
Мне тоже понравился наш обмен мнениями. Так перемыть косточки UML у меня даже с коллегами на работе не получалось.
Других мест не знаю, т. к. не искал. Может быть, кто-то из старожилов подскажет.
Комментировать участие/неучастие в этой теме других участников не возьмусь. Я почти их не знаю.

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

неважно сколько исторических псевдосостояний, при выполнении можем одновременно добраться только до одного.
Это так, но, вероятно, придётся прописать такое положение в языке. Сделать это формально (на OCL) затруднительно. Сама нотация может обескураживать: несколько псевдосостояний предыстории  изображают одну предысторию и несколько меток для состояний, являющихся предысторией по умолчанию. Мне кажется, что такая пометка состояния могла бы делаться не звеном из "вертолётной площадки", а тегом на самом состоянии. Хотя такой вариант, скорее всего менее нагляден, чем стандартный.

Отсутствие в финальном состоянии do-деятельностей и внутренних переходов обусловлено тем, что хочется подчеркнуть, что ничего существенного (с точки зрения региона/состояния, к которому относится финальное состояние) уже произойти не может - только выход, причём это будет и выход из региона/состояния. Но оказалось, что в случае композитного ортогонального (в отличие от неортогонального) состояния появляется новая ситуация - часть регионов достигла финального состояния, а часть - нет.
Мне интересно, откуда появилась в UML такая трактовка? Уж не от неудавшегося сращивания диаграмм состояний с диаграммами деятельности в 1-й версии UML? Ведь в "математических" автоматах финальное состояние -- обычное состояние с дополнительным свойством, т. е. у математиков оно в каком-то смысле больше, чем обычное состояние, а не наоборот.

393
На картинке - верхний автомат: как добиться того же эффекта с одним историческим (то, что триггер "a" на горизонтальных стрелках, а триггер "b" на вертикальных - случайное совпадение)?
От предыстории по умолчанию можно избавиться, заведя переменную-признак "были ли мы в State1", добавить действия по её инициализации и изменению, раздвоить переходы в State1 через choice/junction со сторожем, который при истинности признака ведёт нас в единое псевдосостояние истории, при ложности -- в нужное подсостояние внутри State1. Понятное дело, что с помощью введения переменной можно вообще избавиться от исторических псевдосостояний.
 
На картинке - нижний автомат: как добиться того же эффекта без перехода из финального состояния (последовательность триггеров "аа" приводит к State8, "ab" и "ba" - к State10)?
Можно убрать явный переход из финального состояния, финальное состояние в верхнем регионе сделать обычным, завести две переменные-признака x1 -- "завершён ли верхний регион?" и x2 -- "завершён ли нижний регион?", добавить их инициализацию и действия по изменению, групповой переход по завершению из State6 заменить на переход по триггеру -- событию изменения when(x1 and x2).

Я не настаиваю, что именно так и нужно делать. Должен сработать компромисс -- усложняя нотацию, соизмеряем, оправдывает ли более трудночитаемое описание языка выгоды от более лаконичных диаграмм в особых случаях. Как я писал выше, смыслы финального состояния в стандарте не прояснены должным образом. Возможно, что допущение явных переходов из финальных состояний (а также do-деятельностей в них, внутренних переходов) не усложнит язык, а лишь очистит его от лишних запретов. Некоторое затруднение может быть связано с устоявшимся стереотипом, что явных переходов из финального состояния не бывает.

394
Если стояла цель добавить в работу иллюстрации, которые трудно читать по существу, зато на которых легко разглядеть элементы UML-нотации, то попытку можно зачесть.
Если была нужна модель, то вот перечень сомнительных мест:
1) На диаграмме ВИ в ВИ Просмотр документа участвуют два действующих лица Руководитель и Сотрудник. Вероятно Вы хотели показать, что просматривать могут и тот и другой (странно, что другим нельзя), но получилось, что в любом просмотре должны участвовать и тот и другой. То есть в сценарии этого варианта по Вашей версии будут шаги системы, шаги руководителя и шаги сотрудника. И если сотруднику захочется просмотреть документ, то придётся отвлекать от работы руководителя. Аналогичные замечания можно сделать ко всем ВИ, связанным с 2мя или 3мя действующими лицами.
2) На диаграмме деятельности есть дорожка действующего лица Ответственный, которого не было на диаграмме ВИ.
3) В отдельных местах диаграммы деятельности за узлом действия Отправка уведомления следует узел Получение уведомления, но почему-то так происходит не всегда.
4) Диаграмма деятельности громоздка и не соответствует никакому отдельному ВИ. Разумнее для каждого отдельного ВИ составлять отдельную диаграмму деятельности. Каждая такая диаграмма будет меньше, проще для чтения. Общую обзорную диаграмму деятельности также можно составить, но из более крупных блоков, ссылающихся на поддиаграммы для отдельных ВИ.
5) Отсутствие стрелок на диаграмме деятельности добавляет двусмысленность. Например, неочевидно, что в узел действия Заполнение шаблона входят два потока управления и выходит один, а не наоборот.

395
Диаграмма ВИ, на которой нет связей включения и/или расширения, может быть верной или неверной. Это зависит от описаний вариантов использования. Диаграмму с include/extend можно привести к виду без include/extend, изменив описания ВИ, и новая диаграмма будет верной и будет описывать ту же систему.
В общем случае, не требуется, чтобы на диаграмме обязательно был include или extend. Требования, которые предъявляет Ваш преподаватель, знает он и, может быть, Вы и Ваши коллеги. Обратитесь к ним, чтобы уточнить, какое именно задание Вам досталось.

P. S. Всё же, обратите внимание, что проводить include от Терапевта и к Терапевту нельзя.

396
от каждого ВУ должна идти связь(пока отбросим тип связи), к какому то другому ВУ или актеру.
Очевидно, что это другое требование. Действительно, не должно быть ни одного "яйца", к которому не идёт ни одной связи (ни связи от действующего лица, ни связи от другого ВИ). Вам следует определиться, что именно требуется: связать все ВИ друг с другом или исключить "яйца", к которым не идут никакие связи. 

397
В смысле?
Наличие/отсутствие связи между двумя вариантами использования зависит от их описания. Вероятно, в рамках Вашего задания ВИ рассматриваются просто как "яйца", разложенные по полю диаграммы. Т. е. Вы обязаны освоить систему обозначений, не вникая глубоко в смыслы этих обозначений.
Нет никакого желания затевать разбирательство относительно правоты/неправоты. Оно никак не поможет сдаче Вами задания, как я полагаю.
Если буквально следовать требованию "связать все", то можно видеть 2 ВИ, не связанные с другими: "Описание симптомов" и "Передача данных". К этим двум "яйцам" Вы, выполняя указанное требование, можете  провести include от "яйца" "Обращение пациента". Повторюсь, что эта рекомендация дана для решения поставленной преподавателем задачи (как Вы о ней тут сообщили).

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

399
Чтобы указание ошибок было точным и полным Вам следует:
1) Указать, какую [бизнес] систему Вы  моделируете. Дать её краткое описание.
2) Приложить описания всех вариантов использования и действующих лиц.

Из общих соображений укажу следующее:
Скорее всего, Вы злоупотребляете связями между вариантами использования.
Связь включения не может идти от ВИ (Описание симптомов) к действующему лицу Терапевт и в другую сторону (ДЛ Терапевт -> ВИ Оформление справок).
Обычно названия ВИ -- это глагольные фразы ("Завести амб. карту"), т. е. существительное на первом месте в названии ВИ стоять не должно ("Оформление справок")
Нарушена стандартная нотация UML: связи include и extend должны быть пунктирными стрелками, коммуникации -- сплошными стрелками с обычным, а не треугольным остриём.

400
Здравствуйте, endwar.
Предлагаю Вам определиться, так ли необходим UML. Судя по всему Вы готовите иллюстрацию для презентации и/или текста. То есть схема будет демонстрироваться людям. "Машиночитаемой" она быть не должна. Раз так, можно не связывать себя ограничениями UML. На одной схеме Вы хотите отобразить два (ортогональных) аспекта: членение системы на блоки и набор реализованных методов. Для первого подходит UML-диаграмма компонентов. Для второго --  UML-диаграмма другого типа. То есть, по UMLю вместо одной схемы должно быть две.
Затруднительно представить верный вариант схемы по скудному описанию. Поэтому дам советы общего плана:
1) Определитесь, что важно и должно быть на схеме, а что второстепенно и будет её замусоривать. Например, важно: система, блок препроцессинга, блок решателя, блок постпроцессинга, метод рестартов, метод сопряжённых градиентов, метод Левенберга. Неважно(?): оптимизатор.
2) Определитесь с типами элементов схемы. Для каждого типа подберите способ изображения, отличный от других типов. По списку выше у Вас 3 типа элементов: а) система, б) блок, в) метод. По картинке у Вас 4 типа элементов: а) сплошной прямоугольник со скруглёнными углами, б) пунктирный прямоугольник со скруглёнными углами, в) сплошной прямоугольник, г) сплошной прямоугольник с уголком. Несоответствие.
3) Определитесь с типами связей. Для каждого типа связей подберите способ изображения, отличный от других типов. У Вас 4 типа связей: а) система --состоит-из--> блок, б) блок --связан-по-данным--> блок, в)  блок --реализует--> метод, г) метод --использует--> метод. Все эти связи направленные. На диаграмме лишь два типа связей: а) сплошная стрелка б) ненаправленный(!) пунктир. Опять несоответствие.
4) Дополните схему легендой, раскрывающей Вашу систему обозначений.

401
1. подскажите что за книга
Д. В. Кознов "Основы визуального моделирования"

2. когда диаграммы используются для непосредственного общения или для размышления - вполне нормально отступить от стандарта, но если речь идет о документировании - отступать от какого-то единого понимания стандарта нельзя
Точно замечено. Отступление означает изменение возможной области применения и аудитории.
 
3. если нестандартно, творчески означает: в рамках стандарта (или единого понимания стандарта), но не примитивно, то это не может не приветствоваться
Согласен. Хотя сама книга даёт пример нестандартной трактовки отдельных элементов UML-нотации. Что тоже можно рассматривать как своего рода творчество. Впрочем, офтопик.

Вы и Харел считаете, что историческое псевдосостояние должно иметь входы. Я согласен, да и стандарт не против.
Но стандарт ограничивает количество исходящих переходов из исторического псевдосостояния, ничего не говоря об обязательном наличии хоть одного входящего.

Но тогда появляется вопрос: может ли композитное неортогональное состояние (или регион ортогонального состояния) иметь одновременно псевдосостояния глубокой и неглубокой истории? Стандарт и я считаем, что да (14.5.8.6 первые 2 ограничения).
Да, может. Интересно было бы рассмотреть более-менее реалистичный пример, когда это пригождается.

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

Если речь идет о композитном ортогональном состоянии (с 2 регионами), то переход из финального состояния одного из регионов за пределы этого композитного ортогонального состояния легко интерпретируется: срабатывание триггера имеет результат, если в первом регионе достигнуто финальное состояние, а во втором регионе состояние может быть любым. Причем заменить финальное состояние первого региона обычным состоянием нельзя: есть переход без триггера от композитного состояния - значит в каждом регионе должно быть финальное состояние.
Я имел в виду лишь то, что из финального состояния нельзя явно рисовать переходы.

Дам разъяснение: Харел даёт хорошее, но неформальное описание, стандарт пытается дать формальное, но хорошим его не назовёшь. Я пробую (пока для себя) построить модель (в виде диаграммы классов) абстрактного синтаксиса автомата и если что-то плохо укладывается (вызывает усложнение диаграммы), пытаюсь изменить абстрактный синтаксис автомата (не потеряв ничего существенного).
Такую инициативу можно только поддержать.

402
(не нашёл что такое блокирующийся)
Пожалуй, с блокировкой я погорячился. Этот термин ближе к диаграммам деятельности. Но можно рассматривать что-то вроде "протокольных автоматов с действиями". Т. е. диаграмма состояний составляется в расчёте не на все возможные последовательности событий, а на "правильные". Если события происходят неправильно, автомат ломается-блокируется (в псевдосостоянии, из которого не может попасть в полноценное состояние).

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

Если у junction и choice псевдосостояний такое ограничение есть, то проще сделать единственный переход от начального/исторического к junction/choice, а от junction/choice уже несколько переходов.
В своём отступлении про начальное состояние я пытался объяснить (себе) появление и развитие этого специального обозначения. "Странные" ограничения в стандарте связаны, на мой взгляд, с тем, что специальное обозначение ("звено с кружком") со временем стало трактоваться как полноценный переход. Для меня предпочтительнее вернуться назад, к корням, а значит, запретить "звену с кружком" иметь сторожа, входить в составные переходы и т. п.. Тогда причина запретов становится явной. Иначе, следует отмести запреты, и, я думаю, разрешить ждать в начальном состоянии наступления триггера. Т. е. оно должно иметь те же права, что и финальное состояние, с той лишь поправкой, что из финального нельзя явно выйти, а в начальное нельзя явно войти. Позиция авторов текущей версии стандарта странная, как мне кажется, -- ни туда, ни сюда.

немного странно - если есть деятельность, то она может закончиться, а если нет - то и никакого события не возникает. Может правильней иметь событие со смыслом, что уже ничего больше делать не надо (или что всё уже сделано), тогда если do-деятельность пуста, считать что это событие наступает, когда состояние становится активным. Такое поведение будет похоже на поведение с финальным состоянием композитного состояния - если у композитного состояния есть исходящий переход без триггера и с "подходящим" сторожем, то финальное состояние как бы "проскакивается".
Да, такой подход может иметь место. Но к чему он приводит? Насколько он прагматичен? Состояние (с пустой деятельностью и переходом по завершению) превращается не в способ поведения объекта, а в промежуточную проскакиваемую вершину. Такой конструкции легко найти замену -- тот же junction, например. Оправдать использование такой избыточной, по-моему, конструкции затруднительно.
все исходящие переходы без триггера (как и переходы с совпадающим триггером) должны иметь взаимоисключающие сторожа
Для детерминированного автомата такое требование разумно.

P. S. И вообще, попалась тут книга, автор которой призывает использовать UML нестандартно, творчески.) Обдумываю это предложение.)

403
Может далее не будем особо ориентироваться на стандарт - пытаясь улучшить и формализовать Харела он и не улучшил, и не формализовал (формализация без полноты и непротиворечивости не нужна).
Опираться можно на Харела и на здравый смысл (почти цитата получилась :) ).
Принято безоговорочно.)
Где возможны (и даже обязаны быть) переходы без триггера?
  • из начального псевдосостояния
  • из композитного неортогонального состояния, если в нем есть хоть одно финальное состояние
  • где-то ещё

Вопрос: что должно выполняться для исходящих переходов без триггера (из начального псевдосостояния и композитного неортогонального состояния, если в нем есть хоть одно финальное состояние):
  • ровно один переход, без сторожа
  • несколько со сторожами - взаимно исключающими, но полностью перекрывающими все возможностм
  • что-то ещё
Ещё вопрос: может ли совсем не быть исходящих переходов без триггера из композитного неортогонального состояния, если в нем есть хоть одно финальное состояние
В математической модели конечного автомата определено следующее: во-первых, начальное состояние является полноценным состоянием; во-вторых, в детерминированном автомате (вложенные автоматы не рассматриваем) начальное состояние одно. Харел в своей статье 1987 года пишет о начальных состояниях в том же ключе. Это всегда единственное состояние "региона", которое помечается на диаграмме специальным образом: рисуется кружок-точка и от него проводится одно звено к начальному состоянию. Поначалу (см. "Statecharts in the Making") это спец. обозначение оставалось лишь обозначением, но время шло. На рис. 21 из "Statecharts in the Making" можно видеть, что обозначение стало восприниматься [самим Харелом] на основе конкретного синтаксиса как полноценный переход из неполноценного псевдосостояния, которое в UML назвали "начальным". Думаю, что этот рисунок -- причина сумятицы в стандарте, который в 2-х местах запрещает, а в 1-м разрешает триггеры на переходе из начального п/состояния.
Нужно ли ориентироваться на мат. модель? Ответ не очевиден, так как часто на диаграмме начального состояния нет и это сделано специально. А раз допускается меньше одного начального состояния, то почему бы не допустить больше одного [полагая начальными именно состояния а не спец. обозначение]? Опять же, недетерминированный автомат может иметь несколько начальных состояний, а другие элементы недетерминизма на UML-диаграммах состояний возможны (недетерминированная работа choice и junction).
Но что если обратиться к самому понятию "начального" состояния, как это было проделано с "локальностью/нелокальностью" перехода? Что оно обозначает на самом деле? Можно заметить, что начальность связана со входом в состояние. При каждом входе в композитное состояние (при каждом запуске машины состояний) одно из подсостояний является первым, находящимся в начале, трассы меняющихся текущих состояний. То есть, то, что выше называлось "начальным состоянием" следовало полностью называть "начальным состоянием по умолчанию". При переходах извне состояния, оканчивающихся в подсостоянии, начальное состояние указывается явно как цель перехода. При переходах извне, оканчивающихся на границе подсостояния, начальным состоянием является "начальное по умолчанию". При переходах извне, оканчивающихся в предыстории, начальным оказывается "начальное по предыстории".
Исходя из сказанного, я бы предложил "вернуться к корням", т. е. убрать начальное псевдосостояние и добавить метку "начальное по умолчанию" для состояний. Первый недостаток такого решения очевиден. Нельзя будет разместить на "псевдозвене" действия по инициализации вроде тех, что на рис. 21 у Харела. Однако, это легко решить, введя дополнительное состояние. Это делает немного громоздким автомат, но, на мой взгляд, упрощает метамодель и описание языка диаграмм состояний. Второй недостаток -- есть огромная аудитория пользователей языка, которая привыкла к такому обозначению.
Всё это, конечно, не ответ на заданные вопросы, а контекст этих вопросов.
Про финальное состояние можно вести схожее обсуждение. Так, у Харела почти нет примеров со специально обозначенным финальным состоянием, а те, что есть, как я полагаю, появляются под влиянием UML. Финальное состояние находится на [противоположном] конце трассы меняющихся текущих состояний [или участка этой трассы]. Финальное состояние в "математических" автоматах имеет другой смысл по сравнению со стандартом. Стандартный смысл описан отрывочно и неясно. И. т. п. По всему этому можно судить, удачное ли это обозначение, и оправдывает ли удобство [?] его использования усложнение описания языка. 
Третий аспект кроется в том, что метамодель машины состояний предполагает некоторого исполнителя, которого приходится реализовывать некоторым производителям CASE-средств. С позиции реализатора такого исполнителя может быть удобно, чтобы были начальные и финальные состояния.

А теперь, отбросив радикализм), даю свои ответы с умеренно консервативной позиции:
Переходы без триггера возможны:
  • из начального псевдосостояния (единственный, без сторожа, с возможным эффектом)
  • из псевдосостояния истории (для обозначения предыстории по умолчанию: единственный, без сторожа, с возможным эффектом)
  • из композитного неортогонального состояния, если в нем есть хоть одно финальное состояние
  • из простого состояния, если в нем есть do-деятельность
  • из композитного ортогонального состояния, если в каждом его регионе есть одно (или более чем одно) финальное состояние
  • (если под переходами понимаются и звенья-части других переходов) из junction и choice псевдосостояний

Только в случаях спец. обозначений (т. е. начального и исторического) накладываются ограничения единственности и отсутствия сторожа.  В других случаях их нет. Взаимное исключение и т. д. зависит от того какой автомат мы описываем: детерминированный/недетерминированный/блокирующийся.)

Исходящих переходов без триггера из композитного неортогонального состояния, если в нем есть хоть одно финальное состояние, может не быть. Мы вправе игнорировать событие завершения, если таково описываемое нами поведение.

404
Не совсем понял вопрос, но отвечу, как понял :)
Денис не был модератором раздела про Обучение. Была возможность у членов группы "Memeber of CAR" модерировать разделы форума. Данная возможность также у этой группы убрана.
Благодарю за пояснение.
Также еще добавлю, что у модераторов и администрации ресурса не всегда есть время, чтобы пристально следить за дискуссией и делать во время корректирующие действия. Данный ресурс бесплатный и мы уделяем время ему по мере возможности. Поэтому приношу свои извинения, если что-то пошло не так. Мы за мир во всем мире!
У меня есть предложения, которые, учитывая выше процитированное, не обязательно реализовывать:
1) Полагаю удобным для пользователей размещение на каждой странице форума ссылки на правила (там где Начало, Помощь, Поиск...). Так можно было бы увеличить вероятность того, что у всех пользователей будет единое представление об актуальной версии правил.
2) Полагаю разумным оповещать пользователей об изменениях, затрагивающих правила/пользовательское соглашение. Например, не всем интересно следить за данной веткой. Из-за этого кто-то может невольно пропустить важное для него изменение.
3) Полагаю уместным  в разделе правил, посвящённом модерированию, дать текущий список модераторов. Это способствовало бы правильному общему представлению о распределении ролей и обязанностей.
4) В Помощь было бы хорошо добавить раздел о том, в каких случаях и каким образом пользователю следует обращаться за помощью к модератору. Например, моё участие в этой теме, вероятно, "подогрело" сложившуюся ситуацию, хотя такой цели перед собой я не ставил. За этот побочный эффект приношу свои извинения.

405
Я два года размещаю рекламу наших (и чужих) тренингов в разделе «Обучение и тренинги» и являюсь модератором этого раздела.
Прошу также прокомментировать процитированное в части модераторства. Отдельного списка модераторов нет, так что приходится лазить по дереву разделов, а в нём легко заблудиться.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 »