406

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 23 Июня 2016, 12:08:14 »

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

Хорошо бы описать, что такое вершина, что общего между разными типами вершин, и обосновать дискриминацию разных типов вершин.

Для того, чтобы показать разные варианты поведения (когда историческая память не содержит никакого значения).

Может быть, рассмотреть другой способ?

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

• прагматичность нескольких исторических псевдосостояний невелика
• определить предпочтительную семантику при нескольких исторических псевдосостояниях нелегко

Мне понравился прагматизм Рамбо, высказавшегося в своём интерью, что стандартизация языку моделирования не обязательна. Для каких-то задач множественные исторические псевдосостояния могут быть полезны. В этих случаях оправдано расширить язык. Сделать свой DSL для моделирования автоматов.
Поиски примеров диаграмм с глубокой и неглубокой предысторией в одном состоянии привели к задаче из студенческого quiz-а, не имеющей никакого смысла, кроме проверки знаний. Интересно найти что-то более жизненное для множественных предысторий.

Если имеется в виду Fig. 18. из "The Rhapsody Semantics of Statecharts", то всё нормально - из начального псевдосостояния ровно одно звено, без триггера и условия.

Как мы обсуждали, в стандарте нет явной градации на звенья и переходы. Диаграмму можно трактовать так, что из начального состояния выходит один составной переход, на котором есть сторожа.

Сформулирую вопрос по другому - если композитное состояние имеет внутренний переход, то это:

• недопустимо
• означает, что все подчиненные состояния имеют такой внутренний переход
• означает, что все подчиненные состояния имеют внешний переход в себя с указанными свойствами (триггер, условие, действие). Этот вариант мне не нравится, да и Харел моделирует его локальным переходом к историческому псевдосостоянию (Fig. 34. "STATECHARTS: A VISUAL FORMALISM FOR COMPLEX SYSTEMS*")

Я уверен в ответе 2 (с уточнениями). Обоснование видел в "A Crash Course in UML State Machines" M. Samek. Там есть пример с перекрывающимися разноуровневыми локальными переходами у вложенных состояний.

407

Для всех / Re: UCD для интернет-магазина

« : 23 Июня 2016, 11:27:51 »

И снова я изменил диаграмму.

Можно ещё раз указать на то, что связи между ВИ на диаграмме ВИ влияют на описание ВИ. Из диаграммы следует, что в описании ВИ Оформление заказа должны быть:
1) одна (или более) точка расширения (для регистрации, авторизации);
2) шаги, на которых вызываются сценарии включаемых ВИ (поиск, выбор).
Ещё одно несоответствие между диаграммой и описанием ВИ Оформление заказа можно видеть в том, что при оформлении заказа нет возможности добавлять товары в заказ (только удалять). Вероятно, пропущен ВИ, в рамках которого это можно делать -- Составление заказа или вроде того. Либо надо менять описание и диаграмму деятельности из параллельной темы.

P. S. Ассоциация между действующим лицом и вариантом использования толкуется не только в том ключе, кому нужен ВИ как цель.

408

Для всех / Re: Концептуальная модель предметной области

« : 23 Июня 2016, 11:04:18 »

мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.

Вам виднее, каковы требования по оформлению Вашей дипломной работы.

409

Для всех / Re: Концептуальная модель предметной области

« : 22 Июня 2016, 14:40:12 »

Как-то так получается.

У производителя есть код производителя, но у пользователя -- вместо кода пользователя код администратора. Плох тот пользователь, что не хочет быть администратором?
Заказ с видом доставки связывает помимо линии вид доставки. Что связывает элемент заказа с заказом помимо линии? А с товаром?
Во всех "прямоугольничках" есть что-то красненькое. Хотя, не во всех. В одном нет. Почему?
На примере от преподавателя нет "куриных лапок". А у Вас есть.  Примет ли преподаватель диаграмму с "лапками"?

410

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 22 Июня 2016, 04:16:54 »

Недопустимое сочетание: пусть есть одна глубокая и две неглубокие истории - получается глубокая совместна с каждой неглубокой, а неглубокие между собой нет!

Да. Получается. А что в этом недопустимого? Содержание то у глубокой и неглубокой (если они осмысленно используются) может быть разным и меняться в разные моменты. Совместность означает, что мы работаем на обоих уровнях.

Не то чтобы я настаиваю на единственности/зависимости памятей. Но для меня "вертолётная площадка" - это не признак "отдельной" истории, а признак обращения к "общей" истории, а звено, выходящее из "вертолётной площадки" - указание что делать, если в этой "общей" истории ничего не записано (или записано "особое" значение).

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

Как-то не очень хорошо выглядит - при одних входах работаем ровно с одной памятью, а при других - со всеми памятями. Да и что называем "входом" - пересечение границы композитного состояния снаружи внутрь, которое заканчивается на "вертолётной площадке" или ещё где-нибудь?

Называем любой вход в состояние и любой вход в предысторию. Если не хочется работать с двумя памятями, можно ввести понятие памяти по умолчанию и метить её спецтегом. Например, правую пометим спецтегом. Далее, если не знаем, куда писать (вошли не в предысторию), то пишем по дефолту вправо.)
У Харела в статьях про Statemate и Rhapsody явно говорится, что "площадка" в состоянии одна, на минуточку. В тех же статьях, кстати, есть двузубцы с choice/junction, растущие из начальных состояний. Привет от Харела составителям стандарта [и мне].))

А как воспринимать звено, которое заканчивается на "вертолётной площадке", но не пересекает границы композитного состояния (Harel "STATECHARTS: A VISUAL FORMALISM FORCOMPLEX SYSTEMS*" Fig.14)?

Как переход в запомненное в истории состояние. Или в дефолтную предысторию, если ничего не запомнено. Или в [дефолтное] начальное состояние, если дефолтной предыстории нет, или не можем понять, какая она.

Попутно вопрос по этой диаграмме: вместо использования конструкции с историческим псевдосостоянием можно завести внутренний переход в состоянии update (хотя бы в UML)?

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

411

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 21 Июня 2016, 12:26:10 »

Критерием, который мог помочь при выборе между этими вариантами, могло быть описание поведения, если композитное состояние одновременно имеет и глубокую, и неглубокую историю. Но у Харела таких случаев я не нашел, и в стандарте тоже (хотя в 14.5.8.6 первые 2 ограничения записаны так, что это возможно). Моя позиция - любой выход оказывает влияние на все истории (но подкрепить её нечем).

Необязательно. Можно считать, что разноуровневые истории работают совместно, а одноуровневые независимы.) Не то чтобы я настаиваю на множественности/независимости памятей. Речь скорее о соответствии между визуальным представлением и идеями, которые оно отображает. Если история/память одна, то и "вертолётная площадка" одна. Если несколько вариантов предыстории, то несколько элементов обозначающих эти варианты (а не несколько "площадок"). Разумно, если отдельное отображение имеется для памяти и отдельное -- для предысторий по умолчанию. В стандарте для второго служит [псевдо]звено. Значит, для первого -- "площадка". Отсюда "площадка" одна, псевдозвеньев несколько. Такая логика.

412

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 21 Июня 2016, 11:17:35 »

Ответ:

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

Читал: объясняет, почему плохо, но неясно как будет хорошо.

По мне, в большей степени, объясняет, что у каждого в голове своя порода тараканов.)

413

Для всех / Re: Концептуальная модель предметной области

« : 20 Июня 2016, 21:54:48 »

IMHO серийный учет при торговле постельным бельем вряд ли используется.

Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.

414

Для всех / Re: Диаграмма деятельности (активности)

« : 20 Июня 2016, 21:40:34 »

Клиент может и не авторизироваться для оформления заказа.
пункт 7.2 подразумевает не ввод данных для авторизации, а ввод контактных данных (им, телефон, почта) для оформления заказа и последующей регистрации.

Согласно Вашей диаграмме ВИ (прежней её версии) авторизация обязательно происходила при оформлении заказа (связь включения между ВИ). Вместо 3-х тем, каждая из которых про отдельный тип диаграмм, удобнее было бы иметь одну тему по всей Вашей модели. Диаграммы и описания (части модели) должны подходить друг к другу, иначе целостной модели не получится. Отвечать, Вам отслеживая изменения в одной модели, разбросанные по трём темам, затруднительно.

415

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 20 Июня 2016, 21:22:39 »

Прибавлю, что в "стандарте" UMLя для слепых пунктиров не было предусмотрено, но их легко ввести, если использовать резинки с узелками. 

416

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 20 Июня 2016, 18:48:41 »

Дело в том, что всегда непонятно в какую память записывать, поэтому если записывать в обе,то обе памяти оказываются идентичными.

Каждый выход происходит после какого-то входа. Часть входов происходит по левому пути (через левую память), часть по правому. Через какую память входили, в ту и пишем.

Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).

Харел использовал "системные переменные", которые описывают [текущую | прошлую] конфигурацию состояний автомата. Они не вводятся автором диаграммы. Пример стандартной "системной переменной" без имени -- время -- в событиях времени at(12pm), after(1ns).

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

Думаю, что, разделяя звенья и псевдозвенья, можно договориться о том, что на самом деле запрещать на псевдозвене (и не запрещать сторожей и эффекты просто ради запрета). Пунктиры взяты по аналогии с зависимостями с диаграмм классов. Там-то они прижились.

P. S. Выходила книга Бьянкуцци, Уорден. Пионеры программирования. В ней помимо всего прочего "трое друзей" рассказывают про историю UML, критикуют и предсказывают ему будущее. Pdf-ка гуляет по сети.

417

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 19 Июня 2016, 21:50:55 »

В примере 2-я диаграмма - состояние State6 определяет 3 стабильные конфигурации ({State7, State9},{State7, final},{final, State9}) и одну нестабильную - {final, final}. А если не будет исходящего без триггера перехода из State6 - 4 стабильные? А если такой переход будет, но с условием (которое может и выполняться, и невыполняться) - и то проскакивается, то не проскакивается?

Я рассматриваю способы указывать, что в некоторых состояниях генерируется событие завершения региона. Это можно делать, рисуя от таких состояний (псевдо)звено к псевдосостоянию "крестик без *". ("Крестик со *" будет генерировать завершение всей машины.) Конструкция из состояния и "крестика" будет по смыслу похожа на стандартное финальное состояние, с той лишь разницей, что от обычного состояния можно рисовать переходы, а от финального нельзя, что в обычном состоянии может быть do-деятельность, а в финальном нельзя, входные/выходные действия -- аналогично. Т. е. генерация завершений может быть изображена спец. обозначением -- псевдосостоянием, соединённым с обычным состоянием, а не неполноценным финальным недосостоянием.
Генерацию завершения можно изображать как спец. действие, хотя это может быть не так наглядно.
Рассуждения о нестабильности финальных состояний были неточны, признаю. Можно пытаться считать, что, попав в финальное состояние региона, автомат генерирует событие завершения региона и текущим состоянием становится сам завершённый регион (по Харелу регионы -- состояния). В случае с несколькими финальными состояниями внутри региона, это неудобно, так как может быть важно в каком именно из них произошло завершение.

418

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 19 Июня 2016, 20:24:04 »

Остаётся вариант, что история композитного состояния одна общая (это согласуется и с тем случаем, когда имеются по одному псевдосостоянию и глубокой и неглубокой истории - история у них общая).

Другой вариант, что, если непонятно в какую память записывать, то записывать в обе.) Думаю, что можно напридумывать правила, описывающие модель с несколькими памятями. Речь шла о визуальной метафоре, которая, как мне кажется, сообщает не о том, что есть несколько вариантов истории по умолчанию, а о том, что есть несколько историй. Вот у Харела предлагалось использовать в сторожевых условиях темпоральную логику, сведения о текущем состоянии в ортогональном регионе и т. п. В таком же духе можно от общей одной "вертолётной площадки" провести пунктиры к разным дефолтным предысториям и на пунктирах этих написать "сторожей", проясняющих выбор дефолтной предыстории.

Здесь в "площадку" звенья ни входят, ни выходят (правда это не Харел и не UML)

Создателям Симулинка, вероятно, так было проще реализовывать симулятор. Они и junction превратили в choice.) Реализаторская точка зрения тоже имеет значение, вообще говоря.

Конкретный синтаксис это вообще субъективно.

В подкрепление этого тезиса можно вспомнить конкретные синтаксисы от каждого из "троих друзей" до того как их "подружили".)

Состояния могут быть нестабильными, а псевдосостояния нестабильны всегда.

Могу ещё раз сказать, что стабильность определяется при работе автомата. Можно построить пример [бессмысленного] автомата без стабильных состояний. Упор на стабильность не поясняет, зачем в язык были введены псевдосостояния. Введены они как спец. обозначения, и относиться к ним, как я полагаю, стоит именно так. Можно поправить стандарт, указав там "могут/всегда", но это мало что прояснит о запрете, к примеру, цеплять к псевдосостоянию входное и выходное действие. Оно -- вершина? Вершина. Мы через неё проходим? Проходим -- вон стрелочки идут. Значит, входим и выходим, но не задерживаемся, ведь она нестабильная вершина. И т. д. Если говорить, что псевдосостояние -- это спец. обозначение, что звено, входящее в него или исходящее из него -- не переход, то такое описание будет адекватнее, как мне кажется. Про стабильность/нестабильность можно говорить, рассматривая работу автомата, если это важно по каким-то [другим] причинам.
Если угодно, разница между псевдосостоянием и обычным состоит в том, что для того, чтобы покинуть состояние придётся "съесть" из очереди событие (даже если это событие завершения, которое автомат сам себе может подкладывать в очередь в тот момент, когда "хочет" его съесть). Покидание псевдосостояния происходит сразу без "съедания" события из очереди. Но ведь можно нагромоздить и такое, что при проходе сквозь псевдосостояние порождается событие его завершения, а звено из псевдосостояния должно рассматриваться как переход по этому порождаемому событию. Так мы нивелируем разницу между проскакиваемым состоянием и псевдосостоянием с точки зрения работы автомата.

419

Для всех / Re: UCD для интернет-магазина

« : 19 Июня 2016, 14:03:20 »

Скорее всего поздно об этом писать, но всё же. Сравните свою диаграмму с таким решением:

Где проходит граница Вашей системы?

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

420

Для всех / Re: Концептуальная модель предметной области

« : 19 Июня 2016, 13:35:57 »

Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).

Если поле является массивом, элементы которого в свою очередь имеют поля, значит, его нужно моделировать по-другому. Посмотрите как это сделано на диаграмме с сайта uml-diagrams.

Цена товара может меняться в панели администратора. И странно, но при этом меняется цена в уже сформированных заказах...

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

Чтобы выявить другие ошибки в своём решении, попробуйте для себя обосновать, чем Ваше решение лучше, а чем хуже решений из Сети. Например, в таком духе: В решении с сайта uml-diagrams больше классов и связей, поэтому оно хуже моего. Но эти дополнительные классы и связи позволяют то-то и то-то, чего не может моё решение.