226

Реализация / Re: Композиция, Агрегация

« : 22 Декабря 2017, 16:27:34 »

[deleted]

227

Задачи студентов / Re: Перевод с UML на русский язык

« : 15 Декабря 2017, 17:25:35 »

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

228

Задачи студентов / Re: Перевод с UML на русский язык

« : 15 Декабря 2017, 00:20:22 »

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

229

Для всех / Re: Решения задач UML

« : 14 Декабря 2017, 19:27:50 »

Вот я поспорю. В зоопарке антураж совсем не тот, что в сказке.

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

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

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

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

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

230

Задачи студентов / Re: Перевод с UML на русский язык

« : 14 Декабря 2017, 19:08:00 »

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

231

Для всех / Re: Решения задач UML

« : 13 Декабря 2017, 18:54:24 »

При некоторой вольности прочтения такая диаграмма и для зоопарка сгодится.

232

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

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

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

233

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

234

ПО Аналитика / 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ьная "троица".

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

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

235

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

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

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

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

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

236

Примеры / 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).

237

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

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

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

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

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

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

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

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

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

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

238

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

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

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

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

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

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

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

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

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

239

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

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

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

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

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

240

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

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

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

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