196

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 19 Июня 2018, 12:18:01 »

Стилистически вложение3 лучше ложится на исходный текст. Вложение4 лучше бы легло на текст "если время истечёт раньше наступления События - Действие3, иначе - Действие2".
Стилистически вложение5 не годится, т. к. "ничегонеделательная" деятельность -- костыль "модельера", который (костыль, не "модельер") не должен торчать явно из модели.
По стандарту, скорее всего, все 3 варианта прочекаются.
P. S. К делу не относится, но задачка от авторов "UML3" (см. слайды 50-51) сомнительная какая-то. Как видится с моей планеты.

197

Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы

« : 02 Июня 2018, 09:01:14 »

Диаграмма является продолжением примера, в котором в начале приводится (составляется) диаграмма т. н. "top level UC", а затем вводятся UC уровня пониже. Пример иллюстрирует примитивы языка. Он сродни учебным текстам из учебника английского языка.
Можно в N-ный раз зайти на круг разговоров о том, что язык не является технологией, что на практике отдельные средства языка могут оказаться уместны или не уместны.
В правилах языка может что-то нравиться, что-то не нравиться. Мне, например, не нравится многое накрученное понапрасну вокруг include'ов. Как иллюстрация ещё одна страничка с того же сайта. Увязывание abstract с incomplete, concrete с complete видится мне лишним. Как и заклинание о якобы безусловном включении.

198

Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы

« : 30 Мая 2018, 21:17:15 »

А что-нибудь кроме этого?

Пример с сайта Kirill'a Fakhroutdinov'a:


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

199

Обсуждение статей / Re: Интревью с Грэди Бучем

« : 26 Мая 2018, 20:14:38 »

Главное научиться ловить попутный тахионный поток. Остальное -- дело техники.

200

Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы

« : 26 Мая 2018, 20:10:32 »

Пример нарисовали Рамбо и Блаха в своей книге:

Ещё раз обращаю внимание, ответ дан в смысле соблюдения/нарушения стандарта UML.
Можно вместо стандарта рассматривать правила каких-либо методик, стилей рисования диаграмм и проч. Можно восклицать: "Что в голове у автора диаграммы!" -- как это кое-где кое у кого принято. Можно всё.
P. S. Авторы стандарта придумали операцию allIncludedUseCases(), которая собирает все включённые (непосредственно или косвенно) UC для заданного UC. Если бы косвенное включение не допускалось бы стандартом, то учитывать бы его не стали и OCL-body для операции было бы проще.

201

Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы

« : 25 Мая 2018, 15:49:06 »

Разрабатываю USE CASE диаграмму для учебного проекта. Есть сомнения в ее правильности, в связи с этим два вопроса:

Без текстовых описаний ВИ и условий Вашего учебного проекта затруднительно оценить правильность в плане содержания. Остаётся оценивать соблюдение правил стандарта UML.

1. Легально ли делать связь "include" к прецеденту, который уже является "инклудом" для другого прецедента?

Да.

2. Можно ли связывать актора, допустим, с одним прецедентом "include", при этом не связывая с основным?

Можно. Если направлением связи Вы показываете является ли действующее лицо основным, то стрелки идут обычно от включаемых ВИ ко второстепенным ДЛ. Иначе может оказаться, что у включаемого ВИ два основных ДЛ: 1) непосредственно связанной с ним + 2) основное ДЛ включающего ВИ.

Содержательная "правильность" инклудов вытекает из описаний сценариев ВИ. Но Вы их не приводите (у Вас их нет). Значит учебное упражнение в этой части бессмысленно. 

202

Обсуждение статей / Re: Интревью с Грэди Бучем

« : 25 Мая 2018, 15:37:51 »

До моей планеты добивает YouTube, но с задержкой. Космические расстояния дают о себе знать.
https://youtu.be/wy9pEIX7paQ
Гради Буч  к юбилею UML 1.1.

203

Примеры / Re: Помощь в задании.

« : 25 Мая 2018, 15:31:36 »

Зачем в течения дня одному и тому же читателю выдавать один и тот же экземпляр и фиксировать это?

Ксеранул, сдал, понял, что недоксерил, вернулся, взял снова, доксерил, сдал...
)

Впрочем это все рассуждения бессмысленные, мы с вами ясных требований не знаем.

Поддерживаю.

204

Примеры / Re: Помощь в задании.

« : 19 Мая 2018, 14:26:43 »

Если в читальный зал, то не достаточно.
А кто когда был в библиотеке [по своей воле]? Я -- лет 18ть назад, перед защитой диссера в марсианском универе.
От условий задачи несёт книжной пылью учебника. 

205

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

« : 09 Мая 2018, 22:03:16 »

Это пояснение:?

Оно.

Может наоборот

Может.)
В PSCC2 нет нотации Самека. Так что, это вольное инопланетное допущение, что код имеет отношение к картинке с обложки другой публикации. Поэтому он может расходиться с ним.
QM 4.2.0 вышла в 2018м. Вероятно, к этому времени Самек пришёл к логичному выводу, что раз уж это его прихоть всегда вместе со сторожем рисовать ромб, работать такой однохвостый псевдовыбор должен как обычный UML-переход со сторожем (а многохвостый -- как композитный UML-переход с choice). Раньше он мог думать и рисовать иначе.

Воплощены

Опытный лектор приберегает материал про запас.)

206

Примеры / 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 свой?

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

207

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

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

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

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

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

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

208

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

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

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

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

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

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

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

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

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

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

209

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

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

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

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

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

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

210

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

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

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

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

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