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

×


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

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


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

Страницы: « 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 32 33 »
406
Как-то так получается.
У производителя есть код производителя, но у пользователя -- вместо кода пользователя код администратора. Плох тот пользователь, что не хочет быть администратором?
Заказ с видом доставки связывает помимо линии вид доставки. Что связывает элемент заказа с заказом помимо линии? А с товаром?
Во всех "прямоугольничках" есть что-то красненькое. Хотя, не во всех. В одном нет. Почему?
На примере от преподавателя нет "куриных лапок". А у Вас есть.  Примет ли преподаватель диаграмму с "лапками"?

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

А как воспринимать звено, которое заканчивается на "вертолётной площадке", но не пересекает границы композитного состояния (Harel "STATECHARTS: A VISUAL FORMALISM FORCOMPLEX SYSTEMS*" Fig.14)?
Как переход в запомненное в истории состояние. Или в дефолтную предысторию, если ничего не запомнено. Или в [дефолтное] начальное состояние, если дефолтной предыстории нет, или не можем понять, какая она.
Попутно вопрос по этой диаграмме: вместо использования конструкции с историческим псевдосостоянием можно завести внутренний переход в состоянии update (хотя бы в UML)?
у него там, как я понял, идея в том, чтобы параметризовать эффект такого перехода (в зависимости от состояния апдейтить разные переменные). Почему там важно оставаться внутри композитного состояния, я не уяснил, но пусть так. В UML придётся завести по локальному переходу со своим эффектом в каждом подсостоянии. Если эффект одинаков, то локальный переход может быть общим и лежать в композитном состоянии. 

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

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

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

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

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

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

Да, это формально допустимый вариант, но он требует введения переменной, которая будет содержать информацию для работы "сторожей". А переменная требует инициализации значения и ...(выше уже говорилось: "переменные сильно снижают наглядность диаграммы"). Другое дело, если переменные уже существуют для обслуживания автомата - например используются в каких-то деятельностях (entry, exit, do или на переходах).
Харел использовал "системные переменные", которые описывают [текущую | прошлую] конфигурацию состояний автомата. Они не вводятся автором диаграммы. Пример стандартной "системной переменной" без имени -- время -- в событиях времени at(12pm), after(1ns).
По поводу пунктиров: они будут выражать невозможность повесить триггер, но есть и другие ограничения, например обязательное отсутствие сторожа и/или деятельности на переходе. Есть еще одно соображение (не против визуального выделения, а против именно пунктира) - когда рисуешь от руки на бумаге, то часто сначала ясно, что нужна соединительная линия, а только потом ясно, какого она типа. А превратить нарисованную сплошную в пунктирную достаточно затратно, уж лучше бы сделать какую-нибудь пометку. Но это опять про конкретный синтаксис ;)
Думаю, что, разделяя звенья и псевдозвенья, можно договориться о том, что на самом деле запрещать на псевдозвене (и не запрещать сторожей и эффекты просто ради запрета). Пунктиры взяты по аналогии с зависимостями с диаграмм классов. Там-то они прижились.

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

414

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

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

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

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

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

416
Для всех / Re: UCD для интернет-магазина
« : 19 Июня 2016, 14:03:20 »
Скорее всего поздно об этом писать, но всё же. Сравните свою диаграмму с таким решением:

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

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

417
Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).
Если поле является массивом, элементы которого в свою очередь имеют поля, значит, его нужно моделировать по-другому. Посмотрите как это сделано на диаграмме с сайта uml-diagrams.


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

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

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

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

420
Добрый день.
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.
Найденный Вами пример в интернете (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-моделям можно найти книги.

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

Страницы: « 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 32 33 »