Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
IMHO серийный учет при торговле постельным бельем вряд ли используется.Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.
Клиент может и не авторизироваться для оформления заказа.Согласно Вашей диаграмме ВИ (прежней её версии) авторизация обязательно происходила при оформлении заказа (связь включения между ВИ). Вместо 3-х тем, каждая из которых про отдельный тип диаграмм, удобнее было бы иметь одну тему по всей Вашей модели. Диаграммы и описания (части модели) должны подходить друг к другу, иначе целостной модели не получится. Отвечать, Вам отслеживая изменения в одной модели, разбросанные по трём темам, затруднительно.
пункт 7.2 подразумевает не ввод данных для авторизации, а ввод контактных данных (им, телефон, почта) для оформления заказа и последующей регистрации.
Дело в том, что всегда непонятно в какую память записывать, поэтому если записывать в обе,то обе памяти оказываются идентичными.Каждый выход происходит после какого-то входа. Часть входов происходит по левому пути (через левую память), часть по правому. Через какую память входили, в ту и пишем.
Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).Харел использовал "системные переменные", которые описывают [текущую | прошлую] конфигурацию состояний автомата. Они не вводятся автором диаграммы. Пример стандартной "системной переменной" без имени -- время -- в событиях времени at(12pm), after(1ns).
По поводу пунктиров: они будут выражать невозможность повесить триггер, но есть и другие ограничения, например обязательное отсутствие сторожа и/или деятельности на переходе. Есть еще одно соображение (не против визуального выделения, а против именно пунктира) - когда рисуешь от руки на бумаге, то часто сначала ясно, что нужна соединительная линия, а только потом ясно, какого она типа. А превратить нарисованную сплошную в пунктирную достаточно затратно, уж лучше бы сделать какую-нибудь пометку. Но это опять про конкретный синтаксисДумаю, что, разделяя звенья и псевдозвенья, можно договориться о том, что на самом деле запрещать на псевдозвене (и не запрещать сторожей и эффекты просто ради запрета). Пунктиры взяты по аналогии с зависимостями с диаграмм классов. Там-то они прижились.
Я рассматриваю способы указывать, что в некоторых состояниях генерируется событие завершения региона. Это можно делать, рисуя от таких состояний (псевдо)звено к псевдосостоянию "крестик без *". ("Крестик со *" будет генерировать завершение всей машины.) Конструкция из состояния и "крестика" будет по смыслу похожа на стандартное финальное состояние, с той лишь разницей, что от обычного состояния можно рисовать переходы, а от финального нельзя, что в обычном состоянии может быть do-деятельность, а в финальном нельзя, входные/выходные действия -- аналогично. Т. е. генерация завершений может быть изображена спец. обозначением -- псевдосостоянием, соединённым с обычным состоянием, а не неполноценным финальным недосостоянием.
В примере 2-я диаграмма - состояние State6 определяет 3 стабильные конфигурации ({State7, State9},{State7, final},{final, State9}) и одну нестабильную - {final, final}. А если не будет исходящего без триггера перехода из State6 - 4 стабильные? А если такой переход будет, но с условием (которое может и выполняться, и невыполняться) - и то проскакивается, то не проскакивается?
Остаётся вариант, что история композитного состояния одна общая (это согласуется и с тем случаем, когда имеются по одному псевдосостоянию и глубокой и неглубокой истории - история у них общая).Другой вариант, что, если непонятно в какую память записывать, то записывать в обе.) Думаю, что можно напридумывать правила, описывающие модель с несколькими памятями. Речь шла о визуальной метафоре, которая, как мне кажется, сообщает не о том, что есть несколько вариантов истории по умолчанию, а о том, что есть несколько историй. Вот у Харела предлагалось использовать в сторожевых условиях темпоральную логику, сведения о текущем состоянии в ортогональном регионе и т. п. В таком же духе можно от общей одной "вертолётной площадки" провести пунктиры к разным дефолтным предысториям и на пунктирах этих написать "сторожей", проясняющих выбор дефолтной предыстории.
Создателям Симулинка, вероятно, так было проще реализовывать симулятор. Они и junction превратили в choice.) Реализаторская точка зрения тоже имеет значение, вообще говоря.
Здесь в "площадку" звенья ни входят, ни выходят (правда это не Харел и не UML)
В подкрепление этого тезиса можно вспомнить конкретные синтаксисы от каждого из "троих друзей" до того как их "подружили".)
Конкретный синтаксис это вообще субъективно.
Могу ещё раз сказать, что стабильность определяется при работе автомата. Можно построить пример [бессмысленного] автомата без стабильных состояний. Упор на стабильность не поясняет, зачем в язык были введены псевдосостояния. Введены они как спец. обозначения, и относиться к ним, как я полагаю, стоит именно так. Можно поправить стандарт, указав там "могут/всегда", но это мало что прояснит о запрете, к примеру, цеплять к псевдосостоянию входное и выходное действие. Оно -- вершина? Вершина. Мы через неё проходим? Проходим -- вон стрелочки идут. Значит, входим и выходим, но не задерживаемся, ведь она нестабильная вершина. И т. д. Если говорить, что псевдосостояние -- это спец. обозначение, что звено, входящее в него или исходящее из него -- не переход, то такое описание будет адекватнее, как мне кажется. Про стабильность/нестабильность можно говорить, рассматривая работу автомата, если это важно по каким-то [другим] причинам.
Состояния могут быть нестабильными, а псевдосостояния нестабильны всегда.
Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).Если поле является массивом, элементы которого в свою очередь имеют поля, значит, его нужно моделировать по-другому. Посмотрите как это сделано на диаграмме с сайта uml-diagrams.
Понятно, что моделируемый в рамках учебного примера интернет-магазин может отличаться от реального, но, наверное, не так сильно.
Цена товара может меняться в панели администратора. И странно, но при этом меняется цена в уже сформированных заказах...
Сделал вот такую диаграмму.Если Вы воспользуйтесь поиском по форуму, библиографией и т. д., то сможете обнаружить ошибки в своём решении.
Не совсем понял мысль. В модели преподавателя нет журнала покупок, он как раз в модели из интернета.Я не обратил внимания на названия изображений, приложенных к Вашему сообщению. Из-за чего ошибся, так как предположил, что ER-диаграмму Вам дал преподаватель в качестве примера, а в Сети Вы нашли диаграмму классов. Раз преподаватель Вам выдал диаграмму классов, то воспользуйтесь соответствующей ссылкой, примером запроса, библиографией. А про ER-диаграмму забудьте.
Добрый день.Найденный Вами пример в интернете (UML-диаграмма) неудачен, т. к. относится к иной предметной области. Модель от преподавателя (ER-диаграмма) является хорошей заготовкой ответа (из которой, быть может, следует убрать лишнее, заменить "журнал(?) покупок" на "часть покупки", исправить мощности: покупка -1-включает-n- часть покупки, часть покупки -n-связана с-1- товар) Моделирование интернет-магазинов часто используемое учебное упражнение. Для него есть множество ответов с сети. Например, такая диаграмма классов: http://www.uml-diagrams.org/examples/class-example-online-shopping-domain.png может быть найдена в гугль-картинках запросом вроде class diagram uml shop. Если исправить запрос на entity relationship diagram shop, также найдётся масса вариантов. Например, такой: http://creately.com/jupiter/diagram/image/gyhd76iq2
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.
Убрать из 14.5.8.6 первые 2 ограничения.Я думал о том, что затруднительно описать ограничение, которое бы сказало, что диаграмма "с душком" (например, из-за недетерминированного составного перехода, у которого несколько звеньев заканчиваются в разных исторических псевдосостояниях одного региона). Впрочем, такие сложности не связаны именно с множественностью исторических псевдосостояний, должен признать.
Просто каждый вход в композитное состояние может иметь своё отношение к обработке истории (строго говоря каждый вход внутрь и одно общее на все входы на границу композитного состояния): будет ли учитываться предыдущее посещение композитного состояния и, если да, то что делать, если предыдущего посещения не было.Попробую так. Конкретный синтаксис с несколькими предысториями допускает толкование, что для каждого способа входить в состояние по предыстории (в Вашем примере от 16.06 таких способов у State1 два -- левый и правый) есть отдельная память, ведущая независимую историю. Т. е. при входе слева срабатывает левая предыстория, справа -- правая. Если бы "вертолётная площадка" была одна, повода для такого толкования не возникало бы.
Когда-то такой знак "вертолётной площадки" и был тэгом на композитном состоянии (без входящих и исходящих переходов), что означало, что любой повторный вход в композитное состояние означает продолжение с места прерывания. Потом стало ясно, что это слишком узко, что иногда надо продолжить, а иногда и начать по новой.Замечу, что у Харела (автора предысторий) во всех его примерах в "площадку" обязательно входит звено. То есть, у него это не совсем тэг.
В "математических" автоматах финальное состояние играет другую роль: если обработка последовательности сигналов завершилась в финальном состоянии, то последовательность "правильная"."Математическая" трактовка почти та же, что у протокольных диаграмм состояний. А протокольные финальные состояния нечем не отличаются от обычных.
Сначала о глобальном - мне нравится, как проходит обсуждение, поэтому появились вопросы:Мне тоже понравился наш обмен мнениями. Так перемыть косточки UML у меня даже с коллегами на работе не получалось.
- есть ли в интернете другие места (лучше русскоязычные), где обсуждения похожих тем (нюансы языков моделирования) происходят так же конструктивно?
- почему молчит остальная аудитория форума, варианты:
- джуниоры пытаются разобраться в том, что все уже давно знают - пусть разбираются сами, лучше усвоят;
- очень важная, но сложная тема - сказать по ходу нечего, дождёмся результатов;
- то, что обсуждают, никому никогда не понадобится, но влезать - себе дороже?
Наличие и трактовка перехода из исторического псевдосостояния как раз направлены на избавление от такой переменной-признака.Справедливо. С переменными диаграмма становится более императивной, что не всегда желательно.
неважно сколько исторических псевдосостояний, при выполнении можем одновременно добраться только до одного.Это так, но, вероятно, придётся прописать такое положение в языке. Сделать это формально (на OCL) затруднительно. Сама нотация может обескураживать: несколько псевдосостояний предыстории изображают одну предысторию и несколько меток для состояний, являющихся предысторией по умолчанию. Мне кажется, что такая пометка состояния могла бы делаться не звеном из "вертолётной площадки", а тегом на самом состоянии. Хотя такой вариант, скорее всего менее нагляден, чем стандартный.
Отсутствие в финальном состоянии do-деятельностей и внутренних переходов обусловлено тем, что хочется подчеркнуть, что ничего существенного (с точки зрения региона/состояния, к которому относится финальное состояние) уже произойти не может - только выход, причём это будет и выход из региона/состояния. Но оказалось, что в случае композитного ортогонального (в отличие от неортогонального) состояния появляется новая ситуация - часть регионов достигла финального состояния, а часть - нет.Мне интересно, откуда появилась в UML такая трактовка? Уж не от неудавшегося сращивания диаграмм состояний с диаграммами деятельности в 1-й версии UML? Ведь в "математических" автоматах финальное состояние -- обычное состояние с дополнительным свойством, т. е. у математиков оно в каком-то смысле больше, чем обычное состояние, а не наоборот.
На картинке - верхний автомат: как добиться того же эффекта с одним историческим (то, что триггер "a" на горизонтальных стрелках, а триггер "b" на вертикальных - случайное совпадение)?От предыстории по умолчанию можно избавиться, заведя переменную-признак "были ли мы в State1", добавить действия по её инициализации и изменению, раздвоить переходы в State1 через choice/junction со сторожем, который при истинности признака ведёт нас в единое псевдосостояние истории, при ложности -- в нужное подсостояние внутри State1. Понятное дело, что с помощью введения переменной можно вообще избавиться от исторических псевдосостояний.
На картинке - нижний автомат: как добиться того же эффекта без перехода из финального состояния (последовательность триггеров "аа" приводит к State8, "ab" и "ba" - к State10)?Можно убрать явный переход из финального состояния, финальное состояние в верхнем регионе сделать обычным, завести две переменные-признака x1 -- "завершён ли верхний регион?" и x2 -- "завершён ли нижний регион?", добавить их инициализацию и действия по изменению, групповой переход по завершению из State6 заменить на переход по триггеру -- событию изменения when(x1 and x2).
