Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Виктор Малышко от 02 Января 2013, 23:55:41
-
На зачёте был послан студентом в Википедию с напутствием, мол, правильные диаграммы состояний в википедии, а на лекциях -- неправильные.
Пошёл по указанному адресу. И что же там вижу:
(http://upload.wikimedia.org/wikipedia/commons/b/be/UML_state_diagram.png)
http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B9_%28UML%29 (http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B9_%28UML%29)
Что необычно, в английской есть такой же бред:
http://en.wikipedia.org/wiki/State_diagram_%28UML%29 (http://en.wikipedia.org/wiki/State_diagram_%28UML%29)
Правда, имеется нормальная статья:
http://en.wikipedia.org/wiki/UML_state_machine (http://en.wikipedia.org/wiki/UML_state_machine), но отчего-то для перевода в русскую википедию выбрали не её.
-
Виктор, добрый день. С Новым годом.
Ну все правильно ;). Диаграммы состояний вот такие, а диаграммы автоматов другие :)
Если серьезно, думаю тут все относительно просто. Первая статья небольшая, перевести ее большого труда не составило. Таким образом некто Пес-призраг сохранил себя в истории.
Причем английская страница ведет на несколько иную страницу на русском http://ru.wikipedia.org/wiki/Диаграмма_состояний_(теория_автоматов), которая по созданию СТАРШЕЕ других англоязычных аналогов :)
Однако вот подобные статьи - удар по репутации.
-
Виктор, что не так с диаграммой?
-
1. [start] - определено как сторожевое условие, но это неправильно. Start - не условие, а триггер
2. и т.д.
n-1. retrivial - незнакомое слово, имелось в виду видимо Retrival - считывание.
n. использование do/wait просто глупо
n+1. вообще не сказано, что за объект. Это не есть гуд
-
а в этой статье по-вашему правильно изображена диаграмма деятельности http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8 (http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8)
?
-
Есть ошибки. Некоторые стрелки не показаны. Возможно есть семантическая путаница. Ситаксически практически верно. Прагматику понять тоже можно - попытка описать алгоритм проведения мозгового штурма, вполне к месту
-
а в этой статье по-вашему правильно изображена диаграмма деятельности?
Абстрагируясь от смысла, плохими являются следующие фрагменты:
1) Есть три узла действия, в которые входят по два потока управления. По UML 2.0 узел осуществляет синхронизацию таких потоков. Согласно диаграмме возникнет блокировка в этих узлах.
2) Присутствуют "склеенные" потоки (т. е. две стрелки выходят из разных узлов, сливаются и втыкаются в один). Следовало явно указать merge-узлы.
3) Не ошибка, но рекомендуется не объединять decision и merge узлы в один. Т. е. в ромбике либо один вход и несколько выходов, либо несколько входов и один выход.
-
Виктор, добрый день. С Новым годом.
Эдуард, благодарю за поздравления! Поздравляю с Рождеством! Благополучия и проветания!
-
Виктор, что не так с диаграммой?
Эдуард указал, что перепутаны сторожевые условия и триггеры. Из-за этого триггером всех переходов будет событие завершения. Для состояния Running, в котором нет ни действий, ни деятельности, это полная бессмыслица. Из каждого состояния по событию завершения может быть запущен один из двух исходящих переходов. Независимо от того, что имелось в виду под условиями на переходах, возможен недетерминизм, если оба условия выполнены, который вряд ли тут хотели проиллюстрировать. А если по завершении не выполнилось ни одно из условий, происходит блокировка автомата, так как событие завершения больше не наступит.
Деятельность wait в состоянии Paused -- то, от чего пытаюсь отучить студентов в течение семестра. Автор диаграммы полагает, что чтобы ничего не делать, надо делать "ничего".
-
Можно полюбоваться на диаграмму композитной структуры:
http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BD%D0%BE%D0%B9_%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D1%8B (http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BD%D0%BE%D0%B9_%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D1%8B)
Логика видимо такая, если вокруг фрагмента диаграммы классов нарисовать овал, сразу получается композитная структура.
-
Логика видимо такая, если вокруг фрагмента диаграммы классов нарисовать овал, сразу получается композитная структура.
Есть предложение показать ошибки или правильную диаграмму :)
-
Есть предложение показать ошибки или правильную диаграмму :)
Первое сделать проще, чем второе.
По стандарту частями кооперации являются экземпляры, не классы. Поэтому внутри овала не могут находиться классы, тем более невозможно связать части кооперации наследованием. С точки зрения стандарта затруднительно представить образец Декоратор в виде кооперации.
-
Абстрагируясь от смысла, плохими являются следующие фрагменты:
1) Есть три узла действия, в которые входят по два потока управления. По UML 2.0 узел осуществляет синхронизацию таких потоков. Согласно диаграмме возникнет блокировка в этих узлах.
2) Присутствуют "склеенные" потоки (т. е. две стрелки выходят из разных узлов, сливаются и втыкаются в один). Следовало явно указать merge-узлы.
3) Не ошибка, но рекомендуется не объединять decision и merge узлы в один. Т. е. в ромбике либо один вход и несколько выходов, либо несколько входов и один выход.
вот это я и хотел услышать, чтоб убедиться - не мне одному так кажется
-
Эдуард указал, что перепутаны сторожевые условия и триггеры. Из-за этого триггером всех переходов будет событие завершения. Для состояния Running, в котором нет ни действий, ни деятельности, это полная бессмыслица. Из каждого состояния по событию завершения может быть запущен один из двух исходящих переходов. Независимо от того, что имелось в виду под условиями на переходах, возможен недетерминизм, если оба условия выполнены, который вряд ли тут хотели проиллюстрировать. А если по завершении не выполнилось ни одно из условий, происходит блокировка автомата, так как событие завершения больше не наступит.
Деятельность wait в состоянии Paused -- то, от чего пытаюсь отучить студентов в течение семестра. Автор диаграммы полагает, что чтобы ничего не делать, надо делать "ничего".
В статье там представлена диаграмма состояния неизвестного объекта с неизвестными бизнес-правилами в неизвестной версии нотации.
Причём из названия «пример диаграммы состояний» не следует, что это эталонная диаграмма. Это просто КАКАЯ-то диаграмма, возможно, с ошибками и в содержании и нотации модели.
На мой взгляд, всё это говорит плохо о UML в той же степени, что и о wikipedia.
Если то, что кружки/квадратики обозначают состояния чего-то, а стрелки — возможные направления перехода, понятно большинству людей из их опыта столкновения с инфографикой, начиная с детского возраста, то вот обозначения сторожевых условий / условий перехода — это уже похоже какая-то книжная муть, типа include/extend у use case diagram.
Если вам действительно не всё равно, можете пойти и поправить диаграмму в статье на ту, которая отражает известную предметную область, типа семейного статуса человека в США.
Студенту нашли, что ответить?
-
то вот обозначения сторожевых условий / условий перехода — это уже похоже какая-то книжная муть, типа include/extend у use case diagram.
сторожевое условие - это не муть и далеко не типа include/extend у use case diagram.
в предложенном примере, эти условия реально вообще не нужны. Они нужны тогда и в первую очередь тогда, когда из состояния имеются несколько переходов.
диаграммы состояний (или автоматов) появились задолго до UML, так же как и теория автоматов, которая, конечно, порой недоступна каждому. Отличное использование ее можно найти в пакете Matlab - Stateflow
диаграммы так же бывают разными, просто иллюстрацией, или скрупулезной спецификацией. В отличии от многих диаграмма автоматов может быть строго математична.
диаграмма в UML теряет свою строгость, приобретая описательную силу и универсальность
-
сторожевое условие - это не муть и далеко не типа include/extend у use case diagram.
я написал ОБОЗНАЧЕНИЯ сторожевых условий, а не условия как таковые. Эд, не искажай цитаты.
в предложенном примере, эти условия реально вообще не нужны. Они нужны тогда и в первую очередь тогда, когда из состояния имеются несколько переходов.
Эд, не стучись в открытую дверь. Исходная диаграмма косая и кривая. Но, о чём говорю я — она косая и кривая в том числе в силу запутанности нотации, невозможности легко обнаружить её кривизну невооружённым взглядом.
диаграммы состояний (или автоматов) появились задолго до UML, так же как и теория автоматов, которая, конечно, порой недоступна каждому.
вот именно. были простые и понятные диаграммы. а потом появились комитеты по стандартизации, UML, SysML, OCL, которые усложнили синтаксис языка и мир погрузился во тьму :)
диаграммы так же бывают разными, просто иллюстрацией, или скрупулезной спецификацией. В отличии от многих диаграмма автоматов может быть строго математична.
может. формальная спецификация софта — это мечта всех технократов, учёных и CASE-MDA-кулибиных. Но в реальных проектах встречается не чаще, чем в 1% случаев — и на то есть понятные причины.
-
В статье там представлена диаграмма состояния неизвестного объекта с неизвестными бизнес-правилами в неизвестной версии нотации.
Причём из названия «пример диаграммы состояний» не следует, что это эталонная диаграмма. Это просто КАКАЯ-то диаграмма, возможно, с ошибками и в содержании и нотации модели.
В названии упомянут UML. В тексте даны ссылки на стандарт и др. Что можно оценить, как указание на нотацию.
На мой взгляд, всё это говорит плохо о UML в той же степени, что и о wikipedia.
У двух проектов много общего, но, как мне кажется, первый ещё не достиг состояния второго.
Если вам действительно не всё равно, можете пойти и поправить диаграмму в статье на ту, которая отражает известную предметную область, типа семейного статуса человека в США.
Мне всё равно, что сложено на вики-помойке.
Студенту нашли, что ответить?
Ага.
-
Денис, сигнатура перехода очень сильно следует сигнатуре нотации Харела. В матлабе ровно также обозначено.
В наших проектах, есть понятие жизненный цикл документа/объекта. Нотация автоматов UML активно и повсеместно используется.
-
Мне всё равно, что сложено на вики-помойке.
Если вам всё равно, то как родилась эта тема? «Я гнался за вами три квартала чтобы сказать, как глубоко вы мне безразличны»?
-
Тема родилась из желания указать на качество сведений, а не из желания это качество улучшать. Цитату оставляю на Ваше усмотрение.
-
Это очень странно, что преподаватель, вместо того, чтобы делиться знаниями в одном из лучших образовательных проектов интернета — википедии, хает её.
Википедия формируется кем-попало, в её правилах, как я понимаю, следующее:
1. Наличие информации лучше её отсутствия
2. Можешь дополнить чем-то полезным — дополняй
3. Дополняя, аргументируй приводимые сведения ссылками на авторитетные источники
-
Это очень странно, что преподаватель, вместо того, чтобы делиться знаниями в одном из лучших образовательных проектов интернета — википедии, хает её.
Денис, не очень понятно почему, если Виктор - преподаватель, он не может хаять википедию?
Впрочем исходная тема была в ином, если ты позволишь тебе напомнить, студент Виктора, ссылаясь на википедию, подвергает сомнению авторитет преподавателя.
С чем Виктор и поделился.
-
Эд, давай различать модальности — «странно» не равно «не может».
-
Можно предположить актуальность указанных трёх принципов и оценить результат следования им. Хотя, если ознакомиться с диспутами по удалению статей, можно усомниться в следовании первому принципу.
Но всё же. Берется откуда-то диаграмма, внешне похожая на диаграмму состояний, вклеивается в вики, подкрепляется ссылкой на стандарт, согласно которому она теряет какой-либо смысл. Затем всё это переводится на русский. В итоге -- информационный шум, который заслоняет для рядового пользователя Веб книги, учебники, пособия.
Википедия для меня -- странный проект.