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

×


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

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


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

Страницы: « 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 »
466
Кажется, что эти утверждения противоречат друг другу, но это не так. В первом идет речь о синтаксисе и под словом "переход" подразумевается то, что на диаграмме изображается ровно одной линией со стрелкой, которая идет от (псевдо)состояния источника к (псевдо)состоянию цели. Во втором же говорится о семантике, и под словом "переход" понимается смена одного состояния на другое (под состоянием здесь понимается тоже не то, что в первом).
Разница хорошо ощущается при ортогональных композитных состояниях:
   в первом утверждении состояния это 1) DisplayTime 2) DisplayAlarmTime 3) PlayCD 4) PlayRadio;
   во втором утверждении состояния это 1) DisplayTime&PlayCD 2) DisplayTime&PlayRadio 3) DisplayAlarmTime&PlayCD 4) DisplayAlarmTime&PlayRadio.
Владелец перехода -- элемент метамодели UML, т. е. речь не только от том, как изображать на диаграмме. Я полагаю, что владение переходом определяет не только внешний вид. Кстати, вопрос, кто владеет каждым рассматриваемым переходом.)
Разницу можно прочувствовать, если добавить действия по выходу в каждое вложенное состояние (stopDispleying..., stopPlaying...), или считать, что есть do-деятельности и следить, прерываются они или нет. По второй трактовке получается, что несмотря на то, что владеет переходом нижний регион[?], срабатывание перехода вызывает прекращение do-деятельностей в верхнем регионе (или выполнение действий по выходу).
У Рамбо и Блахи в их книге "UML 2.0. Объектно-ориентированное моделирование и разработка" есть пример 6.11 с термостатом. Я полагаю, что он нарисован по 1й трактовке. Иначе выходит, что установка часов вызывает переключение единиц измерения температуры (с Цельсиев на Фаренгейты).

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

468
А если, например, включение радио или CD происходит в зависимости от истории. Как это показать? Да, и все-таки, радио или CD включается всегда при включение будильника, или в момент возникновения события будильника? На диаграмме, например можно предположить отражение текущего времени, включения сигнала будильника (т.е. радио или плеера :)
Vadim дельно описал, для чего Фаулер помещал на диаграмму историческое псевдосостояние. Поясню, почему событие on я связываю со срабатыванием будильника. Других кандидатов на срабатывание нет, а будильник должен когда-то срабатывать.

469
Эти диаграммы эквивалентны только тогда, когда нет действий (по терминологии Рамбо и Блаха) или активностей (по терминологии Фаулера) ни при выходе из состояния, ни при входе в состояние, ни при переходе. Например: пусть при входе в состояние Play(ing)Radio происходит настройка на "любимую" станцию. В одной диаграмме настройка будет происходить при любом событии Radio, а в другой - только если состояние Play(ing)CD.
Точно замечено.
Поэтому разумнее рассматривать примеры с действиями, что, возможно, расходилось с целью книги Фаулера -- дать беглый обзор языка.
Многие источники (не только Фаулер) считают, что историческое псевдосостояние без входящего перехода, но с исходящим переходом заменяет начальное псевдосостояние, когда происходит первый вход. То есть, при первом входе в состояние On текущим состоянием в нижнем регионе становится Play(ing)Radio.
Интересная тема: возможные варианты сочетания начального и исторического псевдосостояний в одном регионе и наличия (отсутствия) исходящих (входящих) переходов исторического псевдосостояния (с начальным всё ясно: не более одного, никаких входящих и ровно один исходящий)!
Если опираться на стандарт, то такие трактовки следует отвести. Псевдосостояние истории сродни начальному состоянию в том смысле, что это специальные обозначения, что (непосредственно) внутри региона их не может быть больше одного. Но назначения у них разные. Если нет входящих переходов в историческое псевдосостояние, то оно лишь указывает, что автомат запоминает историю, но воспользоваться этой историей в своём поведении он не может.
Вокруг начального много накручено. Несколько исходящих, случай, когда допускается триггер...

470
В исходном тексте:"Figure 10.5 shows a pathetically simple alarm clock that can play either CDs or the radio and show either the current time or the alarm time." То есть, имелось в виду, что когда будильник срабатывает (событие on), то может либо заиграть CD, либо заработать радио.
Второй фрагмент: "Figure 10.5 also includes a history pseudostate. This indicates that when the clock is switched on, the radio/CD choice goes back to the state the clock was in when it was turned off. The arrow from the history pseudostate indicates what state to be in on the first time when there is no history." То есть, переводчик снова отличился.

Пусть текущее состояние Off и происходит событие on. Совершается переход в композитное состояние с 2-мя ортогональными регионами. В этом переходе неявный fork, то есть, текущим станет сочетание из двух подсостояний, взятых из разных регионов. В верхнем регионе есть начальное псевдосостояние, следовательно, можно определить, что текущим станет DisplayTime. В нижнем регионе начального состояния нет. Значит, диаграмма ill formed. То, о чём пишет Фаулер, было бы справедливо, если бы нижний регион содержал начальное состояние. См. приложенный вариант. Подобные ошибки (псевдосостояние истории есть, а переходов в него нет) содержатся в книге Леоненкова.
На счёт И и ИЛИ стандарт указывает, что составные диаграммы как бы порождают И-ИЛИ дерево, описывающее какие конфигурации состояний допустимы. Для рассматриваемого примера дерево будет:
OR
 Off
 On
  AND
   OR
    DisplayTime
    DisplayAlarmTime
   OR
    PlayCD
    PlayRadio

Отдельно замечу, что на диаграмме отсутствуют действия и деятельности. То есть, работа радио, CD, отображение времени -- всё это в воображении. Автомат лишь переключается между состояниями, и больше ничего не делает. Тут было бы уместно вспомнить тему про то, чему не следует учить.

471
Дефектом обоих вариантов диаграммы является отсутствие в нижнем регионе начального состояния и перехода из него в историческое псевдосостояние. Т. о. в любом случае диаграмма ill formed.

472
Можно прибавить, что в книге Блахи и Рамбо есть пример другой диаграммы с такими же групповыми локальными переходами (стр. 151, рис. 6.11). Пример трактуется так же как у Фаулера.
P. S. Если бы на диаграмме Фауле переход был бы не локальным, а внешним, то после него была бы активной конфигурация состояний DisplayCurrentTime & PlayingRadio.

473
Здесь нет внутренних переходов. Переходы, начинающиеся с границы состояния On являются не внутренними, а локальными (и групповыми).
По стандарту владельцем перехода является регион. Может быть, этим и руководился Мартин Фаулер, приведший в своём "дистиллированном UML" эту диаграмму. Предположительно, он посчитал, что локальный переход по событию Radio относится только к его владельцу (нижнему региону) и подсостояниям, заключённым в нём.  По этой трактовке выходит, что DisplayAlarmTime & PlayingCD --Radio--> DisplayAlarmTime & PlayingRadio. Но в стандарте при описании групповых переходов ничего не говорится о регионах, а подчёркивается, что групповой переход исходит из (всего) композитного состояния. Поэтому возможна другая трактовка, по которой происходит выход из DisplayAlarmTime, т. е. групповой переход действует на все  подсостояния из обоих регионов On. И получается, что эта диаграмма ill formed.
Замечу, что попадается более прозрачная версия той же диаграммы, лишённая к тому же недостатка, из-за которого из PlayingRadio по событию Radio приходится выходить и тут же возвращаться обратно.

474
Где сказано, что они нужны? Вы смотрели юзкейс?
Почему частота не принципиальна при выборе считать/хранить?
Нет. Не любое. Новый метод расчёта может обеспечить сохранение адекватности данных, при некоторых изменениях. При других не сможет. Отсюда и был вопрос "как" и разговор о примере.
Вы слышали выражение "выводимый атрибут"? И кто теперь изобретает то, что собеседник не говорил?
Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.
Где я предлагаю "безграничные возможности"?
Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.
По-моему, всё прозрачно и ясно. "Популярные грабли", "система-однодневка", "плохой метод" видно не только мне.

475
Ну какое исключение, серьёзно. Вы знаете частоту, когда нужны эти даты? [В версии условий игрушечного примера частота = 0.] Вы уверены, что сразу станет плохо, как только начнут менять? Как менять? Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?
Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.
Ярлык подправьте так, как считаете нужным. Дело в ярлыке, а не в конкретной формулировке написанного на нём.

476
Да, не понимаю. Вы говорите о данных, про которые не известно, нужны ли они. На этом шатком основании делаете выводы о решении. От решения проводите обобщение до метода, который так же огульно объявляете универсально плохим. Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо. И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.
И всё это ради чего?

477
Зачем мне это?
Чтобы вернуться в реальный контекст.

Библиотеку? Я отметил в рекомендациях подход, применение которого (безотносительно предметной области) делает жизнь и предметных специалистов, и автоматизаторов значительно ярче и богаче. О чем и отписал.
Подход? KICK?

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

 
Дабы новичок видел, что не все альтернативы одинаково полезны. Может быть, это убережет его от получения личного опыта (и кто знает - может, даже меня от ликвидации последствий его получения новичком).
Уберечь новичка от получения личного опыта? Вы уверены, что хотите ему тем самым добра? И я так и не понял, Вы одну и ту же библиотеку устраиваетесь автоматизировать? Где каталогизация? Дублинское ядро? ISBNы где, в конце концов? Давайте уж тогда скажем прямо, что задачу из сообщения, открывшего тему, решать на самом деле не надо, так как она высосана из пальца.

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

479
Полагаю, что речь идёт о диаграммах размещения. Примеры диаграмм, нарисованных в EA:
http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/deploymentdiagram.html
http://www.sparxsystems.com.au/resources/tutorial/physical_models.html

480
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
Другие популярные грабли называются YAGNI. Можно делать вид, будто всерьёз делаешь ПО для библиотеки, а можно делать вид, что даёшь советы по учебному примеру. Что ему больше подходит, каждый решает за себя, не за другого.

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