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

×


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

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


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

Страницы: « 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
Ситуация из 9. чревата тогда, когда правило начального значения и правило производного значения приводят к разным результатам. Init это только на момент инициализации, а derive - и на момент инициализации, и на всю последующую жизнь! (readonly только на оставшуюся жизнь, но не на момент инициализации)
...
Производный атрибут может использоваться в invariant-ограничениях, а там неактуальным не место!
С Вами согласны авторы стандарта OCL 2.4 (см. 7.3.3, 7.3.7, 12.6, 12.9). Я спорить не буду, лишь замечу, что обороты вроде "всё время" употребимы для деклараций/спецификаций. С точки зрения реализации может быть достаточно [а может-- и нет], чтобы выводимый атрибут имел корректное значение всякий раз, когда оно затребовано. Такой ситуации отвечает описание ограничения как тела операции, а не как правила вывода. Быть может, то, что авторы UML 2.5 в метамодели UML описывают body, указывает на это обстоятельство. В этом можно увидеть различие между umlьным derive и oclьным (про oclьный явно сказано в тексте его стандарта, что он "всё время"). Забавно, что umlьные инварианты соблюдаются не всегда, если верить мелкому замечанию внутри 6.3.3. (мол, между вызовами операций объекта всё должно быть чики-пуки, а во время выполнения метода на инварианты смотрят сквозь пальцы).

У тех же Новикова и Иванова про derive:... Если убрать зависимый элемент и заменить все его использования на его derive-определение, ничего измениться не должно. А это возможно, если зависимый элемент постоянно будет актуальным.
Авторы "UML3" переводят пояснение, данное в стандарте к стереотипу <<derive>> из стандартного профиля, который можно применять к связям реализации и манифестации. Полагаю, что к этому случаю написанное и относится.

317
readonly и derived - это свойства "раз и навсегда", frozen (unfrozen) - только на время.
Согласно. Выше, говоря о связке readOnly с frozen, имело в виду, что readOnly=frozenForever.

Кроме того, если атрибут readonly, то делать его frozen (unfrozen) не имеет смысла - от этого ничего не изменится. И еще, если атрибут derived, то какой смысл давать ему defaultValue, разве что считать это дополнительным ограничением на те атрибуты, по которым вычисляется этот атрибут.
Речь шла не о совместном применении readOnly и frozen, а об общности их смыслов.
Меня озарило, что авторы стандарта дали кучу примеров использования обсуждаемых нами тегов и слэшей. Они даны на диаграммах (и OCLях) описывающих метамодель UML. На 9.5.2 есть такое: Property::/isComposite:Boolean=false (также в 9.9.17.5). Авторы демонстрируют свой приём моделирования. Для каждого выводимого атрибута (полюса ассоциации) ими заводится одноимённая операция, возвращающая выведенное значение. Если OCL позволяет, то операции даётся тело (удивительно, что не derive!). См. Property::isComposite() в 9.9.17.7. Если убрать начальное значение в этом примере, смысл сохранится. Есть подозрение, что явное выписывание начального значения тут -- подсказка читателю диаграммы, чтобы ему не пришлось искать тело и в уме делать вывод. В схожей ситуации 12.3.2 (12.4.1.4, 12.4.1.6), Extension::/isRequired:Boolean вместо =false указано {readOnly}. Налицо "эффект дрожжей". Есть ещё одно подозрение, что завихрения относительно readOnly + derived рождались у авторов стандарта и обкатывались на метамодели UML. Т. е. это их реализаторская точка зрения, в которой они путают "не может меняться извне" с "не может меняться после инициализации". По каким-то причинам авторам эта путаница удобна. О том, как быть остальным, они не заботились. Щепотка "дрожжей" нашлась в описании Message::/messageKind {readOnly}. Для выводимого атрибута задана операция, тело которой состоит из возврата значения взятого у самого атрибута.
 
Например описание атрибутов "длина, ширина, /площадь=6 {derive: длина*ширина}" означает: "Сразу после инициализации длина и ширина могут быть любыми числами, но их произведение должно равняться 6. Потом на длину и ширину не накладывается никаких ограничений, но площадь всегда будет равна их произведению.".
Я бы такое описание прочло так: Длина и ширина не имеют значений по умолчанию. Площадь по умолчанию равна 6. В какие-то моменты времени значение площади вычисляется как произведение длины на ширину. Чтобы описать, в какие именно моменты, следует дать диаграмму состояний и/или дать реализации операций класса Прямоугольник.

Эти авторы когда-то впечатлили меня фразой: "существуют три уровня понимания обучающимся нового предмета, которые характеризуются следующими признаками: 1. Возникает приятное чувство понимания; 2. Может повторить своими словами; 3. Видит ошибки. Данная книга написана на третьем уровне и адресована обучающимся, ориентированным на третий уровень" - взято отсюда. Про derived ничего не говорят, только про derive.
Авторы захаживали/захаживают на эту планету, так что я остановлюсь на первом предложенном ими уровне.

Склеиваем и получаем: как получилось расчетное значение сразу после инициализации, так дальше и не меняется, хотя все время пересчитывается.
Я полагаю, что слэш не устанавливает явной директивы, что нужно всё время пересчитывать. Стандарт на этот счёт лишь замечает, что изменение значения nonReadOnly выводимого свойства должно подчиняться derive-ограничению.

Рассмотрим класс "меняющийся прямоугольник" с атрибутами: длина, ширина, площадь, первоначальная площадь. Правильным описанием двух последних атрибутов будет: /площадь {derive: длина*ширина}, первоначальная площадь=площадь {readonly} (если считать, что "=defaultValue" отражает постусловие конструктора). Делать первоначальную площадь derive нельзя - тогда надо указывать правило вычисления. Или считать, что для атрибута с derived наличие "=defaultValue" (может в сочетании с readonly) служит правилом вычисления.
С точки зрения написанного мной выше этот пример может быть разобран так:
Значение первоначальной площади зависит от других значений, значит этот атрибут можно пометить как выводимый.
Указание начального значения у первоначальной площади, которая является {readOnly}, играет ту же роль, что и правило вычисления. При инициализации объекта будет вычислено то, что справа от равенства, результат будет положен в  первоначальную площадь, далее он меняться не будет.

318
Его frozen-атрибуты - это нечто не из UML (хотя явно где-то нужно).
Да. Но у него, на мой вкус, внятная позиция по тому, что это такое и как увязываются между собой {readOnly} и {frozen}. Если можно морозить, то можно и разморозить и т. п. Есть другой вариант внятной позиции.

А вот про совместное readonly и derived не увидел.
Совместное получается склеиванием раздельного, т. к. в стандарте оба свойства из метамодели независимы. Мы берём то, что сказано про readonly, и то, что сказано про derived и объединяем. Вот аналогия: теплое и сладкое -- это тёплое + сладкое. По намёкам из текущей версии стандарта выходит, что от соединения теплого и сладкого возникает дополнительный эффект "дрожжей" и градус в модели вдруг повышается.

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

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

Как правильно это понять ... не требует атрибут Склад::фиоКладовщика делать {readOnly}?
Второе. Извините за невнятность.

В исходных данных:
Для меня на данный момент проблема выглядит так:
  • используя readonly и конструктор можно нужную ситуацию описать
  • конструктор использовать не хочется
  • вместо конструктора можно отразить только его постусловие
  • "=defaultValue" не отражает постусловие
  • может "init: Накладная::фиоКладовщика = Склад::фиоКладовщика" отражает постусловие?
"=defaultValue" отражает постусловие конструктора в той части, в которой важно. И "init: Накладная::фиоКладовщика = Склад::фиоКладовщика" тоже. Просто в этих двух выражениях нет явной привязке ко времени, когда берётся присваиваемое значение. Эта привязка неявная, данная стандартом в пояснении к defaultValue. Постусловие, как мне кажется, нагляднее говорит о временнОй привязке. Выше писало про @pre, его можно [с некоторой тонкостью] использовать, что явно скажет о том, когда используется значение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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