Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Во многих источниках информации указано, что use case - это некая цель, которую желает достичь пользователь с помощью системы.Просто приклею это сюда и улечу.
Зачем вводится понятие "вершина", которое объединяет понятия "состояние" и "псевдосостояние"? У состояний и псевдосостояний много общего (например каждое звено исходит от ровно одного из них и приходит ровно к одному из них).Это понятно. Но в том же ключе можно назвать элементы диаграмм классов вершинами [графа, которым является ДК].
Отразил, как понял в 1 и 2 вложении. Вложение 3 - вариант с запоминанием в переменной, откуда пришли, вложение 4 - провокационная версия того же.Благодарю. В 2 провокационно хотелось пунктирную часть видеть исходящей из середины сплошной (на манер пунктира класса ассоциации).
Беда стандарта, что в текстовой части смешаны и синтаксис, и семантика (это ещё не беда - так многие источники делают: действительно при первоначальном изучении только так и можно что-то понять), и при этом один и тот же термин "переход" используется и при описании синтаксиса, и при описании семантики, а часть, которая должна однозначно определить синтаксис - метамодель, этой цели не достигает.+1
Согласен, всё равно такой N-зубец надо проверять на полноту выходов. Вложения 3 и 4 содержат пример того же для исторического псевдосостояния. Может это всё для того, чтобы только после choice/junction проверять полноту выходов?Мудрёно.
Изменения.Моё замечание про ассоциации не касалось якобы нехватки их на Вашей диаграмме.
Вершина (Vertex) = состояние (State) + псевдосостояние (Pseudostate). Потом, при рассмотрении вложенных автоматов (StateMachine), возможно добавятся и ссылки на точки соединения (ConnectionPointReference). А такое дискриминация вершин?Это понятно, но зачем выделяется такая категория? Очевидно же, что автомат лишь визуально состоит из вершин и звеньев, а на самом деле определяет правила переключения между конфигурациями состояний и сопутствующее поведение. У отделённого сиамского близнеца диаграмм состояний -- диаграмм деятельности -- контрольные узлы никто не называет псевдоузлами, например. И не говорит о стабильности.
Какой (кроме junction/choice после звена из "вертолётной площадки")?Заручимся тем, что Харел придумал чистить предысторию спец. действием. По его плохому примеру разрешим проверять, пуста ли предыстория в стороже. Тогда, в Вашем примере можно рисовать двузубец с choice, первый зуб которого идёт в "вертолётную площадку" (одну! общую!) и имеет сторожа [not EmptyHistory], второй идёт в предысторию по умолчанию и имеет сторожа [else]. Прелесть в том, что можно рисовать трезубец, n-зубец и описывать условные дефолтные предыстории.
В описании (диаграмме) автомата есть только звенья (Transition). У каждого звена ровно 1 вершина-исто(чни)к и ровно 1 вершина-цель.Такое прочтение возможно. С другой стороны можно видеть (в тексте, не в метамодели!) составные переходы (compound transition) и всюду дальше их первого упоминания подозревать, что транзишэнами называют и их и звенья. Довольно бессмысленно, на мой взгляд, запрещать в стандарте проводить из начального псевдосостояния несколько исходящих звеньев, но разрешать(?) рисовать хареловский эквивалентный им N-зубец с choice/junction.
Да вот с мощностями проблем нет. Редко сталкивался с необходимостью использования системы группой лиц по предварительному сговору:)Надо заметить, что попытки сделать диаграмму ВИ подвидом диаграммы классов мало продуктивны, на мой взгляд. Но почему-то подкреплены стандартом. Того гляди, у ВИ вырастут квалификаторы, появятся N-арные связи и другая чертовщина. Именно превращение туманных коммуникаций в подвид ассоциаций и применение к ним дефолтных единиц и определяет трактовку "И". А по дефолту лучше бы пошёл 0..1
А вот втыкал две ассоциации в один ВИ частенько... Искренне считая, что по умолчанию xor
Кстати в силу чего считается, что по умолчанию И?Начиная с какой-то версии UML появилось дурацкое правило, что неуказанная мощность полюса равна 1 (т. е. 1..1).
В общем случае - не менее одного перехода. Причём это правило действует на все вершины (состояния и псевдосостояния), кроме начального (у начального своё правило - если оно относится к композитному состоянию, не менее одного перехода к этому композитному состоянию). Смысл - любая вершина должна быть достижимой.Хорошо бы описать, что такое вершина, что общего между разными типами вершин, и обосновать дискриминацию разных типов вершин.
Для того, чтобы показать разные варианты поведения (когда историческая память не содержит никакого значения).Может быть, рассмотреть другой способ?
То, что она общая - заложено в семантике (в одной из возможных семантик).Мне понравился прагматизм Рамбо, высказавшегося в своём интерью, что стандартизация языку моделирования не обязательна. Для каких-то задач множественные исторические псевдосостояния могут быть полезны. В этих случаях оправдано расширить язык. Сделать свой DSL для моделирования автоматов.
Мне подумалось, что ограничение на единственность исторического псевдосостояния в рамках композитного состояния (в разных источниках) обусловлена тем, что:
- прагматичность нескольких исторических псевдосостояний невелика
- определить предпочтительную семантику при нескольких исторических псевдосостояниях нелегко
Если имеется в виду Fig. 18. из "The Rhapsody Semantics of Statecharts", то всё нормально - из начального псевдосостояния ровно одно звено, без триггера и условия.Как мы обсуждали, в стандарте нет явной градации на звенья и переходы. Диаграмму можно трактовать так, что из начального состояния выходит один составной переход, на котором есть сторожа.
Сформулирую вопрос по другому - если композитное состояние имеет внутренний переход, то это:Я уверен в ответе 2 (с уточнениями). Обоснование видел в "A Crash Course in UML State Machines" M. Samek. Там есть пример с перекрывающимися разноуровневыми локальными переходами у вложенных состояний.
- недопустимо
- означает, что все подчиненные состояния имеют такой внутренний переход
- означает, что все подчиненные состояния имеют внешний переход в себя с указанными свойствами (триггер, условие, действие). Этот вариант мне не нравится, да и Харел моделирует его локальным переходом к историческому псевдосостоянию (Fig. 34. "STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS*")
И снова я изменил диаграмму.Можно ещё раз указать на то, что связи между ВИ на диаграмме ВИ влияют на описание ВИ. Из диаграммы следует, что в описании ВИ Оформление заказа должны быть:
мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.Вам виднее, каковы требования по оформлению Вашей дипломной работы.
Как-то так получается.У производителя есть код производителя, но у пользователя -- вместо кода пользователя код администратора. Плох тот пользователь, что не хочет быть администратором?
