421

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

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

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

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

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

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

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

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

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

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

422

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

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

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

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

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

423

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

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

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

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

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

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

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

424

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

« : 18 Июня 2016, 23:18:25 »

Сделал вот такую диаграмму.

Если Вы воспользуйтесь поиском по форуму, библиографией и т. д., то сможете обнаружить ошибки в своём решении.

425

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

« : 18 Июня 2016, 22:54:21 »

Не совсем понял мысль. В модели преподавателя нет журнала покупок, он как раз в модели из интернета.

Я не обратил внимания на названия изображений, приложенных к Вашему сообщению. Из-за чего ошибся, так как предположил, что ER-диаграмму Вам дал преподаватель в качестве примера, а в Сети Вы нашли диаграмму классов. Раз преподаватель Вам выдал диаграмму классов, то воспользуйтесь соответствующей ссылкой, примером запроса, библиографией. А про ER-диаграмму забудьте.
Дополнения для Visio, чтобы рисовать UML-диаграммы находятся тут: http://www.softwarestencils.com/uml/

426

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

« : 18 Июня 2016, 13:50:04 »

Добрый день.
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.

Найденный Вами пример в интернете (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
Учебный пример с интернет-магазином подробно рассматривается в книгах по UML:
Мацяшек "Анализ и проектирование информационных систем с помощью UML 2.0"
Розенберг, Скотт "Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного internet-магазина"
Коналлен "Разработка веб-приложений с использованием UML"
Магазины в книгах разные (книжные, видеокассетные, ...) но это не принципиально.
На этом форуме также есть несколько заходов на модели интернет-магазинов. [Воспользуйтесь поиском по форуму.]
Думаю, что и по ER-моделям можно найти книги.

[В сторону] Для студенческих задач на форуме есть свой раздел.

427

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

« : 18 Июня 2016, 11:54:02 »

Убрать из 14.5.8.6 первые 2 ограничения.

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

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

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

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

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

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

В "математических" автоматах финальное состояние играет другую роль: если обработка последовательности сигналов завершилась в финальном состоянии, то последовательность "правильная".

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

428

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

« : 17 Июня 2016, 17:25:38 »

Сначала о глобальном - мне нравится, как проходит обсуждение, поэтому появились вопросы:

• есть ли в интернете другие места (лучше русскоязычные), где обсуждения похожих тем (нюансы языков моделирования) происходят так же конструктивно?
• почему молчит остальная аудитория форума, варианты:
  
  • джуниоры пытаются разобраться в том, что все уже давно знают - пусть разбираются сами, лучше усвоят;
  • очень важная, но сложная тема - сказать по ходу нечего, дождёмся результатов;
  • то, что обсуждают, никому никогда не понадобится, но влезать - себе дороже?

Мне тоже понравился наш обмен мнениями. Так перемыть косточки UML у меня даже с коллегами на работе не получалось.
Других мест не знаю, т. к. не искал. Может быть, кто-то из старожилов подскажет.
Комментировать участие/неучастие в этой теме других участников не возьмусь. Я почти их не знаю.

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

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

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

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

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

Мне интересно, откуда появилась в UML такая трактовка? Уж не от неудавшегося сращивания диаграмм состояний с диаграммами деятельности в 1-й версии UML? Ведь в "математических" автоматах финальное состояние -- обычное состояние с дополнительным свойством, т. е. у математиков оно в каком-то смысле больше, чем обычное состояние, а не наоборот.

429

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

« : 17 Июня 2016, 02:19:32 »

На картинке - верхний автомат: как добиться того же эффекта с одним историческим (то, что триггер "a" на горизонтальных стрелках, а триггер "b" на вертикальных - случайное совпадение)?

От предыстории по умолчанию можно избавиться, заведя переменную-признак "были ли мы в State1", добавить действия по её инициализации и изменению, раздвоить переходы в State1 через choice/junction со сторожем, который при истинности признака ведёт нас в единое псевдосостояние истории, при ложности -- в нужное подсостояние внутри State1. Понятное дело, что с помощью введения переменной можно вообще избавиться от исторических псевдосостояний.
 

На картинке - нижний автомат: как добиться того же эффекта без перехода из финального состояния (последовательность триггеров "аа" приводит к State8, "ab" и "ba" - к State10)?

Можно убрать явный переход из финального состояния, финальное состояние в верхнем регионе сделать обычным, завести две переменные-признака x1 -- "завершён ли верхний регион?" и x2 -- "завершён ли нижний регион?", добавить их инициализацию и действия по изменению, групповой переход по завершению из State6 заменить на переход по триггеру -- событию изменения when(x1 and x2).

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

430

Примеры / Re: Дипломная работа: варианты использования+диаграмма деятельности по СЭД

« : 14 Июня 2016, 14:38:20 »

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

431

Задачи студентов / Re: Диаграмма вариантов использования

« : 13 Июня 2016, 13:24:17 »

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

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

432

Задачи студентов / Re: Диаграмма вариантов использования

« : 13 Июня 2016, 13:08:55 »

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

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

433

Задачи студентов / Re: Диаграмма вариантов использования

« : 13 Июня 2016, 12:58:58 »

В смысле?

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

434

Задачи студентов / Re: Диаграмма вариантов использования

« : 13 Июня 2016, 12:40:13 »

Я моделирую процесс амбулаторного осмотра.

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

Преподаватель говорит что все ВИ должны быть связанны, поэтому делал так. Предыдущую модель он забраковал т.к. там были висящие ВИ, то есть от АКТЕР ->ВИ и всё. 

Такое сложно комментировать.

То есть мне надо сделать связь от симптомов к заполнению листа приема? А оформление справок(исправлю на глаг.фразу) справок тогда с чем нужно связать?

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

435

Задачи студентов / Re: Диаграмма вариантов использования

« : 13 Июня 2016, 12:10:57 »

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

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