316

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

« : 19 Мая 2017, 18:24:10 »

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

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

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

317

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

« : 18 Мая 2017, 01:51:53 »

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

318

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

« : 15 Мая 2017, 19:12:45 »

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

319

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 19:49:14 »

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

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

320

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 18:04:16 »

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

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

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

321

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 13:24:57 »

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

322

ПО Аналитика / Re: Управление изменениями требований

« : 03 Мая 2017, 01:34:34 »

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

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

323

Для всех / Re: Реализация и документы

« : 30 Апреля 2017, 05:43:45 »

Подскажите пожалуйста, какие вообще диаграммы для чего используются?
Если уже есть развернутый ответ на форуме, укажите где.

Развернутый ответ есть здесь:
http://www.uml-diagrams.org/uml-25-diagrams.html

324

ПО Аналитика / Re: Управление изменениями требований

« : 29 Апреля 2017, 21:50:35 »

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

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

325

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 19 Апреля 2017, 22:39:47 »

Для меня если условие на исходящем звене проверяется не заранее, а по достижении, то это по сути - choice.

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

326

Для всех / Re: Помогите создать классовую диаграмму

« : 15 Апреля 2017, 11:09:36 »

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

327

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 14 Апреля 2017, 23:33:41 »

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

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

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

Ссылка на Матлаб прекрасна. Там и про 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

328

UML SysML и пр. / Re: Переход от псевдосостояния истории

« : 14 Апреля 2017, 23:05:44 »

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

329

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 11 Апреля 2017, 12:57:27 »

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, допустимы.

330

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 10 Апреля 2017, 15:58:50 »

Звено от junction к choice не обладает действиями, поэтому склеивая звенья-половинки (и действия на них) получим те же действия, что и на другой половинке.
Звено от junction к choice не обладает сторожем, что равносильно постоянной ИСТИНЕ, поэтому склеивая звенья-половинки и перемножая сторожей получим того же сторожа, что и на другой половинке.

Дело не в склеивании как таковом. При удалении junction мы вместо одного сложного перехода получаем несколько простых, решенных статически. Тут так не удастся: либо создастся дубль choice со звеном одновременно входящим и выходящим из него (и это будет его единственный вход); либо создастся бесконечное количество "простых" переходов: с одним, с двумя, с тремя, ... с N, ... choice'ами без "рефлексивного звена". Отвечая я мысленно дорисовываю действия к Вашему примеру, т. к. обеднённый частный случай, к. м. к. не показателен.   

А возможны ли недостижимые вершины для well formed? Понимаю, что инструмент (типа EA) их должен поддерживать - как иначе сохранить промежуточный результат работы над диаграммой/моделью, но в конечном результате им нет места!

Разрешено всё, что не запрещено.) Я не знаю. Мне кажется, в попытках определять ill- и well formed создатели стандарта UML пока не преуспели.