256

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

« : 20 Ноября 2017, 23:20:19 »

Дайте, пожалуйста, ссылку.

https://www.uml-diagrams.org/derived-property.html

Derived property is property which value (or values) is produced or computed from other information...

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

257

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 20 Ноября 2017, 23:14:15 »

Верим, поэтому конечно "подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация", но это необязательно обозначать на диаграмме, если у этой ассоциации нет ничего нового, по сравнению с исходной.

Если читать стандарт UML 2.5 буквально, то в 11.5.4 (стр. 200) описано как должен изображаться класс ассоциации. И там ничего не говорится о том, что наследование делает какие-то элементы нотации класса ассоциации необязательными. Интересно, что класс ассоциации единый элемент модели, но изображается сразу тремя графическими конструкциями: линией ассоциации (или "ромбиком с лучами", если она n-арная) + пунктирчиком + "висюлькой" класса. И обобщение, по идее, можно рисовать, стартуя от любой части, и финишируя в любой части.

Кстати "Лизковой" - это здорово, сразу видно, что речь идет о женщине, а то некоторые об этом забывают (а то и не знали никогда)

Может быть тут правильнее "принцип Лисковы" (полагая, что Liskov -- Лискова).
А вот Рамбо не верит в LSP. И нам не велит.) [Upd: Перепутало Рамбо с Бертраном Мейером. Да и тот, не то, чтобы не верит в LSP, просто не считает его чем-то значительным и связанным именно с Лисков.] Какой-то зловред вроде него включил в стандарт "isSubstitutable"-свойство обобщения (9.2.3.2), указывающее подчиняется ли наследник LSP или нет.

А вот здесь есть новое, поэтому изображение ассоциации на диаграмме оправдано (но это выбор не инструмента, а пользователя, который, правда ошибся - 0..4 не может наследовать 0..2)

Тут, кстати, интересно разобрать. Экземпляром ассоциации является линк (соединение) у которого нет мощности. LSP оперирует экземплярами.

Так они могут захотеть чтобы я и остальные наследуемые свойства указывал - какая тогда выгода от такого изображения наследования

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

В наследнике доопределяется только то, что связано с его "классовой" сутью, поэтому на диаграмме отображается только класс (отображая и ассоциацию, что можно при ней указать - или ничего, или повторить то, что на родительской)

Здесь снова (как, может помните, на диаграммах состояний) сталкиваемся с желанием сделать каждый визуальный элемент отдельным элементом модели. А стандарт не велит [пока].

258

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 19 Ноября 2017, 16:47:42 »

Версия MagicDraw 16.5. Не могу создать связь подкласс-суперкласс, если суперкласс - класс-ассоциация, а подкласс - просто класс (не ассоциация).
Если пытаюсь перенести уже созданную (между классом и классом) связь - выдает сообщение-предупреждение: "Между этими элементами отношения заблокированы или не разрешаются".
Может есть какой-то вариант?
Кстати в обратную сторону сделать класс-ассоциацию подклассом просто класса - работает!

Если мы верим в принцип Лизковой, то подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация. В каноническом RUPовом примере наследник явно обозначен как класс ассоциация (хотя, там это оправдано по смыслу).

Может быть, создатели MagicDraw хотят, чтобы и Вы явно указывали наследника как класс ассоциацию.
В обратную сторону происходит усложнение предка в наследнике. От обычного класса берутся атрибуты, операции, связи. К ним добавляется всё то, что доопределено в наследнике.

259

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

« : 11 Ноября 2017, 02:53:31 »

Вот-вот, если про создание сказать нечего, кроме того, что есть правило расчета значения атрибута создаваемого объекта - можно и не создавать операцию со стереотипом <<create>>.

Авторы стандарта UML дают в описании метамодели UML пример, когда для каждого выводимого атрибута (тут у меня натяжка, т. к. выводимый м. б. <> есть правило расчёта) заводят операцию, поясняющую выводимость.
Почитало про выводимость у Фахрутдинова. Мне понравилось. По его формулировке можно сделать вывод, что если для атрибута есть сеттер, то он выводимый. Ну, или мой переводчик с английского на нлошный глючит.)
 

Мне избыточность (в виде возможности выразить одно и то же несколькими способами) тоже не очень нравится, хочется её приспособить для чего-нибудь нужного

Авторы стандарта uml позаботились о том, чтобы поставить рогатку на этом пути. В 9.5.3 сказано, что uml'ьный init работает только в отсутствие "specific setting for the Property"() и в отсутствие ocl'ьного init. Авторы стандарта ocl написали так, как-будто про uml'ьный init слыхом не слыхивали, т. е. подпели.
Плюс к этому, разные части uml'ного стандарта писали разные люди, из-за чего можно испытать много радости, читая, например, в 16.1.1.1, что создание объекта и "creation operation" могут содержать в себе инициализацию, но в то же время есть действие CreateObjectAction, которое только создаёт объект, не выполняет инициализацию атрибутов (которая моделируется отдельными действиями).

Или для решения свежей проблемы:можно было бы считать, что init не задает выражение, которое рассчитывает значение, а является логическим выражением, которое должно быть истинным в момент создания: для описанного примера context накладная init: self.склад.кладовщик->includes(self.кладовщик).Если так, то того же эффекта можно добиться сочетанием init или = (с выражением как в derive) и readOnly - и вычислим в момент создания объекта, и на элементы вычисляемого выражения никакого влияния.

Такая трактовка (лог. выражение, которое должно быть истинным) нестандартна (расходится со стандартом ocl).

260

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

« : 02 Ноября 2017, 05:54:02 »

Получается операция нужна только для того, чтобы к ней "приякорить" примечание - если в примечании указать, что оно относится к созданию Заявки (любому, не обязательно связанному с конкретной операцией), то этого достаточно.

Согласно текущей версии модели других способов создания заявок пока нет. Т. е. операция нужна, чтобы описать, как [вообще] создаются Заявки. К слову, в этом месте стандарт не декларирует, а рекомендует, т. е. указывает некоторую сложившуюся практику.

Примечание в этом случае будет связано не с конкретной операцией, а с <<create>> для Заявки.

С конкретной операцией (как элементом модели) будет связан конкретный экземпляр стереотипа <<create>>. С ним, в свою очередь, -- ограничение. Задать ограничение внутри класса для всех его конструкторов проблематично. Если мы не имеем в виду init:, конечно. Можно дать define-ом общее ограничение, но в каждом постусловии конструктора придётся явно сослаться на него.

Дублирование - это плохо

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

Теперь о новой проблеме. Пусть есть Склад, который связан не с одним, а со МНОГИМИ Кладовщиками. Накладная связана с одним Складом и с одним Кладовщиком (причем ни Склад, ни Кладовщик со временем не меняются {readOnly}). В момент создания Накладной её Кладовщик должен быть одним из Кладовщиков, связанных с её Складом, но это только в момент создания. Получается нужен init не типа derive (правило для вычисления значения), а типа invariant (правила проверки того, что значение является подходящим). Как init он действует только при создании, а как invariant не вычисляет, а проверяет.

Я всё ещё верю, что readOnly выводимые значения вычисляются [только] в момент создания объекта. Т. е. derive не "распространяет" readOnly дальше -- на элементы вычисляемого выражения.

261

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

« : 20 Октября 2017, 20:19:15 »

Вдруг уже не актуально, тогда простите.
На диаграмме классов описываем

Заявка
--------------------------------
датаСоздания : Дата = сегодня() {readOnly}
датаВстречи : Дата {readOnly}
--------------------------------
<<create>> новаяЗаявка(дВ : Дата) : Заявка

к этой операции приякориваем примечание о том, что пользователю в формочке для создания заявок предложат по умолчанию, и о том, что из формочки будет вызван этот конструктор.

на ocl пишем:
context Заявка::датаСоздания : Дата
init: сегодня()
Это мы продублировали кусок uml-ного описания атрибута, чтоб определение работало в два раза сильнее.))

context Заявка::новаяЗаявка(дВ : Дата) : Заявка
post: result.датаВстречи = дВ
это мы рассказали о том, что датаВстречи заполняется конструктором, параметром которого является значение даты.

Если есть желание утроить, то можно ещё
context Заявка::новаяЗаявка(дВ : Дата) : Заявка
post: result.Создания = сегодня()

Понятно, что дублирование ограничений делает модель менее модифицируемой. Вместо того, чтобы править в одном месте, правим в 2-3 местах.

262

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

« : 01 Октября 2017, 10:51:52 »

Другая диаграмма и/или связанное описание может пояснять то, что не отражено на первой. Но не может менять смысл, зафиксированный первой. Поэтому, обсуждая этот смысл, привлекать другие диаграммы означает отвлекаться от главного в пользу второстепенного.

В Agile Modeling, к слову, допускается противоречивость. Накосячили в одном месте (где неважно), исправили в другом (где важно).

Чеккер выдаёт перечень ошибок. Поскольку речь об поиске "ржак" на диаграммах, точка зрения чеккера уместнее.

263

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

« : 30 Сентября 2017, 23:13:07 »

Если бы имена элементов модели были бы важнее типов элементов и связей между ними, то для лучшего моделирования нужно было бы стереть человечков, овальчики, стрелочки. И заменить их на слова. Но напала блажь -- высказываться невербально, на графическом (и в том числе программно читаемом) языке. Представим себя программами-чеккерами. С такой точки зрения имена элементов модели -- лишь строчки. Смысл модели в наборе элементов, их свойствах, их связях. И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.

[Про остальное написало в личку.]

264

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

« : 30 Сентября 2017, 04:10:09 »

Видение такого известного популяризатора стандарта UML как Kirill Fakhroutdinov проиллюстрировано примером на его сайте:
http://www.uml-diagrams.org/bank-atm-uml-use-case-diagram-example.html
На минуту представим себя на планете, где банкоматы выдают деньги в обход банка. Или силами, почерпнутыми у Арлоу и Нейштадта на минуту обобщим Customer и Bank и "исправим" диаграмму. По-моему, неплохая выходит планета. Уже лечу к ней.

265

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

« : 30 Сентября 2017, 03:49:11 »

Тем, кто составляет список сект, могу предложить две: секта тех, кто читал стандарт; секта тех, кто не читал.
А теперь внимание. Анафему в студию! Или недостатки модели сами транзитивно переползают на автора модели?

С крепнущей уважухой,
НЛО

266

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

« : 30 Сентября 2017, 03:44:06 »

Первая часть абзаца весьма логична и не вижу способов опровергнуть такие выводы. Другая часть, по-моему, эмоциональная. Неужели, НЛО, Вам ведомы земные страсти и сарказм?

Это с кем поведёшься (про страсти и сарказм). Если возможно, то обсуждению моей персоны и того, что мне ведомо, прошу посвятить отдельную тему.

Но. Возьмем таких авторитетов UML как Арлоу и Нейшдат (в своей книге uml2 и UP) в разделе 5.2 описывают как возникает обобщение (кстати ни в руководстве по UML2, ни в книге Рамбо и Блаха, почти ничего об этом не пишется).

Книга Арлоу и Нейштадта не про RUP.
Книга Арлоу и Нейштадта не является спецификацией UML.
Книга Арлоу и Нейштадта написана в 2006 году, а стандарты OMG 2.5 и ISO 19505-1 и -2 много позже.
Да, Рамбо почти ничего не пишет по ВИ. Потому что их придумал Якобсон. Можно сходить на его сайт, найти там презентуху "USE-CASE 2.0" и на одной из первых страниц увидеть проиллюстированное примером видение изобретателя термина ВИ.
Можно мысленно проделать трансформацию по методу Арлоу и Нейштадта примера из 2.4.1, породив обобщающее действующее лицо от Customer и Supervisor, и убедиться, что обобщение действующих лиц не является способом борьбы с "пересекающимися линиями". Разумная трактовка их манипуляций заключается в том, что эскизная диаграмма с ошибкой при помощи трансформации, исправляющей ошибку приводится к верной модели.

Думаю, что утверждение про то, что по стандарту нельзя однозначное и прямое толкование найти, следует обосновать. Сделайте это, а потом я прилечу и с ведомым мне сарказмом проверю Ваше обоснование на прочность.

267

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

« : 28 Сентября 2017, 19:10:50 »

Вполне себе справедливо утверждение.
В стандарте 2.4.1 есть диаграмма:

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

268

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

« : 28 Сентября 2017, 12:37:30 »

Смешная диаграмма про воинов продолжает работать в рекламе курса.
Уважуха. ОО-анализ на языке, похожем на UML, отчего бы нет.

В новой версии видеоролика смешную диаграмму про воинов убрали. Вторую смешную диаграмму оставили. А что делать? Нельзя же рекламировать курс про "анализ на" так называемом "UML" совсем без диаграмм.
Что мы видим на единственной диаграмме?

Крановщик с технологом могут войти в систему только вместе, взявшись за руки? "Ржака" -- если использовать предложенный нам термин. Но для анализа на языке, похожем на UML, сойдёт.

С неизменной уважухой,
НЛО

269

Задачи студентов / Re: Отношение между классами

« : 21 Сентября 2017, 14:08:39 »

Агрегацию нарисуем, когда почка станет искусственной, т. е. "имплантируемым в организм гемодиализным аппаратом".
Сейчас композиция показывает, что, например, при кремации невырезанные почки сгорают вместе с трупом.
[Б-р-р. Улетаю. Тема зашла куда-то не туда.]

270

Задачи студентов / Re: Отношение между классами

« : 19 Сентября 2017, 21:14:35 »

Или вот другая история.
Сначала на нашей планете думали, что: Человек◆-1---1..2-Почка.
Потом прилетели пришельцы и научили трансплантологии. Выяснилось, что:  Человек◆-0..1---0..2-Почка (с двумя почкам рождается, с 1-2 живёт, из трупа можно вырезать все и пересадить, до пересадки не более чем 72 часа почка живет сама по себе в холодильнике). Трансплантологи подзуживают, что на самом деле Человек◆-0..1---0..3-Почка, так как можно вшить доп. почку к имеющимся двум, и такое было. На нашей планете.