226

Примеры / Re: Когда следует создавать композитное состояние?

« : 07 Мая 2018, 14:13:10 »

На этой "обложечной" диаграмме свои вопросы:
1. почему из zero1 переходы по POINT и DIGIT_1-9 нарисованы по-разному?

Прети-принтинг) Может быть, так "красивше".)

2. если в состоянии begin будет OPER, но не "-", что дальше подключается OPER из ready или нет?

В PSCC2 есть кусок кода  [p.191] и пояснение к нему. Самек считает, что else ветка в его нотации означает, что событие не обрабатывается, а передаётся дальше обработчику суперсостояния. По стандарту такого быть не может. Одно событие может "поджечь" несколько переходов только, если каждый из них начинается в своём ортогональном  регионе композитного состояния.

 
3. что происходит при OPER в negated1: проверку делаем, но в любом случае больше ничего?

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

 
Где? Когда из begin есть свой OPER, а из ready свой?

Да. Уж было думало, что поймало Самека на горячем, ан нет. Стандарт говорит, что тут всё детерминировано.

227

Примеры / Re: Когда следует создавать композитное состояние?

« : 07 Мая 2018, 10:24:38 »

2. По калькулятору Самека есть вопросы:
...
4. какой смысл имеет указание внутреннего перехода без действий, например в zero1 есть внутренний переход без действий по DIGIT_0 и нет перехода по EQUALS - в обоих случаях ничего не происходит.

То ли у него протокольная стейт-машина, то ли для дидактики ему нужны эти ничего не делающие внутренние переходы.

На "обложке" дана диаграмма калькулятора в нотации Самека, к слову.

P. S. Оценило, что калькулятор иллюстрирует стандартное правило выбора одного перехода из конфликтующих.

228

Примеры / Re: Когда следует создавать композитное состояние?

« : 06 Мая 2018, 18:40:49 »

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

Автор утверждает в тексте, что есть девайс как "исходник" модели. Который демонстрирует моделируемое поведение. Имелось в виду, что он есть только у автора. В тексте есть одна трасса. И общие слова. По этому мне сложно чекать модель. Судя по фотке девайса, на нем есть кнопки, которых в модели нет.)
 

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

По изложению учебного примера выходит не совсем так. С самого начала появляются эти имена (operand1-2), к тому же совпадающие с нетерминалами БНФ.

Для begin есть возможность задать знак (переход к negated1), а для result - нет, различия есть. Много общего, но есть различия - делай композит.

Ну, можно сторожа усложнить и таки "склеить" begin-о-result т. е. ready.
Кажется, автор свои приёмы моделирования рассказывает в PSCC2. Здесь он рассказывает, как может протекать ход моделирования. Неудачно, на мой взгляд.

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

Для калькулятора, больше похожего на настоящий, а не на калькулятор Самека, может быть меньше сложностей. Мне так кажется.

229

Примеры / Re: Когда следует создавать композитное состояние?

« : 06 Мая 2018, 11:34:48 »

композит ready и negated1 тоже имеет смысл для логики работы калькулятора - в нём он готов к вводу цифровой части числа-операнда

Некоторая трудность в том, что кроме модели другого описания (достаточно точного) поведения калькулятора нет (скачать прогу, которая якобы реализует, я не смогло). Поэтому логику приходится "считывать" из модели. А читатели разные. Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.
Модель, очевидно, не совершена. Наличие отдельного от begin result'а (а вслед за ним и ready) выглядит ненужным усложнением. Вероятно, потому, что т. н. "калькулятор" только "ест" нажатия своих кнопок и куда-то "инсёртит" цифры и что-то "негатит". Но не считает.

композит ready и negated1 объединит 3 исходящих перехода (ready объединяет 4). Кстати, отсутствие перехода по OPER от negated1 выглядит подозрительно.

Всё это так. Но с тем же результатом можно потрошить любой учебный пример.
Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?

230

Примеры / Re: Когда следует создавать композитное состояние?

« : 05 Мая 2018, 06:35:53 »

Вопрос: почему для состояний result и begin заведено композитное состояние ready, а для ready и negated1 - нет?

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

Интересно также наблюдать эволюцию конкретно этой диаграммы в разных версиях текста. Вместо переходных псевдосостояний сейчас псевдосостояния выбора. Появился повод пересмотреть "Practical UML Statecharts in C/C++" II. Где обнаружились паттерны создания диаграмм состояний, пример с "ошибкой Фаулера/Рамбо" и прочие сласти (действие по выходу, управляющее историей состояния).

231

Для всех / Re: Нужна помощь в создании набора UML-диаграмм для интернет-магазина

« : 26 Апреля 2018, 16:21:46 »

Не могли бы вы помочь с диаграммами?

Судя по всему, модель строится из учебных целей. Судя по всему, проверяться будет в основном владение "рисовалкой" и соблюдение правил того "учебного UML", который дают в неназванном вузе. Вряд ли проверяющий будет выискивать недостающие ВИ, скорее успокоится, если их количество будет достаточно большим. Вряд ли проверяющий будет рад стикерам и А4.
Чтобы порадовать проверяющего, рекомендую раздобыть книгу:
Применение объектного моделирования с использованием UML и анализ прецедентов на примере книжного Internet-магазина / К. Скотт, Д. Розенберг .— М. : ДМК-Пресс, 2007 .— 160 с. : ил. — (Объектно-ориентированные технологии в программировании) .— пер. с англ. - ISBN 0-201-73039-1 (англ.). - ISBN 5-94074-050-2 (рус.) .— ISBN 978-5-94074-050-2
Она Вам поможет решить свою учебную задачу, как мне кажется.

232

Для всех / Re: Прошу помощи с прохождением аналитической игры

« : 18 Апреля 2018, 22:16:15 »

...

[Сползаем в офтопик]. Научпоп, которым является указанный "проект ... в открытом доступе", не стоит путать с образованием, в том числе, высшим. Ленность препода не является поводом пытаться майнить очки, перепосчивая задание по форумам, в том числе, непрофильным.

233

Для всех / Re: Прошу помощи с прохождением аналитической игры

« : 18 Апреля 2018, 15:39:12 »

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

234

Примеры / Re: Курсовой проект "Стиральная машина "

« : 15 Апреля 2018, 20:40:26 »

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

235

Реализация / Re: Композиция, Агрегация

« : 01 Марта 2018, 11:10:48 »

Колесо можно открутить и лишь потом расхреначить авто.)
Композиция с 0..1 у ромба позволяет части существовать без целого (части [?]чего[?], спрашивается).
Фархутдинов пишет:

..in some cases a part can be removed from a composite before the composite is deleted, and so is not necessarily deleted as part of the composite.

236

Реализация / Re: Композиция, Агрегация

« : 01 Марта 2018, 09:33:47 »

"... которое обеспечивает выполнение этого структурного ограничения.

Или не обеспечивает.)

237

Реализация / Re: Композиция, Агрегация

« : 01 Марта 2018, 01:00:34 »

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

238

Примеры / Re: Диаграмма ВИ. Работа с выборками

« : 18 Февраля 2018, 15:30:24 »

Однако для меня только лучше, если кто-то, особенно с другой планеты, скажет где и что я делаю не так (:

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

Если Ваша аудитория готова мириться с тем, что описания ВИ большие и структурированные на потоки, подпотоки, подподпотоки, ... если Вы готовы мириться с частичным дублированием описаний разных ВИ, то структурированная ДВИ со связями между ВИ не нужна. В таком случае описание главного ВИ объемлет всё. Включения и расширения не имеют собственных отдельных описаний и существуют как части описания главного ВИ.

SALar "развинчивает" Вашу диаграмму не с точки зрения нотации, а с аналитической, со смысловой. Скорее всего, для практических задач это важнее.

Galogen даёт советы, исходя из обоих точек зрения.

239

Примеры / Re: Диаграмма ВИ. Работа с выборками

« : 15 Февраля 2018, 16:42:17 »

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

240

Для всех / Re: Помогите с диаграммой классов для описания предметной области

« : 08 Февраля 2018, 20:09:13 »

В текущей версии комплекс -- не товар (значит, не имеет стоимости, не может быть включён в заказ).
Единственная операция на диаграмме кажется странной. Что, куда предполагается добавить?
Минимальные мощности 1 не всюду уместны. Например, водку (добавку) можно добавить в томатный сок (напиток), но не обязательно её ещё и в борщ (еда) плескать или в пельмени из шприца заряжать (еда). Опять же водку можно и в виноградный сок добавить (ну хорошо-хорошо, пусть будет чай+сахар, кофе+сахар).
Начать было удобно с внятного текстового описания ПО, которую предстоит визуально моделировать.