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

×


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

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


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

Страницы: « 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 »
241
1) "Include" и "extend" не стереотипы.
2) Авторы большинства подобных тем не предоставляют достаточных сведений, чтобы была возможность ответить на их вопрос.
3) Беглого знакомства с книжкой Коберна обычно достаточно, чтобы самому себе дать адекватный ответ на подобный вопрос.

242
Реализация / Re: Композиция, Агрегация
« : 22 Декабря 2017, 16:27:34 »
[deleted]

243
Композиция и агрегация (а также ассоциация) определяют тип для описания однородных соединений между экземплярами. И накладывают ограничения на соединения между экземплярами. И это всё несмотря на то, что это связи между классами.
Меня такие картинки заставляют задумываться, что уместнее писать 1 или 0..1, ну и про всякие там фигурные скобочки и их внутренности. И про OCLи, которые к таким картинкам прилагаются как обязательная их часть.
Всё вышесказанное относится к контексту моей планеты, а не здешней. Любые совпадения/расхождения случайны.

244
На моей планете ДНК и РНК не слипаются по общей "нуклеотиде". А если и слипаются, то не делают вид, что общая "нуклеотида" не общая, а частная -- в монопольном владении каждого хозяина. Опять же стандарт UML с моей планеты такое делать не велит.

245
Для всех / Re: Решения задач UML
« : 14 Декабря 2017, 19:27:50 »
Вот я поспорю. В зоопарке антураж совсем не тот, что в сказке.

Диаграмма классов может подойти если зайти со стороны классификации сказок. Вроде:
Сказка
AA
| |
| L__ ЛитературнаяСказка
L_ФольклорнаяСказка

ФольклорнаяСказка
AAA
| | |
| | L__ ВолшебнаяСказка
| L__ ...
L_СказкаOЖивотных

СказкаOЖивотных
AAA
| | |
| | L__ ...
| L__ ...
L_СказкаПроЛису

И вот наконец наша сказка -- экземпляр класса СказкаПроЛису

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

246
На диаграмме чего-то странное с закрашенными ромбиками творится. Так что я -- тоже новичок и тоже пока ничего не понимаю. На языке стандартного UML прочесть её нельзя.

247
Для всех / Re: Решения задач UML
« : 13 Декабря 2017, 18:54:24 »
При некоторой вольности прочтения такая диаграмма и для зоопарка сгодится.

248
Если что, мне розовая диаграмма кажется симпатичнее чем серая. Только бы редефайнов навставлять и наследование как-нибудь позамысловатее -- начинать от линий ассоциации.) На серой рука тянется объявить, что наследование подчиняется "принципу Рамбо" и считать, что наследники наследуют от класса ассоциации только классовую часть.
А решение с одним классом ассоциацией, у которого опциональные поля и составные части, рассматривалось?

249
Дайте, пожалуйста, ссылку.
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", то можем смело метить атрибут этого сеттера выводимым.)))

250
Верим, поэтому конечно "подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация", но это необязательно обозначать на диаграмме, если у этой ассоциации нет ничего нового, по сравнению с исходной.
Если читать стандарт UML 2.5 буквально, то в 11.5.4 (стр. 200) описано как должен изображаться класс ассоциации. И там ничего не говорится о том, что наследование делает какие-то элементы нотации класса ассоциации необязательными. Интересно, что класс ассоциации единый элемент модели, но изображается сразу тремя графическими конструкциями: линией ассоциации (или "ромбиком с лучами", если она n-арная) + пунктирчиком + "висюлькой" класса. И обобщение, по идее, можно рисовать, стартуя от любой части, и финишируя в любой части.
Кстати "Лизковой" - это здорово, сразу видно, что речь идет о женщине, а то некоторые об этом забывают (а то и не знали никогда)
Может быть тут правильнее "принцип Лисковы" (полагая, что Liskov -- Лискова).
А вот Рамбо не верит в LSP. И нам не велит.) [Upd: Перепутало Рамбо с Бертраном Мейером. Да и тот, не то, чтобы не верит в LSP, просто не считает его чем-то значительным и связанным именно с Лисков.] Какой-то зловред вроде него включил в стандарт "isSubstitutable"-свойство обобщения (9.2.3.2), указывающее подчиняется ли наследник LSP или нет.

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

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

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

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

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

252
Вот-вот, если про создание сказать нечего, кроме того, что есть правило расчета значения атрибута создаваемого объекта - можно и не создавать операцию со стереотипом <<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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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