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

×


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

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


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

Страницы: « 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 34 35 »
316
Думаю, тут снова проявляется безалаберность авторов [текста] стандарта.
В книге Dragan Milicev "Model-Driven Development with Executable UML" (pdf-ка есть на bookfi) хорошо разъясняется взгляд на readonly-атрибуты, frozen-атрибуты, выводимые атрибуты. ReadOnly = замороженные сразу после инициализации + без возможности разморозки. NonReadOnly выводимые (по стандарту UML) = обычные атрибуты с единственной особенностью: их значения можно посчитать по другим значениям, но, вообще говоря, неизвестно когда и как посчитать. Отсюда ReadOnly выводимые (по стандарту UML) = замороженные сразу после инициализации + без возможности разморозки атрибуты с единственной особенностью: их значения можно посчитать по другим значениям, но, вообще говоря, неизвестно когда и как посчитать.
Итого: можно ставить слэш перед Накладная::фиоКладовщика {readOnly}, и пытаться отражать "когда" и "где" оно выводится постусловием конструктора. Это не требует делать {readOnly} атрибут Склад::фиоКладовщика.

317
Но по моим представлением так описывается несколько другая ситуация: да в дальнейшем фиоКладовщика изменяться не сможет, но при заведении накладной в фиоКладовщика можно внести что угодно, просто в качестве начального значения для редактирования будет предложено значение равное Склад.фиоКладовщика, а не пустышка.
Если просто описать постусловие конструктора и этим ограничиться, то сказанное будет справедливо (у атрибута будет значение по умолчанию, которое после инициализации можно менять). Если к постусловию (или к указанию начального значения) добавляется {readOnly}, это делает значение по умолчанию неизменным в течение всего времени существования объекта (после инициализации).

P. S. Концы ассоциаций могут быть помечены {readOnly}. Но предпочтение тэга/мема дело привычки.

318
Попробую, как обычно, внести путаницу.
По стандарту frozen больше нет, есть {readOnly}.
По стандарту объект любого класса создаётся "голеньким", независимо от того, указаны начальные значения атрибутов или нет. Объект создаёт специальная создающая деятельность (её можно рисовать на диаграмме деятельности). Сразу после того как создающая деятельность отработала, запускается инициализирующая деятельность, которая вычисляет начальные значения и присваивает их ({readOnly} и не-{readOnly} атрибутам с начальными значениями). Стандарт пишет, мол, часто инициализирующую деятельность моделируют как конструктор -- операцию с подходящей сигнатурой и стереотипом <<create>>. Конструктору можно указать постусловие. На диаграмме это выглядит как приякоренное к конструктору примечание с пометкой post:. В постусловии можно использовать постфикс @pre, чтобы лишний раз указать, что значение берётся таким, каким оно было до вызова конструктора. Но даже если это не сделать, стандарт определяет момент вычисления выражения, описывающего начальное значение. Т. о. короткое описание того, что в начальном посте:
в Накладной фиоКладовщика:string=Склад.фиоКладовщика {readOnly}
См. 6.3.3 в нижней части стр. 15.

319
По существу помочь автору темы затруднительно. Диаграмму классов ему нужно нарисовать, чтобы сдать задание, а про что это задание (бизнес-модель/модель системы) неизвестно. Подозреваю, что задание про то, чтобы нарисовать диаграмму классов. И выхода из цикла нет. Может быть поэтому диаграмма, приложенная в начале темы, выглядит химерой.
В рамках флуда [скореее флейма], можно заметить, что бывают диаграммы классов, на которых участников бизнес-процессов изображают в виде классов. И они придуманы не институтскими преподами. Например:

320
Что же, потоком идёт прежняя "милота". "Стандартный" русский язык не включает в себя "строительное" и/или криминальное "арго". А раз так, то общение на нём со строителем -- не лучший выбор. В контексте стройки он -- плохой язык. И т. п. и т. д. И учить русский язык -- потеря времени. А любое произведение какого-либо русского писателя -- повод для "ржаки".

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

321
Недостатки онлайновой рисовалки коллеги по форуму нашли очень быстро. И принесли мне "граблей". Благодарю. Вопросов моих, таким образом, как бы не было. Узнаваемый стиль.

Скобочки можно опустить. Именовать так, как привычнее. "Лишнюю" среднюю палку убрать. Можно убрать и рамочки, заменив на охотников.

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

322
Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".
А почему это не UML, если автор, это нарисовавший, считает, что рассказывает про UML?

323
Само пошутило, само поржало.  ;D
Небезызвестный Kirill Fakhroutdinov считает, что это " typical misconception", что я перевожу на язык тутошней планеты как "популярные грабли".

Кто в этот раз напишет "+100500 к граблям"? Вопрос риторический.

324
Для всех / Re: Реализация и документы
« : 30 Апреля 2017, 05:43:45 »
Подскажите пожалуйста, какие вообще диаграммы для чего используются?
Если уже есть развернутый ответ на форуме, укажите где.
Развернутый ответ есть здесь:
http://www.uml-diagrams.org/uml-25-diagrams.html

325
Цитировать
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html

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

326
Для меня если условие на исходящем звене проверяется не заранее, а по достижении, то это по сути - choice.
Я так поняло, что если бы были действия (transition action) на циклическом звене, то цикла бы было как бы два. Сначала перед выходом из состояния ходили бы и считали в уме круги, а уж потом бы вышли и сколько насчитали, столько бы раз запустили transition action. Жуткий гибрид.)

327
Можно заметить, что сделанное EA больше похоже на db.png, чем Ваша диаграмма классов. И сделать из этого выводы.
До вторника можно успеть нагуглить книжку Джима Коналлена с примерами диаграмм, похожих на те, что Вам нужны.

328
Другой причины для дублирования кроме одновходовости пока не придумывается.

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

Конечно, если диаграмма рисуется для чтения человеком, то "мертвое" лучше с неё убрать.

Ссылка на Матлаб прекрасна. Там и про history junction замечательно написано. Только переводчик ленивый.) Пример без действий, и локальный переход может быть нелокальным -- смысл не меняется. Есть полный пример с действиями: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant35.html#1028350
Ну и "вкуснятинка" вроде того, что "вертолётной площадки" достаточно, переход в неё может не вести, любой переход к границе суперсостояния на самом деле ведёт к ней (если история не пуста).
И это не choice'ы, это такие junction'ы.) Цикл отработает до выхода из состояния)): http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant40.html
Их можно ставить всюду, даже после начального псевдосостояния. Начальных может быть несколько: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant31.html
А иногда их можно использовать для того, чтобы вернуться назад как ни в чём не бывало: http://info.eps.surrey.ac.uk/SCS/manuals/matlab65/toolbox/stateflow/semant45.html

329
Буч как первоисточник кучи ошибок, это здорово. Может быть, всё дело в различиях версий UML?

330
1. Да, по стандарту.

2. Нет. Если State1 и/или State2 -- junction'ы, то прежде следует преобразовывать их. Если State1 и/или State2 -- не junction'ы, и State3 -- choice, то [если мы верим в одновходовые choice] State3 дублируется State3bis и мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут ветки State3]
State2 --[guard2 && guard3]/act2, act3-->State3bis--> [тут ветки State3]

3. Если State2 = State3 и эта вершина choice, то мы получаем:
State1 --[guard1 && guard2]/act1, act3-->State3--> [тут нерефлексивные ветки State3]
к State3 дорисовываем дополнительную ветку, соответствующую одному витку цикла:
State3 --[guard2 && guard3]/act2, act3-->State3bis--> [тут нерефлексивные ветки State3]
к State3bis дорисовываем дополнительную ветку, соответствующую двум виткам цикла:
State3bis --[guard2 && guard3]/act2, act3-->State3bisbis--> [тут нерефлексивные ветки State3]
к State3bisbis дорисовываем ...
т. е. выращиваем бесконечное дерево переходов-звеньев.
Это если придерживаться духа стандартных примеров по использованию junction и choice.
Либо, как предлагалось, превращаем choice в обычное состояние.

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

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